Table Of Contents
Test Bed 3: Call Flows and Redundancy
Tested Call Flows
Cisco Unified Customer Voice Portal Post-Routed Call Flow
Description of Cisco Unified Customer Voice Portal SIP Call Flow
Cisco Unified Customer Voice Portal Post-Routed Call Flow at Specific Sites
Configuration of Components
Cisco Unified Expert Advisor Call Flow
Description of Unified Expert Advisor Call Flow
Cisco Unified Expert Advisor Call Flow at Specific Sites
Configuration of Components
Cisco Outbound Option Call Flow
Description of Cisco Outbound Option Call Flows
Cisco Outbound Option Call Flow at Specific Sites
Configuration of Components
Cisco Unified Mobile Agent Call Flow
Description of the Cisco Unified Mobile Agent Call Flow
Cisco Unified Mobile Agent Call Flow at Specific Sites
Configuration of Components
Failure, Failover and Recovery
Failure without Failover Testing
Private Connection Between Roggers
Test Bed 3: Call Flows and Redundancy
This topic provides configuration information for a variety of sample call flows that were tested and verified in Test Bed 3 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
The Cisco Unified Customer Voice Portal (Unified CVP) test bed handles the following types of call flows:
•Unified CVP Post-Routed Call flow, where the call arrives at the branch offices/retail centers and the call is handled by agents at these sites.
•Cisco Unified Expert Advisor (Unified Expert Advisor) where the call arrives at the branch offices/retail centers and the call is handled by expert advisors at these sites.
•Outbound Option where the call is handled by dedicated agents in Site6.
•Cisco Unified Mobile Agent (Unified Mobile Agent) call flow where the call is handled by Unified Mobile Agents associated with sites in the call center.
Cisco Unified Customer Voice Portal Post-Routed Call Flow
Cisco Unified Customer Voice Portal (Unified CVP) in the comprehensive mode is deployed to provide IVR queueing and call treatment. The Unified CVP comprehensive deployment involves the either a SIP or H.323 ingress gateway, Unified CVP Call Server (co-located H.323 Service and Unified CVP Application Server), an IOS Voice Browser (VXML-enabled), and the Unified ICME components. Other involved components include the Gatekeeper, Unified Communications Manager, HTTP Media Server, and Cisco Unified Customer Voice Portal Studio (Unified CVPS) server.
This section describes a sample Unified CVP Post-Routed call flow that was tested and verified in this test environment. In a typical Unified CCE system with Unified CVP (comprehensive mode), there is no pre-routing of customer calls. Calls arrive immediately at the peripheral (Unified CVP) that issues a ROUTE_REQUEST message to Unified ICME. Unified ICME begins its routing script and the caller can experience one of these segments:
•A segment in which the call is queued for an agent
•A segment in which the caller talks to an agent
Thereafter, the agent may transfer the call to a second agent or supervisor, which might include another queued segment if the second agent is not yet available.
Description of Cisco Unified Customer Voice Portal SIP Call Flow
1. The call comes from the PSTN into an IOS SIP Ingress Gateway that originates a SIP call to the SIP Proxy (either Cisco Unified Presence (Unified Presence) or Cisco Unified SIP Proxy (Unified SIP Proxy)).
2. The SIP Proxy sends the call to the CVP SIP subsystem service.
3. The SIP subsystem service sends the details of the call to the Unified CVP Call Server using HTTP.
4. The Unified CVP Call Server sends a NEW_CALL event to Unified ICME using the Unified ICME/VRU Interface protocol via the Unified CVP VRU PIM.
5. Unified ICME, upon receipt of the NEW_CALL event, sends a temporary label to connect a VRU to the Unified CVP Call Server.
6. The Unified CVP Call Server sends the label with a correlation ID to the SIP subsystem service.
7. The SIP subsystem service sends the label to the SIP Proxy.
8. The SIP Proxy sends the call to the VXML gateway.
9. The VRU functionality of the PSTN Gateway then sends a message to the Content Switch regarding the new call.
10. The Content Switch routes this message to the appropriate Unified CVP Call Server that in turn sends a REQUEST_INSTRUCTION message to Unified ICME.
11. 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.
12. Unified ICME, upon receipt of the REQUEST_INSTRUCTION message, also sends a CONNECT_TO_RESOURCE event back to the Unified CVP Call Server.
13. 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.
14. Upon execution of the routing script by Unified ICME, the Unified CVP Call Server gets a RUN_SCRIPT_REQ event from Unified ICME.
15. The Unified CVP Call Server runs the script and sends instructions to the SIP subsystem client (PSTN Gateway) via HTTP (VXML) to play the media file.
16. The SIP subsystem client sends HTTP requests to the HTTP Media Server to get the media file and then plays it out to the caller.
17. The caller is requested by the contents of the media file to respond to the prompts in the recording.
18. The SIP subsystem client detects the response or caller-entered digits (CED) and sends it to the Unified CVP Call Server which then forwards it to Unified ICME.
Figure 1 is a graphical representation of the Unified CVP Post-Routed call flow as described up to this point (steps 1-18).
Figure 1 Unified CVP Post-Routed Call Flow
19. Upon receiving the digits, Unified ICME executes the rest of its script and tries to find an agent in a skill group based on the customer's entry. If an agent is not available, it queues the call to that skill group and sends a RUN_SCRIPT_REQ to the Unified CVP Call Server.
20. The Unified CVP Call Server instructs the SIP subsystem client to play a hold announcement and music.
21. When an agent becomes available, Unified ICME instructs the Unified CVP Call Server, with a CANCEL and a CONNECT event, to stop playing the media and start setting up the IP Transfer to the agent.
22. The Unified CVP Call Server sends a VXML Transfer to the SIP subsystem service to start call setup to the agent.
23. The SIP subsystem sends the call to the SIP Proxy, which sends the call to the Unified Communications Manager where the agent is located.
24. The SIP subsystem service sends several messages to the SIP Proxy to:
a. Open and close the appropriate path to the originating PSTN Gateway and the VRU.
b. Transfer the call to the agent phone device in Unified Communications Manager.
c. Connect the call to the agent.
Figure 2 is the second graphical representation of the Unified CVP Post-Routed call flow describing the rest of the call flow (steps 20-24).
Figure 2 Unified CVP Post-Routed Call Flow
Cisco Unified Customer Voice Portal 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 4 and Figure 5.
The sample Unified CVP Post-Routed call arrives at the branch office sites and retail centers (not at the data centers) and is handled by agents at the remote sites. Note that the Unified CVP Call Servers are located at the data centers.
1. Call comes to a PSTN gateway at one of the remote sites (Site6) and is delivered to Unified CVP at the data centers (Site1/Site5).
2. Unified ICME instructs the SIP subsystem client to play a media file with menu prompts requesting caller input.
3. Based on the digits entered by the caller, Unified ICME searches for an available agent in a particular skill group at the local site (Site6) and delivers the call to that agent.
4. If there no available agents at Site6, the call is placed in queue and a message is played informing the caller that agents are not available.
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 CVP Post-Routed call flow is available at: http://docwiki.cisco.com/wiki/Category:Contact_Center_System_Configurations
Cisco Unified Expert Advisor Call Flow
This section describes a sample Unified Expert Advisor call flow that was tested and verified in the contact center test environment. Typically, the Unified Expert Advisor system is deployed in the Unified CVP Post-Routed environment along with Unified Expert Advisor Runtime and Reporting servers, Unified Presence and Unified Personal Communicator.
Unified Expert Advisor is an adjunct product option to Unified CCE and cannot be deployed by itself.
Expert advisors receive instant messages from formal call center agents and use Unified Personal Communicator as their desktops. Calls are delivered to Unified Expert Advisor when Unified CCE determines that expert advisors are available. Unified Expert Advisor then determines which expert advisor will answer the call based on selection strategies.
Description of Unified Expert Advisor Call Flow
1. The call comes from the PSTN into an IOS SIP Ingress Gateway.
2. The SIP Ingress Gateway sends the call to the Unified CVP Call Server.
3. Unified CVP Call Server sends the call to Unified ICME. Unified ICME runs a routing script and queues the call to an expert advisor skill group.
4. Unified ICME sends a translation route label to Unified CVP Call Server.
5. Unified CVP Call Server delivers the call using the translation route label as DNIS to Unified Expert Advisor.
6. Unified Expert Advisor recognizes this DNIS as a translation route DNIS and queries Unified ICME for the call context data.
7. Unified ICME responds to Unified Expert Advisor with call context data such as call variables, ECC variables, and an Assignment Queue label.
8. Unified Expert Advisor sends IM-based notifications via Unified Presence to expert advisors in the specified Assignment Queue.
9. The first available expert advisor responds affirmatively to the IM-based notification.
10. Unified Presence then forwards the affirmative response to Unified Expert Advisor.
11. Unified Expert Advisor delivers the call to Unified Communications Manager, which delivers the call to the expert advisor who responded affirmatively.
12. A media connection is established between the SIP Ingress Gateway and the expert advisor's desktop and the call is delivered to the expert advisor.
Figure 3 is the graphical representation of the Unified Expert Advisor call flow.
Figure 3 Unified Expert Advisor Call Flow
Cisco Unified Expert Advisor Call Flow at Specific Sites
Note that the site-specific information described in this section is not represented in the graphics shown in Figure 6.
The sample Unified CVP Post-Routed call arrives at the branch office sites and retail centers (not at the data centers) and is handled by expert advisors at the remote sites. Note that the Unified CVP Call Servers are located at the data centers (Site1/Site5).
1. Call comes to a PSTN gateway at Site6 and is delivered to Unified CVP at the data centers.
2. Expert advisors at all eligible remote sites (Site3, Site6 and Site8) receive IM-based notifications from Unified Expert Advisor.
3. An available expert advisor at Site3 responds first affirmatively and the call is delivered to that site.
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 Expert Advisor call flow is available at: http://docwiki.cisco.com/wiki/Category:Contact_Center_System_Configurations
Cisco Outbound Option Call Flow
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)
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. In the Unified CVP test bed (Test Bed 3), Outbound Option calls are handled by a set of dedicated agents in Site6.
The Outbound Option call flow is handled in the test bed 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 Site6 makes a reservation call to an agent dedicated to making outbound calls at 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 Unified CVP Post-Routed call flow is available at: http://docwiki.cisco.com/wiki/Category:Contact_Center_System_Configurations
Cisco Unified Mobile Agent Call Flow
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 (Test Bed 1 or Test Bed 2). Subsequent call handling and treatment depends on the components (Unified IP IVR or Unified CVP) 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. Based on where the call arrives, the following call processing takes place:
•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.
•Test Bed 3—Unified ICME queues the call to that skill group and sends a RUN_SCRIPT_REQ to the Unified CVP Call Server. The Unified CVP Call Server instructs the Voice Browser Client to play a hold announcement and music.
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. Based on where the call arrives, the following call processing takes place:
•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.
•Test Bed 3—Unified ICME queues the call to that skill group and sends a RUN_SCRIPT_REQ to the Unified CVP Call Server. The Unified CVP Call Server instructs the Voice Browser Client to play a hold announcement and music.
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
In the Test Bed 3, Unified Mobile Agent calls are handled by a set of mobile agents associated with Site3 and Site6. The following steps show how a sample Unified Mobile Agent call flow is handled 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 an Unified IP IVR/Unified CVP at Site1/Site4 and a recording is played back to the customer.
4. If Unified ICME determines that a mobile agent at Site3 is available to accept the call, it requests redirection of the call from Site1/Site4 Unified IP IVR/ Unified CVP 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 CVP Post-Routed call flow is available at: http://docwiki.cisco.com/wiki/Category:Contact_Center_System_Configurations
Failure, Failover and Recovery
This topic includes the following section:
•Failure without Failover Testing
–Private Connection Between Roggers
Failure without Failover Testing
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.
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