Re: [rtcweb] Minimal SDP negotiation mechanism

Christer Holmberg <> Tue, 20 September 2011 12:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2C17C21F8BAE for <>; Tue, 20 Sep 2011 05:40:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.535
X-Spam-Status: No, score=-6.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hkSTviS+KRpA for <>; Tue, 20 Sep 2011 05:40:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 62E9A21F8B9F for <>; Tue, 20 Sep 2011 05:40:33 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c47ae000000b17-f4-4e788a5270a9
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 28.1F.02839.25A887E4; Tue, 20 Sep 2011 14:42:58 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Tue, 20 Sep 2011 14:42:57 +0200
From: Christer Holmberg <>
To: Harald Alvestrand <>
Date: Tue, 20 Sep 2011 14:42:55 +0200
Thread-Topic: [rtcweb] Minimal SDP negotiation mechanism
Thread-Index: Acx3j0RVhrNg2QYcS/OzKt07zeJ9CAAArFeA
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "" <>
Subject: Re: [rtcweb] Minimal SDP negotiation mechanism
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: Tue, 20 Sep 2011 12:40:34 -0000


>> In SIP it's possible to get two or more different answers back for 
>> one offer, due to forking.  I'm not sure you want/need to 
>> handle that 
>> case, but it can and does in-practice happen in SIP.
>> Whether we want the browser to support forking is one 
>> thing, and I guess it much depends on whether we want to be 
>> able to do things on the media plane during the early phase 
>> of a session establishment.
> I think we need to do all the transforms we need to do. It 
> would be great if there was a consistent set of things we are 
> required to be able to do.
> If a JS app wants to support forking, I think it's reasonable 
> to leave it to the JS which answer it wants to pass on to the 
> PeerConnection object. When we get multiple ANSWERs like 
> this, is there any information from the first ANSWER that 
> needs to be preserved after the second ANSWER has arrived? (I 
> really hope that the answer is a really clear NO...)

The answers as such are independent from each other, so from that perspective the answer is NO :)

The question is whether we want to allow actions to to take place on the media plane before we know which early dialog will be part of the established call.

For example, you won't be able to perform resource reservation procedures for multiple early dialog if the browser only deals with one early dialog at any given time.

>> But, at least the API needs to allow a JS SIP app to 
>> "replace" a previously received SDP with a new one (if the 
>> SIP app, in the forking case, for example chooses to always 
>> use the latest received SDP answer).
> We might get SIP compatibility if we decide that SDP ANSWER 
> can be received at any time, changes the state of the 
> connection, and never generates a response. SDP ANSWER is now 
> an one-way offer/answer.

Doesn't the browser still need to know with which offer the answer is associated?