<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
> Security, obscurity and adaptability. If one asterisk fails one<br>
> customer is angry. If one multi-customer asterisk fails, lots of<br>
> customers get angry. ;)<br>
><br>
</div>On the other hand, it's harder to build a scalable solution that<br>
way... There's no reason why we could not have another Asterisk<br>
standing by when one fails. The issue here is that calls would go down<br>
and states would be lost for blinking lamps. That will always happen<br>
(unless someone magically adds the needed code to handle that).<br>
<br>
There are architecture problems that we haven't solved in Asterisk<br>
today in regards to multi-hosting. There's a lack of segmentation of<br>
Asterisk that could prevent overlaps. I've been doing a few things,<br>
like multiparking and SIP domains that are steps toward a solution.<br>
Tilghman has some extra headers for AMI in testing and we've discussed<br>
how to use that for more segmentation by applying event filters to<br>
those headers. Next step would be to be able to restrict access for<br>
orignate-like actions in manager by applying contexts to each manager<br>
account.<br>
<br>
The settings in feature.conf are also pbx-wide, which might be a<br>
problem. There are propably a lot more issues that I don't see right<br>
now.<br>
<br></blockquote><div><br>One great way to have the multi-hosting implemented in all conf files would be<br>to use a technique a bit similar to the 'group' keyword used in zaptel.conf;:<br><br>[general]<br>setting3 = 34<br>
<br>company => 1<br><br>setting1 = 1<br>setting2 = 1<br><br>company => 2<br><br>setting1 = 2<br>
setting2 = 2<br>....<br><br>Thereafter, you add a column in iax/sip_buddies to specify the corresponding company ID.<br><br>I however don't know how such a change would be on a programming point of view.<br><br></div>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
So there are a lot of reasons why you want a single PBX per customer<br>
today. Hopefully someone will fund work so that we can support at<br>
least 50% of the cases in a large PBX with failover, and have the rest<br>
that are advanced users using their own. That would be very beneficial<br>
for all of us.<br>
<br></blockquote><div><br>How do you guys feel about having a local mysql slave database on each Asterisk, for reading only<br>purposes? Is this setup part of the 50% we are tempting to describe here or would integrators<br>
count on good hardware and optimized networks (like separate lans) and only have a master DB<br>to count on? <br> <br><br></div></div>