VoIP Dialing Modes

Outbound Contact supports the following VoIP dialing modes: Predictive, Progressive, Predictive with seizing, Progressive with seizing, Power GVP, and Progressive GVP. In these VoIP dialing modes, the call control/flow is as follows:

• The call is dialed from the Trunk Group DN.
• OCS controls the call.
• In Transfer modes, OCS transfers the call to VTD.
• In ASM modes, OCS bridges the call with engaging call.
• In GVP modes, OCS also controls the Treatment VoiceXML application.

Note:

If a Campaign Group is not Outbound-VoIP-ready, these dialing modes function like the non-VoIP dialing modes (with the exception of the Progressive GVP mode which is not available in non-VoIP dialing modes). For information on how OCS works with VoiceXML applications in these modes, see VoiceXML Applications. For information on how OCS handles Apply to Call treatments in these modes, see Apply to Call Treatments. For more information on Outbound in a VoIP environment, see OutboundVoIPDeployment.

Progressive, Predictive, Progressive with Seizing, and Predictive with Seizing Dialing Modes

When a Campaign Group/environment is Outbound-VoIP-ready (see VoIP Environment Configuration), these modes function like their standard, non-VoIP counterparts, but in a VoIP environment with its associated components. See their associated descriptions described earlier.

Power GVP Dialing Mode

The Power GVP dialing mode uses SIP Server to dial outbound calls, to detect call results, and to further process successfully connected calls. This Power GVP mode dials calls so that the number of calls in progress equals the Max Queue Size setting of the Campaign Group. Like the non-VoIP usage, this dialing mode can be very effective when running "agent-less" campaigns, because it enables you to use custom-created VoiceXML scripts to automate call processing and allow for self-service of the contacted outbound customers. See Genesys Voice Platform for more information.

Progressive GVP Dialing Mode

The Progressive GVP dialing mode dials calls from a Calling List when a GVP port is available. The dialing pace is calculated based on port availability; so this mode dials calls equal to the number of Call Progress Detection ports configured for the Campaign Group. This dialing mode requires SIP Server for placing outbound calls, instead of T-Server, and uses GVP Voice XML applications for call processing.

Note:

In this dialing mode, the predictive algorithm does not calculate the dialing rate based on agent availability. Instead, it calculates the number of dial requests to maintain the total number of customer calls in any state (for example, dialing or established) that is not greater than the number of ports available for the Campaign Group, in accordance with Resources assignment (see Resources). Warning: OCS considers a port available when it is notified as such by SIP Server.

VoiceXML Applications

When running Outbound Contact using the VoIP dialing modes, OCS identifies which VoiceXML application that GVP should start by including the URI of that application in the TApplyTreatment function.

• (All call results) OCS determines the URI based on the value set in the initial-page-url option of the Voice Platform Profile configuration object and whose DBID is specified in the IVR Profile ID attribute for the Campaign Group.
• (Answering Machine call results only) If you want to use a dedicated VoiceXML application for Answering Machine call results, OCS determines the URI based on the value set in the am-initial-url option of the Voice Platform Profile configuration object and which is associated with the Campaign Group. If a URI is not specified in the am-initial-url option, OCS uses the URI set by the initial-page-url option.

Note:

The URI Answering Machine VoiceXML application is never passed in ivr-profile-id pair to SIP Server, which means that it cannot be prefetched by GVP.

In addition, for Answering Machine Detection call results, OCS can instruct GVP on how to handle beep detection. The am-beep-detection option specifies whether GVP is forced to detect an answering machine beep before starting the VoiceXML application. This information is passed on to GVP in the Extensions KV list of the same TApplyTreament function.

Note:

For information on the initial-page-url and am-initial-url options, see the Genesys Voice Platform 8.1 User's Guide. For information on the IVR Profile ID attribute for the Campaign Group, see IVR Profile.

Apply to Call Treatments

In a VoIP environment, after an outbound call is established on the Trunk Group DN, OCS can apply Transfer/Connect or Drop treatments to the call. These treatments—which you configure by using the Treatment configuration object with an Apply to Call action—always have a higher priority than VoiceXML application call handling.

This approach is helpful in the following scenarios:

• A Connect treatment is configured for an Answering Machine call result. A Destination DN is also configured. OCS receives EventEstablished with an AM call state. Despite the configured IVR Profile ID, OCS issues RequestSingleStepTransfer to the Destination DN and completes call/record processing.
• A Drop treatment is configured for an Answering Machine call result. OCS receives EventEstablished with an AM call state. Despite the configured IVR Profile ID, OCS issues RequestReleaseCall and completes call/record processing.

Apply to Call treatments offer an alternative mechanism for call handling. Although it is possible to perform the same call processing in the VoiceXML application (transfer or drop), treatments can be used to improve performance, so that GVP does not need to fetch (or retrieve), parse and execute the VoiceXML application in these basic scenarios.

Outbound Call Transfer by Treatment Application after Processing by the VoiceXML Script

OCS can now apply a treatment of type Transfer or Connect as a step of processing of an outbound call when running in VoIP environment in Power GVP or Progressive GVP dialing modes, if requested by the VoiceXML script. Whenever the processing of a successful outbound call is completed by a VoiceXML application, and further processing of this call is still required, the call can be transferred by OCS to a pre-configured arbitrary destination DN. For example, an outbound call can be transferred to an ACD queue for delivery to a live agent for assisted service after the call has been self-serviced by VoiceXML script execution.

The advantage of this feature is that the transfer is handled by OCS after receiving a specific message from the VoiceXML application. There is no need to implement the transfer by means of the VoiceXML application itself or by any other system component.

Provisioning

Enabling this functionality requires that the Calling List reference the Treatment configuration object. This object should have the Apply to Call action set to Transfer or Connect, a destination DN specified (for example, ACD queue), and the Number in sequence property set to 1. The Apply to Record action of the Treatment configuration object can be set to either No Treatment or Update all records in chain.

Note:

A treatment of type Transfer or Connect can be configured for certain call results only. It is supported for Answer, Answering Machine, Pager, Fax, and OK call results. Genesys recommends that you configure it to the Answer call result, since other call results might affect how OCS makes outbound call on the first stage of call processing (when requesting SIP Server to make an outbound call and when processing EventEstablished on the Trunk Group DN for a successful call results).

Processing

The following is an example of a RecordProcessed request which will be delivered to OCS by the VoiceXML application so that OCS can attempt a Transfer treatment application:

POST http://host1.domain1:8080/records/15?req=RecordProcessed HTTP/1.1
Host: host1.domain1:8080
User-Agent: GVP/8.0 Banking self-service #4
Content-type: application/json
Content-length: 116
{
"GSW_CALL_RESULT":33,
"GSW_TREATMENT":"RecordTreatCampaign",
"CUSTOMER_CODE": 22,
"DATE_LAST_SERVED": "10/30/2008"
}

If the VoiceXML application delivers the RecordProcessed notification to OCS by using HTTP with the GSW_TREATMENT attribute that is specified and the treatment is configured as described in the example above, OCS uses a single step transfer to deliver the call to the destination DN that is specified in the Treatment configuration object.

The Apply to Record property of the treatment controls how OCS treats the chain of records after the transfer. If this property is set to Update all records in chain, OCS finalizes the chain of records in the Calling List and the transferred call processing can no longer affect the chain. If the Apply to Record property is set to No Treatment, OCS does not finalize the chain and awaits further updates for this chain through HTTP from the VoiceXML application or through Desktop protocol from the agents desktop.

Note:

If the chain of records is not finalized by this treatment and the call is passed to an agent for the further processing, OCS only processes the Desktop protocol requests from the agent if this agent belongs to a Group that is associated with the current Campaign Group and is properly logged in.