|
|
This chapter describes the Parlay X 3.0 Third Party Call communication service in detail:
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:
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: |
Off-the shelf, the Parlay X 3.0 Third Party Call communication service can be configured to support the following network protocol:
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.
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:
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:
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-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:
The Parlay X 3.0 Third Party Call-Parlay 3.3 MPCC communication service supports the tel: address scheme.
|