Subject: Re: [Sip] Undefined UAS behaviour in RFC3261 12.2.2

From: "James M. Polk" <[email-masked]>
Date: Wed, 09 Aug 2006 23:16:38 -0500

Ros

CSEq numbers are independent between Methods.  In other words, the PRACK 
and UPDATE can be using the same CSeq numbers, which have to always 
increase by 1 within a new transaction of that Method regardless who the 
UAS is (retransmissions have the same CSeq number as the original request).

Therefore you would not get an error unless a new request had the same Cseq 
number using the same Method *or* a new request or retransmission used a 
lower number than any previous transaction used within that same Method.

At 06:01 PM 8/9/2006 -0400, Molodyko, Rostislav wrote:
>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
>         boundary="----_=_NextPart_001_01C6BBFF.5CE91767"
>
>Hi All,
>
>         The section 12.2.2 UAS Behavior states that UAS should :
>
>-       reject the requests If the remote sequence number was not empty, 
>but the sequence number of the request is lower than the remote sequence 
>number
>
>-       consider the request in-order if the sequence number of the 
>request is greater than the remote sequence number
>Not clear what UAS behaviour should be if the sequence number is equal to 
>the remote sequence number, but the incoming request is a new request (not 
>a retransmission).
>
>         In the example below UAC sends UPDATE with the same Cseq like 
> PRACK. I guess UAS should reject that UPDATE with 500 or 4xx, while it is 
> not stated in RFC.
>
>At UAC side:
>
>============ TRANSMITTED: =========
>
>INVITE sip:[email-masked]:4000 SIP/2.0
>
>Call-ID: [email-masked]
>
>CSeq: 10 INVITE
>
>...
>
>============ RECEIVED: ==========
>
>SIP/2.0 180 Ringing
>
>Call-ID: [email-masked]
>
>CSeq: 10 INVITE
>
>============ TRANSMITTED: =========
>
>PRACK sip:[email-masked]:4000 SIP/2.0
>
>Call-ID: [email-masked]
>
>CSeq: 11 PRACK
>
>...
>
>============ RECEIVED: ==========
>
>SIP/2.0 200 OK
>
>Call-ID: [email-masked]
>
>CSeq: 11 PRACK
>
>============ TRANSMITTED: =========
>
>UPDATE sip:[email-masked]:4000 SIP/2.0
>
>Call-ID: [email-masked]
>
>CSeq: 11 UPDATE
>
>...
>
>============ RECEIVED: ==========
>
>SIP/2.0 200 OK                          // ???
>
>Call-ID: [email-masked]
>
>CSeq: 11 UPDATE
>
>         Is this case covered by any new RFC or Draft?
>
>Regards,
>
>Ros Molodyko
>
>SIP Development
>
>Sonus Networks
>
>250 Apollo Drive
>
>Chelmsford, MA 01824
>
>Direct phone: 978-614-8620
>
>
>
>_______________________________________________
>Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>This list is for NEW development of the core SIP Protocol
>Use [email-masked] for questions on current sip
>Use [email-masked] for new developments on the application of sip

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Attila Sipos" <[email-masked]>
Date: Thu, 10 Aug 2006 07:47:01 +0100

>> and UPDATE can be using the same CSeq numbers,

You need a new CSeq for each new request sent by a UA irrespective
of the method.

In RFC3261 it says:
   CSeq or Command Sequence contains an integer and a method name.  The
   CSeq number is incremented for each new request within a dialog and
   is a traditional sequence number.

Also from "12.2.1.1 Generating the Request"...

   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).

So this means that you have to use a new CSeq for each new request
whatever method that request has.  So you can't send a PRACK with a
CSeq of 2 (for example) and then send (from the same UA) an UPDATE
with a CSeq of 2. The UPDATE should have a CSeq of 3.

And with respect to what the UAS should do, I refer you to
Dale Worley's earlier mail:
>>If the UAS notices the problem, it can reject the request with 500.
>>But it is not required to detect the problem, it might just re-send
>>the response to the first request.

Regards,

Attila

Attila Sipos
http:/www.vegastream.com

>> -----Original Message-----
>> From: James M. Polk [mailto:[email-masked]]
>> Sent: 10 August 2006 05:17
>> To: Molodyko, Rostislav; [email-masked]
>> Subject: Re: [Sip] Undefined UAS behaviour in RFC3261 12.2.2
>> 
>> 
>> Ros
>>