02-01-2012 01:19 AM - edited 03-14-2019 09:16 AM
Hi,
We have the following setup
Hosted IPCC 8.5
CVP 8.5
UCM 8.5
this is newly deployed setup, call center is working, agents are complaining the calls are randomly disconnect while they put the customer on hold, same time we have tested customer end, it is playing CVP error message 92929292.
We have tested another scenarion with normal IPT calls without invoking CVP/ICM, in this scenario calls are not disconnecting during the hold.
Hope we have missed some config or need some tune-up work. Please help us.
with Regards,
Manivannan
02-01-2012 02:25 AM
Mani,
If the calls are dropped as soon as hold button is pressed then enabling MTP would fix this issue. Is that the case ?
GP.
02-01-2012 10:49 PM
Dear Gajanan,
We have total 7 voice gateways and have 7 sip trunks to UCM, none of the Voice gateway sip trunks having MTP enabled, but it is working fine, but only two Voice Trunks only having this issue (hold calls disconnecting).
So we have enabled MTP on trunks it is working, could you please advise us, why this is working without MTP enabled on other voice gateways, we would like to know the root causes.
with Regards,
Manivannan
05-12-2012 11:47 PM
we are getting sip media timeout error on the VG, seems we have to increase some timer and found
timer receive-rtcp 120 been resolved the issue, but still under observation.
05-13-2012 06:50 AM
You need to understand how that timer works. In timer receive-rtcp M , M is a multiplier - it multiplies the value of ip rtcp report interval to produce the timeout value. The default for the interval is 5000 msec - so if you don't have this defined, then 5 seconds is in action. The default for the multiplier is 5 - so 5x5 = 25s. By setting the mutiplier to 120 you have extended the timer to 600 seconds, which is far too long and will give you other problems.
Normally RTP packets help with the SIP media activity detection, but there can be periods where RTP is not being transmitted, so RTCP is a better way to control media detection. If you have VAD set on your dial peer, RTP may not be sent during silence. The recommendation is to have
no vad
set on all your CVP dial peers. Do you have that set?
Define
ip rtcp report interval 5000
timer receive-rtcp 4
See http://www.cisco.com/en/US/docs/ios/12_2/12_2x/12_2xb/feature/guide/ftsiprtp.html
Please don't use MTPs. You don't need them when CVP is configured correctly. What sort of MTPs are you using?
I have another question for you. What are these SIP trunks from CUCM to the 7 voice gateways for?
Regards,
Geoff
05-14-2012 12:56 AM
Thanks for the input,
We have seven sip trunks to voice gateway out of the 7 we have one trunk mtp enabled, other six are not enabled, it is software MTP configured.
I would like to have an review of call flow because it may be some wrong configration in our setup let me list out please correct or share your idea
Call is coming to Voice Gateway (PSTN - PRI)
Translation to ICM Dialed number 8XXX
We have the dial-peers (4 nos to 4 CVP) with hunt configuration
off-course no vad is configured.
dial-peer voice 8889 voip
destination-pattern 88..$
session protocol sipv2
session target ipv4:172.25.7.164
dtmf-relay rtp-nte
codec g711ulaw
no vad
We dont have any SIP proxy in our setup
So we have configured on the cvp oamp
local static routes
88>172.25.14.100
88>172.25.14.101
88>172.25.14.104
88>172.25.14.106
88>172.25.14.107
88>172.25.24.103
(We understood this is for incoming pattern from the voice gateway to cvp server)
as usual through the CVP PG send the route request to icm, and icm sends back the coorelation ID to cvp
Now CVP send back the coorelation ID to orginator (voice gateway) 8001234567
In CVP oamp
In Advanced Configuration --> Dialed Number (DN) patterns
91919191
92929292
8001234567>
2>
3>
4>
configured. (2>, 3> 4> extension number agent)
On the VG we have the dial-peer configured for coorelation ID
dial-peer voice 801 voip
translation-profile incoming block
service bootstrap
session protocol sipv2
incoming called-number 8001234567T
voice-class codec 1
dtmf-relay rtp-nte h245-signal h245-alphanumeric
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 falback none
icpif 25
no vad
and we have the dial-peer for extension number
dial-peer voice 2001 voip
destination-pattern 2...$
session protocol sipv2
session target ipv4:172.25.27.10
session target transport udp
dtmf-relay sip-notify
codec g711ulaw
no vad
as well as we have the dial-peer 91919191 (ringtone) and 92929292 (cvperror)
kindly cross check and update us for any tune-up.
05-14-2012 05:33 AM
You have some work to do.
We dont have any SIP proxy in our setup
So we have configured on the cvp oamp
local static routes
88>172.25.14.100
88>172.25.14.101
88>172.25.14.104
88>172.25.14.106
88>172.25.14.107
88>172.25.24.103
(We understood this is for incoming pattern from the voice gateway to cvp server)
Those are useless and don't do anything. Static routes in the Ops Console are for outbound calls from CVP.
The gateway finds a CVP server for the imcoming call through the set of dial peers - I assume you have 4 equal preference dial peers. You could also do that through local SRV on the gwy.
Send To Originator is configured, so you correctly have
In Advanced Configuration --> Dialed Number (DN) patterns
91919191
92929292
8001234567>
to send the transfer label 8001234567+corr id back to the originating gateway. You also send ringtone and error to the originating gateway. Correct.
Now the VXML is playing on the ingress/VXML gateway, and an agent becomes available. You need to get the call to an agent and agent phones are (something like) 2XXXX, 3XXXX, 4XXXX. So you need to have a static route to your subscriber - something like
2>,172.25.27.10
3>,172.25.27.10
4>,172.25.27.10
will work for 1 Sub. For this to work you need to have SIP trunks from your CUCM to each of your Call Servers (not to the gateway). Having
In CVP oamp
In Advanced Configuration --> Dialed Number (DN) patterns
2>
3>
4>
configured. (2>, 3> 4> extension number agent)
in the Send To Originator section is wrong. You don't want these going to the gateway where you have a dial peer sending it to the subscribers, and your SIP trunks from CUCM to the 7 gateways. That's all messed up.
But if you have more than 1 sub (of course you do), you need to use a cluster name for these routes and configure SRV plus local SRV. You need to have
2>,cvp.foo.icm
3>,cvp.foo.icm
4>,cvp.foo.icm
and configure cvp.foo.icm as the cluster name, set use SRV, local SRV and configure SRV.xml to load balance your Subscribers.
Regards,
Geoff
05-14-2012 11:16 AM
Hi Geoff,
Attached is the config for the test CVP config.
Is this fine?
05-14-2012 11:46 AM
Sandeep and Manivannan - are you a team?
Well that is nothing like what Manivannan described. Are these proposed changes?
If so, I think you must configure the FQDN to match the cluster name = cucm.test.com
I guess that 172.25.27.10 and 172.25.27.11 are two Subs - is that all you have, just 2 - and you are trying to create a Server Group to load balance the Call Managers. It will send the SIP OPTION PING as a heartbeat to the Subs and also work like an SRV. That's the best you can do without a proxy.
Talk to me about those crazy SIP trunks you have.
Regards,
Geoff
05-14-2012 01:22 PM
Geoff,
yes, we are working together on this. these are the proposed changes.
I have created the server group and added the configuration to the CVP sip service but the calls are still not going to the extension. if we add the 2> in the dialed number pattern then the call lands on the agent phone.
in this case the sip trunk is used by the gateway to send call to the cucm.
also we have different teams making outbound calls and then we have supervisors and other admin people using sip trunks for outbound calls.
Regards,
Sandeep
05-14-2012 03:29 PM
I have created the server group and added the configuration to the CVP sip service but the calls are still not going to the extension.
So in the static routes you have addeed
2>,cup.test.com
and you have set the FQDN to cup.test.com and restarted CVP Call Server?
And you HAVE created SIP trunks, RFC 2833 between the Subs and your CVP Call Servers?
All three things - yes?
I really don't care if outbounders are using SIP trunks to the gateway - that is independent of CVP. You are doing it the wrong way and there will be side effects (such as needing to apply MTP - a sure sign that something is wrong).
Take out the 2> that you put in the send to originator section and try to solve the problem. Trust me - you can make it right. Turn on DEBUG on the Dynasoft library and watch the SIP messages. You will see what you are doing wrong.
Regards,
Geoff
05-15-2012 04:49 AM
Hi Geoff,
As discussed earlier on a different thread, looking on the static routes on the CVP
88>172.25.14.100
88>172.25.14.101
88>172.25.14.104
88>172.25.14.106
88>172.25.14.107
88>172.25.24.103
This static routes in CVP will take only the first static route if both are identical
Regards,
Dass
05-15-2012 07:10 AM
But those routes don't do anything. The gateway chooses a CVP through the dial peer. Static routes are for outbound calls from CVP - not inbound calls.
I agree with you that identical static routes in CVP do not load balance - we did go through this in a previous discussion.
Regards,
Geoff
05-16-2012 12:41 AM
Hi Geoff,
We have enabled the logs and found the error we are getting as below
B2BUA is not configured with a route for making calls to [2192]. Please add this route. [id:5010]
SIP trunk configured properly - CUCM - CVP (CSS configured correctly ,
RFC 2833)
Seems to be some other config is missing
with Regards,
manivannan
05-16-2012 02:54 AM
If so, I think you must configure the FQDN to match the cluster name = cucm.test.com
configuring this in the Server group as mentioned in the picture above is not sufficient? do we have to configure this on the gateways or proxy?
"Release 8.0(1) adds this configuration into the Operations Console SIP subsystem using the Server
Groups concept. The Server Group term just refers to the local SRV configuration. When you turn on
Server Groups with Heartbeating, you get the dynamic routing capability for Unified CVP to
preemptively monitor the status of endpoints. This feature only covers outbound calls from Unified CVP.
To cover the inbound calls to Unified CVP, the CUSP proxy server can send similar heartbeats to Unified
CVP, which can respond with status responses."
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: