Re: [rtcweb] Use of offer / answer semantics

Harald Alvestrand <> Thu, 08 September 2011 10:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 975E721F8B08 for <>; Thu, 8 Sep 2011 03:48:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -107.888
X-Spam-Status: No, score=-107.888 tagged_above=-999 required=5 tests=[AWL=2.710, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Q6fcpJyG+65e for <>; Thu, 8 Sep 2011 03:48:45 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 75BB321F8B01 for <>; Thu, 8 Sep 2011 03:48:45 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id E0A9C39E0F3; Thu, 8 Sep 2011 12:50:36 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qXTNxLCeWitp; Thu, 8 Sep 2011 12:50:36 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTPS id 0497139E074; Thu, 8 Sep 2011 12:50:36 +0200 (CEST)
Message-ID: <>
Date: Thu, 08 Sep 2011 12:50:35 +0200
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: Bernard Aboba <>
References: <>, <> <BLU152-W507A8040FD123508451E51931E0@phx.gbl>
In-Reply-To: <BLU152-W507A8040FD123508451E51931E0@phx.gbl>
Content-Type: multipart/alternative; boundary="------------090402070501080306060900"
Subject: Re: [rtcweb] Use of offer / answer semantics
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 08 Sep 2011 10:48:46 -0000

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