Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP

"Ejzak, Richard P (Richard)" <richard.ejzak@alcatel-lucent.com> Tue, 01 May 2012 13:57 UTC

Return-Path: <richard.ejzak@alcatel-lucent.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 9619B21E82C5 for <rtcweb@ietfa.amsl.com>; Tue, 1 May 2012 06:57:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 nnacU6B7fEhg for <rtcweb@ietfa.amsl.com>; Tue, 1 May 2012 06:57:46 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id D59D621E82BB for <rtcweb@ietf.org>; Tue, 1 May 2012 06:57:45 -0700 (PDT)
Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q41DvhO7025831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 1 May 2012 08:57:43 -0500 (CDT)
Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q41DvghR023631 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 1 May 2012 08:57:43 -0500
Received: from USNAVSXCHMBSA1.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Tue, 1 May 2012 08:57:42 -0500
From: "Ejzak, Richard P (Richard)" <richard.ejzak@alcatel-lucent.com>
To: Justin Uberti <juberti@google.com>, "Nataraju A.B" <nataraju.sip@gmail.com>
Date: Tue, 1 May 2012 08:57:40 -0500
Thread-Topic: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP
Thread-Index: Ac0nRUzcKWbc33ZVRO+KqwMZL0Xe+QAWQKOQ
Message-ID: <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>
In-Reply-To: <CAOJ7v-3K=NK6zCLr-E-aSHDKVv2hMqnUhZKroX0YoBTo6-nQ+Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_6F428EFD2B8C2F49A2FB1317291A76C1136029362AUSNAVSXCHMBSA_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12
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 13:57:48 -0000

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<mailto: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<mailto: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<mailto:rtcweb@ietf.org>
https://www.ietf.org/mailman/listinfo/rtcweb



--
Thanks,
Nataraju A.B.