![]() ![]() ![]() ![]() ![]() ![]() |
The following chapter describes the Parlay X 2.1 Third Party Call communication services in detail:
The 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 the Concepts and Architectural Overview, another document in this set.
Using a Third Party Call Parlay X 2.1 communication service, an application can:
In the Parlay X 2.1 Third Party Call communication services 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, first Network Gatekeeper attempts to set up a call leg to the A-party. Once the caller goes off-hook (“answers”), Network 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 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. Thus this communication service only supports “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: |
Off-the shelf, Parlay X 2.1 Third Party Call communication services can be configured to support the following network protocols:
When Network Gatekeeper is configured to use this protocol it connects to the SIP network. In this case, Network Gatekeeper acts as a Back-to-Back-User-Agent. During the call duration phase the actual call is purely peer-to-peer.
When Network 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 the Concepts and Architectural Overview for the exact version of the standard Network Gatekeeper supports.
Communication services share many common features, covered in the “Introducing Communication Services” chapter of the 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:
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 when:
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 below. This list does not include EDRs created when exceptions are thrown. For more information, see Events, Alarms, and Charging..
.The following events are generated for the INAP/SS7 communication service in addition to those listed in Table 3-1 above:
The table below 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 Network Gatekeeper for either the Parlay X 2.1 Third Party Call/SIP or INAP/SS7 communication services:
The Parlay X 2.1 Third Party Call using either SIP or INAP/SS7 communication services supports the tel:
address scheme.
![]() ![]() ![]() |