[Freeswitch-users] Metaswitch perimeta SBC - any thoughts?

[Cal Leeming [Simplicity Media Ltd]]

I'm going to be doing some more tests on this over the next few days. From
what I can tell, the approach we're trying to use does look sane, it's
working under initial prototypes (benchmarks tbc), and does almost exactly
what we require it to do under the development constraints we have (e.g.
not having to worry about installing individual licenses on developers
machines for propriety s/w such as F5, and being cloud deployable, i.e. not
a physical solution as this would mean giving each developer their own
physical box, or having development run over corp WAN rather than local VM
LAN etc.)

The term 'SBC' seems to be thrown around quite wildly and can mean
different things to different people.. Some SBCs have minimal
functionality, others implement a full range of features including LCR.

I've come to the conclusion that if it does what we require, and it can
scale to the numbers we need it to, then it will probably work fine for us.

However, I would still be interested in hearing from others on large scale
approaches, specifically ones where you can scale out, rather than up (i.e.
you can throw a lot of servers at it, rather than having to increase the
resources of just a single server).

Cal

On Tue, Apr 9, 2013 at 6:41 PM, Cal Leeming [Simplicity Media Ltd] <
cal.leeming at simplicitymedialtd.co.uk> wrote:

> We attempted to use FreeSWITCH as an SBC but came up against problems
> scaling.
>
> Instead my idea was to place a dumb proxy in front of lots of FreeSWITCH
> instances, with two profiles exposed.. one for UC registrations, and
> another for the backend FS instances. When a UC sends a register, it
> forwards the request to a backend, if it was successful then a persist
> entry is created. If a user tried to call another user in the same domain
> (or another domain that we hold), it would send the request through to the
> SBC, the SBC would then check the persistance table for an entry for that
> user, and redirect the query to the appropriate server where the user was
> currently registered. If no entry was found, a random server would be
> picked to handle voicemail and redirects etc. Any INVITEs would also have
> their SIP/SDP re-written to allow RTP proxying as well for full topology
> hiding. This allows a single domain to be spread across an unlimited amount
> of servers. In theory the bottleneck would be the speed of which the SBC
> can proxy packets.. initial tests show that a python prototype can forward
> approx 350mbit/sec on a single thread (using eventlet) before it starts to
> choke, and we were able to saturate a gbit link with zero packet loss and
> jitter using 8 threads (that's with full SIP/SDP parsing too). We've tested
> using the F5 and Stingray too, but their throughput isn't as good.
>
> However, my concern is that no one (from what I can tell) is using this
> approach to scale voice platforms, and this makes me question whether or
> not it is the correct thing to do.
>
> Cal
>
> On Tue, Apr 9, 2013 at 6:20 PM, Michael Jerris <mike at jerris.com> wrote:
>
>> Can you describe a bit more what exactly you want to get out of an SBC
>> for your setup?  This topic is totally fine for the list
>>
>> Mike
>>
>>
>> On Apr 9, 2013, at 1:07 PM, Cal Leeming [Simplicity Media Ltd] <
>> cal.leeming at simplicitymedialtd.co.uk> wrote:
>>
>> Hello all,
>>
>> Does anyone here have any first hand experience using the Metaswitch
>> perimeta SBC with FreeSWITCH?
>> http://www.metaswitch.com/products/perimeta-session-border-controller
>>
>> I know this isn't strictly on-topic, but I find the people on this list
>> are usually best placed to give useful feedback on related products.
>>
>> At the moment we're weighing up the pros/cons of using our own in-house
>> SBC, F5 LTM, Stingray TM, OpenSER, or buying a purpose made SBC such as the
>> Perimeta.
>>
>> Any thoughts?
>>
>> Cal
>>
>> (Mods: if you aren't happy with this being discussed on the list, just
>> let me know).
>>
>>
>>
>> _________________________________________________________________________
>> 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/20130410/3ab6ae68/attachment.html