[asterisk-dev] [Code Review] 2465: Bridging Native RTP Support
rmudgett
reviewboard at asterisk.org
Wed May 8 13:09:13 CDT 2013
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2465/#review8503
-----------------------------------------------------------
/team/group/bridge_construction/apps/app_chanspy.c
<https://reviewboard.asterisk.org/r/2465/#comment16425>
Change to:
ast_channel_lock(chan);
if (ast_channel_is_bridged(chan)) {
ast_softhangup_nolock(chan, AST_SOFTHANGUP_UNBRIDGE);
}
ast_channel_unlock(chan);
/team/group/bridge_construction/apps/app_mixmonitor.c
<https://reviewboard.asterisk.org/r/2465/#comment16427>
Change to:
ast_channel_lock(chan);
if (ast_channel_is_bridged(chan)) {
ast_softhangup_nolock(chan, AST_SOFTHANGUP_UNBRIDGE);
}
ast_channel_unlock(chan);
/team/group/bridge_construction/bridges/bridge_native_rtp.c
<https://reviewboard.asterisk.org/r/2465/#comment16438>
Change the test to:
if (bridge->num_channels != 2)
The c0 == c1 test will pass if there are 3 or more channels in the bridge.
/team/group/bridge_construction/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/2465/#comment16428>
Use the new ast_channel_is_bridged() function instead of the internal function.
/team/group/bridge_construction/main/bridging.c
<https://reviewboard.asterisk.org/r/2465/#comment16437>
This can be removed when the AST_SOFTHANGUP_UNBRIDGE check is moved to the correct location.
/team/group/bridge_construction/main/bridging.c
<https://reviewboard.asterisk.org/r/2465/#comment16435>
This check needs to be done in bridge_channel_wait() right after ast_waitfor_nandfds(). Otherwise you risk having the AST_SOFTHANGUP_UNBRIDGE flag escape the bridging system and really hanging up the call.
/team/group/bridge_construction/main/bridging.c
<https://reviewboard.asterisk.org/r/2465/#comment16441>
If the current technology has (AST_BRIDGE_CAPABILITY_1TO1MIX | AST_BRIDGE_CAPABILITY_NATIVE) set
This test will pass only if capabilities has neither bit set.
/team/group/bridge_construction/main/bridging.c
<https://reviewboard.asterisk.org/r/2465/#comment16442>
The smart bridge technology evaluation code must be rethought. This code will not work as expected.
- rmudgett
On May 8, 2013, 2:42 p.m., Joshua Colp wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2465/
> -----------------------------------------------------------
>
> (Updated May 8, 2013, 2:42 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/apps/app_chanspy.c 386842
> /team/group/bridge_construction/apps/app_mixmonitor.c 386842
> /team/group/bridge_construction/bridges/bridge_native_rtp.c PRE-CREATION
> /team/group/bridge_construction/channels/chan_gulp.c 386842
> /team/group/bridge_construction/channels/chan_h323.c 386842
> /team/group/bridge_construction/channels/chan_jingle.c 386842
> /team/group/bridge_construction/channels/chan_mgcp.c 386842
> /team/group/bridge_construction/channels/chan_motif.c 386842
> /team/group/bridge_construction/channels/chan_sip.c 386842
> /team/group/bridge_construction/channels/chan_skinny.c 386842
> /team/group/bridge_construction/channels/chan_unistim.c 386842
> /team/group/bridge_construction/include/asterisk/rtp_engine.h 386842
> /team/group/bridge_construction/main/bridging.c 386842
> /team/group/bridge_construction/main/rtp_engine.c 386842
>
> 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/20130508/72a50c4e/attachment-0001.htm>
More information about the asterisk-dev
mailing list