Dialogic Global Call IP Benutzerhandbuch

The SIP SUBSCRIBE and NOTIFY methods (as documented in IETF RFC 3265) provide a basic 
mechanism for event notification between nodes. In the most basic implementation, an entity on a 
network can use the SUBSCRIBE request to communicate its interest in certain state changes for 
resources or calls on the network, and those entities (or other entities acting on their behalf) can 
send NOTIFY messages as notifications when those state changes occur. This SUBSCRIBE / 
NOTIFY mechanism is used outside of a dialog or call. 

In addition, there may be unsubscribed NOTIFY messages that are not preceded by a 
corresponding SUBSCRIBE request. One common use of unsubscribed NOTIFY messages is to 
enable and disable the Message Waiting Indicator (MWI) on a PIMG.

The Dialogic

®

 Global Call API library for SIP fully supports both the SUBSCRIBE and NOTIFY 

methods, including both subscribed and unsubscribed NOTIFY. These messages are all handled on 
a “pass-through” basis (in other words, there are no Global Call state changes associated with the 
events). The Global Call Extension API mechanism is used in all cases. Outgoing requests and 
responses are sent by building an appropriate GC_PARM_BLK and then calling gc_Extension( ), 
while incoming requests and responses are passed to the application as GCEV_EXTENSION 
events. 

Note that the NOTIFY messages which are used in the Dialogic

®

 Global Call API library 

implementation of SIP call transfer are not handled explicitly by applications using the techniques 
described in this section. The Dialogic

®

 Global Call API library handles these messages implicitly, 

automatically generating the outgoing NOTIFY messages that are required in a call transfer 
operation, and passing incoming NOTIFY messages associated with a call transfer to the 
application as GCEV_INVOKE_XFER or GCEV_INVOKE_XFER_FAIL events. The exception 
to this generalization is a NOTIFY message that is sent to the Transferor after the primary call has 
been dropped; in this case, the message is interpreted as a “normal” NOTIFY outside of a dialog 
and is passed as a GCEV_EXTENSION event that the application must explicitly accept or reject 
as described in 

, on page 235. These post-

termination NOTIFY messages may occur under various circumstances, including the following:

In the normal course of events in the scenario where the Transferor is notified upon ringing of 
the transferred call (see 

If a 200 OK to NOTIFY is lost in the network and the primary call is terminated by party A 
before party B sends another NOTIFY as a retry

If a non-Global Call UA sends a NOTIFY for some reason after the primary call is terminated

Note that an application that will be sending and receiving SUBSCRIBE and NOTIFY messages 
must enable both the SIP message information (header) and SIP MIME (body) access features 
before starting the IPT virtual board with the gc_Start( ) function. The 

utility function populates the 

 structure with default values. The default values of 

the sip_msginfo_mask field in this structure must be overridden to enable application access to 
SUBSCRIBE and NOTIFY messages. Specifically, the sip_msginfo_mask field must be set to the 
OR of IP_SIP_MSGINFO_ENABLE and IP_SIP_MIME_ENABLE. See the reference page for 

 on page 553 for more information on this field and these mask values.