[asterisk-dev] [Code Review] 2558: Eliminate most calls to ast_channel_internal_bridged_channel().

Matt Jordan reviewboard at asterisk.org
Mon May 20 19:41:14 CDT 2013


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



/team/group/bridge_construction/channels/chan_unistim.c
<https://reviewboard.asterisk.org/r/2558/#comment17018>

    The -42 is weird.



/team/group/bridge_construction/channels/chan_vpb.cc
<https://reviewboard.asterisk.org/r/2558/#comment17019>

    I think there should still be an ast_verb here indicating whether or not it got an Asterisk bridge.
    
    The verbose message just prior to this informs the user that we're checking for bridges, and that there wasn't a native bridge. If we find a bridge, we should tell them.



/team/group/bridge_construction/main/channel.c
<https://reviewboard.asterisk.org/r/2558/#comment17020>

    We may be better off making this a function of the bridging framework.
    
    Essentially, as each channel joins a bridge, the oldest linkedid should be propagated between all pairs of channels.
    
    This is currently called in two places:
    (1) In channel masquerade. To some extent this shouldn't really be done any longer - we don't really want a channel to have its linkedid change, even if it replaces a channel that had an older linkedid. The two channels aren't really 'related', they're simply swapping with each other.
    (2) In features.c as two channels are bridged.
    
    We don't have to do this now, but you may want to update the BUGBUG to reflect that this should be handled by bridging (unless you're in an infinite wait bridge...)


- Matt Jordan


On May 20, 2013, 11:03 p.m., rmudgett wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2558/
> -----------------------------------------------------------
> 
> (Updated May 20, 2013, 11:03 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> The new bridging API will never set the ast_channel_internal_bridged_channel().  This patch removes most calls to ast_channel_internal_bridged_channel().
> 
> 
> Diffs
> -----
> 
>   /team/group/bridge_construction/main/channel.c 389333 
>   /team/group/bridge_construction/include/asterisk/channel.h 389333 
>   /team/group/bridge_construction/channels/chan_vpb.cc 389333 
>   /team/group/bridge_construction/channels/chan_unistim.c 389333 
>   /team/group/bridge_construction/apps/app_dumpchan.c 389333 
>   /team/group/bridge_construction/CHANGES 389333 
>   /team/group/bridge_construction/main/cli.c 389333 
>   /team/group/bridge_construction/main/features.c 389333 
>   /team/group/bridge_construction/main/manager.c 389333 
> 
> Diff: https://reviewboard.asterisk.org/r/2558/diff/
> 
> 
> Testing
> -------
> 
> Checked output of DumpChan() output.
> Checked output of AMI Status action.
> Checked CLI "core show channels verbose" and "core show channel x".
> 
> 
> Thanks,
> 
> rmudgett
> 
>

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


More information about the asterisk-dev mailing list