Clearspace Server Syndication Feed

On Route Failover, Forking and SLA

joegen — Fri, 05 Sep 2008 05:06:45 GMT

Thanks to private funding from a customer, I recently found time to introduce ICT forking and SLA in OpenSBC. Forking is the term used in RFC 3261 to allow SIP Servers to literally clone INVITE transactions and send them to multiple destinations, thus, giving the ability of a single call to ring on multiple destinations. Up until recently, OpenSBC only supports serial route failover. This, technically, is not real forking for OpenSBC will create separate dialogs for each failover attempt. Solegy has been using this failover machanism for years to ensure higher call completion rate in exchange for a bit longer post dial delay or PDD. OpenSBC forking mechanism, on the other hand, is done in parallel instead of serial attempts. To the SIP grammatist, forking can be either serial or parallel. To clarify the semantics however, we call serial forking as route-failover and shared line appearance SLA for parallel forking.

How does it work?

There are two ways in which forking can be achieved in OpenSBC. The first is by providing static routing rules in the B2BUA-Route section of OpenSBC.

Via B2BUA-Route

sip:alice* sip:ua1.atlanta.com, sip:ua2.atlanta.com, sip:ua3.atlanta.com
In the routing rule above, the wild card sip:alice* which essentially means "Any request URI that starts with 'sip:alice' followed by any number of characters" will be serially routed to the three destinations sip:ua1.atlanta.com, sip:ua2.atlanta.com, sip:ua3.atlanta.com. This type of routing is called route-failover.
Recent improvements to OpenSBC added the capability to try all three routes simultaneously instead of serially. This is shared line appearance or SLA. This is achieved by providing a parameter "fork=true" to the routing rule wild card.

fork=true sip:ua1.atlanta.com, sip:ua2.atlanta.com, sip:ua3.atlanta.com

Via REGISTER

Aside from routing rules as described above, OpenSBC now makes it seamless for multiple Address Of Records or AOR to be be registered while each record points to a different distinct binding. Do not be overwhelemed by the terms. AOR is the To-URI and the Binding is the Contact-URI in the REGISTER request. The static route above can be duplicated by sending registrations as follows

REGISTER sip:osbc.atlanta.com SIP/2.0 /CRLF To: sip:alice@atlanta.com /CRLF Contact: sip:ua1.atlanta.com

REGISTER sip:osbc.atlanta.com SIP/2.0 /CRLF To: sip:alice@atlanta.com /CRLF Contact: sip:ua2.atlanta.com

REGISTER sip:osbc.atlanta.com SIP/2.0 /CRLF To: sip:alice@atlanta.com /CRLF Contact: sip:ua3.atlanta.com

If you will notice, the three REGISTER requests above share a common To-URI sip:alice@atlanta.com while all three differ in the Contact-URI. The previous behavior of OpenSBC, is to just preserve the last registration attempt for an AOR. This overwrites the old record which makes it impossible to support forking via registration in the past. Recent modification, (in fact I rewrote the registrar code), in OpenSBC now allows this scenario making it possible to do forking via registrations.

There is no special configuration required in OpenSBC for it to attempt a fork for SLA registrations. If OpenSBC detects multiple binding, it will automatically fork the calls. As of this moment, only parallel forking is supported for registration. Serial forking support is planned in the future.

Does SLA work for Upper-Registration too?

Yes but with a caveat. OpenSBC has support for upper registration. This is the term we coined to represent the ability of OpenSBC to hijack registration bindings before it relays the registration to the actual registrar. This allows OpenSBC to always stay in the middle of registered UA and the SIP Server that needs far-end NAT traversal for RTP.

The current implementation of Upper-Registration now also allows the registrar to fork calls. To achieve this, OpenSBC not only hijacks the registration by setting the contact address, it also now preserves the original binding as an escaped parameter of the Contact-URI sent to the upper registrar. If an upper registrar decides to fork a call to an SLA account, OpenSBC would be able to identify the carrect binding to be used for each forked transactions.

It is worth noting, however, that OpenSBC only has partial support for Merged Requests" Merge Request is the term used for the situation whereby INVITEs that are forked arrives at the same server. Since OpenSBC is a B2BUA rather than a SIP Proxy, it can only reserve one RTP session for each call. This results to an undesirable complication in upper registrar forking where only the first INVITE received by OpenSBC gets a B2BUA session. The rest of the merge requests are simply relayed by OpenSBC. Yes, the serial fork would still ring the multiple devices but only the first INVITE will have the ability to anchor media. This is a deal breaker if the mutiple devices are behind a NAT. As of this moment, at least until a solution is found to this problem, I do not recommend upper registrar to fork calls towards OpenSBC.

Bottom line, it's a happy week for me. Thanks to the generosity of sponsors, we continously advance OpenSBC as a free alternative to commercial border controllers.

grnVoIP Implements OpenSBC for Prepaid Wholesale Business

ehernaez — Fri, 05 Sep 2008 05:05:34 GMT

We are happy to announce that our friends at grnVoIP have replaced their SIP session border controllers with the OpenSBC open session border controller. grnVoIP has supported the OpenSourceSIP intitiative since it's inception, and we are pleased that they are able to reap tangible benefits from their investment. The move puts the equivalent of $7 Million in prepaid wholesale termination traffic onto the OSBC platform and demonstrates the continuing success that companies find using open source software.

FMC with OpenSBC

ehernaez — Wed, 07 Nov 2007 04:11:54 GMT

There is a lot of hype about fixed mobile convergence (FMC ). Almost every vendor that touts a solution in this area uses the example of seamlessly transfering a call from their mobile phone to a SIP phone when the user enters a WiFi zone. It makes for a great talking point. Who among us hasn't walked into their office from the parking lot and asked to call or be called back on a landline?

In fact, it's very hard to devise a real FMC service if you are not a mobile network operator. Doing so requires one to route the mobile leg of a call through a SIP proxy (either by forwarding your mobile phone number to a SIP DID, or by forwarding a SIP DID to your mobile phone) in order to control the signalling on the mobile leg. It's messy because it requires the mobile call to be converted and then reconverted between TDM, VoIP and GSM protocols.

That said, I am happy to report that the OpenSBC team has recently added support for FMC scenarios. It works like this:

1. Caller A dials a number that is forwarded to User B's mobile phone through a SIP PSTN gateway, and User B answers;

2. While the mobile call is in session, a SIP endpoint with the same user address as the mobile phone registers to OSBC;

3. OSBC recognizes that the new registration is a match for the ongoing session, and sends an INVITE to the newly registered endpoint;

4. When the endpoint OKs the INVITE, OSBC sends a re-INVITE to the SIP PSTN gateway containing the endpoints comtact information.

I was excited to test this scenario recently using a my Cingular mobile phone and a UTStarcom WiFi phone. As soon as the WiFi phone registered to OSBC, the mobile call was placed on hold, and the WiFi phone started ringing. Boy was I enthralled. As long as I have been in this business, it still amazes and delights me to see this stuff work. Sad... I know.

I encourage anyone else that is interested in recreating this test to give it a try. Please post your results, good or bad, to the forum.

_________________________

NOTE: The only carrier (so far) to deploy a public FMC service - T-Mobile's @Home - has received less than stellar feedback from users. Some of the complaints concern the less-than-smooth hand-off between the GSM and WiFi networks, and the tendency for the UMA handset to try to lock-in to a competing WiFi signal while a call is in session.