cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5410
Views
4
Helpful
16
Replies

Calls On Hold disconnecting after few seconds

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

16 Replies 16

Gajanan Pande
Cisco Employee
Cisco Employee

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.

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

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.

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

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.

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

Hi Geoff,

Attached is the config for the test CVP config.

Is this fine?

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

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

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

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

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

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


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

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: