Subject: [Sip] NOTIFY after a SUBSCRIBE has expired

From: [email-masked]
Date: Mon, 10 Jun 2002 11:51:24 +0300

Sorry if I missed this in the draft.

UA1 sends a SUBSCRIBE with expires 3600

UA2 responds with 200 ok followed by NOTIFY.

Now, 3600 seconds later, the subscription has not been refreshed, so UA1 deletes all information cached about the subscription.

UA2 realises that the subscription has expired and sends a NOTIFY with subscription-state of terminated.

UA1 receives this NOTIFY, doesn't find a dialog and rejects the NOTIFY with 481.

This does not seem to be the correct behaviour. UA1 should not remove any dialog information until it receives a NOTIFY with subscription-state terminated. Is this the correct behaviour? Is this mentioned anywhere in events-05?

Regards,
Hisham

_______________________________________________
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: Adam Roach <[email-masked]>
Date: Mon, 10 Jun 2002 15:13:23 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> 
> Now, 3600 seconds later, the subscription has not been 
> refreshed, so UA1 deletes all information cached about the 
> subscription.
> 
> UA2 realises that the subscription has expired and sends a 
> NOTIFY with subscription-state of terminated.
> 
> This does not seem to be the correct behaviour. UA1 should 
> not remove any dialog information until it receives a NOTIFY 
> with subscription-state terminated. Is this the correct 
> behaviour? Is this mentioned anywhere in events-05?

What you've described is certainly what's detailed in the current
document. For the most part, it's necessary -- otherwise, how would
UA1 ever clear state if UA2 disappeared from the network?

I guess if we were really bothered by the potential for a 481 in
this case, we could ask the subscriber to hold on to dialog
state for several more seconds to sucessfully catch and process
the incoming NOTIFY. Personally, I don't see any gain from doing
so. I could be overlooking some reason that sending a 481 
instead of a 200 is a Bad Thing; let me know if you can think of one.

Note that this does not mean that sending NOTIFY messages upon
expiration is wasted; it helps prevent synchronization issues in which
the subscriber (for whatever reason) thinks the subscription lasts
longer than the notifier does.

/a