Communication Service Reference

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

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

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:

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

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

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:

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

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:

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

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

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:

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.


  Back to Top       Previous  Next