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

[opticron]

> On June 20, 2013, 1: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.

Actually, the append will fail gracefully with -1 if provided a NULL value to append.


- opticron


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


On June 11, 2013, 9:57 p.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2603/
> -----------------------------------------------------------
> 
> (Updated June 11, 2013, 9:57 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_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/20130622/a839c2f6/attachment-0001.htm>