RE: [Sip] Out of sequence datagrams

["Brett Tate" <brett@broadsoft.com>]

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

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip