[asterisk-dev] [Code Review] 2465: Bridging Native RTP Support

[Mark Michelson]

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


I can't find any further faults in the logic here.

I see a trend, though, that worries me. There are several places where channel properties are set without first locking the channel. The most troublesome of these are the attachment and detachment of the native RTP framehook and the setting of ast_channel_internal_bridge(). These are operations that really should have the channel locked while performing them.

- Mark Michelson


On May 9, 2013, 11:06 a.m., Joshua Colp wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2465/
> -----------------------------------------------------------
> 
> (Updated May 9, 2013, 11:06 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> This change implements the following:
> 
> 1. Adds a native RTP bridge technology which does local or remote bridging depending on conditions
> 2. Makes the bridging core aware of native bridges
> 3. Calls into the compatible callback of bridging technologies when present to check compatibility
> 4. Tweaks some logic to cause the bridge to reconfigure when external conditions influence it
> 
> 
> Diffs
> -----
> 
>   /team/group/bridge_construction/apps/app_chanspy.c 388160 
>   /team/group/bridge_construction/apps/app_mixmonitor.c 388160 
>   /team/group/bridge_construction/bridges/bridge_native_rtp.c PRE-CREATION 
>   /team/group/bridge_construction/channels/chan_gulp.c 388160 
>   /team/group/bridge_construction/channels/chan_h323.c 388160 
>   /team/group/bridge_construction/channels/chan_jingle.c 388160 
>   /team/group/bridge_construction/channels/chan_mgcp.c 388160 
>   /team/group/bridge_construction/channels/chan_motif.c 388160 
>   /team/group/bridge_construction/channels/chan_sip.c 388160 
>   /team/group/bridge_construction/channels/chan_skinny.c 388160 
>   /team/group/bridge_construction/channels/chan_unistim.c 388160 
>   /team/group/bridge_construction/include/asterisk/rtp_engine.h 388160 
>   /team/group/bridge_construction/main/bridging.c 388160 
>   /team/group/bridge_construction/main/rtp_engine.c 388160 
> 
> Diff: https://reviewboard.asterisk.org/r/2465/diff/
> 
> 
> Testing
> -------
> 
> 1. Tested that non-RTP channels do not cause the native RTP bridge to be used
> 2. Tested that if conditions allow it that remote bridging (ala reinvite) occurs
> 3. Tested that if remote bridging is not possible that local bridging occurs
> 4. Tested that if conditions are not correct none of the above happens
> 5. Tested that external applications cause the bridge to be reconfigured, and alternate technology used if needed
> 
> 
> Thanks,
> 
> Joshua Colp
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130509/c752f4aa/attachment-0001.htm>