[asterisk-bugs] [JIRA] (ASTERISK-23941) ARI: Attended transfers of channels into Stasis application lose information

[Kinsey Moore (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-23941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=220209#comment-220209 ] 

Kinsey Moore edited comment on ASTERISK-23941 at 7/2/14 3:59 PM:
-----------------------------------------------------------------

The current behavior of Stasis() in regard to attended transfers as demonstrated in tests/rest_api/bridges/attended_transfer is as follows:
* Swap transfers are allowed with the Stasis()-controlled bridge
** This results in situations where non-Stasis()-controlled channels are allowed into Stasis()-controlled bridges
* ARI applications are not directly notified that swap operations have occurred
** It sees a BridgeAttendedTransfer message mention a channel it controls
** It sees its controlled channel exit the bridge, exit Stasis(), and hangup
** It sees a new uncontrolled channel enter a bridge it controls with no indication that it is replacing the channel that hungup
*** The swap field in the json blob defines the uniqueid of the channel that is being swapped, but that does not get passed on to Stasis() event consumers.

Conclusion: Stasis() must know about any channels being swapped out and it must also control the resultant channel.

The paths forward:

Option 1: Forbid Swap Transfers Again
* Reinstate swap prevention flags for all ARI bridges (easy)
* Write masquerade fixup code to notify ARI that the name of its channel has changed (easy-moderate)
* Optionally, write bridging code to allow double-masquerade transfers (easy-moderate)
** This would allow app-local-app transfers to occur
** This would require a new stasis attended transfer message variant
* In this case, Stasis() would behave similarly to ConfBridge(); it would not participate outside itself in the bridging framework

Option 2: Forge Onward with Attended Transfers
* Add new stasis attended transfer message variant for instances where local channels are required to accomplish the bridge (easy)
** This allows Stasis() to notify ARI consumers that their channel is being replaced with another
* Intercept channels entering Stasis()-controlled bridges (unknown difficulty)
** Force them into Stasis() before adding them into the bridge via Stasis() channel control mechanisms

Option 3: Other?


was (Author: kmoore):
The current behavior of Stasis() in regard to attended transfers as demonstrated in tests/rest_api/bridges/attended_transfer is as follows:
* Swap transfers are allowed with the Stasis()-controlled bridge
** This results in situations where non-Stasis()-controlled channels are allowed into Stasis()-controlled bridges
* ARI applications are not directly notified that swap operations have occurred
** It sees a BridgeAttendedTransfer message mention a channel it controls
** It sees its controlled channel exit the bridge, exit Stasis(), and hangup
** It sees a new uncontrolled channel enter a bridge it controls with no indication that it is replacing the channel that hungup
*** The swap field in the json blob defines the uniqueid of the channel that is being swapped, but that does not get passed on to Stasis() event consumers.

Conclusion: Stasis() must know about any channels being swapped out and it must also control the resultant channel.

The paths forward:

Option 1: Forbid Swap Transfers Again
* Reinstate swap prevention flags for all ARI bridges (easy)
* Write masquerade fixup code to notify ARI that the name of its channel has changed (easy-moderate)
* Optionally, write bridging code to allow double-masquerade transfers (easy-moderate)
** This would allow app-local-app transfers to occur
** This would require a new stasis attended transfer message type
* In this case, Stasis() would behave similarly to ConfBridge(); it would not participate outside itself in the bridging framework

Option 2: Forge Onward with Attended Transfers
* Add new stasis attended transfer message type for instances where local channels are required to accomplish the bridge (easy)
** This allows Stasis() to notify ARI consumers that their channel is being replaced with another
* Intercept channels entering Stasis()-controlled bridges (unknown difficulty)
** Force them into Stasis() before adding them into the bridge via Stasis() channel control mechanisms

Option 3: Other?

> ARI: Attended transfers of channels into Stasis application lose information
> ----------------------------------------------------------------------------
>
>                 Key: ASTERISK-23941
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-23941
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/Bridging, Resources/res_ari
>            Reporter: Matt Jordan
>            Assignee: Kinsey Moore
>
> When performing a SIP level attended transfer into Stasis, insufficient information is presented for an external application to adequately handle what just occurred.
> For example: when a PJSIP channel enters into a Stasis application as the second leg of an attended transfer, when the attended transfer completes, a masquerade and/or a bridge swap may be performed to replace the existing PJSIP channel. Because a new channel is coming into a Stasis application, the following must occur:
> # A StasisStart event must be emitted for the channel entering into the Stasis application.
> # The attended transfer event must inform the ARI client of the channels involved, including the channel taking the place of the channel leaving the application.
> # A StasisEnd event must be emitted for the channel leaving the Stasis application.



--
This message was sent by Atlassian JIRA
(v6.2#6252)