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

[opticron]

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

Ship it!


Ship It!

- opticron


On May 17, 2013, 2:44 p.m., Matt Jordan wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2532/
> -----------------------------------------------------------
> 
> (Updated May 17, 2013, 2:44 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> 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/20130523/13a215a8/attachment.htm>