-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4158/
-----------------------------------------------------------
(Updated Nov. 12, 2014, 5:59 p.m.)
Status
------
This change has been marked as submitted.
Review request for Asterisk Developers.
Changes
-------
Committed in revision 427762
Bugs: ASTERISK-24489 and ASTERISK-24498
https://issues.asterisk.org/jira/browse/ASTERISK-24489
https://issues.asterisk.org/jira/browse/ASTERISK-24498
Repository: Asterisk
Description
-------
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, I prefer 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.
Diffs
-----
/branches/12/main/rtp_engine.c 427539
Diff: https://reviewboard.asterisk.org/r/4158/diff/
Testing
-------
Issue reporter tested and verified that they no longer crash.
Thanks,
Matt Jordan
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
