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

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Mon, 30 Apr 2012 07:01:38 +0000

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.

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 30 Apr 2012 09:22:42 -0700

Hi Partha,

I believe such a flow illegal, per RFC 3311:

      o  If the UPDATE is being sent before the completion of the INVITE
         transaction, and the initial INVITE contained an offer, the
         UPDATE cannot be sent with an offer unless the callee has
         generated an answer in a reliable provisional response, has
         received a PRACK for that reliable provisional response, has
         not received any requests (PRACK or UPDATE) with offers that it
         has not answered, and has not sent any UPDATE requests
         containing offers that have not been answered.

Cheers,
Charles

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ravindran, Parthasarathi
> Sent: Monday, April 30, 2012 12:02 AM
> To: Justin Uberti; Cullen Jennings
> Cc: [email-masked]
> Subject: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP
> 
> 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:
> 
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Nataraju A.B" <[email-masked]>
Date: Mon, 30 Apr 2012 23:25:13 +0530

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 <
[email-masked]> wrote:

> Justin/Cullen,
>
> Could you please explain in case for an SDP_OFFER(1), the remote entity

-- 
Thanks,
Nataraju A.B.

---

From: Justin Uberti <[email-masked]>
Date: Mon, 30 Apr 2012 19:50:56 -0700

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?