Summary:	ASTERISK-02837: DTMF Stops working in Voicemail
Reporter:	cheiser (cheiser)	Labels:
Date Opened:	2004-11-16 18:32:40.000-0600	Date Closed:	2008-01-15 15:14:15.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) rtp_dtmf_rollover.patch ( 1) rtp.c.patch ( 2) rtp.rollover-revised.patch
Description:	Asterisk uses RTP Sequence numbers to detect new RTP Event Packets.  The problem is this number can rollover during a call and thus asterisk stops recognizing DTMF. ****** ADDITIONAL INFORMATION ****** This was located by using tcpdumps and full debug logs to determine what transpires between the time DTMF is working and when it stops.  The only thing significant is the rollover of RTP Sequence numbers. Attached is a patch to use RTP Timestamps instead.
Comments:	By: cheiser (cheiser) 2004-11-16 18:35:11.000-0600 Note:  I have already signed a disclaimer By: Mark Spencer (markster) 2004-11-16 21:45:05.000-0600 Does not apply to CVS head.  Looks like it might be badly formatted. By: Kevin P. Fleming (kpfleming) 2004-11-17 08:58:49.000-0600 I have uploaded a re-spun version of horshack's patch, it was badly formatted. Compiled and tested here without trouble. By: cheiser (cheiser) 2004-11-17 13:30:58.000-0600 Sorry about the formatting problem.  My bad.  I was trying to get this out from home, etc...  The revised patch looks good.  I have yet to hear reports of dtmf problems so far. By: cheiser (cheiser) 2004-11-17 13:35:50.000-0600 Ok... I no longer like my fix. It appears as though Cisco IP Phones use the same RTP Timestamp on all the packets for a particular dtmf event.  So, detecting rollover needs to be done another way. By: Mark Spencer (markster) 2004-11-17 13:35:53.000-0600 Fixed in CVS By: cheiser (cheiser) 2004-11-17 14:01:22.000-0600 Note that this rtp.rollover-revised.patch works completely differently, and I haven't tested it at all yet. Since some endpoints don't increment the timestamp field at all for their DTMF events, I changed the approach. This patch uses sequence numbers, but if that test fails, we check to see if we're in the middle of a dtmf event OR if the last sequence number was >= 65530 and the new one was <= 6 This should allow the system to handle both a dtmf event that rolls over as well as a dtmf digit that starts after the rollover already happened.  (Since we could have a DTMF event at 62000 and not have another one until it's rolled over and we're at 100). Check it out etc...  I will be applying it and updating my servers this evening. By: cheiser (cheiser) 2004-11-17 14:01:53.000-0600 see last bugnote By: Mark Spencer (markster) 2004-11-17 14:04:37.000-0600 Fixed in CVS By: Russell Bryant (russell) 2004-11-17 23:02:50.000-0600 fixed in 1.0 - will be in 1.0.3 By: Digium Subversion (svnbot) 2008-01-15 15:14:10.000-0600 Repository: asterisk Revision: 4280 U   trunk/rtp.c ------------------------------------------------------------------------ r4280 | markster | 2008-01-15 15:14:10 -0600 (Tue, 15 Jan 2008) | 2 lines Fix rollover with DTMF (bug ASTERISK-2837) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=4280 By: Digium Subversion (svnbot) 2008-01-15 15:14:11.000-0600 Repository: asterisk Revision: 4281 U   trunk/rtp.c ------------------------------------------------------------------------ r4281 | markster | 2008-01-15 15:14:11 -0600 (Tue, 15 Jan 2008) | 2 lines Revised seqno fix (bug ASTERISK-2837) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=4281 By: Digium Subversion (svnbot) 2008-01-15 15:14:15.000-0600 Repository: asterisk Revision: 4286 U   branches/v1-0/rtp.c ------------------------------------------------------------------------ r4286 | russell | 2008-01-15 15:14:15 -0600 (Tue, 15 Jan 2008) | 2 lines detect sequence number rollover (bug ASTERISK-2837) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=4286