Я занимаюсь разработкой приложения для социальных сетей, которое включает функцию аудиовызова. Я интегрировал с SocketIO + WebRT C для этого аудиовызова. Я получаю аудиовызов двумя способами.
- Сокет-вызов, когда сокет подключен и активен
- VoIP-вызов по умолчанию независимо от того, подключен сокет или нет.
К вашему сведению, почему у меня было два способа получения вызова, как упомянуто выше,
- Включен VoIP по умолчанию, потому что иногда вызов сокета не отвечает и никогда не показывает вызов в это время.
- Включен сокет, когда приложение находится на переднем плане, чтобы гарантировать получение вызова в случае ошибок MissingDeviceToken / BadDeviceToken для VoIP pu sh.
С учетом iOS 13 рекомендаций для использования VoIP, я следовал ниже шагам для интеграции.
- Когда приложение убито или сокет не подключен, получит вызов VoIP и ответит provider.reportNewIncomingCall () . Так что здесь нет проблем для использования VoIP.
Когда сокет подключен, получит как вызов сокета, так и вызов VoIP. Но вызов сокета будет получен мгновенно перед получением вызова VoIP. Итак, вот что я сделал:
Ответ на вызов сокета с помощью provider.reportNewIncomingCall () .
После небольшой задержки получит VoIP pu sh для того же вызова, который уже вызван сокетом. Здесь я должен ответить на это
VoIP pu sh с помощью CallKit. Но я уже вызвал вызов. Итак, я использовал приведенный ниже код для обработки.
- provider.reportCall (with: call.uuid, updated: update) с тем же идентификатором uuid & update, который использовался для инициализации вызова сокета. Надеюсь, этот вызов VoIP также ответил CallKit, и нет никаких проблем с блокировкой VoIP / завершением приложения.
Вопрос 1: Это правильный способ решения вышеуказанного вопроса?
===============================
Согласно моему требование к приложению, должен быть один активный вызов за раз из моего приложения.
Учтите, я нахожусь в активном вызове, и еще один входящий вызов принимается через VoIP. Итак, я не хочу показывать дополнительный звонок. Поэтому я игнорирую VoIP pu sh для дополнительного вызова. Но это приводит к этому «sh» приложению «Killing», потому что оно никогда не отправляло входящий вызов в систему после получения обратного вызова PushKit VoIP pu sh. »
Вопрос 2: Как обрабатывать выше упомянутый сценарий?
========================= 1064 *