On Wed, Mar 21, 2012 at 2:58 PM, Vinay V <[email protected]> wrote:
> Hi All,
>
> I wanted clarification regarding the following section in
> RFC 3261.
>
>
> 13.2.2.4 2xx Responses
>
>
>
> Multiple 2xx responses may arrive at the UAC for a single INVITE
>
> request due to a forking proxy. Each response is distinguished by
>
> the tag parameter in the To header field, and each represents a
>
> distinct dialog, with a distinct dialog identifier.
>
>
>
> If the dialog identifier in the 2xx response matches the dialog
>
> identifier of an existing dialog, the dialog MUST be transitioned to
>
> the "confirmed" state, and the route set for the dialog MUST be
>
> recomputed based on the 2xx response using the procedures of Section
>
> 12.2.1.2. Otherwise, a new dialog in the "confirmed" state MUST be
>
> constructed using the procedures of Section 12.1.2.
>
>
>
> Note that the only piece of state that is recomputed is the route
>
> set. Other pieces of state such as the highest sequence numbers
>
> (remote and local) sent within the dialog are not recomputed. The
>
> route set only is recomputed for backwards compatibility. RFC
>
> 2543 did not mandate mirroring of the Record-Route header field in
>
> a 1xx, only 2xx. However, we cannot update the entire state of
>
> the dialog, since mid-dialog requests may have been sent within
>
> the early dialog, modifying the sequence numbers, for example.
>
>
>
> Does this mean that the other pieces of state in the cloned dialog will
> remain same as the original dialog?
>
>
>
> UAC
>
> |----INV-Cseq1-------->
>
> |
>
> |<--180—Tag:T1---------
>
> |
>
> |---Prack—Tag:T1—Cseq2->
>
> |
>
> |ß--180-Tag:T2------------
>
> |
>
> |---Prack-Tag:T2-Cseq?-->
>
> |
>
>
>
> In the above call flow what should be the Cseq of Prack with Tag:T2.
>
> Should it be 2 or 3??
>
I would vote for Cseq:2
>
>
>
> Regards
>
> Vinay
>
>
>
>
> ****************************************************************************
> *************************************************
> This e-mail and attachments contain confidential information from HUAWEI,
> which is intended only for the person or entity whose address is listed
> above. Any use of the information contained herein in any way (including,
> but not limited to, total or partial disclosure, reproduction, or
> dissemination) by persons other than the intended recipient's) is
> prohibited. If you receive this e-mail in error, please notify the sender
> by
> phone or email immediately and delete it!
>
>
> ****************************************************************************
> *************************************************
>
>
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
--
Thanks,
Nataraju A.B.
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
