Oracle® Communications Services Gatekeeper Communication Service Guide Release 5.0 Part Number E21362-01 |
|
|
View PDF |
This chapter describes the 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 communication service supports for the application-facing interfaces and the network protocols, see the appendix on standards and specification in Concepts Guide.
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 of Parlay X 2.1 Interface in Application Developer's Guide.
For information about the RESTful Third Party Call interface, see the discussion of Third Party Call in RESTful 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 CDRs, and so on, they are the same.
The Parlay X 2.1 Third Party Call/SIP 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 9-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 9-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 9-3 lists the technical specifications for the communication service.
Table 9-3 Properties for Parlay X 2.1 Third Party Call/SIP
Property | Description |
---|---|
Managed object in Administration Console |
domain_name > OCSG > server_name > Communication Services > Plugin_third_party_call_sip |
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 |
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 MBean listed in the "Properties for Parlay X 2.1 Third Party Call/SIP" section.
Configure behavior of the network protocol plug-in instance:
Set up the routing rules to the plug-in instance. See "Managing and Configuring the Plug-in Manager" in 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 “Defining Global Node and Service Provider Group Node SLAs” and “Managing SLAs” in the Accounts and SLAs Guide.
Provision service provider accounts and application accounts. For information, see Accounts and SLAs Guide.
Following is a list of attributes for configuration and maintenance:
Scope: Cluster
Unit: Not applicable
Format: Boolean
Specifies if charging is allowed, meaning that the charging parameter is allowed to be present in a request from an application.
Scope: Cluster
Unit: Not applicable
Format: String in URI format
Specifies the Controller SIP URI that is used to establish the third party call. If this value is set, a call appears to the callee to come from this URI. By default, the value is None, where no controller URI is used to establish the call. In this case, the call appears to the callee to come from the caller
Scope: Cluster
Unit: Not applicable
Format: String in URI format
Specifies the URI of the IMS service control route.
Scope: Cluster
Unit: Minutes
Format: Integer
Specifies for maximum length allowed for a call. If this time expires, the call is terminated.
Scope: Cluster
Unit: Minutes
Format: Integer
Specifies how long to retain status information about a call after it has been terminated.