In this section:
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:
The SBC does not send notifications for Re-INVITE and UPDATE messages or their responses.
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:
loadDistribution
flag). The ERE sends separate policy responses containing server details for matches of the calling and called user. For more information on configuring this feature, refer to Configuring the SBC to Send Unsolicited Call Notifications to Application Servers.
When the SBC sends NOTIFY messages, it populates the following headers in the messages as follows:
NOTIFY Message Header Contents
Header | NOTIFY 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: |
To | Same as the Request URI. |
Call-ID | Auto-generated by the SBC. |
CSeq | nnn NOTIFY |
Max-Forwards | 70 |
Via | SBC Via header |
Contact | SBC signaling address |
Event | dialog |
Subscription-State |
|
Content-Type | application/dialog-info+xml |
Content-Length | Based on the message body size. |
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.
NOTIFY Message XML Contents
XML Contents | NOTIFY Sent for Matched Calling Party on Ingress Leg | NOTIFY Sent for Matched Called Party on Egress Leg |
---|---|---|
dialog-info version attribute | Starts at 0 for every new call notification and increases by 1 for every notification related to the same call. | |
dialog-info state attribute | Set to "full." The SBC sends the complete state in every notification. | |
dialog-info entity | URI 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 attribute | Populated with the unique session ID the SBC generates for each leg. | |
dialog call-id attribute | Call-id of the ingress call leg. | Call-id of the egress call leg. |
dialog local-tag attribute | To header tag for the ingress leg. | From header tag for the egress leg. |
dialog remote-tag attribute | From 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 attribute | Set to "initiator." | Set to "recipient." |
identity element in local element | The To header contents in the ingress INVITE message. | The From header contents in the egress INVITE message. |
identity element in remote element | The From header contents in the ingress INVITE message. | The To header contents in the egress INVITE message. |
Ribbon Proprietary extension – PAI | The 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 – Timestamp | The current local timestamp for the SBC, in millisecond precision. | |
Session-Id | For 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. |
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.
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.
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.
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.