[Freeswitch-users] Advice on scalable design pattern

Thu Mar 14 20:22:49 MSK 2013

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130314/9fd3dc68/attachment.html 