Subject: [Sip] Out of sequence datagrams

From: "Fred O'Leary" <[email-masked]>
Date: Tue, 20 May 2003 10:40:44 -0700

Hi,
Please refer to the snippet from "12.2.2 UAS Behavior" of RFC3261

....
 If the remote sequence number is empty, it MUST be set to the value
   of the sequence number in the CSeq header field value in the request.
   If the remote sequence number was not empty, but the sequence number
   of the request is lower than the remote sequence number, the request
   is out of order 
....

Because the ordering of UDP datagrams isn't guarenteed, it is possible for
the above to occur. For example NOTIFY with CSEQ 2 is received after the BYE
with CSeq 3. Since, from the application perpective, the dialog has ended,
there appears no way the NOTIFY can be processed by the UAS. Any ideas much
appreciated.

Fred O'Leary
MTS Sylantro Systems Corp.
(408)626-3040

_______________________________________________
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: "Brett Tate" <[email-masked]>
Date: Tue, 20 May 2003 15:11:45 -0400

>  If the remote sequence number is empty, 
>  it MUST be set to the value of the sequence 
>  number in the CSeq header field value in 
>  the request.
>  If the remote sequence number was not empty, 
>  but the sequence number of the request is lower 
>  than the remote sequence number, the request
>  is out of order 
> ....
> 
> Because the ordering of UDP datagrams isn't 
> guarenteed, it is possible for the above to occur. 
> For example NOTIFY with CSEQ 2 is received after 
> the BYE with CSeq 3. Since, from the application 
> perpective, the dialog has ended, there appears no 
> way the NOTIFY can be processed by the UAS. 

If order is important, requests should
be queued until the prior request has been 
acknowledged.  However concerning your BYE
and NOTIFY example, the BYE only terminates
the call associated with the dialog.  The
BYE does not necessarily terminate subscriptions 
associated with the dialog.  Thus if the NOTIFY
relates to the implicit subscription caused
by a REFER, the notifies can continue to be
sent after the BYE has released the call
associated with the dialog.