Subject: [Sip] Undefined UAS behaviour in RFC3261 12.2.2

From: "Molodyko, Rostislav" <[email-masked]>
Date: Wed, 9 Aug 2006 18:01:27 -0400

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

---

From: [email-masked]
Date: Wed, 9 Aug 2006 18:45:10 -0400

From: "Molodyko, Rostislav" <[email-masked]>

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

The only way this could happen is if the UAC is grossly malfunctioning
and sending more than one request with the same Call-Id/CSeq.  (Notice
that the other cases can happen normally, due to network delays, etc.)

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.

Dale

---

From: Manjunath Warad <[email-masked]>
Date: Thu, 10 Aug 2006 10:44:23 +0800

Hi,
    I think UAS need to treat it as normal request though CSeq is same.
I would like to quote a scenario where this could be possible! Since
proxy can retry request on failure response, if UAS rejected a request
with failure response and immediate upstream proxy retries to the same
UAS and since proxy cannot update CSeq, this scenario is quite possible
in the network. 
    Retrying to the same UAS mean to say, the same UA stack might be
shared among different users and CSeq check would matter for UA stack
and not the user of UA. 
 
Could be something like this:
 
UAC                P1                P2                P3
UAS(stack)            User1                User2
INV -------------->
                        ---------------->
                                            ------------->
 
---------------> ------------------->
 
<---------------- <---------------4xx
 
INV(retry)------> ----------------------------------------> 
 
Now CSeq at UAS is same.
 
<---------------- <---------------------------------------200
                                            <---------------
                        <---------------
200<--------------
 
Rgds,
Manju

-----Original Message-----
From: Molodyko, Rostislav [mailto:[email-masked]] 
Sent: Thursday, August 10, 2006 6:01 AM
To: [email-masked]
Subject: [Sip] Undefined UAS behaviour in RFC3261 12.2.2

Hi All,

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

At UAC side:

CSeq: 10 INVITE

...

SIP/2.0 180 Ringing

CSeq: 10 INVITE

CSeq: 11 PRACK

...

SIP/2.0 200 OK

CSeq: 11 PRACK

CSeq: 11 UPDATE

...

SIP/2.0 200 OK                          // ???

CSeq: 11 UPDATE

Regards,

Ros Molodyko

SIP Development

Sonus Networks

250 Apollo Drive

Chelmsford, MA 01824

---

From: [email-masked]
Date: Thu, 10 Aug 2006 10:09:04 -0400

From: Manjunath Warad <[email-masked]>

   Since proxy can retry request on failure response, if UAS rejected
   a request with failure response and immediate upstream proxy
   retries to the same UAS and since proxy cannot update CSeq, this
   scenario is quite possible in the network.

No, the proxy cannot "retry" a request, only a UAC can.  But if the
proxy's sending of the request to one UAS got a failure response, it
can send the request to another address (which might go to the same
UAS).  But that request is a different branch, as evidenced by the
fact that the "branch" parameter in the topmost Via header is
different.  Because of the different branch parameter, the UAS will
process the request afresh.

The request on a different branch will, of course, have the same CSeq
and method.

Dale