[asterisk-dev] [Code Review] 2582: Reimplement bridging and DTMF features related channel variables in the bridging core.

[jrose]

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

Ship it!


Only thing I spotted was a minor documentation issue.


/trunk/main/bridging.c
<https://reviewboard.asterisk.org/r/2582/#comment17205>

    > Is guaranteed to be large enough.
    
    While this is true for the one time this function is called, the lingo seems to imply that the function itself handles this when it is instead a requirement of the function that this be the case. Perhaps this should instead say something like:
    
    "Must be large enough to contain the comma separated list of all bridged peers."


- jrose


On May 31, 2013, 5:09 p.m., rmudgett wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2582/
> -----------------------------------------------------------
> 
> (Updated May 31, 2013, 5:09 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-21555
>     https://issues.asterisk.org/jira/browse/ASTERISK-21555
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> * The channel variable ATTENDED_TRANSFER_COMPLETE_SOUND is no longer channel driver specific.  If the channel variable is set on the transferrer channel, the sound will be played to the target of an attended transfer.
> 
> * The channel variable BRIDGEPEER becomes a comma separated list of peers in a multi-party bridge.  The BRIDGEPEER value can have a maximum of 10 peers listed.  Any more peers in the bridge will not be included in the list.  BRIDGEPEER is not valid in holding bridges like parking since those channels do not talk to each other even though they are in a bridge.
> 
> * The channel variable BRIDGEPVTCALLID is only valid for two party bridges and will contain a value if the BRIDGEPEER's channel driver supports it.
> 
> * The channel variable DYNAMIC_PEERNAME is redundant with BRIDGEPEER and is removed.  The more useful DYNAMIC_WHO_ACTIVATED gives the channel name that activated the dynamic feature.
> 
> * The channel variables DYNAMIC_FEATURENAME and DYNAMIC_WHO_ACTIVATED are set only on the channel executing the dynamic feature.  Executing a dynamic feature on the bridge peer in a multi-party bridge will execute it on all peers of the activating channel.
> 
> * Removed no longer needed builtin_blindtransfer() and dependent functions.
> 
> 
> Diffs
> -----
> 
>   /trunk/CHANGES 390311 
>   /trunk/UPGRADE.txt 390311 
>   /trunk/bridges/bridge_builtin_features.c 390311 
>   /trunk/configs/chan_dahdi.conf.sample 390311 
>   /trunk/configs/iax.conf.sample 390311 
>   /trunk/configs/sip.conf.sample 390311 
>   /trunk/configs/skinny.conf.sample 390311 
>   /trunk/include/asterisk/bridging.h 390311 
>   /trunk/include/asterisk/bridging_features.h 390311 
>   /trunk/main/bridging.c 390311 
>   /trunk/main/features.c 390311 
> 
> Diff: https://reviewboard.asterisk.org/r/2582/diff/
> 
> 
> Testing
> -------
> 
> * Performed DTMF and external attended transfers with the ATTENDED_TRANSFER_COMPLETE_SOUND channel variable on the transferrer channel.  The sound is heard by the transfer target party.
> 
> * Created two-party and multi-party bridges.  The BRIDGEPEER value updates as bridge parties are added and removed.  Tested the maximum limit of peers in the list and got the expected number of peers in the list even though there were more peers.
> 
> * Tested BRIDGEPVTCALLID.  It only shows up on two party bridges when the peer channel driver supports it.
> 
> * Tested DYNAMIC_FEATURES to verify that the DYNAMIC_FEATURENAME and DYNAMIC_WHO_ACTIVATED are set on the executing channel.
> 
> 
> Thanks,
> 
> rmudgett
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130603/72202a44/attachment.htm>