[asterisk-dev] [Code Review] 2532: Migrate a slew of AMI events over to Stasis-Core

svnbot reviewboard at asterisk.org
Fri May 24 15:44:11 CDT 2013


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2532/
-----------------------------------------------------------

(Updated May 24, 2013, 3:44 p.m.)


Status
------

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
-------

Committed in revision 389733


Bugs: ASTERISK-21462
    https://issues.asterisk.org/jira/browse/ASTERISK-21462


Repository: Asterisk


Description
-------

This patch refactors a number of AMI events over to Stasis-Core. This includes:
* ChanSpyStart/Stop
* MonitorStart/Stop
* MusicOnHoldStart/Stop
* FullyBooted/Reload
* All VoiceMail/MWI related events

Some infrastructure changes were also made in order to support the new events. This included:
* A new generic AMI topic and message type. Generic AMI messages have a JSON blob that conforms to the following:
 { "type": s, "class_type": s, "event": o}
 where type is the AMI event type; class_type is the AMI class authorization; event is a sequence of key/value pairs that will be directly outputted to AMI.
* MWI stasis information was renamed to better reflect the naming conventions used
* MWI objects can now reference a channel snapshot. Often, an MWI chance occurs because a channel modified the state of a mailbox, and having direct access to a snapshot of the channel at that moment in time is important.

In general, this patch makes a number of trade-offs between what AMI has historically output and what makes the most sense for Stasis-Core to provide. A good example of this are the number of message types defined for the various media/channel related events, as well as what is published to the generic manager topic versus the already defined system topic. The approach taken here was to push information that only AMI consumes to AMI, and if future consumers want that information, to refactor those messages to another topic at that time.


Diffs
-----

  /team/mjordan/ami-refactoring/main/manager_mwi.c 388381 
  /trunk/CHANGES 389006 
  /trunk/apps/app_chanspy.c 389006 
  /trunk/apps/app_fax.c 389006 
  /trunk/apps/app_minivm.c 389006 
  /trunk/apps/app_voicemail.c 389006 
  /trunk/channels/chan_dahdi.c 389006 
  /trunk/channels/chan_iax2.c 389006 
  /trunk/channels/chan_mgcp.c 389006 
  /trunk/channels/chan_sip.c 389006 
  /trunk/channels/chan_skinny.c 389006 
  /trunk/channels/chan_unistim.c 389006 
  /trunk/channels/sig_pri.c 389006 
  /trunk/include/asterisk/_private.h 389006 
  /trunk/include/asterisk/app.h 389006 
  /trunk/include/asterisk/json.h 389006 
  /trunk/include/asterisk/manager.h 389006 
  /trunk/include/asterisk/stasis_channels.h 389006 
  /trunk/main/app.c 389006 
  /trunk/main/asterisk.c 389006 
  /trunk/main/cdr.c 389006 
  /trunk/main/cli.c 389006 
  /trunk/main/dnsmgr.c 389006 
  /trunk/main/enum.c 389006 
  /trunk/main/json.c 389006 
  /trunk/main/loader.c 389006 
  /trunk/main/manager.c 389006 
  /trunk/main/manager_channels.c 389006 
  /trunk/main/pbx.c 389006 
  /trunk/main/stasis_channels.c 389006 
  /trunk/res/res_fax.c 389006 
  /trunk/res/res_jabber.c 389006 
  /trunk/res/res_monitor.c 389006 
  /trunk/res/res_musiconhold.c 389006 
  /trunk/res/res_sip_mwi.c 389006 
  /trunk/res/res_xmpp.c 389006 

Diff: https://reviewboard.asterisk.org/r/2532/diff/


Testing
-------


Thanks,

Matt Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20130524/70c9e0e2/attachment.htm>


More information about the asterisk-dev mailing list