Ваш клієнт не може прийняти дзвінок, поки телефон заблоковано. Або з'являється відлуння, яке дратує обох співрозмовників. А іноді дзвінок обривається, коли приходить 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 включає його за замовчуванням.
Деталі вибору аудіокодека
Opus — адаптивний кодек, бітрейт від 6 до 510 кбіт/с. Підтримує стерео та багатоканальний звук. Для сумісності з SIP-телефонами можуть знадобитися G.711 (PCMA/PCMU) або G.722. При виборі кодека враховуйте: підтримку на клієнтах, ширину каналу, вимоги до якості.Порівняння підходів: Managed SDK vs WebRTC
| Параметр | Managed SDK (Twilio, Agora) | WebRTC + TURN |
|---|---|---|
| Складність розробки | Низька | Середня |
| Вартість хвилини | ~$0.004–0.01 | ~$0.001 (свій TURN) |
| Контроль | Обмежений | Повний |
| Затримка | Залежить від SDK | Мінімальна (<100 мс) |
| Необхідні ресурси | Немає | TURN-сервер |
Managed SDK простіше в розробці, але WebRTC дозволяє заощадити до 80% витрат на дзвінки при власній інфраструктурі TURN. При високому навантаженні (більше 10 000 хвилин на місяць) різниця стає суттєвою.
Типові помилки та їх рішення
| Помилка | Рішення |
|---|---|
| Відлуння | Встановлення MODE_IN_COMMUNICATION на обох платформах + AEC (акустична ехоподавлення) |
| Дзвінок не приходить на заблокований екран | Інтеграція CallKit/ConnectionService |
| Затримка >300 мс | Налаштування P2P ICE, TURN тільки як fallback |
| Переривання при SMS | Обробка AVAudioSessionInterruptionNotification (iOS) та AudioManager (Android) |
| Bluetooth звук не перемикається | Явне керування SCO через BroadcastReceiver |
Що входить в роботу
- Аналіз вимог та вибір оптимального стеку (WebRTC, Twilio, Agora або кастомний SIP).
- Проектування сигнального каналу (WebSocket, SIP або власний протокол).
- Розгортання TURN-сервера (coturn) та налаштування ICE-кандидатів.
- Інтеграція CallKit (iOS) та ConnectionService (Android) з PushKit/FCM.
- Тестування на 20+ реальних пристроях з різними версіями ОС та мережевими умовами.
- Оптимізація аудіоякості: AEC, адаптивний jitter buffer, корекція втрат пакетів.
- Документація та навчання команди замовника.
- Підтримка після запуску (моніторинг, bugfix, доопрацювання).
Процес розробки VoIP-дзвінків
- Аналіз вимог та вибір стеку (managed SDK vs WebRTC).
- Проектування сигнального та медіаканалу.
- Розгортання TURN-сервера та налаштування ICE.
- Інтеграція CallKit/ConnectionService та PushKit/FCM.
- Тестування на реальних пристроях з різними мережевими умовами.
- Оптимізація аудіоякості та усунення артефактів.
- Деплой та моніторинг.
Зв'яжіться з нами, щоб обговорити архітектуру вашого VoIP-рішення. Замовте розробку, і ми гарантуємо стабільні дзвінки без відлуння та обривів. Отримайте консультацію інженера — ми готові допомогти.