If the state of enterprise VoIP were a baseball game, what inning would we be in right now? I don't think I can...
trace that back to a baseball game, but initially, people were trying to figure out if enterprise VoIP was even possible. And we've really gone way beyond that. We're still in the early stages of the widespread rollout. Cisco alone has shipped more than four million business-class phones, and we've got another 400 million still to sell. The things that will be more interesting are the next generation of application platforms and the types of vertical collaboration things you'll see. So far you see some of that in the financial areas, but you don't see a lot of that across the industry as a whole. You're the author of a book about "practical" VoIP. Generally speaking, what would you say are the most impractical aspects of developing and implementing an enterprise VoIP system today? One issue that people run into a lot is that the people who do traditional telephony at a large enterprise are not the people who run the data networks. Bringing that together, that often turns out to be one of the difficulties. Those two groups need to become one group effectively working together. That's facilitated by education and learning how to put things in place together.
What's also important is being able to manage the whole system and understand why things work or don't work is also one of the hardest pieces of practical deployments.
It's the last thing that you have to get absolutely right. The tools to manage any system are always what come out later. With VoIP, the stuff in fairly simple implementations it's easy, but the more interesting aspects of VoIP involves connecting things in ways that weren't even necessarily considered by the people who built the equipment, like interoperability between different systems and ways of integrating vertical applications. When you start doing that with VoIP, you start having people using stuff in ways that were never imagined, and that's when it gets complicated. What are the most basic guidelines to help an enterprise know when and where open source might fit into a VoIP deployment?
The guidelines aren't so much about location -- it's not about whether you can use open source in a small branch office versus a main office. They're around the advantages. You can modify it in ways that you could never get somebody to do for you. If there's a specific application that a company wants to use to drive business forward, then open source can be a great tool. Our goal with VOCAL was to build a toolkit that people could use without a complete understanding of telephony.
On the flip side, if people want some company they can phone for support when something's wrong, and they don't need to customize things, then they're going to want to get something that's supported by a vendor. That doesn't mean there's no open source option -- Cisco is commercially shipping products that use open source components -- but it does mean there's a need to be a company behind them. Can you think of an example where open source can enable customization?
We've seen people do some very specific Web applications where clicking on a link would initiate an IP call across the network in a certain way. You can take some open source software and develop an application like that internally fairly easily. But it was an application so narrow that it would have been difficult to get any of the large vendors to decide to make a product around it. Does using open source code or tools make a VoIP system and more or less secure?
I think at some level, it's hard to answer that. There's a certain group of people who believe -- and not in terms of just VoIP -- that by preventing hackers from ever having access to the source, it's harder for them to find exploits in it. That has some truth to it. So I don't think anybody really knows. Some of the open source code was written just to scratch an itch, per se, and the security is awful. On the other hand, I think some of the open source code written with security in mind has some of the best security around anywhere.
We were working on how to come up with a very interoperable SIP stack that worked well and implemented advanced security features. The way we found it was easiest to solve those interoperability problems was to show the source code to our partners. So we put some effort into an open source SIP stack called reSIProcate with a bunch of advanced security features in it. Lately it's almost impossible to hear about VoIP without hearing SIP in the next breath. Is all the SIP hype justified, and why or why not?
Several years back we used to have debates at many industry conferences about whether H.323 or SIP would win out, and we don't have those debates anymore. It's pretty obvious that all of telephony is moving toward SIP as the underlying mechanism. Will it solve every last problem we've ever had? Of course not. The problems that are hard with every protocol are still hard with SIP, but it set up a lot of basic yet powerful constructs for dealing with a number of issues. It's going to advance significantly further than any other telephony protocols. You've said SIP-enabled presence systems are the "next big thing" in VoIP. Give me the business argument for why a company should spend part of its VoIP budget on enabling presence?
Presence is interesting because as we move to advanced forms of communications, we're trying to find ways to increase productivity -- to not have constant interruptions and know when and where you can find people. How do I make it so that some people can reach me, but if other people want to reach me they may not ring my phone, but they send me an IM that I can then respond to in 30 seconds instead of right away.
As for presence systems, there are several proprietary systems available today, but companies want to figure out how to securely share information in an interoperable way. There are a lot of companies using SIP and SIMPLE to do that. However, lots of vendors, including Cisco, will work to deliver [products using] whatever protocol customers want. One issue with SIP is the various vendor-specific dialects that companies build into their products to enhance functionality, hence limiting interoperability. Can this be addressed to enable broad-based application interoperability or is it already too late?
I don't think of it as being a major hindrance of SIP deployment, but there have been vendors that have implemented various extensions, and people who have had to implement drafts because the standards process is long and slow. I think that will continue for all time because there will always be people who want to do something that isn't addressed in a standardized way yet.
The best thing for customers in the long run is that they push their vendors so that the things that turn out to be useful get standardized, because that's how they're going to be able to get the full benefit of SIP.