[asterisk-bugs] [JIRA] (ASTERISK-21496) Stasis Core - Add the Transfer bridging message and corresponding AMI event

[Matt Jordan (JIRA)]

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

Matt Jordan closed ASTERISK-21496.
----------------------------------

    Resolution: Duplicate
    
> Stasis Core - Add the Transfer bridging message and corresponding AMI event
> ---------------------------------------------------------------------------
>
>                 Key: ASTERISK-21496
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21496
>             Project: Asterisk
>          Issue Type: New Feature
>      Security Level: None
>          Components: Core/Bridging, Core/ManagerInterface, Core/Stasis
>            Reporter: Matt Jordan
>              Labels: Asterisk12
>
> 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