Since I started working on implementation of this, I've noticed a few things that change this specification a little.
First, owing to how res_mwi_external has been made, it can only be used without app_voicemail. Since when using
externally controlled MWI there aren't any other mailboxes that we need to be worried about as far as conflicts and
such are concerned, there isn't really a need to require that the only mailboxes the consumer can manipulate are
ones that were created by and are controlled by ARI.
If we nix this requirement, then ARI will be able to manipulate mailboxes created through AMI (and vice versa),
but the point since these are all external control mechanisms, the worry about conflicting operations going through
on mailboxes that are being managed by multiple systems is greatly diminished.
The only major change from the original description is that any function where I mentioned a response of
"409 - Mailbox not in a stasis application" is no longer a plausible response. I'm not entirely sure what the
This also makes state persistence a little easier to manage since there wouldn't be a need to re-establish a
mailbox as belonging to ARI between reloads.
Jonathan R. Rose
Digium, Inc. | Software Engineer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
direct +1 256 428 6139
Check us out at: http://digium.com & http://asterisk.org
Digium, Inc. | Software Engineer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
direct +1 256 428 6139
Check us out at: http://digium.com & http://asterisk.org
_______________________________________________ asterisk-app-dev mailing list asterisk-app-dev@xxxxxxxxxxxxxxxx http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
