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:

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.