|
|
This 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 set up 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 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:
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 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. |
| 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. |
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-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: |
Off-the shelf, the Parlay X 3.0 Call Notification communication service can be configured to support the following network protocol:
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.
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:
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 Oracle Communications Services 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 Oracle Communications Services Gatekeeper, indicating that a call participant has interacted with a play-and-collect operation. The response includes the digits collected.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-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. |
The Parlay X 3.0 Call Notification/Parlay 3.3 MPCC communication service supports the tel: address scheme.
|