Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

CUCM to CVP calls. CTI-RP vs Route Pattern

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
1 ACCEPTED SOLUTION

Accepted Solutions

You have to point the route

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

Done!!!

26 REPLIES

Kartik,The Route Pattern that

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

-Jameson
New Member

Thanks Jameson for taking the

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

From the beginning of the

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

-Jameson
New Member

 I am using Type 10. and Call

 

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

yes, both approach will work

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

New Member

If I make call by adding

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

Interesting... I may have to

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

-Jameson
New Member

Hi Jameson,

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

sand_miet1,

sand_miet1,

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

-Jameson

-Jameson
New Member

Hi team,

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.

Hey Ritesh,

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.

New Member

Dear Chintan,

Dear Chintan,

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

regards,

Ritesh Desai

Hey Ritesh,

Please ignore i see them attached.

looking at it

New Member

Chintan,

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

You have to point the route

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

Done!!!

New Member

Thanks mate...

Thanks mate...

I will check on this and come back with result. Give me sometime.

Thanks,

regards,

Ritesh Desai.

sure, please update the

sure, please update the thread when you have the results.

New Member

Chintan,

Chintan,

Need clarification on below flow what u mentioned earlier. Correct if am wrong.

--> 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)

Configured "6111> 192.168.83.241" under CVP call server > SIP > Local Static Routes.

CVP Logs: SIP 404, Abnormally ending.

--> 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 queried ICM using DNIS: 611111111140, ICM issued VRU label to CVP 811111111141

--> 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.

On CVP, System > Dialed Number Pattern > 8111* pointed 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

Bootstrap service is configured on gateway. On VG dial-peer config as below;

!

service bootstrap flash:bootstrap.tcl

!

DP 8111

service bootstrap

incoming called no 8111T

voice-class sip rel1xx disable

dtmf relay rtp nte

codec g711ulaw

no vad

!

Noticed is there is silence after dialling RP 3009 and disconnects after 1-2mins max. Result: FAIL.

Thanks...

regards,

Ritesh Desai

572: 192.168.83.245: May 09


572: 192.168.83.245: May 09 2016 18:54:34.658 +0530: %CVP_11_0_SIP-3-SIP_ERROR_SNMP: B2BUA is not configured with a route for making calls to [811111111141]. Please add this route. [id:5010]
573: 192.168.83.245: May 09 2016 18:54:34.658 +0530: %CVP_11_0_SIP-3-SIP_CALL_ERROR: CALLGUID = 5E91C7800001000000000040F853A8C0 LEGID = 5e91c780-73018f94-60-f853a8c0 - [INBOUND]: Destination URL is null, cannot make the transfer. [id:5004]


if you see in above logs, it says B2BUA is not configured for label 811111111141,
You might have added route for 81111> but not save and deploy.

do save and deploy and make sure configuration are delivered to CVP and test again.

And Don't forget to rate if it helps.

Regards,

Chintan

New Member

Chintan,

Chintan,

Now, am hitting calls on VG with q.850 Normal Clearing code (16). but  its playing CVP ERROR service 92929292.

on CVP I can see error saying Abnormal ending. SIP code 404 not found. Gateway call using SURV TCL flag.

PLs suggest.

regards,

Ritesh Desai.

Hey Ritesh, I am once again

Hey Ritesh, I am once again re emphasising on what i have already commented in previous thread.

the route to 8111111111! for CVP is missing. you have to configure it to point to VXML gateway on your CVP call server.

you may have added the static route and saved it, but would have forgot to do save and deploy.

if already saved and deployed, please try restarting CVP server and see of it helps.

New Member

That worked. I solved it. Was

That worked. I solved it. Was getting confused with Dialled Number Pattern under System tab and Device Mgmt > Unified CVP Call Server > SIP Service. Adding static and tested it worked.

But am getting 1 more issue and that is

On Softphone I can see the Label (611111111143) but there is silence for 1 min and call disconnects. At RunExtNode, call moves from X sign and releases. Audio Path is also correct. Codec also not an issue. Its not hitting Queue to SG. I restarted Call Server and VXML Server.

Pls suggest.

regards,

Ritesh Desai.

you may want to pursue the

you may want to pursue the other issue in separate thread, perhaps some one may be able to help you out there.

New Member

Thanks Chintan for guidance.

Thanks Chintan for guidance.

regards,

Ritesh Desai

How Does your Route pattern

How Does your Route pattern on CUCM to route VRU label look like?

the label is appended by cor ID, is your route pattern able to handle that?

i see in your above post that you have route pattern 611111XXXX, its incorrect.

it should be like 6111111111! (little "!" at the end to catch any thing which starts with 6111111111 and followed by anything)

VIP Super Bronze

Excellent answer Chintan.

Excellent answer Chintan. Great stuff! This really helped me to understand things better

Please rate all useful posts "The essence of christianity is not the enthronement but the obliteration of self --William Barclay"
2527
Views
0
Helpful
26
Replies