What's the most interesting or exciting thing happening in the enterprise VoIP market right now, in your opinion?
For the first eight or nine years, we were working on building equipment that could reasonably replace stupid features in the PBX and reach a sort of parity where it could be deployed widely and nobody would complain when the PBX was turned off.
Now we're at the point where people are exploiting the technology to do things you couldn't do with a PBX. People aren't talking about how to make VoIP as good as a legacy PBX anymore; it's assumed that we're there or close to being there. Will there be a "killer app" or functionality that will drive awareness of those advanced capabilities?
I don't think it'll be a killer app so much as a systems attribute of being able to do mass customization. Like it or not, a PBX provides exactly the same set of services to everyone. But now we have the ability to mass-customize services based on job functions or preferences. An individual can customize the voice communications system -- setting up call coverage, dealing with voice mail -- to their own needs. You could never afford to have a PBX with one set of applications for engineers and another set for executives. Now, with this type of system, you can afford to deploy features and services for small groups or individuals.
Requires Free Membership to View
You've been vocal about the complexities involved with developing Session Initiation Protocol -compliant VoIP equipment that is not only secure, but also functions with the QoS that corporate users expect. Can you elaborate on those complexities, and on Cisco's efforts to provide end-to-end SIP support? First let me say I think the situation has improved drastically in the last year, for a couple of reasons. One is the big [vendors] have gotten their acts together with SIP products, notably Cisco, Avaya and friends. Cisco will be coming out with a fully SIP-enabled version of CallManager in the near future.
SIP has a different architecture than some legacy protocols. Basically, some legacy PBX features are harder to develop with SIP. Now we're getting over that hump. The people who have developed SIP products have that experience under their belts, and the strengths can now be exploited to do some very sophisticated stuff. In terms of security, we're quite a bit further along than we were. The ITF standards in these areas have been pretty well solidified with just one or two holes remaining, so industry agreement has increased dramatically as well. What more can you tell me about the upcoming CallManager release?
It's been deployed internally. It allows you to connect Cisco phones or other SIP-based phones to CallManager, and get the full functionality of CallManager using SIP. Think of it like a brain transplant. For someone who has an existing CallManager phone system, we can slide SIP underneath and they won't be able to tell the difference. Will the evolution of the core SIP primitives ever reach a point where SIP-compliant gear from multiple vendors will offer data transfer interoperability without needing vendor customization?
In terms of interoperability for all the basic stuff -- making a call, receiving a call, transferring a call, putting someone on and off hold -- I think we're there. I think enterprises want two things beyond that -- one we can give them, and another we can't or probably won't.
One is the guarantee that something won't get screwed up if you mix and match equipment from different vendors. I don't think we're quite there yet, but the SIP Forum is working on an effort to group phone functions into various classes. That will allow vendors to group functions into various classes and express what a product does based on a narrower set of categories, instead of listing 100 different features. That will be helpful to customers, but it'll be six or eight months before that's available to the industry.
The other thing is they want some kind of stamp or certification that guarantees interoperability according to a set of specifications governed by some authority. I don't think that will happen because, in a sense, interoperability is at odds with certification. Nobody goes to the suppliers of their IP stacks or Ethernet controllers asking for certification, and the reason is stuff just interoperates. The SIP community in general has resisted certification. Certification doesn't always promote interoperability in the broad sense, though it may in a narrow sense for the big vendors who can pay $20,000 or $30,000 per product to get a certification. So avoiding certifications in the VoIP industry is about keeping costs down and promoting competition?
If you're a big guy you can amortize certification costs over millions of units, and it's not a big deal. It's quite different if you're trying to sell 10,000 units at small price points. And it isn't just for costs, it's reducing barrier for entry, making the whole ecosystem more competitive so it will evolve faster. On the other side, though, doesn't that make it more difficult for enterprises to choose products in the short term?
 |
||||
|
|
|||
|
||||
This is a somewhat radical view. Security experts would probably not subscribe to this view, and in a way my view is meant to be thought-provoking rather than convince people that this is the right way to look at the world.
The approach of the security world is to decide to either allow or disallow packets from a certain source on the network. That's where I think they've gone off the rails in the sense that if you take that approach, you only have one large hammer to use against someone -- you have to drop their packets or allow them. I'm saying there's a large middle ground. To that end, should organizations rethink certain security paradigms?
Again, my colleagues in the security group would probably disagree, but the security issue is not so much whether you allow someone on the network, but what you allow them to do, based on your assessment of who they are and what threats your network is being exposed to. For example, if I decide that a voice user on my network is a 'bad guy' because his password has expired or his certificate looks quirky, can that person still pick up the phone and dial 911 if the building is burning down? On the other hand, you have to be careful that unauthorized users can't mount a denial-of-service attack against the emergency service itself. The only way I know how to do that is using QoS machinery; I can't do that with pure security machinery.