Re: JSEP proposal

Great to see this written up - it's somewhat different than I was imagining so good to see it written down because I was probably imaging the wrong sort of thing. 

Few questions to try and make sure I understand the proposal. I want to get my head around how this would all work before trying to decide how it compares to other proposals. 

In the scenario where we start with voice and later add video, I assume that after the initial call is set up, the side that wants to add video will call the createOffer method then setLocalDescription and later when the answer is received will call the setRemoteDescription. Do I have that right ?

And when you say SDP, you mean RFC 3264 offer/answer SDP?

When the JS calls createOffer before a connect(), what transport addresses and/or ICE candidates get put in the SDP returned in the offer?

I assume that connect() is what starts gathering of STUN / TURN candidates?

If the JS calls createOffer(), then changes the offer a bit and then passes it to setLocalDescription, what things in the offer can JS change and what does it need to keep the same?

Thanks - and no rush on reply - I am only checking email every few days and suspect this thread will take some time to sort out all the parts of it. 


On Dec 17, 2011, at 16:11 , Justin Uberti wrote:

> For your holiday reading pleasure, here is the initial version of the JSEP proposal for moving the signaling state machine out of the browser and into Javascript.
> Right now this is in a Google doc, but I will be submitting it as an Internet-Draft soon as well.
> Please have a look and send comments, either in the doc, to the list, or directly to me.
> Happy Holidays,
> --justin

Received on Sunday, 18 December 2011 22:43:38 UTC