Re: [rtcweb] Use of offer / answer semantics

[Harald Alvestrand <[e-mail]>]

Getting everyone confused by not doing a deep inline answer, but 
replying to the first message on the thread......

On 09/06/11 16:46, Cullen Jennings wrote:
> In my roll as an individual contributor, I want to propose some text that I think we can get rough consensus on around that helps specify which parts of the signaling issues we agree on and which we don't.
>
> At the last meeting, my read of the the room was there was a fair amount of agreement in the room that offer / answer semantics  with SDP are what we want to use. I don't think there was was broad agreement on if one should use SIP or not, or for that matter jingle. If we can nail down this decisions as the direction the WG is going, it will really help make progress. What I would like to do is propose some following principles in the text below. If we have agreement on these, then they would go into the overview document and help guide the design of other documents. I want to highlight that none of the principles below imply that we would need to use SIP in the browsers - the principals would all work fine if we there was signaling gateway in the web server that converged SIP to whatever proprietary HTML / JS  / HTTP that the applications wanted to use between the browser and the web server.
>
>
>
> 1) The media negotiations will be done using the same SDP offer/answer semantics that are used in SIP.
To be precise - you're suggesting that we use RFC 3264 offer/answer 
semantics. (That RFC is 25 pages long. RFC 3261, the core SIP document, 
is 269 pages, and is NOT a normative reference from 3264. I am anxious 
to avoid having a normative dependency on 3261.)

I agree with this.
> 2) It will be possible to gateway between legacy SIP devices that support ICE and appropriate RTP / SDP mechanisms and codecs without using a media gateway. A signaling gateway to convert between the signaling on the web side to the SIP signaling may be needed.
I agree with this - I think the "may be needed" will turn out to be 
"will be needed", but some portion of that gateway can be implemented by 
Javascript running in the browser, if desirable.
> 3) When a new codec is specified, and the SPD for the new codec is specified in the MMUSIC WG, no other standardization would should be required for it to be possible to use that in the web browsers. Adding a new codecs which might have new SDP parameters should not change the APIs between the browser and javascript application. As soon as the browsers support the new codec, old applications written before the codecs was specified should automatically be able to use the new codec where appropriate with no changes to the JS applications.
I agree with this (modulo spelling and WG name fixups).

I decided that the fight against SDP was not worth fighting after 
listening to the dozens of WGs doing SDP extensions for various 
purposes, many of which might make sense to incorporate in a browser 
platform, and concluding that SDP wouldn't hold still enough for us to 
specify a gateway from/to it.

                         Harald