Communication Service Reference

     Previous  Next    Open TOC in new window    View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Parlay X 2.1 Third Party Call Communication Services

This chapter describes the Parlay X 2.1Third Party Call communication services in detail:

 


An Overview of the Parlay X 2.1 Third Party Call Communication Services

The SOAP Service Facade Third Party Call Parlay X 2.1 communication services implement the Parlay X 2.1 Third Party Call interface. For the exact version of the standard these communication services support, see “Appendix A: Standards and Specifications” in Concepts and Architectural Overview, another document in this set.

Note: The RESTful Service Facade Third Party Call interfaces provide RESTful access to this same functionality. The internal representations are identical, and for the purposes of creating SLAs and reading CDRs, etc., they are the same.

Using a Third Party Call Parlay X 2.1 communication service, an application can:

How It Works

In the Parlay X 2.1 Third Party Call communication services model, a call has two distinct stages:

Call Setup

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, Oracle Communications Services Gatekeeper attempts to set up a call leg to the A-party. When the caller goes off-hook (“answers”), Oracle Communications 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.

Call Duration

While the call is underway, the audio channel that connects the caller and the callee is completely managed by the underlying telecom network. During this phase of the call, the application can only query as to 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 (or mobile-terminated) functionality.

Note: Third Party Call communication services manage only the signalling, or controlling, aspect of a call. The media, or audio, channel is managed by the underlying telecom network. Only parties residing on the same network can be controlled, unless:

Supported Network Protocols

Off the shelf, Parlay X 2.1 Third Party Call communication services can be configured to support the following network protocols:

SIP

When Oracle Communications Services Gatekeeper is configured to use this protocol, it connects to the SIP network. In this case, Oracle Communications Services Gatekeeper acts as a Back-to-Back User Agent. During the call duration phase, the actual call is peer-to-peer.

INAP/SS7

When Oracle Communications Services Gatekeeper is configured to use this protocol, it connects to the underlying network via an INAP/SS7 interface. See “Appendix A: Standards and Specifications” in Concepts and Architectural Overview for the exact version of the standard Oracle Communications Services Gatekeeper supports.

 


Configuration Specifics for the Parlay X 2.1 Third Party Call Communication Services

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 Parlay X 2.1 Third Party Call communication services, including:

Charging Data Records

Generation of CDRs

The Parlay X 2.1 Third Party Call using SIP and the Parlay X 2.1 TPC using INAP/SS7 are standard communication services. CDRs are written:

In addition, Parlay X 21 Third Party Call using INAP/SS7 also writes CDRs:

Event Data Records

Both the Parlay X 2.1 Third Party Call SIP and the TPC INAP/SS7 communication services use the 3.0 mechanism and are documented in Table 3-1 and Table 3-2. This does not include EDRs created when exceptions are thrown. For more information, see Events, Alarms, and Charging.

Table 3-1 Event types emitted in the Parlay X 2.1 Third Party Call/SIP communication service
Event data
Description
8022
makeCall
8023
getCallInformation
8024
endCall
8025
cancelCallRequest

.The following events are generated for the INAP/SS7 communication service in addition to those listed in Table 3-1 above:

Table 3-2 Event types emitted in the Parlay X 2.1 Third Party Call/INAP-SS7 communication service
Event data
Description
8026
callConnected
8027
callReleasedNotification

Statistics

Table 3-3 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 either the Parlay X 2.1 Third Party Call/SIP or INAP/SS7 communication services:

Table 3-3 Transaction types for Parlay X 2.1 Third Party Call communication service
Method
Transaction type
makeCall
TRANSACTION_TYPE_CALL_CONTROL_SERVICE_INITIATED

Supported Address Schemes

The Parlay X 2.1 Third Party Call using either SIP or INAP/SS7 communication services supports the tel: address scheme.


  Back to Top       Previous  Next