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?
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 at atlanta dot com /CRLF Contact: sip:ua1.atlanta.com
REGISTER sip:osbc.atlanta.com SIP/2.0 /CRLF To: sip:alice at atlanta dot com /CRLF Contact: sip:ua2.atlanta.com
REGISTER sip:osbc.atlanta.com SIP/2.0 /CRLF To: sip:alice at atlanta dot com /CRLF Contact: sip:ua3.atlanta.com
If you will notice, the three REGISTER requests above share a common To-URI sip:alice at atlanta dot 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.