[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.

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.


> On June 20, 2013, 6:45 p.m., opticron wrote:
> > /trunk/main/rtp_engine.c, lines 1825-1827
> > <https://reviewboard.asterisk.org/r/2603/diff/1/?file=39555#file39555line1825>
> >
> >     This should probably check that snapshot is non-NULL if retreived.

It already does on line 1868. The extraction method also expects that the snapshot may be NULL.

It is technically valid (although not currently possible) to have RTCP information without a channel, and given that different threads may be involved, I wouldn't want to blow away a message because we got out of order with the Stasis cache.


> On June 20, 2013, 6:45 p.m., opticron wrote:
> > /trunk/main/rtp_engine.c, lines 1793-1803
> > <https://reviewboard.asterisk.org/r/2603/diff/1/?file=39555#file39555line1793>
> >
> >     The vast majority of the ast_rtp_rtcp_report to JSON conversion seems to occur outside the JSON conversion function.

Yeah, I don't really like that either.

I think I'll change this to just push the ast_rtp_rtcp_report struct, and have the AMI message build it from that.


- 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/20130622/f9a954bb/attachment.htm>