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

Question

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

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

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

WebRTC 内部日志（感谢@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 can't be called before SetRemoteDescription.

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

Answer 1

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

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

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

Answer 2

这里有一个有用的图表http://www.w3.org/TR/webrtc/#examples-and-call-flows，它说明了调用流程并显示了调用的内容和时间。就个人而言，我发现图表更好地讲述了这个故事。它遵循offer-answer模型。