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

Question

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

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

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

Answer 2

此处有一个有用的图表 http://www.w3.org/TR/webrtc/#examples-and-call-flows，它说明了调用流程并显示了调用的内容和调用时间。就我个人而言，我发现图表更能说明问题。它遵循提供-回答模型。

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

Am I taking the correct approach in implementing WebRTC?

javascript

webrtc