Re: [rtcweb] Question about JSEP createOffer

"Ravindran, Parthasarathi" <> Thu, 10 May 2012 08:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AC92B21F8607 for <>; Thu, 10 May 2012 01:11:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.503
X-Spam-Status: No, score=-6.503 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7bxf+BF6hwBy for <>; Thu, 10 May 2012 01:11:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3538321F85D9 for <>; Thu, 10 May 2012 01:11:04 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Thu, 10 May 2012 01:11:04 PDT
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 10 May 2012 04:11:14 -0400
Received: from ([fe80::8d0f:e4f9:a74f:3daf]) by ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Thu, 10 May 2012 13:40:58 +0530
From: "Ravindran, Parthasarathi" <>
To: Justin Uberti <>
Thread-Topic: [rtcweb] Question about JSEP createOffer
Date: Thu, 10 May 2012 08:10:58 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C16033CC2inbamail01sonus_"
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [rtcweb] Question about JSEP createOffer
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, 10 May 2012 08:11:09 -0000


The new media type/codec change by the answerer requires the complete set of codec from offerer. It is not appropriate to remember the previously offered codec & capabilities as it is subject to vary in the mid-session. For example, it is possible for the offerer to remove webcam in the middle of the audio session wherein answerer should not expect that video is supported by offerer as it was offered initially.

Please read inline for more comments.


From: Justin Uberti []
Sent: Thursday, May 10, 2012 8:32 AM
To: Ravindran, Parthasarathi
Cc: Roman Shpount;
Subject: Re: [rtcweb] Question about JSEP createOffer

On Wed, May 9, 2012 at 2:24 AM, Ravindran, Parthasarathi <<>> wrote:
I agree with Richard & Roman. “Full” re-OFFER MUST supported required for couple of mid session scenario like

1)      The session is established with audio and then video shall be added in the middle in case complete offer is provided in re-OFFER.
You don't need a complete offer here, just a "full" offer for the video m= section. This should already work today.
<partha>  IIUC for audio session, each time re-offer MUST contain “full” offer for video section </partha>

2)       It is possible to change the codec in the middle of the Session as Roman mentioned.
This also doesn't require a complete offer. The application would need to remember what codecs are available so that it could change the offered codec to something other than what it is currently using, but it would not need to resend all codecs.
<partha> Your proposal is limiting as the answerer has no choice to the select the preferred codec </partha>

I agree Roman's case of a B2BUA seems like it would need a full offer, although the idea of connecting an existing call to a new destination seems like an uncommon case; the application could simply start a new call (i.e. create a new PeerConnection), right?

If we decide we need to support this, the simplest way of handling this would be to simply extend the |hints| parameter in createOffer to have some sort of "complete" flag.
<partha> your API proposal looks good  as it is possible to re-use the existing or offer full based on the application needs. But the application developer  MUST aware of the implication as it calls for interop issue in case of federation scenario if the full offer is not sent across. </partha>

From:<> [<>] On Behalf Of Roman Shpount
Sent: Tuesday, May 08, 2012 9:03 PM
To: Justin Uberti
Subject: Re: [rtcweb] Question about JSEP createOffer

On Tue, May 8, 2012 at 10:46 AM, Justin Uberti <<>> wrote:

That is an interesting point. Could you give a short example of when such a "full" re-OFFER would be used? There are a few ways we could handle this case.

Actually I was the person who argued that "full" capabilities should be present in original SIP O/A, when new offer is generated in an existing session. The use case for this are B2BUA that connect an existing session to a new call or another existing session. Typically, B2BUA would ask one of the call parties for the offer (send an INVITE with no body in SIP), get the new offer, and send this offer to the newly placed call. In order for this to work, all the calling party capabilities should be listed in this new offer, in particular all the codecs and all the communications types (audio, video, text, etc), or call would not be successfully established.
Roman Shpount