The following diagram shows how various applications in your Unified CCX system work together.
Figure 1. Typical Unified CCX call flow
The basic Unified CCX call flow process is identified below:
A call arrives at voice gateway.
The voice gateway routes the call based on direction from the Unified CM (using H.323 or MGCP).
The Unified CM is configured for the dialed number to be routed by Unified CCX so a route request is sent to the Unified CCX server (using Unified CM Telephony).
Based upon the dialed number, the Unified CCX server selects an available CTI port and initiates the configured script. The first step in the work flow (accept) initiates the establishment of an Real-time Transport Protocol (RTP) VoIP data stream between the CTI port on the Unified CCX server and the VG port. In this scenario, we are assuming no appropriately skilled agents are available, so the application flow executes the queue loop logic until an agent becomes available.
An appropriately skilled agent becomes available.
The agent is selected/reserved by the Unified CCX server and this triggers the call to be transferred to the agent's phone and subsequently causes the agent's phone to ring (using Unified CM signaling). In addition, the Unified CCX server delivers a screen pop to the selected agent's desktop and enables the answer button on the agent's desktop.
The agent answers the call, which initiates the establishment of an RTP VoIP data stream between the agent's phone and the voice gateway port.
Relationships between tasks, sessions, contacts, and channels
When installing and configuring Unified CCX, you must understand the concepts, call flows, and configuration dependencies explained in this chapter:
Task. Unified CCX receives the incoming contact (call) signal on a trigger, which is then assigned an application. The application can be a script application, a Java application, a routing application, or an post-routing application. When Unified CCX accepts the contact, the application starts an application task. The application task in turn invokes an instance of a script associated with the application.
Session. A session tracks contacts as they move around the system. This enables information to be shared among contacts that are related to the same session.
When a contact is received (inbound) or initiated (outbound), Unified CCX checks to see if an existing session already exists with that contact's Implementation ID. The Implementation ID is the Unified CM Global Call ID plus the Unified CM node (GCID/<node>). If a session already exists for the contact, Unified CCX associates it with that session. If no session already exists for the contact, Unified CCX automatically creates one.
After the contact ends, the session remains idle in memory for a default period of 30 minutes before being automatically deleted.
Contact. A contact can be a call, an HTTP request, an email, or a web chat. A contact carries attributes such as creation time, state, language, and so on.
Channel. Each type of contact has its own channel. Channels are allocated and associated with contacts as needed and are used to perform actions on contacts.
Unified CM Telephony deployment considerations
The CTI route point associated with the user enables the Unified CM to query the pertinent external application for routing instruction. Different route point's can query different applications (Unified CCX, Unified ICME, or third-party applications) through Unified CM Telephony. The trigger (route point or dialed number) is mapped to a CTI port group in the Unified CCX configuration. The Unified CCX system chooses an available CTI port in this port group and returns that CTI Port number to the Unified CM so it can setup a call to that CTI port. The Unified CM then makes a call to that CTI port making it ring and the accept step at the beginning of the application answers the call by taking the CTI port off hook. Until the accept step is executed, the caller hears ringing. If no CTI port is available in that port group, then the Unified CCX system answers the Unified CM with the all routes busy response, which triggers the Unified CM to use its forward on busy logic configured for that CTI route point.
When deploying your system, you must understand the following about call flows and the Unified CM configuration dependencies that can impact call flow:
How is a call presented to the Unified CCX system? An incoming call is given to the Unified CCX system on a trigger (CTI Route Point, Caller > CTI Route Point). The trigger signals the Unified CCX system through Unified CM Telephony that there is an incoming call. Unified CCX rejects the call if the Max Session limit has been hit for the trigger or the application to which the trigger is assigned. If there are available sessions, based on the Call Control Group assigned to the trigger, Unified CCX searches for an available CTI Port to receive the call. If it finds an available port, it sends a request to the Unified CM through Unified CM Telephony/CTI requesting that the caller be rerouted from the CTI Route Point to the CTI Port. This takes place as a Unified CM Telephony Redirect request. For this to be successful, the Unified CMs Default setting for Calling Search Space (CSS) must be able to place the call to the selected CTI Port (redirecting party, or in this case, the CTI Route Point).
Why is the CTI Route Point associated with a Unified CM user? For the Unified CCX system to know that a call is coming, it must have control of the line carrying the call. This is done through a Unified CM user. The Unified CM user is associated with the CTI Route Point as a device that the Unified CM user controls. When a trigger is assigned to an application in the Unified CCX system, the Unified CM Telephony subsystem knows that it must take control of that line using the Unified CM Telephony client installed on the Unified CCX system. Once it has control of the line, Unified CM Telephony monitors that line for events as well as performing call-control operations on that line.
How does the Unified CCX system determine which CTI Port to use? A Unified CCX application requires a trigger. The trigger type determines whether or not a port is required.
There are two types of triggers: Unified CM Telephony and HTTP.
If an application is started by dialing a phone number, it must have a Unified CM Telephony trigger.
If an application is started by entering a URL, it must have an HTTP trigger. If an application is triggered by calling a Unified CM Telephony trigger:
The Unified CCX system looks for an available CTI Port in the Unified CM Telephony Call Control Group assigned to the trigger.
Unified CCX then requests the Unified CM to redirect the caller to the desired CTI Port.
The call is presented to the CTIport.
Unified CCX accepts the call on the CTI Port, the call rings on the CTI Port, and a Unified CCX script decides how to handle the call.
Why does the Unified CM Telephony trigger need to have primary and/or secondary dialog groups assigned to it? For the Unified CCX system to establish a media connection to a caller, Unified CCX must allocate a Media Channel for that call. When Unified CCX accepts a call on a CTI port, it looks for an available Media Channel in the primary dialog group. The primary dialog group may be an ASR channel. But if none is available, then the secondary dialog group may be a normal Cisco Media Channel (DTMF only). If you do not use ASR/TTS, you will be using the Cisco Media Group which does not have the secondary dialog group option.
What are the Unified CCX script call control choices?
The call control step choices are:
Accept. Answers the call and establishes a media connection. This is based on the Primary and Secondary dialog groups assigned to the trigger. It can be either the Cisco Media Dialog Group or ASR.
Reject. Rejects the call and returns it to the Unified CM without answering it.
Terminate. Disconnects the Contact.
Redirect. Requests that the Unified CM reroute the caller to another destination.
How are Redirects done?
Redirects can be done in several ways:
When Unified CCX requests that a caller be rerouted from a CTI Route Point to a CTI Port.
When a Unified CCX script executes a Call Redirect step. Once the Unified CCX system requests a Redirect and the Unified CM accepts it, the redirecting CTI Port is released and returned to the idle port list.
HTTP contact flow
When an HTTP request is presented to Unified CCX:
The HTTP trigger is assigned to an application.
When the URL trigger is hit, an application task is started.
The application is assigned to a script and the script starts.
An HTTP control channel is allocated.
The script performs steps on the triggering contact.
Possible step choices are:
Get HTTP contact information. Obtain Header Information, Parameters, Cookies and Environment Attributes and assign them to local variables.
Send a response. Send a Document Object as a response to the calling browser.
Send a JSP reply. Send a response to the calling browser based on a JSP template. This step allows for the mapping of local variables to keywords in the template.
HTTP redirect. Allows a calling browser to be redirected to a different URL.
Web chat flow
See the following figure for a typical Unified CCX web chat flow:
Figure 2. Unified CCX web chat flow
Configuration: This is a configuration step and is a percursor to the web chat flow depicted in the figure. The appadmin configures the chat parameters, making sure that the Unified CCX administrator has a SocialMiner, chat CSQ, and a chat widget with a problem statement defined and configured. The Unified CCX administrator also reviews and verifies other web chat configuration parameters. The Unified CCX administrator preconfigures the customer widget form fields using the appadmin in the chat widget creation step. The configuration process generates the skeletal web code that the administrator passes over to the web developer for the customer website. The web developer formats the chat widget code and embeds it into an HTML page on the customer website.
Web chat request: A contact logs in to the customer website and initiates a web chat request by filling up the customer widget form and selecting an appropriate problem statement.
SocialMiner receives the request: SocialMiner receives the web chat request and opens the chat UI at the customer website. Also, the SocialMiner sends the new contact notification to the Unified CCX.
Contact queuing: After receiving the contact notification from SocialMiner, the Unified CCX matches the problem statement chosen by the contact, and queues the contact in a specific service queue. A queue is a flow where the Unified CCX already has an agent waiting for a contact in that queue and the contact is immediately routed to the available agent.
Agent login: A web chat agent belonging to the service queue on which the contact was queued logs in from the Web Chat Agent desktop.
Agent becomes ready: An agent sends a request to the Unified CCX to make the agent ready to chat. This request triggers the Unified CCX to start an allocation process and find the appropriate contact for the agent from the service queues. The CSQ configuration decides the allocation logic (either most skilled or longest available). After a contact is identified for the agent, the contact is allocated and the agent is moved to the Busy state and is prompted to accept the contact through a dialog event.
Agent accepts: An agent responds to the dialog event. If the agent does not accept during the configured accept time out, the contact is re-queued and is ready to be allocated to the other agent. After receiving a confirmation from the Unified CCX for the accept request, the Cisco Agent Desktop launches the chat reply template.
Chat session creation: When the SocialMiner gets the request to open the chat reply template from the Cisco Agent Desktop, the SocialMiner serves the template page to the Cisco Agent Desktop and connects the agent to the chat session.
Chat session complete: When an agent or a customer ends the chat session, the SocialMiner sends the event back to the Unified CCX to indicate the session ended.
Unified CCX receives session end message: After receiving the message, the Unified CCX updates the session records and moves the agent back to the Not Ready state.
Important Unified CM configuration dependencies
The Unified CCX software tells the Unified CM how to distribute calls. For both products to work together correctly, you must therefore understand how calls are set up when you configure Unified CM devices.
You must be aware of the following:
Repository Datastore. The RDS resides on the Unified CCX server in the Informix database. It holds the prompts, grammars, documents, and scripts used by the system.
CTI Ports and Route Points. When configuring Unified CCX through the Unified CCX Application Administration web page, you must enter and configure the CTI Ports and Route Point information in the Unified CCX; this information is updated automatically in the Unified CM by the Unified CCX. The Unified CCX uses these ports and route points when a call is dialed to the Route point trigger.
Unified CM Telephony User. When Unified CCX starts up, it establishes it's Unified CM Telephony communication session with Unified CM. The Unified CM Telephony user ID and password are used by Unified CM to authenticate the request to begin a Unified CM Telephony communication session. The Unified CM Telephony user ID and password are configured into Unified CM automatically as part of the Unified CCX installation process.
Redirects. The Unified CCX can instruct Unified CM to redirect calls to another destination. Redirects are essentially a blind transfer. When a new call arrives at Unified CM and is routed to a CTI route point, the Unified CCX selects an idle CTI port and implicitly instructs the Unified CM to redirect the call from the CTI route point device to the selected CTI port device. The redirect step in the application editor allows calls to be explicitly redirected to another destination. In either scenario, the destination needs to be in the same CSS as the CTI ports and CTI route points.
Destination. A redirect will fail if the redirecting device (CTI Port) lacks a CSS that contains the partition bound to the destination.
Calling Search Space. Calling search spaces (CSS) determine the partitions that calling devices, including Cisco Unified Communications phones (SCCP or SIP), and gateways, can search when attempting to complete a call. A collection of partitions are searched to determine how a dialed number must be routed. The CSS for the device and the CSS for the directory number get used together. The directory number CSS takes precedence over the device CSS.
Device Regions. The calling and the called devices' regions determine the maximum amount of bandwidth that one call is allowed to consume. While this indirectly affects what codec is used when media negotiation happens between the two parties, the Region configuration simply dictates the highest bandwidth codec permissible. Depending on the configuration of the two parties, other lower-bandwidth codecs might be negotiated during media negotiation.
If you install Unified CCX with the default codec (G.711), your region configuration must allow calls into the region assigned to the CTI Ports at G.711. Otherwise, calls across the WAN are forced to G.729 in the region configuration, which causes the call to fail.
Device Locations. In the event that one or more of the devices are in a location, if sufficient bandwidth is not available, the requested call-control operation will fail. Refer to Location Configuration for more information.
Media Connections. Media connections to the Unified CCX system are either all G.711 or all G.729. This means that the Unified CM region configuration must allow for connections between devices and the Unified CCX server's CTI Ports with the appropriate Codec. If not, then Transcoder channels MUST be configured and available. You do this at the appropriate matching Codec at Unified CCX installation time.
Connection path device (Codec). When you create a region, you specify the codec that can be used for calls between devices within that region, and between that region and other regions. The system uses regions also for applications that only support a specific codec; for example, an application that only uses G.711.
Outbound Dialer configuration properties
The Outbound Dialer feature provides Outbound dialing functionality in addition to existing Unified CCX inbound capabilities. This feature allows agents who are not busy with inbound calls to handle Outbound calls. With the Outbound feature, customer calls are placed using the Cisco Unified Communications by way of the Unified CM for call control.
Since Unified CCX 9.0(1), you can configure a campaign as an Outbound IVR campaign if you have an Outbound IVR license in addition to the existing Unified CCX Premium license. If you select the IVR based option for a campaign, the outbound calls will be handled by the IVR scripts. Typical applications include appointment and bill payment reminders.
You must be aware of the following:
License requirements. The outbound feature is available along with the Unified CCX Premium license and not available with Standard and Enhanced licenses. Since Unified CCX 9.0(1), you need to upload an Outbound IVR license in addition to the existing Unified CCX Premium license if you want to create Outbound IVR campaigns.
Deployment availability. The Outbound feature is only available with Unified CM deployments.
Area code mapping. The system is pre-configured with the area code and time zone mappings for only the area codes within North America. You must manually enter the time zone mapping for international area codes into the system using the Unified CCX Administration GUI.
Do Not Call list. The United States Do Not Call list is not supported and must be filtered out manually before uploading. You must use your own tools to expunge Do Not Call numbers from their Contact List table.
High availability requirements. For high availability deployments, all Unified CCX and database nodes must already be in service.
IP Phone Agent. The IP Phone Agent is not supported
CAD workflows. CAD workflows will be disabled for outbound calls.
10,000 contacts. Contacts can only be uploaded in batches of 10,000.
Time zone usage. The contact's time zone is used as an indication of when the system can place an outbound call to that contact.