我是否采用了正确的方法来实施WebRTC?

时间:2015-04-12 01:39:17

标签: javascript webrtc

这个项目中有相当多的代码。目前,我没有收到将远程流添加到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()
  11. 此时,我的期望是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);
    

2 个答案:

答案 0 :(得分:1)

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

请注意,您无法在步骤8中与多个同行共享优惠。但听起来并不像您打算这样做。实际上,您希望在步骤8中调用createAnswer并在步骤9中将其发送到客户端(以及任何候选冰)。在步骤10中,您在调用者处调用setRemoteDescription。

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

答案 1 :(得分:0)

此处有一个有用的图表http://www.w3.org/TR/webrtc/#examples-and-call-flows,用于说明呼叫流程,并显示要呼叫的内容和时间。就个人而言,我发现图表更好地讲述了这个故事。它遵循提供 - 答案模型。