javascript - 我在实现 WebRTC 时采取了正确的方法吗？

Question

这个项目中有相当多的代码。目前，我没有收到将远程流添加到我的 RTCPeerConnection 的回调。此时我不想提供代码示例，而只是验证我是否采用了有效的方法来设置连接。

1. node.js 后端服务器管理 websocket 连接以促进对等发现。服务器工作正常。
2. 当客户端请求对等页面时，它会在加载处理程序期间建立连接。
3. 在onload期间，客户端向服务器打开一个websocket，服务器通过IP:PORT字符串记住客户端。
4. 客户端调用 getUserMedia() 并在成功回调期间创建 RTCPeerConnection，并执行 createOffer()。在回调期间，设置了 localDescription，这是寻找 ICE 候选人的开始。
5. 收集到所有 ICE 候选人后，客户端向服务器注册，将其本地描述、ICE 候选人等发送到服务器。
6. 服务器通知任何其他连接的客户端一个新的 per 已加入，同时发送 sdp 对象和所有 ICE 候选者。这使每个客户端都知道所有其他客户端的 ICE 候选人和 SDP 对象。
7. 所有同行都通过创建一个 UI 元素来使用react，用户可以点击该元素来发起调用。
8. 当用户单击 UI 元素时，将查找关联的远程对等点的信息，并将远程对等点的每个 ICE 候选者添加到对等点连接，添加 SDP 对象作为远程描述，并发出邀请请求发送到服务器。
9. 服务器通知被邀请的关联客户端。
10. 收到通知的对等方然后查找发起调用的对等方并添加该对等方的所有 ICE 候选者和远程描述。然后调用 createAnswer()。

在这一点上，我的期望是 WebRTC 堆栈将启动底层 session 启动，并且两个对等方都将获得 addstream 回调以连接视频。这是一个好方法吗？工作流是否有必要以不同的顺序发生？

WebRTC-internals 日志(感谢@Philipp Hancke)显示以下内容。即使我的代码在 setRemoteDescription()

之后调用了 createAnswer

4/12/2015, 6:35:26 PM   setRemoteDescription 
4/12/2015, 6:35:26 PM   createAnswer 
4/12/2015, 6:35:26 PM   setRemoteDescriptionOnFailure
4/12/2015, 6:35:26 PM   createAnswerOnFailure

CreateAnswer 不能在 SetRemoteDescription 之前调用。

rtcPeer.conn.setRemoteDescription(new RTCSessionDescription(remotePeers[msgObj.peer].sdp));
rtcPeer.conn.createAnswer(createOfferSuccess);

Answer 1

不使用滴流冰会对调用建立时间产生非常负面的影响，但这可能是一个问题。您可能希望在第 5 步中访问 peerconnections .localDescription，以便发送包含所有候选人的报价。

请注意，您不能在第 8 步中与多个同行共享优惠。但听起来您并不打算这样做。实际上，您想在第 8 步调用 createAnswer，并在第 9 步将其发送给客户端(连同任何 ice 候选者)。在第 10 步，您在调用方调用 setRemoteDescription。

这听起来与您所描述的略有不同，这可能解释了为什么您没有获得远程流。确保 createOffer、setLocalDescription、setRemoteDescription 的顺序与您在 chrome://webrtc-internals 中检查时在 apprtc.appspot.com 上看到的顺序相同——调用者不必调用 createAnswer。