cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1947
Views
5
Helpful
20
Replies

CVP with SIP blind transfer ringback

Chris Deren
Hall of Fame
Hall of Fame

CVP 7 with SIP, I am noticing that when calls are blind transferred in order to play ringback I require an Announciator, which is not very bandwidth efficient. The only thing I can find in the documentation is to set the "send h225 user info message" to "h225 info for call progress tone", but this is only for H323 deployment. How do I make it work without annouciator with SIP?

CM version 7.0.2

CUPS 7.0.2

IOS 12.4.15T8

20 Replies 20

Chad Stachowicz
Level 6
Level 6

Chris,

I have had to do this at all of my SIP

style deployments. Maybe file it with the CCM TAC and see if you can get a feature request of some sort.

Chad

Chad,

You mean you had to use Annunicator to get it working?

I've opened TAC case and was referenced bug CSCsl08853 as workaround, I'll give it a try.

Chris

Ringback is played through the ringtone service on the gateway. Do you have all the static routes in the SIP Proxy for the ringtone label configured correctly? I have ringback on SIP warm transfers working and have never used the Annunciator to do this. Something is odd.

Regards,

Geoff

Geoff,

Rinback works initially when the call is ringing into agent by invoking the ringback tcl script, however when that call is answered and transfered to another destination then the rinback is not heard. I can get it to ring by either using annunicator or an MTP on the inbound SIP trunk.

I opened TAC case and was told this is a SIP limitation, but I am not convinced.

Chris

Chris,

That makes sense - by "inbound SIP trunk" I suppose you mean the CUCM SIP trunk to the Proxy server"?

Since I was working with an IOS prior to 12.4(15)T8, I required MTPs on this trunk anyway for SIP warm transfers. Plus I have agents in Auto Answer via CUCM so I may not have noticed the absence of ringback. All my deployments seem to use auto-answer.

Current customer is using T8 and we have no MTPs setup on the SIP trunks. I'll have to turn off auto-answer to check.

Please post back if you get some info through TAC (from the DE).

Regards,

Geoff

Geoff,

I have found thar even with T8 I still need MTPs for transfers to work, if I do not use MTP the first warm transfer works ok, but the second one fails. As a workaround I created site specific sip trunk for outboud only (with sip security profile using port other than 5060) with MTP enabled. Not sure what the issue here is, do multiple transfers work for you without MTP?

Also, i have another question related to another post we discussed. I have found that with sigDigits deploemtnt I cannot make calls to cti route points, I see the CM label being invoked and call is made to CVP (via CUPS) via matching route pattern, I see the call hitting CVP server, but the correlation never takes place and I do not see the VRU lebel being invoked. The same environemnt works fine when I change it not to use sigDigits. Have you been able to get routing to cti rp working with sigDigits feature?

Chris

Chris,

I have sigdigits with SIP and CTI RP working just fine. I'm guessing you have network trafser prefered on.

Also, if you used 12.4(22)T all those MTP's required on SIP Trunk's aren't needed anymore ;)

Chad

Chad,

network trafser prefered is not checked on neither CM nor VRU routing clients. The call simply fails the sendToVRU node and connects to error tcl script. Any idea what I may be missing?

Chris

Chris,

I have SIP.sigdigits set and I make SIP warm transfers from agents using DNP (Dialed Number Plan). I only need to keep context when agents do the transfer, so the DNP method is used. Let's say that the number called (an internal route point) to reach the routing script is 555 1234.

I also have CM generated calls working in two different ways (an IP phone cannot call a DNP).

A call can be placed from an IP phone at any site to 555 1234, which is a route point in CUCM that starts a routing script, Send to VRU kicks in and returns the transfer label on the CUCM RC.

In this method you cannot choose the gateway - the proxy will round robin between all the gateways configured as static routes in the proxy for the CVP RC transfer label.

The third method is an IP phone can call 1234 with a site-specific prefix. An agent in the St Louis branch office calls (say) 314 1234 and using sigdigits this is a route pattern in CUCM that sends the call to CVP. Now the transfer label will have the sigdigits prepended and we can make it go back to the site gateway. This is not a context-keeping transfer - CVP sees it like a new call, but I don't care. It's a way for non-agent staff to call the contact center, or transfer a customer who has called them by their DID.

I prefer the first two methods (doesn't matter which site the agent is at, they call the same number) but you need to choose which gateways to queue the transfer on. I'm thinking that in a branch office environment, a couple or gateways at the data center is the way to go.

In another deployment I am doing which uses send to originator, I'm going to do exactly that - with send to originator, the transfer label is not needed in the proxy as a static route.

Now - to your problem.

Yes - it will work. Because you have SIP.sigdigits set (let's say sigdigits = 3), you need to make the CUCM label have three extra digits because CVP will strip them off.

Let's say without sigdigits you have 8222222222 as the NVRU label on the CUCM routing client. You also have 8222222222! as a route pattern in CUCM that sends it down the SIP trunk to the proxy, and you have a static route in the proxy for 8222222222* to find a CVP Call Server. 8111111111 is the label on the NVRU for the CVP RC and 8111111111* is configured in the proxy as a static route to the gateway.

Now with sigdigits, change the label on the NVRU for the CUCM RC to (say) 5558222222222. Change the route pattern and the static route to CVP.

When the call arrives at CVP it will strip off three digits (the 555) but the rest is valid and it can find the correlation ID in the usuual way, and then find the script it has paused.

If you look at the CVP log you will probably see how it's not finding the correlation ID correctly.

Now on the way back out, CVP is going to put 555 in front of the 8111111111 so you need to have a static route to the gateway on 5558111111111* and a dial peer 5558111111111T on the gateway for the bootstrap to match this.

Once sigdigits is on, CVP is absolutely rutheless and will strip off three digits on any number that comes in, and will apply those digits to any number on the way out - transfer labels, error labels, ringtone labels. Everything.

Regards,

Geoff

That's exactly what I am doing. My CM label is 222222 (tried it with 2222222222 as well, due to max DNIS lenght on CVP), CVP label is 1111111111. Route pattern in CM is 22222! and it prefixes 8000, this RP points to CUPS and static route points to CVP. Call arrives to CVP, but immediately gets routed to error label.

I have 80001111111111* static route pointing to VXML GW. which invokes bootstrap. It does not look like the VRU leg ever gets engaged.

Chris

Guys,

Anything else I may be missing?

Chris

Chris, check the CVP log for an error. Turn on the DynaSoft library with the CVP Debug web page to see all the SIP messages.

Look in the proxy logs to see an error like "failed lookup for pattern xxx".

Regards,

Geoff

Geoff,

Proxy only sees the initial INVITE and TRY to the CM label, but never sees any call to VRU label, same thing in CVP logs, nothing for the VRU label.

Chris

Is there any documentation stating that 12.4.22T does not require any MTPs anymore?

Chris

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: