[asterisk-bugs] [Asterisk 0017571]: [patch] [regression] RFC 2833 frame out of order detection does not properly handle numeric overflow

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17571 
====================================================================== 
Reported By:                mdeneen
Assigned To:                mmichelson
====================================================================== 
Project:                    Asterisk
Issue ID:                   17571
Category:                   Core/RTP
Reproducibility:            sometimes
Severity:                   block
Priority:                   normal
Status:                     ready for review
Target Version:             1.4.34
Asterisk Version:           1.6.2.9 
JIRA:                       SWP-1807 
Regression:                 Yes 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-06-30 10:24 CDT
Last Modified:              2010-07-06 09:29 CDT
====================================================================== 
Summary:                    [patch] [regression] RFC 2833 frame out of order
detection does not properly handle numeric overflow
Description: 
SVN revision r254482 added code to detect out of sequence RTP frames, and
to discard them.  However, at least with my ITSP, the RTP sequence is a 16
bit unsigned number.  It is possible to get into a situation where the
check fails because the RTP sequence number rolls back around to 0 as the
DTMF frame comes in.

In this situation, the last sequence number (rtp->lastevent) is not
updated and further DTMF frames are ignored.

For example, rtp->lastevent might be 65535.  The RTP sequence can never be
greater than this, so no further DTMF will be processed.

Instead of doing:

if (rtp->lastevent > seqno) {
    return;
}
Perhaps it should not fall into the "out of order" branch if the
difference between the last sequence and the current sequence is greater
than a chosen reasonable number.

======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0015811 [patch] dtmf creating double digits if ...
has duplicate       0017545 [regression] DTMF transfers stop workin...
====================================================================== 

---------------------------------------------------------------------- 
 (0124247) svnbot (reporter) - 2010-07-06 09:29
 https://issues.asterisk.org/view.php?id=17571#c124247 
---------------------------------------------------------------------- 
Repository: asterisk
Revision: 274157

U   branches/1.4/main/rtp.c

------------------------------------------------------------------------
r274157 | mmichelson | 2010-07-06 09:29:22 -0500 (Tue, 06 Jul 2010) | 16
lines

Fix problem with RFC 2833 DTMF not being accepted.

A recent check was added to ensure that we did not erroneously
detect duplicate DTMF when we received packets out of order.
The problem was that the check did not account for the fact that
the seqno of an RTP stream will roll over back to 0 after hitting
65535. Now, we have a secondary check that will ensure that the
seqno rolling over will not cause us to stop accepting DTMF.

(closes issue https://issues.asterisk.org/view.php?id=17571)
Reported by: mdeneen
Patches: 
      rtp_seqno_rollover.patch uploaded by mmichelson (license 60)
Tested by: richardf, maxochoa, JJCinAZ


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=274157 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-07-06 09:29 svnbot         Checkin                                      
2010-07-06 09:29 svnbot         Note Added: 0124247                          
======================================================================