# Communication Service Reference

# Parlay X 3.0 Third Party Call Communication Service

This chapter describes the Parlay X 3.0 Third Party Call communication service in detail:

- An Overview of the Parlay X 3.0 Third Party Call Communication Service

- How It Works
- Supported Network Protocols

- Configuration Specifics for the Parlay X 3. 0 Third Party Call Communication Service

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

## An Overview of the Parlay X 3.0 Third Party Call Communication Service

This communication service implements the Parlay X 3.0 Third Party Call interface. For the exact version of the standard this communication service supports, see “Appendix A: Standards and Specifications” in Concepts and Architectural Overview, another document in this set.

Using the Third Party Call Parlay X 3.0 communication service, an application can:

- Setup a uniquely identified call between one or more participants and add or delete further participants, or transfer them to other established calls
- Indicate charging information to be associated with the call session
- Indicate information on any media to be used in association with the call
- Interact with the functionality of other communication services, such as Audio Call to play audio to call participants or Call Notification to respond to previously established notifications
- Query Oracle Communications Services Gatekeeper for the status of an established call or particular call participants
- Terminate an ongoing call it created

### How It Works

The Parlay X 3.0 Third Party Call communication service can be used by applications that need to set up calls to one or more participants, as, for example, in establishing a conference call. It can also be used to set up calls that also use the capabilities of other communication services (Audio Call or Call Notification). The application first sets up the call session by using the `makeCallSession` operation, passing in the address of at least one (the A-party) participant.

Note: | In the most common case, the address of a second participant, the B-party, is also passed in.

Oracle Communications Services Gatekeeper sends a request to establish the first call leg to the underlying network and returns a unique identifier (`callSessionIdentifier`) to the application synchronously. This identifier allows the application to perform further administrative tasks on the call, and provides any other communication services (Audio Call or Call Notification) access to the call at any point during the call session.

Note: | The Call Session Identifier is returned to the application before the A-party goes off hook (answers). To receive information on the ongoing status of the call session, the application polls Oracle Communications Services Gatekeeper, using the identifier and the `getCallSessionInformation` operation.

While the call is underway, the application can add additional parties, delete one or more parties, or transfer parties to and from other established call sessions, using the identifier returned during the call setup phase. The functionality of the Audio Call (playing media to one or more participants) and Call Notification (for example rerouting a “busy” address to a second predefined one) communication services can also be accessed in the context of the call session using this same identifier. A call can be terminated in two ways, either by using the application-facing interface, or by having the call participants hang up.

Requests using the Third Party Call communication service flow only in one direction, from the application to the network. By itself this communication service supports only application-initiated (or mobile terminated) functionality. Mobile originated scenarios can be supported when using this communication service in concert with Call Notification.

Note: | The Parlay X 3.0 Third Party Call communication service manages only the signalling, or controlling, aspect of a call. The call itself takes place in 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, the Parlay X 3.0 Third Party Call communication service can be configured to support the following network protocol:

- Parlay 3.3 Multi-Party Call Control

#### Parlay 3.3 Multi-Party Call Control

When Oracle Communications Services Gatekeeper is configured to use this protocol, it connects to a Parlay 3.3 Multi-Party Call Control SCS provided by an OSA/Parlay Gateway. See “Appendix A: Standards and Specifications” in the Concepts and Architectural Overview for the exact version of the standard Oracle Communications Services Gatekeeper supports.

## Configuration Specifics for the Parlay X 3. 0 Third Party Call Communication Service

Communication services share many common features, covered in the “Introducing Communication Services” chapter of the 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 3. 0 Third Party Call communication service, including:

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

### Charging Data Records

#### Generation of CDRs

There are seven specific Parlay X 3.0 Third Party Call-Parlay 3.3 MPCC communication service CDRs. They occur when the following criteria are met:

- After Oracle Communications Services Gatekeeper has created the first call leg of a call session. This is not dependent on whether the participant has answered.
- After a call participant has been added to a call session, deleted from a session, or transferred to or from another session.
- When call information or call participant information has been successfully delivered to the application
- When the call is ended by the application

### Event Data Records

The EDRs produced by the Parlay X 3.0 Third Party Call/Parlay 3.3 communication service are of the standard type and are documented in Table 4-1. This does not include EDRs created when exceptions are thrown. For more information on the contents of standard EDRs, see Events, Alarms, and Charging.

Table 4-1 Event types emitted in the Parlay X 3.0 Third Party Call/Parlay 3.3 communication service
EdrId | Method Called
--- | ---
10000 | addCallParticipant
10001 | deleteCallParticipant
10002 | endCallSession
10003 | getCallParticipantInformation
10004 | getCallSessionInformation
10005 | makeCallSession
10006 | transferCallParticipant
10007 | eventReportRes
10008 | eventReportErr
10009 | callLegEnded
10010 | callEnded
10011 | createAndRouteCallLegErr
10012 | getInfoRes
10013 | getInfoErr

### Statistics

Table 4-2 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 the Parlay X 3.0 Third Party Call-Parlay 3.3 MPCC communication service:

Table 4-2 Transaction types for Parlay X 3.0 Third Party Call - Parlay 3.3 MPCC communication service
Method | Transaction type
--- | ---
makeCallSession | TRANSACTION_TYPE_CALL_CONTROL_SERVICE_INITIATED
transferCallParticipant | TRANSACTION_TYPE_CALL_CONTROL_SERVICE_INITIATED
addCallParticipant | TRANSACTION_TYPE_CALL_CONTROL_SERVICE_INITIATED

### Supported Address Schemes

The Parlay X 3.0 Third Party Call-Parlay 3.3 MPCC communication service supports the`tel:` address scheme.