[asterisk-commits] r254542 - svn:log

Thu Mar 25 12:13:18 CDT 2010

Author: mmichelson
Revision: 254542
Modified property: svn:log

Modified: svn:log at Thu Mar 25 12:13:18 2010
------------------------------------------------------------------------------

--- svn:log (original)
+++ svn:log Thu Mar 25 12:13:18 2010
@@ -1,56 +1,1 @@
-Recorded merge of revisions 254454 via svnmerge from 
-https://origsvn.digium.com/svn/asterisk/trunk
-
-................
-  r254454 | mmichelson | 2010-03-25 11:04:48 -0500 (Thu, 25 Mar 2010) | 50 lines
-  
-  Recorded merge of revisions 254452 via svnmerge from 
-  https://origsvn.digium.com/svn/asterisk/branches/1.4
-  
-  ........
-    r254452 | mmichelson | 2010-03-25 10:59:56 -0500 (Thu, 25 Mar 2010) | 44 lines
-    
-    Several fixes regarding RFC2833 DTMF detection.
-    
-    Here is a copy and paste of the details from my request on
-    reviewboard that dealt with these changes:
-    
-    Fix 1. The first change in place is to fix Mantis issue 15811, which deals with a situation where Asterisk will incorrectly interpret out of order RFC2833 frames as duplicate DTMF digits. For instance, we would receive a sequence like:
-    
-    seqno 1: DTMF 1
-    seqno 2: DTMF 1
-    seqno 3: DTMF 1
-    seqno 4: DTMF 1
-    seqno 6: DTMF 1 (end)
-    seqno 5: DTMF 1
-    seqno 7: DTMF 1 (end)
-    seqno 8: DTMF 1 (end)
-    
-    Prior to this patch when we received the frame with seqno 5, we would interpret this as a new DTMF 1. With this patch, we will check the seqno of the incoming digit and not process the frame if the seqno is lower than the last recorded seqno. Note that we do not record the seqno of the dropped DTMF frame for future processing. While the above situation is what was designed to be fixed, the patch is written in such a way that the following would also be fixed too:
-    
-    seqno  9: DTMF 1
-    seqno 10: DTMF 1 (end)
-    seqno 11: DTMF 1 (end)
-    seqno 13: DTMF 2
-    seqno 12: DTMF 1 (end)
-    seqno 14: DTMF 2
-    seqno 15: DTMF 2 (end)
-    seqno 16: DTMF 2 (end)
-    seqno 17: DTMF 2 (end)
-    
-    In this second situation, the beginning of the DTMF 2 arrives before the final end frame of the DTMF 1. With the patch, seqno 12 is no processed and thus we properly interpret the DTMF.
-    
-    Fix 2. The second change in place is to fix an issue like the following:
-    
-    seqno 1: DTMF 1
-    seqno 2: DTMF 1
-    seqno 3: DTMF 1 (end) *packet lost*
-    seqno 4: DTMF 1 (end) *packet lost*
-    seqno 5: DTMF 1 (end) *packet lost*
-    seqno 6: DTMF 2
-    
-    When we receive seqno 6, we had code in place that was supposed to properly end the previously unended DTMF 1. The problem was that the code was essentially a no-op. The code would set up an end frame for the DTMF 1 but would immediately overwrite the frame with the begin for DTMF 2. I changed process_dtmf_rfc2833() so that instead of returning a single frame, it is given as an output parameter a list of frames. Each frame that needs to be returned is appended to this list.
-    
-    Fix 3. The final change is a minor one where an AST_CONTROL_SRCCHANGE frame could get lost. If we process a cisco DTMF or an RFC 3389 frame and no frame was returned, then we would return &ast_null_frame. The problem is that earlier in the function, we may have generated an AST_CONTROL_SRCCHANGE frame and put it in the list of frames we wish to return. This frame would be lost in such a case. The patch fixes this problem
-  ........
-................
+Fix potential crashes from trying to reference nonexistent RTP streams.


