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