Solved! Go to Solution.
You have to point the route pattern for VRU labels for CUCM to CVP SIP Trunks,
you can't point them directly to gateway and execute bootstrap service.
the VRU label sent to CUCM RC must be send to CVP sip service, now CVP sip service will once again query back the ICM where ICM will send one more label to CVP which CVP will use to locate VXML gateway.
e.g Call to CTI RP --> ICM will pass 6111111111! to CUCM
--> CUCM will match route pattern and send it directly to CVP or CUSP
-->if CUSP is used, the CUSP will point it to server group of CVPs
--> the label will come as new SIP invite to CVP sip service
--> CVP will break the label down with DN and CorID based on MAX DNIS length configured on call server (MAX DNIS length should always match the length of VRU label)
--> CVP Queries ICM with DNIS and CorID, ICM is able to identify the call based on CorID and issues one more VRU label to CVP(you configure separate VRU label for all Routing clients).
--> CVP finds VXML gateway for that VRU label based on Static routes or DNS SRV or what so ever your solution uses and sends the call to VXML gateway.
--> VXML gateway matches dial-peer for that label, runs bootstrap service, identifies the CVP from the request came and send HTTP request to IVR service of that CVP
The Route Pattern that is mentioned is used for connecting a call leg through CVP to a local VXML Gateway for media playback. The CTI Route Point is entirely different from the Route Pattern/Route List setup. Here's the basic call flow:
Yes, this is basically the same call flow for a fresh internal call to a queue, or an internal warm transfer to a queue. The CTI Route Point is needed in both cases. The Route Pattern/Route List combo is needed in both cases.
When you start looking at reporting, yes of course the two call scenarios are different. One is a transfer, the other isn't. The transferred call will have a more complex call history if you look at it in the TCDR.
From the standpoint of call legs, you will use less legs if you do a direct (one-step) transfer instead of a warm transfer. It is also simpler to maintain the call context in that case. In a warm transfer scenario, the agent is putting a caller on hold, then starting a new call, and joining the two calls together. The new call is coming from the agent, not the original caller. In a direct transfer, CVP just takes back the original call, potentially does more queuing, then sends the original caller to a new agent target.
Thanks Jameson for taking the time to reply.
But I was referring to a call flow which does NOT needs a CTI-RP at all vs one which does need. So:
Call Flow 1
There is a Route Pattern 15xx for eg pointing to CUCM-CVP SIP trunk
Call from an IP Phone to 1599 reaches CVP over the CUCM-CVP SIP trunk
CVP treats this as a new call and follows the normal comprehensive call flow
Call Flow 2
There is a CTI Route Point 1599 associated to pguser
Call from an IP Phone to 1599 reaches ICM, ICM send correlation ID to CUCM.RC
CUCM has a Route Pattern to send the correlation ID to CVP over the CUCM-CVP SIP Trunk and so on ...
What are your thoughts about Call Flow 1 above and difference between the 2 please? Call Flow 2 is more complex and needs a CTI-RP and Call Flow 1 doesn’t. I agree in the background we might see more complex reporting in TCD for Call Flow 2, but from an end user point both fresh internal call to a queue, or an internal warm transfer can be simple achieved by a wildcard Route Pattern [1-8]xxx for e.g. but what do I loose by doing this please?
From the beginning of the chapter you mention:
This chapter provides information about the minimal software component release requirements for the Unified ICME Warm Consult Transfer and Conference to Unified CVP feature for Type 2/7 VRUs. Resource sizing and configuration requirements are also included.
What CVP call flow model are you working with? I think the different call flows you mention are for different CVP models... (Comprehensive, Director, Standalone, etc.) I've never seen the "Call Flow 1" you mention on a Type 10 Comprehensive model.
I am using Type 10. and Call Flow 1 works.
Just added a wildcard Route Pattern [1-8]xxx (pointing to CUCM-CVP Sip trunk) and it used by both callers to make fresh new calls into the IT Helpdesk and also by agents for warm transfer purposes.
btw I also have the CTI-Ports warm transfer call configured and working on the same setup as well.
Thanks & Regards,
yes, both approach will work.
the only difference i felt using CTI Route Point in place of directing calls to CVP is
"ICM gets control of call on "
if you use CTI Route point then ICM will be in Control of call on very first step, and this is what people prefer in IPCC deployment.
so id there is some failure in call delivery, you can easily handle those in script.(e.g you are not able to transfer call to CVP)
in case of route pattern, ICM gets control of after call travers CUCM trunk to CVP, and then ICM.
i will give you one scenario:
if you are doing warm transfer using CTI RP, you have very good mechanism to choose available agent from skill before actually sending it to CVP queue.
you can put select node to select agent from skill, and if no available agent then you can send call to CVP for queue(send to VRU).
in this way you can minimise sending every call to CVP, even if agent is already ready to take call.
If I make call by adding transfer number via Route patterns --GW--CVP--ICM--CUCM then finesse show correct number like 7700156 if agent dials.
Now if we have redesigned our system and now agents are transferring through CTI route point and in this case if they transfer on 7700156 ---call goes to cti route point then ICM ,we have DN with 7700156 and call type mapped but what happens on finesse we get cucm label 888111.......which is actually translated on ICM and same show in finesse as well as on recording solution.
customer want to see 7700156 on finesse as well as on recording solution. Recording solution says we are showing whatever we are getting from Cisco.
We want to see actual transferred number not this CUCM VRU label on finesse
Call flow is agent--tranfers to 7700156---ICM---->cucm--->Route pattern(888111....)-->CVP---ICM--->bootstarp label----VXML gateway then agent landing
screen shot attached
Interesting... I may have to try that, though I'm not sure yet where I would use it over the CTI Route Points.
The big questions I see are:
Both of the above could have big effects on reporting, especially if you do anything with the TCD table. The second certainly has an effect if you do CTI screen pops.
One query ,If I had configured send to originator on CVP ops console Dialed number pattern & if my bootsraop number is 777777 then again it would send to CUCM? or to VXML
As per above post am following the same. Below is the info. Please guide.
1.Internal caller dials DN.
Caller able to dial DN3009 from IP Communicator
2.DN hits CTI RP in CUCM. CTI RP sends call to ICM.
Calls comes on ICM.
3.ICM matches DN to Call Type to Script, executes Script.
Yes. I can see call comes on ICM and can monitor the calls.
4.At some point, Script has either Send To VRU or a Run Ext. Script node.
Call moves from ‘X’ mark and releases the call.
5.ICM sends CUCM Network VRU label back to CUCM.
(Configuration available on Network VRU script Explorer) Label: 6111111111
6.CUCM routes label using Route Pattern and Route List. The CSS of the internal caller determines how this is modified, i.e. which prefix digits to add for determining VXML gateway to route to.
On CUCM, Trunk Pointing to CVP configured. Route Group, Route List and Route Pattern (611111XXXX) configured.
7.Call is sent to CVP through SIP trunk
SIP trunk is in Full Service.
8.CVP receives call, tells ICM it has the call.
9.CVP starts new call leg to VXML gateway with digit string to match bootstrap dial-peer.
On CVP > System > Dialled No pattern > 6111* routed to Voice Gateway cum VXML gateway.
#dial-peer voice 1001 voip
#incoming called no 6111T
10.VXML Gateway receives call, initiates bootstrap TCL and VXML magic.
On IP Communicator I see BUSY signal. On JTAPI and CUCM PIM1 logs I see BUSY message and call disconnect. On VG no debug logs getting generated. CTI Route point shows registered with ICM.
I can see RCK and RCD on CUCM PIM
On CUCM, my RP = 6111! pointed to VG.
On VG =
voice-class sip rel1xx disable