What about proxy, I do not find any text in RFC 3261 for proxy behavior. So call stateful proxy can expect CSeq as 3. How to deal with call stateful proxy?
Regards, Ravi Kumar ---------------------------------------------------------------------------- --------------------------------------------------------- This e-mail and its 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! -----Original Message----- From: Ravi Kumar [mailto:raviku...@huawei.com] Sent: Monday, March 26, 2012 5:13 PM To: 'harbhanu.sa...@gmail.com'; 'vin...@huawei.com'; 'sip-implementors@lists.cs.columbia.edu' Subject: RE: [Sip-implementors] Clarification regarding the Cseq to be used in mid dialog req on cloned leg. Hi, But in my opinion it should send request with CSeq 3. Because if some node in network use CSeq of dialog on which forked response is received then above implementation will be more flexible. UAS will not have any impact because as per RFC 3261 this is not error condition. RFC 3261 12.2.2 UAS Behavior If the remote sequence number was not empty, and the sequence number of the request is greater than the remote sequence number, the request is in order. It is possible for the CSeq sequence number to be higher than the remote sequence number by more than one. This is not an error condition Please share your opinion on this. Regards, Ravi Kumar ---------------------------------------------------------------------------- --------------------------------------------------------- This e-mail and its 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! -----Original Message----- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of harbhanu sahai Sent: Wednesday, March 21, 2012 6:29 PM To: Vinay V Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Clarification regarding the Cseq to be used in mid dialog req on cloned leg. As here 18x will create an 'early dialog', which would be clone of previous one. So, the CSeq here should be '2'. Requests within a dialog MUST contain strictly monotonically increasing and contiguous CSeq sequence numbers (increasing-by-one) in each direction (excepting ACK and CANCEL of course, whose numbers equal the requests being acknowledged or cancelled). Therefore, if the local sequence number is not empty, the value of the local sequence number MUST be incremented by one, and this value MUST be placed into the CSeq header field. Also, the below text for re-computation mentions that CSeq should not be recomputed on receiving 2xx, since it might have changed owing to mid-dialog requests. Hope it helps. Thanks, Harbhanu On Wed, Mar 21, 2012 at 2:58 PM, Vinay V <vin...@huawei.com> 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--------> > > | > > |<--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 > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
