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, 1 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.