问题描述
问题来自here，看来还没有人给出正确的答案。
=================================
嗨，开发人员
我正在开发一个包含音频通话功能的社交应用程序。我为此音频通话与SocketIO + WebRTC集成。我通过两种方式接收音频呼叫。 连接套接字并激活后的套接字调用 默认情况下，无论是否连接套接字，VoIP呼叫。
仅供参考，为什么我有两种如上所述的接听电话的方式，
- 默认情况下启用VoIP，因为有时套接字呼叫没有响应，并且从不显示呼叫。
- 在应用程序处于前台时启用套接字，以确保在VoIP推送发生MissingDevicetoken / BadDevicetoken错误时能够接收到呼叫。
考虑到iOS 13 VoIP使用指南，我按照以下步骤进行了集成。
-
当应用程序被杀死或套接字未连接时，将获得VoIP呼叫并使用provider.reportNewIncomingCall（）进行响应。因此，这里的VoIP使用没有问题。
-
连接套接字后，将同时获得套接字呼叫和VoIP呼叫。但是套接字呼叫会在获得VoIP呼叫之前立即获得。所以这就是我所做的：
provider.reportCall(with: call.uuid,updated: update)具有用于套接字调用启动的相同uuid和update。
希望此VoIP呼叫也可以通过CallKit响应，并且VoIP阻止/应用终止没有问题。
问题1：这是处理上述问题的适当方法吗？
================================================ ================================================== =========
根据我的应用程序要求，我的应用程序一次应该有一个活动呼叫。
考虑一下，我正在通话中，并且通过VoIP接到了另一个来电。因此，在这里，我不想显示其他呼叫。因此，我忽略了额外呼叫的VoIP推送。但这会导致崩溃：“杀死应用程序，因为它在收到PushKit VoIP推送回调后从未向系统发布传入呼叫。”
问题2：如何处理上述情况？
================================================ ================================================== =========
我尝试
对于问题2，我尝试从this one回答。
尽管在某些情况下（例如，当用户碰巧以足够快的速度接听电话时）不起作用，但来自推送的第二个来电将显示“呼叫堆叠”屏幕。
此方法还会在最近的呼叫列表中创建其他呼叫，并显示一条条状呼叫，该呼叫说呼叫在第一个传入事件的传入屏幕期间结束，这是糟糕的用户体验。
我还发现this one看起来很有前途，但众所周知这会很好。
有人对此有任何解决方案吗？ 谢谢
解决方法
正如一位Apple工程师在技术支持请求中确认我那样，我的answer在理论上是正确的。但是，实际上，由于PushKit和CallKit的异步特性，如果没有不必要的报告呼叫或因报告失败而崩溃，基本上是不可能做到这一点的。因此，强烈建议不要这样做。
因此，对于问题2，如果this answer对您来说不可接受，那么我看到的唯一解决方案是让服务器为您处理。因此，服务器应具有正在进行的呼叫列表，并避免将VoIP推送发送给已参与呼叫的用户。
对于问题1，您实现的解决方案并不十分可靠：您无法在异步环境中对事件的顺序进行任何假设。在套接字呼叫之前可能会收到VoIP推送，在这种情况下，您将无法报告新的来话，因为您只是报告呼叫更新。或者，再举一个更微妙的示例：您大致同时收到推送和套接字调用，由于套接字调用而报告了新的来话呼叫，但是（请记住，CallKit是异步的）而系统正在处理新的来电呼叫请求，您就可以处理VoIP推送而无需报告新的来话呼叫。
我认为，处理这种情况的更简单方法是拥有一种并且只有一种方法来处理新的来电，这就是通过VoIP推送。这样，您的应用程序在任何情况下都可以工作，并且在应用程序终止或已经运行时，不必为收到的呼叫实现两个不同的代码路径。