Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers

"Hutton, Andrew" <> Wed, 06 November 2013 19:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C431021E8087 for <>; Wed, 6 Nov 2013 11:10:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.457
X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 90nhI79g9XQD for <>; Wed, 6 Nov 2013 11:10:24 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E491421F9CC2 for <>; Wed, 6 Nov 2013 11:10:14 -0800 (PST)
Received: from (unknown []) by (Server) with ESMTP id 9C82B23F0677; Wed, 6 Nov 2013 20:10:07 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Wed, 6 Nov 2013 20:10:07 +0100
From: "Hutton, Andrew" <>
To: Parthasarathi R <>, 'Justin Uberti' <>, 'Paul Kyzivat' <>
Thread-Topic: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers
Thread-Index: Ac7ZKu97RkimDg8HS1yf9W6X1FrNbAAV/t7wAGdqfCA=
Date: Wed, 6 Nov 2013 19:10:06 +0000
Message-ID: <>
References: <> <> <00b901ced985$85594160$900bc420$>
In-Reply-To: <00b901ced985$85594160$900bc420$>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF17C321EEMCHP04MSXglobal_"
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers
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: Wed, 06 Nov 2013 19:10:29 -0000

I would just like to say that I agree with the points raised by Paul and Partha here that it has to be possible for the application to create an offer with a complete set of current capabilities.  The reason for this is of course interoperability with existing SIP implementations which need this.  Having to create a new peer connection and force use of INVITE with replaces doesn’t work well with existing implementations and would be a high cost to pay for what is hopefully a simple API constraint to create a full offer.


From: [] On Behalf Of Parthasarathi R
Sent: 04 November 2013 09:44
To: 'Justin Uberti'; 'Paul Kyzivat'
Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers


As the signaling is not defined in WebRTC, it is not possible to assume that the remote side capabilities will not change between browser to browser scenario as well.  RTCWeb Server shall transfer the session using RE-INVITE equivalent functionality.

Re-INVITE without offer is a power tool in SIP for getting the capabilities before selecting the final codec. It shall be used to initiate the offer from the remote side. One of the INIVTE/Re-INVITE without offer usecase in WebRTC shall be used to get ICE-TCP candidate from the browser wherein the incoming TCP connection is forbidden by the firewall.


From:<> [] On Behalf Of Justin Uberti
Sent: Monday, November 04, 2013 12:26 PM
To: Paul Kyzivat
Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers

On Fri, Nov 1, 2013 at 2:45 PM, Paul Kyzivat <<>> wrote:
Section 5.2.2 (Subsequent Offers) says:

   o  The m= line and corresponding "a=rtpmap" and "a=fmtp" lines MUST
      only include codecs present in the remote description.

   o  The RTP header extensions MUST only include those that are present
      in the remote description.

   o  The RTCP feedback extensions MUST only include those that are
      present in the remote description.

   o  The "a=rtcp-mux" line MUST only be added if present in the remote

   o  The "a=rtcp-rsize" line MUST only be added if present in the
      remote description.

Including only codecs that were present in the prior answer is a bad idea. It doesn't play well with SIP. There is no harm in continuing to include all the codecs you support. And it keeps options open for changing codecs later.

The same is true for most other things that are being restricted based on what was in the last answer. (But I won't say that with certainty without checking the semantics of each one.)

For further info, see RFC 6337, especially section 5.1.

According to section 5.2.5, it seems that this is only the cases for offers triggered by offerless reINVITEs. I don't think we want to be re-allocating and negotiating codecs every time we want to make a change to the session descriptions in use.

Generally I think we should consider that the capabilities of the remote side will not change unexpectedly during the call, and so full renegotiation is not needed with each reINVITE. If full renegotiation is needed, use an INVITE-with-replaces, as Cullen has suggested. This avoids complicated cases like having to unBUNDLE in mid-call, or re-reserve codecs that are unlikely to be used.

rtcweb mailing list<>