It seems to me that the notion of killer applications remains a remarkable confusion of senses in telecommunications — everyone has heard of it but few have seen it.

We have witnessed numerous laments about telcos becoming pipe providers and having no applications to offer. The role of infrastructure  and the companies operating it is in fact a complex subject. It is not unique to telecommunications — we find it for example in power distribution, gas distribution and other transportation systems as well. What seems unique to me in telecommunications is the obsession with a “killer application.” Have you even seen a gas or power company  trying to offer you such?

I actually consider representations of network infrastructure as “just pipes” to be a serious understatement. In fact, a study of financial data of providers offering both transport and applications shows that a vast majority of revenues is coming from transport. There is not a single application which gets to its user without network infrastructure. And ownership of this infrastructure is not easy to compete against as it is surrounded by substantial investment barriers.

In fact I see a very compelling value proposition  in companies that offer “just pipes.” Their attempts to add applications to their bundled service portfolio appear interesting too. What however appears unappealing to me is attempts to bind the pipes and applications technically together. Which is in my opinion the key design flaw with IMS.

I would like to add an IMS example which shows how misunderstanding of the value chain results in odd technology. There has been a tremendous effort to introduce facilitation of roaming charges, as we know it from 2G networks, to SIP infrastructure in 3G IMS networks. Is it however a compelling technology for increasing service provider’s revenues? I very much doubt that. The key, compelling, hard-to-get service is in this particular case – international mobile network access. If I travel abroad, I will pay roaming charges for international data access. At the same time I am technically free to use a SIP provider that does not introduce additional roaming charges for my phone calls. What remains is an odd investment in IMS roaming facilities for SIP telephony.

This example shows that IMS design is not really established upon a compelling value hierarchy, otherwise it could never be possible to bypass it so easily. In fact, I argue that the value SIP brings to telecommunications is not SIP itself (which IMS is focused on), but leveraging the Internet pipes underneath it. It is the Internet which breaks international and market segmentation barriers. It is a globalization technology in its truth sense.

The trends we have witnessed with our customers seem to confirm my observations. The leading scenario appears to be SIP trunking, which is aimed at leveraging a single infrastructure with global impact. IMS artifacts haven’t been witnessed in these deployments.

In conclusion, I consider the “pipe business” to be of tremendously compelling value. I see SIP telephony as a great application to leverage the full potential of the Internet global reach. At the same time, I consider IMS artifacts attempting to integrate those two too closely as contradictory to this purpose.

I look forward to hearing your views on this posting, whether supportive or not.

Standards like SIP define a set of rules for how elements behave, focusing on
how messages are constructed and sent, and how other elements react when they
are received. The specifications focus on describing behavior when the received
messages adhere to the protocol. While they can provide general guidance on
dealing with erroneous input, there are a large number of ways (frequently
unbounded) to say or do something wrong at any given protocol step. It would be
counterproductive, if not impossible, to call each of them out explicitly in
the specification.  

So, implementers have to choose what to do when the peer they are talking to
does something out of spec.  One approach would be to strictly reject any
inputs that contain such errors. While sometimes tempting, this approach
ultimately leads to systems that are easy to break and expensive to maintain.

Jon Postel captured a better approach in the RFC793 (the definition of TCP at
the time) : “TCP implementations will follow a general principle of robustness:
be conservative in what you do, be liberal in what you accept from others.”.
Adhering to this simple approach to achieving robustness differentiates systems
that thrive in real deployments from those that are quickly removed for causing
operational pain.

Let’s look at an example. Twice a year, we bring a large number of SIP
implementations together for a week long test event known as the SIPit.  We’ve
done 23 of these so far, and we’re still seeing new implementations at each
event. In the early days, new implementations tended to be overly strict in
enforcing grammar rules. One of the classic problems involved SIP’s Date header
field. One of these in a SIP message might look like this:

    Date: Sat, 13 Nov 2010 23:29:00 GMT

The specification defines the syntax of the header such that the timezone field
on that line can only contain “GMT”. Use of any other timezone string, even
“UTC”, is invalid according to the grammar rules. Some of these early
implementations would reject a SIP request (or even pretend they never saw it)
if the sender used UTC or some other timezone, even if they did NOTHING with
the value in the Date header field later in their processing. Calls failed
because of bits the recipient wasn’t going to use anyway. These implementers
quickly changed their code so that calls worked, but if they had taken Postel’s
maxim into account in the first place, they would have succeeded on their first
try.

I chose that example because its easy to see how Postel’s maxim applies without
diving too deep into the details of SIP. At recent SIPits, few implementations
have fallen into that well known trap. But many similar pitfalls exists (from
simple syntactic things like handling To-tags in registration and dealing with
spurious quotes in Digest authentication challenges, to semantic violations of
the extensibility mechanisms or the offer/answer exchange).  The
implementations that follow the approach of strictly adhering to the
specification in the messages they send, but ignoring other’s mistakes when
they don’t matter, interoperate with many more implementations than the ones
that take a brittle “protocol-police” path.  Being robust, they’re the ones
that work (and get to remain) in real deployments.

In future posts we’ll explore a bit more about how the approach of being
conservative in what you do, but liberal in what you accept from others can be
applied to applications in addition to protocols.

Welcome again to our new blog. We hope you’ve enjoyed this post and we look
forward to visiting with you going forward.

Welcome to SIP Sessions – a new blog dedicated to discussions around emerging
technologies and SIP – authored by folks who have been involved with SIP from
the beginning.

It’s been our experience that the most rapid technological advancements are
driven by frequent and wide collaboration, so we’ll be focusing our posts on
ideas and concepts central to new approaches to spark productive discussions.
Please jump in at any time and enjoy! We look forward to the conversations.