Jump to: navigation, search

Supplementary Services Gateway

The Supplementary Services Gateway manages the initiation of outbound sessions in GVP 8.5. It provides services for customer applications through the SIP Server to the Resource Manager to establish outbound calls between the caller and the Media Control Platform. This allows the Resource Manager to enforce policies, such as usage limits and dialing or translation rules, or to prevent certain customers from placing outbound calls.

For information about how the Resource Manager enforces policies, see Policy Enforcement.

This section provides an overview of the following topics:

Trigger Applications

The Supplementary Services Gateway uses the standard HTTP request/response method when communicating with trigger applications (or customer applications), which generally resides at the customer premises. Trigger applications send requests to the Supplementary Services Gateway server to initiate outbound-call sessions. The requests are validated and stored before processing and the Supplementary Services Gateway sends final call results (success or failure) to the trigger applications through notification URLs (which are part of the call initiation requests sent by the trigger application).

Supplementary Services Gateway Interfaces

The Supplementary Services Gateway performs outbound-call initiation through the following interfaces:

  • Customer Application interface Enables the Supplementary Services Gateway to receive customer requests and manage the initiation of outbound calls with the help of SIP Server. SIP Server initiates two call legs and bridges them to establish a media path between the Media Control Platform (through the Resource Manager) and the external party.

Through this interface the Supplementary Services Gateway acts as an HTTP Server, collecting HTTP call requests from trigger applications, providing authentication by using HTTPS, validating the input data, and storing it in its external database. If the customer input is not sufficient to make a call or if data is missing, the Supplementary Services Gateway returns an error to the trigger application.

  • T-Lib Client interface—Enables the Supplementary Services Gateway to batch and initiate requests to SIP Server to establish third-party call control from the Media Control Platform to external parties or destinations.
  • HTTP Client interface—Enables the Supplementary Services Gateway to post results to a notification URL at the logical conclusion of a call.

Supplementary Services Gateway Services

The Supplementary Services Gateway can establish instances of outbound-call sessions across multiple instances of the Media Control Platform. The interfaces that are used by the Supplementary Services Gateway rely on the Resource Manager to distribute the outbound-call-processing load across multiple Media Control Platforms.

Gateway Services

  • In a hosted environment, third-party clients accessing the Supplementary Services Gateway do not require direct access to the Media Control Platform or other GVP components because the Supplementary Services Gateway provides an external interface for outbound-call-processing requests. Multiple Supplementary Services Gateways can reside between private customer networks and GVP.

Tenant Services

  • The Supplementary Services Gateway supports outbound-call requests from tenants in the following scenarios:
    • Multiple requests for a VoiceXML application from multiple trigger applications
    • Requests for multiple VoiceXML applications from a trigger application
    • Requests for multiple VoiceXML applications from multiple trigger applications

Supplementary Services Gateway Functions

The Supplementary Services Gateway performs the following functions:

  • Outbound-call initiation Outbound calls are initiated and VoiceXML applications provide IVR functions for end users.
  • Outbound-call triggers Trigger applications use HTTP POST requests to initiate call triggers for single and bulk requests to generate outbound calls. Initial and reattempt outbound-call triggers are queued and prioritized.
  • Batched and queued requests Batches of outbound session creation requests are accepted and executed by using application-specified limits on concurrent port usage and launch rates.
  • Persistent call trigger data Call trigger data is stored persistently in the Supplementary Services Gateways external database until ports are available. Storing the data persistently prevents data loss where multiple restarts may occur. Any outbound call that is attempted but not completed when the Supplementary Services Gateway restarts is reinstated as a new call, or removed from database, based on the configuration, when the server is fully operational again.
  • Result notification for requests. The trigger application is notified by using HTTP URLs when an outbound call succeeds or fails. Notifications are sent after the call has been successfully established, the TTL has expired, or after a call fails the specified number of attempts.
  • Cancellation of outbound requests. Trigger applications can use HTTP POST or DELETE to cancel requests for calls that are not yet initiated. The Request ID that is returned to the trigger application for the create request and tenant ID is specified in the cancel request.
  • Status of outbound requests. Trigger applications use HTTP GET or POST requests to obtain the status of a request stored in the Supplementary Services Gateways external database. The Request ID that is returned to the trigger application for the create request and tenant ID is specified in the query request.
  • Call Progress Detection (CPD) results. The Supplementary Services Gateway can use either a media gateway or the Media Server as a CPD provider. The trigger application can also specify that CPD is not required for a call. The Supplementary Services Gateway, based on the parameters provided in the TA,controls whether CPD is started either with the first media packet received or after the call is connected and can specify whether the IVR should be started for specific CPD results.
  • HTTP access from IPv6 networks. The Supplementary Services Gateway supports HTTP access from IPv6 networks for all requests.
  • Connectivity to SIP Server on IPv6 networks. The Supplementary Services Gateway supports connectivity to SIP Server on IPv6 networks for T-Lib activities.
  • SNMP MIBs and trap generation are supported in the same way as all other (monitored) GVP components.

For more information about how the Supplementary Services Gateway performs its functions, see How the Supplementary Services Gateway Works.

This page was last edited on January 13, 2015, at 23:54.
Comments or questions about this documentation? Contact us for support!