Re: [rtcweb] Minimal SDP negotiation mechanism

Harald Alvestrand <harald@alvestrand.no> Tue, 20 September 2011 12:57 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5982321F8C15 for <rtcweb@ietfa.amsl.com>; Tue, 20 Sep 2011 05:57:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.693
X-Spam-Level:
X-Spam-Status: No, score=-108.693 tagged_above=-999 required=5 tests=[AWL=1.906, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfPNDF5-VTK5 for <rtcweb@ietfa.amsl.com>; Tue, 20 Sep 2011 05:57:48 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 724E521F8BF4 for <rtcweb@ietf.org>; Tue, 20 Sep 2011 05:57:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D54E939E0BC; Tue, 20 Sep 2011 15:00:13 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpJXIIqGuiUa; Tue, 20 Sep 2011 15:00:13 +0200 (CEST)
Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 3D0A339E08A; Tue, 20 Sep 2011 15:00:13 +0200 (CEST)
Message-ID: <4E788E5C.9090306@alvestrand.no>
Date: Tue, 20 Sep 2011 15:00:12 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>
References: <4E777500.5030201@alvestrand.no> <69262135-CF5D-4E79-85CD-82DFDC4250C0@acmepacket.com> <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@ESESSCMS0356.eemea.ericsson.se> <4E788458.1090108@alvestrand.no> <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233F6F2A0@ESESSCMS0356.eemea.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Minimal SDP negotiation mechanism
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Sep 2011 12:57:49 -0000

On 09/20/11 14:42, Christer Holmberg wrote:
> Hi,
>
>>> 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.
I get a steady increase in my uneasiness here. A PeerConnection should 
(in my opinion) be about the connection between the browser and a single 
other endpoint, and the media transmitted between those two. Once we 
start requiring that the PeerConnection know the difference between 
"early" media and "late" media, it seems to me we're slipping down a 
slippery slope.

 From the standpoint of PeerConnections, it may make sense to treat a 
forked call as two PeerConnections rather than one - but in that case, 
we may have the need to be able to create a PeerConnection from another 
PeerConnection (duplicating state, and maybe sharing resources, which is 
ugly).

Forking is hard, it seems.
>>> 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?
The browser (PeerConnection implementation) or the Javascript?

That's a question I don't have an answer to.

Is there any information in there where the browser would act 
differently if it knew which offer the answer was associatied to?

I went over the offer/answer with Per Kjellander today; if we follow RFC 
3264's recommendation of only having one outstanding offer at a time, we 
did not find any need to identify offers ("there can be only one") - if 
we can get into the situation where we get an answer after we've sent 
out a subsequent offer and gotten that answered, we may get a need for it.
> Regards,
>
> Christer
>
>