Summary:	ASTERISK-21101: Stasis Core - Refactor Device State support
Reporter:	Matt Jordan (mjordan)	Labels:	Asterisk12
Date Opened:	2013-02-14 16:32:24.000-0600	Date Closed:	2013-04-16 12:08:46
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Core/Stasis
Versions:		Frequency of Occurrence
Related Issues:	cannot be resolved before completion of ASTERISK-20959 Create Stasis Core Module
Environment:		Attachments:
Description:	Once the Stasis Core API is finished, we need to begin refactoring current consumers/producers on the event subsystem to take advantage of it. This includes Device State. Publishers: * {{res_jabber}} * {{res_xmpp}} * {{devicestate}} Consumers: * {{app_queue}} * {{pbx}} * {{ccss}} * {{devicestate}} * {{res_jabber}} * {{res_xmpp}} An important distinction that has to be worked out is {{res_xmpp}} and {{res_jabber}}'s knowledge of what is a local device on this system and what is a remote device state update. For remote device states that come in from an XMPP message, the device state has to be raised in the system. However, notifications that originated locally have to be raised externally, but not again in the system. Currently, this appears to be handled by having two different event types for device state ({{AST_EVENT_DEVICE_STATE}} and {{AST_EVENT_DEVICE_STATE_CHANGE}}); ideally, this would be unified and {{res_xmpp}}/{{res_jabber}} would know whether or not the device was local or external. For now, assume that {{res_corosync}} will be disabled until we figure out how to re-transmit the currently supported items across the wire.
Comments:	By: Kinsey Moore (kmoore) 2013-03-13 11:15:19.233-0500 Having investigated the issue and now done the vast majority of the work, I can safely say that it is not possible to remove the distinction between the local state and cluster-wide state which means that there will be two different all-device topics with caching and device-specific topics that distribute aggregated state. On the plus side, things do get simpler with stasis via removal of task processors that are unnecessary given Stasis' guaranteed serialization of callback invocations, making the device state aggregator always run (instead of being conditionally run which introduces more complexity), and reducing the complexity of the aggregator to a callback that compiles a new state to publish from a pseudo-taskprocessor with its own thread. Ongoing work can be found here: http://svn.digium.com/svn/asterisk/team/kmoore/stasis-device_state By: Kinsey Moore (kmoore) 2013-04-16 12:08:46.302-0500 This has been completed and merged into trunk.