# Communication Service Reference

# Parlay X 2.1 Call Notification Communication Service

The following chapter describes the Parlay X 2.1 Call Notification communication service in detail:

- An Overview of the Parlay X 2.1 Call Notification Communication Service

- How It Works
- Supported Network Protocols

- Configuration Specifics for the Parlay X 2.1 Call Notification Communication Services

- Charging Data Records
- Event Data Records
- Statistics
- Supported Address Schemes

## An Overview of the Parlay X 2.1 Call Notification Communication Service

The SOAP Services Facade Call Notification communication service implements the Parlay X 2.1 Call Notification set of interfaces. For the exact version of the standard this communication service supports, see “Appendix A: Standards and Specifications” in Concepts and Architectural Overview, another document in this set.

Note: | The RESTful Service Facade Call Notification interfaces provide RESTful access to this same functionality. The internal representations are identical, and for the purposes of creating SLAs and reading CDRs, etc., they are the same.

Using the Call Notification communication service, an application can:

- Set up and tear down notifications on call events for a given combination of caller and callee
- Receive additional notifications on call events related to the notification in question
- Affect a call during call setup

Note: | The operations made available by the Call Notification communication service are concerned only with monitoring (and, in some cases, making certain changes to) calls. This communication service is not used to set up new calls; it is used only to reroute or terminate calls already in progress.

### How It Works

For an application to receive notifications about call setup attempts from the network, it must register its interest in these notifications by setting up a subscription in Oracle Communications Oracle Communications Services Gatekeeper. A subscription, or a notification, is defined by a set of addresses and a set of criteria. The criteria define the events in which the application is interested.

Note: | The addresses may possibly be translated by some mechanism in the telecom network prior to reaching Oracle Communications Services Gatekeeper.

Two types of notifications exist:

- Simple monitoring
- Monitoring and rerouting

#### Simple monitoring

An application can register to be notified about the following events as the call between the caller and the callee is set up:

- Callee is busy
- Callee is not reachable
- Callee does not answer
- Call is in progress
- Call setup in progress

#### Monitoring and rerouting

In addition to monitoring the state of call setup, an application can also choose to make certain changes to the call under certain conditions. An application can:

- Intercept a call setup attempt between the caller and the callee and reroute the call (to a C-party) without making an attempt to connect with the callee (B-party). An example might be a general technical support number that is routed to the appropriate call center based on time of day.

In addition, if one of the monitored events occurs (busy, not reachable, does not answer), an application can:

- Let further processing of the call be handled by the network
- End the call
- Reroute the call to another callee (C-party.)

Requests (that is, registration for notifications) using the Call Notification communication service flow only in one direction: from the application to Oracle Communications Services Gatekeeper. Therefore this communication service supports only network-triggered requests.

Note: | The Call Notification communication service manages only the signalling, or controlling, aspect of a call. The media, or audio, channel is managed by the underlying telecom network. Only parties residing on the same network can be controlled, unless:

- The network plug-in connects to a media gateway controller
- One of the participants is connected to a signalling gateway so that, from a signalling point of view, all parties reside on the same network

### Supported Network Protocols

Off-the shelf, the Parlay X 2.1 Call Notification communication service can be configured to support the following network protocol:

- SIP

#### SIP

When Oracle Communications Services Gatekeeper is configured to use this protocol it connects to the SIP network. Oracle Communications Services Gatekeeper acts as a SIP Back-to-Back User Agent. Although from a signalling point of view three parties are involved - the caller, the callee, and Oracle Communications Services Gatekeeper - from the SIP perspective, the media channel (the actual call) that is established is purely peer to peer.

## Configuration Specifics for the Parlay X 2.1 Call Notification Communication Services

Communication services share many common features, covered in “Introducing Communication Services” in Concepts and Architectural Overview, but each one has a few characteristics that are specific only to that service. This section describes those specific features for the Parlay X 2.1 Call Notification communication service, including:

- Charging Data Records
- Event Data Records
- Statistics
- Supported Address Schemes

### Charging Data Records

#### Generation of CDRs

The CDRs generated by the Parlay X 2.1 Call Notification to SIP communication service belong to two basic groups. They occur when the following criteria are met:

- After a `notifyBusy`, `notifyCalledNumber`, `notifyNoAnswer`, `notifyAnswer`, or `notifyNotReachable` is sent from the network.
- After a `handleBusy`, `handleCalledNumber`, `handleNoAnswer`, or `handleNotReachable` is called

### Event Data Records

Table 5-1 lists EDR IDs created by the Parlay X 2.1 Call Notification to SIP communication service. This list does not include EDRs created when exceptions are thrown. For more information, see Events, Alarms, and Charging.

Table 5-1 Event types emitted in the Call Notification/SIP communication service
Event data | Description
--- | ---
3000 | startCallNotification
3001 | stopCallNotification
3002 | startCallDirectionNotification
3003 | stopCallDirectionNotification
8014 | notifyBusy
8015 | notifyCalledNumber
8016 | notifyNoAnswer
8017 | notifyNotReachable
8018 | handleBusy
8019 | handleCalledNumber
8020 | handleNoAnswer
8021 | handleNotReachable

### Statistics

Table 5-2 outlines the correlation between the methods being invoked from either the application (in application-initiated requests) or the telecom network (in network-initiated requests) and the transaction type collected by the statistics counters in Oracle Communications Services Gatekeeper for the Parlay X 2.1 Call Notification to SIP communication service:

Note: | Method names for network-initiated requests are specified by the internal Gatekeeper name, which is not necessarily the same as the message from the network.

Table 5-2 Transaction types for Parlay X 2.1 Call Notification-SIP communication service
Method | Transaction type
--- | ---
notifyBusy | TRANSACTION_TYPE_CALL_CONTROL_NETWORK_INITIATED
notifyNotReachable | TRANSACTION_TYPE_CALL_CONTROL_NETWORK_INITIATED
notifyNoAnswer | TRANSACTION_TYPE_CALL_CONTROL_NETWORK_INITIATED
notifyCalledNumber | TRANSACTION_TYPE_CALL_CONTROL_NETWORK_INITIATED
handleBusy | TRANSACTION_TYPE_CALL_CONTROL_NETWORK_INITIATED
handleNotReachable | TRANSACTION_TYPE_CALL_CONTROL_NETWORK_INITIATED
handleNoAnswer | TRANSACTION_TYPE_CALL_CONTROL_NETWORK_INITIATED
handleCalledNumber | TRANSACTION_TYPE_CALL_CONTROL_NETWORK_INITIATED

### Supported Address Schemes

The Parlay X 2.1 Call Notification-SIP communication service supports the`tel:` address scheme.