What is the difference between ucce and icm
For example, with CVP customers can:. Each Dial Interactive project is structured to fit your specific needs. Dial Interactive begins by working jointly with your organization to gain a solid understanding of your business strategy, environment and process architecture that will drive the technology and application requirements. This involves looking closely at your existing business logic, call flows and scripts.
This mechanism enables Unified ICM to retrieve the appropriate call context for this same call, which at this stage is to proceed to the IVR portion of the call. These two correlation mechanisms operate as follows:. Unified ICM 7. CUCM must be configured to handle these arbitrary extra digits.
Cisco Unified ICM 7. However, they differ on how they connect to the VRU. However, the difference between these two types is in how they release the VRU leg and how they connect the call to the final destination. In Type 7, the switch cannot take the call away from the VRU. When the IVR treatment is complete, Unified ICM must disconnect or release the VRU leg before the final connect message can be sent to the Switch leg to instruct the switch to connect the call to the destination.
It is somewhat more efficient under Type 7 because it gets a positive indication from Unified ICM when its VRU leg is no longer needed as opposed to waiting for the VoiceXML gateway to inform it that the call has been pulled away. As stated previously, there are two legs of the call: the Switch leg and the VRU leg. However, they differ in how they connect the call to the final destination.
Type 2 is used when the switch does not have the capability to take the call away from the VRU to deliver it to an agent. The VRU effectively assumes control of the switching responsibilities when it receives the call. This process is known as a handoff. A Network VRU entry has two pieces of information:. Type: This is a number from 2 to 10 and corresponds to the types previously described. They are also required but never used in the case of Type 5.
Each label is made up of two parts:. However, in one specific case Types 3 or 7 is still required. Network VRU configuration entries have no value until they are associated with active calls. There are three places in Unified ICM where this association is made:. Depending on the call flow model, Unified ICM looks at either the peripheral or the customer instance to determine how to transfer a call to a VRU.
To examine how these VRU types interact with the previously defined Unified CVP Functional Deployment models, it is necessary to define the different variances of these models as such:. Therefore a Network VRU is not needed.
Because this model does not provide queuing or self-service, there is no VRU leg. Therefore, a Network VRU setting is not required. In this model however, Unified CVP devices act as both the Switch and VRU leg, but interestingly enough, the call does not need to be transferred from the switch leg to the VRU leg before a call treatment can occur. Deployments using Unified ICM 7. By using this node in the routing script, an incremental step is provided testing the viability of the VRU components of the solution.
From a call routing and Network VRU perspective, this model is identical to Model 3a previously described. However, depending on which kind of NIC is used, it might be required to take over the Switch leg when it receives the call. This model actually has two submodels, which are described separately in the following sections. It further assumes that if the agent is requesting that the call be retransferred to another agent or back into queue or self-service, the NIC can retrieve the call from the agent and redeliver it as requested.
There are two variants of this submodel, depending on whether the Correlation ID or the Translation Route mechanism is used to transfer calls to the VRU. There are a few exceptions to this rule, in which case the Correlation ID mechanism can be used. The peripherals need not be associated with any Network VRU. In that way, an unnecessary delivery and removal from Unified CVP can be avoided when the requested agent is already available.
When the call is delivered, the NIC cannot be instructed to retrieve the call and redeliver it somewhere else. In these cases, Unified CVP can take control of the switching responsibilities for the call. From the perspective of Unified ICM, this process is known as a handoff. Calls that fit this particular submodel must use the Translation Route mechanism to transfer calls to the VRU.
There is no way to implement a handoff using the Correlation ID mechanism. To implement this model with Unified ICM 7. If the call is going to the VRU leg because it is being queued, generally these two nodes should appear after the Queue node.
In that way, an unnecessary delivery and removal from Unified CVP can be avoided if the requested agent is already available. Two different VRU transfer nodes are required.
When the call is sent to the available call center agent's phone, if the agent does not answer within the timout duration, the call is sent back to the queue.
It is not lost. RONA or calls missed by the agents is a commonly used performance criteria. It is an unwanted situation and agent performance is measured with the number of calls missed as well as the other parameters. If the call waits too long in the queue, your routing script may send the call to another queue or a phone number.
In this case, the call is taken out of the current queue and marked as "Dequeued" in the reports. So, the call is not abandoned or answered but taken out of the queue and sent to an alternate destination. This can be another queue or a phone number such as voicemail or outsourcer.