Summary:ASTERISK-21337: Bridge API Enhancements - add stasis core messages for blind/attended transfers
Reporter:Matt Jordan (mjordan)Labels:Asterisk12
Date Opened:2013-03-29 09:18:43Date Closed:2013-06-28 14:06:01
Status:Closed/CompleteComponents:Core/Bridging Core/Channels
Versions:Frequency of
must be completed before resolvingASTERISK-21517 API Improvements: refactor app_queue to listen for a Transfer stasis message and update the Queue Log appropriately
is related toASTERISK-21698 Bridge API Enhancements - handle Attended Transfers in CDRs
Description:Please see the [Bridge Construction|http://svn.asterisk.org/svn/asterisk/team/group/bridge_construction/] Team project for the current status of this work.

Transfers typically involve a sequence of actions taken upon one or more bridges. While third parties can reconstruct those actions based solely upon bridge messages, it may be difficult for those parties to know whether or not a transfer is beginning or ending, or whether it failed or succeeded.

Currently, {{chan_sip}} contains a Transfer event that is raised during transfer scenarios. While that's all fine and good, the Transfer event needs to be raised in the bridging core. In addition, there are some scenarios where a combination of BridgeEnter/BridgeLeave events may not be sufficient to determine what the end of the transfer looks like. Consider the following:

* Party A calls Party B and is placed into a bridge
* Party A performs an attended transfer to VoiceMail.
* Party A completes the attended transfer, Party B takes the place of Party A, and Party A is hung up.

When Party B takes the place of Party A, a masquerade occurs, as Party A is not in a bridge when the transfer operation completes. This means that while a BridgeLeave message should fire for Party A (as it leaves the bridge prior to being hung up), Party B will not receive a BridgeLeave message - it is stolen out of the bridge and put directly into VoiceMail.

Something has to tell consumers what just happened. Hence, the transfer message.

The Transfer Message needs to convey the following:

* TransferMethod - whether this is a 'core' transfer (DTMF in features) or 'external' transfer (SIP, IAX2, etc.)
* TransferType - 'blind' or 'attended'
* The Transferer channel snapshots and the transfer target channel snapshots
* Whether or not the transfer operation succeeded or failed
* If successful, whether the destination of the transfer is a dialplan location (for blind transfers), a bridge (and its ID for attended transfers), or an application (for call pickup (blonde transfers) or voicemail, etc.)

This is a rather large meta message, but allows consumers to properly know the state of the participants.
Comments:By: Mark Michelson (mmichelson) 2013-06-07 16:07:50.724-0500

For the record, in the scenario described, there will be a BridgeLeave event for B. The B channel is removed from the bridge and a callback results in the masquerade occurring.