Summary:	ASTERISK-01478: Asterisk not dealing with DTMF very well from some SIP phones
Reporter:	jesses (jesses)	Labels:
Date Opened:	2004-04-27 16:15:20	Date Closed:	2011-06-07 14:10:45
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	I have tried a number of SIP software based phones with asterisk. I notice that many SIP phones are set to send DTMF inband and rfc2833 simultaniously. Some phones give you the ability to choose one or the other, but some send both at the same time and don't give you a choice. When I use SIP phones that send both at the same time, when I set sip.conf dtmfmode=rfc2833, it will catch duplicate, i.e. for every tone I send, asterisk will receive it twice. If I set dtmfmode=info or inband, it will just ignore the tones completely. Although the software makers should really give me the option of what kind of DTMF to send, I think asterisk should have a way to work with these types of phones.
Comments:	By: Brian West (bkw918) 2004-04-27 16:42:22 What phones?  I have a 7960 and it doesn't do this. By: jesses (jesses) 2004-04-27 16:46:37 The SIP EyeP phone from EyeP Media, the SIPPS phone from Ahead Software Ag, etc. It seems to be a reoccuring problem in software based SIP phones. By: jesses (jesses) 2004-04-27 18:07:44 Actually I did some more testing, if I set dtmf mode to inband, it will randomly accept or not accept tones. I tried it with a few different phones and I can't find any pattern to it. Sometimes it accepts every tone, sometimes no tones. Perhaps asterisk has a very tight threshold for the length of a received dtmf tone to be considered valid? edited on: 04-27-04 17:04 By: jesses (jesses) 2004-04-29 13:34:58 It seems that asterisk breaks rfc2833 section 3.2 which says that if a client sends overlapping tones, you must render only the rfc2833 tones and pass through the rest By: Mark Spencer (markster) 2004-04-29 20:42:18 If we both render the rfc2833 and pass through the tones in-band (which is what happens if you have asterisk set to rfc2833) then you get overlapped tones, which is precisely why this doesn't work calling out a gateway.  In any case, this has nothing to do with section 3.2 of RFC2833 which says that the endpoint MAY send audio and dtmf at the same time.  It does NOT say you can send the DTMF in-band and out of band at the same time.  It says it's RECOMMENDED that gateways only render the encoded tone since the audio may contain spurious tones, but it is not a requirement of the RFC and in any case is entirely irrelevant to the Asterisk model.