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

[rmudgett]

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


You need to start breaking long lines at 90 columns. :)


/team/group/bridge_construction/apps/app_chanspy.c
<https://reviewboard.asterisk.org/r/2465/#comment16123>

    All calls to ast_bridge_channel() will by necessity have to be changed.  That function is going away.  It currently only returns NULL.



/team/group/bridge_construction/apps/app_mixmonitor.c
<https://reviewboard.asterisk.org/r/2465/#comment16124>

    Same



/team/group/bridge_construction/bridges/bridge_native_rtp.c
<https://reviewboard.asterisk.org/r/2465/#comment16125>

    You can now do this and if there happens to be only one channel in the bridge you won't crash:
    	struct ast_bridge_channel *other;
    
    	/* Find the channel we actually want to write to */
    	other = ast_bridge_channel_peer(bridge_channel);
    	if (!other) {
    		return -1;
    	}
    
    	/* The bridging core takes care of freeing the passed in frame. */
    	ast_bridge_channel_queue_frame(other, frame);
    
    	return 0;
    



/team/group/bridge_construction/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/2465/#comment16126>

    Remove the call to ast_bridge_channel()



/team/group/bridge_construction/main/bridging.c
<https://reviewboard.asterisk.org/r/2465/#comment16127>

    You must lock the bridge for these two lines to meet preconditions:
    ast_bridge_channel_lock_bridge(bridge_channel);
    ...
    ast_bridge_unlock(bridge_channel->bridge);


- rmudgett


On April 23, 2013, 4:06 p.m., Joshua Colp wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2465/
> -----------------------------------------------------------
> 
> (Updated April 23, 2013, 4:06 p.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/main/rtp_engine.c 386345 
>   /team/group/bridge_construction/main/bridging.c 386345 
>   /team/group/bridge_construction/channels/chan_sip.c 386345 
>   /team/group/bridge_construction/include/asterisk/rtp_engine.h 386345 
>   /team/group/bridge_construction/bridges/bridge_native_rtp.c PRE-CREATION 
>   /team/group/bridge_construction/apps/app_chanspy.c 386345 
>   /team/group/bridge_construction/apps/app_mixmonitor.c 386345 
> 
> 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/20130426/bcd6cda6/attachment-0001.htm>