Interfacing UCCE with CUCM via JTAPI
From the UCCE 9.x SRND:
In order for JTAPI communications to occur between Unified CM and external applications such as Unified CCE and Unified IP IVR, a JTAPI user ID and password must be configured within Unified CM. Upon startup of the Unified CM PIM or on startup of the Unified IP IVR, the JTAPI user ID and password are used to sign in to Unified CM. This sign-in process by the application (Unified CM PIM or Unified IP IVR) establishes the JTAPI communications between the Unified CM cluster and the application. A separate JTAPI user ID is required for each Unified IP IVR server (and Unified CM PIM). In a Unified CCE deployment with one Unified CM cluster and two Unified IP IVRs, three JTAPI user IDs are required: one JTAPI user ID for Unified CCE and two JTAPI user IDs for the two Unified IP IVRs. The best practice is one PG User for each PG Pair.
The Unified CM software includes a module called the CTI Manager, which is the layer of software that communicates through JTAPI to applications such as Unified CCE and Unified IP IVR. Every node within a cluster can execute an instance of the CTI Manager process, but the Unified CM PIM on the PG communicates with only one CTI Manager (and thus one node) in the Unified CM cluster. The CTI Manager process communicates CTI messages to and from other nodes within the cluster.
For example, suppose a deployment has a Voice Gateway homed to node 1 in a cluster, and node 2 executes the CTI Manager process that communicates to Unified CCE. When a new call arrives at this Voice Gateway and needs to be routed by Unified CCE, node 1 sends an intra-cluster message to node 2, which sends a route request to Unified CCE to determine how the call is routed.
Each Unified IP IVR also communicates with only one CTI Manager (or node) within the cluster. The Unified CM PIM and the two Unified IP IVRs from the previous example can communicate with different CTI Managers (nodes) or they can all communicate with the same CTI Manager (node). However, each communication uses a different JTAPI user ID. The JTAPI user ID is how the CTI Manager tracks the different applications.
When the Unified CM PIM is redundant, only one side is active and in communication with the Unified CM cluster. Side A of the Unified CM PIM communicates with the CTI Manager on one Unified CM node and Side B of the Unified CM PIM communicates with the CTI Manager on another Unified CM node. The Unified IP IVR does not have a redundant side, but the Unified IP IVR does have the ability to fail-over to another CTI Manager (node) within the cluster if its primary CTI Manager is out of service.
 |
| UCCE Signaling |
The JTAPI communications between the Unified CM and Unified CCE include three distinct types of messaging:
A typical Unified CCE call includes all three types of JTAPI communications within a few seconds. When a new call arrives, Unified CM requests routing instructions from Unified CCE. For example, when Unified CM receives the routing response from Unified CCE, Unified CM attempts delivery of the call to the agent phone by instructing the phone to begin ringing. At that point, Unified CM notifies Unified CCE that the device (phone) has started ringing and that notification enables the agent’s answer button on the desktop application. When the agent clicks the answer button, Unified CCE instructs Unified CM to make the device (phone) go off-hook and answer the call.
- Routing control Routing control messages provide a way for Unified CM to request routing instructions from Unified CCE.
- Device and call monitoring Device monitoring messages provide a way for Unified CM to notify Unified CCE about state changes of a device (phone) or a call.
- Device and call control Device control messages provide a way for Unified CM to receive instructions from Unified CCE on how to control a device (phone) or a call.
In order for the routing control communication to occur, Unified CM requires the configuration of a CTI Route Point. A CTI Route Point is associated with a specific JTAPI user ID, and this association enables Unified CM to know which application provides routing control for that CTI Route Point. Directory (Dialed) Numbers (DNs) are then associated with the CTI Route Point. A DN is associated to a CTI Route Point that is associated with Unified CCE JTAPI user ID. This enables Unified CM to generate a route request to Unified CCE when a new call to that DN arrives.
In order for the phones to be monitored and controlled, they also must be associated in Unified CM with a JTAPI user ID. Starting with Unified CM 8.0, when using Extension Mobility or Extension Mobility Cross Cluster, it is possible to associate an Extension Mobility device profile instead. In a Unified CCE environment, the IP phones or the corresponding Extension Mobility device profiles are associated with Unified CCE JTAPI user IDs. When an agent logs in from the desktop, the Unified CM PIM requests Unified CM to allow the PIM to begin monitoring and controlling that phone. Until the login has occurred, Unified CM does not allow Unified CCE to monitor or control that phone. If the device or the corresponding Extension Mobility device profile has not been associated with a Unified CCE JTAPI user ID, then the agent login request fails.
Support for Extension Mobility Cross Cluster (EMCC) is provided in Release 8.0. The Unified CCE PIM phone registers to the local Unified CM after Extension Mobility login and it looks like an agent situated across a WAN. The Unified CCE peripheral is managing the agent devices based on the Extension Mobility profile rather than on a phone device in the Application User on Unified CM. For more details, see the Cisco Unified Communications Solution Reference Network Design Guide (SRND).
Because EMCC is now supported, you can associate Extension Mobility devices by two methods; either by device or by user profile. The best practice is to associate the Extension Mobility profile to the CCE Application User on UC Manager.
Because the Unified IP IVR also communicates with Unified CM using the same JTAPI protocol, these same three types of communications also occur with the Unified IP IVR. Unlike Unified CCE, the Unified IP IVR provides both the application itself and the devices to be monitored and controlled.
The devices that Unified CCE monitors and controls are the physical phones. The Unified IP IVR does not have physical ports like a traditional IVR. Its ports are logical ports (independent software tasks or threads running on the Unified IP IVR application server) called CTI Ports. For each CTI Port on the Unified IP IVR, there needs to be a CTI Port device defined in Unified CM.
Unlike a traditional PBX or telephony switch, Unified CM does not select the Unified IP IVR port to which it sends the call. Instead, when a call needs to be made to a DN that is associated with a CTI Route Point that is associated with a Unified IP IVR JTAPI user, Unified CM asks the Unified IP IVR (through JTAPI routing control) which CTI Port (device) handles the call. Assuming the Unified IP IVR has an available CTI Port, the Unified IP IVR responds to the Unified CM routing control request with the Unified CM device identifier of the CTI Port that is going to handle that call.
The following scenarios are examples of device and call control performed by the Unified IP IVR.
- When an available CTI Port is allocated to the call, a Unified IP IVR workflow is started within the Unified IP IVR. When the Unified IP IVR workflow executes the accept step, a JTAPI message is sent to Unified CM to answer the call on behalf of that CTI Port (device). When the Unified IP IVR workflow wants the call transferred or released, it again instructs Unified CM on what to do with that call.
- When a caller releases the call while interacting with the Unified IP IVR, the Voice Gateway detects the caller release and notifies Unified CM by using H.323 or Media Gateway Control Protocol (MGCP), which then notifies the Unified IP IVR by using JTAPI. When DTMF tones are detected by the Voice Gateway, it notifies Unified CM via H.245 or MGCP, which then notifies the Unified IP IVR through JTAPI.
In order for the CTI Port device control and monitoring to occur, the CTI Port devices on Unified CM must be associated with the appropriate Unified IP IVR JTAPI user ID. If you have two 150-port Unified IP IVRs, you have 300 CTI ports. Half of the CTI ports are associated with JTAPI user Unified IP IVR 1, and the other half of the CTI ports are associated with JTAPI user Unified IP IVR 2.
While Unified CM can be configured to route calls to Unified IP IVRs on its own, routing of calls to the Unified IP IVRs in a Unified CCE environment is done by Unified CCE (even if you have only one Unified IP IVR and all calls require an initial IVR treatment). Doing so ensures proper Unified CCE reporting. For deployments with multiple Unified IP IVRs, this routing practice also allows Unified CCE to load-balance calls across the multiple Unified IP IVRs.
Design Warning: SIP, JTAPI and DTMF
From the UCCE 9.x SRND:
Unified IP IVR is notified of caller entered digits (DTMF input) by way of JTAPI messages from Unified CM. Unified IP IVR and Unified CM do not support mechanisms to detect in-band DTMF digits. In deployments with SIP Voice Gateways or SIP phones that support only in-band DTMF (or are configured to use in-band DTMF In accordance with RFC 2833), Unified CM must invoke an MTP resource to convert the in-band DTMF signaling to out-of band signaling so that the Unified IP IVR can be notified of caller entered digits.
Therefore, in environments that include SIP phones or gateways, it is necessary to provision sufficient MTP resources. Keep this in mind if the phones need to interact with Unified IP IVR. Likewise, CTI ports do not support in-band DTMF (RFC 2833). The Mobile Agent feature relies on CTI ports, so MTP resources are required when in-band DTMF (RFC 2833) is negotiated. SIP trunking is supported using CVP deployments with Cisco IOS gateways (IOS GW) and Unified Border Elements (CUBE).
No comments:
Post a Comment