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

[Matt Jordan]

> On June 20, 2013, 6:45 p.m., opticron wrote:
> > /trunk/main/rtp_engine.c, lines 1844-1846
> > <https://reviewboard.asterisk.org/r/2603/diff/1/?file=39555#file39555line1844>
> >
> >     This is unnecessary since ast_json_array_append is NULL-safe.
> 
> Matt Jordan wrote:
>     Yes, but I don't want to publish half a message. If you get a memory allocation error, publishing half a message means everyone who extracts the message will have to expect that the data may be missing.
>     
>     If you can't build a message, you need to bail.
> 
> opticron wrote:
>     Actually, the append will fail gracefully with -1 if provided a NULL value to append.

Until someone - for some reason I can't fathom - inserts code between the pack and the append call that just happens to use the json_report_block value.

Explicitly checking success/failure as soon as you know something can fail tells everyone who looks at the code that "I thought this could fail and this is what I wanted to have happen". Removing checks and relying on another call in the future to handle it for you adds no value, makes the code harder to maintain, and introduces places where bugs can creep in.


- Matt


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


On June 12, 2013, 2:57 a.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2603/
> -----------------------------------------------------------
> 
> (Updated June 12, 2013, 2:57 a.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_sip.c 391524 
>   /trunk/channels/chan_skinny.c 391524 
>   /trunk/channels/chan_unistim.c 391524 
>   /trunk/include/asterisk/cdr.h 391524 
>   /trunk/include/asterisk/channel.h 391524 
>   /trunk/include/asterisk/json.h 391524 
>   /trunk/include/asterisk/rtp_engine.h 391524 
>   /trunk/main/asterisk.c 391524 
>   /trunk/main/json.c 391524 
>   /trunk/main/manager.c 391524 
>   /trunk/main/rtp_engine.c 391524 
>   /trunk/res/res_rtp_asterisk.c 391524 
>   /trunk/channels/chan_multicast_rtp.c 391524 
>   /trunk/channels/chan_motif.c 391524 
>   /trunk/channels/chan_mgcp.c 391524 
>   /trunk/channels/chan_jingle.c 391524 
>   /trunk/channels/chan_h323.c 391524 
>   /trunk/channels/chan_gulp.c 391524 
>   /trunk/channels/chan_gtalk.c 391524 
> 
> 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/b9dc0815/attachment.htm>