Guest

Support

Tested Call Flows

Hierarchical Navigation

  • Viewing Options

  • PDF (922.0 KB)
  • Feedback
Tested Call Flows

Table Of Contents

Tested Call Flows

Cisco Unified Communications Manager Post-Routed Call Flow

Description of Cisco Unified Communications Manager Post-Routed Call Flow

Agent Is Available (Scenario A)

Agent Is Not Available (Scenario B)

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

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

Parent/Child Call Flow

Description of Parent/Child Call Flows

In the Parent System (Test Bed 2)

In the Child System (Test Bed 2)

Agent is Available at the Child Site (Scenario A)

Agent is Not Available at the Child Site Using IP IVR (Scenario B)

Agent is Not Available at the Child Site Using CVP (Scenario C)

Parent/Child Call Flow at Specific Sites in Test Bed 2

In the Parent System (Test Bed 1)

In the Child System (Test Bed 1)

Parent/Child Call Flow at Specific Sites in Test Bed 1

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


Tested Call Flows


This topic provides detailed description and configuration information for a variety of sample call flows that were tested and verified in the three separate test beds in the contact center environment for Cisco Unified Communications System Release 8.0(2).

Test Bed 1—Unified IP IVR test bed, which 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.

Test Bed 2—Parent and Child test bed, which handles the following types of call flows:

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.

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.

Outbound Option call flow where the call is handled by dedicated agents in Site8.

Test Bed 3—Unified CVP test bed, which handles the following types of call flows:

Unified CVP where the call arrives at the branch offices/retail centers and the call is handled by agents at these sites.

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.

Unified Mobile Agent call flow where the call is handled by Unified Mobile Agents associated with sites in the call center.

This topic contains the following sections:

Cisco Unified Communications Manager Post-Routed Call Flow

Cisco Unified Customer Voice Portal Post-Routed Call Flow

Cisco Unified Expert Advisor Call Flow

Parent/Child Call Flow

Cisco Outbound Option Call Flow

Cisco Unified Mobile Agent Call Flow

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/ipcc802/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-dev.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/ipcc802/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-dev.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 6 is the graphical representation of the Unified Expert Advisor call flow.

Figure 6 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/ipcc802/Component_Installation_and_Configuration_Guides.html

Information related to configuring the various components involved in handling the Unified Expert Advisor Post-Routed call flow is available at: http://docwiki-dev.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 (Test Bed 2)

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 7 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 7 Parent/Child Call Flow (in the Parent System)

In the Child System (Test Bed 2)

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 8 shows how the Parent/Child call flow is handled by the child system when an agent is available (Scenario A).

Figure 8 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 9 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 9 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.

In the Parent System (Test Bed 1)

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 (Test Bed 1)

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 in Test Bed 1

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/ipcc802/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-dev.cisco.com/wiki/Category:Contact_Center_System_Configurations

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 10 is a graphical representation of the Outbound Option call flow (using Outbound Dialer) as described here.

Figure 10 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 11 is a graphical representation of the Outbound Option call flow (using SIP Dialer) as described here.

Figure 11 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 Option call flows are tested in the following test beds:

In the Unified IP IVR test bed (Test Bed 1), Outbound Option calls are handled by a set of dedicated agents in Site5.

In the Parent/Child test bed (Test Bed 2), the Outbound Option calls are handled by as set of dedicated agents in Site8.

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 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/ipcc802/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-dev.cisco.com/wiki/Category:Contact_Center_System_Configurations

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 (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

Sample Unified Mobile Agent call flows are tested in both the test beds:

In the Unified IP IVR test bed (Test Bed 1), Unified Mobile Agent calls are handled by a set of mobile agents associated with Site6 and Site7.

In the Unified CVP test bed (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 in either test bed 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 Site7 (for Test Bed 1) or Site3 (for Test Bed 3) 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/ipcc802/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-dev.cisco.com/wiki/Category:Contact_Center_System_Configurations