[asterisk-dev] [Code Review] 2470: Add API call to perform externally-intiated blind transfers on a bridge

[jrose]

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



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

    They don't look pulled from thin air.



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

    No, this is never going to happen. The only reason we are even interested in the whole extension is so that we can originate a local channel to it if the bridge is a multiparty bridge. Aside from that, all we get out of this is the argument string on the extension and use it for bridge_move. I don't believe autoservice is ever going to be a factor in any of this.



/team/group/bridge_construction/main/manager.c
<https://reviewboard.asterisk.org/r/2470/#comment16115>

    white space


- jrose


On April 24, 2013, 10:25 p.m., Mark Michelson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2470/
> -----------------------------------------------------------
> 
> (Updated April 24, 2013, 10:25 p.m.)
> 
> 
> Review request for Asterisk Developers, jrose and rmudgett.
> 
> 
> Bugs: ASTERISK-21335
>     https://issues.asterisk.org/jira/browse/ASTERISK-21335
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> This adds a new API call to bridging.h called ast_bridge_blind_transfer(). It is intended to be used by channel drivers and other entities that receive external notifications to perform a blind transfer.
> 
> The idea here is to provide the transferer channel, and the target extension and context. Given this information, all parties bridged to the transferer will be transferred to the given location. In the case where the transferer is bridged to multiple peers, the entire bridge is transferred by starting a local channel and swapping the transferer and local channel. In the case where the transferer is bridged to a single party, then that one party is redirected to the given destination.
> 
> Another parameter that the blind transfer code can be given is a framehook. This is useful for cases where the caller of ast_bridge_blind_transfer() wishes to be able to monitor the progress of the new outbound call. The framehook is attached either to the newly-created local channel (in the case of transferring multiple bridged peers) or to the existing transferee channel (in the case of transferring a single channel).
> 
> During implementation discussions, it was noticed that there were some special flags needed for bridges. One such flag always prohibits transfers from occurring on a bridge. This is useful for holding bridges, parking bridges, and other bridges where the participant is not necessarily aware that he is in a bridge. Another flag states that no matter the number of participants in the bridge, the entire bridge should be transferred rather than only transferring a single participant. This is used for bridges that are intended to always be multi-party, such as the bridge created by app_confbridge. I have applied these flags in a few places. Please let me know if there are other bridges where these flags should be applied.
> 
> Unfinished business:
> * There is a large chunk of code that is commented out with regards to parking. The API that this section relies on is currently a work in progress in /team/jrose/bridge_projects/. Once that code has been merged, then the parking-relevant code can be tested.
> * There are likely some small details that I have not addressed. For instance, I do not set any channel variables at all during a blind transfer. It may be desirable to set a BLINDTRANSFER or other variables on channels. Please let me know if there are items that I need to add here.
> * This review is intended only to implement blind transfers, but you will notice in bridging.h an ast_bridge_attended_transfer() function and a stub for it in bridging.c. This is simply a placeholder for now, but it will be implemented soon.
> 
> 
> Diffs
> -----
> 
>   /team/group/bridge_construction/apps/app_bridgewait.c 386463 
>   /team/group/bridge_construction/apps/app_confbridge.c 386463 
>   /team/group/bridge_construction/include/asterisk/bridging.h 386463 
>   /team/group/bridge_construction/include/asterisk/bridging_features.h 386463 
>   /team/group/bridge_construction/include/asterisk/framehook.h 386463 
>   /team/group/bridge_construction/main/bridging.c 386463 
>   /team/group/bridge_construction/main/manager.c 386463 
>   /team/group/bridge_construction/main/pbx.c 386463 
> 
> Diff: https://reviewboard.asterisk.org/r/2470/diff/
> 
> 
> Testing
> -------
> 
> To test this, I created an AMI action called BlindTransfer. The action takes the transferer channel, context, and extension as an argument. With this action, I was able to test both a one-to-one blind transfer, as well as a transfer of a confbridge. They both worked. I wrote this AMI action as a way of testing this API, but I also documented it in case it is decided that this would be a useful action to have permanently.
> 
> 
> Thanks,
> 
> Mark Michelson
> 
>

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