In my opinion this is what should happen as per RFC-3265. Whenever a new subscription request is received by the UAS (notifier) if it accepts it. It will send a 2XX response and then should build and send a NOTIFY with initial state for the event for which subscription was created. It is perfectly possible that all the NOTIFYs may get lost in the network.
So if the UAC ( Subscriber) has received a 200OK response to the SUBSCRIBE and has not received a NOTIFY for the same dialog created using the SUBSCRIBE request. The only possibility based on the below recommendations can be that all the NOTIFYs were lost in the network or else the UAS (notifier) is not compliant with RFC-3265 recommendations ( notifier MUST send a NOTIFY message ). If it was the case of lost NOTIFYs, then the UAS (notifier) as per section recommendation of section 3.2.2 will remove the subscription. So it be safer on the UAC ( Subscriber) side to send another subscription request, because if it was the case of lost NOTIFYs it will again re-attempt creating a new subscription on the UAS ( notifier) side ( it would have deleted the dialog created by the previous SUBSCRIBE request due to timeout of NOTIFYs on it's end), if it was not the case of lost NOTIFYs, then UAS ( notifier) will treat this SUBSCRIBE request as a refresh request and will do not harm on both end (UAS or UAC ) Below are the relevant sections of RFC-3265 for your own reference. Regards, Indresh Section 3.1.4.4 The subscriber can expect to receive which has processed a successful subscription refresh. Until the first NOTIFY message should consider the state of the subscribed neutral state. Documents which define this "neutral state" in such a way that application (see section 4.4.7.). Section 3.1.6.2 Upon successfully accepting or refreshing a subscription, notifiers MUST send a NOTIFY message immediately to communicate the current resource state to the subscriber. This NOTIFY message is sent on the same dialog as created by the SUBSCRIBE response. If the resource has no meaningful state at the time that the SUBSCRIBE message is processed, this NOTIFY message MAY contain an empty or neutral body. See section 3.2.2. for further details on NOTIFY message generation. Section 3.2.2 If the NOTIFY request fails (as defined above) due to a timeout condition, and the subscription was installed using a soft-state mechanism (such as SUBSCRIBE), the notifier SHOULD remove the subscription. -----Original Message----- From: [EMAIL PROTECTED] [ <mailto:[EMAIL PROTECTED]> mailto:[EMAIL PROTECTED] Behalf Of Satya Sent: Thursday, March 31, 2005 4:32 AM To: [email protected] Subject: [Sip-implementors] NOTIFY Handling Hi, When a UAC sends SUBSCRIBE and receives 200 OK response for it, but doesn't receive a NOTIFY message, what is the UAC's action.It should retry or based on what policy it should delete the subscription. Thanks, Satya _______________________________________________ Sip-implementors mailing list [email protected] <http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
