Re: [rtcweb] Minimal SDP negotiation mechanism

Harald Alvestrand <harald@alvestrand.no> Tue, 20 September 2011 12:15 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 44EF521F8C45 for <rtcweb@ietfa.amsl.com>; Tue, 20 Sep 2011 05:15:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.632
X-Spam-Level:
X-Spam-Status: No, score=-108.632 tagged_above=-999 required=5 tests=[AWL=1.967, 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 riUAcuhxYEbA for <rtcweb@ietfa.amsl.com>; Tue, 20 Sep 2011 05:15:03 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 99A0821F8C3D for <rtcweb@ietf.org>; Tue, 20 Sep 2011 05:15:03 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EE43839E0BC; Tue, 20 Sep 2011 14:17:28 +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 nDJGvDkrdWkX; Tue, 20 Sep 2011 14:17:28 +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 53A3A39E08A; Tue, 20 Sep 2011 14:17:28 +0200 (CEST)
Message-ID: <4E788458.1090108@alvestrand.no>
Date: Tue, 20 Sep 2011 14:17:28 +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>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852233F6F222@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:15:04 -0000

On 09/20/11 14:08, 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...)
> 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.