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

[Joshua Colp]

> On May 9, 2013, 3:36 p.m., rmudgett wrote:
> > /team/group/bridge_construction/bridges/bridge_native_rtp.c, lines 70-72
> > <https://reviewboard.asterisk.org/r/2465/diff/4/?file=37520#file37520line70>
> >
> >     Use ast_channel_get_bridge() to determine if the channel is in a bridge and to safely get a bridge pointer reference.  You MUST have the channel locked to call the function.  Also it seems dangerous to have a frame hook call the bridge technology join/leave calls since the bridge is controlling when channels enter/leave the bridge technology.

Well, it's an implementation detail that it has to be done. We either expose this detail to the bridging core, which is ungood, or we have to build a mechanism within the core to allow technologies to intercept this sorta stuff (we'll probably have to do this anyway, at which point moving this over to it would be kosher).


- Joshua


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


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