This is the second of two blog postings on this topic. The first posting was on April 21^st and can be accessed by clicking HERE.

Once we make the determination that SCTP will be the foundation for building a Signaling Transport Network, many important issues must be addressed. SCTP is a connection oriented protocol with advanced features such as multi-homing and multi-streaming that can be leveraged to both enhance reliability and scalability.

However, it also makes the network design that much more complex. Therefore, it is essential that a common architecture strategy be defined for all types of signaling (SS7, BICC, SIP, LTE X2AP/S1AP, DIAMETER etc.). Instead of building islands of Signaling Transport infrastructure, it has to be built as a common resource that can serve as a shared transport for different types of controlling/signaling information. The connection oriented nature of SCTP imposes certain challenges with respect to network scalability. Having one or more SCTP hubs that centralize the SCTP connection to all the end nodes simplifies both interoperability between different network elements and enhances the network scalability. Higher layer session level routing (such as Global Title Translation, SIP Proxy Routing, ENUM resolution) could be added on top of the centralized SCTP layer, thus offloading many of these functions from the end nodes. The architecture is not voice-centric and can be reused for any non-VoIP services that use SIP-like signaling. The architecture also facilitates network monitoring by providing a centralized vantage point in the Signaling network. Architectural strategies such as path diversity are addressed once and reused for all types of signaling.

This approach has already been applied by many operators for both traditional TDM networks that use SS7 and VoIP networks using BICC. However, most initial SIP-based VoIP networks today use SIP over UDP (and sometimes TCP.) Is it time to make the transition to carry SIP over SCTP and have a common signaling transport strategy? If you agree that we should not build airplanes based on who travels in it, then you probably agree with this common signaling transport strategy too.

I look forward to hearing your comments.

This is the first of two blog postings on this topic. The second posting is planned for Tuesday, April 28th.

Most early VoIP networks that use SIP Signaling use UDP as the transport layer for carrying signaling and payload. The advantage of using UDP as a transport layer protocol is that it is simple, has low overhead and is omnipresent. The disadvantage of UDP is that it is not a guaranteed delivery protocol.

While UDP is good enough for carrying the payload such as voice, its suitability for carrying Control Information is debatable.  Message loss has very limited impact on the quality of voice (hardly noticeable), whereas signaling message loss could have a significant impact on the quality of session setup (post-dial delay, dropped sessions, session setup time etc.), network resource utilization, and charging functions.

Use of UDP can also be justifiable at the edge of the network (User to Network boundary), where the advantage of simplicity and scalability outweighs any reliability requirements. However, as SIP becomes a mainstream signaling control protocol within carrier core networks, using SIP over UDP is questionable. Looking at the past, when carriers migrated SS7 signaling from TDM to IP, experience clearly indicates that SS7 over UDP (or TCP) was not a feasible option. The industry standardized on SS7 over SCTP implementation, which was developed as part of SIGTRAN group of protocols. The same was also true with BICC networks as mobile carriers started deploying R4 Mobile Switching Servers. Looking into the future, LTE networks and the IMS architecture have standardized on SCTP as the standard transport layer protocol for signaling.

What are the challenges of building a large scale SIP-based signaling network using SCTP as the foundation? Is it scalable? Have standard bodies addressed all the architectural issues related to building a large scale SIP signaling network over SCTP? I will be talking more about this next week, and meanwhile I would like to know what you think about this?

On March 31, The New York Times Bits blog reported that 94% of all email is spam. This was based on statistics from Google’s Postini division. Turn that around, and it means only 6% of email is real, spam-free communication. There are few other media where we would accept that sort of signal to noise ratio. 

At the risk of stealing some thunder from Dorgham and Jiri’s recent posts on SPIT and VoIP identity, a statistic like that forces me to jump into the fray. Because I realize that if we keep doing things the same way, we may look forward to a future where 94% of your phone calls qualify as SPIT. 

In my opinion, there is one historical flaw in the email architecture that made Spam as we know it possible. That is, it had no end-to-end identity requirement. You could put anything you wanted in the From header of an email. Even if the submitting MTA authenticated the sender, there was no standard way for it to communicate the sender’s identity to the recipient. The effect is, you can’t really know who an email is from. There have been later attempts to improve this. DKIM, for example, may hold some promise. But it’s hard to retrofit an architectural change into a widely deployed protocol.

This resulted in an arms race between spammers and those trying to filter out the spam. There have been lots of filtering techniques over the years–content based filtering, statistical filtering, blackhole lists, greylisting, etc.

Most of the techniques works for a while, but the spammers always get wise to them. Spam filtering is very much hampered by the risk of false positives, where important non-spam gets tossed out like the proverbial baby in the bathwater. The only perfectly efficient spam filter is one that filters out all mail whatsoever.

You can tell how well filtering has worked by the headline of this article. It is becoming harder and harder to conduct business via email. Users are retreating into the walled gardens of social network services for most or all of their communications. 

So how would end-to-end identity help? It lets you build much smarter spam filtering policies. It’s not perfect, since some domains give out identities for free, in the form of free email addresses with no identification requirements. But there are others that don’t. If you can white list your friends and coworkers, and know for sure if a given piece of mail is from one of them, you can build much more aggressive spam filters for all the rest.

The IETF Real-Time Application area has historically had trouble moving forward with end-to-end identity features for SIP and related protocols. RFC4474 is promising, but facing some of the retrofitting-architectural-change problems I mentioned earlier. Part of the problem is that people have trouble agreeing on what problems they want to solve.

I hope we can all agree that this one needs solving. Fortunately, VoIP architectures are not nearly as entrenched as email architectures, so maybe it’s not too late to avoid a future of 6% SPIT free VoIP.

Most communication technologies follow a fairly predictable trend: first, forward-thinking researchers develop prototype of the technology. Then, pilot deployments demonstrate the viability of the technology. After the utility of the technology is proven, the protocols for multiple interoperable implementations are standardized. If the technology is successful, the early pilot deployments begin to gateway to each other (and a broader community) using the standardized protocols. Eventually, the proprietary islands disintegrate, leaving behind a fully standardized solution.

And that’s when the exciting stuff starts to happen.

One of the clearest examples of this is email – the earliest days of email began with dial-in bulletin board systems and isolated corporate email systems. The IETF standardized the Simple Mail Transfer Protocol (SMTP) in 1982; and, gradually, the proprietary systems gatewayed to the standardized protocols. Eventually, the islands faded away – today, just about all email in the world is exchanged using SMTP. Long gone are the days when you had to worry about having an account on the same email service to be able to communicate with your buddies; when someone says they have “email,” you assume that you can communicate with them using whatever email system(s) you happen to use.

We’ve seen similar migrations in the World Wide Web (distributed hypertext systems trace back to Douglas Engelbart’s work from 1968), with standardization coming about a decade later than email. And we’re in the same curve (albeit much earlier) for Presence and Instant Messaging (think ICQ, AOL, and Yahoo followed by XMPP and SIMPLE), and realtime Voice and Video over IP.

What’s exciting is how quickly we’re getting to the stages of gatewaying the proprietary islands to standardized protocols: last week, Skype announced its plans to gateway its own (very large) voice-over-IP island to the rest of the world.

However, unlike the other technologies I mention above, I have noticed a worrying trend in deployments of SIP to add proprietary extensions to the protocol – most often, in ways that interfere with proper interoperation with actual standard clients. The examples are manifold.

A major operating system vendor has incorporated what they claim to be “SIP” into a number of products, but uses a format for presence that is completely proprietary, and cannot interoperate with standard clients. These products also employ a proprietary federation mechanism that is fundamentally incompatible with the SIP inter-domain routing model.

Another major vendor who sells “SIP” PBXes abuses the SIP events mechanism quite egregiously by sending message waiting indications to every registered phone, regardless of whether those indications are supported by the device (and, conversely, sells phones that never subscribe to receive message waiting indicators).  The same vendor uses the same kind of unsolicited (and unauthenticated) notification to cause the phones to reboot – meaning one person with a 10-line perl script can knock an entire enterprise’s voice network over whenever they want to. And I have personally had to modify clients to deal with the fact that this vendor’s products send certain unwanted (and largely useless) types of media packets, even when the SIP negotiation has indicated they should not be sent.

The story repeats itself many times in the SIP world – current deployments have multiple, non-interoperable ways of sending DTMF (TouchTones^®) with SIP; bridged-line appearance; directed call pickup; and several other features.

Why, you may ask, is this any worse than the proprietary islands? Well, back when these vendors had their own proprietary systems, no one expected things to work together. You bought an entire system from a single vendor, and never expected things to work with other vendors’ equipment. But now, when vendors decide to implement non-standard protocols and call them “SIP,” they raise expectations that their equipment will work with systems from other vendors who also claim to implement “SIP.” And when things go off the rails, everyone starts getting the impression that “SIP doesn’t work.”

As someone who has spent well over a decade making sure that SIP does work, I find this very frustrating. Basically, you have vendors implementing proprietary protocols inspired, to varying degrees, by the SIP standard. And these implementations get labeled “SIP,” when they’re not. And we know they don’t work (or, even worse, sometimes work and sometimes don’t) with actual SIP devices.

My point is: standards are pretty much an all-or-nothing proposition. If you’re going to claim to follow a standard, you’ll do everyone a favor by following that standard. If you’re going to do something non-standard that is somehow based on SIP, then what you have is a proprietary protocol inspired by a standard. And that’s okay, as long as you don’t hold it out to be anything other than a proprietary protocol.