Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP
"Nataraju A.B" <nataraju.sip@gmail.com> Tue, 01 May 2012 16:12 UTC
Return-Path: <nataraju.sip@gmail.com>
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 AA46F21E8271 for <rtcweb@ietfa.amsl.com>; Tue, 1 May 2012 09:12:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.339
X-Spam-Level:
X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 TavW1DworgcK for <rtcweb@ietfa.amsl.com>; Tue, 1 May 2012 09:12:30 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0428721E8134 for <rtcweb@ietf.org>; Tue, 1 May 2012 09:12:29 -0700 (PDT)
Received: by lbbgo11 with SMTP id go11so222181lbb.31 for <rtcweb@ietf.org>; Tue, 01 May 2012 09:12:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DzGPA8p+hYETaxUJJCL20Qr1JrSAJBJJVXavAsFvYNo=; b=ksElVXGkmquue4O8nc7rlwiZnlP+ePUr7cpqwRSyFPomkdDu/pwcyBTYVOkwAHoDu7 HbAMTJhwGsT8DXfmZ+fEMPPcJiFOhG9QyloKsE1+AibwVW5xrh820zhCHKd0nXHz5Ug1 0uazmJvYTTiEJphadLajH4chH0OlB+Wc0zxwHqdarQ9OPJxtz6jTMAI4gPHyE9NUvHrk ar9E/ZYZY6K/UAtR7Y5V0V1U+0lV2gc1rCG+fndydSlf+oX+3LRfU3awcyNNOog8tFV9 9Ri7F+yIrRxxk8tCGPuR/mfVzTQS/R46t+Q8Wb3kd1SpDZ65wwMJIH4iWAomeSR4yL1W 9uMw==
MIME-Version: 1.0
Received: by 10.152.111.41 with SMTP id if9mr23544740lab.19.1335888748739; Tue, 01 May 2012 09:12:28 -0700 (PDT)
Received: by 10.112.86.129 with HTTP; Tue, 1 May 2012 09:12:28 -0700 (PDT)
In-Reply-To: <6F428EFD2B8C2F49A2FB1317291A76C1136029362A@USNAVSXCHMBSA1.ndc.alcatel-lucent.com>
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>
Date: Tue, 01 May 2012 21:42:28 +0530
Message-ID: <CA+rAfUMC48ZeAdpur_B+6nRzEyNYjRFe66U-h62eAoGZVDd-pg@mail.gmail.com>
From: "Nataraju A.B" <nataraju.sip@gmail.com>
To: "Ejzak, Richard P (Richard)" <richard.ejzak@alcatel-lucent.com>
Content-Type: multipart/alternative; boundary="f46d0407152953fddc04befbd608"
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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: Tue, 01 May 2012 16:12:31 -0000
The original scenario mentioned by Partha is quite logical and acceptable, since there is only one O/A open all the times. If not handled properly, this additional UPDATE (with OFFER2) during the lifetime of INVITE transaction lead to ambiguities. Hence rfc6337, don't support this as a valid O/A. On Tue, May 1, 2012 at 7:27 PM, Ejzak, Richard P (Richard) < richard.ejzak@alcatel-lucent.com> 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. 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.**** > > ** ** > > Richard**** > > ** ** > ------------------------------ > > *From:* rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On > Behalf Of *Justin Uberti > *Sent:* Monday, April 30, 2012 9:51 PM > *To:* Nataraju A.B > *Cc:* rtcweb@ietf.org > *Subject:* Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in > JSEP**** > > ** ** > > Yes, I was under the impression that SIP enforced this requirement, > although I am probably not aware of all the corner cases. Is there a > real-world scenario where this flow is required?**** > > On Mon, Apr 30, 2012 at 10:55 AM, Nataraju A.B <nataraju.sip@gmail.com> > wrote:**** > > If the scenario considered is without reliable provisional responses. Then > the first ANSWER must be in 200-INV and no more O/A allowed during > INVITE(initial) transaction.**** > > ** ** > > Basic requirement for reliable and unambiguous O/A is -* At any point in > time there could be only one O/A open. ***** > > ** ** > > Also only one O/A suggested during INVITE(initial) transaction.**** > > ** ** > > For reference, rfc6337, list outs different O/A models...**** > > ** ** > > <rfc6337>**** > > ** ** > > ** ** > > Offer Answer RFC Ini Est Early**** > > -------------------------------------------------------------------**** > > 1. INVITE Req. 2xx INVITE Resp. RFC 3261 Y Y N**** > > 2. 2xx INVITE Resp. ACK Req. RFC 3261 Y Y N**** > > 3. INVITE Req. 1xx-rel INVITE Resp. RFC 3262 Y Y N**** > > 4. 1xx-rel INVITE Resp. PRACK Req. RFC 3262 Y Y N**** > > 5. PRACK Req. 200 PRACK Resp. RFC 3262 N Y Y**** > > 6. UPDATE Req. 2xx UPDATE Resp. RFC 3311 N Y Y**** > > ** ** > > Table 1: Summary of SIP Usage of the Offer/Answer Model **** > > </rfc6337>**** > > ** ** > > Thanks,**** > > Nataraju A B**** > > ** ** > > On Mon, Apr 30, 2012 at 12:31 PM, Ravindran, Parthasarathi < > pravindran@sonusnet.com> wrote:**** > > Justin/Cullen, > > Could you please explain in case for an SDP_OFFER(1), the remote entity > replies with SDP_PRANSWER followed by new SDP_OFFER (2) what is the > expected behavior. The exact callflow is as follows: > > > Browser1-------------------------Browser2(SIP-JSEP gateway) > | SDP_OFFER(1) | INV with offer1 > |------------------------------->|---> > | SDP_PRANSWER(1) | 183 with answer1 > |<-------------------------------|<--- > | SDP_OFFER(2) | UPDATE with offer2 > |<-------------------------------|<--- > | SDP_ANSWER(2?) | > |--------------------->? > > The reason for this O/A callflow is due to UPDATE method (RFC 3311) > mapping in Browser 2 (SIP-JSEP gateway). > > Thanks > Partha > > PS: For simplicity, PRACK message exchange is not chosen in SIP side. > > > > > **** > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb**** > > > > **** > > ** ** > > -- > Thanks,**** > > Nataraju A.B.**** > > ** ** > > ** ** > -- Thanks, Nataraju A.B.
- [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