CUCM to CVP calls. CTI-RP vs Route Pattern

[Kartik Bhatia]

CVP 9 or above CUCM 9 or above Requirement: 1. Consultive Warm Transfer - The agents to be able to transfer calls to a a different department by dialing an internal number and wait in the queue until answered. 2. Internal - Back-office people to dial internal IT-Helpdesk or HR I see the above call flows as same, i.e. a Call Originating from CUCM to CVP .... correct me please? I have tested both and they both work exactly the same way, i.e. using a CTI-RP associated to PGUSER, ICM answers it sends correlation id to CUCM and CUCM sends this to CVP ...AND... using a simple route patters instead point to CUCM-CVP SIP trunk. Functionally they behave same way - ICM/CVP answers and queues call until answered. But the documentation confuses me, below snippet from CVP Config Guide "... Calls Originated by Unified CM Internal Help Desk calls: For these calls, the Unified Communication Manager (CM) phone user calls a CTI Route Point Consultative Warm Transfer: For these calls, a Unified CM agent places the caller on hold and dials in to Unified ICME to reach a second agent .... " And then on the same doc, there a Note (*1) Note For warm transfers, the call from Agent 1 to Agent 2 does not typically use a SIP Trunk, but you must configure the CTI Route Point for that dialed number on the Unified CM server and associate that number with your peripheral gateway user (PGUSER) (*2) And then again on the same doc under 'Unified ICME Warm Consult Transfer/Conference to Unified CVP' chapter/section it mentiones doing this using a Route Patter 'Create a route pattern and assign the route list to the route pattern' So the confusion is 1. Why treat these call flows as Internal and Warm Transfer - they are calls from CUCM to CVP for the same end result - queue the call and transfer to an agent? 2. Route pattern or CTI-RP, what diff it makes? They both behave the same way, so is there a diff from reporting point of view that a call to CTI-RP are treated as Transferred rather than new calls or what? 3. Also if you compare (*1) & (*2) above, they both talk about Warm Transfer and *1 says 'must use CTI-RP' and *2 says use a Route Pattern? Please assist. Thanks & Regards, Kartik

[Jameson Gagnepain]

Kartik,

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:

1. Internal caller dials DN
2. DN hits CTI RP in CUCM. CTI RP sends call to ICM.
3. ICM matches DN to Call Type to Script, executes Script.
4. At some point, Script has either Send To VRU or a Run Ext. Script node.
5. ICM sends CUCM Network VRU label back to CUCM.
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.
7. Call is sent to CVP through SIP trunk
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.
10. VXML Gateway receives call, initiates bootstrap TCL and VXML magic.

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.

-Jameson

[Kartik Bhatia]

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?

Kartik

[Jameson Gagnepain]

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.

-Jameson

[Kartik Bhatia]

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,

Kartik Bhatia

[Chintan Gajjar]

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.

regards

Chintan

[sand_miet1]

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.

plz reply

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

[Jameson Gagnepain]

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:

1. How does a warm transfer to your Route Pattern get treated by ICM reporting? In the TCD table, I suspect that the transfer to a Route Pattern gets a new RouterCallKey, with the RouterCallKeySequenceNumber starting over at 0.
2. In the warm transfer, is the original caller's information passed, or does it count as a call from the first Agent? I suspect the latter.

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.

-Jameson

[sand_miet1]

Hi Jameson,

1. Call is sent to CVP through SIP trunk
2. CVP receives call, tells ICM it has the call.
3. CVP starts new call leg to VXML gateway with digit string to match bootstrap dial-peer.

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

[Jameson Gagnepain]

sand_miet1,

I've never used "send to originator" in my environment, so I am not sure. Perhaps someone else here can answer.

-Jameson

[Ritesh Desai]

Hi team,

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
    #service bootstrap
    #incoming called no 6111T
    #Dtmf-relay rtp-nte
    #codec g711ulaw
    #no vad
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

regards,

RItesh Desai.

[Chintan Gajjar]

Hey Ritesh,

we will start with router and Pim logs, can you collect rtr and cucm pim logs for the call and post it here.

[Ritesh Desai]

Dear Chintan,

Sorry for long gap. I have attached ICM Router and CUCM PIM logs for reference.

regards,

Ritesh Desai

[Chintan Gajjar]

Please ignore i see them attached.

looking at it

[Ritesh Desai]

Chintan,

On CUCM, my RP = 6111! pointed to VG.

On VG =

DP 1004

destination-pattern 6111T

service bootstrap

voice-class sip rel1xx disable

dtmf-relay rtp-nte

codec g711-ulaw

no vad

regards,

Ritesh Desai