I am very new to the Asterisk world and will try to do my best with this.
We have an Asterisk conf. server and just recently, after 70 calls are up, callers get a message “password not valid” message. In the past, we were able to get hundreds of calls to this server. It has a one gig connection to our farm switch.
Calls are using SIP trunks to our Cisco Call Manager 8.6.2 Cisco says the Asterisk server is returning MRM::waiting_AllocateMtpResourceErr - ERROR - no resources are available
++++++++++++++++++++++++++++++++
INVITE sip:1240@172.18.69.26:5060 SIP/2.0
Via: SIP/2.0/UDP 172.18.69.17:5060;branch=z9hG4bK44b3a13a38d505
From: “Mason” sip:6812@172.18.69.17;tag=14333335~6a5e8fa5-1b3d-471f-a954-3f74705613f7-61374109
To: sip:1240@172.18.69.26
Date: Thu, 07 Nov 2013 14:05:47 GMT
Call-ID: b1d6f500-27b19e3b-27d561-114512ac@172.18.69.17
Supported: timer,resource-priority,replaces
Min-SE: 1800
User-Agent: Cisco-CUCM8.6
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY
CSeq: 101 INVITE
Expires: 180
Allow-Events: presence
Supported: X-cisco-srtp-fallback,X-cisco-original-called
Cisco-Guid: 2983654656-0000065536-0000190790-0289739436
Session-Expires: 1800
P-Asserted-Identity: “Mason” sip:6812@172.18.69.17
Remote-Party-ID: “Mason” sip:6812@172.18.69.17;party=calling;screen=yes;privacy=off
Contact: sip:6812@172.18.69.17:5060
Max-Forwards: 70
Content-Length: 0
+++++++++++++++++++++++++++++
In case of a good call, the MTP is properly allocated and the INVITE is sent out as an early offer and SDP attributes are sent along.
Can anyone help me with this? thanks, Dan
I forgot to add, this is the only thing I could find on the software version.
Kernel
Linux(x86_64) 2.6.18 238.12.1.el5
MTPs are Cisco resources, so the you are hitting a limit on the Cisco. You may be able to increase the number of MTPs, but, as it would naturally fall back to not using them, if it could, you won’t be able to disable their use in this case.
The Asterisk version is displayed in the opening banner when you run asterisk -r and is also included as a SIP header in all currently supported versions of Asterisk.
Some further detail. MTPs are Media Transfer Points. They mean that the UCM backbone servers need to be involved in the media path for a call. This will happen if the Cisco needs to transcode between different codecs, or if it needs to monitor the media stream, e.g. to detect DTMF signalling - basically the same things that stop Asterisk using an external bridge. You may find that using a PSTN gateway also forces their use.
You may be able to avoid them if you can avoid the reasons for employing them, e.g. make sure that the Asterisk codecs match the incoming ones. Make sure that the Cisco isn’t looking for DTMF, etc.
Thank you David!! That was it. Some of hardware MTP services in the Cisco Call Mgr. had become unknown. I had to go to those routers and restart sccp. I’m not sure why they would become unknown, but that was definitely the problem. Thanks again for your help!!!
I realize this issue is fixed, but some comments regarding CUCM 8 and Asterisk integration for any that might run into this or similar problems in the future:
Sounds like you have the SIP Trunk set up in CUCM to always require MTP. This will hairpin all the RTP through the available MTPs before sending to Asterisk or the endpoints. (In this case, I think you only had the software MTP in the CUCM left, which is why you were still able to do some calls. Look under System–>Service Parameters, Cisco IP Voice Media Streaming App to see the MTP settings and call limits.)
Anyhow, I have a similar CUCM & Asterisk platform in production, but I made sure to add an MTP resource while de-selecting the option to always require it on the CUCM SIP trunk. The CUCM platform will then use the MTP resources only when needed. (For example, some phones–like the Cisco 7936–can’t do RFC2833 DTMF, and Cisco will use the MTP to inject it into the RTP stream.)
Once you get it working this way, the only limit to the number of calls will be the CPU on the Asterisk box or the network itself. Personally, I’ve artifically load tested to around 3000 calls on a fairly beefy server, so I know it works.
Hope this is helpful to someone.
-Brian