Table Of Contents
Test Bed 2: 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
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
Parent/Child Call Flow
Description of Parent/Child Call Flows
Parent/Child Call Flow at Specific Sites in Test Bed 2
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
Failure, Failover and Recovery
Failure without Failover Testing
Private Connection Between Roggers
Test Bed 2: Call Flows and Redundancy
This topic provides configuration information for a variety of sample call flows that were tested and verified in Test Bed 2 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 Parent and Child test bed handles the following types of call flows:
•Cisco Unified Communications Manager Post-Routed call flow, where the call arrives at Site5 and Site9 and is handled by agents at Site5 and Site9 respectively.
•Unified CVP Post-Routed Call flow, where the call arrives at Site 8 and the call is handled by agents at this site.
•Parent and Child call flow where the call comes into the parent sites at Site1/Site4 and is handled by agents in the child sites at Site5, Site8 and Site9.
•Outbound Option call flow where the call is handled by dedicated agents in Site8.
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:Contact_Center_System_Configurations
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 4 is a graphical representation of the Unified CVP Post-Routed call flow as described up to this point (steps 1-18).
Figure 4 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 5 is the second graphical representation of the Unified CVP Post-Routed call flow describing the rest of the call flow (steps 20-24).
Figure 5 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
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 SIP Gateway that originates a SIP call to Cisco Unified SIP Proxy (Unified SIP Proxy).
2. Unified SIP Proxy sends the SIP call to the CVP SIP subsystem service.
3. The CVP 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 the 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 CVP SIP subsystem service.
7. The CVP SIP subsystem service sends the label to Unified SIP Proxy.
8. Unified SIP Proxy sends the call to the VXML gateway.
9. 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.
10. 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.
11. Unified ICME, upon receipt of the REQUEST_INSTRUCTION message, also sends a CONNECT_TO_RESOURCE event back to the Unified CVP Call Server.
12. 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.
13. Upon execution of the routing script by Unified ICME, the Unified CVP Call Server gets a RUN_SCRIPT_REQ event from Unified ICME.
14. The Unified CVP Call Server runs the script and sends instructions to the CVP SIP subsystem client (PSTN GW) via HTTP (VXML) to play the media file.
15. The 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.
16. The caller is requested by the contents of the media file to respond to the prompts in the recording.
17. The 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.
18. Unified ICME does the following:
–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.
–Sends a PRE_CALL message to the Unified CCGE.
19. 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.
20. The Unified CVP Call Server sends a VXML Transfer to the CVP SIP subsystem service to start call setup to the peripheral target.
21. The CVP SIP subsystem service sends the call to Unified SIP Proxy and Unified SIP Proxy sends the call to the Unified Communications Manager.
22. The CVP SIP subsystem service sends several SIP messages to Unified SIP Proxy to:
–Open and close the appropriate RTP path to the originating PSTN Gateway and the VRU.
–Set up the call to the Unified Communications Manager in the child system.
Figure 6 is the graphical representation of the Parent/Child call flow. Note that while the Unified CVP Call Browser, CVP SIP subsystem service, and Media Server are represented as separate entities, they are all on the same physical Unified CVP Call server.
Figure 6 Parent/Child Call Flow (in the Parent System)
In the Child System
1. The call comes to the CTI route point on the Unified Communications Manager of the child system. Unified Communications Manager sends a NEW_CALL message to the Unified SCCG.
2. The Unified SCCG sends a ROUTE_REQUEST message to the Unified CCGE.
3. The Unified CCGE responds with a ROUTE_SELECT (and a label), which is a CTI route point on the child Unified Communications Manager.
4. The Unified SCCG sends the CTI route point to the child Unified Communications Manager.
5. Unified Communications Manager sends a NEW_CALL message to the Unified SCCG.
6. The Unified SCCG sends a ROUTE_REQUEST to the child Unified ICME Rogger.
7. Based on agent availability, follow these procedures:
a. If an agent is available, see Agent is Available at the Child Site (Scenario A)
b. If an agent is not available, see Agent is Not Available at the Child Site Using IP IVR (Scenario B).
Agent is Available at the Child Site (Scenario A)
1. The Unified ICME Router executes the Unified ICME script based on the dialed number that was part of the ROUTE_REQUEST. The script determines the skill group that can best answer the call and checks for agent availability.
1. Unified ICME then does the following:
–Sends a PRE_CALL message to the Unified SCCG with call context information, so that the Unified SCCG can reserve the agent and wait for the call to arrive at the agent's phone.
–Returns a ROUTE_RESPONSE message with a routing label to the Unified Communications Manager.
2. Unified Communications Manager translates the digits in the label and rings the agent's phone.
3. The Unified Communications Manager, via the JTAPI link, sends a notification to the Unified SCCG that the call has arrived.
4. The Unified SCCG reports to Unified ICME that the call has arrived and is ringing on the agent's phone.
5. When the agent answers the call via the Unified CCE Desktop, JTAPI sends a MsgEstablished/CS_CONNECT message to the Unified SCCG.
6. The Unified SCCG reports to the Unified ICME Rogger that the agent has answered the call.
Figure 7 shows how the Parent/Child call flow is handled by the child system when an agent is available (Scenario A).
Figure 7 Parent/Child Call Flow (Child System with Agent Available)
Agent is Not Available at the Child Site Using IP IVR (Scenario B)
1. The Unified ICME Router executes the Unified ICME script based on the dialed number that was part of the ROUTE_REQUEST. The script determines the skill group that can best answer the call and checks for agent availability.
2. Since an agent is unavailable to answer the call, the Unified ICME script executes a RUN_EXTERNAL_SCRIPT node. It then places the call in a queue for the specific skill group.
3. The Unified ICME Rogger returns a ROUTE_RESPONSE message with a label to the Unified Communications Manager. The label allows the call to route to the 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.
|
4. When the call arrives, the JTAPI link on Unified Communications Manager informs Unified IP IVR, which in turn informs the Unified SCCG.
5. When the Unified SCCG receives the incoming call arrival message, it sends a REQUEST_INSTRUCTION message to Unified ICME.
6. Unified ICME instructs Unified IP IVR, via the Unified SCCG, to play the queue messages for the caller, until such time an agent is available to take the call.
7. Once an agent becomes available, the Unified SCCG sends an AGENT_STATE_CHG message to Unified ICME indicating that a qualified agent has become available.
8. Unified ICME then:
–Sends PRE_CALL message to the Unified SCCG with call context information, so that the Unified SCCG 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.
9. 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-A7 in Agent is Available at the Child Site (Scenario A).
Figure 8 is the graphical representation of steps B1-B9 of the Parent/Child call flow describing the call treatment provided by the child system when an agent is not available.
Figure 8 Parent/Child Call Flow (Child System with Agent Not Available)
Agent is Not Available at the Child Site Using CVP (Scenario C)
1. 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.
2. The Unified CVP Call Server instructs the SIP subsystem client to play a hold announcement and music.
3. 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.
4. The Unified CVP Call Server sends a VXML Transfer to the SIP subsystem service to start call setup to the agent.
5. The SIP subsystem sends the call to Unified SIP Proxy and Unified SIP Proxy sends the call to the Unified Communications Manager where the agent is located.
6. The SIP subsystem service sends several messages to Unified 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.
Parent/Child Call Flow at Specific Sites in Test Bed 2
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 2 and is routed by the parent systems (Unified ICME) to the child systems (Unified CCE). The call is handled by agents at the child sites.
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 best child system to deliver the call, for instance, the first child system. In this contact center environment, Site2 is part of the first child system.
At the Child Site:
1. The call is transferred to an available agent located in Site2. If an agent is not available, the call is placed in queue at the Site1 Unified IP IVR and a recording is played back to the caller.
2. The child Unified ICME system determines that an agent at Site3 is available to handle the call. It requests redirection of the call from Site1 Unified IP IVR to the Site3 agent.
3. 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 Parent and Child 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 9 is a graphical representation of the Outbound Option call flow (using Outbound Dialer) as described here.
Figure 9 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 Parent/Child test bed (Test Bed 2), the Outbound Option calls are handled by a set of dedicated agents in Site8.
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 Site8 makes a reservation call to an agent dedicated to making outbound calls at Site8 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: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