Розробка голосових дзвінків (VoIP) у мобільному додатку

Ваш клієнт не може прийняти дзвінок, поки телефон заблоковано. Або з'являється відлуння, яке дратує обох співрозмовників. А іноді дзвінок обривається, коли приходить SMS. Ці баги — типові наслідки неповноцінної інтеграції VoIP. Ми вирішуємо їх на рівні архітектури, спираючись на досвід у телемедицині, логістиці та корпоративних комунікаціях.

Реалізація VoIP-дзвінків у мобільному додатку — не одне завдання, а кілька пов'язаних технічних шарів: сигнальний протокол, медіатранспорт, керування аудіосесією та інтеграція з системними API дзвінків. Пропустити або спростити будь-який із цих шарів — отримати дзвінок, який працює в демо, але ламається в продакшні: відлуння, пропадання звуку при вхідному сповіщенні, неможливість прийняти дзвінок із заблокованого екрану.

Як працює CallKit?

На iOS VoIP без CallKit технічно можливий, але додаток не отримує аудіосесію при вхідному дзвінку на заблокованому екрані, система не показує системний екран вхідного дзвінка, а після iOS 13 додатки без CallKit не отримують PushKit сповіщення для VoIP. CallKit — системний фреймворк, який показує системний екран вхідного дзвінка, керує аудіосесією, підтримує Bluetooth/AirPods та відображає дзвінки в історії викликів.

import CallKit
class CallManager: NSObject {
  let provider: CXProvider
  let callController = CXCallController()

  init() {
    let config = CXProviderConfiguration()
    config.supportsVideo = false
    config.maximumCallsPerCallGroup = 1
    config.supportedHandleTypes = [.phoneNumber, .emailAddress]
    provider = CXProvider(configuration: config)
    super.init()
    provider.setDelegate(self, queue: nil)
  }

  func reportIncomingCall(uuid: UUID, callerName: String) {
    let update = CXCallUpdate()
    update.remoteHandle = CXHandle(type: .generic, value: callerName)
    update.hasVideo = false
    provider.reportNewIncomingCall(with: uuid, update: update) { error in
      // починаємо відповідати на дзвінок після дозволу системи
    }
  }
}

PushKit для вхідних дзвінків у фоновому режимі. На відміну від звичайних APNs push, PushKit будить додаток миттєво і з високим пріоритетом. Але з iOS 13 Apple вимагає негайно викликати reportNewIncomingCall при отриманні VoIP push — інакше додаток завершується з crash. Не можна робити мережевий запит перед викликом CallKit.

Android: ConnectionService та Telecom API

Аналог CallKit на Android — ConnectionService з пакету android.telecom. Дозволяє додатку стати «телефонним акаунтом» у системі, показувати дзвінки на екрані блокування, керувати аудіомаршрутизацією. Для вхідних дзвінків у фоні — FCM push з priority: high. На Android 14+ фонові сервіси обмежені, але ForegroundService типу phoneCall (доданий в Android 14) вирішує саме це завдання — у нього немає обмежень на запуск при вхідному дзвінку.

Керування аудіосесією через AudioManager:

val audioManager = context.getSystemService(Context.AUDIO_SERVICE) as AudioManager
audioManager.mode = AudioManager.MODE_IN_COMMUNICATION
audioManager.isSpeakerphoneOn = false
// при завершенні: audioManager.mode = AudioManager.MODE_NORMAL

Bluetooth-гарнітури — окремий головний біль. BluetoothHeadset profile, SCO з'єднання для голосу (не A2DP!), BroadcastReceiver на ACTION_SCO_AUDIO_STATE_UPDATED. Без явного керування SCO звук йде через динамік навіть при підключеній Bluetooth-гарнітурі.

Чому важливий TURN-сервер?

Якщо використовуємо WebRTC самостійно (а не через Twilio/Vonage), потрібен TURN-сервер для пробивання NAT. Без нього дзвінки працюють тільки в одній мережі — класичний баг на демо, який ламається у клієнта за офісним NAT. TURN-сервер також допомагає при симетричних NAT, коли стандартний STUN не спрацьовує.

coturn — open source TURN сервер, розгортається на VPS за кілька годин. Конфігурація ICE:

// Android WebRTC SDK
val iceServers = listOf(
    PeerConnection.IceServer.builder("stun:stun.example.com:3478")
        .createIceServer(),
    PeerConnection.IceServer.builder("turn:turn.example.com:3478")
        .setUsername("user")
        .setPassword("password")
        .createIceServer()
)

Кодеки: Opus для аудіо (адаптивний бітрейт 6–510 кбіт/с, добре працює при втратах пакетів до 20%). WebRTC SDK включає його за замовчуванням.

Порівняння підходів: Managed SDK vs WebRTC

Managed SDK простіше в розробці, але WebRTC дозволяє заощадити до 80% витрат на дзвінки при власній інфраструктурі TURN. При високому навантаженні (більше 10 000 хвилин на місяць) різниця стає суттєвою.

Типові помилки та їх рішення

Що входить в роботу

• Аналіз вимог та вибір оптимального стеку (WebRTC, Twilio, Agora або кастомний SIP).
• Проєктування сигнального каналу (WebSocket, SIP або власний протокол).
• Розгортання TURN-сервера (coturn) та налаштування ICE-кандидатів.
• Інтеграція CallKit (iOS) та ConnectionService (Android) з PushKit/FCM.
• Тестування на 20+ реальних пристроях з різними версіями ОС та мережевими умовами.
• Оптимізація аудіоякості: AEC, адаптивний jitter buffer, корекція втрат пакетів.
• Документація та навчання команди замовника.
• Підтримка після запуску (моніторинг, bugfix, доопрацювання).

Процес розробки VoIP-дзвінків

1. Аналіз вимог та вибір стеку (managed SDK vs WebRTC).
2. Проектування сигнального та медіаканалу.
3. Розгортання TURN-сервера та налаштування ICE.
4. Інтеграція CallKit/ConnectionService та PushKit/FCM.
5. Тестування на реальних пристроях з різними мережевими умовами.
6. Оптимізація аудіоякості та усунення артефактів.
7. Деплой та моніторинг.

Зв'яжіться з нами, щоб обговорити архітектуру вашого VoIP-рішення. Замовте розробку, і ми гарантуємо стабільні дзвінки без відлуння та обривів. Отримайте консультацію інженера — ми готові допомогти.