An early SIP pioneer, Johnston says the protocol still offers promise of multi-vendor interoperability as well as vendor innovation.

Alan Johnston is one of the SIP pioneers. He's an author of IETF RFC 3261, the core SIP standard, and he's written four books on SIP. He's currently with Avaya, where he serves as a Consulting Member of the Technical Staff. We wanted to do an update on where the SIP standard is at, in terms of interoperability and related key issues, so we turned to Dr. Johnston, who replied via email to my questions:

Does "SIP" have any meaning at all as a protocol IETF 3261, or is it only significant as another way of saying "IP communications", "session control," etc., in contrast to legacy TDM/call control?

SIP can be thought of as a "toolkit"--by deploying it, an enterprise or service provider can build all kinds of different services and features. RFC 3261 provides the foundation for the toolkit and is sufficient for many basic communication capabilities. However, the IETF continues to build upon this foundation with additional RFCs to expand the depth and breadth of capabilities that can be supported utilizing SIP.

What does "SIP Interoperability" mean, in a practical sense, to the enterprise? Does the term have any real-world meaning today? Can an enterprise successfully procure communications network components that deliver plug-and-play multivendor SIP interoperability?

SIP Interoperability enables an enterprise to deploy advanced communication and collaboration solutions without being locked into a single vendor solution. By embracing solutions based on open standards, an enterprise is able to take advantage of best in breed for both their enterprise equipment as well as their service provider connectivity. Further, a well-designed SIP solution allows for a migration of legacy systems into a SIP environment without requiring a complete rip and replace. Of course, most services require a number of SIP RFC standards to be used. The flexible, toolkit nature of SIP means that often there is more than one way to provide most SIP services--different sets of SIP standards can be used. Having a multivendor interoperable SIP feature or service not only means having all vendors conform to the RFCs, but also having all vendors implement a given feature in a compatible way.

The industry recognizes that standards alone are not sufficient to ensure interoperability and as such has come together to in venues such as the SIP Forum and the IMTC [International Multimedia Telecommunications Consortium] to create recommendations on how to do features and services using SIP, and to allow vendors to aggressively test feature and service interoperability.

Are there any efforts at plug-and-play SIP interoperability that are likely to actually bear fruit? If not, why not, and if so, what specifically is being worked on and what are the likely deliverables and timetable?

Yes, absolutely. Plug-and-play SIP interoperability is demonstrated at the protocol level many times each year at the SIPit SIP interoperability events that are run by the SIP Forum. Avaya has attended many of these events during which we have achieved plug-and-play interoperability in the first attempt with many new vendors and products at each event. However, just SIP interoperability is not enough--SIP feature interoperability is needed. There are some examples of increasing interoperability for particular SIP features and services. For example, there is a new effort being launched by the SIP Forum in 2012 which will be called SIPconnectIT. SIPconnectIT will be similar to SIPit but focused on SIP trunking interoperability between enterprise communication servers and Service Providers using the SIP Forum's SIPconnect SIP trunking recommendation. Given the explosive growth and excitement in the industry around SIP trunking, we expect these events to be well attended and increase plug-and-play interoperability around SIP trunking.

At what points in the network (endpoint to server, server to server, SBC to call controller, SBC to carrier network, etc.) is SIP relevant--and at each of these points, what "flavor" or type of SIP is relevant, or what portions of the standard are invoked?

There are not different flavors of SIP, though different RFCs may be applicable at different times and at different points in the network depending on what the solution is trying to accomplish. Different RFCs can be viewed a building blocks, each designed to do a specific task well. More importantly, these SIP RFCs are designed to be put together to enable more complex tasks to be accomplished. So a SIP solution starts with RFC 3261 as a foundation and then uses other SIP and other Internet standards to deliver the full capabilities.