Re: [rtcweb] Use of offer / answer semantics

[Harald Alvestrand <[e-mail]>]

On 09/08/11 06:45, Bernard Aboba wrote:
>
> > > 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.
If we start off from:
- RFC 3264 assuming that we support all of it, and then list the parts 
we don't want
- RFC 3261 assuming we support none of it, and list the parts we do want
we might have a better dialogue (or at least a more precise one).
>
> > > 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.
Unless RTCWEB mandtory codecs have some overlap with the NENA i3 Stage 3 
codecs, you have given a good argument for why NENA i3 Stage 3 devices 
should not be in the list of "legacy SIP devices that support ICE and 
appropriate RTP / SDP mechanisms and codecs".

I'm still hoping that some day, someone will show up with a serial 
number and software version for a device they definitely think should be 
in the "legacy SIP devices that support ICE and appropriate RTP / SDP 
mechanisms and codecs" category.
>
> > > 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.
Nothing ever "just works"..... but simple cases should continue to work.
>
> > 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.
I think we agree. Let's get down to specifics (in another thread).