1

我正在使用 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的步骤）

这个流程几乎运行良好。在 10 次通话中，有 1 次没有收到来自其中一位同伴的视频/音频（而两位同伴都有可用的本地视频）。在这种情况下，我注意到 SDP 包含的答案a=recvonly应该是a=sendrecv在正常情况下。我进一步确定，当对方收到offer需要回复的时候，这边的localMedia有时还没有添加，因为MediaDevices.getUserMedia可能需要一段时间才能完成。我还通过记录并观察报价有时在添加本地曲目之前到达来确认此操作顺序。

我假设在添加本地媒体之前我不应该发送答案？

我正在考虑两种方法来解决这个问题，但我不确定哪个选项是最好的，如果有的话：

  • 仅在 MediaDevices.getUserMedia() 完成后创建 RTCPeerConnection。同时，当接收到一个 offer 时，还没有对等连接，所以我们将 offer 保存在缓冲区中，以便在创建 RTCPeerConnection 后处理它们。
  • 当收到一个报价，并且还没有 localMedia 轨道时，请推迟创建答案，直到添加 localMedia 轨道。

我很难决定哪种解决方案（或另一个）最适合“完美谈判”模式。

提前致谢！

4

1 回答 1

2

是的，如果您“静态地”执行此操作，最好在创建报价之前添加流，但最好的方法是在 onnegotiationneeded 事件中执行此操作，因为 addtrack 事件会触发 onnegotiationneeded 事件。因此，您应该添加流，然后在 onnegotiationneeded 中使用 createoffer。就答案而言，您之前可以毫无问题地完成，但请记住，建立良好的连接将使您可以毫无问题地添加/删除曲目（即使在设置了 SDP 之后）。您没有发布任何代码，但请记住您还必须交换 ice 候选人。最后一条建议，请记住以上所有内容都是异步的！所以你应该使用承诺，并等待直到描述设置好，然后才创建一个提议/答案。希望这会有所帮助

于 2021-06-17T11:56:16.860 回答