When an application receives the SipSubscriptionReceived event, it has the opportunity to accept or decline an event subscription from another application or device. If the application indicates that the subscription request can not be granted, then the application has no need to ever call this API procedure. If however the application decides to grant the event subscription, then the application takes ownership of the notification handle that is specified during the SipSubscriptionReceived event processing. If the application takes ownership of a notification handle, it should call this API procedure before it fully terminates for each notification handle it owns. It should also call this API procedure when the requesting application or device indicates that it no longer wants to subscribe to the specific subscription event.

If an application recreates VoipMediaEngine..::.SUBSCRIBE_REQUEST data by calling the RecreateSubscribeRequest(VoipMediaEngine, VoipMediaEngine..::.SUBSCRIBE_REQUEST) API procedure, it must also call this procedure to free memory resources associated with the recreated SUBSCRIBE_REQUEST data.

An application can call this API procedure to obtain the buffer size in bytes required to persist a notification handle. This buffer can then be allocate by the application and passed to the PersistNotifyHandle API procedure.

Call this API procedure to determine if a native handle has been assigned to the object and if the object is valid.

Event notification handles are presented to an application at the time an event subscription is received. If an application has to terminate before all other devices have un-subscribed, this API procedure will allow the application to create a "persistent data copy" of the notify handle. The application can then save this persistent data somewhere and then terminate. An application can then at a later time instantiate the persisted event notify handle and service event notifications without forcing the subscribing devices to re-subscribe to the event. All server based applications that accept event subscriptions should persist their subscriptions in between application restarts.

If an application persists event subscriptions between application termination and startup, this API procedure can be called to reinstantiate the NOTIFY_HANDLE for an event subscription.

If an application creates a persistent notification information, it can recreate the data associated with the original subscription request by calling this API procedure.

The SendEventNotification function can be called by application software to send an event notification to another telephony application or device. Events should only be sent to applications or devices that have previously made a request to receive such events. When another telephony application or device makes an attempt to subscribe to an event your application supports, your application will receive the SipSubscriptionReceived event. When your application processes this event, it must maintain the NOTIFY_HANDLE that is specified in the subscription event data. Your application can then use this handle to send notifications to the requesting application or device.