这个项目中有相当多的代码。目前,我没有收到将远程流添加到RTCPeerConnection
的回调。我不是在此时提供代码示例,而是仅仅验证我采用了有效的方法来设置连接。
getUserMedia()
,在成功回调期间,RTCPeerConnection
已创建,createOffer()
。在回调期间,localDescription设置,这是开始寻找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);
答案 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,用于说明呼叫流程,并显示要呼叫的内容和时间。就个人而言,我发现图表更好地讲述了这个故事。它遵循提供 - 答案模型。