SIP Sessions

Back-to-Back User Agents (B2BUA) Considered Harmful for Service Providers

Technology-savvy observers have witnessed that two concepts for building SIP servers emerged over the past decades -- that of a proxy server as specified in RFC3261 and that of a so-called back-to-back user agent (B2BUA).

In this posting I'm building upon a recent discussion in the IETF standardization body, which reconfirmed to me that use of the B2BUAs has a vastly negative impact on service provider's competition capabilities.

Let's review those two elements before I proceed to conclusions. The key difference is that a proxy server is a passive element whereas a B2BUA is an active one. The proxy server, inspired in its concepts by IP routers, merely verifies SIP signaling messages and routes them to a proper destination, sometimes partially modifying those. This is the original notion of a SIP server as laid down in the SIP architecture specified in RFC 3261. The architecture has been primarily aiming Internet-grade scalability challenges.

On the contrary, a back-to-back user agent inserts itself actively in SIP calls. It splits a call in two legs and presents itself as callee to the caller and as caller to the callee. This behaviour allows the B2BUA to play a more active role in call processing as it can impersonate both SIP telephones involved in a phone conversation, and implement certain features on their behalf. B2BUAs are frequently located inside so called Session Border Controllers (SBCs).

There have been many educated conversations in the past trying to compare these two concepts to each other. Properties under debate included scalability, transparency, feature richness, level of call control, message integrity, and even more.

Let me however focus on two aspects I consider of utmost importance to service providers: time-to-market and operational expense. These characteristics are of business nature and thus may seem only indirectly related to the technical discussion. However, there are technical properties of B2BUAs that have very direct business impact.

The single greatest disadvantage of B2BUA is broken transparency. The B2BUAs split each call in two "half's". Each of the "half's" is technically speaking a call on its own in that elements of the messages are not guaranteed to be the same. This single design decision makes life very difficult. Obviously troubleshooting becomes difficult if a call is split in pieces that can't be easily associated with each other. A troubleshooter located in proximity of a caller sees messages which are dramatically different than those a troubleshooter located close to callee gets to see. It is thus rather difficult to correlate both half's, especially if there are additional errors under failure circumstances.

Since there is no specification for  a B2BUA, automated monitoring equipment can't reduce effort efficiently and complex troubleshooting is left to highly skilled human experts. I believe the direction of impact on customer care cost is rather obvious.

Transparency broken by B2BUA also impairs innovation. The B2BUA's active control of signaling requires understanding of SIP features that are to be communicated between call parties. That's different from proxy servers that transparently relay SIP messages from one party to another. The fundamental shortcoming of B2BUA is that it simply can never anticipate SIP features introduced by end-devices.

These are very valuable source of innovation and allow to increase value of service providers' offering  without touching critical infrastructure. Such features are then going to fail traversing the B2BUAs.

Now let's look how such a feature could look like on the example of identity. I've been personally concerned by lack of identity in the Internet generally and with SIP in particular. Lack of  verifiable and traceable identity makes email users and analogically SIP users as well too easily vulnerable to malicious communication using spoofed IDs. I also believe that for success of an identity system, it must have a good migration path. In other words, it must be incredibly simple to deploy and use. Here is an idea: could we use a trivial "Is it really you giving me this call" reverse query before we allow an incoming call to ring?

The answer is simple: yes you can if you do NOT use B2BUAs.

To reiterate my point: proxy servers by being passive allow the infrastructure to communicate new signaling features even if they specifically do not understand them.  To implement a reverse call verification, end-devices can simply exchange a query between themselves that refers to the call attempt. Callee's telephone asks the address claimed in call attempt "are you really calling me"? If both parties support this  feature, callee's phone can conclude that a call attempt is having genuine caller id. A SIP proxy server just mediates the reverse query like it does for any other SIP message.

In contract to that, a B2BUA will break such new application. Since it is based on an end-device-implemented feature, the B2BUA probably does not understand the reverse queries. Consequently, it is not able to translate the reference to the initial call in the reverse queries and the caller id verification will fail.

Architecturally seen, broken transparency has a huge price tag associated with it. B2BUAs increase operation cost by making troubleshooting complex and by prohibiting applications that can be deployed in an end-to-end manner without costly interaction with the network infrastructure. In conclusion, I recommend against using B2BUAs in service provider deployments that are concerned with customer care cost and capability to rapidly introduce new services.