Interoperability = nirvana in eyes of UC pros. But when we talk about interoperability, we usually refer to it in terms of how well (or poorly) different communications systems work with each other. What about the network infrastructure? Because let’s face it — you may be a big CallManager fan but your reseller gives you a great price on Juniper network switches.
In addition to the conversation about the convergence of voice and video in IP communications in today’s Q&A with the head of Cisco Systems’ telephony unit, Steve Slattery, I also asked what his team is doing to ensure that Cisco IP telephony gear operates as smoothly on a Juniper or HP network as it does on a Cisco one.
Check out Steve’s full answers below the jump, but here’s something to think about even if you go no further. Steve says Cisco voice products “never have any problem in working with other [vendors’] gear.” Well, let’s hear it, Cisco voice customers — how true is that? Are Cisco voice products painless to deploy on any network?
How much collaboration does your unit do with Cisco’s routing and switching team to ensure those products interoperate and perform well alongside Cisco’s voice infrastructure?
We take an architectural approach to the overall solution. In my portfolio are really applications that reside on the Cisco architectural platform — starting with the networking gear and some the networking services from Cisco, whether it’s policy or security or whatever. We actually have a very interesting approach looking at an architectural solution and then you have various business units that own elements of that solution. But the teams work very well together to make sure for the end customer that things come together and that there’s value to having Cisco on Cisco.
What about customers that have an HP or Juniper network? What’s done to ensure these products work just as well on those networks?
We take a very open standards approach when we build our products as well. Players like Juniper can bring elements of the solution, but they don’t have a complete solution so we make sure when we do our validation and testing that we work with the existing products that are in the market. But when we’re looking at a complete solution — when we look at it from an architecture perspective — we’re always looking for ways that we can really significantly improve the user experience or the possibility for the partner. When you bring so many different pieces to the table, it gives you unique opportunities to do things differently. But we never have any problem in working with other people’s gear.
What kinds of technical challenges do customers frequently run into when deploying Cisco’s IP voice and video telephony products?
I wouldn’t say frequently. I think we’ve gotten beyond a lot of the teething pains of voice over IP and built capabilities in the products that really simplify that. Historically, there have been issues around making sure the network is ready for video, and we’ve built capabilities within the products for the network not being properly configured and set up…. There really aren’t any significant technical issues anymore from voice over IP. I think as we move forward into video, we’ll probably go through a similar transition because video has different demands on the network, so we’re conscious of that and trying to be proactive to get ahead of that so we don’t go through the teething pains initial voice over IP deployments had.