Summary:	ASTERISK-05024: Asterisk does not recognizes DTMF when is dialed TOO FAST and numbers are repeated. Using Cisco DTMF (type 121)
Reporter:	Sebastian Nocetti (snocetti)	Labels:
Date Opened:	2005-09-08 10:09:04	Date Closed:	2008-01-15 15:53:09.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Interoperability
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	When I send DTMF from a Cisco-5300 using OUT OF BAND, and RFC2833 on ASTERISK SIDE, if I dial TOO FAST the numbers, asterisk only recognizes 1 of them EXAMPLES. If I dial: 123456 FAST, using app_get_data to obtain numbers, asterisk works OK. If I dial: 112233 FAST, using app_get_data to obtain numbers, asterisk only recognizes 123, it is like second number that is repeated is not recognized, it happens all times. I dont know what kind of debug do you need... I tried with TCP-DUMP to see if packets are arryving, and they are!!... ****** ADDITIONAL INFORMATION ****** CONFIG: CISCO-5300 with DIAL-PEER VOIP with CISCO-RTP, H245-SIGNAL OUT OF BAND AND NO VAD Config. SIP.CONF with DTMF in RFC2833, all using G.729. Cisco has an E1 connected to PSTN.
Comments:	By: Michael Jerris (mikej) 2005-09-08 10:11:32 rtp debug of the digits being passed with verbose of the call and sip debug should do it. By: Sebastian Nocetti (snocetti) 2005-09-08 10:19:38 show me commands to launch and I will do it... By: Tilghman Lesher (tilghman) 2005-09-08 15:46:28 CLI> rtp debug <lots of debug output> CLI> rtp no debug By: Kevin P. Fleming (kpfleming) 2005-09-14 20:23:39 Please do _not_ post debug traces in a bugnote; they should be uploaded as files. Thanks. Unfortunately that trace does not show us the contents of the RTP packets, so we'll probably a need another set of traces, only this time capture the RTP packets (inbound and outbound) using tcpdump or ethereal at the same time so we can match up the raw packets with the messages in the trace log. By: Sebastian Nocetti (snocetti) 2005-09-14 22:55:23 Sorry, I did not know that, I will send TCPDUMP details soon, I dont have Ethereal, but I will try to install it so I can send a complete set of bugs... see you, sebas. By: Sebastian Nocetti (snocetti) 2005-09-15 10:22:12 all things i do with TCPDUMP or ETHEREAL ever show me same debug when I did RTP DEBUG into Asterisk.. I don't know how to do a deeper debug. If someone can help, I will appreciate that. By: Michael Jerris (mikej) 2005-09-15 15:56:29 This is specific to the parsing of type 121 rtp I beleive (cisco ism) which is also why we are not getting proper rtp debugs as you would typically expect from 2833.  This is most likely in process_cisco_dtmf howerver I have not taken a close look yet.  We need to add proper rtpdebug messages for cisco rfc2833 as we have for regular 2833. By: Brian West (bkw918) 2005-09-16 10:37:36 RFC2833 is type 101 in most cases.  I would also like to point out that this looks like an RTP bridge. By: Sebastian Nocetti (snocetti) 2005-09-16 10:52:22 so, how Can I help... I don't know how to look inside rtp packets, but if you see the debug, you will see that when I dial all 10 numbers, it seems like all packets are received (I marked it in debug).... I dont know why Asterisk did not process that... By: Sebastian Nocetti (snocetti) 2005-09-24 18:13:46 After doing some tests, I can say it does not happen using DTMF-RELAY RTP-NTE on cisco side, it only affects when CISCO-RTP is configured By: Kevin P. Fleming (kpfleming) 2005-09-25 23:33:08 This does not appear to be easily fixable... from my reading of process_cisco_dtmf(), the incoming RTP DTMF packets do not have an 'end' flag (unlike RFC2833), so we can only do the actual send once we have allowed a small amount of time to pass after receiving the digit (presumably in case it is repeated unintentionally). If the same digit arrives during that timeout, we cannot tell that it is a new instance of the digit being pressed, it appears to be a duplicate. Based on the code, this timeout appears to be roughly .375 seconds, so I don't really know how you could press keys and release them fast enough to trip this problem... We'll have to see the actual RTP packets themselves; if you have used tcpdump to capture the RTP packets, please upload that file so we can review it with Ethereal to see how the stream appears. By: Sebastian Nocetti (snocetti) 2005-09-26 00:08:18 I have used TCPDUMP to capture but I cant see inside packets... it is like tcpdump or ethereal cant see inside CISCO-RTP packets. By: Kevin P. Fleming (kpfleming) 2005-09-26 12:03:26 That's OK, I know how they are formatted and I can look in them manually if needed (they are very small). By: Olle Johansson (oej) 2005-10-11 23:22:22 Closing due to lack of response. By: Sebastian Nocetti (snocetti) 2005-10-24 13:12:00 After changing variable DTMFTIMEOUT = 3000 to DTMFTIMEOUT = 1500 into RTP.C all works ok for me, please check it, thanks!! By: Olle Johansson (oej) 2005-10-25 14:55:48 Thanks for the feedback, now let's figure out if that's a proper way to solve this. Anyone that can comment on that? By: Kevin P. Fleming (kpfleming) 2005-10-31 19:15:04.000-0600 The DTMF timeout is now configurable in rtp.conf in CVS HEAD. By: Digium Subversion (svnbot) 2008-01-15 15:53:09.000-0600 Repository: asterisk Revision: 6918 U   trunk/configs/rtp.conf.sample U   trunk/rtp.c ------------------------------------------------------------------------ r6918 | kpfleming | 2008-01-15 15:53:09 -0600 (Tue, 15 Jan 2008) | 2 lines allow DTMF timeout to be configurable (issue ASTERISK-5024) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=6918