Summary:ASTERISK-02837: DTMF Stops working in Voicemail
Reporter:cheiser (cheiser)Labels:
Date Opened:2004-11-16 18:32:40.000-0600Date Closed:2008-01-15 15:14:15.000-0600
Versions:Frequency of
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.


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)



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)



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)