我在实施 WebRTC 时采取了正确的方法吗？

Question

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

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

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

WebRTC-internals 日志（感谢@Philipp Hancke）显示以下内容。即使我的代码createAnswer在之后调用setRemoteDescription()

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 can't be called before SetRemoteDescription.

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

Answer 1

不使用滴流冰将对呼叫建立时间产生非常负面的影响，但这可能是一个问题。您可能希望在步骤 5 中访问对等连接 .localDescription，以便发送包含所有候选人的录用通知。

请注意，您无法在第 8 步中与多个同行共享报价。但听起来您并不打算这样做。实际上，您想在步骤 8 中调用 createAnswer，并在步骤 9 中将其发送给客户端（以及任何ice 候选者）。在步骤 10 中，您在调用者处调用 setRemoteDescription。

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