Filter
Top Products
4.15 Using SIP SUBSCRIBE and NOTIFY Messages
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 Section 4.15.8, “Responding to NOTIFY Requests”, 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 Figure 26, “Successful SIP Unattended Call Transfer, Party A Notified
with Ringing”, on page 80)
• 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 INIT_IP_VIRTBOARD( )
utility function populates the IP_VIRTBOARD 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
IP_VIRTBOARD on page 553 for more information on this field and these mask values.