5

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.

Improve this question
2
  • What is the inbound connection mechanism? Are you taking PRI's from the LEC or SIP trunks?
    – rnxrx
    Jul 6, 2012 at 15:30
  • @rnxrx, I am using SIP trunks. However since posting this we have further isolated the problem it seems to only happen with certain mobiles. I am updating the post.
    – Eugene van der Merwe
    Jul 10, 2012 at 10:00

2 Answers 2

Reset to default
2

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.

Improve this answer
2
  • Thanks we have checked with our upstream and we are waiting for feedback from them. What's strange about this problem it just started happening out of the blue about two months ago.
    – Eugene van der Merwe
    Aug 1, 2012 at 6:23
  • 1
    We put a huge amount of pressure on the upstream to tell us what's up after discovering adding trunks for other provider's work. What baffles the upstream is that is seems to be a regional problem - from certain provinces in our country it works 100% on all cellular networks. From other provinces, such as the province in which we find ourselves, it doesn't work on the same provider's network. Although they haven't sorted it out I think at this point we can clearly see it's an upstream problem. Should they be unable to resolve we will unfortunately be forced to use another upstream.
    – Eugene van der Merwe
    Aug 27, 2012 at 9:39
1

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .