Open Source SBC – Is there such a thing?
Session Border Controllers (SBCs) are utilized as a means to providing both load balancing and security structures for VoIP networks. To be completely honest, 90% of my customers utilize SBC appliances, be it Acme Packet, Juniper, NexTone or others.
According to a report by Transnesus, a combination of OpenSER and Asterisk can be utilized as a Back-To-Back-User-Agent (B2BUA) structure – however, the general configuration and setup isn’t clear and straight forward. I’ve been thinking to myself: “Why hadn’t anyone written and Open Source SBC? could it be? usually there’s an Open Source alternative to any commercial product”.
Like any other search on the net, I’ve pointed my Firefox to Google, and typed the phrase “Open Source SBC”, aparently, such a thing exists from a company called Solegy – over at the web address: http://www.opensourcesip.org. So, I downloaded the source code, and after a 30 minute compilation phase (bearing in mind working on a Virtual server running under VMWARE Server) – the compilation completed.
Compiling was one thing, running it was a completely different thing – took me a while to realize where the binary is located and how the configuration works out – once I did that was a breeze. On my system, after compilation the binary was located according to the following:
[root@opensbc obj_linux_x86_r]# pwd /root/OpenSBC-1.1.5-RC1-Bundle/opensbc/obj_linux_x86_r [root@opensbc obj_linux_x86_r]# ./opensbc -x Message from syslogd@ at Thu Nov 13 23:15:35 2008 ... tvms OpenSBC: Starting service process "OpenSBC" v1.1.5-25
Per the information provided by Solegy, the OpenSBC project supports several modes of operations, ranging according to the following:
Full Mode - By default OpenSBC runs in full mode exposing its capability both as a relay SIP proxy, Registrar and as a B2B User Agent. When OpenSBC receives an INVITE or a REGISTER request it would follow the following procedure to make a decision how to route a request: ● If the Request-URI resolves to a remote domain, the request will be relayed. If a relay route is available, the request is sent to that route. If a relay route is not available, then the URI is resolved via DNS. ● If the Startline-URI resolves as a local address and port, the To URI is checked if it resolves to a local domain and port. If not, the request would be proxied using Relay Routes or via DNS resolution. The Request URI would be rewritten to point to the resolved route. ● INVITE: If both Request URI and To URI resolves to a local listener and port, the B2BUA Route is used to route the INVITE. ● REGISTER: If both Request URI and To URI resolves to a local listener and port, the local Registrar will process the registration. This would include Authorization of the user. B2BOnly Mode - This mode removes the relay capability but exposes the Registrar and the B2BUA functionalities. This mode does not do the checks performed by Full Mode. It will always process REGISTER and INVITE as local. ● INVITE: This mode always use B2BUA Route to route calls. If there is not corresponding route found, a DNS resolutions is done against the Request URI or the To URI in case the Request-URI resolves to a local address. ● REGISTER: Registrations are always handled by the local registrar. Proxy Only Mode - This mode removes the B2BUA functionality but exposes Registrar and the relay SIP Proxy functionalities ● Always uses Relay Routes for all messages including REGISTER. If a relay route is not configured, Requests will be relayed using DNS resolution. If a registrations is resolved as local, the registrar would handle the registration including authorization B2BUpperReg Mode - This is almost the same as the B2BOnly mode but with the additional capability of relaying registrations to upper registrars. ● INVITE: This mode always uses B2BUA Route. ● REGISTER: For registrations, it performs the Request URI and To URI checking and relay for a remote domain or process the registration locally for local domains. ● Upper-Registration: This mode also has the capability to hijack-registrations towards upstream registrars.
Per the above, I didn’t completely understand what I should use for normal IP phones operations, so, I guess I’m more or less on my own on this one. My general understanding says that I need to use the B2BupperReg mode, however, I can’t say I’m totally sure about it – I’ll be experimenting with OpenSBC and the virtual Asterisk servers i’ve written before over the couple of months.
|Print article||This entry was posted by on November 13, 2008 at 11:24 am, and is filed under Asterisk, GPL, SIP, community, open source, technnology. Follow any responses to this post through RSS 2.0. You can leave a response or trackback from your own site.|
No comments yet.
No trackbacks yet.
about 1 month ago - No comments
Since the inception of GreenfieldTech, back in 2007, we’ve assisted over 40 different VoIP companies to bootstrap their activities and launch their products. During that period, some of these companies had become a great success and some had disappeared from the face of the planet. This series of posts will bring the story of some of them – and we’ll try to analyze what made each company into a success or a failure.
about 2 months ago - No comments
Open Source – What really drives it? is the desire to change and create something new? is it a firm belief in the idea that knowledge wants to be free and that software should roam the world? or when you boil down – is it just plain Ego?
about 1 year ago - No comments
So, let’s talk PRI cards. Once every often a company approaches me to evaluate their products. I do my best to be as impartial as I can – after all, Digium products are my favorite. However, I’m always happy to see a product that can compete nicely with Digium, simply because I believe it will make Digium products better and stronger. So, a couple of months ago, Allo.com approached me to evaluate their PRI card. I agreed, and they’ve sent me their PCI-e version of a quad span E1/T1 card.
about 4 years ago - No comments
When most of us think about PBX systems, we usually associate these with cumbersome usage, confusing dialing codes and in most cases – a PBX system is automatically associated with the annoying task of transferring a call from one handset to another. Lately, I’ve been thinking deeply about how people use PBX systems, is this really the only way to use a PBX system? is there something else to the mix? can we really enrich one of the oldest operational paradigms in the world? – and for that matter, can the public be re-educated to assimilate a new breed of PBX systems or services?
about 4 years ago - No comments
Today I got the chance to speak at a Polycom half-day convention, mainly to speak about Asterisk and HDvoice. Now, putting aside the part about HDvoice (I’m getting a post about that on its own), I gotten to the point where I believe that I’m currently perceived as being an eccentric.
about 5 years ago - 3 comments
As a part of my job, I manage and maintain customer platform – usually operating in the Calling Cards and VoIP services market. Over the course of time, I’ve learned to rely on some providers in this world, knowing that they work 99.999% of the time. For example, i like working with DID numbers provided
about 5 years ago - 5 comments
One of the biggest questions in the world of Asterisk is: “How many concurrent channels can be sustained with an Asterisk server?” – while many had tried answering the question, the definitive answer still alludes us. Even the title of this post says “3500 concurrent channels with Asterisk” doesn’t really say much about what really
about 5 years ago - No comments
Lately I’ve come to the realization, that we are to blame for our own inability to promote Open Source and the adaptation of Open Source proficiency. Being an Open Source evangelist and consultant, this is very weird to be said by one like myself, however, this is my realization – and I will explain. In
about 6 years ago - No comments
To those of you familiar with the SIP signalling protocol or any other VoIP protocol for all that matter, you are most probably familiar with the issue of traversing DTMF (Dual Tone Multi Frequency) tones correctly over a VoIP link. The main issue is that there is no one standard for doing this. While in