Overview of a peer connection lifetime

[Alexandre GOUAILLARD]

Dear all,

I see a lot of questions on the mailing list, in my course, and during the meetups about the different states and flow of a peer connection. I thought I should share a slide that shows an overview of what you should expect, as it proved helpful for some as a reference.

Note:

- italic bold blue items are not mandatory, and should regarded as work arounds. However their use is so widespread that I thought I should place them in the right place in the flow, so people know when to modify the sdp, filter the candidates and so on.

- How to set up the signaling and the GUM part are left out. There are way too many variants.

- Not all the ICE states are currently implemented in the browsers (failed and completed are missing).

- This drawing is for trickle ICE.

- This drawing is for one peer connection only, multiparty, and topologies of connection are left out. For each connection in your app, you have all those states and items repeated.

Any feedback is welcome.

Cheers.

alex.

--

Alex. Gouaillard, PhD, PhD, MBA

------------------------------------------------------------------------------------

CTO - Temasys Communications, S'pore / Mountain View

President - CoSMo Software, Cambridge, MA

------------------------------------------------------------------------------------

sg.linkedin.com/agouaillard

• 
  

[C.G. Anderson]

Sweet! Thanks!

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Leighton Carr]

Hi Alex,

Nice job on the diagram.  Just my $0.02 - although caller / callee is mostly based on how the individual signal-server is set up, I find it more intuitive to think about the initial offer as the call.  I noticed you had the callee sending the initial offer - is this intended?

Cheers,

Leighton.

[Alexandre GOUAILLARD]

I noticed it this morning, after a flood of feedback. I put it wrong in the slide. Good catch, and thanks for the feedback.

I also added a few missing arrows, a 'BYE' signal that triggers the close state of peer connection and/or is triggered by that very same state.

I'm letting the dust settle, and I'll provided an updated version.

cheers.

For more options, visit https://groups.google.com/d/optout.

[Alexandre GOUAILLARD]

Here is the updated and fixed slide, thanks all for the feedbacks

By the way, ICE Connection states 'completed' and 'failed' have just landed in chrome 8 hours ago. Everybody that had implemented timeouts, or any other kind of workaround, to handle cleanly the disconnected state can start removing them.

http://code.google.com/p/webrtc/issues/detail?id=1414

[Arafat Al Mahmud]

• • In the diagram, you mentioned that addRemoteStream(s) should be called after setRemote(offer) (or setRemote(answer)). So far, I couldn't find any such method in the RTCPeerConnection object. Exactly what are you indicating to do ?

[Alexandre GOUAILLARD]

hi,

From the top of my head,  setRemoteDescription triggers parsing of the SDP, which in turn triggers onRemoteStreamADD JS event. Your application could/should catch this event and decide what to do (for example, create an HTML video element and assign the media stream, which is the second parameter of the triggered event, to the media element for display).

HTH.

Alex.