# Communication Service Reference

# 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

- How It Works
- Supported Network Protocols

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

- Charging Data Records
- Event Data Records
- Statistics
- Supported Address Schemes

## 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:

- 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 Oracle Communications Services Gatekeeper for the status of a previously set up call
- Cancel a call it is creating as it is about to be set up
- Terminate an ongoing call it created

### How It Works

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

- Call Setup
- Call Duration

#### 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:

- 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

### 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
- INAP/SS7

#### 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
- Event Data Records
- Statistics
- Supported Address Schemes

### 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:

- When Oracle Communications 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

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

- When the network notifies Oracle Communications Services Gatekeeper that the call is connected; that is, that the second participant has answered the call
- When the network notifies Oracle Communications Services Gatekeeper that a call participant has disconnected

### 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.