# Communication Service Reference

# Parlay X 3.0 Call Notification Communication Service

This chapter describes the Parlay X 3.0 Call Notification communication service in detail:

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

- How It Works
- Supported Network Protocols

- Configuration Specifics for the Parlay X 3.0 Call Notification Communication Service

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

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

This Call Notification communication service implements the Parlay X 3.0 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.

Using a 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 notifications on call events related to established notifications
- Interact with the functionality of other communication services, including Audio Call to play audio to call participants and/or collect data from them or Third Party Call to reroute the call or set up additional call legs.
- End the call

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 during the setup phase. By itself, this communication service is not used to set up new calls, only to reroute or terminate calls already in progress.

### How It Works

In order 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 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:

- Monitoring
- Monitoring and rerouting

#### Monitoring

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

- The callee is busy
- The callee is not reachable
- The callee does not answer
- The caller is attempting to call the callee
- The callee has answered the call

Note: | The above notifications may include a Call Session Identifier identifying the call session in the network, if available, to allow interactions with other Parlay X Web Services, such as Third Party Call and Audio Call. These interactions tend to be asynchronous.

- A call participant has interacted with a play-and-collect-media event. The notification contains the results of the interaction, including the digits collected.
- A call participant has interacted with a play-and-record-media event. The notification contains the results of the interaction, including the location of the recorded information.

Note: | Setting up a notification for a play and record media event is supported in Oracle Communications Services Gatekeeper version 4.0, but setting up the play and record interaction is not supported in the Parlay X 3.0 Audio Call communication service in this version.

#### 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, in a synchronous manner. In the case of certain monitored events (busy, not reachable, no answer, call attempt), an application can specify how to handle them, including:

- Continue to let the call be managed by the network in the normal manner, by, for example, playing a busy tone
- End the call
- Intercept the call setup attempt between the caller and the callee and reroute the call to another callee (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.

Note: | If the call is rerouted, the media type is always negotiated by the underlying network. The MediaInfo parameter is not currently used by the communication service.

Because the Call Notification communication service does handle traffic in two directions (from the application to the network and from the network to the application) its functionality has some aspects of both the application-initiated and the network-triggered types. The communication service itself manages only the signalling, or controlling, aspect of the call. The call itself, the media, or audio, channel, is completely handled by the underlying telecom network.

Note: | Because the communication service manages only the signalling aspect of the call, 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 3.0 Call Notification communication service can be configured to support the following network protocol:

- Parlay 3.3 Multi-Party Call Control

#### Parlay 3.3 Multi-Party Call Control

When Oracle Communications Services Gatekeeper is configured to use this protocol, it connects to a Parlay 3.3 Multi-Party Call Control SCS provided by an OSA/Parlay Gateway. See “Appendix A: Standards and Specifications” in Concepts and Architectural Overview for the exact version of the standard Oracle Communications Services Gatekeeper supports.

## Configuration Specifics for the Parlay X 3.0 Call Notification Communication Service

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 Call Notification communication service, including:

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

### Charging Data Records

#### Generation of CDRs

There are three CDRs generated by the Call Notification Parlay X 3.0/Parlay 3.3 MPCC communication service. They occur when the following criteria are met:

- After a `reportNotification` is sent from the Parlay gateway to Oracle Communications Services Gatekeeper, indicating that a call event defined by the notification has occurred and (in appropriate cases) needs to be handled.
- After a `sendInfoandCollectRes` has been sent from the Parlay gateway to Oracle Communications Services Gatekeeper, indicating that a call participant has interacted with a play-and-collect operation. The response includes the digits collected.

### Event Data Records

Table 6-1 lists EDR IDs created by the Parlay X 3.0 Call Notification/Parlay 3.3 MPCC communication service. This does not include EDRs created when exceptions are thrown. For more information, seeEvents, Alarms, and Charging.

Table 6-1 Event types emitted in the Parlay X 3.0 Call Notification/Parlay 3.3 MPCC communication service
Event data | Description
--- | ---
11000 | startCallDirectionNotification
11001 | stopCallDirectionNotification
11002 | startCallNotification
11003 | stopCallNotification
11004 | startPlayAndCollectNotification
11006 | stopMediaInteractionNotification
11007 | reportNotification
11008 | deleteNotification
11009 | createNotification
11011 | sendInfoAndCollectRes

.

### Statistics

Table 6-2 below 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 3.0 Call Notification/Parlay 3.3 MPCC 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 6-2 Transaction types for Parlay X 3.0 Call Notification/Parlay 3.3 MPCC communication service
Method | Transaction type
--- | ---
reportNotification (both CallNotification and CallDirection) | TRANSACTION_TYPE_CALL_CONTROL_NETWORK_INITIATED
sendInfoAndCollectRes (callNotification only) | TRANSACTION_TYPE_CALL_CONTROL_NETWORK_INITIATED

### Supported Address Schemes

The Parlay X 3.0 Call Notification/Parlay 3.3 MPCC communication service supports the`tel:` address scheme.