[asterisk-bugs] [JIRA] (ASTERISK-21462) Stasis Core - Refactor random AMI events

[Matt Jordan (JIRA)]

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

Matt Jordan reassigned ASTERISK-21462:
--------------------------------------

    Assignee: Matt Jordan
    
> Stasis Core - Refactor random AMI events
> ----------------------------------------
>
>                 Key: ASTERISK-21462
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21462
>             Project: Asterisk
>          Issue Type: New Feature
>      Security Level: None
>          Components: Core/ManagerInterface, Core/Stasis
>            Reporter: Matt Jordan
>            Assignee: Matt Jordan
>              Labels: Asterisk12
>
> The events on this issue need to be refactored from direct AMI event generation to notifications that are put out on the Stasis-Core message bus. 
> For events related to system level information, a new 'system' topic should be created. Messages related to the health and status of the system should be published to this topic.
> For those events that dump non-channel related events out, a generic function that takes in a list of parameters and encodes them into JSON should be created. A fair number of the events listed here have little value outside of AMI, and can always be refactored into a different, more structured approach if needed.
> If an event references a channel but does *not* imply an actual state change, the name or unique ID of the channel can be passed along. The manager core itself can query for the state of the channel in the cache and use that snapshot to send out to concerned parties. One way of doing this would be:
> {noformat}
> {
>   Channels: [
>     { ChannelName: "SIP/Foo",
>       ChannelRole: "Spyee" },
>     { ChannelName: "SIP/Bar",
>       ChannelRole: "Spyer" },
>   ]
> }
> {noformat}
> * app_chanspy
> ** ChanSpyStart. Conveys two channels with roles "Spyee" and "Spyer". No state is changed in the channels.
> ** ChanSpyStop. Only conveys the Spyee Channel.
> * app_minivm
> ** MiniVoiceMail. (Currently formatted incorrectly, we should fix that). This should be handled completely in JSON.
> * app_stack
> ** Raise the existing VarSet channel event.
> * app_voicemail
> ** MessageWaiting. Currently has two different events with different parameters; this should be done in JSON and - most likely - always convey the same parameters.
> * CDR/CEL
> ** While many of the parameters are conveyed as part of a channel, the CDR and CEL events may be posted to a backend after the channel has been disposed of and may be removed from the cache. This should probably be a JSON blob.
> * func_global
> ** Refactor to the VarSet channel event.
> * asterisk
> ** Shutdown/FullyBooted. Both can be JSON.
> * cdr
> ** Reload. This should be a generic call in a common header file that would raise a reload event on any module reload. {{loader.c}} should perform this in {{ast_module_reload}} (possibly replacing the test suite event)
> ** NewAccountCode/NewPeerAccount - these have been refactored in the CDR work already.
> * dnsmgr/enum - see Reload under cdr
> * loader.c
> ** ModuleLoadReport - JSON
> * manager.c
> ** Reload - see Reload under cdr
> ** all others here can be left alone (they are in manager after all)
> * pbx.c
> ** HangupHandler* - use a channel snapshot (most likely), as the channel state is likely to change before the cache can be queried
> * res_fax
> ** FaxStatus - channel state doesn't change much while a channel is in the fax application. Use a handle to the channel (and have manager grab it from the cache) along with a JSON blob for the fax data.
> ** ReceiveFax/SendFax - same as FaxStatus
> * res_jabber/res_xmpp
> ** JabberEvent - remove. This is useless.
> ** JabberStatus - this should probably be subsumed as an endpoint. If not, convert to JSON.
> * res_monitor
> ** MonitorStart/MonitorStop - a channel snapshot event is sufficient. Potentially, a handle would work as well.
> * res_musiconhold
> ** MusicOnHold - this uses a subevent field. This should probably be changed to MusicOnHoldStart/MusicOnHoldStop. A channel snapshot with a blog is fine; if possible, use a handle and have manager get it from the cache.

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