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

[Mark Michelson]

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

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/20130424/ae29bcb9/attachment-0001.htm>