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

Asterisk Bug Tracker noreply at bugs.digium.com
Fri Jul 2 10:43:12 CDT 2010


A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17571 
====================================================================== 
Reported By:                mdeneen
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17571
Category:                   Core/RTP
Reproducibility:            sometimes
Severity:                   minor
Priority:                   normal
Status:                     new
Asterisk Version:           1.6.2.9 
JIRA:                        
Regression:                 No 
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-02 10:43 CDT
====================================================================== 
Summary:                    [patch] 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...
====================================================================== 

---------------------------------------------------------------------- 
 (0124188) mmichelson (administrator) - 2010-07-02 10:43
 https://issues.asterisk.org/view.php?id=17571#c124188 
---------------------------------------------------------------------- 
I've uploaded a simple patch which implements the idea of using a windowed
approach to determine if the seqno has rolled over.

richardf and I discussed on IRC a more deterministic method of doing so
using the timestamps from the RTP events instead of the seqno. However,
this is prone to error due to SSRC changes plus the fact the timestamp
itself can roll over (though admittedly much much much less frequently).
Thus I have chosen to go with the easier, less error-prone method that will
likely work 99.99999% of the time :) 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-07-02 10:43 mmichelson     Note Added: 0124188                          
======================================================================




More information about the asterisk-bugs mailing list