Subject: RE: [Sip] Out of sequence datagrams

From: "Fred O'Leary" <[email-masked]>
Date: Tue, 20 May 2003 14:16:15 -0700

This is what suspected. Yes the NOTIFY is a result of the implicit
SUBSCRIPTION caused by the REFER. So from an implementation perspective,
what is/should be the CSEQ relationship between NOTIFY CSEQ and the INVITE
dialog? (If there is none, the UAS would need to differentiate NOTIFY CSEQ's
from the INVITE/BYE even though the call identifers are the same.)

-----Original Message-----
From: Brett Tate [mailto:[email-masked]]
Sent: Tuesday, May 20, 2003 12:12 PM
To: [email-masked]
Subject: RE: [Sip] Out of sequence datagrams

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

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.

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

> This is what suspected. Yes the NOTIFY is 
> a result of the implicit SUBSCRIPTION caused 
> by the REFER. So from an implementation 
> perspective, what is/should be the CSEQ relationship 
> between NOTIFY CSEQ and the INVITE dialog? 

They subscription and call share the same 
dialog.  Thus the cseq must continue to 
increment upon each sent request.

Your prior example of a NOTIFY with cseq
value 2 being received after a BYE with
cseq value 3 could produce several results.

If the UAS does not care about refer related
notifies after processing a BYE, it could
return a 481 to avoid a resend or future
notifies.

It the notify contained a subscription-state 
of terminated, the UAS could return a 200,
481, or 500.  If the 500 is returned, the
UAC might not actually bump the cseq and
resend the request; thus it might lead to
a delay in subscription cleanup on the referrer.

If the UAS does still care about the notifies
and subscription-state is not terminated, 
it should return a 500 response to inform 
the UAC that it was received out of order.  
Since the 500 isn't only used for incorrectly 
order cseq, adding a retry-after header with
a small value communicates that the UAS would 
like the UAC to try again if needed.