Summary:	ASTERISK-01028: [PATCH] fix multiple detection of rtp dtmf events with eg cisco phones
Reporter:	cloos (cloos)	Labels:
Date Opened:	2004-02-12 01:15:40.000-0600	Date Closed:	2011-06-07 14:05:19
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) final-dup-fix.diff
Description:	(Some?) cisco phones interleave voice packets with the rfc2833 packets; this causes eg waitfordigit() to see an extra digit every time a voice packet shows up before the current event's end packets.  This is in part because all of the packets in a dtmf event have the same timestamp, but the voice packets each have an unique timestamp. Increasing dtmftimeout from 300 to 3000 solves this for keypresses less than 3000/8000 seconds long. Also, if the rtp packets are re-ordered along the way to the  * box more multiple detections occur every time the duration in a rfc2833 packet is less than the last packet of that event that was seen. The patch increases dtmftimeout to 3000 and drops rfc2833 and cisco dtmf packets that have a sequence number less than the last such packet that was processed. (It is important not to drop packets with the same sequence number as the last one processed, since cisco phones -- but not their atas -- use the same sequence number for all three end packets.)
Comments:	By: flavour (flavour) 2004-02-18 05:26:28.000-0600 This patch fixed the same problem on a Grandstream Budgetone 101 By: Olle Johansson (oej) 2004-03-21 11:30:13.000-0600 Someone else that tried this patch? Is it working? By: twisted (twisted) 2004-04-17 19:50:46 Any more updates on this? By: Brian West (bkw918) 2004-04-17 23:06:16 This has been fixed I think because I don't have the problem with my 7960. bkw By: cloos (cloos) 2004-04-18 06:24:17 I will have my client give head a test and compare that with head plus this patch.   You need to have alink that re-orders packets to see part of the bug; if your packets from the cisco to * stay in order you cannot really test this.... I think the dtmftimeout change should go in in any case. W/o this patch dtmf was useless across his link. By: twisted (twisted) 2004-04-28 18:54:42 cloos: any update?  Anyone have any update on this? By: Brian West (bkw918) 2004-04-30 00:22:09 Let us know if the latest "relaxdtmf option" in sip might fix this. By: kapela (kapela) 2004-05-03 13:41:55 Reminder sent to bkw918 Bkw; I've cvs'd this weekend and tested CVS-HEAD with several 7960 and 7940 sets. It seems that the 'new' option (apprently for use in the [general] section of sip.conf) doesn't solve the problems I had with dtmf. However, applying the diff to rtp.c & recompiling does fix the problem. Just a heads up, see you on #asterisk.. -Tk By: kapela (kapela) 2004-05-03 14:04:34 Reminder sent to bkw918 scratch that - in the diff for rtp.c, I find I need to change the constant to: static int dtmftimeout = 8000; ..for a user to have a 'normal' experience using the cisco phones. Without this value cranked, (allowing 1-second long button presses before duplicate numbers are sensed) users mentioned to me they had to 'press digits unhumanly fast' lest they'd get duplicates. I'd suggest that the diff & a higher value for the digit timeout be considered necessary for correct handling of  these strange RTP and DTMF situations. By: Digium Subversion (svnbot) 2008-01-15 14:53:44.000-0600 Repository: asterisk Revision: 2895 U   trunk/rtp.c ------------------------------------------------------------------------ r2895 | markster | 2008-01-15 14:53:43 -0600 (Tue, 15 Jan 2008) | 2 lines Ignore dupe packets for RFC2833 (bug ASTERISK-1028) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=2895