Outbound-VoIP in ASM Dialing Modes
Contents
In VoIP environments, when Campaigns are running in ASM modes, agents are engaged by the RTP stream from Media Server. Media Server bridges the engaging and outbound calls, connecting the two RTP streams.
Campaign Group Configuration
In the Outbound-VoIP ASM modes, configure a Campaign Group object the same way that you would for the standard Predictive with seizing or Progressive with seizing dialing modes, but with the addition of the Trunk Group DN configuration. For more information, see Campaign Group Configuration.
| Note: | If the Trunk Group DN is not configured in the Campaign Group object, OCS processes that Campaign Group by dialing on behalf of the Voice Transfer Destination (VTD), as it did in 7.x releases. |
Engaging Calls
In a VoIP environment, OCS requests that an engaging call be dialed. OCS sends this request to SIP Server (using TLibrary) for it to make a call from the Trunk Group DN to VTD. Similarly to the standard ASM mode, the engaging call is then delivered from VTD to the agent's DN.
| Note: | For engaging calls, the TMakeCall request includes the Trunk Group DN and the Voice Transfer Destination DN. |
The following option affect how the engaging call is dialed:
- beep-on-merge--Controls whether a beep is played to the agent immediately before the agent is bridged to the customer call.
- call_wait_agent_connected_timeout--Specifies the timeout, in seconds, between when the engaging call is dialed and when the agent answers the call.
For a successful engaging call (that is, one that is established with an agent), when SIP Server sends EventEstablished to OCS, it includes the Media Server ID (GSW_MEDIA_SRV_ID) as a user data attribute. This enables OCS to bridge only engaging and customer calls that reside on the same Media Server.
For an unsuccessful engaging call (that is, one that is not established with an agent), note the following:
- If an engaging-call request cannot be made, SIP Server issues an EventError on the Trunk Group DN identifying the reason for the failure. Error codes include 50 (Unknown error), 53 (Invalid attribute), and 415 (Invalid destination).
In a VoIP environment, the most likely cause of the failure is the unavailability of resources required to make the call (for example, a lack of available ports on Media Server or the Media Gateway).
- If an engaging-call request is successfully placed but the engaging call is released because the agent is busy, SIP Server issues EventDestinatationBusy and EventReleased on the Trunk Group DN.
- If the engaging-call request is successfully placed but the agent does not answer within the timeout specified by the call_wait_agent_connected_timeout option, OCS releases the call.
| Note: | No announcements are supported for engaging calls. |
Customer Calls
For customer calls, OCS uses the TMakePredictiveCall request to initiate customer calls. This request includes the Trunk Group DN and the Voice Transfer Destination DN.
Call Progress Analysis
Call progress analysis (CPA) occurs based on the setting of the call_answer_type_recognition option, which specifies what has to be detected on the pre-connect (SIT tones) and post-connect (for either a fax or an answering machine) phases of the call, as well as answering machine detection sensitivity.
| Note: | If a record is configured with a call_answer_type_recognition value (see Per-Record Basis) that is not supported by SIP Server (for example, ISDN messages that are based on answering-machine detection only), or if the record does not specify a value, OCS applies instead the no_am_detection value. |
The following options affect CPA for VoIP dialing modes:
- cpd-recording, which allows you to specify whether the call progress detection phase of the call should be recorded.
- call_timeguard_timeout option, which specifies the maximum time that is allowed for CPA after the call is connected.
- cpd-on-connect option. which specifies that CPA begins after the call is connected. Set this option to false or no.
| Notes: |
|
OCS receives the results of CPA (performed by the Media Gateway or the GVP Media Server) in the CallState attribute of EventEstablished (the call has been connected), EventDestinationBusy (the call has been rejected) or EventReleased (call was not answered or it was released by SIP Server) and assigns a call result.
| Note: | When CPD Proxy is used in front of multiple CPD Servers, there is a probability of abandoned calls in both Progressive ASM and Predictive ASM modes. |
For information on attributes that are specific to VoIP environment, see the Outbound Contact Reference Manual.
Successful Call Flows
For a successful customer call, SIP Server passes the Media Server identifier to OCS.
Unsuccessful Call Flows
For an unsuccessful customer call, note the following:
- If a customer call (RequestMakePredictiveCall) cannot be placed, SIP Server issues an EventError on the Trunk Group DN, providing the reason for the failure in the ErrorCode and the ErrorMessage attributes. Error codes include 50 (Unknown error), 53 (Invalid attribute), and 415 (Invalid destination).
In a VoIP environment, the most likely cause for the failure is the unavailability of resources required to make a call (for example, a lack of available ports on Media Server or the Media Gateway).
- If the call is initiated but is released because of a negative call-progress result (usually due to the detection of a SIT tone or a busy response), SIP Server issues EventDestinationBusy and EventReleased on the Trunk Group DN with the associated CallState attribute.
- If the call is initiated successfully, but the call is released because it was not answered or is answered by a fax or answering machine, according to the SIP Server configuration, SIP Server issues EventReleased on the Trunk Group DN with the associated CallState attribute.
Merging Engaging and Customer Calls
For all dialing sessions, OCS maintains information about the distribution of engaging and customer calls among Media Servers. There are two methods — bridging and transfer — for merging an engaging call with a customer call when these calls might be on different Media Servers.
You specify the merge method (bridging or transfer) using the merge-method option at the Campaign Group Level or the OCS Application Level.
| Note: | In a multi-site environment, to maintain the correct Events and ensure user data propagation when merging these calls, configure the SIP Server user-data-from option with a value of current. For more information about this option, see the Framework SIP Server Deployment Guide. |
Bridging Method
OCS controls when and how to bridge the engaging and customer calls. As the default method, when a customer call is connected and call-progress analysis is completed, OCS attempts to find an established engaging call on the same Media Server as the customer call and responds as follows:
- If OCS finds an established engaging call, it bridges the two calls.
- If OCS does not find an established engaging call (for example, in the Predictive mode) on the same Media Server, OCS releases the customer call, with the option to play a configured announcement before releasing it, as configured in either the asm_drop_announcement_data option or the asm_drop_am_announcement_data option.
While the asm_drop_announcement_data option allows you to play the same announcement for all call results, the asm_drop_am_announcement_data option allows you to play a different announcement for Answering Machine call results than the one used for Answer call results.
For SIP Server, if the asm_drop_announcement_data option and/or the asm_drop_am_announcement_data is configured, OCS releases the call only after the announcement is played, which occurs after OCS receives EventTreatmentEnd from SIP Server.
You can configure OCS to handle a scenario in which it cannot find an established engaging call on the same Media Server by setting the value of the on-bridging-unable option to transfer. By doing so, OCS connects the customer call to the first found established engaging call, regardless of the Media Server on which the engaging call is established. You configure this option at the Campaign Group Level OCS Application Level.
If the value of the merge-method option is set to bridging, then the on-bridging-unable option is taken into account in scenarios where bridging is not possible; if the value of the on-bridging-unable option is set to transfer, then OCS will attempt to use the Transfer method; if the value is set to drop, then the call is dropped.
When the bridging method is used, no SIP messaging is provided to OCS if the agent's SIP endpoint fails and the calls are not merged. As a result, OCS is unable to identify the call with a Transfer error.
Transfer Method
For the transfer method, OCS attempts to find an established engaging call on the same Media Server as the customer call and responds as follows:
- If OCS finds an established engaging call on the same Media Server, it connects it with the customer call.
- If OCS does not find an established engaging call on the same Media Server, OCS selects the first found established engaging call on any Media Server and connects it with the customer call.
The following figure illustrates the event flow for the merging of the call legs.
Transferring a Customer Call
If OCS determines that the customer call must be transferred to another destination (for example, a treatment with a transfer call action), OCS uses a single-step transfer. OCS considers the transfer complete when the customer call is transferred from the Trunk Group DN to the VTD. Then, OCS finalizes the chain processing with a call result.
Using the Opt-Out Feature With SIP Server in VoIP Environments
The OCS opt-out feature enables the call recipient to opt-out from any further outbound calls in ASM mode. This feature addresses legislative requirements and enables call recipients to opt-out by pressing certain buttons on the touch tone phone if there are no agents available to speak to them. A typical supported scenario is described in the section, Opting Out of Outbound Calls in ASM Mode.
When SIP Server places outbound calls in VoIP environments and there are no available agents to handle the answered outbound call, the post-connect outbound call processing is handled by Genesys Voice Platform (GVP). GVP runs VoiceXML applications that can play announcements, collect DTMF (or speech) input, compare the input that is provided by the call recipient with the pre-configured opt-out pattern, and deliver the DoNotCall request to OCS by using HTTP or HTTPS. No pre-defined VoiceXML application exists that can handle all of these tasks. Therefore, you must create your own ad-hoc VoiceXML application.
OCS activates the VoiceXML application on GVP in this type of ASM mode when it cannot merge an outbound call with an engaged call, and only if all of the following are true:
- The Campaign Group object in the configuration has an IVR Profile configured that defines which VoiceXML application to activate.
- The OCS digits-detection-pattern configuration option is set to a non-empty string.
- The OCS digits-detection configured option is set to one of the following values:
- all
- answer and the detected call result is Answer
- am and the detected call result is Answering Machine
When OCS activates a VoiceXML application for the record being called, it makes available to the VoiceXML application that is specified in the SIP Headers, the values of the following options:
This process enables the VoiceXML application to build its own logic to process the opt-out request and adapt to the configuration changes in OCS. However, OCS must receive only correctly-formed DoNotCall requests from the VoiceXML application by using HTTP or HTTPS, so that the specific call recipient's phone number can be marked as DoNotCall. All of the underlying logic, such as playing the message, receiving, and processing the called-party input (in the form of DTMF and/or speech) contained in the VoiceXML application.
For more information about how OCS works with GVP and VoiceXML applications in VoIP Environment, see VoiceXML Applications. For information about how to create VoiceXML applications, see the Genesys Voice Platform 8.1 Deployment Guide.
SIP Server and High Availability Limitation
When you are running a dialing session in an ASM mode for an outbound IP campaign and SIP Server is part of a Network Load Balancing cluster that is operating in hot-standby mode, use the Switchover command instead of the Stop command in Solution Control Interface (SCI) to switch from the primary to the backup SIP Server. If you use the Stop command, the primary SIP Server will generate EventLinkDisconnect and of all its associated clients will re-register all DNs on the backup SIP Server. If the primary SIP Server had established calls for Outbound VoIP agents and the agents received an Engaged status, the re-registration process will change the agent status to Busy Unknown or Ready, depending on whether the agent was engaged before starting the backup SIP Server.