[asterisk-bugs] [JIRA] (ASTERISK-21877) Bridge API Enhancements - fix the Parking BUGBUG comments in trunk

[Jonathan Rose (JIRA)]

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

Work on ASTERISK-21877 started by Jonathan Rose.

> Bridge API Enhancements - fix the Parking BUGBUG comments in trunk
> ------------------------------------------------------------------
>
>                 Key: ASTERISK-21877
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21877
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/Bridging, Resources/res_parking
>    Affects Versions: 12
>            Reporter: Matt Jordan
>            Assignee: Jonathan Rose
>              Labels: Asterisk12
>      Target Release: 12
>
>
> There are two known issues in Parking:
> * {{./res/parking/parking_bridge.c: /* BUGBUG Adding back local channel swapping made us not hear music on hold for the channel that got swapped}}
> When a local optimization occurs and the channel on the other end of the Local channel is put into parking, the role assignments and options set on the Local channel are not completely honored. This includes the Ringing option. In general, however, when the channel is pushed into the parking bridge, it should obtain the roles/options that were previously on the Local channel.
> * {{./res/parking/parking_applications.c: /* XXX BUGBUG - determining the parker when transferred to deep park priority}}
> When a channel is blind transferred into a parking extension, the parker of the channel is relayed via the Stasis-Core message to concerned parties. However, if the application in the first extension is not the parking application, the parker is unknown and the message will be incomplete.
> In order to convey this information, we need to store a snapshot of the parker channel on the parkee channel, as the channel itself will most likely have gone away (and hence cannot be queried from the Stasis-Core cache). Since this is a scenario that may occur in other places - that is, a channel has to relay information about a channel that affected it and we aren't guaranteed that the channel exists any longer (and we don't want to affect its lifetime) - we should implement a generic solution that allows channel snapshots to be stored in a datastore on a channel.
> Note that the multi-channel blob object allows role-typed snapshots to be stored in an opaque ao2 container, and may be of use here.

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