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

"Parthasarathi R" <> Mon, 04 November 2013 17:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EE2A021E825E for <>; Mon, 4 Nov 2013 09:45:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.991
X-Spam-Status: No, score=-1.991 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UMPVL1kt3yNx for <>; Mon, 4 Nov 2013 09:45:09 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 9C13321E824B for <>; Mon, 4 Nov 2013 09:44:39 -0800 (PST)
Received: from userPC (unknown []) (Authenticated sender: by (Postfix) with ESMTPA id D5FBD19082AF; Mon, 4 Nov 2013 17:44:31 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120823; t=1383587076; bh=Nc4Pid9xGDcrw4aJ5l0ZCnzMb5/2dymFoKObNuOyiNU=; h=From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type; b=nESrTmyS32um1p0d0F8Zyf53PDuZs7cZMSFMOHLxCz8vub8K/bTt8/bf3iK88yMkI PGU9urf9MRpCW5yPeTcQKCqBzdBKN3d8zwo50ljCcNR6E+vvAGBcvA4EWMwgkzppMP klDBeQ7lOJLgrNtuPGxwiAXl+EFdsSY/w2fa3bkQ=
From: "Parthasarathi R" <>
To: "'Justin Uberti'" <>, "'Paul Kyzivat'" <>
References: <> <>
In-Reply-To: <>
Date: Mon, 4 Nov 2013 23:13:34 +0530
Message-ID: <00b901ced985$85594160$900bc420$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BA_01CED9B3.9F117D60"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac7ZKu97RkimDg8HS1yf9W6X1FrNbAAV/t7w
Content-Language: en-us
X-CTCH-RefID: str=0001.0A020208.5277DD04.0149, ss=1, re=0.100, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.100
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CTCH-SenderID-TotalMessages: 1
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalRecipients: 0
X-CTCH-SenderID-TotalVirus: 0
X-CTCH-SenderID-BlueWhiteFlag: 0
X-Scanned-By: MIMEDefang 2.72 on
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: Mon, 04 Nov 2013 17:45:15 -0000



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