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
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.
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.
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.
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.
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).
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?
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 ;)
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?
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.
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, 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".
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.
I got this resolved, I needed to make the CM label 4 digits longer than my VRU label to compensate for the sigDigits. So my CM label ended up being 22222222222222, route pattern prefixes 8000, the CVP max-dnis is 14. Not sure why this is the case but it works now.
Not that I have found specifically. I just know Corey V which participates on the board moved one of our CC's there for this. And here in the US we just eliminated MTP on SIP trunk from PSTN to SIP Trunk to CCM with CUBE on all supplimentary services. Really just know from experience. we use 12.4(22)YB on the lastest project though. Believe Corey uses the T Train.
On the CUBE we us 12.4(22)T1. On the VXML gateway we use 12.4(15)T8. On a combined TDM/VXML gateway (38xx series) we use 12.4(15)T8.
The BOM says the 38xx gateway has two supported IOS trains:
"12.4(15) T4 or later T releases
12.4(20) T1 or later T releases"
12.4(15)T8 resolves the MTP problem.
>I got this resolved, I needed to make the CM label 4 digits longer than my VRU label to compensate for the sigDigits
That's exactly what I was saying when I noted:
"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."
I was pointing you in the right direction.