Summary:	ASTERISK-15484: DTMF not detected at all from Sipgate despite TCPDump showing keypresses
Reporter:	Daniel Richards (d_richards)	Labels:
Date Opened:	2010-01-21 03:29:11.000-0600	Date Closed:	2011-07-27 13:43:15
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/RTP
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	V: 1.6.2.1 Issue is with incoming calls from ITSP 'Sipgate'. DTMF keypresses are not detected when they enter Sipgate from the PSTN network, despite being clearly visible with a TCPDump. There are some very slight differences in the events: (this may help to visualise: http://www.fotobytes.co.uk/user22171/dtmf_debug.php ) WORKING DETECTION: 1... .... = Marker: True Payload type: telephone-event (101) ..00 0000 = Volume: 0 Event Duration: 480 FAILED DETECTION: 0... .... = Marker: False Payload type: Unknown (101) ..00 1010 = Volume: 10 Event Duration: 1280 Initially considered this to be config/Sipgate but after several weeks of tweaking, changes, reading up and consultation with Sipgate this looks like Asterisk could be to blame. Have tried with Linksys ATA and it detects the DTMF coming in from Sipgate flawlessly, which tends to support the issue is at least partially with Asterisk.
Comments:	By: Leif Madsen (lmadsen) 2010-01-28 15:02:03.000-0600 I think this is the issue... Payload type: telephone-event (101)   vs.    Payload type: Unknown (101) Its my belief that the gateway that SIPgate is using is not declaring the payload type correctly, and because of this Asterisk doesn't know what is going on with the DTMF (or that its DTMF at all?). Because Asterisk should be RFC compliant, I'd like to see where it says in the RFC that we should be able to accept this type of payload type and know what it is. By: Daniel Richards (d_richards) 2010-01-28 23:47:14.000-0600 I agree that it appears to be badly formed - however Wireshark is able to work out that it is a DTMF keypress - as does my PAP2, Draytek Voice Gateway, Grandstream Adaptor, Swissvoice IP10s  - so the oddball here is {as ever} Asterisk. I guess all those other devices arn't RFC compliant? Looking at RFC2833 it states: "This payload format is used for five different types of signals: o  DTMF tones (Section 3.10); o  fax-related tones (Section 3.11); o  standard subscriber line tones (Section 3.12); o  country-specific subscriber line tones (Section 3.13) and; o  trunk events (Section 3.14). A compliant implementation MUST support the events listed in Table 1" It's clear to see from the TCPDump that the event type of DTMF tone is present and other hardware detects it without issue - so this has to come down to how Asterisk implements RFC2833. Again I agree that the formation of the sent data is not ideal, but the event is clear to see, unless the way you are looking for the data is also 'not ideal'. Such as depending on 'telephone event' rather than '101'. As those that develop Asterisk seem to want to argue all the time, and fix nothing - please close this issue. I know no matter how much time I waste looking at this, you'll never fix it. I don't have time to waste with a toy like this that half works. If I need a broken PBX in the future - with a high cost of ownership I'll revist Asterisk. Thanks for your time. By: Terry Wilson (twilson) 2010-03-03 22:47:10.000-0600 Woah, d_richards. Calm down.  I don't think anyone was arguing with you--lmadsen was just asking for the information required to solve the issue. Looking at the code in trunk, anyway, it does look like we match on the name. I believe that rfc2833 dtmf is a dynamically numbered payload and therefor some other device could use 101 for something completely different than a telephone-event. We just have to make sure that anything we do doesn't break other devices. Standards are there for a reason and we try very hard to follow them.  If it is possible to make other broken implementations work without breaking compliant ones, we often will do that. It is just something that has to be done very carefully--hence why lmadsen was asking questions. There certainly is no need for vitriol. By: Justin Sharp (sharpone) 2010-03-23 16:29:57 I believe I've hit a similar issue in 1.4.30 RFC2833 DTMF is unreliable when volume is set to 10. In asterisk version 1.4.26 volume was set to 5 and was reliable. Since volume is the absolute value of -gain dBm0 (according to the RFC) 10 is a lower volume than 5, (or 0 for that matter) and may be why some PSTN type equipment is having a hard time understanding it. It would be nice if this was a configurable setting. I'm not 100% sure that volume is the issue, however in studying the packet dumps, its the only difference I can see. I will be rolling back to 1.4.26 since I know it works, and DTMF is critical for our sales people being able to reach their prospects. By: Leif Madsen (lmadsen) 2010-03-24 13:31:02 I admit to not being an RFC2833 expert, but I'm not sure how volume makes a different here. RFC2833 is an out-of-band signalling method for DTMF, so there should just be packets that signal start and stop of the DTMF. Or am I missing something fundamental here? By: Justin Sharp (sharpone) 2010-03-24 13:48:17 Sure, rfc2833 is out of band, however why the need for a volume indicator in the first place since rfc2833 is out of band? The answer is most likely that somewhere down the line of the call, DTMF must be translated and go inband (i.e. if the destination is still analog), otherwise there would be no need of volume/signal level at all. I'm no expert either, it's just a hypothesis, but one which for all intents and purposes seems to be correct in my limited testing. I rolled back to 1.4.26 last night and tested all of the numbers that our employees had complained about DTMF not recognizing, or requiring multiple presses to recognize. The result, every single number worked with single presses of keys, every time. Analyzing the packet dumps showed the ONLY difference in the RTP EVENT packets to be the volume bits were 5 instead of 10 (decimal). According to the RFC: "The [volume] range of valid DTMF is from 0 to -36 dBm0 (must accept)" however, in practice -5 is the lowest I've been able to go and still have reliable detection on the destinations we are calling. By: Terry Wilson (twilson) 2010-03-24 13:54:05 There was a change in dtmf handling that broke things for some users a while back that made it into all branches. It was fixed on March 12 in SVN. If you were having trouble with 1.4.30, but not 1.4.26, then could I get you to try checking out from the 1.4 SVN branch and testing that to see if it fixes your issue? Another way to similarly test would be to use 1.4.30, but add "constantssrc=yes" in sip.conf. By: Russell Bryant (russell) 2011-07-27 13:43:09.701-0500 Per the Asterisk maintenance timeline page at http://www.asterisk.org/asterisk-versions maintenance (bug) support for the 1.4 and 1.6.x branches has ended. For continued maintenance support please move to the 1.8 branch which is a long term support (LTS) branch. For more information about branch support, please see https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions If this is still an issue, please open a new issue so it can be re-triaged appropriately. Thanks!