[test-results] [Bamboo] Asterisk Testing > Asterisk Trunk > #495 has FAILED (2 tests failed, 1 failures were new). Change made by Matthew Jordan.

[Bamboo]

-----------------------------------------------------------------------
Asterisk Testing > Asterisk Trunk > #495 failed.
-----------------------------------------------------------------------
Code has been updated by Matthew Jordan.
2/270 tests failed, 1 failure was new.

http://bamboo.asterisk.org/browse/TESTING-ASTERISKTRUNK-495/


--------------
Failing Jobs
--------------
  - Asterisk CentOS 6 64-Bit (CentOS 6): 2 of 270 tests failed.



--------------
Code Changes
--------------
Matthew Jordan (370272):

>Handle extremely out of order RFC 2833 DTMF
>
>The current implementation of RFC 2833 DTMF handling in res_rtp_asterisk will,
>if a packet arrives out of order, drop the packet.  This is to prevent
>duplicate ton generation in the Asterisk core.  Since the RTP layer does not
>buffer data itself, this is the only option the RTP layer currently has for
>handling packets that arrive out of order.
>
>For the most part, this doesn't matter.  For a particular digit, so long as a
>BEGIN packet arrives before the first END packet, the digit will be produced.
>If subsequent BEGIN packets arrive interleaved with the ENDs, they will be
>dropped; likewise, if the BEGIN or END packets themselves are out of order,
>those packets are dropped but sufficient information is conveyed to the
>Asterisk core to produce the appropriate digit.
>
>For certain sequences of DTMF packets - most notably when, for a particular
>digit, an END packet arrives before any BEGIN packet for that digit - this
>is a real problem.  When an END arrives before any BEGINs, the END packet is
>dropped - but at the same time, it causes subsequent BEGIN packets for that
>digit to be ignored.  When the next in order END packet arrives, it too is
>dropped - Asterisk believes that there was no initial BEGIN.
>
>The solution this patch provides is to trust the END packet to convey the
>information needed for the Asterisk core to produce the DTMF digit.  If we
>receive an END packet, and it:
>  * Has a timestamp greater then the last timestamp received from an END
>    packet
>  * Does not have the same sequence number as the last received sequence
>    number (and is thus not an END packet retransmission)
>Then we send the END frame up to the Asterisk core.  It contains enough
>DTMF information for Asterisk to produce the digit.
>
>On the other hand, if we receive a BEGIN or continuation packet that occurs
>with a timestamp equal to or less then the last END timestamp, then we've
>received something out of order - but we already have received enough
>information to produce the digit.  These packets are dropped.
>
>Much thanks goes to Olle Johansson (oej) for providing the idea for this
>solution.
>
>Review: https://reviewboard.asterisk.org/r/2033/
>
>(issue ASTERISK-18404)
>Reporter: Stephane Chazelas
>Tested by: Matt Jordan
>........
>
>Merged revisions 370252 from http://svn.asterisk.org/svn/asterisk/branches/1.8
>........
>
>Merged revisions 370271 from http://svn.asterisk.org/svn/asterisk/branches/10
>



--------------
Tests
--------------
New Test Failures (1)
   - AsteriskTestSuite: S/one-step-parking
Existing Test Failures (1)
   - AsteriskTestSuite: S/channels/ s i p/generic ccss

--
This message is automatically generated by Atlassian Bamboo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/test-results/attachments/20120719/96c5919e/attachment-0001.htm>