When installing and configuring Unified IP IVR, you must understand the concepts, call flows, and configuration dependencies explained in this section:

• Task: The Unified CCX receives the incoming call/contact signal on a Trigger, which is then assigned an Application. The application can be a workflow application, a CM Telephony application, (and in a Unified CCE system) an ICM Translation Routing application or an ICM Post-Routing application. When the 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), the 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 CallID plus the Unified CM node (GCID/<node>). If a session already exists for the contact, the Unified CCX associates it with that session. If there is no session for the contact, the 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, or an email. A contact carries attributes such as creation time, state, language, and so on.

• Channel. Each type of contact can have various channel types associated with it. Channels are allocated and associated with contacts as needed and are used to support performing actions on contacts.

  Different types of channels are allocated based on the type of contact and the type of dialogue that needs to be supported between the Unified CCX and the Contact. For example, a CM Telephony call that is presented to Unified CCX will be connected to a CTI Port. To support the call control event transfer, a Call Control channel is allocated.

  If the Trigger is associated to a Primary and or Secondary Dialogue Group, depending on the type, a Media Channel or an MRCP channel will be allocated.

  If an application is triggered by an HTTP Trigger, an HTTP Control Channel will be allocated.

When deploying your system, you should 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?

  Through the Caller, and then the CTI Route Point. An incoming call is given to the Unified CCX system on a Trigger, which is also called a CTI Route Point. The trigger signals the Unified CCX system through 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 Unified CM through CM Telephony/CTI requesting that the caller be rerouted from the CTI Route Point to the CTI Port.

  The calling party is a GW (for a call from the PSTN) or an IP Phone (for an internal call into the system).

• 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 will be required.

  There are two types of triggers: CM Telephony and HTTP.

  • If an application is started by dialing a phone number, it must have a 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 CM Telephony Trigger:

    1. The Unified CCX system looks for an available CTI Port in the CM Telephony Call Control Group assigned to the Trigger.

    2. Unified CCX then requests the Unified CM to Redirect the caller to the desired CTI Port.

    3. The call is presented to the CTI Port.

    4. 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 CM Telephony Trigger need to have Primary and or Secondary Dialogue 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. If there are none available, it will look for an available channel in the Secondary Dialogue Group.

• 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 Dialogue Groups assigned to the Trigger. It can be either CMT (Cisco Media Termination) or ASR (Automatic Speech Recognition).

  Reject. Rejects the call and returns it to Unified CM without answering it.

  Terminate. Disconnects the Contact.

  Redirect. Requests that 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

  • In Unified CCE, when a Unified ICME system sends a Connect request to the Unified CCX system to send a queued call to a destination label.

    Once the Unified CCX system requests a Redirect and Unified CM accepts it, the redirecting CTI Port is released and returned to the idle port list.

When an HTTP request is presented to Unified CCX:

1. The HTTP trigger is assigned to an application.

2. When the URL trigger is hit, an application task is started.

3. The application is assigned to a script and the script starts.

4. An HTTP control channel is allocated.

5. 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.

The figure below shows a simplified block diagram of a contact flow outside of Unified CCE.

Figure 1. Basic Contact Flow Outside of Unified CCE

The following are the steps a call or contact takes within a Unified IP IVR system with Unified CM but without Unified CCE:

1. The caller dials the desired phone number or enters a Web address.

2. Unified CCX receives the contact signal at the phone number trigger point or the Web address trigger point.

3. Unified CCX determines which CTI port to take the contact on and sends a Redirect Request to CTI in the Unified CM to send the contact to the port:

   • If the contact is a call, then the Unified CCX system looks for a CTI port in the CM Telephony Call Control Group assigned to the trigger (the phone number).

   • If the contact is a Web connection, then the Unified CCX system looks for a CTI port in the HTTP Control Group assigned to the trigger (the URL).

4. Unified CM sends the contact to the specified CTI port.

5. The caller is presented to Unified CCX on the CTI port.

6. Unified CCX accepts the call.

7. Unified CCX starts an application that executes a CCX script.

8. The script determines how to handle the call:

   The Unified CCX script can Redirect the call (for example, when no agents are available). Or, the Unified CCX script can answer the call with the Accept step.

   If the Unified CCX script answers the call and the trigger has been assigned a Dialog Group, Unified CCX establishes a media connection with the caller.

Unified CM is a software ACD that distributes calls. The Unified IP IVR software tells Unified CM how to distribute calls. For both products to work together correctly, you should therefore understand how calls are set up when you configure the Unified CM devices.

You should be aware of the following:

• Repository Datastore. The IDs resides on the Unified CCX server in the MSDE or SQL2K database. It holds the prompts, grammars, documents, and scripts used by the system.

• CTI Ports and Route Points. When configuring Unified CCX in the Unified CCX Administration web page, you must enter the information that Unified CCX uses to configure CTI Ports and Route Points in Unified CM.

• CM Telephony User. When configuring Unified CCX, you define a CM Telephony User Prefix that is used to create the CM Telephony User in the Unified CM.

• Redirects. Redirects are performed when a call comes and the call is sent from the route point to the designated CTI port (in this case, the redirect takes place internally as part of the protocol), when a Unified CCX script executes a call Redirect step, or when a Unified ICME system sends a Connect request to the Unified CCX system to send a queued call to a destination label.

  When the Redirect is performed, if the Unified CM destination is available, the call is immediately sent to the Unified CM and released from the CTI Port.

• Destination. A Redirect will fail if the destination is not available.

• Redirect Calling Search Space. Unlike the redirect that the Route Point does to the CTI Port (which is not configurable), the CSS used for a redirect for a call that is already established on a CTI Port is indeed controlled by the Redirect Calling Search Space parameter in the Call Control Group config.

• Calling Search Space. Calling search spaces (CSS) determine the partitions that calling devices, including IP phones, SIP phones, 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.

  See Cisco Unified Communications Manager Maintain and Operate Guides for more information.

• Device Regions. Regions determine the maximum bandwidth codec that is allowed for calls both intra- and inter-region, not the codec itself. In the case of the Unified CCX servers CTI Ports, if the connection to calling or called device cannot be made at the Unified CCX servers installed bandwidth, then a Transcoder channel must be available.

  Warning

  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 if there are no hardware transcoding resources properly configured and available.

  See Regions Configuration for more information.

• 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.

  See 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 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.

The SS_TEL or SS_SIP (Telephony subsystems) debug traces can be used to debug the CM Telephony aspect of a call.

When debugging Unified ICME problems in the Unified IP IVR system, turn on the ICM related debugs. The Unified CCX LIB_ICM (ICM library) and the SS_ICM (ICM subsystem) show the Unified ICME events messaging. Use the Cisco Unified Contact Center Express Solutions Servicing and Troubleshooting Guide for instructions on how to interpret the messages and how to use Trace.

When configuring your Unified IP IVR system in an Unified CCE environment, you need to be aware of the following:

• The DNs (Dialed Numbers) of the Route Points, that is, the triggers that you configure in the Unified CCX system are used in the Unified ICME system as Translation Route DNIS'. As such, it is critical that these DNs match the Translation Route DNIS’ you configure in ICM. If you fail to do this, Translation Routing will not work and calls will be dropped.

  For example, if your Translation Route DNIS pool has DNIS’ 5000, 5001, 5002, and 5003 in it, then you must create four Route Points, each with one of those numbers as the DN of the Route Point.

  So, your configuration might look like this (the names are up to you, but the DNs are mandatory):

  • TRRoutePoint1 – DN 5000

  • TRRoutePoint2 – DN 5001

  • TRRoutePoint3 – DN 5002

  • TRRoutePoint4 – DN 5003

• The CTI port group number IDs in Unified CCX must have the same numbers as the peripheral trunk group numbers in the Unified ICME system.

• It is imperative that the script name referenced in your Unified ICME Run External Script node matches what is configured in the VRU Script List configuration in the ICM Subsystem on Unified CCX.

Figure 2. The Script Name Referenced in your ICM Run External Script Node

In order to eliminate any confusion, name the Unified CCX script exactly the same in all places.

Consider the example BasicQ.aef script provided with your Unified CCX server. Obviously, this is the script name by which Unified CCX will know the script. However, you can refer to this script in a Run External Script node in Unified ICME by whatever name you want. The VRU Script List configuration in Unified CCX Application Administration application is where you couple the ICM External Script name with the Unified CCX script name.

Figure 3. Matching the ICM Script Name with the Unified CCX Script Name

• The VRU Script Name column on the left is the name that Unified ICME will refer to when calling the script and the Script column on the right is the file name of the Unified CCX script you want to run when Unified ICME calls the script mentioned in the VRU Script Name column.

• As you can imagine, if you refer to these scripts by different names in Unified ICME and Unified CCX, it can become confusing when it comes time to troubleshoot. Thus keep these names exactly the same. This way there is no ambiguity as to what script you are referring to.

• The VRU connection port numbers in Unified CCX must be the same as the VRU connection port numbers in the Unified ICME system.

• Any enterprise ECC (Expanded Call Context) variables must be defined on both sides of the system (in Unified IP IVR and in Unified ICME software).