Summary:ASTERISK-21496: Stasis Core - Add the Transfer bridging message and corresponding AMI event
Reporter:Matt Jordan (mjordan)Labels:Asterisk12
Date Opened:2013-04-17 13:44:00Date Closed:2013-04-17 13:56:22
Status:Closed/CompleteComponents:Core/Bridging Core/ManagerInterface Core/Stasis
Versions:Frequency of
Description: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.