On 3/26/12 2:45 PM, Ravi Kumar wrote:
> 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?
You stated *your opinion* that the sender should use CSeq 3.
That doesn't mean that everyone will agree with your opinion.
I posted a reply a few days ago reaching the opposite conclusion.
Why should a proxy care? If for some reason it does care it should
probably make the most generous interpretation, which is that the next
CSeq in the dialog should be the last one seen on the dialog (1) plus one.
Thanks,
Paul
> 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-------->
>>
>> |
>>
>> |<--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
>> 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
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
