cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2356
Views
0
Helpful
14
Replies

CUCM 10.5 and SIP Trunk EO issue

Hatem_Hamdi
Level 1
Level 1

Hi all,

I have a customer with CUCM 10.5(1) solution. He uses a SIP Trunk for PSTN calls. CUCM is integrated to the PSTN in the following manner. 

CUCM === CUBE === ITSP. The ITSP is using EO only so I have to check the "MTP Required" in the Trunk configuration on CUCM. I know that CUCM can do EO without MTP but I could not use it because I can't get supplementary services to work with it. 

My problem is the following : after reaching a certain number of calls (around 40), CUCM starts sending SIP invites without SDP which causes calls to fail. I don't think it is a problem with MTP shortage because a have the SIP Trunk's MRGL including an IOS software MTP with 500 sessions plus two MTP of CUCM IPVMS. 

What could the issue be? please advise?

Best  Regards

14 Replies 14

Jitender Bhandari
Cisco Employee
Cisco Employee

Hi,

 

Can you please provide traces for working and non working scenario, with calling and called party number for both.

 

JB

Hi Hatem_Hamdi,

 just to double check ... you are using G.711 between CUCM and CUBE, and you try to use CUCM with EO without success, because of that you use the 'MTP Required', am I correct?

Try to use the following command during your test just to check what is happening with the MTP:

 

# show dspfarm dsp all

 

Hope this helps.

Chris Deren
Hall of Fame
Hall of Fame

You do not need to check MTP on the sip trunk, in fact that is a bad idea.  Build a SIP profile that uses EO and invokes MTP "ONLY" when needed, i.e. DTMF mismatch.

Hi Chris,

I tried to do that but I had problem with some features such as confernce, call hold/resume, MoH.

That means you have some misconfiguration in your configuration.  For example you are using wrong DTMF method on your GW/CUCM, you need to ensure it's consistent with what the telco offers. I would recommend resolving this issue rather than attempting to use MTP for every call which is not going to be very scalable and efficient.

ctd_77801
Level 1
Level 1

Did you ever find the resolution to this?  We are having an identical problem. Thanks,

Hi,

 just to double check ... you are using G.711 between CUCM and CUBE, and you try to use CUCM with EO without success, because of that you use the 'MTP Required', am I correct?

 Try to use the following command during your test just to check what is happening with the MTP:

 # show dspfarm dsp all

Hope this helps.

Sorry, maybe I should start a new thread.  We are using a SIP trunk that requires MTP endpoint to a 3rd party IVR server.  We are having the identical issue  though after about 40 calls we notice CUCM no longer sending the SDP header when it initiates a session with the IVR, causing the IVR server to ignore the request.  This only happens when calling from an internal phone, external calls are routed directly to the IVR and since the IVR server initiates the session it is not looking for the SDP header and the call routes correctly. 

We have found a temporary solution of adding a router to be an MTP endpoint rather than using the CUCM, which will probably be better to offload that from the CUCM.

Thanks,

Hello Hatem,

did you find any solution? we are experiencing the same behaviour.

Edit: problem was the 48 call count limit under ip voice media streaming app service parameters

this is a limit to consider when designing voice network where mtp is necessary

Thanks

Giovanni

Hi Giovanni,

It is not always compulsory to use EO between CUCM and CUBE, if EO is the requirement between CUBE and provider. You can enable 'early-offer forced' in CUBE and let CUCM still uses DO (by default) while communicating with CUBE. You can check and let us know how it goes.

- Vivek

hello Vivek,

correct.

My environment is bit ditteferent. The sip trunk is beetween Callmanager and an Asterisk server (they need EO at the moment to negotiate media, don't ask why). And there is no routing between all the vlans in the network so mtp is mandatory at the moment.

The Symptom was similar (callmanager was not able to add SDP content in the invites "after reaching a certain number of calls (around 40)"

The reason is the limit of 48 mtp resourses (CUCM's MTP) avaiable by default

It's a temporary design we are migrating all the customer's infrastructure to callmanager/cube/hardware MTP

Actually, we incremented to the maximum (512) the number of MTP resourses avaiable in order to be able to let the RTP flow through CUCM for around 100/120 concurrent calls

IT'S NOT GOOD DESIGN, don't use unless you need in emergency situation!!!!!

Hi Giovanni,

So in that case, you will try to have CUBE in place at an earliest so that you can increase the number of sessions as and when required.

- Vivek

Exactly

Hi Giovanni,

Actually I didn't. After several troubleshooting sessions with the provider we couldn't make supplementary services to work with CUCM BE-EO : every mid-call Re-Invite breaks the call. So we stick with MTP and increased the capacity using IOS MTPs.

Regards

Hatem