Re: [rtcweb] Use of offer / answer semantics

[Bernard Aboba <[e-mail]>]

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

[BA] I do *not* agree that RTCWEB should have to support every aspect of SDP offer/answer.   Basic offer/answer, sure.  All potential corner cases?  Not necessarily. 

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

[BA] This seems like a good principle, but I'm not clear that it will work with all use cases.  For example, what happens in the E911 use cases when an RTCWEB implementation attempts to make a call to a PSAP implementing NENA i3 Stage 3?  If you don't have a media gateway, then the browser will need to implement one of the mandated codecs on the PSAP side.  So in those use cases, eliminating the media gateway implies making G.711 and H.264 mandatory-to-implement.  

> > 3) When a new codec is specified, and the SDP 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).

[BA] Agree with "no new standardization".  But that doesn't mean that applications will automatically "just work", right?  That's a much harder requirement.

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

[BA] Agree that it's not worth fighting, but making it clear what we do and do not support will be a "fight" of sorts.  That is, unless you're willing to require that the browser be able to *everything* enabled by RFC 3264.  Personally, I don't think that is worthwhile.