[test-results] [Bamboo] Asterisk > Asterisk Unit Tests > #812 has FAILED (4 tests failed, no failures were new). Change made by Matt Jordan.

[Bamboo]

-----------------------------------------------------------------------
Asterisk > Asterisk Unit Tests > #812 failed.
-----------------------------------------------------------------------
This build occurred because it is a dependant of AST-ATRUNKFULLBUILD-840.
2/2 jobs failed, with 4 failing tests, no failures were new.

https://bamboo.asterisk.org/bamboo/browse/AST-ATRUNKUNIT-812/

---------------------
Currently Responsible
---------------------

Corey Farrell (Automatically assigned)
John Bigelow (Automatically assigned)
Richard Mudgett (Automatically assigned)



--------------
Failing Jobs
--------------
  - CentOS 6 32-Bit Unit Testing (Unit Testing): 2 of 457 tests failed.
  - CentOS 6 64-Bit Unit Testing (Unit Testing): 2 of 457 tests failed.



--------------
Code Changes
--------------
Matt Jordan (427771):

>main/rtp_engine: Fix crash when processing more than one RTCP report info block
>
>Asterisk - in res_rtp_asterisk - only understands a single RTCP report info
>block. When the RTCP information was refactored in the RTP Engine to be pushed
>over the Stasis message bus, I put in the hooks into the engine to handle
>multiple RTCP report info blocks, in the hope that a future RTP implementation
>would be able to provide that data. Unfortunately, res_rtp_asterisk has a
>tendency to "lie":
>(1) It will send RTCP reports with a reception_report_count greater than 1
>    (which is pulled directly from the RTCP packet itself, so that part is
>    correct)
>(2) It will only provide a single report block
>
>When the rtp_engine goes to convert this to a JSON blob, hilarity ensues as it
>looks for a report block that doesn't exist.
>
>This patch updates the rtp_engine to be a bit more skeptical about what it is
>presented with. While this could also be fixed in res_rtp_asterisk, this patch
>prefers to fix it in the engine for two reasons:
>(1) The engine is designed to work with multiple RTP implementation, and hence
>    having it be more robust is a good thing (tm)
>(2) res_rtp_asterisk's handling of RTCP information is "fun". It should report
>    the correct reception_report_count; ideally it should also be giving us all
>    of the blocks - but it is *definitely* not designed to do that. Going down
>    that road is a non-trivial effort.
>
>Review: https://reviewboard.asterisk.org/r/4158/
>
>ASTERISK-24489 #close
>Reported by: Gregory Malsack
>Tested by: Gregory Malsack
>
>ASTERISK-24498 #close
>Reported by: Beppo Mazzucato
>Tested by: Beppo Maazucato
>........
>
>Merged revisions 427762 from http://svn.asterisk.org/svn/asterisk/branches/12
>........
>
>Merged revisions 427763 from http://svn.asterisk.org/svn/asterisk/branches/13
>



--------------
Tests
--------------
Existing Test Failures (4)
   - AsteriskUnitTests: /res/parking/dynamic parking variables
   - AsteriskUnitTests: /channels/features/test features channel dtmf
   - AsteriskUnitTests: /res/parking/dynamic parking variables
   - AsteriskUnitTests: /channels/features/test features channel dtmf

--
This message is automatically generated by Atlassian Bamboo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/test-results/attachments/20141113/4ac1db00/attachment-0001.html>