[asterisk-bugs] [JIRA] (ASTERISK-21337) Bridge API Enhancements - add stasis core messages for blind/attended transfers

[Matt Jordan (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-21337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Jordan updated ASTERISK-21337:
-----------------------------------

    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.


  was:
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.

The blind/attended transfer APIs should let Stasis-core know when a transfer operation is beginning, when it ends, and what the final state of the involved bridges/channels is. This is particularly important for attended transfers involving an application where a channel masquerade has to occur, as this operation typically does not follow the anticipated bridge enter/leave pattern.

    
> Bridge API Enhancements - add stasis core messages for blind/attended transfers
> -------------------------------------------------------------------------------
>
>                 Key: ASTERISK-21337
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21337
>             Project: Asterisk
>          Issue Type: New Feature
>          Components: Core/Bridging, Core/Channels
>            Reporter: Matt Jordan
>              Labels: Asterisk12
>      Target Release: 12
>
>
> 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.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira