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[18900]: 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:
<strong>Full Mode</strong> - 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. <strong>B2BOnly Mode</strong> - 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. <strong> Proxy Only Mode</strong> - 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 <strong>B2BUpperReg Mode</strong> - 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.