| Summary: | ASTERISK-21180: Implement channel state events for Stasis HTTP | ||
| Reporter: | Matt Jordan (mjordan) | Labels: | Asterisk12 |
| Date Opened: | 2013-02-27 15:34:03.000-0600 | Date Closed: | 2013-05-10 08:19:38 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Core/Stasis Resources/res_ari |
| Versions: | 12 | Frequency of Occurrence | |
| Related Issues: | |||
| Environment: | Attachments: | ||
| Description: | Now that Stasis-Core is moving along and channel state is getting put out onto the Stasis-Core message bus, we can start exposing channel state changes through Stasis-HTTP.
Channels in a Stasis application - or created as a result of an action in a Stasis application (such as an outbound dial) should have their states sent to the appropriate client over websockets. * Create JSON events representing channel state changes, channel creation, and channel hangup. * -Create an XML schema in source for documenting the events. This might be similar to the existing managerEvent schema (but will probably be better served by something less AMI peculiar)- * Pass events through Stasis-Core out app_stasis' websocket. Note that the channel events might want to live in something other than res_stasis_http Revised task list: * Get parity with AMI for channels that are already in a Stasis Application * Define the subscription model for channels/endpoints * Scope out the work for propagating channel/endpoint messages for subscriptions | ||
| Comments: | By: Kinsey Moore (kmoore) 2013-03-27 18:11:56.211-0500 Work has been occurring in the branch here: http://svn.digium.com/svn/asterisk/team/kmoore/stasis-channel_events-take2 This is in the middle of rework. | ||