Talk has become so cheap that we don’t want to talk about cheap talk any more. Well, that was the idea of SIP, to truly move beyond voice, beyond network boundaries of the past and free us from the shackles of that dull, boring Voice. But that does not seem to be the case in the operator networks of today, at least for now. Every SIP conversation that I have had with operators, every real SIP deployment that I have come across in an operator network, I hear voices!!!

Voice-centric SBC’s that are grumbling because they cannot lift the heavy load of voices… unhappy softswitches confined to the voice core, MSC Servers trying to pick between BICC and SIP to carry voice signaling, confused IMS trying to figure out its raison d’être beyond voice…

The reason for SIP was never to replace something that is working fine, but it got trapped somewhere along the way to become voice focused. This is to be expected. Despite the continuing decline in the potential of voice revenue, it is still the cash king for the service provider. Operators (maybe with a few exceptions) will continue to invest in new technology such as SIP in their voice networks for a few more years.

But that is not my concern. In my view, what seems to be not right is that we are building these SIP networks with an architecture that is too voice-centric. The burden of voice may be too heavy to lift when it comes time to go beyond voice.

A few examples:

Deploying border devices that break the end-to-end transparency of a session (read Jiri Kuthan’s blog posting – “Back-to-Back User Agents (B2BUA) Considered Harmful for Service Providers“).

Network implementations that combine the media functions with Session Controllers in a single box. Many of the scalability issues we are seeing with SBC deployments are due to this fact.

Network implementations that combine the SIP UA functions (MSC Servers and Softswitches) and SIP Proxy/Routing functions (SIP Signaling Routers). These two functions not only scale differently, but also have different dependencies from a network evolution perspective. SIP UA have some media dependency (for example an MSC Server deals only with Voice and SMS) where as SIP Routing functions are independent of media and access. 

SIP is just a protocol, but its power comes from some underlying architectural principles that are more important than the bits and bytes of a protocol. Our near term goal may be to solve a Voice problem. But this should not dictate the future network architecture that will be the foundation for multi-media communication services. A few key principles to look for in a SIP network design:

• Avoid breaking end-to-end transparency at the service layer
• Decompose independent functional blocks that scale differently and have differentevolution profiles
• Reuse functional components (Horizontal model of IMS versus Silo model) for multiple media and service compositions

Have you come across problems in the network that resulted primarily because some core architecture principles were compromised? What were those core architecture principles? How could that have been avoided? I would like to hear from your experience.

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.

In last week’s post, Ben touched on some of the aspects of SIP network deployment that stifle innovation. I’d like to follow up by taking you behind the scenes and discussing a bit about what we do at the Internet Engineering Task Force (IETF) to help facilitate innovation.

Probably the most important work the IETF does to foster innovation lies not in what we choose to standardize, but in what we choose to leave unstandardized. With rare exception, the IETF does not standardize how to implement services in SIP. One of the key philosophies that has been central to the development of the SIP protocol is that the IETF defines a rich and powerful set of protocol tools, and allows application developers to implement services using these tools.

To illustrate the difference between tools and services, we’ll consider use cases that involve the interaction between three parties in a single call experience.

SIP includes a number of tools that allow for fairly powerful manipulation of call legs (including the REFER method, and the Join: and Replaces: header fields).  Depending on the desired use cases, user experience, and security properties, endpoints can use these tools in a wide variety of different ways to establish calls involving three parties.

Here is a very basic call-flow that has properties that are effectively identical to the PSTN named service known as “three-way calling”:

However, there are other message flows that would produce the same user experience, albeit with some different properties. For example, using a network-based server to provide media mixing can reduce the amount of voice traffic that is sent and received over Bob’s network connection, and reduce the CPU load on Bob’s phone. These properties may be desirable, for example, if Bob is on a wireless mobile device. Such a call flow may look something like this:

There are a large number of other call flows that can be used to achieve the exact same user experience, but with different technical properties.

What is key, however, is that Bob’s phone (as the initiator of the three-party call) can make the decision about which tools to employ, and how to employ them, unilaterally. This doesn’t require any support from Alice’s device or from Charlie’s device, other than use of the standardized call-leg manipulation tools. From the point of view of Alice and Charlie, the user experience is identical between the two call flows I discuss above. And that is exactly what the IETF hoped to achieve with its philosophy of standardizing protocol tools instead of named services. Only Bob’s device knows whether it is better off performing local mixing or farming mixing off to a network-based media server.

All of that said, the key motivator for defining tools instead of services in the SIP protocol is this: tools can be combined in unique and innovative ways to invent novel services that are limited only by the creativity of the companies producing products in this space. If the IETF were to standardize named services, then the abilities of SIP would be constrained to those named services and nothing else. It would be the end of innovation.