GVP Call Flows

This topic describes some sample basic Genesys Voice Platform (GVP) call flows.

• Basic Inbound-Call Flow
• Basic Outbound-Call Flow
• Basic CTI Call Flow (Inbound)
• Basic CTI Connector/ICM Call Flows (Inbound)
  • Cisco ICM Type 8 Deployment Call Flow
  • SCI Transfer Call Flow
  • Inbound Call Using CRI
• Basic PSTN Call Flow (Inbound)
• Basic PSTN Call Flows (Outbound)
  • Initiated by the Supplementary Services Gateway
  • Resulting From an Inbound Call Transfer

Basic Inbound-Call Flow

The figure below illustrates how GVP handles a typical inbound call:

[+] Basic Inbound-Call Flow Description

1. A call comes in to the Session Initiation Protocol (SIP) Server from an external source through a third-party media gateway.
2. The SIP Server passes the call to the VP Resource Manager (SIP INVITE).
3. The Resource Manager determines what to do with the call. If the Resource Manager accepts the call, it matches the call to an Interactive Voice Response (IVR) Profile and selects a resource. For more information about how the Resource Manager selects services and resources, and how it enforces policies, see How the How the Resource Manager Works.
4. The Resource Manager sends the call to a Media Control Platform or Call Control Platform resource (SIP INVITE). When it forwards requests to resources, the Resource Manager inserts additional SIP headers or parameters, as required by the service prerequisites, service parameters, and policies that have been configured for the IVR Profile. For more information, see Service-Request Modification.
5. The Fetching Module for that Media Control Platform or Call Control Platform resource fetches the required Voice Extensible Markup Language (VoiceXML) or Call Control XML (CCXML) page from the application server (file, Hypertext Transfer Protocol (HTTP), or Secure HTTP (HTTPS) request).
6. The VoiceXML Interpreter (Next Generation Interpreter [NGI] or GVP Interpreter [GVPi]) on the Media Control Platform or CCXML Interpreter (CCXMLI) on the Call Control Platform interprets the page and executes the application (VoiceXML or CCXML).
7. Depending on the application, the Media Control Platform or Call Control Platform requests (through the Resource Manager) and uses additional services:
   • For automatic speech recognition (ASR) or text-to-speech (TTS) services, the Media Control Platform communicates with the third-party speech application server by using Media Resource Control Protocol (MRCPv1 or MRCPv2).
   • If the Call Control Platform requires conference or audio play/record services, it obtains them from a Media Control Platform resource.
   The Media Control Platform or Call Control Platform sends all requests for services from other GVP components through the Resource Manager (SIP or Network Announcement [NETANN]).
8. The Real-time Transport Protocol (RTP) media path is established between the Media Control Platform and the SIP end user in this example, the originating caller through the media gateway.
9. The Resource Manager ends the call when one of the parties (the SIP end user, the Media Control Platform, or the Call Control Platform) disconnects, or when the call is transferred out of GVP (SIP BYE or REFER).

Basic Outbound-Call Flow

The figure below illustrates how GVP handles a typical outbound call (without CPD).

[+] Basic Outbound-Call Flow Description

Call Triggers

1. Trigger applications send HTTP POST or GET requests to the Supplementary Services Gateway (SSG) to request outbound-call initiation. The request includes a Token that uniquely identifies the request.
   
   

   Validation

2. The Supplementary Services Gateway performs validation on each incoming request:
   • It checks the HTTP POST query string for the TenantName, for example, <host>:9800/SSG?TenantName=<Name of the Tenant> and rejects the request if the TenantName is not present.
   • It checks to ensure that all mandatory parameters are included in the CreateRequest part (Token, IVRProfileName, Telnum, and NotificationURL) and that it adheres to the defined XML schema.
   • After validation, a RequestID is created for each CreateRequest and sent back to the trigger application in the HTTP response.

   Success or Failure Response

3. The Supplementary Services Gateway sends a 200 OK single or bulk response to the trigger application (depending on the whether the POST is a single or bulk request).
   • If request validation is successful, the Supplementary Services Gateway generates a unique (internal) ID or RequestID for each CreateRequest and inserts the request into the database. The RequestID and Token are passed back to the trigger application in the 200 OK response with a SUCCESS ResponseType.
   • If validation fails when request is being parsed or when it is inserted into the database, the Supplementary Services Gateway inserts a FAILURE ResponseType in the 200 OK response.
   • If parsing or validation of bulk POST requests fails, the entire request fails and the 200 OK response contains a ReasonCode and Reason (or failure description).
   • If parsing or validation of bulk POST requests succeed, but an operational error occurs for example, the insertion of a specific record into the database fails the 200 OK response contains a combination of SUCCESS and FAILURE ResponseTypes and the Tokens for each request.

   Request to SIP Server

4. After the Supplementary Services Gateway accepts the request, it parses the XML data in the body of the POST request, and extracts the requests and its parameters.
   • It invokes a TMakePredictiveCall T-Lib request to initiate the outbound call through SIP Server.
5. SIP Server establishes two call legs; one to the Media Control Platform through the Resource Manager and one to the external party.
   • It sends a SIP INVITE request to the Media Control Platform through the Resource Manager and a SIP INVITE request to the external party.
6. Both the Resource Manager and external party send a 200 OK response.

   Call Establishment

7. SIP Server sends an acknowledgement (ACK) to the Resource Manager and the external party.
   • The two call legs are bridged and the RTP session begins between the Media Server module of the Media Control Platform and the external party.
   • Simultaneously, SIP Server sends a message to the Supplementary Services Gateway indicating the call legs have been established and bridged (EventEstablished with a CallStateOK extension).
8. The Supplementary Services Gateway sends a request to SIP Server (TApplyTreatment) to execute the prepared dialog with the Media Server (Media Control Platform).
9. SIP Server then sends an INFO MSML message to the Media Server (Media Control Platform through Resource Manager).
   • It then sends a message back to the Supplementary Services Gateway to indicate that the call treatment has been applied (TreatmentApplied event).
10. At the end of the call the Resource Manager (for the Media Control Platform) responds with 200 OK and BYE messages to the SIP Server.
    • SIP Server sends 200 OK and BYE messages to the external party.
    • SIP Server sends an EventReleased message to the Supplementary Services Gateway.

    Call Treatment Applied

11. After receiving the TreatmentApplied event from SIP Server, the Supplementary Services Gateway marks the call as a success in the database. Later, when the database records are cleaned up, the Supplementary Services Gateway sends this information to the trigger application in a Notification URL, along with the Token, RequestID, TenantName, IVRProfileName, CallUUID (unique ID that is generated by SIP Server), and other details.

Basic CTI Call Flow (Inbound)

The figure below illustrates how GVP handles an inbound call through IVR server while using the CTI Connector.

[+] Basic CTI Call Flow (Inbound) Description

1. A call comes in to the SIP Server from an external source through a third-party media gateway.
2. The SIP Server passes the call to the VP Resource Manager (SIP INVITE).
3. The Resource Manager checks the SIP INVITE header. If the request is from a resource that is provisioned to be managed by the Resource Manager, the call is accepted, and a new session is created.
4. If the resource is a gateway resource that has the use-cti parameter set to 1, the Resource Manager routes the call to a CTI Connector Resource group and selects a tenant or owner for the gateway resource. The Resource Manager forwards the request to a member of the CTI Connector group based on its load balancing scheme and adds the gvp.rm.cti-call=1 parameter to the X-Genesys-GVP-Session-ID header.
5. When the CTI Connector receives the SIP INVITE from Resource Manager, the CTI Connector (acting as a B2BUA) fetches ANI, DNIS, CONNID, and UUID from the IVR Server.
6. The CTI Connector sends a new SIP INVITE to the Resource Manager with extension SIP header configured with:
   • the user-part of the Request-URI set to DNIS
   • the user-part of the FROM header set to ANI
   • the user-part of the TO header set to DNIS
7. The Resource Manager searches the SIP INVITE from the CTI Connector based on the sip-header-for-cti-dnis parameter and maps the call to an IVR Profile, adding the gvp.rm.tenant-id parameter to the SIP header.
8. The Resource Manager sends the call to a Media Control Platform or Call Control Platform resource (SIP INVITE).
9. The call proceeds as in Steps 4 to 8 in Basic Inbound-Call Flow. In addition to the ASR, TTF, conference or audio play/record services described in that procedure's Step 7, the Media Control Platform or Call Control Platform can request and use additional CTI Connector services. The NGI voice application uses send or receive extensions to invoke the SIP INFO message between the MCP and the CTI Connector through Resource Manager to request the following mid-call features:
   • GetData
   • SetData (Add and Replace)
   • DeleteData (DeleteOne and DeleteAll)
   • GetStat
   • PeekStat
   • AccessNumGet
   Tip

   The send and receive extensions are used by NGI voice applications only (not by GVPi voice applications).

   Three transfer types are supported using CTI Blind, Bridge, or CTI transfer. The NGI voice application sends a request to transfer to a route DN to the CTI Connector with the Request URI parameter RouteRequest=1:

   • If the request is for a Blind transfer (SIP REFER), the VoiceXML session is terminated when the transfer to a route DN is successful.
   • If the request is for a Bridge transfer (SIP INVITE), the outbound-call leg from the Media Control Platform to the route DN is active until a connection to an available agent is complete.
10. The Resource Manager ends the call when one of the parties (the SIP end-user, the Media Control Platform, the Call Control Platform, or the CTI Connector) disconnects (SIP BYE) or when the call is transferred out of GVP (SIP REFER).
11. If the CTI Connector initiates the SIP BYE message, the Resource Manager passes interaction data back to the Media Control Platform in the BYE message. The Resource Manager then processes a custom SIP header, X-Genesys-GVP-CDR, and passes it on to the Reporting Server in the final CDR for the call.

Basic CTI Connector/ICM Call Flows (Inbound)

The call flows in this section illustrate how the CTI Connector and Cisco Intelligent Contact Management (ICM) framework handle call setup through ICM's Service Control Interface (SCI) and Call Routing Interface (CRI) for an inbound call.

Cisco ICM Type 8 Deployment Call Flow

This section describes how GVP handles Cisco ICM Type 8 deployment calls, and does not include a diagram:

[+] Cisco ICM Type 8 Deployment Call Flow Description

1. The RM receives a call but does not fetch the IVR profile, because the use-cti parameter is set to 1. Instead, the RM forwards the call to the CTI Connector.
2. Upon receiving a SIP_INVITE message from the RM, the CTI Connector prepares a REQUEST_INSTRUCTION message, because the enablePreRouting parameter is set to true.
3. The CTI Connector sends the Translation Route Number received as a user-part in the TO header of the SIP INVITE message in the DNIS field of the REQUEST_INSTRUCTION message to ICM.
4. When the RUN_SCRIPT_REQ message is received from ICM for the first time, the CTI Connector sets the user-part of the TO header in the INVITE message to RM with either ScriptID or Call Variable value, depending on the DNISIndicator parameter's value.
5. The RM fetches the IVR Profile and initiates a NETANN dialog toward MCP to execute the appropriate VXML application, and passes an empty ScriptID to it. When the VXML application completes execution, the MCP disconnects the call.
6. ICM optionally may send subsequent RUN_SCRIPT_REQUEST messages. For each of these subsequent messages, CTI Connector initiates a NETANN dialog to RM in the same IVR profile context. Since RM already knows about the IVR Profile, it replaces the SCRIPTURL with the initial-page-url that is configured in the IVR profile, and forwards it to the MCP. This continues till the caller disconnect the call, or all the scripts have executed from the ICM point of view.

SCI Transfer Call Flow

The figure below depicts a basic inbound call transfer through ICM s SCI interface.

[+] SCI Transfer Call Flow Description

1. A call comes in to the SIP Server from an external source through a third-party media gateway.
2. The SIP Server passes the call to the Resource Manager using a SIP INVITE message.
3. The Resource Manager checks the header in the INVITE message to determine if the request is from a resource that is provisioned to be managed by the Resource Manager. If it is, the call is accepted and a new session is created.
4. If the resource is a gateway resource that has the use-cti configuration option set to 2, the Resource Manager routes the call to a CTI Connector resource group and selects a tenant or owner for the gateway resource. The Resource Manager forwards the request to a resource in the CTI Connector group, based on its load balancing scheme, and then:
   • Adds the gvp.rm.cti-call=1 option to the X-Genesys-GVP-Session-ID header.
   • Adds all of the CTI-related service parameters that are configured in the IVR Profile. (For example, cti.icm.enableBridgeXfer, cti.icm.ScriptMapping.)
   • Adds the gvp-tenant-id=<tenant name> in the Request-URI parameter.
     
   Where <tenant name> is the name of the tenant that to which the call belongs.)
5. When the CTI Connector receives the INVITE message from Resource Manager, the CTI Connector (acting as a B2BUA) sends NewCall to the ICM and waits for its instructions, either to execute the scripts, transfer the call to an agent, or release the call.
6. After receiving RUN_SCRIPT_REQ (which includes the scriptID) from the ICM:
7. The CTI Connector generates a new SIP dialog towards the Resource Manager.
8. The Resource Manager sends the call to the Media Control Platform or Call Control Platform resource using an INVITE message.
   • The call proceeds as in Steps 4 to 8 in Basic Inbound-Call Flow.
   • When script execution is completed, the result (either success or failure) is sent back to the ICM in RUN_SCRIPT_RESULT. The result might also include Caller Entered Digits (CED), ICM call variables, or ECC variables.
   • The ICM might have multiple script execution requests before it send a request to transfer the call.
9. When all the scripts are executed, the ICM sends CONNECT to the CTI Connector to initiate the transfer by returning the label and by specifying the type of transfer:
   • By default, the CTI Connector invokes a BLIND transfer to connect the caller to an agent by using the REFER method on the initial caller leg.
   • In the instruction, the ICM indicates that the BRIDGE transfer is to be used.
   Important

   Starting from 8.5.160.73, CTI Connector provides the ability to override the transfer destination of a CONNECT message in REFER scenarios on ICM. Two parameters control this behavior:

   • cti.TransferToFixedAgent, in the gvp.service-parameters section of the IVR Profile. Set to true for CTIC to disregard the CONNECT label and use the fixed label. (Default is false.)
   • cti.FixedAgent, in the gvp.service-parameters section of the IVR Profile. Must contain the fixed destination for the transfer (a telephone number of the appropriate length).

   The actual destination specified in the CONNECT message label will be passed as a header named “X-Genesys-ICM-Connect-Label” in the INVITE message to SIP Server.
10. The CTI Connector then initiates a new SIP dialog towards an agent (through the Resource Manager) and bridges it with the caller leg.
    • The CTI Connector checks the IVR Profile s cti.icm.enableBridgeXfer configuration option value to identify the type of transfer. If the configuration option is enabled, the CTI Connector uses the BRIDGE transfer, otherwise it uses the BLIND transfer.
11. The Resource Manager ends the call when either the SIP end-user, Media Control Platform, or CTI Connector disconnects using a BYE message, or when the call is transferred out of GVP using a REFER message.
12. After the call is terminated:
    • The CTI Connector informs the ICM of call termination.
    • The CTI Connector passes the call disposition, (COMPLETED_IN_IVR, TRANSFERRED_TO_AGENT, or ABANDONED_IN_QUEUE) in the X-Genesys-GVP-CDR custom SIP header to Resource Manager. The Resource Manager then passes it to the Reporting Server in the final CDR for the call.

Inbound Call Using CRI

The figure below depicts a basic inbound call transfer through ICM s CRI interface.

[+] Inbound Call Using CRI Description

1. A call comes in to the SIP Server from an external source through a third-party media gateway.
2. The SIP Server passes the call to the Resource Manager using a SIP INVITE message.
3. The Resource Manager checks the header in the INVITE message to determine if the request is from a resource that is provisioned to be managed by the Resource Manager. If it is, the call is accepted and a new session is created.
4. If the resource is a gateway resource that has the use-cti configuration option set to 2, the Resource Manager routes the call to a CTI Connector resource group and selects a tenant or owner for the gateway resource. The Resource Manager forwards the request to a resource in the CTI Connector group, based on its load balancing scheme, and then:
   • Adds the gvp.rm.cti-call=1 option to the X-Genesys-GVP-Session-ID header.
   • Adds all of the CTI-related service parameters that are configured in the IVR Profile. (For example, cti.icm.enableBridgeXfer, cti.icm.ScriptMapping.)
   • Adds the gvp-tenant-id=<tenant name> in the Request-URI parameter.
     
   Where <tenant name> is the name of the tenant that to which the call belongs.)
5. When the CTI Connector receives the SIP INVITE from the Resource Manager (acting as a B2BUA) it informs the ICM that a new call has arrived and starts playing the VoiceXML application that is configured in the IVR Profile, as follows:
   • CTI Connector generates a new SIP dialog towards Resource Manager.
   • The Resource Manager sends the call to a Media Control Platform using a SIP INVITE message.
   • The call proceeds as in Steps 4 to 8 in Basic Inbound-Call Flow.
   • The VoiceXML application can send Caller Entered Digits (CED), ICM call variables, or ECC variables to CTI Connector that are passed to the ICM.
6. After the VoiceXML application plays the IVR, it sends a requests to the ICM and through a ROUTE request, determines which agent receives the call.
7. The NGI voice application sends a TRANSFER request to the CTI Connector with the ROUTE request in the Request-URI parameter set to 1. The CTI Connector interacts with the ICM to obtain the final destination label, and determines the next step, as follows:
   • If the request is made using a SIP REFER message, the CTI Connector initiates a BLIND transfer using the REFER method on the caller leg.
   • If the request is made using a SIP INVITE message, the CTI Connector initiates a new SIP dialog to the agent and bridges the call with it.
8. The Resource Manager ends the call when either the SIP end-user, Media Control Platform, or CTI Connector disconnects using a BYE message, or when the call is transferred out of GVP using a REFER message.
9. After the call is terminated:
   • The CTI Connector informs the ICM of call termination.
   • The CTI Connector passes the call disposition, (COMPLETED_IN_IVR, TRANSFERRED_TO_AGENT, or ABANDONED_IN_QUEUE) in the X-Genesys-GVP-CDR custom SIP header to Resource Manager. The Resource Manager then passes it to the Reporting Server in the final CDR for the call.

Basic PSTN Call Flow (Inbound)

The figure below illustrates how GVP handles a typical inbound call from the PSTN network.

[+] Basic PSTN Call Flow (Inbound) Description

1. A call comes in from an external source through the TDM network, and The PSTN Connector detects an inbound-call trigger (through the Dialogic port).
2. The PSTN Connector converts the TDM signals to a SIP INVITE message adding the X-Genesys-GVP-IVR-port (used by the CTI Connector), and X-Genesys-GVP-PSTNC-DBID custom headers before sending it to SIP Server.
   • If the prefix parameter is configured for the PSTN Connector Trunk DN, then PSTN Connector also sends the X-Genesys-GVP-Trunk-Prefix custom header in the INVITE message.
   The RTP prefill information is also added in the SDP to enable faster-than-real-time RTP from the Media Control Platform.
3. SIP Server passes the request to the Resource Manager (SIP INVITE).
4. When the Resource Manager receives the INVITE request, it passes it to the Media Control Platform.
5. The call proceeds as in Steps 4 to 9 in Basic Inbound-Call Flow.

Basic PSTN Call Flows (Outbound)

This section describes two basic outbound PSTN call flows.

Initiated by the Supplementary Services Gateway

The figure below illustrates how GVP handles a typical outbound call initiated by the Supplementary Services Gateway to the PSTN network:

[+] Initiated by the Supplementary Services Gateway Description

1. The Supplementary Services Gateway triggers an outbound call through the TLib interface to SIP Server.
2. SIP Server sends a request for an outbound call to both the PSTN Connector and the Media Control Platform (through the Resource Manager). In this case SIP Server acts as a third-party call controller.
3. When the Media Control Platform receives the request for outbound-call initiation, it sends a SIP 200 OK message (along with SDP negotiation information) to the Resource Manager.
4. SIP Server passes the SDP negotiation information (copied from the 200 OK message) in an INVITE message to the PSTN Connector.
5. The PSTN Connector sends a SIP 100 Trying message to the SIP Server to indicate that call initiation is in progress
6. The PSTN Connector extracts the ANI from the FROM header of the INVITE message. If the ANI is not specified, PSTNConnector is used as the default ANI.
7. When the TDM call is in the alerting state, the PSTN Connector sends a 180 Ringing message back to the SIP Server.
8. When the call is established between the PSTN Connector and the destination party, the PSTN Connector initiates the media session with the Media Control Platform by sending a SIP 200 OK message, including an X-Genesys-GVP-IVR-port custom header. If the PSTN Connector accepts the SDP negotiation information from the initial INVITE, the 200 OK contains SDP in the reply.
9. If the PSTN Connector is unable to complete the call setup, it sends a SIP error code in the response to indicate the cause of the failure. For a complete list of SIP error codes, see the GVP 8.5 User's Guide.
10. The Media Control Platform sends a SIP ACK message (through the Resource Manager) to the PSTN Connector and the Media Control Platform, and the two-way media session is established.
11. If the PSTN caller hangs up the session terminates and the Media Control Platform sends a SIP BYE message (through the Resource Manager) to the PSTN Connector.
12. The call is dropped and the Dialogic port is cleared on the PSTN side. The PSTN Connector sends a SIP 200 OK to the Media Control Platform and the call is released.

Resulting From an Inbound Call Transfer

The figure below describes how GVP handles a typical outbound call to the PSTN network resulting from the transfer of an inbound call:

[+] Resulting From an Inbound Call Transfer Description

1. A call comes in from an external source through the TDM network and The PSTN Connector detects an inbound call trigger (through the Dialogic port).
2. The call proceeds as in Steps 2 to 4 in Basic PSTN Call Flow (Inbound).
3. The Resource Manager sends the call to a Media Control Platform or Call Control Platform resource (SIP INVITE). When it forwards requests to resources, the Resource Manager inserts additional SIP headers or parameters, as required by the service prerequisites, service parameters, and policies that have been configured for the IVR Profile.
4. The call proceeds as in Steps 5 to 9 in Basic Inbound-Call Flow.
5. When the Media Control Platform transfers the call, it generates an outbound INVITE (or REFER) message to the Resource Manager, passing on the X-Genesys-Trunk-Prefix header that was received in the inbound INVITE message.
6. The Resource Manager applies the prefix to the user part of the Request URI and the TO header of the outbound INVITE message (or to the Refer-To header for the outbound REFER message), and sends it to SIP Server.
7. SIP Server searches all available Trunks DNs to find the PSTN Connector DN that best matches the prefix to ensure the chosen PSTN Connector is the same one that initiated the inbound call.
   • If the value of the replace-prefix option is set to <empty string> in the Trunk DN, SIP Server strips the prefix from the INVITE message before sending it to the PSTN Connector.
8. The call can proceed in one of two ways, depending on the type of transfer:
   1. For bridge transfers (INVITE from the Media Control Platform):
      • The PSTN Connector performs route-based dialing, or port-based dialing, depending on how the VoiceXML application is configured, and pass on an Authorization code if this information is specified in the value of the X-Genesys-GVP-PSTNC-Data custom SIP header such as, Route=n;PortDlgc=x-y;AuthCode=<code>.
      • The call proceeds as in Steps 5 to 10 in the Initiated by the Supplementary Services Gateway Call Flow.
   2. For blind transfers (REFER from the Media Control Platform):
      • The PSTN Connector initiates the appropriate blind transfer on the network side and both call legs (TDM and SIP) are terminated.