[Freeswitch-users] Advice on scalable design pattern

[Cal Leeming [Simplicity Media Ltd]]

Sorry, hit send too fast!

I think ultimately this is going to come down to trial and error, and a
heck of a lot of testing.. If I can avoid having to re-do the work of other
people then great, but it may just be one of those "gotta find out for
yourself" things.

Cal

On Thu, Mar 14, 2013 at 4:00 PM, Cal Leeming [Simplicity Media Ltd] <
cal.leeming at simplicitymedialtd.co.uk> wrote:

> I've looked at a countless number of set ups (including Kazoo), the
> problem here is choice.. there's many different ways of doing things.
>
> Some people have even gone to the extent of implementing a bunch of
> switching logic within their proxies.. others use them as dumb transport
> layers.
>
> Cal
>
>
> On Thu, Mar 14, 2013 at 3:43 PM, Ben Langfeld <ben at langfeld.co.uk> wrote:
>
>> Have you looked at how 2600hz do this kind of thing with Kazoo?
>>
>> Regards,
>> Ben Langfeld
>>
>>
>> On 14 March 2013 03:02, Cal Leeming [Simplicity Media Ltd] <
>> cal.leeming at simplicitymedialtd.co.uk> wrote:
>>
>>> Hello all,
>>>
>>> I'm currently looking at the various different ways you can deploy
>>> FreeSWITCH in a scalable manner, but struggle a little bit on design.
>>>
>>> The sweet spot I'm trying to find is one where I can scale out capacity
>>> by simply throwing more servers at it.
>>>
>>> In an ideal world, this would mean support for;
>>>
>>> * Have multiple users from multiple domains to be spread over multiple
>>> servers... a single domain should not be restricted to a single FreeSWITCH
>>> instance
>>> * Have no single point of failure within the structure
>>> * Have no single point of bottleneck within the structure
>>> * Should not use OpenSIPS.. (I suspect this might get me a lot of flack,
>>> but seriously, I'd rather write my own in python or ZXTM traffic script
>>> than use OpenSIPS lol).
>>>
>>> So far, the best option I can come up with is (although I'm not sure if
>>> it's the best available);
>>>
>>> * Proxy sitting in front of all backend FreeSWITCH instances, acting in
>>> a media proxy fashion only (dual pair of proxies in active/passive mode)
>>> * Proxy tracks registrations to the appropriate backend instance, and
>>> makes their session sticky
>>> * 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't require putting in a request to your upstream providers for an
>>> additional set of trunks.
>>> * 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.
>>>
>>> The other simpler option is to allocate domains to a specific backend
>>> instance.. but this really doesn'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.
>>>
>>> Any general thoughts/comments on this would be much appreciated.
>>>
>>> Thanks
>>>
>>> Cal
>>>
>>> _________________________________________________________________________
>>> Professional FreeSWITCH Consulting Services:
>>> consulting at freeswitch.org
>>> http://www.freeswitchsolutions.com
>>>
>>> 
>>> 
>>>
>>> Official FreeSWITCH Sites
>>> http://www.freeswitch.org
>>> http://wiki.freeswitch.org
>>> http://www.cluecon.com
>>>
>>> FreeSWITCH-users mailing list
>>> FreeSWITCH-users at lists.freeswitch.org
>>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>>> http://www.freeswitch.org
>>>
>>>
>>
>> _________________________________________________________________________
>> Professional FreeSWITCH Consulting Services:
>> consulting at freeswitch.org
>> http://www.freeswitchsolutions.com
>>
>> 
>> 
>>
>> Official FreeSWITCH Sites
>> http://www.freeswitch.org
>> http://wiki.freeswitch.org
>> http://www.cluecon.com
>>
>> FreeSWITCH-users mailing list
>> FreeSWITCH-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130314/1a9ecca9/attachment.html