| Oracle® Communications Services Gatekeeper Communication Service Guide Release 5.1 E37526-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Communications Services Gatekeeper Communication Service Guide Release 5.1 E37526-01 |
|
|
PDF · Mobi · ePub |
This chapter describes the Parlay X 3.0 Call Notification/Parlay 3.3 Multi-Party Call Control (MPCC) communication service in detail.
Parlay X 3.0 Call Notification/Parlay 3.3 MPCC communication service exposes the Parlay X 3.0 Call Notification set of application interfaces.
The communication service acts as an Open Services Architecture (OSA) Parlay application to an internal Services Gatekeeper OSA/Parlay Gateway. It uses this gateway to access the MultiParty Call Control SCS. For information about the gateway, see "Managing OSA/Parlay Gateway Connections using Parlay_Access" in Oracle Communications Services Gatekeeper System Administrator's Guide.
For the exact version of the standards that the communication service supports for the application-facing interfaces and the network protocols, see the appendix on standards and specifications in Oracle Communications Services Gatekeeper Concepts Guide.
Using the Parlay X 3.0 Call Notification/Parlay 3.3 MPCC 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 or to collect data from them or Third Party Call to reroute the call or to set up additional call legs.
End the call.
The operations made available by this 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.
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 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.
The addresses may 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:
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:
These 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.
Setting up a notification for a play and record media event is supported, but setting up the play and record interaction is not supported in the Parlay X 3.0 Audio Call/Parlay 3.3 MPCC 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:
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.
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 this communication service handles 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.
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.
For information about the SOAP-based interface for the Parlay X 3.0 Call Notification communication service, the discussion of Parlay X 3.0 Interfaces in Oracle Communications Services Gatekeeper Application Developer's Guide.
The Parlay X 3.0 Call Notification/Parlay 3.3 MPCC communication service generates Event Data Records (EDRs), Charging Data Records (CDRs), alarms, and statistics to assist system administrators and developers in monitoring the service.
For general information, see Appendix A, "Events, Alarms, and Charging."
Table 16-1 lists IDs of the EDRs 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.
Table 16-1 Event Types Generated by Parlay X 3.0 Call Notification/Parlay 3.3 MPCC
| EDR ID | Method Called |
|---|---|
|
11000 |
startCallDirectionNotification |
|
11001 |
stopCallDirectionNotification |
|
11002 |
startCallNotification |
|
11003 |
stopCallNotification |
|
11004 |
startPlayAndCollectNotification |
|
11006 |
stopMediaInteractionNotification |
|
11007 |
reportNotification |
|
11008 |
deleteNotification |
|
11009 |
createNotification |
|
11011 |
sendInfoAndCollectRes |
Parlay X 3.0 Call Notification/Parlay 3.3 MPCC-specific CDRs are generated under the following conditions:
After a reportNotification is sent from the Parlay gateway to 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 Services Gatekeeper, indicating that a call participant has interacted with a play-and-collect operation; the response includes the digits collected.
Table 16-2 maps methods invoked from either the application or the network to the transaction types collected by the Services Gatekeeper statistics counters.
Table 16-2 Methods and Transaction Types for Parlay X 3.0 Call Notification/Parlay 3.3 MPCC
| Method | Transaction Type |
|---|---|
|
reportNotification (both CallNotification and CallDirection) |
TRANSACTION_TYPE_CALL_CONTROL_NETWORK_INITIATED |
|
sendInfoAndCollectRes (callNotification only) |
TRANSACTION_TYPE_CALL_CONTROL_NETWORK_INITIATED |
This section describes the properties and workflow for the Parlay X 2.1 Call Notification/Parlay 3.3 MPCC plug-in instance.
Most of the configuration is done in the OSA Access module, but with configuration parameters for Parlay MultiParty Call Control. See "Managing OSA/Parlay Gateway Connections using Parlay_Access" in Oracle Communications Services Gatekeeper System Administrator's Guide.
Two different types of notifications are managed:
Regular notifications, started by an application invoking startCallNotification or startCallDirectionNotification
Media notifications, started by an application invoking startPlayAndCollectNotification
This plug-in service is requires Orbacus, which is not installed by default. For information about installing Orbacus, see Oracle Communications Services Gatekeeper Installation Guide.This plug-in service does not support multiple instantiation using the Plug-in Manager. There is a one-to-one mapping between plug-in service and plug-in instance. The plug-in instance is created when the plug-in service is started.
Table 16-3 lists the technical specifications for the communication service.
Table 16-3 Properties for Parlay X 3.0 Call Notification/Parlay 3.3 MPCC
| Property | Description |
|---|---|
|
Managed object in Administration Console |
domain_name > OCSG > server_name > Communication Services->Plugin_px30_call_notification_parlay_mpcc |
|
MBean |
Domain=com.bea.wlcp.wlng Name=wlng_nt InstanceName=Plugin_px30_cn_parlay Type=com.bea.wlcp.wlng.px30.plugin.callnotification.parlay.management.mbean.CallNotificationMBean |
|
Network protocol plug-in service ID |
Plugin_px30_call_notification_parlay_mpcc |
|
Network protocol plug-in instance ID |
Plugin_px30_call_notification_parlay_mpcc |
|
Supported Address Scheme |
tel |
|
Application-facing interfaces |
com.bea.wlcp.wlng.px30.plugin.CallNotificationManagerPlugin com.bea.wlcp.wlng.px30.plugin.CallDirectionManagerPlugin com.bea.wlcp.wlng.px30.callback.CallDirectionCallback com.bea.wlcp.wlng.px30.callback.CallNotificationCallback |
|
Service type |
CallNotification |
|
Exposes to the service communication layer a Java representation of: |
Parlay X 3.0 Part 3: Call Notification |
|
Interfaces with the network nodes using: |
Open Service Access (OSA); Application Programming Interface (API); Part 4: Call Control SCF; Subpart 7: MultiParty Call Control Service |
|
Deployment artifacts |
px30_callnotification_parlay.jar, packaged in wlng_nt_call_notification_px30.ear px30_call_notification.war and px30_call_notification_callback.jar, packaged in wlng_at_call_notification_px30.ear |
This plug-in service does not support multiple instantiation using the Plug-in Manager. There is a one-to-one mapping between plug-in service and plug-in instance. The plug-in instance is created when the plug-in service is started.
Following is an outline for configuring the plug-in using the Administration Console or an MBean browser.
Using the Administration Console or an MBean browser, select the MBean listed in the "Properties for Parlay X 3.0 Call Notification/Parlay 3.3 MPCC" section.
Gather information about the OSA/Parlay Gateway and configure the protocol translator accordingly. The following information needs to be obtained from the OSA/Parlay Gateway administrator and configured in the Parlay Access service:
OSA/Parlay SCS type to be used in the look up (service discovery) phase when requesting the MultiParty Call Control service (OSA/Parlay SCS) from the OSA/Parlay Gateway. Typically this is P_MULTI_PARTY_CALL_CONTROL.
OSA/Parlay service properties to be used in the look up (service discovery) phase when requesting a service (OSA/Parlay SCS) from the OSA/Parlay Gateway. This depends on the OSA Gateway implementation.
Authentication type used by the OSA/Parlay Framework.
Encryption method used for the connection with the OSA Gateway.
Signing algorithm used when signing the service level agreement (SLA) with the OSA/Parlay Framework.
Set up the OSA/Parlay Client and the OSA/Parlay Client Mappings. See "Managing OSA/Parlay Gateway Connections using Parlay_Access" in Oracle Communications Services Gatekeeper System Administrator's Guide.
Set up the routing rules to the plug-in instance. See "Managing and Configuring the Plug-in Manager" in Oracle Communications Services Gatekeeper System Administrator's Guide. Use the plug-in instance ID and address schemes listed in the "Properties for Parlay X 3.0 Call Notification/Parlay 3.3 MPCC" section.
If desired, create and load a node SLA. For details see “Defining Global Node and Service Provider Group Node SLAs” and “Managing SLAs” in the Oracle Communications Services Gatekeeper Accounts and SLAs Guide.
Provision the service provider accounts and application accounts. For information, see Oracle Communications Services Gatekeeper Accounts and SLAs Guide.
This section describes operations for configuration and maintenance:
Scope: Cluster
Deletes a media notification.
Signature:
deleteMediaNotification(correlator: String)
Scope: Cluster
Deletes a notification from the storage and removes it from OSA Gateway.
Signature:
deleteNotification(correlator: String)
Scope: Cluster
Displays information about a media notification. The information includes:
Parlay X correlator
Parlay X callSessionIdentifier
needNotify This is an internal field. If true, the plug-in instance needs to invoke the Call Notification callback method sendInfoAndCollectRes.
Parlay IpAppUICallRef (CORBA IOR)
Parlay X endPoint to where the notification is sent
Data about the owner of the notification:
Service provider account ID
Application account ID
Application instance ID
notifMode, used to distinguish which kind of media notification the notification belongs to. This is the Parlay X operation that created the notification:
1 = The notification was created using startPlayAndCollectInteraction.
2 = The notification was created using startPlayAndRecordInteraction.
Signature:
getMediaNotification(correlator: String)
Scope: Cluster
Displays information about a notification. The information includes:
Parlay X Correlator
Parlay X Endpoint where notifications are sent
List of Parlay notification IDs associated with the Parlay X notification. There is one for each called party address for which notifications should be triggered supplied in the Parlay X operations startCallNotification or startCallDirectionNotification.
Data about the owner of the notification:
Service provider account ID
Application account ID
Application instance ID
Signature:
getNotification(correlator: String)
Scope: Cluster
Displays all active media notifications. These are notifications that have been registered by an application using:
startPlayAndCollectNotification
startPlayAndRecordNotification
Returns a list of correlators that uniquely identify each notification.
Signature:
listMediaNotifications()
Scope: Cluster
Displays all active call notifications. These are notifications registered by an application using:
startCallDirectionNotification
startCallNotification
Returns a list of correlators that uniquely identify each notification.
Signature:
listNotifications()
|
 Copyright © 2011, 2013, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|
