In this section:

Related articles:

For deployments requiring notifications when calls are set up by the SBC, you can configure the SBC to send SIP NOTIFY messages to a specified Application Server when a call's calling party or called party matches criteria you specify. Application Servers do not need to subscribe (send a SUBSCRIBE message) to receive these call notifications. Instead, through configuration, you specify the call criteria that triggers the SBC to send call notifications and which server should receive the notifications. This feature is applicable to SBC deployments using the Embedded Routing Engine (ERE) for routing and policy management, and not to deployments that use an external PSX.

Using the NOTIFY message format specified in RFC 4235, when the calling party or called party matches the configured criteria, the SBC sends notifications corresponding to four events within the span of a call:  

  • Call created event 
    • For a calling party match - On receiving an initial INVITE request, if the calling party matches, the SBC sends a call created event (NOTIFY) for the ingress leg to the server specified in the matching criteria. 
    • For a called party match - While sending an initial INVITE request toward the egress side, if the called party matches, the SBC sends a call created event (NOTIFY) for the egress leg to the server specified in the matching criteria.  
  • Call progress/ringing event 
    • The SBC sends a NOTIFY for the matched calling/called party for the ingress/egress leg after receiving/sending a 18x message.
  • Call connected event
    • The SBC sends a NOTIFY for the matched calling/called party for the ingress/egress leg after receiving a 200 OK response to the initial INVITE. 
  • Call terminated event
    • The SBC sends a NOTIFY for the matched calling/called party for the ingress/egress leg upon call termination. 

The SBC does not send notifications for re-INVITE and UPDATE messages or their responses.

Configuration Overview

The SBC provides four configuration entities that you use together to specify the call criteria the ERE compares against calls and to provide information about the servers (call notification servers) to notify in the event of a match:

  • cnsGroupProfile – contains information on up to 8 servers to receive call notifications, and specifies how to distribute the notifications among the servers (through the loadDistribution flag). The ERE sends separate policy responses containing server details for matches of the calling and called user.  
  • cnsGroupCluster – a container for cnsGroupProfiles. The configuration of each individual callNotificationCriteria object specifies the cnsGroupCluster that will be the recipient of notifications when a call matches that particular set of criteria. Currently, a cnsGroupCluster can contain only one cnsGroupProfile.
  • callNotificationCriteria – an individual set of criteria (called party, calling party, trunk group for the other call leg) the ERE compares against calls. The object also identifies the cnsGroupCluster to notify in the event of a match.   
  • callNotificationCriteriaGroup – a group of up to 32 callNotificationCriteria objects that you assign to a SIP trunk group. For calls on that trunk group, the ERE compares the calling number/called number and other-leg trunk group against the criteria in the group. The callNotificationCriteriaGroup specifies the sequence in which the criteria should be evaluated. Once a call matches one of the callNotificationCriteria objects, the matching process skips the remaining criteria in the group and the SBC initiates its notification process. 

For more information on configuring this feature, refer to Configuring the SBC to Send Unsolicited Call Notifications to Application Servers.

NOTIFY Message Headers

When the SBC sends NOTIFY messages, it populates the following headers in the messages as follows:

Table 1: NOTIFY Message Header Contents

HeaderNOTIFY Header Contents
Request-URI

SIP URI specified in the cnsGroupProfile that is associated with the matching notification criteria. A value to populate the userpart of the Request-URI is also specified in the matching notification criteria and can be the called number, calling number, a specified static value, or none.

From

The URI user part is set to "sbc" and the host part is the SBC signaling address used to send the NOTIFY. For example:
From: sip:sbc@<sbc_signaling_address>

ToSame as the Request URI.
Call-IDAuto-generated by the SBC.
CSeqnnn NOTIFY
Max-Forwards70
ViaSBC Via header
ContactSBC signaling address
Eventdialog
Subscription-State
  • For NOTIFY messages sent for initial INVITE messages, 18x responses, or 200 OK messages, the value is "active."
  • For NOTIFY messages sent for CANCEL or BYE messages the value is "terminated."
Content-Typeapplication/dialog-info+xml
Content-LengthBased on the message body size.

NOTIFY XML Message Body Contents

The following table lists the contents of the XML body within the NOTIFY messages and how the SBC populates them with information about a call that matched configured notification criteria. The contents of some elements differ based on whether the message is sent for a match on the ingress or egress leg.

Table 2: NOTIFY Message XML Contents

XML ContentsNOTIFY Sent for Matched Calling Party on Ingress LegNOTIFY Sent for Matched Called Party on Egress Leg
dialog-info version attributeStarts at 0 for every new call notification and increases by 1 for every notification related to the same call.
dialog-info state attributeSet to "full." The SBC sends the complete state in every notification.
dialog-info entityURI in the From header of the initial INVITE message received on the ingress leg.URI in the To header of the initial INVITE message sent on the egress leg.
dialog id attributePopulated with the unique session ID the SBC generates for each leg.
dialog call-id attributeCall-id of the ingress call leg.Call-id of the egress call leg.
dialog local-tag attributeTo header tag for the ingress leg.From header tag for the egress leg.
dialog remote-tag attributeFrom header tag for the ingress leg.To header tag; available only for messages after the initial INVITE (18x, 200 OK, and BYE), per SIP protocol.
dialog direction attributeSet to "initiator." Set to "recipient." 
identity element in local elementThe To header contents in the ingress INVITE message.The From header contents in the egress INVITE message.
identity element in remote elementThe From header contents in the ingress INVITE message.The To header contents in the egress INVITE message.
Ribbon Proprietary extension – PAIThe P-Asserted-Identity header contents from a SIP message on the specific call leg, if one is received in the call in an INVITE, 18X, 200 OK, or BYE message.
Ribbon Proprietary extension – TimestampThe current local timestamp for the SBC, in millisecond precision.
Session-IdFor correlation purposes, a session ID taken from a SIP header in the initial INVITE message. Specify which header to use as the source of the Session ID by creating a SIPREC metadata profile in which you map the header to the Session-Id XML element. Then, assign that SIPREC metadata profile as the sipCallNotificationMetadataProfile to the SIP trunk group that is sending the call notifications.

Routing of NOTIFY Messages

The SBC allows using either an explicit IP address or an FQDN when specifying the address of an Application Server that will receive call notifications. If the FQDN resolves to multiple IP addresses, the SBC attempts to send all NOTIFY messages for a particular call to the same server IP address.

If a server becomes unavailable and the SBC is unable to send subsequent NOTIFY messages to the same server, the SBC attempts to send them to the next server in the group. Similarly if the trunk group specified for a server goes out of service, the SBC attempts to send subsequent notifications to the next server in the group.

Crankback Scenarios

With notifications enabled, if the SBC receives an error to an initial INVITE request that results in the SBC changing the call to a new route, the SBC sends a "terminated" NOTIFY for the error response and it sends a new initial NOTIFY message that contains the new dialog information based on the new route. If the new route triggers notifications and the SBC had already sent notifications to a server on the ingress leg, the SBC continues to send subsequent notifications to the same server. If notifications were not previously sent on the ingress leg, the SBC sends notifications to the server called for by the match on the new route.

Call Redirection Scenarios

With notifications enabled, if the SBC receives a 3xx redirection response to an initial INVITE request, the SBC response depends on whether the redirection leads to a change in the dialog identifiers (call-id, from tag). If no change results, then the SBC does not send a NOTIFY message for the redirected INVITE. If the dialog identifier changes, the SBC sends a "terminated" NOTIFY for the 3xx response and sends a Trying NOTIFY for the redirected INVITE if the notification criteria matches for the called party. 

Call Transfer Scenarios

The SBC supports call transfers initiated using SIP REFER messages, REFER with Replaces, and INVITE with Replaces. If the user to whom a call is transferred matches some configured call notification criteria, then the SBC sends call notifications for the numbers involved in the call transfer.