<div>Hello all,</div><div><br></div><div>I&#39;m currently looking at the various different ways you can deploy FreeSWITCH in a scalable manner, but struggle a little bit on design.</div><div><br></div><div>The sweet spot I&#39;m trying to find is one where I can scale out capacity by simply throwing more servers at it.</div>
<div><br></div><div>In an ideal world, this would mean support for;</div><div><br></div><div>* Have multiple users from multiple domains to be spread over multiple servers... a single domain should not be restricted to a single FreeSWITCH instance</div>
<div>* Have no single point of failure within the structure</div><div>* Have no single point of bottleneck within the structure</div><div>* Should not use OpenSIPS.. (I suspect this might get me a lot of flack, but seriously, I&#39;d rather write my own in python or ZXTM traffic script than use OpenSIPS lol).</div>
<div><br></div><div>So far, the best option I can come up with is (although I&#39;m not sure if it&#39;s the best available);</div><div><br></div><div>* Proxy sitting in front of all backend FreeSWITCH instances, acting in a media proxy fashion only (dual pair of proxies in active/passive mode)</div>
<div>* Proxy tracks registrations to the appropriate backend instance, and makes their session sticky</div><div>* If backend instance needs to make a call to another user in the same domain, it bridges to the call to back to the proxy, the proxy then determines which other FreeSWITCH instance has the user then routes the request accordingly. If the call is to an external destination, the proxy will route it to the traffic aggregation switches (which is basically another pair of FreeSWITCH instances), which then gets routed to the upstream provider.. this means you only have to maintain 2 sets of trunk configuration.. so when you need to scale out your freeswitch backends, it doesn&#39;t require putting in a request to your upstream providers for an additional set of trunks.</div>
<div>* The bottleneck within these clusters is the dual proxies in active/passive mode.. you could fix this by allocating customers to a specific cluster (rather than instance), thus controlling which customers go to which proxy.. if an entire cluster dies, you can re-route that clusters traffic to a different cluster.</div>
<div><br></div><div>The other simpler option is to allocate domains to a specific backend instance.. but this really doesn&#39;t feel clean.. it means a customer cannot scale past the floor limit of a single instance, it has less redundancy, and overall just feels wrong.</div>
<div><br></div><div>Any general thoughts/comments on this would be much appreciated.</div><div><br></div><div>Thanks</div><div><br></div><div>Cal</div>