This chapter describes the Oracle Communications Services Gatekeeper Parlay X 2.1 Third Party Call/Session Initiation Protocol (SIP) communication service in detail.
The Parlay X 2.1 Third Party Call/SIP communication service exposes the Parlay X 2.1 Third Party Call application interfaces.
The communication service connects to a SIP-IMS network using Oracle Converged Application Server. Converged Application Server is collocated with Services Gatekeeper in the network tier. In this relationship, Services Gatekeeper acts as a Back-to-Back User Agent for all calls.
For the exact version of the standards that the Parlay X 2.1 Third Party Call/SIP communication service supports for the application-facing interfaces and the network protocols, see Services Gatekeeper Statement of Compliance.
Using a Third Party Call Parlay X 2.1 communication service, an application can:
Set up a call between two parties.
For example, an application could set up a call between an investor and a broker if a particular stock reaches a predetermined price. Or a computer user could set up a call between himself and someone in the address book with a mouse click.
Query Services Gatekeeper for the status of a previously set up call.
Cancel a call as it is about to be set up.
Terminate an ongoing call it created.
In the Parlay X 2.1 Third Party Call model, a call has two distinct stages:
There are two parties involved in Third Party Call calls: the A-party (the caller) and the B-party (the callee). When a call is set up using a Third Party Call communication service, Services Gatekeeper attempts to set up a call leg to the A-party. When the caller goes off-hook (answers), Services Gatekeeper attempts to set up a call leg to the B-party. When the callee goes off-hook, the two call legs are connected using the underlying telecom network. This ends the call setup phase.
The application can cancel the call during this phase.
While the call is underway, the audio channel that connects the caller and the callee is completely managed by the telecom network. During this phase of the call, the application can only query for the status of the call. A call can be terminated in two ways, either using the application-facing interface, or having the caller or callee hang up.
Requests using a Parlay X 2.1 Third Party Call communication service flow only in one direction, from the application to the network. Therefore this communication service supports only application-initiated functionality.
The Parlay X 2.1 Third Party Call /SIP communication service manages only the signalling, or controlling, aspect of a call. The media or audio channel is managed by the telecom network. 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 2.1 Third Party Call communication service, see the discussion about Parlay X 2.1 Part2: Third Party Call in Services Gatekeeper Application Developer's Guide.
For information about the RESTful Third Party Call interface, see the discussion about RESTful Third Party Call interfaces in Services Gatekeeper Application Developer's Guide.
The RESTful Service Call Notification interfaces provide RESTful access to the same functionality as the SOAP-based interfaces. The internal representations are identical, and for the purposes of creating SLAs and reading charging data records (CDRs), and so on, they are the same.
The Parlay X 2.1 Third Party Call/SIP communication service generates Event Data Records (EDRs), CDRs, alarms, and statistics to assist system administrators and developers in monitoring the service.
See "Events, Alarms, and Charging" for more information.
Table 12-1 lists the IDs of the EDRs created by the Parlay X 2.1 Third Party Call/ SIP communication service. This does not include EDRs created when exceptions are thrown.
Parlay X 2.1 Third Party Call-specific CDRs are generated under the following conditions:
When Services Gatekeeper has received an event from the network stating that the second call leg has been connected and the associated phone has started to ring. This CDR is not dependent on whether the call is answered.
When call information has been successfully delivered to the application.
When the call is ended by the application.
When the call request is canceled by the application.
Table 12-2 maps methods invoked from either the application or the network to the transaction types collected by the Services Gatekeeper statistics counter:
This section describes the properties and workflow for setting up a Parlay X 2.1 Third Party Call/SIP protocol translation module.
Parlay X 2.1 Third Party Call/SIP uses two parts for SIP connectivity: a part that executes as a network protocol plug-in instance in Services Gatekeeper container and a part that executes as a SIP application in the SIP Server container.
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 12-3 lists the technical specifications for the communication service.
Table 12-3 Properties for Parlay X 2.1 Third Party Call/SIP
| Property | Description |
|---|---|
|
Managed object in Administration Console |
To access the object, select domain_name, then OCSG, then server_name, then Communication Services, then Plugin_third_party_call_sip, in that order. |
|
MBean |
Domain=com.bea.wlcp.wlng Name=wlng_nt InstanceName=Plugin_px21_third_party_call_sip Type=com.bea.wlcp.wlng.plugin.tpc.sip.management.TPCMBean Documentation: See the "All Classes" section of Services Gatekeeper OAM Java API Reference. |
|
Network protocol plug-in service ID |
Plugin_px21_third_party_call_sip |
|
Network protocol plug-in instance ID |
Plugin_px21_third_party_call_sip |
|
Supported Address Scheme |
sip, tel |
|
Application-facing interface |
com.bea.wlcp.wlng.px21.plugin.ThirdPartyCallPlugin |
|
Service type |
ThirdPartyCall |
|
Exposes to the service communication layer a Java representation of: |
Parlay X 2.1 Part 2: Third Party Call |
|
Interfaces with the network nodes using: |
SIP: Session Initiation Protocol, RFC 3261 |
|
Deployment artifacts |
px21_third_party_call_service.jar, Plugin_px21_third_party_call_sip.jar, and Plugin_px21_third_party_call_sip.war, packaged in wlng_nt_third_party_call_px21.ear px21_third_party_call.war, packaged in wlng_at_third_party_call_px21.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.
Select the TPCMBean MBean.
See the "All Classes" section of Services Gatekeeper OAM Java API Reference for details on this MBean.
Configure behavior of the network protocol plug-in instance using these fields to the TCPMBean:
ChargingAllowed
ControllerURI
ISCRouteURI
MaximumCallLength
StatusRetentionTime
Set up the routing rules to the plug-in instance. See the discussion about configuring and managing the plug-in manager in Services Gatekeeper System Administrator's Guide. Use the plug-in instance ID and address schemes listed in the "Properties for Parlay X 2.1 Third Party Call/SIP" section.
If required, create and load a node SLA. For details see the discussion on defining global node and service provider group node SLAs and managing SLAs in Services Gatekeeper Portal Developer's Guide.
Provision the service provider accounts and application accounts. For information, see Services Gatekeeper Portal Developer's Guide.
For a description of the attributes and operations of the TPCMBean MBean, see the "All Classes" section of Services Gatekeeper OAM Java API Reference.