[asterisk-dev] [Code Review] 2603: Refactor RTCP events over to Stasis (with a bit of cleanup)

[Matt Jordan]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2603/
-----------------------------------------------------------

(Updated June 24, 2013, 8:04 p.m.)


Review request for Asterisk Developers.


Changes
-------

Addressed Kinsey's findings.

The big change here is to use an ao2 object to pass the RTCP information around on Stasis, and push the JSON to where it belongs - in to_json.


Bugs: ASTERISK-20754 and ASTERISK-21471
    https://issues.asterisk.org/jira/browse/ASTERISK-20754
    https://issues.asterisk.org/jira/browse/ASTERISK-21471


Repository: Asterisk


Description
-------

This patch does the following:

* It merges Jaco Kroon's patch from ASTERISK-20754, which provides channel information in the RTCP events. Because Stasis provides a cache, Jaco's patch was modified to pass the channel uniqueid to the RTP layer as opposed to a pointer to the channel. This has the following benefits:
  (1) It keeps the RTP engine 'clean' of references back to channels
  (2) It prevents circular dependencies and other potential ref counting issues
* The RTP engine now allows any RTP implementation to raise RTCP messages. Potentially, other implementations (such as res_rtp_multicast) could also raise RTCP information. The engine provides structs to represent RTCP headers and RTCP SR/RR reports.
* Some general refactoring in res_rtp_asterisk to done to try and tame the RTCP code. It isn't perfect - that's *way* beyond the scope of this work - but it does feel marginally better.
* A few random bugs were fixed in the RTCP statistics. (Example: performing an assignment of a = a is probably not correct)
* We now raise RTCP events for each SR/RR sent/received. Previously we wouldn't raise an event when we sent a RR report.

Note that this work will be of use to others who want to monitor call quality or build modules that report call quality statistics. Since the events are now moving across the Stasis message bus, this is far easier to accomplish. It is also a first step (though by no means the last step) towards getting Olle's pinefrog work incorporated.


Diffs (updated)
-----

  /trunk/channels/chan_gtalk.c 392115 
  /trunk/channels/chan_gulp.c 392115 
  /trunk/channels/chan_h323.c 392115 
  /trunk/channels/chan_jingle.c 392115 
  /trunk/channels/chan_mgcp.c 392115 
  /trunk/channels/chan_motif.c 392115 
  /trunk/channels/chan_multicast_rtp.c 392115 
  /trunk/channels/chan_sip.c 392115 
  /trunk/channels/chan_skinny.c 392115 
  /trunk/channels/chan_unistim.c 392436 
  /trunk/include/asterisk/cdr.h 392115 
  /trunk/include/asterisk/channel.h 392115 
  /trunk/include/asterisk/json.h 392115 
  /trunk/include/asterisk/rtp_engine.h 392115 
  /trunk/main/asterisk.c 392115 
  /trunk/main/json.c 392115 
  /trunk/main/manager.c 392115 
  /trunk/main/rtp_engine.c 392115 
  /trunk/res/res_rtp_asterisk.c 392115 

Diff: https://reviewboard.asterisk.org/r/2603/diff/


Testing
-------

Lots. A lot of wiresharking.

Additionally, testing was done to ensure that the AMI event payloads matched the RTCP packets sent between instances of Asterisk.


Thanks,

Matt Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130624/4337e887/attachment.htm>