Joey Carson
Joey Carson

Reputation: 3113

Am I taking the correct approach in implementing WebRTC?

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.

  1. A node.js backend server manages websocket connections to facilitate peer discovery. The server is working just fine.
  2. When a client requests the peer page, it sets up the connection during the onload handler.
  3. During onload, the client opens a websocket to the server, the server remembers the client by IP:PORT string.
  4. The client calls 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.
  5. When all ICE candidates have been gathered, the client registers with the server, sending its local description, ICE candidates, etc. to the server.
  6. The server notifies any other connected clients that a new per has joined, sending the sdp object and all ICE candidates as well. This makes each client aware of the ICE candidates and SDP object for all other clients.
  7. All peers react by creating a UI element for a user to click to initiate a call.
  8. When the user clicks the UI element, the associated remote peer's information is looked up and each one of the remote peer's ICE candidates are added to the peer connection, SDP object is added as the remote description, and the an invite request is sent to the server.
  9. The server notifies the associated client that is being invited.
  10. The peer that receives the notification then looks up the peer that is initiating the call and adds all of that peer's ICE candidates and remote description. It then calls 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

Answers (2)

jonpd
jonpd

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

Philipp Hancke
Philipp Hancke

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

Related Questions