Re: JSEP proposal

Comments inline.

On Sun, Dec 18, 2011 at 5:43 PM, Cullen Jennings <fluffy@cisco.com> wrote:

>
> 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 ?
>

Yes. The adder of the video will need to keep the old description around,
in the event the request is rejected. Alternatively, it could choose to
only apply the new local description once the request is accepted, although
this could lead to media clipping.


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

Yes.


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

None currently. The c= line will have some placeholder address to make the
SDP valid, but the application would have to add the ICE a= lines itself.


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


Yes.


>
> 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?
>

I would think it could change anything other than the ICE information,
provided that the new description is compatible with the requirements set
out in http://tools.ietf.org/id/draft-cbran-rtcweb-media-00.txt and
http://www.ietf.org/id/draft-ietf-rtcweb-security-01.txt

For example, it could rearrange or remove codecs, change payload type ids,
etc. Given that the UA has to be able to handle arbitrary remote
descriptions, handling modified local descriptions should not be hard.


>
> 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.
>
> Cullen
>
>
>
>
> 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.
> >
> >
> https://docs.google.com/a/google.com/document/d/1L_3SyFM4aeiOoWUOpVVw6anvp63gF6boiVWa9dQ_2AY/edit?hl=en_US
> >
> > 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
>
>