Table Of Contents
Test Bed 1: Call Flows and Redundancy
Tested Call Flows
Cisco Unified Communications Manager Post-Routed Call Flow
Description of Cisco Unified Communications Manager Post-Routed Call Flow
Cisco Unified Communications Manager Post-Routed Call Flow at Specific Sites
Configuration of Components
Parent/Child Call Flow
Description of Parent/Child Call Flows
Parent/Child Call Flow at Specific Sites
Configuration of Components
Cisco Outbound Option Call Flow
Overview
Description of Cisco Outbound Option Call Flows
Cisco Outbound Option Call Flow at Specific Sites
Configuration of Components
Cisco Unified Mobile Agent Call Flow
Overview
Description of the Cisco Unified Mobile Agent Call Flow
Call by Call Connection Mode
Nailed Connection Mode
Cisco Unified Mobile Agent Call Flow at Specific Sites
Configuration of Components
Failure, Failover, and Recovery
WAN Access Router
Private Connection Between Roggers
Test Bed 1: Call Flows and Redundancy
This topic provides configuration information for a variety of sample call flows that were tested and verified in Test Bed 1 in the contact center environment for Cisco Unified Communications System Release 8.5(1). This topic also describes specific test cases that were executed as a part of Cisco Unified Communications System Release 8.5(1) failover testing.
This topic contains the following sections:
•
Tested Call Flows
•Failure, Failover, and Recovery
Tested Call Flows
Test Bed 1—Unified IP IVR test bed, handles the following types of call flows:
–Cisco Unified Communications Manager call flow (Unified Communications Manager), where the call arrives at Site1/Site4 but is handled by agents at Site2, Site3 and Site7.
–Parent and Child call flow where the call comes into the parent sites at Site1/Site4 and is handled by agents in the child site at Site12.
–Cisco Outbound Option (Outbound Option) call flow where the call is handled by dedicated agents in Site5.
–Cisco Unified Mobile Agent (Unified Mobile Agent) call flow where the call is handled by Unified Mobile Agents associated with the virtual call center.
Cisco Unified Communications Manager Post-Routed Call Flow
Cisco Unified Communications Manager takes care of the switching requirements of the Cisco Unified Contact Center Enterprise (Unified CCE) system.
This section describes a sample Unified Communications Manager Post-Routed call flow that was tested and verified. In this sample Unified Communications Manager Post-Routed call flow model, the customer call comes in first to the Unified Communications Manager. The Unified Communications Manager can receive the call from the PSTN network on a Cisco Voice Gateway.
The Unified Communications Manager informs Unified ICME of the new call to request routing information. ICME, using its routing logic, determines the appropriate target (agent or peripheral that is the Unified IP IVR).
In this call flow model, Unified ICME responds to the Unified Communications Manager with a routing label for Unified IP IVR and then sends the call to the Unified IP IVR. The Unified IP IVR prompts the user for Caller Entered Digits (CED). Based on the caller's response, Unified ICME looks for an available agent in the appropriate skill group. If no agents are available, then the call remains in Unified IP IVR for queueing. Once the agent becomes available, Unified ICME redirects the call to that agent.
Description of Cisco Unified Communications Manager Post-Routed Call Flow
1. The call comes into the Unified Communications Manager CTI route point. Unified Communications Manager sends a NEW_CALL message to the Peripheral Gateway (PG).
2. The PG sends a ROUTE_REQUEST message to the Unified ICME Router. The Unified ICME Router executes the Unified ICME script based on the dialed number that was part of the ROUTE_REQUEST.
3. The Unified ICME script executes a RUN_EXTERNAL_SCRIPT node.
4. The Unified ICME Rogger returns a ROUTE_RESPONSE message with a label to the Unified Communications Manager. The label allows the call to be routed to Unified IP IVR. For Unified IP IVR, the dialed number is a CTI route point that is owned by the Unified IP IVR user.
 |
Note On Unified IP IVR, this CTI route point is defined as a JTAPI Trigger. Unified IP IVR is in the same Unified Communications Manager cluster as the call.
|
5. When the call arrives, the JTAPI link on Unified Communications Manager informs Unified IP IVR, which in turn informs the PG.
6. When the PG receives the incoming call arrival message, it sends a REQUEST_INSTRUCTION message to the Unified ICME system.
7. The Unified ICME system instructs Unified IP IVR to play the VRU script prompting the caller to provide CED. Upon receipt of the CED, Unified ICME determines the skill group that can best service the call.
Figure 1 shows how the Unified Communications Manager Post-Routed call is handled prior to agent involvement.
Figure 1 Unified Communications Manager Post-Routed Call Flow
Agent Is Available (Scenario A)
1. If an agent is available, Unified ICME:
–Sends a PRE_CALL message to the PG with call context information, so that the PG can reserve the agent and wait for the call to arrive at the agent's phone.
–Instructs Unified IP IVR to redirect the call from the agent queue to the available agent.
2. Unified IP IVR then sends the call to the Unified Communications Manager.
3. Unified Communications Manager decides whether the agent's phone is in the same Unified Communications Manager cluster or in a different cluster.
|
Note If the agent's phone is on a different Unified Communications Manager cluster, then the call is routed to the appropriate Unified Communications Manager.
|
4. The Unified Communications Manager then rings the agent's Cisco Unified IP Phone.
5. The Unified Communications Manager, via the JTAPI link, sends a notification to the PG that the call has arrived.
6. The PG reports to Unified ICME that the call has arrived and is ringing on the agent's phone.
7. When the agent answers the call via the Unified CCE Agent Desktop, JTAPI sends a MsgEstablished/CS_CONNECT message to the PG.
8. The PG reports to the Unified ICME Rogger that the agent has answered the call.
Figure 2 shows how the Unified Communications Manager Post-Routed call is handled when an agent is available (Scenario A).
Figure 2 Unified Communications Manager Post-Routed Call Flow (Agent is Available)
Agent Is Not Available (Scenario B)
1. If an agent is not available, Unified ICME places the call in an agent queue for the specific skill group and waits for an available agent in the skill group to become available.
2. Unified ICME instructs Unified IP IVR to play the queue messages for the caller, until such time an agent is available to take the call.
3. Once an agent becomes available, the PG sends an AGENT_STATE_CHG message to Unified ICME indicating that a qualified agent has become available.
4. Unified ICME then:
–Sends PRE_CALL message to the PG with call context information, so that the PG can reserve the agent and wait for the call to arrive at the agent's phone.
–Instructs Unified IP IVR to redirect the call from the agent queue to the available agent.
5. Unified IP IVR then sends the call to the Unified Communications Manager and the call is handled in the same manner as described in steps A3-A8 in Agent Is Available (Scenario A).
Figure 3 shows how the Unified Communications Manager Post-Routed call is handled when an agent is not available (Scenario B).
Figure 3 Unified Communications Manager Post-Routed Call Flow (Agent is Not Available)
Cisco Unified Communications Manager Post-Routed Call Flow at Specific Sites
Note that the site-specific information described in this section is not represented in the graphics shown in Figure 1, Figure 2, and Figure 3.
The sample Unified Communications Manager Post-Routed call arrives in Site1/Site4 but is handled by agents in Site2, Site3, and Site7:
1. The call comes to Site1/Site4 from the PSTN, but there are no agents located at these data centers.
2. The calls are transferred to agents located in Site2 and Site3 based on the number dialed by the customer.
3. Based on the menu selection made by the customer and the agent availability for that skill group, the call is transferred to an agent in the skill group to which the call was routed.
4. If an agent is not available, the call is placed in queue at an Unified IP IVR at Site1/Site4 and a recording is played back to the caller.
5. Unified ICME determines that an agent at Site3 is available to handle the call. It requests redirection of the call from Site1/Site4 IP IVR to the Site3 agent.
6. Site3 agent answers the call.
Configuration of Components
For installation and configuration documentation on these components, see Components Installation and Configuration Guides at:
http://www.cisco.com/cisco/web/docs/iam/unified/ipcc851/Component_Installation_and_Configuration_Guides.html
Information related to configuring the various components involved in handling the Unified Communications Manager Post-Routed call flow is available at:
http://docwiki.cisco.com/wiki/Category:Unified_Communications_System_Implementation
Parent/Child Call Flow
The Cisco Unified Contact Center Gateway Enterprise (Unified CCGE) feature, which includes the parent Unified Intelligent Contact Management Enterprise (Unified ICME) system, the child Unified Contact Center Enterprise (Unified CCE) system and the child Unified CCX system, allows the children to appear as traditional ACDs connected to the Unified ICME system. The following Peripheral Gateways are used in this deployment:
•Unified CCGE—Provides all the standard Peripheral Interface Manager (PIM) data and functionality including translation routing, pre- and post-routing, and an auto configuration feature that eliminates repeating configuration tasks between the child Unified CCE/Unified UCCX and parent Unified ICME systems.
•Unified SCCG—Combines the Unified Communications Manager Peripheral Gateway (PG) and VRU PG to look like one peripheral. Unified ICME uses Unified CCGEs to communicate to the CTI server on the Cisco Unified System Contact Center Gateway (Unified SCCG) in Unified CCE environments.
|
Note Typically, a parent Unified ICME system, including Unified CVP, VXML and PSTN gateways, is located in a different location than a child Unified CCE or child Unified CCX systems. Unified CCGEs and SCCGs are installed at the child sites. This section describes a sample Parent/Child call flow, components, and configuration that were tested and verified in this contact center test environment.
|
Parent and Child Systems Relationships
The systems in an Unified CCGE deployment play different roles. The following terms describe the relationship between these roles:
•Parent system—The Unified ICME system that serves as the network or enterprise routing point, involving Unified CCGEs.
•Child system—The Unified CCE system that is set up to function as an ACD, involving
Unified SCCGs. The Unified CCX can also be set up to function as an ACD.
The parent system does the following:
•Routes calls from parent to child.
•Uses Unified CVP to provide initial call treatment (prompting) for calls that come into the parent sites.
•Based on Unified ICME call routing logic, routes the call to an available agent in the child system. If no agents are available, queues the call at the local Unified IP IVR, Unified CVP and Unified CCX at the child system
The child system does the following:
•Can receive calls with or without the involvement of the parent system (requires additional setup to ensure that calls are routed directly from the PSTN to the child site).
•For calls received directly by the child, uses Unified IP IVR or Unified CVP to provide initial call treatment and queuing.
•Based on Unified ICME call routing logic, routes the call to an available agent at its own site or queues it at Unified IP IVR or Unified CVP locally.
For detailed information on the parent and child model, see the Cisco Contact Center Gateway Deployment Guide for Cisco Unified ICME/CCE/SCCE/CCX at:
http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/ipcc_enterprise/ipccen terprise8_0_1/installation/guide/ipcc80gtwy.pdf
Description of Parent/Child Call Flows
In the Parent System
1. The call comes from the PSTN into an IOS VXML Gateway that originates a SIP call to the Unified CVP SIP subsystem service.
The Unified CVP SIP subsystem service sends the details of the call to the Unified CVP Call Server using HTTP.
2. The Unified CVP Call Server sends a NEW_CALL event to the Unified ICME using the Unified ICME/VRU Interface protocol via the Unified CVP VRU PIM.
3. Unified ICME, upon receipt of the NEW_CALL event, sends a temporary label to connect a VRU to the Unified CVP Call Server.
The Unified CVP Call Server sends the label with a correlation ID to the Unified CVP SIP subsystem service.
4. The Unified CVP SIP subsystem service sends the label to VXML gateway.
5. The VRU functionality of the PSTN Gateway then sends a message to the appropriate Unified CVP Call Server that in turn sends a REQUEST_INSTRUCTION message to Unified ICME.
Unified ICME uses the correlation ID, which is relayed to it as a part of the REQUEST_INSTRUCTION message, with the call it processed earlier.
6. Unified ICME, upon receipt of the REQUEST_INSTRUCTION message, also sends a CONNECT_TO_RESOURCE event back to the Unified CVP Call Server.
7. The Unified CVP Call Server acknowledges Unified ICME with a RESOURCE_CONNECTED event, and then Unified ICME executes the routing script enabled for that call.
8. Upon execution of the routing script by Unified ICME, the Unified CVP Call Server gets a RUN_SCRIPT_REQ event from Unified ICME.
9. The Unified CVP Call Server runs the script and sends instructions to the Unified CVP SIP subsystem client (PSTN Gateway) via HTTP (VXML) to play the media file.
10. The Unified CVP SIP subsystem client sends HTTP requests to the HTTP Media Server to get the media file and then plays it out to the caller.
11. The caller is requested by the contents of the media file to respond to the prompts in the recording.
12. The Unified CVP SIP subsystem client detects the response or caller-entered digits (CED) and sends it to the Unified CVP Call Server that then forwards it to Unified ICME.
13. Unified ICME does the following:
a. Receives the CED and determines the appropriate child system to handle the call by returning a label for the peripheral target. In this case, the peripheral is the child Unified Communications Manager.
b. Sends a PRE_CALL message to the Unified CCGE at the child site.
14. Unified ICME instructs the Unified CVP Call Server, with a CONNECT event, to start setting up the IP Transfer to the peripheral target. In this case, the label for the peripheral target is defined as a CTI route point on the Unified Communications Manager in the child system.
The Unified CVP Call Server sends a VXML Transfer to the Unified CVP SIP subsystem service to start call setup to the peripheral target.
15. The Unified CVP SIP subsystem service sends the call to the Unified Communications Manager.
In the Child System
1. Unified Communications Manager at the child site passes the call to Unified CCX.
2. When a call arrives at a Unified CCX trigger, a workflow (script) is executed.
3. Unified CCX makes a post-route request to Unified ICME to query final destination of the call (by placing the Request Route step in the workflow).
4. When Unified ICME gets the route request via the Unified CCGE, a Unified ICME returns a label to Unified CCX.
5. Unified CCX script queues the call to a ContactService Queue (CSQ), updates the label with the CSQ-Id, and then transfers the call to an available agent.
Parent/Child Call Flow at Specific Sites
Note that the site-specific information described in this section is not represented in the graphics in this section.The sample Parent/Child call arrives at the parent sites (Site1/Site4) in Test Bed 1 and is routed by the parent systems (Unified ICME) to the child system (Unified CCX). The call is handled by agents at the child Site12.
At the Parent Site:
1. Call comes to a PSTN gateway at Site1 and is delivered to the parent Unified CVP Call Control Server at Site1.
2. The parent Unified CVP Call Control Server informs the parent Unified ICME system at Site1 of the call which returns the temporary label to connect to the Site1 VRU.
3. The parent Unified CVP Call Control Server switches the call to the VRU.
4. The parent Unified ICME system instructs the parent Unified CVP Call Control Server to play a media file with menu prompts requesting the caller to enter digits.
5. Once the caller responds, Unified ICME determines the appropriate child system to handle the call and instructs Unified CVP Call to set up the transfer to the peripheral target, which in this case is the CTI route point on the Unified Communications Manager in the child system at Site12.
At the Child Site:
1. Unified Communications Manager at Site12 passes the call to Unified CCX at Site12.
1. Unified CCX places the call in CSQ first while searching for an available agent in Site12 before routing it to the agent,
Configuration of Components
For installation and configuration documentation on these components, see Components Installation and Configuration Guides at:
http://www.cisco.com/cisco/web/docs/iam/unified/ipcc851/Component_Installation_and_Configuration_Guides.html
Information related to configuring the various components involved in handling the Parent and Child call flow is available at:
http://docwiki.cisco.com/wiki/Category:Unified_Communications_System_Implementation
Cisco Outbound Option Call Flow
Overview
Cisco Outbound Option (Outbound Option) is a feature of Unified ICME that provides outbound dialing functionality along with existing inbound capabilities of the Unified ICME software. With Outbound Option, contact centers can be configured for automated outbound activities. Agents who are not busy handling inbound requests can perform outbound calls.
Call blending and predictive dialing offer a way to increase resource utilization and increase productivity in a contact center. Outbound Option enables contact center managers in need of outbound campaign solutions to take advantage of the enterprise view that Unified ICME maintains over agent resources.
This section describes a sample Outbound Option Post-Routed call flow that was tested and verified in this test environment.
Description of Cisco Outbound Option Call Flows
Using Outbound Dialer
1. Outbound Option requests skill group statistics from the CTI Server.
2. The CTI Server returns skill statistics from the ACD/Unified Communications Manager.
3. Outbound Option uses predictive logic to calculate the number of lines to dial and requests customer records from the Campaign Manager.
4. The Campaign Manager retrieves the required customers from its database and sends those customers to Outbound Option.
5. Outbound Option makes reservation requests via the MR PG interface. Once an agent is selected by the router, a physical reservation call is placed to continue to reserve the agent.
6. Once agents are reserved, Outbound Option makes customer calls via a Cisco Voice Gateway. Call classification (that is, the result of the call; busy response, answering machine detection, and so on) is handled on Outbound Option.
7. If a customer is contacted, they are transferred to an available agent within that skill group via the agent's call waiting line.
8. (Optional functionality provided by Cisco Client Services) When agents receive customer calls, they get an HTML-based script popup on their desktops, originating from Microsoft Active Server Pages that provides them with customer data.
9. After the customer call ends, a wrap-up code is sent to Outbound Option, which sends it to Unified ICME via the CTI Server and the MR PG.
10. The Campaign Manager then saves call disposition information in the Logger database.
Figure 4 is a graphical representation of the Outbound Option call flow (using Outbound Dialer) as described here.
Figure 4 Outbound Option Call Flow (using Outbound Dialer)
Using SIP Dialer
1. An import of customer records is scheduled at the Unified ICME Logger and the Outbound Option Campaign Manager starts the import process. Customer records are delivered to the Outbound Option SIP Dialer.
2. The SIP Dialer looks for an available agent via the Media Routing interface on the MR PG.
3. The MR PG forwards the request to the Unified ICME Router.
4. The routing script on the Unified ICME Router identifies an agent and responds to the MR PG.
5. The Media Routing PIM notifies the SIP Dialer that an agent is available and the SIP Dialer reserves the agent for the call.
6. The SIP Dialer signals the SIP Proxy and the SIP Proxy finds a gateway and then places a call to a customer based on the dialing campaign.
7. The Egress Voice Gateway places the call to the customer and performs Call Progress Analysis.
8. If the customer answers the call and voice detection occurs, the SIP Dialer is notified by the Egress Voice Gateway via the SIP Proxy.
9. The SIP Dialer asks the Egress Voice Gateway to transfer the call to the reserved agent based on the agent extension.
10. The Egress Voice Gateway initiates the call transfer to the SIP Proxy and the SIP Proxy forwards the invitation to Unified Communications Manager.
11. Unified Communications Manager forwards the call invitation to the agent's phone and a media connection is established between the gateway and the reserved agent's phone. The call is routed to that agent.
Figure 5 is a graphical representation of the Outbound Option call flow (using SIP Dialer) as described here.
Figure 5 Outbound Option Call Flow (using SIP Dialer)
Cisco Outbound Option Call Flow at Specific Sites
Note that the site-specific information described in this section is not represented in the graphics in this section.
Sample Outbound call flows is tested in the Unified IP IVR test bed 1, where the Outbound Option calls are handled by a set of dedicated agents in Site5.
The Outbound Option call flow is handled in the test beds as follows:
1. Customer records are imported at the Logger dynamically. A Dialing List is created.
2. During an active Campaign, the Outbound Option at Site5/Site8/Site6 makes a reservation call to an agent dedicated to making outbound calls at Site5/Site8/Site6 via the MR PG.
3. The agent is set to a reserved state.
4. Outbound Option dials out to a customer from the Dialing List via the Cisco Voice Gateway.
5. If the customer is contacted, Outbound Option transfers the call to the reserved agent at Site5/Site8/Site6 within the Outbound Option skill group.
6. After the customer call ends, call disposition information is saved in the Logger database.
Configuration of Components
For installation and configuration documentation on these components, see Components Installation and Configuration Guides at:
http://www.cisco.com/cisco/web/docs/iam/unified/ipcc851/Component_Installation_and_Configuration_Guides.html
Information related to configuring the various components involved in handling the Outbound Option call flow is available at:
http://docwiki.cisco.com/wiki/Category:Unified_Communications_System_Implementation
Cisco Unified Mobile Agent Call Flow
Overview
The Cisco Unified Mobile Agent feature extends the Cisco Unified Contact Center Enterprise (Unified CCE) architecture by enabling it to connect customer calls to an agent phone that is not controlled by Unified CCE. This could be an agent:
•Outside the contact center, using an analog phone at home or a cell phone.
•Inside the contact center, using an IP phone not controlled by Unified CCE.
Unified CCE does this by using a Unified Communications Manager CTI port as a proxy for the mobile agent's phone. Once the proxy is configured, the JTAPI interface instructs Unified Communications Manager to place a call to the mobile agent through an appropriate gateway and to connect the customer call to the mobile agent.
A local agent refers to an agent who is configured as a non-mobile agent and whose phone is controlled by Unified CCE. A local agent can be working within a contact center or at a remote location.
The flow of a customer call meant for a mobile agent is similar to the one meant for a local agent, except in the manner in which the call is ultimately delivered to the agent phone. The call flow is initially processed according to the specific environment in which it arrives. Subsequent call handling and treatment depends on the components in the test bed, but varies from how it is normally handled once the customer call is designated to be delivered to a mobile agent. Unified Mobile Agent supports the same call control capabilities as Unified CCE (answer, hold, transfer, and others). All call control is done through the agent desktop.
For additional information, see "System Configuration for Unified Mobile Agent" in Mobile Agent Guide for Cisco Unified Contact Center Enterprise & Hosted Release 7.5(1) at: http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/icm_enterprise/icm_enterprise_7_5/user/guide/ipcc75mag.pdf
Description of the Cisco Unified Mobile Agent Call Flow
Unified Mobile Agent supports the following two call connection modes:
•Call by call connection mode
•Nailed connection mode
Call by Call Connection Mode
In a call by call dialing configuration, the mobile agent's remote phone is dialed for each incoming call. When the call ends, the mobile agent's phone is disconnected before being made ready for the next call. In this connection scenario, the mobile agent must answer the phone by going off-hook. The answer button on the agent desktop is not enabled and Auto-Answer is not possible, because there is no call control mechanism to force the mobile agent phone to go off-hook.
At login, the mobile agent specifies the agent ID, password, a local CTI port Directory Number (DN) as the instrument (CTI OS) or extension (Cisco Agent Desktop), and a number for the mobile agent's remote phone.
Mobile Agent is Not Available
When a customer call arrives and an agent is unavailable, the call processing that occurs is the same as that for a local agent.
In Test Bed 1—Unified ICME queues the call for a skill group or an mobile agent and instructs Unified IP IVR to play the queue messages for the customer, until such time an agent is available to take the call.
Mobile Agent is Available
Once an agent is selected for the call and if the agent happens to be a mobile agent, the call flow is as follows:
1. The router uses the directory number (DN) entered at the time of login for the mobile agent's local CTI port as the routing label to direct the call.
2. The incoming call rings at the mobile agent's local CTI port. The Unified SCCG is notified that the local CTI port is ringing but it does not answer the call immediately. The customer hears ringing at this point.
3. Simultaneously, another call is initiated from the network CTI port (also referred to as remote CTI port) to the selected agent. If the agent does not answer within the configured time, Redirect On No Answer (RONA) processing is initiated.
|
Note If the mobile agent's phone is configured with voicemail, disable the voicemail to allow RONA call processing to occur.
|
From a customer's perspective, the call by call delivery mode has a longer ring time compared to the nailed connection delivery mode. This is because, it is only after the call is routed to the mobile agent that the Unified SCCG starts to dial the mobile agent's remote phone number and, after the agent answers, connects the customer call to the agent call. The customer continues to hear ringing up to this point.
4. When the mobile agent answers their remote phone by going off-hook, this second call is temporarily placed on hold.
5. The original customer call is answered and directed to the mobile agent's call media address. The agent call is then taken off hold and directed to the customer call media address, resulting in an RTP stream between the two VoIP endpoints.
6. When the call ends, both connections are disconnected and the mobile agent status is set to either ready, not ready, or wrap-up, depending upon agent configuration and agent desktop input.
Nailed Connection Mode
In a nailed dialing configuration, the mobile agent is called once at login and the line stays up and connected through multiple customer calls. In this connection scenario, the Auto-Answer feature is allowed and a nailed mobile agent can log off by using either the desktop or by hanging up the phone.
At login, the following occurs:
1. The mobile agent specifies the agent ID, password, a local CTI port Directory Number (DN) as the instrument (CTI OS) or extension (Cisco Agent Desktop), and a number for the mobile agent's remote phone.
2. A call is initiated to the mobile agent's phone from the network CTI port (also referred to as remote CTI port) statically associated (by the Unified SCCG) with the local CTI port used at login.
3. When the agent answers, the call is immediately placed on hold. Only at this point is the mobile agent considered fully logged in and ready to accept incoming customer calls.
Mobile Agent is Not Available
When a customer call arrives and an agent is unavailable, the call processing that occurs is the same as that for a local agent.
In Test Bed 1—Unified ICME queues the call for a skill group or an mobile agent and instructs Unified IP IVR to play the queue messages for the customer, until such time an agent is available to take the call.
Mobile Agent is Available
Once an agent is selected for the call and if the agent happens to be a mobile agent, the call flow is as follows:
1. The router uses the directory number (DN) entered at the time of login for the mobile agent's local CTI port as the routing label to direct the call.
2. The incoming call rings at the mobile agent's local CTI port. The Unified ICME Agent PG Unified SCCG is notified that the local CTI port is ringing but its does not answer the call immediately. The customer hears ringing at this point.
3. The agent's desktop indicates a call is ringing, but the agent phone does not ring because it is already off-hook (due to the nailed connection). If the agent does not answer within the configured time, RONA processing is initiated.
|
Note If the mobile agent's phone is configured with voicemail, disable the voicemail to allow RONA call processing to occur.
|
4. When the agent presses the Answer button on the agent desktop to accept the call, the customer call is answered and directed to the mobile agent's call media address. The agent call is then taken off hold and directed to the customer call media address.
5. When the call ends, the customer connection is disconnected, but the mobile agent connection is placed back on hold.
6. The mobile agent status is set to ready, not ready, or wrap-up, depending upon agent configuration and agent desktop input.
Cisco Unified Mobile Agent Call Flow at Specific Sites
Sample Unified Mobile Agent call flows are tested in the Unified IP IVR test bed 1, where the Unified Mobile Agent calls are handled by a set of mobile agents associated with Site6 and Site7.
The following steps show how a sample Unified Mobile Agent call flow is handled in Test Bed 1 by mobile agents associated with the call center:
1. The call comes to Site1/Site4 from the PSTN, but there are no agents located at these data centers.
2. Based on the menu selection made by the customer and the agent availability for that skill group, the call is transferred to an agent in the skill group to which the call was routed.
3. If an agent is not available, the call is placed in queue at Unified IP IVR at Site1/Site4 and a recording is played back to the customer.
4. If Unified ICME determines that a mobile agent at Site7 is available to accept the call, it requests redirection of the call from Site1/Site4 Unified IP IVR to the mobile agent via the PSTN.
5. The mobile agent answers the call.
Configuration of Components
For installation and configuration documentation on these components, see Components Installation and Configuration Guides at:
http://www.cisco.com/cisco/web/docs/iam/unified/ipcc851/Component_Installation_and_Configuration_Guides.html
Information related to configuring the various components involved in handling the Unified Mobile Agent call flow is available at:
http://docwiki.cisco.com/wiki/Category:Unified_Communications_System_Implementation
Failure, Failover, and Recovery
The contact center environment is intended to be redundant and self-healing. In many cases, this functionality makes a failover and recovery from a failure nearly invisible. This section discusses the failover testing that was done with contact center components that did not provide redundancy capabilities in the event of a failure.
WAN Access Router
Pre-Test Conditions
The following describes the test conditions for this test:
•Test site involved is Site3.
•All links for Site3 are up and active.
•A WAN router is deployed at this site for communication with other sites across the Frame Relay cloud.
•Calls at Site3 are in progress in the IOS Voice Browser and on CAD systems with at least one supervisor monitoring an agent call.
•There is no backup implemented for the serial interface on the WAN router at Site3.
Test
The following describes the failover testing done for the WAN access router (without a backup WAN link):
1. Disable the serial interface of the WAN router at Site3 and observe the impact to system behavior.
2. Verify the results of the above procedure as described in After Disabling the Serial Interface.
3. Enable the serial interface of the WAN router at Site3 and observe the affect on system behavior.
4. Verify the results of this procedure as described in After Enabling Serial Interface.
Results
The following results were verified in this test.
|
Note No affect is expected to Site1 and Site5 call processing or agent states. All failures occur at Site3.
|
After Disabling the Serial Interface
For new calls generated from the PSTN
•New inbound calls to the IOS Voice Browser (Gateway) can behave in one of two ways, depending upon the gateway configuration:
–They can fail with a busy tone.
–They can be re-routed or "hairpinned," using a Gateway Redirect Dial Peer, as new calls to the Unified CVP at another inter-cluster site.
For transient calls (already in the IOS Voice Browser and being transferred to agents):
•If the call was re-directed by the IOS Voice Browser to an agent, the call continued the transfer and rang at the agent phone. This situation occurred only if the call reached the agent phone before the phone realized that it had lost the WAN connection with its Cisco Unified Communications Manager (Unified Communications Manager).
•If the call had not yet been re-directed by the IOS Voice Browser to an agent, the call either failed or, if a backup re-direct was programmed in the gateway, the call was hairpinned to another Unified CVP site within the cluster.
•If the call was in queue on the IOS Voice Browser, the call either failed, or, if a backup re-direct was programmed in the gateway, the call was hairpinned to another Unified CVP site within the cluster.
|
Note In all cases, the H.323 call survivability timer affected the life of the call. All calls may be removed from the ingress gateway after this timer expires.
|
For existing calls being handled by agents:
•Calls stayed active and operational until the call ended normally or until the H.323 timer expired.
•The following affect was observed to the agent state for agents in Site3:
–Agents lost connectivity to the CAD server at Site3 and the agent desktops were in a NOT_READY state until the WAN connection was restored.
–Agents already engaged on calls were not be able to perform any agent state change or telephony functions, such as hold, conference, and transfer, during the outage event.
–Agents were not be able to log into the system during this event.
–Unified ICME showed the remote agents at Site3 as being no longer available (the WebView report showed the remote agents as being logged out).
•The following was the affect observed to supervisor monitoring:
–Supervisor already in a monitor session with the agent and caller remained in the call for the duration of the call, or until the H.323 timer expired and the call was terminated by the gateway.
–Supervisor was not be able to perform any call control functions to barge in, intercept, or perform any conference or chat functions on the Supervisor desktop.
After Enabling Serial Interface
•Phones were reset and re-registered with their target Unified Communications Manager.
•Agent desktops reconnected to the CAD Servers and, depending upon the phone state (reset or not), allowed the agents to become READY without having to log in again.
•Agents that were not logged in were able to now log in (if the Cisco Unified IP Phones were reset properly).
•Any calls that were in the gateway prior to the failure and were hairpinned to another site remained in this state until the call was terminated normally. In this situation, the gateway does not automatically terminate the calls.
Private Connection Between Roggers
Pre-Test Conditions
The following describes the test conditions for this test:
•Test sites involved are Site1 and Site5.
•Rogger A is located at Site1 and Rogger B is located in Site5.
•All links between the two sites are up and active.
•Calls are in progress between the Site1 and Site5 Unified Communications Manager clusters.
•There is no backup implemented for the private connection between the two Roggers at Site1 and Site5.
Test
The following describes the failover testing that was performed for the private connection between the Roggers (without a backup connection):
1. Simulate a failure of the private link between Rogger A and Rogger B.
2. Verify the system behavior immediately after the simulated private link failure as described in After the Private Link Failure.
3. Place calls from a PSTN call generator and route them between Site1 and Site5.
4. Verify the system behavior after the private link was restored as described in After the Private Link was Restored.
Results
The following results were verified in this test:
After the Private Link Failure
•Via the Event Viewer, both Roggers indicated a loss of heart beats on the private network after missing five consecutive 100 ms heart beats.
•The Roggers sent Test Other Side (TOS) messages to the Peripheral Gateway, which responded with either Rogger A or Rogger B as the enabled side of the system.
•Based on the Rogger that was considered the enabled side, the other Rogger became disabled.
•The enabled Rogger then initiated the Enabled Simplex operation (visible in the MDS process window).
•There was no affect observed to system operation or behavior.
•There was no loss of calls or agent state across the system during this failure.
After the Private Link was Restored
•The Roggers observed the presence of a duplex partner and performed a state transfer operation from the active side to the inactive side call router.
•Upon completion of the state transfer operation, the MDS processes reported that both Roggers were in an active duplex operation.
•No affect on call processing was observed during this event window.
Feedback