[asterisk-dev] [Code Review] 3061: External MWI core support with AMI using it.

Matt Jordan reviewboard at asterisk.org
Tue Dec 10 12:03:57 CST 2013



> On Dec. 10, 2013, 5:01 p.m., Matt Jordan wrote:
> > I fundamentally disagree with a design decision made in this patch.
> > 
> > The concept of a 'context' is an Asterisk thing - specifically, a concept that is derived from static .conf files. It has no semantic meaning outside of Asterisk, and certainly has no semantic meaning in voicemail, databases, e-mail servers, or any other thing. From the perspective of defining a structure to its static configuration files, a "context" is a perfectly fine and legitimate concept - but that doesn't mean it should be applied elsewhere.
> > 
> > Asterisk's app_voicemail, rightly or wrongly, allowed users to group mailboxes into compartments delineated by the 'context' concept. This had the side effect of requiring the unique identifier for a mailbox to be 'mailbox at context'. This limitation is entirely an app_voicemail concept and is not needed here.
> > 
> > From the perspective of an external system looking to use Asterisk as an MWI proxy, enforcing 'context' here is limiting and completely unnecessary. If I want to supply 'alice', 'bob', and 'jim' as mailboxes I should be allowed to do so. I should not be forced to use 'default' or something else that has no semantic meaning to my system. At the same time, if I want to provide my own domains (which is really what this is from the perspective of an external user), I should be allowed to do so - but that merely means adding 'alice at foo.net', 'bob at foo.net', and 'jim at bar.com'. The AMI actions, ARI REST calls, and the entire MWI proxy shouldn't care if someone appends a domain to the unique ID comprising the mailbox. It should still just be a string unique ID.
> > 
> > This design flaw has a ripple effect through this entire patch - but until we resolve this fundamental problem, I'm not sure I'd look at this patch any further.
> 
> rmudgett wrote:
>     The mailbox at context concept is completely entrenched in the Asterisk code base and cannot be removed without reworking the entire MWI system.  Existing MWI events, channel drivers, and the stasis messages all assume this format.  Trying to ignore this fact in the external MWI core and external MWI AMI interface is more limiting.
>

I disagree.

First, imposing limitations on an external system because something that we're trying to move away from was written in a way that is different than how external systems would want to consume it defeats the purpose of what we're trying to do here. I'd rather spend time getting Asterisk to be a communications engine that external systems want to consume - and do it correctly - rather than enforce some silly limitation for the next 10 years "because that's the way Asterisk has always done it".

Looking at what actually has to be changed:

(1) Raising a Stasis message for MWI requires a mailbox and context. However, it really doesn't - it actually uses a unique ID (single string) which is a concatanation of mailbox/context. This could easily be modified to accept an empty string for context and, if an empty string is provided, it uses just the mailbox as the unique ID.

(2) chan_sip/chan_iax2/chan_dahdi: Subscribing for MWI. This currently will auto-append a 'default' to what a peer subscribes for doesn't contain a context. This behavior could be kept by default. Optionally, we could choose to not append 'default' via some configuration option. Or we could make a breaking change and no longer auto-append 'default'. Either way, this is not a large amount of code and could be handled.

(3) chan_pjsip: Subscribing for MWI here passes the value in as-is. There's nothing here that needs to be done, as it subscribes for whatever you told it to subscribe for.

I don't see any technical limitation here that couldn't be easily overcome.


- Matt


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


On Dec. 9, 2013, 9:51 p.m., rmudgett wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3061/
> -----------------------------------------------------------
> 
> (Updated Dec. 9, 2013, 9:51 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> This patch can be broken into four main components:
> 
> 1) Voicemail callback registration/unregistration function improvements are in the following files:
> include/asterisk/doxyref.h,
> include/asterisk/app.h,
> main/app.c, and
> apps/app_voicemail.c.
> 
> * The voicemail registration/unregistration functions now take a struct of callbacks instead of a lengthy parameter list of callbacks.
> 
> * The voicemail registration/unregistration functions now prevent a competing module from interfering with an already registered callback supplying module.
> 
> 2) The core resource support for external MWI providers are in the following files:
> include/asterisk/res_mwi_external.h,
> configs/sorcery.conf.sample,
> res/res_mwi_external.c, and
> res/res_mwi_external.exports.in.
> 
> * The core external MWI resource provides for MWI message counts persistence using sorcery.  With sorcery, the user is able to configure which sorcery wizzard backend to use if the default astdb is not desired.
> 
> * The core external MWI resoruce provides some CLI commands to manually manage the MWI counts if needed.
> The new CLI commands are:
> "mwi external delete all",
> "mwi external delete like <regex>",
> "mwi external delete mailbox <box[@[context]]>",
> "mwi external list all",
> "mwi external list like <regex>",
> "mwi external show mailbox <box[@[context]]>", and
> "mwi external update mailbox <box[@[context]]>".
> 
> 3) The AMI component of external MWI is in:
> res/res_mwi_external_ami.c
> 
> * The external MWI AMI interface provides a thin wrapper around the core external MWI resource.
> The resource adds the following AMI actions:
> MWIExternalGet,
> MWIExternalDelete, and
> MWIExternalUpdate.
> 
> 4) A consistency fix to sorcery astdb regex record retrieval is in:
> res/res_sorcery_astdb.c
> 
> * The AstDB wizzard is inconsistent with the other sorcery wizzards with its regex record selection.  Any pattern that uses the '^' regex character to anchor the pattern to the beginning of the key *must* be a simple prefix.  Any wildcard matching used with the '^' anchor will fail.  As a result, a regex of "^.*@context$" will not return anything even if there are mailboxes in "context".
> 
> 
> Diffs
> -----
> 
>   /trunk/res/res_sorcery_astdb.c 403574 
>   /trunk/res/res_mwi_external_ami.c PRE-CREATION 
>   /trunk/res/res_mwi_external.exports.in PRE-CREATION 
>   /trunk/res/res_mwi_external.c PRE-CREATION 
>   /trunk/main/app.c 403574 
>   /trunk/include/asterisk/res_mwi_external.h PRE-CREATION 
>   /trunk/include/asterisk/doxyref.h 403574 
>   /trunk/include/asterisk/app.h 403574 
>   /trunk/configs/sorcery.conf.sample 403574 
>   /trunk/apps/app_voicemail.c 403574 
> 
> Diff: https://reviewboard.asterisk.org/r/3061/diff/
> 
> 
> Testing
> -------
> 
> Used the CLI "database show" along with the new CLI commands and AMI actions to test adding/updating, getting, and deleting external MWI counts.
> 
> 
> Thanks,
> 
> rmudgett
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20131210/0c41cb04/attachment.html>


More information about the asterisk-dev mailing list