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

[Matt Jordan]

> On June 27, 2013, 5:09 p.m., Joshua Colp wrote:
> > /trunk/main/rtp_engine.c, line 1820
> > <https://reviewboard.asterisk.org/r/2603/diff/2/?file=40147#file40147line1820>
> >
> >     I think it would be handy to have #defines for the types, for those reading.

Agreed


- Matt


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


On June 24, 2013, 8:04 p.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> 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.
> 
> 
> 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
> -----
> 
>   /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/20130701/29946518/attachment.htm>