Jump to: navigation, search

How the Call Control Platform Works

Operational Overview

The Call Control Platform receives requests for call-control or conference services for incoming connections from the Resource Manager, in the form of SIP INVITE messages. The platform can conference, transfer, or redirect calls by using other kinds of SIP messages Transfers. The platform can also initiate outbound calls by sending SIP INVITE requests either through the Resource Manager or directly to the destination.

The platform can also receive requests for CCXML sessions directly from an external HTTP client.

For more detailed information, see the 8.5 CCXML Reference.

Incoming Connections

The Call Control Platform handles service requests for incoming connections in a typical call flow, as follows:

  1. The Call Control Platform receives a SIP INVITE from the Resource Manager.
  2. The Call Control Platform assigns a device profile to the connection. For more information about device profiles, see Device Profiles.
  3. The Call Control Platform can accept, reject, join, or redirect the connection. Configuration options enable you to customize some of the SIP responses that the Call Control Platform sends to the Resource Manager for the events. For more information, see the section about customizing SIP responses in the GVP 8.5 User's Guide.
  4. For connections that it accepts, the Call Control Platform sends an HTTP/HTTPS or file retrieval request to the Fetching Module to fetch the initial page.
    • Because the Resource Manager has modified the SIP request by inserting service prerequisites for the IVR Profile, the SIP Request-URI includes a CCXML parameter, which specifies the URI of the initial page of the required CCXML application.
    • If the Request-URI from the Resource Manager does not include an initial page URI, or if the Call Control Platform is being used in a deployment without the Resource Manager, the Call Control Platform uses the default that has been configured for the platform (in the ccpccxml.default_uri configuration option).
    • Call Control Platform HTTP requests comply with HTTP 1.1. For HTTPS, the Call Control Platform supports HTTP over Secure Socket Layer (SSL) 3.0 and HTTP over TLS.
    • The HTTP/HTTPS fetch method (get or post) depends on whether the method parameter was specified in the SIP Request-URI. The default is get.
    • The following parameters are also supported in the HTTP/HTTPS fetch:
      • namelist—A list of ECMAScript variables whose values are submitted as part of the request.
      • enctype—The encoding type to be used for namelist data, if the method is post. The only supported value is application/x-www-form-urlencoded.

      For both get and post methods, namelist variables must be encoded in the URI query string in the form url-encoded format (as described in the HTML 4.01 specification). If the get method is used, the namelist variables are appended after a question mark (?).

  5. The CCXMLI compiles and interprets the initial page, and all subsequent pages, so that the Call Control Platform can execute the application.
    • A CCXML page may transition to another page as it is executed, but only one page is executed at a time.
    • The CCXML session may create and interact with other entities:
      • Connections (other SIP sessions)
      • Dialogs (VoiceXML sessions)
      • Conferences
      • Other CCXML sessions
    • To improve performance, the Call Control Platform enables the root page of the initial page to be cached. Caching is not relevant for the initial page itself, or for other pages, because CCXML application pages are session-specific. For more information about how the Fetching Module caches pages, see Caching.
    • The Call Control Platform supports receiving DTMF events in SIP INFO messages, and it propagates the events and data to the CCXML application and other connections.
  6. The Call Control Platform uses the Media Control Platform to provide bridging, conference, and transcoding services. It may also perform implicit conferencing and transcoding if the endpoints of a connection do not have the required bridging capabilities or support the required codecs. The Call Control Platform obtains these services by sending SIP requests through the Resource Manager. Dialog-initiated transfers between CCXML sessions, or between CCXML and VoiceXML sessions, are application driven, with the SIP messaging going through the Resource Manager in SIP INFO messages. For more information about transfers, see Transfers.
  7. For each CCXML session, the Call Control Platform generates call-detail records, which it sends to the Reporting Server. For information about the CDR attributes, see CDR Reporting.
  8. For each CCXML session, the Call Control Platform sends logs and metrics (CCXML application event logs) to the log sinks and, from there, to the Reporting Server. For more information about metrics, see Metrics. For descriptions of the Call Control Platform metrics, see the GVP 8.5 Metrics Reference Guide. In GVP 8.1 and above the Call Control Platform supports Operational Reporting (OR).
  9. If it is configured to do so (see the description of the ccxmli.debug.data.* and ccxmli.platform.save.* parameters), the Call Control Platform captures fetch data for CCXML and ECMAScript files, to aid in debugging CCXML applications.

    Outgoing Connections

    The Call Control Platform can place outbound calls by starting a new CCXML session, if it receives a session creation request directly from an HTTP client. Alternatively, it can place an outbound call within the context of an existing session.

    The CCXML application uses the <createcall> tag to create the connection, and it specifies the destination of the call (in the dest attribute) as a SIP URI. The value of the dest attribute is used in the Request URI that the Call Control Platform sends to the Resource Manager to place the call. The Resource Manager, in turn, forwards the request either to another SIP Proxy that has been configured in a route set for the Call Control Platform, or to the SIP Server.

    You can override the default outbound proxy configured in the route set by specifying an outboundproxy hint in the CCXML <createcall> tag.

    If an outbound call (connection or conference leg) is not joined to any call and the user does not set the caller information, the caller URI is configurable.

    Device Profiles

    The Call Control Platform interacts with a variety of SIP devices, all of which have different characteristics and features. The concept of a device profile enables the Call Control Platform to interact with a wide range of devices, even though they might differ in the way they support SIP.

    The device profile defines a number of properties that describe the SIP and SDP capabilities of a class of devices. The Call Control Platform uses a device profile when it performs call-control operations (for example, <join> and <accept>). The Call Control Platform assigns a device profile to any SIP device with which it interacts. The properties of the device profile then govern how the Call Control Platform interacts with the SIP device.

    Device-Profile Configuration File

    The properties of the various device profiles are defined in a text file in the Call Control Platform config directory (<Call Control Platform Installation Directory>\config\ccpccxml_provision.dat). For more information about the properties that are defined for CCXML device profiles, see the section about configuring device profiles in the GVP 8.5 User's Guide.

    Assigning Device Profiles

    The Call Control Platform assigns device profiles, as follows:

    • Incoming connections—The Call Control Platform tries to match the SIP header from the incoming SIP INVITE with the value of the SIP Header Name property that is defined in the device profile configuration file, using the order of precedence that is also specified in the configuration file. (By default, the SIP header that the platform looks for is User-Agent.) If it cannot match the SIP header, the Call Control Platform uses the Default Inbound profile that has been provisioned (see Default Device Profiles below).
    • Outbound connections, dialogs, and conferences—The Call Control Platform matches CCXML hints with the value of the Device Profile Name property that is defined in the device profile configuration file. If it cannot match the hint, the Call Control Platform uses the Default Outbound, Default Dialog, or Default Conference profile that has been provisioned (see Default Device Profiles below).

    Default Device Profiles

    By default, VP Call Control Platform 8.5 is provisioned with the following device profiles for SIP devices, by order of precedence:

    • Dialogic Media Gateway
    • Cisco Gateway
    • Audiocodes Gateway
    • Convedia Media Server
    • X-Lite
    • Brooktrout Snowshore
    • GVP MCP
    • Audiocodes MP 104
    • eyeBeam
    • Kapanga
    • Default Inbound
    • Default Outbound
    • Default Conference
    • Default Dialog

    For the property values that have been defined for the preprovisioned device profiles, see the GVP 8.5 User's Guide.

    If your deployment uses SIP devices that are not adequately represented by the default device profiles, you must either provision additional device profiles or modify an existing device profile. For more information, see the section about configuring device profiles in the GVP 8.5 User's Guide.

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