Summary:ASTERISK-21564: API Enhancements - CEL refactoring - bridge state
Reporter:Matt Jordan (mjordan)Labels:Asterisk12
Date Opened:2013-04-17 22:17:21Date Closed:2013-06-13 08:54:01
Status:Closed/CompleteComponents:CEL/General Core/Stasis
Versions:Frequency of
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
** 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
Comments:By: Kinsey Moore (kmoore) 2013-05-15 14:21:36.320-0500

Work on this is available in the following subversion branch: