Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP
Harald Alvestrand <harald@alvestrand.no> Wed, 02 May 2012 13:35 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 C88A421F8599 for <rtcweb@ietfa.amsl.com>; Wed, 2 May 2012 06:35:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.508
X-Spam-Level:
X-Spam-Status: No, score=-110.508 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 in-Y93DRqxxr for <rtcweb@ietfa.amsl.com>; Wed, 2 May 2012 06:35:22 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 8D03921F8598 for <rtcweb@ietf.org>; Wed, 2 May 2012 06:35:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2F70539E112 for <rtcweb@ietf.org>; Wed, 2 May 2012 15:35:21 +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 YEccJ9zEFEAm for <rtcweb@ietf.org>; Wed, 2 May 2012 15:35:19 +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 ESMTPSA id 11AF139E089 for <rtcweb@ietf.org>; Wed, 2 May 2012 15:35:19 +0200 (CEST)
Message-ID: <4FA13816.6050003@alvestrand.no>
Date: Wed, 02 May 2012 15:35:18 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120412 Thunderbird/11.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.com> <CA+rAfUMfZBHxAjR0zmwhSxftQbPK0X3sNuxu4UV6bnMvnJ_9xA@mail.gmail.com> <CAOJ7v-3K=NK6zCLr-E-aSHDKVv2hMqnUhZKroX0YoBTo6-nQ+Q@mail.gmail.com> <6F428EFD2B8C2F49A2FB1317291A76C1136029362A@USNAVSXCHMBSA1.ndc.alcatel-lucent.com>
In-Reply-To: <6F428EFD2B8C2F49A2FB1317291A76C1136029362A@USNAVSXCHMBSA1.ndc.alcatel-lucent.com>
Content-Type: multipart/alternative; boundary="------------070408090808060708040105"
Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP
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: Wed, 02 May 2012 13:35:24 -0000
On 05/01/2012 03:57 PM, Ejzak, Richard P (Richard) wrote: > > Hi Justin, Partha, > > The call flow from Partha is a very reasonable one in the presence of > SIP forking. Let's assume that a first target responded with an SDP > answer in a 183 that must be treated as a PRANSWER since other targets > have not yet had a chance to respond. Then the first target sends an > UPDATE with offer2. > > As far as SIP is concerned, there is no such thing as a PRANSWER. The > first target already responded with an SDP ANSWER and wants to UPDATE > with a new offer. > In that case, PRANSWER seems like the wrong semantic.... if you want to support multiple answers, shouldn't you do the cloning before you start accepting answers? > > This is perfectly legitimate and common SIP usage. PRANSWER is a > local construct that should be usable by the application to support > more complex offer/answer cases like forking. > > You must respond to this offer by cloning the peer connection, closing > the clone with an ANSWER identical to the previous PRANSWER and then > applying offer2 to the clone (or just applying the offer2 directly > with the understanding that the previous transaction is closed). The > original peer connection must revert to the original OFFER state to > allow for other targets to respond. > > Alternately, the original peer connection can support the first target > and a new clone created if there is the potential for other forked > responses to the original offer. Either way can be made to work. > > This is a perfectly reasonable SIP use case that explains why we need > to be able to clone the peer connection. > Hmm.... could you please propose a semantic for "clone" that allows us to evaluate whether/how it can be implemented? Especially, I am worried about what the state of the peerconnection has to be before it is cloned, what the state of the peerconnection is after it is cloned, which peerconnection owns the various resources allocated (ports are the obvious part of it), and which peerconnection any streams (local or remote) attached to the peerconnection before the clone are attached to after the clone. In an earlier thread, I suggested a peerconnection factory that could generate an offer, but required you to manufacture a real peerconnection before applying an answer (any answer).... since I'm not that interested in supporting forking, I haven't pursued that further. Others might want to. I don't think any of this is impossible. I do think it requires rather precise definitions of what we want before we ask browser developers to do it. Harald
- [rtcweb] SDP_PRANSWER followed by SDP_OFFER scena… Ravindran, Parthasarathi
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Charles Eckel (eckelcu)
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Nataraju A.B
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Justin Uberti
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Ejzak, Richard P (Richard)
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Nataraju A.B
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Ravindran, Parthasarathi
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Ravindran, Parthasarathi
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Harald Alvestrand
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Roman Shpount
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Roman Shpount
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Harald Alvestrand
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Christer Holmberg
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Roman Shpount
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Christer Holmberg
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Harald Alvestrand
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Ejzak, Richard P (Richard)
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Ejzak, Richard P (Richard)
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Christer Holmberg
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Roman Shpount
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Christer Holmberg
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Roman Shpount
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Randell Jesup
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Roy, Radhika R CIV (US)
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Christer Holmberg
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Roman Shpount
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Randell Jesup
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Roman Shpount
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Christer Holmberg
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Roman Shpount
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Christer Holmberg
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Roman Shpount
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Christer Holmberg
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Justin Uberti
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Ravindran, Parthasarathi
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Cullen Jennings
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Roman Shpount
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Martin Thomson
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Cullen Jennings
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Cullen Jennings
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Roman Shpount
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Martin Thomson
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Cullen Jennings
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Justin Uberti
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Cullen Jennings
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Martin Thomson
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Iñaki Baz Castillo
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Roman Shpount
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Cullen Jennings
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Roman Shpount
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Cullen Jennings
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Ejzak, Richard P (Richard)
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Neil Stratford
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Randell Jesup
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Victor Semanic
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Ejzak, Richard P (Richard)
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Ravindran, Parthasarathi
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Tim Panton
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Roman Shpount
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Martin Thomson
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Roman Shpount
- Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER s… Randell Jesup