I'm having difficulty determining the detailed steps of the call routing flow in IPCC
As I understand it:
0. (optional pre-route)
Call arrives at gateway
gateway passes call to CMGR
CMGR may transalate call DN to new DN.
CMgr makes route request to ICM using DNIS or DN(?)
ICM runs script with trans route included, then (?) sends a special trans label to the PG, informing it to wait for a call with a particular ID to arrive.
IPIVR runs it's script, then returns some kind of label to ICM, -- but I don't see the route points in ipivr as dns in ICM. Once this label arrives the trans route is complete, and the first route in the tranroute to vru node is ignored, call is sent to ?? the route in the tr node OR the route chosen in the script path after the trToVRU script node?
IPIVR gets the call again then requests CMgr to connect it.
Inbound Call Routing Decisions
There are three types of inbound call scenarios that can be configured in IPCC Enterprise with an IVR solution, pre-routing, post-routing and translation routing. A pre-routing call is sent by an IXC to determine an initial destination for a call. This is generally known as routing in the cloud. Post-routing describes a call that is received by a peripheral, such as an IVR, which will then refine the original destination or redirect the call. Lastly, translation routing is used to optimize cradle-to-grave call tracking, comprehensive reporting and Computer Telephony Integration (CTI). Translation routing ensures that the association between a call and its related data is maintained throughout the life of the call, enabling administrators to improve call center management and agents to enhance customer service. Translation routing will be used in the ICM/IVR deployment.
What is a translation route?
A translation route is a temporary destination for a call that allows other information to be delivered with the call. This is done by first delivering the call to the translation route. While the routing client , CallManager, is processing the call, the ICM delivers the final destination for the call, along with any call-related data, to the Peripheral Gateway IVR PG. The IVR then works with the PG to reroute the call to the ultimate peripheral target (IVR Script) and ensure that the appropriate information is also delivered.
When the ICM returns a translation route label to the routing client, it also sends a message directly to the Peripheral Gateway (PG) at the targeted peripheral. This message alerts the PG that a call will be arriving that requires route translation and contains the following information:
The trunk group on which the call will arrive and the DNIS value associated with it.
A label to be used by the PG to determine the ultimate skill target of the call.
Instructions for further processing such as a database lookup to be performed by the PG.
When the peripheral sees the call arrive on the specified trunk group and with the specified DNIS value, it passes this information to the IVR. The PG then combines this information with data it has received from the ICM and sends it, with the call, to the IVR script.
The Translation Route has an inherent relationship with the targeted. This association allows the ICM to notify the PG (IVR) that a call will be arriving on the DNIS associated with the peripheral target used in the Translation Route.
A single translation route can be used to send information to any number of different targets. However, the PG must uniquely identify the call in order to ensure that the call information is accurately delivered with the call. As a result, translation routing cannot be performed on two calls to the same peripheral target simultaneously. To avoid this, a set of peripheral targets, and routes, are typically defined for each translation route. This process is managed internally on IPCC, twenty translation routes have been created for each IVR. The formula to determine how many translation routes are necessary is, (Max(BHCA)/3600)*10*1.5. Using a calculation of 600 BHCA comes to 2.5 translation routes. It is best to error on the side of caution when dealing with translation routes which is why twenty were created for each IVR. Side effects of not having enough translation routes are dropped calls.
pleae rate helpful posts.
andy dignan - berbee
1. Inbound call is received by the voice gateway (Cisco 6608)
2. The voice gateway asks CallManager where to send the call (based on the DNIS)
3. CallManager determines that the DNIS is associated with the pguser (all CTI Route Point DNISs are associated with the pguser which talks to ICM) and sets up the call between the gateway and ICM.
4. ICM receives the call and routes it to the appropriate script based on the DNIS.
5. The ICM script sends the call through a Translation Route to VRU step which informs the IVR a call will be arriving.
6. The IVR chooses an available Translation Route, which is where the call is parked for a very short period of time while the call data is being passed by ICM to the IVR PG and finally to the IVR. Lastly, the IVR chooses an available CTI Port /IVR Port. This is where the call now resides while a customer is listening to prompts
7. The IVR returns the call back to ICM and the ICM Router chooses the next available agent and either delivers the call to that agent or returns the call to the IVR for queuing treatment.
please rate helpful posts.
andy dignan - berbee
OK, that's clear enough. But when I try to track the details so that I can implement it the details don't work out. Here's what I understand including some points where I can't figure out what happens enough to design and configure it myself. The Cisco doc sometimes obscures the details.
1. Call gets to Cisco gateway 6608
2. Gateway forms some type of RR to CMgr based on DNIS passed in from the gateway.
3. CMgr mapping: Looks up dnis and finds it is a route point.
i. Are all dnis passed into Cmgr route points?
ii. Does Cmgr lookup determine that this dnis is associated with the pguser; pg user is a Cmgr conduit to ICM. Cmgr makes a route request to ICM (?).
4. ICM recieves the route request, runs script according the the dnis passed by CMgr, which may not be the original dnis received by the telco.
5. The ICM script reaches a Trans Route to VRU node (this is the case Im interested in).
6. Here I need to figure out how to confige these myself Im responsible for that. Im confused about what happens next:
Unlike a standard routing node that resolves down to a route, the call is not sent yet any route. Instead the ICM informs the PG to wait (?) and the call is transferred to the VRU with some temporary label (?). Is this label determined by the 1st of the 2 routes in the trans route to VRU node?. How does the ICM choose this temp label it looks to me like it has the IP-IVR- route points known as JTAPI triggers configured as labels. But the label type is ACD/PBX! This is IPCC theres no ACD involved.
7. ? The IVR chooses another route? Where do I configure that? I thought we were still in the ICM script, passing out of the trans RouteToVRU node.
8. ?The The IVR, not ICM picks a CTI/IVR port; call sites there while the trans route script processes, maybe promting the customer and doing a database dip.
9. ? Once the IVR script is done it looks like the ICM trns routing script reaches a routing node and delivers the call to an agent? but it also looks like script flow jumps back and the call exits the trans route to VRU node. Around step 6 as you exlained it I cant figure out the details. So it either goes to an agent at this point, or parks it at the IVR. The IVR chooses a cti or IVR port and does ? next.
In step 6, I couldnt see in CRA AppAdmin where the trans routes are configured. Thought these were the sole provice of the ICM.
Is the ICM involved in every routing step, or does the VRU sometime take control and route without input from ICM? I'm guessing no, since only the ICM can select an agent... but what happens with RONA?
These are lenthy questions; I appreciate your time forming the answers.
6. Configure X number of Translation Route Points. Associate them to your "jtapiuser" (the CTI ports and Translation routes get accociated to the jtapiuser and the dialed numbers get associated to the pguser.
Next, in AppAdmin add a new "Application" and in the drop down box instead of Cisco Script Application choose Translation Route. Lastly, add your Translation Pattern Route Points as JTAPI triggers for this Application.
This .pdf takes you through configuring IPCC Enterprise from start to finish. The only difference is that instead of choosing "Post Routing" choose "ICM Translation Routing" for your application.
sorry here is the link to .pdf.
The link has changed it seems. May you pl let me know what is the name of this guide or post the latest link to this document.