问题描述
我正在使用 WebRTC 构建一个视频通话应用程序，该应用程序允许一个对等方通过在大厅中选择某人来呼叫另一个对等方。当对等体 A 发送呼叫请求时，其他对等体 B 可以接受。此时，WebRTC信令开始：
- 双方都使用 MediaDevices.getUserMedia() 获取本地媒体
- 双方都创建了一个 RTCPeerConnection 并附加了事件侦听器
- 双方都调用 RTCPeerConnection.addTrack() 添加本地媒体
- 一个对等方 A（不礼貌的用户）创建一个提议，调用 RTCPeerConnection.setLocalDescription() 将该提议设置为本地描述，并将其发送到 WebSocket 服务器，后者将其转发给另一个对等方 B。
- 另一个peer B收到这个offer并添加调用RTCPeerConnection.setRemoteDescription()将其记录为远程描述
- 另一个对等点 B 然后创建一个答案并将其再次传输给第一个对等点 A。
（基于 https://developer.mozilla.org/en-US/docs/Web/API/WebRTC_API/Connectivity 的步骤）
此流程几乎运行良好。在十分之一的呼叫中，我没有收到来自其中一个对等方的视频/音频（而两个对等方都有工作的本地视频）。在这种情况下，我注意到答案 SDP 包含 a=recvonly 而这在正常情况下应该是 a=sendrecv。
我进一步确定，到对方收到offer需要回复的时候，这边的localMedia有时还没有添加，因为MediaDevices.getUserMedia可能需要一段时间才能完成。我还通过记录和观察报价有时在添加本地曲目之前到达来确认此操作顺序。
我假设在添加本地媒体之前我不应该发送答案？
我正在考虑解决此问题的两种方法，但我不确定哪个选项最好（如果有）：
- 仅在 MediaDevices.getUserMedia() 完成后创建 RTCPeerConnection。同时，在接收报价时，还没有对等连接，因此我们将报价保存在缓冲区中，以便稍后在创建 RTCPeerConnection 后对其进行处理。
- 当收到报价时，并且还没有 localMedia 轨道，请在添加 localMedia 轨道之前暂缓创建答案。
我很难决定哪种（或另一种）解决方案最适合“完美协商”模式。
提前致谢！
解决方法
暂无找到可以解决该程序问题的有效方法，小编努力寻找整理中！
如果你已经找到好的解决方法，欢迎将解决方案带上本链接一起发送给小编。
小编邮箱:dio#foxmail.com (将#修改为@）