I guess this is a little confusing, and the language may not be as
precise as it could be.
When you send the initial dialog establishing request you need to create
some state for the "pending" dialog. Its sort of a "half-dialog" since
you are waiting for a response to complete it.
When you receive a first response (2xx or even 1xx with a tag, contact,
etc.) you can establish a dialog for it. (Final if its 2xx, early-dialog
if its 1xx.) That fills in the missing pieces, including the route set,
remote contact, etc.)
You can then proceed to use that dialog. You could get a request on it
(e.g. UPDATE, NOTIFY (if this was a subscribe), etc.) The first such
received message will establish the first remote CSeq value. After that
you will check cseq values for subsequent received requests.)
You can also get a 1xx or 2xx with a different tag. That will result in
establishing a separate dialog. Its probably cleaner to think of it as
being derived from that pending half-dialog. It is unrelated to anything
that has happened on the other dialog you established. Depending on how
you want to optimize your implementation, you may not have completely
separate structures for this. If you mutate your pending dialog into the
first early/full dialog, then you will have to "clone" it to create
another dialog. If so, there is some stuff you might have to roll back.
Specifically, any remote CSeq value you have as a result of requests
received on the other dialog will need to be removed, so that the other
UA on the new dialog can choose its own CSeq.
You chose the initial local CSeq when you sent the dialog establishing
request. It will be the same when received at both forked destinations.
They will each expect the *next* message from you to have the next value
after that. If you have sent subsequent messages on the first dialog,
bumping your local CSeq, the UA on the other dialog won't have received
them. So, if you clone the first dialog to create the 2nd you might have
a wrong local cseq value.
Thanks,
Paul
On 3/21/12 5:28 AM, Vinay V 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??
>
>
>
> 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
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
