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.
Among the various network segments described above, where should the enterprise prioritize SIP compliance?
There are two key areas that require attention, within the enterprise and between the enterprise and service provider. Within an enterprise the focus should be on creating a SIP core. This provides a foundation for deploying enhanced communication and collaboration applications, creates a focal point for transitioning other parts of an enterprise's communication infrastructure, and enables significant flexibility with respect to device type and how and where a user authenticates and connects to the network. The second area of focus should be between the enterprise and the service provider. Particularly with the deployment of a SIP core, there is often cost savings from consolidating SIP trunks to a service provider.
Would you describe SIP as a mature standard/set of standards? Are there any new developments coming within the IETF (or other entities) that will take SIP in a new direction or expand its functionality beyond the footprint of what it can now enable?
SIP is a mature set of standards. While there is still ongoing standardization work in the IETF, currently most of these efforts are adding minor functionality. For example, there is ongoing work proposed to add a Session ID to SIP to help in troubleshooting and logging. Given the overall stability of the standard and the broad adoption across the industry, this is an exciting time be creating rich collaboration and communication solutions. As these types of solutions are created, the open standards model of the IETF and the interoperability testing of the SIP Forum are there to address required enhancements to ensure on-going multi-vender interoperability. In addition, focus in the industry is on using and operating SIP networks. For example in 2011 the SIP Forum initiated the SIP Network Operator's Conference, known as SIPNOC. These ongoing conferences provide a forum for the industry to share and work together to make SIP easier to operate, manage, and interoperate.
How does SIP relate to middleware systems like Avaya ACE? By enabling, for example, Microsoft Lync endpoints to talk to Avaya Aura servers, is ACE replacing a need for Lync and Aura to "speak" SIP in identical ways? If so, does this suggest that true plug-and-play SIP interoperability isn't likely on a wide scale (i.e., that you'll always need a middleware platform like ACE)?
Middleware systems like ACE (and Avaya Enablement Server--AES--before it) are products to supplement communication control. They work with a variety of underlying telephony signaling technologies and are specifically positioned to make programming an application to consume or influence communications straightforward. They are not designed to replace or supplement SIP interoperability.
How receptive have the carriers been to the SIPForum's efforts with regard to SIPConnect and newer efforts? Last I heard, the major carriers hadn't signed on to SIPConnect 1.1.
SIPconnect has seen quite a lot of industry adoption, especially among the service providers who are rolling out SIP trunking the fastest. This includes smaller service providers, but also the Cable MSOs who have chosen SIPconnect as their standard way for offering SIP services to businesses and enterprises. Some of the larger service providers have been slow to adopt SIPconnect, but they are also slow to roll out SIP trunking in general for a variety of business reasons.
Some service providers are also making efforts to standardize on client access to rich communications services. Avaya is aware of a number of initiatives in motion and intends to participate by supporting rich interoperation with carrier systems supporting this client access approach. This will result in Avaya supporting even more diverse codecs and capability signaling mechanisms as well as evolved end to end security and encryption involving mobile clients.
Should enterprises even bother making plug-and-play SIP/SIP feature interoperability a priority? Or is it more efficient and cost-effective to go with either a single-vendor strategy or a middleware architecture?
SIP interoperability is key to allowing best of breed solutions. It took many years for vendors to be fully ISDN interoperable. Relatively speaking, it is still early in the SIP era, and we see continual evidence of improvement. Advocating interoperability is surely better than advocating for single vendor solutions.
