The Great Thing About Standards
By Jonathan Rosenberg, SIP Specific - Speaking SIP
Everyone who has worked in the telecom industry has heard the quip: "The great thing about standards is that there are so many to choose from!" While it is funny, it points to a real problem in our industry. The problem, of course, is the frequent lack of interoperability between vendors or between networks, despite the plethora of standards. Why is that? Why are we doing all of this work in standards if it's not resulting in interoperability?
The answer is not a simple one. Interoperability suffers for many reasons. First and foremost, vendors implement, and network designers deploy, only parts of a standard. This is not due to stupidity or malice, but rather engineering reality. Standards, by their nature, must be designed to meet a superset of the requirements of the players that come to the table to craft that standard. As a consequence, any particular standard ends up being much more complex than any one vendor needs for any one customer or any one product release. Since engineering resources are always limited, a subset gets implemented to meet the requirements immediately in front of each team. If two vendors implement different subsets, there is a good chance they won't interoperate.
A related problem is that vendors often have to meet requirements that the standards don't address. If you consider the breadth of network providers, market segments and services available today, this should be no surprise. It is one reason that standards bodies sometimes grow around segments of the market - ones for cable providers, for European cellular providers, for landline providers, and so on.
However, sometimes the problem is that there are just too many ways of doing something. SIP has received a great deal of success in the marketplace because of its flexibility. However, that strength comes with a penalty - it tends to complicate interoperability.
As an example, take something as seemingly mundane as a call transfer. SIP has several ways in which a transfer feature can be implemented. One way is to use the REFER method. Transferors can send a REFER to the transfer target, or they can send a REFER to the transferee. It is also possible to accomplish a transfer using third-party call control techniques. What happens, however, when one phone in a system does a transfer using one technique, but a different phone has been developed using a different technique?
If both phones are fully compliant to the SIP specification and to the REFER specification, the transfer will work. That's the beauty of SIP - one side of a call can do a feature one particular way, and the other side doesn't have to even understand it in order for the feature to interoperate. That is one of the key ideas behind the SIP vision for how to provide innovation: by standardizing a set of tools that can provide key primitives, and then allowing implementers to build more complex features around those primitives while maintaining interoperability.
But most phones aren't necessarily fully compliant to the SIP or REFER specifications. A vendor interested in transfer probably picked a technique, implemented that, and ignored those parts of the specification that would be used by someone implementing transfer in a different way. Similarly, a vendor implementing transfer using thirdparty call control may have omitted REFER support entirely. In those cases, there isn't going to be interoperability.
What is needed to fix this problem? A standards organization needs to look at the various ways any particular feature can be implemented, and for each one, must define a minimum set of functionality that everyone has to support. This minimum set of functionality would be in the form of specifications or portions of a specification that need to be implemented. That minimum set is chosen so that vendors can implement the feature in a few different ways, yet still ensure interoperability overall.
This may sound like a simple process, but it is not. The challenge is in balancing the needs of interoperability with a desire for innovation. Without a doubt, the way to maximize interoperability would be to explicitly enumerate all of the features that are supported. Then, for each one, a series of call flows and functional behaviors would be defined. In this way, it would be very clear to vendors of equipment exactly what they need to do to support each and every feature. Interoperability would be great! There would be no ambiguity in how the feature works, no way two vendors could make differing assumptions on the flows to use, and no confusion on what the role of each box was for each feature.
Of course, this interoperability would come at high cost. The only features that would work in such a system are those explicitly enumerated features. Indeed, even for those features, they would work only as described in the standard. Variations and tweaks would not be supported. This defeats the entire purpose of choosing SIP, though! If all a network designer wants is the existing set of telephony features, there are already plenty of existing technologies that do that quite adequately. The promise of SIP are the new features it can bring to the table. Not just presence and IM, but improvements upon even the most common of features.
Fortunately, to achieve interoperability, it is not necessary to specify every detail of how a feature works. For example, consider Do Not Disturb (DND). In this familiar feature, an endpoint signals to its server that it would like incoming calls to be diverted in some way, so that the phone does not ring. In order for this feature to interoperate between the phone and the server, there needs to be a standard way to signal activation and deactivation of DND. However, once activated, it doesn't really matter whether the server sends the call to voicemail, rejects it, plays a multimedia file, or redirects the caller to a web page. The trick, therefore, is to specify only this tiny bit of the feature - how activation status is signaled to the server - without constraining how the feature works.
Recently, a new working group has been proposed in the Internet Engineering Task Force (IETF) to do exactly this. This new group is called BLISS - Basic Level of Interoperability for SIP Services. If all goes well, BLISS will be approved and on its way to solving this problem by the time you read this article. BLISS will be looking at groups of related features, and for each one, look at the call flows utilized for those features, determine where things fail, and then define a minimum interoperability recommendation for that group of related features. Its charter covers features such as shared line, call park, do-not-disturb, and call completion to busy subscriber.
Once BLISS is done, we'll have even more standards to add to an already long list of standards to choose from. This time, however, it really will be a great thing.
Jonathan Rosenberg is the co-author of SIP and SIMPLE. He is currently a Cisco Fellow and architect for the IP Communications Business Unit in the Voice Technology Group at Cisco (www.cisco.com).
