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-------->
|
|<--180Tag:T1---------
|
|---PrackTag:T1Cseq2->
|
|ß--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??
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
