Reputation: 3113
There's quite a good amount of code in this project. At the moment, I'm not getting a callback to add the remote stream to my RTCPeerConnection
. Instead of providing a code sample at this point, I'd rather just verify that I'm taking a valid approach to setting up the connection.
getUserMedia()
and during the success callback, the RTCPeerConnection
is created, and createOffer()
. During the callback, the localDescription set, which is what kicks off finding ICE candidates.createAnswer()
.At this point, my expectation is that the WebRTC stack would start the underlying session initiation and both peers would get the addstream callback to hook up the video. Is this a good approach? Is it necessary for the workflow to happen in a different order?
The WebRTC-internals log (thanks @Philipp Hancke) shows the following. Even though my code is calling createAnswer
after 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);
Upvotes: 5
Views: 796
Reputation: 356
There is useful diagram here http://www.w3.org/TR/webrtc/#examples-and-call-flows that illustrates the call flow and shows what to call and when. Personally, I find the diagram tells the story better. It follows the offer-answer model.
Upvotes: 0
Reputation: 17295
Not using trickle ice is going to have a very negative impact on call setup time but that might be a concern here. You probably want to access the peerconnections .localDescription in step 5 so you send an offer containing all candidates.
Note that you can't share an offer with multiple peers in step 8. But it doesn't sound like you intend to do this. Actually you want to call createAnswer in step 8 and send it to the client (along with any ice candidates) in step 9. In step 10, you call setRemoteDescription at the caller.
This sounds slightly different from what you're describing which might explain why you don't get a remote stream. Make sure the order of createOffer, setLocalDescription, setRemoteDescription is the same as the one seen on apprtc.appspot.com when you inspect it in chrome://webrtc-internals -- the caller should not have to call createAnswer.
Upvotes: 1