[asterisk-bugs] [JIRA] (ASTERISK-21564) API Enhancements - CEL refactoring - bridge state

[Matt Jordan (JIRA)]

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

Matt Jordan updated ASTERISK-21564:
-----------------------------------

    Description: 
Yay, CEL!

With Stasis-Core, we no longer need a bunch of CEL events all over the code, as the state of channels and bridges is conveyed across the Stasis-Core message bus. The second step is to refactor the following:

* Subscribe to the all bridge caching topic in cel.c. Set up a message router to handle bridge updates.
** When both channels join a two-party bridge type, raise a AST_CEL_BRIDGE_START
** When both channels leaves a two-party bridge type, raise a AST_CEL_BRIDGE_END
** When a channel joins a multi-party bridge type, raise a AST_CEL_CONF_ENTER
** When a channel leaves a multi-party bridge type, raise a AST_CEL_CONF_EXIT
** When a channel enters an infinite wait bridge owned by parking (or we receive a parking start message), raise a AST_CEL_PARK_START
** When a channel leaves an infinite wait bridge owned by parking (or we receive a call pickup for a channel in park), raise a AST_CEL_PARK_END
* AST_CEL_CONF_START/AST_CEL_CONF_END
** Nothing raises these events right now. It's a bit odd to do so, since we get conference messages for channels already and we have the initial enter message. We need to investigate these two to determine if they need to be raised or not.
* Remove all instances of the above events

  was:
Yay, CEL!

With Stasis-Core, we no longer need a bunch of CEL events all over the code, as the state of channels and bridges is conveyed across the Stasis-Core message bus. The second step is to refactor the following:

* Subscribe to the all bridge caching topic in cel.c. Set up a message router to handle bridge updates.
** When both channels join a two-party bridge type, raise a AST_CEL_BRIDGE_START
** When both channels leaves a two-party bridge type, raise a AST_CEL_BRIDGE_END
** When a channel joins a multi-party bridge type, raise a AST_CEL_CONF_ENTER
** When a channel leaves a multi-party bridge type, raise a AST_CEL_CONF_EXIT
** When a channel enters an infinite wait bridge owned by parking (or we receive a parking start message), raise a AST_CEL_PARK_START
** When a channel leaves an infinite wait bridge owned by parking (or we receive a call pickup for a channel in park), raise a AST_CEL_PARK_END
* AST_CEL_CONF_START/AST_CEL_CONF_END
** Nothing raises these events right now. It's a bit odd to do so, since we get conference messages for channels already and we have the initial enter message. We need to investigate these two to determine if they need to be raised or not.

    
> API Enhancements - CEL refactoring - bridge state
> -------------------------------------------------
>
>                 Key: ASTERISK-21564
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21564
>             Project: Asterisk
>          Issue Type: New Feature
>          Components: CEL/General, Core/Stasis
>            Reporter: Matt Jordan
>
> Yay, CEL!
> With Stasis-Core, we no longer need a bunch of CEL events all over the code, as the state of channels and bridges is conveyed across the Stasis-Core message bus. The second step is to refactor the following:
> * Subscribe to the all bridge caching topic in cel.c. Set up a message router to handle bridge updates.
> ** When both channels join a two-party bridge type, raise a AST_CEL_BRIDGE_START
> ** When both channels leaves a two-party bridge type, raise a AST_CEL_BRIDGE_END
> ** When a channel joins a multi-party bridge type, raise a AST_CEL_CONF_ENTER
> ** When a channel leaves a multi-party bridge type, raise a AST_CEL_CONF_EXIT
> ** When a channel enters an infinite wait bridge owned by parking (or we receive a parking start message), raise a AST_CEL_PARK_START
> ** When a channel leaves an infinite wait bridge owned by parking (or we receive a call pickup for a channel in park), raise a AST_CEL_PARK_END
> * AST_CEL_CONF_START/AST_CEL_CONF_END
> ** Nothing raises these events right now. It's a bit odd to do so, since we get conference messages for channels already and we have the initial enter message. We need to investigate these two to determine if they need to be raised or not.
> * Remove all instances of the above events

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