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

Matt Jordan (JIRA) noreply at issues.asterisk.org
Wed Apr 17 13:44:01 CDT 2013


Matt Jordan created ASTERISK-21496:
--------------------------------------

             Summary: 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


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



More information about the asterisk-bugs mailing list