One of the first articles posted to SIP Sessions discussed Postel’s Maxim, also known as the Robustness Principle:

Be conservative in what you do, be liberal in what you accept from others.

That article gave examples of how robustness declines when individual implementations don’t follow that principle. Today, I’d like to explore how the principle helps large systems and architectural design.

Imagine a system where all of the elements present are following this principle. Then introduce a single new element that doesn’t.

1. An element not following the first part of the principle will not be careful with what it emits. It might emit things that force edge conditions to occur, or even outright violate the protocols the system is using. The system as a whole will continue to behave robustly. Being liberal in what they receive, the remaining elements will forgive as much protocol violation as they can without emitting non-conformant messages themselves. They will have anticipated gracefully handling edge conditions. The system as a whole will not be significantly perturbed by the new element, and for the most part, the new element is likely to get whatever services it wanted.
2. An element not following the second part of the principle will be over-sensitive to variations in the messages from others. In the perfect system discussed so far, all the other elements are being careful to send conforming messages, so the new element’s brittleness won’t be exposed. The system continues to work robustly, at least until the rest of the system starts to evolve.

Now take the same system and introduce a very large number (enough to be a majority) of new elements that don’t follow this principle.

1. If the new elements are not conservative in what they emit, the entire system is placed under strain. The previous elements are now executing exception code as part of normal operation. Edge cases become the norm for them. The system no longer meets the expectations used to make optimization decisions in the original elements. In many cases, however, the system still won’t fail. But the robustness has been removed – used up. The next wave of non-conformance has a much higher chance of bringing the system down.
2. If the new elements are overly sensitive to what they receive, the strain is not (initially) so great. Because the original elements are conservative, this sensitivity isn’t exercised and the system will seem unperturbed. But then someone will have a bright idea and introduce a new, standard behavior into the system. These new elements, and remember they are the majority, will not accept this new behavior. A forklift upgrade of all of them will be required before a single new element trying to exercise this new behavior can be expected to work.

In short, a system that takes advantage of the robustness principle can survive even a large number of ill-behaved participants, but the cost is becoming brittle.

It’s easy to overlook this resulting brittleness when trying to solve any particular problem in isolation. It might be tempting to say – “Well, it’s ok if we violate this part of the specification, because this other part of the specification says conformant elements must not break if we behave this way.” This is a trap. It’s like saying “I can speed through every intersection, even if the lights are red, because the law says other drivers are required to make sure the intersection is safe to enter before doing so.” It’s even worse for a specification or an operational policy to encourage violating half of the robustness principle this way. That’s like having a driving school telling its students to run through all the red lights.

Hey, it would work if the rest of the system were perfect in executing the “make sure the intersection is safe” rule.

That’s where reality tears the notion down. The system I had you imagine at the beginning of the two exercises above cannot exist
in the real world. Real systems will have imperfections. Systems that use the robustness principle make it less likely that those imperfections will result in failure. Introducing elements that don’t follow the principle negates that robustness, and in real systems,  will cause those systems to fail.

This is my first in what will become regular contributions to the Tekelec SIP Blog.  In addition to covering SIP from a purely technical perspective, I will look at some of the traction and activities in the market.  This installment focuses on the adoption of IMS, and hence SIP, by mobile operators as the foundation for supporting voice and SMS in LTE environments.

IMS, like many new technologies, has gone through a tremendous “hype cycle”.  There has been the typical name bashing – with claims such as IMS means “I Must Sell” new technologies and the ups and downs of “everyone is moving to IMS” and then “no one is moving to IMS”. While initially developed by the mobile industry in 3GPP, it was widely adopted as a standard by the wireline and cable communities as well.  At this point in time the number of commercial deployments of IMS has been modest by any measure and my guess is that there are probably more commercial wireline deployments of IMS then there are commercial wireless deployments.  However, over the next few years that may all change.

On November 4th 2009, a relatively simple press release was made by a collection of mobile operators on the work that they had collaborated on to create an IMS profile that they named “One Voice”.  Simply put, this profile was created to help the industry secure a common standardized IMS voice (and SMS) solution. To do this, they defined a “profile” or specification that defines a common, recommended feature set from the 3GPP IMS specifications when multiple options exist for a single functionality.  The goal of One Voice was in essence to have a common IMS profile to support Voice and SMS in an LTE environment.

Since then there has been considerable collaboration between the GSMA and participating One Voice companies to enable the profile work to be handed over to the GSMA to take the lead moving forwards. On February 15, 2010, GSMA announced that it had chosen to adopt the One Voice initiative and has given it its full backing.  Having adopted the One Voice profile, the GSMA has opened the work to its entire membership (820+ operators and 220+ vendors) and will work with all interested companies to define protocols needed for LTE voice connectivity.  It will also work to define the interfaces and functional architecture required to enable international roaming and establish interconnection policies between mobile operators, using the One Voice profile as the basis of that work.  This will all result in the definition of end-to-end service principles for Voice over LTE.  The sum total of work will be completed under the name of Voice over LTE, or VoLTE.

This work will hopefully benefit the entire operator and vendor community and move towards broadening the deployment of SIP and IMS-based technologies. The worldwide penetration of mobile phones greatly exceeds that of wireline phones so the adoption of IMS in wireless networks will greatly expand the use of SIP. Of course, the work will take time and LTE will not be deployed over night, although there appears to be growing momentum for LTE in large part driven by the huge uptake in mobile data.

In the mean time, what do I expect to see?  Well, many operators today have deployed VoIP in their core network as part of their R4 soft switch deployments.  However, when the 3GPP R4 specifications were adopted they selected BICC – or Bearer Independent Call Control – as the signaling protocol because of the relative immaturity of SIP at the time.  Over the last 12-18 months we have begun to see some of the R4 soft switches (or MSS) in mobile networks evolve to support SIP in addition to BICC and of course SIP has become the “winner” for next generation signaling.  Recently we have also seen interest in BICC-to-SIP functionality to help mobile operators cost effectively transition to SIP and interwork with other SIP based networks (e.g., international transit networks) from their BICC-based mobile core. 

So will IMS happen in mobile networks as part of the deployment of LTE?  More than likely the answer is yes based on the current direction being pushed by the mobile operators behind the VoLTE initiative. Of course many other questions remain, including: over what time frame will this happen, what is the evolution path, and how long will hybrid 3G-4G networks exist and what challenges will these hybrid networks create for operators?  I will likely address these and other topics in future posts.

Vince Lesch

Tekelec CTO

It may be of interest to readers of this blog that recently a thought-provoking Internet Draft was published by Henry Sinnreich et al: SIP APIs for Communications on the Web – draft-sinnreich-sip-web-apis-00. In a nutshell, the Internet Draft exhibits critique of SIP and suggests a consequent usage of HTTP technology for VoIP used along with other Internet applications.

The question begs, whether the critique is justified and whether the shortcomings mentioned introduce sufficient pain to make one-self busy with abandoning SIP. I think the critique is largely fair; I’m less sure that there is a time window in which the level of pain can cause such a change.

The critique cites several reasons: standards’ complexity, insufficient consideration of NAT traversal and difficulties to link to web apps – to name the most significant ones. The complexity statement can be easily confirmed by looking at the VoIP RFC Watch site maintained by Nils Ohlmeier or by checking the SIP WG RFC dependency graph. And, NAT traversal has proven itself to be a large problem resulting in the formation of new network element type – the session border controller (SBC). Non-voice apps are indeed still letting us wait for them.

The real question to me is whether these difficulties will create enough motivation to change from SIP to Web technology. The window of opportunity seems closed: complexity can be somewhat lowered; like it or not, we have SBCs for NAT traversal; and web-apps can be built with or without SIP.

Still, isn’t the number of these workarounds a good enough reason to give the HTTP legacy a try? I have recently found out that remote sharing of “smart boards” (i.e. whiteboards with direct output to PCs) works over web port 80 via a third party to facilitate NAT and firewall traversal. Most video apps are using HTTP (even though typically one-way), and the number of emails exchanged via HTTP certainty creates a fair traffic share. To me it looks like we’re already giving HTTP a try…

My last post described how MSRP endpoints use SDP to setup sessions. Today, we’ll discuss how the MSRP protocol uses the results of the SDP offer/answer exchange.

Each endpoint builds a “target path” that it will use for all MSRP communication with its peer. If an endpoint does not use a relay, then the target path is exactly the same as the SDP path attribute value it received from its peer. On the other hand, if the endpoint does use a relay, then it forms the target path by prepending the URI that it got from each relay to the peer’s SDP path attribute value. In both cases, the target path form a roadmap of how to get an MSRP request to the peer, i.e. a list of MSRP URIs showing each hop to visit on the way, ending with the URI of the destination device.

If you recall from last time, Alice sent Bob an SDP offer containing the following:

a=path:msrps://alice.example.com:7654/asfd34;tcp

Bob responded with an SDP answer containing this:

a=path:msrps://relay.example.net:8211/asfioef;tcp msrps://bob.example.net:6581/asfd34;tcp

Since Alice didn’t introduce a relay (Bob’s relay doesn’t count here), she’s got life easy. Her target path is exactly what Bob sent her:

msrps://relay.example.net:8211/asfioef;tcp msrps://bob.example.net:6581/asfd34;tcp

msrps://relay.example.net:8211/asfioef;tcp  msrps://alice.example.com:7654/asfd34;tcp

Alice and Bob are now almost ready to exchange MSRP messages. But there’s one more step that must happen first. Alice must open a TCP connection towards Bob. Note that RFC 4975 says the offerer always opens the connection towards the answerer. There’s work afoot to allow MSRP endpoints to negotiate the connection direction using COMEDIA, but for now lets assume Alice and Bob are using RFC 49752 as-is.

Alice connects to the first device in her target path. In this case, that’s Bob’s relay. She uses the DNS to get an IP address for “relay.example.net” and opens a TCP connection to port 8211, and starts sending messages. That’s assuming she doesn’t already have such a connection–for example, she might already have an MSRP session in progress with someone else that uses the same relay as Bob. In that case, she just uses the connection she already has.

Now, lets pretend for just a moment that things were reversed, and Bob had sent the original offer. The first device in his target path is also “relay.example.net”. But since he already set up a connection to that relay when he authenticated with it, he doesn’t need to setup a new one. He just reuses the one he already has. The relay would establish a connection to the next hop (Alice, in this case) on demand.

When either endpoint wants to send a message to the other, it constructs a SEND request with the message content in its payload. The endpoint puts its target path in a To-Path header field, and its own URI in the From-Path header field. It then sends the request to the first device in the To-Path. If that device is the peer, then that’s pretty much all there is to it. If the first device is a relay, the relay removes its own URI from the To-Path and prepends it to the From-Path, then relays the request downstream.

Here’s a picture for Alice and Bob. I’ve replaced the actual URIs with the symbols “Alice”, “Bob”, and “Relay” to try to keep it readable.

At this point, you are probably (and rightly) wondering what the point of a relay moving its URI to the From-Path header field when it relays a request. This allows a downstream device to send a response to a SEND request, in the form of a REPORT request. Don’t confuse this with a message from the human Bob in response to a message from the human Alice. That would simply be another SEND request in the opposite direction. Instead REPORT requests carry delivery information about the original request.

The peer device, and any relays in between can originate a REPORT request back to the endpoint that sent a SEND request. They do this by inserting the From-Path that they observed in the Send request into the To-Path of the REPORT request. Here’s a picture showing a REPORT request sent by Bob, and another by Bob’s relay.

That’s enough for now. Next time, I’ll talk about how MSRP messages can be broken into “chunks” in order to multiplex multiple sessions across the same connection.