<br><br><div class="gmail_quote">On Mon, Jul 30, 2012 at 2:36 AM, Kannan <span dir="ltr"><<a href="mailto:vasdeveloper@gmail.com" target="_blank">vasdeveloper@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>2. Multi-tenant PBX: Configuring multiple PBXs within the same instance of Asterisk. I.e. partitioning a single instance of Asterisk into multiple PBXs by way of configurations, using unique landing context for each tenant.</div>
<div>3. Virtual PBX: Multiple virtual machines within the same hardware, each host an instance of Asterisk.</div></blockquote><div><br></div><div>We use number two. We dabbled with number three but didn't like the results for a lot of different reasons. As others have mentioned, there is a certain level of danger when you mix companies so closely. We have in the past made a mistake and brought down the whole system, but it's been many years since we've done that. Part is improved skill and part is that Asterisk has improved and no longer commits suicide for certain minor errors.</div>
<div> </div><div>To do this, you need to plan out a good naming convention for everything that will be unique to customers accounts. SIP accounts, macros, contexts, etc etc. We use the accountcode feature and prepend the accountcode through the dial plan and accounts.</div>
<div><br></div><div>accountcode.301 would be a SIP account</div><div><br></div><div>accountcode#function would be a context name</div></div><div><br></div><div>We do deploy custom hardware for specific functions or customers who are particularly large in some cases. We just need a good reason to. Like they want to self-manage, or they make a lot of changes, need custom integration with databases, etc.</div>
<div><br></div>-- <br><div>Carlos Alvarez</div><div>TelEvolve</div><div>602-889-3003</div><div><br></div><br>