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@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@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@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@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org