[Freeswitch-users] Advice on scalable design pattern

Thu Mar 14 20:41:01 MSK 2013

Thanks for the detailed comments, anyone else have any thoughts on this?

Cal

On Thu, Mar 14, 2013 at 5:22 PM, Muhammad Shahzad <shaheryarkh at gmail.com>wrote:

> Well i have done a lot of "trail and error" on this specific problem in
> past 3 years and have come to conclusion that,
>
> 1. You need at least one layer 4 switching service that manages all
> routing between your end-users and your internal cluster of media services.
> It checks and validates inbound traffic, decides which partition (if your
> cluster is sub-group into different service types) or portion (if your
> cluster consists of similar nodes) of your cluster serves it and forwards
> traffic to it. What software you use for this purpose is entirely your
> choice? I have used OpenSIPS, Kamailio, OverSIP and even a small proxy i
> wrote in PERL. The fundamental principle for choosing the right software is
> how you want to handle traffic? e.g.
>
>     a). You can use redirection using SIP response code 302.
>     b). You can do state-full relay, by creating and managing SIP
> transactions.
>     c). You can do bridging, e.g. by using B2BUA.
>
> 2. You need layer 5 switching cluster, providing the actually services the
> end-user needs. You can break the cluster in small groups service-wise,
> e.g. IVR Service, Voicemail Service, Billing Service, Transcoding Service
> etc. etc. OR if you can have each node serving all services on its own.
>
> 3. Often to handle outbound traffic you can setup another layer 4
> switching service or use same as the one for inbound. Generally for very
> very large setup e.g. >10M users you should have a separate termination
> gateway.
>
> Thank you.
>
>
> On Thu, Mar 14, 2013 at 5:02 PM, Cal Leeming [Simplicity Media Ltd] <
> cal.leeming at simplicitymedialtd.co.uk> wrote:
>
>> 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
>>>>
>>>>
>>>
>>
>> _________________________________________________________________________
>> 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
>>
>>
>
>
> --
> Mit freundlichen Grüßen
> Muhammad Shahzad
> -----------------------------------
> CISCO Rich Media Communication Specialist (CRMCS)
> CISCO Certified Network Associate (CCNA)
> Cell: +49 176 99 83 10 85
> MSN: shari_786pk at hotmail.com
> Email: shaheryarkh at googlemail.com
> _________________________________________________________________________
> 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/bcb09bee/attachment.html 