Asterisk does not recognise DTMF tones from mobile phones
We have an Asterisk 1.8.7.0 (the Elastix derivative) switchboard.
Every since a month ago, seemingly out of the blue, the switchboard does not recognise DTMF tones any more from mobile phones.
- Testing the switchboard using 7777 works.
- Testing the switchboard from a normal phones works.
- Testing the switchboard from a mobile phone fails.
Looking at the log file I can't see anything. I used 'asterisk -rvvvv' and 'tail -f /var/log/asterisk/full' to see the live output and scan the logs. I guess I don't see anything because it's simply not recognising the DTMF tones.
I did brief research and found an old setting for SIP phones, 'rfc2833compensate=yes', and tried adding this to 'sip_general_custom.conf'. After that I did 'core restart when convenient' but that didn't make any difference.
Could anyone give me some additional troubleshooting steps?
Edit 10 July 2012:
Since posting this we have further isolated the problem. The mobiles affected are:
- Blackberry
- iPhone
- Android Ice Cream (Samsung Galaxy S II)
The following phones are not affected:
- Android Gingerbread (Samsung Galaxy S II, Samsung Tab)
- Normal land lines
Additional information:
We have an IVR, press '1' for technical support, press '2' for sales. If you know the extension of the person you would like to dial, press it now.
Before, you could press '1' at any time. Now, you have to wait till the very end before pressing '1'. If you wait, this works with all phones.
Solution 1:
Have you checked with your SIP Provider has anything changed on their end?
Ours once stopped supporting a codec without notification before. If you have not made a configuration change, you should check where a change may have occurred. A lot of problems originate with the sip trunk provider, so it is a good place to check.
Solution 2:
I would take a network capture (tcpump), see how the DTMF are received (SIP INFO or RTP packets or in the voice signal). If in RTP, check if there are out-of-order deliveries as asterisk was known to have a bug there. Try turning on RTP debugging as well.