![]() ![]() ![]() ![]() ![]() ![]() |
The following chapter describes the Parlay X 3.0 Call Notification communication service in detail:
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:
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 setup new calls, only to reroute or terminate calls already in progress. |
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 Network 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 Network Gatekeeper. |
Two types of notifications exist:
An application can register to be notified about the following events as the call between the caller and the callee is set up:
Note: | The above notifications may include a callSessionIdentifier 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, by nature, to be asynchronous. |
Note: | Setting up a notification for a play and record media event is supported in Network 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. |
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:
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-initiated” types. It’s important to note that 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: |
Off-the shelf, the Parlay X 3.0 Call Notification communication service can be configured to support the following network protocol:
When Network Gatekeeper is configured to use this protocol, it connects to a Parlay 3.3 MultiParty 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 Network Gatekeeper supports.
Communication services share many common features, covered in the “Introducing Communication Services” chapter of 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:
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:
reportNotification
is sent from the Parlay gateway to Network Gatekeeper, indicating that a call event defined by the notification has occurred and (in appropriate cases) needs to be handled.sendInfoandCollectRes
has been sent from the Parlay gateway to Network Gatekeeper, indicating that a call participant has interacted with a Play and Collect operation. The response includes the digits collected.
The following are lists of EdrIds
created by the Parlay X 3.0 Call Notification/Parlay 3.3 MPCC communication service. This list does not include EDRs created when exceptions are thrown. For more information, seeEvents, Alarms, and Charging..
.
The table 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 Network 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. |
The Parlay X 3.0 Call Notification/Parlay 3.3 MPCC communication service supports the tel:
address scheme.
![]() ![]() ![]() |