Cisco’s Take on Open (Cisco) Standards

Recently Stacy Melillo Spognardi from Cisco blogged about using standards based implementation to lower cost of UC. I love seeing Cisco blog posts that take a stab at the industry. Partly because no matter how informed they seem to be on the industry they ignore their own heritage and the capabilities of their competitors. I guess you can call it a case of selective memory. The same thing your other half accuses you of when for not remembering to pick up some milk on the way home but you can replay the entire Muppets Manamana song in your mind as if you were listening to it. Your humming it right now aren’t you? But still can’t remember that milk.

Let’s take a look at Stacie’s blog and with a broader sense of where we are as an industry and with Cisco’s history of standards in mind.

“One thing that stays constant in this industry is change, especially when it comes to devices. Let’s take a walk down memory lane and see if you can remember any of these once “have to have” mobile devices. The Nokia 9000, The Motorola “Flip phone” and The “Razor”, Palm Pilot, dare I say the Blackberry and of course at the start of 2007 the IPhone came on to the market — and we all know how that is playing out — this being a rarity. More recently, Samsung is challenging Apple with the Galaxy and DROID OS is becoming more prevalent than IOS. Last I checked, there was an estimated 1.3 million Android activations per day. Android is now the #1 mobile OS.”

I personally don’t think it really matters who is the leading smart phone manufacture to a UC provider? There is an expectation from companies that all major mobile OS’s are supported and this does include Windows Phone. The fact that Cisco doesn’t support WP shows that the Post PC marketing message is more important than reality of expectations around the enterprise space limiting a users choice of handset.

“The examples I have shown are mobile devices, but I could argue the same point for any endpoint like tablets, personal video endpoints, IP Phones etc. The point I am making is that over time devices come in and out of favor (some last longer than others) and employees’ preferences change very rapidly as new products promise novel and exciting features and functionality. IT Managers need to be able to adapt to these changes in preference, but also minimize any negative impact they may have on their networks and costs. The bottom line is people want to collaborate with each other using whatever device they choose and frequently the first adopters of new devices are those in the executive suite. Given these influencers are also those that approve IT budgets, it seems prudent to be open to their needs.”

To me this message seems confused. I thought the value of a platform was to be open to the needs of the organization, not just to the needs of employees or executives so they approve budgeting to a project. Helping companies drive new revenue streams and lower costs seem to spring to mind but that doesn’t seem to rate a mention. This sounds like something a sales person would say and not a trusted advisor to the organization. At the end of the day platform choice and deployment varies widely between companies and where they are in their technology lifecycles. Believe it or not, there are companies that want to have a say in what they deploy and support and not just give into consumerization wholly and solely. A trusted adviser needs to be able to be flexible in their approach adjusting to the needs of an organization and not just sell a marketing message to executives.

“IT managers need to weigh heavily the impact of standards when choosing a collaboration partner and strategy and they need to be mindful of the impact that multiple devices on that decision. Some questions to consider are: How will non-standard based end points communicate with each other? What will happen as new devices du jour enter the workplace? Will I be able to support them with minimal effort? What added infrastructure needs to exist to make this happen? Will new code have to be written to enable third party devices to work together and function as intended with a great user experience?”

Considering Cisco’s own history in this space this statement makes a strong case against Cisco’s own technology investments. Namely the use of Cisco Discovery Protocol (CDP) and Skinny Call Control Protocol (SCCP) which most Cisco voice networks still heavily depend on. I could name a dozen large Cisco VoIP networks that rely on CDP for voice VLAN discovery and most likely establishing port trust for QoS. By default Cisco phones and networks run CDP and depending on what IOS and phone firmware LLDP as well. Over time Cisco are slowly moving more to standards based protocols but most deployments still rely heavily on their proprietary protocols. Overall this has helped to ensure customers have a hard time converting to more standards based deployments and securing Cisco’s voice and network deployments. So is the message to dump Cisco’s voice networks that rely on this technology or spend money upgrading their propriety technology to more standards based versions? I am not sure. Just a hunch, I bet it’s the latter.

“Let’s say that I am the IT manager for a medium sized business that is in the process of expanding all over the world. Some of the global offices are in locations that have limited bandwidth availability and I’m looking into a VoIP deployment but would also like to have IM, presence, and web and video conferencing capabilities. I am considering vendors that offer both proprietary as well as standard-based CODECs.

During my research phase I made some discoveries. In my case, I will have some locations that will be operating on very minimal bandwidth. With Audio CODECs such as G.729, a standards-based low bandwidth audio CODEC, you know what your payload size will be and you have a high likelihood of being interoperable at the CODEC level with other devices. Your network will be very predictable. In some cases, there are CODECS which are tuned for the internet and are “flexible”, using more bandwidth to compensate for lost packets, as well as increasing bandwidth to try to improve quality. These CODECS, while great on the Internet, are not predictable and often use much more bandwidth than is expected as a result of their “flexibility”. Codecs which are both flexible and proprietary not only are unpredictable but do not “play well with others”.”

Interesting. G.729 maybe a standard but it is not free and has to be licensed which means it’s proprietary even though widely used (Sipro Lab Telecom is the authorized Intellectual Property Licensing Administrator for G.729 technology and patent pool). It also suffers from poor quality when there is minimal packet lose over uncontrolled networks so you better make sure you spend a lot of time and money on your network to make sure it’s predictable. Now I am not going to disagree that having a predictable architecture for quality control over your network isn’t desirable but codec alone won’t get you there especially one that was designed for TDM networks. The suggestion that organizations should just disregard the trend of people working from home (which I am doing right now) for the sake of using standards is a weak concept. How about using a platform that meets the needs of an organization whether in the office or remote. Now that’s a concept.

“Add video and sharing capabilities to the mix and the bandwidth requirements become even greater. As an example, in some cases a desktop share between two people swells from 300k to over 1.5M per person when a third person is added — with no ability to limit or control bandwidth usage. This will result in a sub-par experience including but not limited to dropped calls, latency, and jitter and adverse effects on other flows and applications. How do I fix such a problem? I will need to increase bandwidth. In some locations this isn’t even an option. And as much as bandwidth costs are going down, it is still a formidable cost especially in remote areas of the world.

Looking at the Video CODEC part of the equation, standards-based CODECs like H.265 are much more bandwidth efficient than other proprietary video CODECs. In fact, H265 can save up to ½ of my bandwidth. When I choose to adopt standards based codecs, I also vastly improve my interoperability with existing video units and reduce hair-pinning through transcoders, which costs even more bandwidth.”

H.265, I am not even sure where to begin. It is possible that H.265 could be a great future solution but right now it buys you nothing. Considering that the industry in general is moving more towards H.264 SVC and AVC as standard implementation codecs Cisco’s push of a draft codec is premature. It is more indicative of Cisco trying to create exclusive Cisco only video network making it harder for customer to leave for another vendor if they choose. At the end of the day does it matter if it’s a standard if no one else uses it? Nope. While other video vendors are at least trying to come to terms on a standard implementation of a video codec Cisco is heading off in a direction of its own. I have yet to see other companies committing to the same Cisco flavor of H.265. Is this just a Cisco problem? Nope, it’s actually an industry problem that forums like the UCIF are trying hard to solve but it seems Cisco is just happy to tout how it uses standards.

“Remember, in this example we are focused on a medium sized organization. If I were to expand this example to an enterprise environment using a proprietary solution — the network can be crippled and the bandwidth cost would be MUCH greater. Why would I spend my IT budget on more bandwidth if it can be avoided with a standards-based solution that offers a better experience?

So, what about SIP? Using a proprietary secure SIP implementation for call control is recommended by some vendors as a security measure by encrypting the SIP call control traffic. But, it also has limitations by preventing intelligence in the network that helps route traffic more efficiently. Using other security methods in my network like tunneling, VLANs or VPNs still ensures network protection, but does so without encrypting the SIP call control traffic. These methods enable the network to see the SIP call control traffic and allow many enhancements to call flow resulting in a potential reduction in bandwidth and cost savings by re-routing traffic. It also allows me to integrate disparate call control platforms, since most call control systems that implement security use completely different key exchange mechanisms, rendering them non-interoperable.”

The suggestion that secure encrypted signaling (standards based encryption was never mentioned, so I can only assume all encrypted signaling is bad) is less desirable than VPNs and tunneling certainly pushes at the notion that Cisco are trying place network integration higher in the priority list over security. The fact most modern UC systems can turn off encryption to allow SIP interoperability if encryption methods differs even if only over a trunk seems over looked. The answer is leave it all unencrypted and let the network do that. Seems like a great solution for Cisco, not so great if you a customer concerned about security. The fact that VLAN’s and security are even mentioned together in the same sentence kind of makes me shutter a little. In the end it may be a combination of methods that leads to the ideal solution but suggesting that security is sacrificed for network routing is self-serving to say the least. Meanwhile Cisco’s Wi-Fi competitor Aruba seem to be able to identify network traffic while it’s still encrypted. Wait a minute, didn’t Cisco say that wasn’t possible?

“Beyond bandwidth concerns, proprietary solutions cannot communicate with standards-based solutions. In order for this to happen I would need to purchase a number of gateways to facilitate the transcoding or signaling translation. This poses two major problems. First, it introduces a much greater level of complexity as you deploy gateways your network. Second, it adds additional capex to my reduced budget in this current economic environment.”

If my Cisco deployment runs G.729 (which at times Cisco has had issues with, see here to understand Cisco’s G.729 pre-standard implementation wows) and I want to interface to the PSTN that uses G.711 don’t I need a gateway and transcoders? Yep. Gateways, transcoders and media termination points (Cisco term but in some form every vendor has them) are a part of all vendor ecosystems and sometimes the use of standards does not negate this. Video in particular is an evolving technology and the final state of industry standards is moving at a rapid pace. Even the inclusion of WebRTC seems to be throwing a new wrench into the works for video evolution so to conclude that the world will live on without gateways is misinformed to say the least.

“Lastly, some companies that offer collaboration solutions manufacture their own IP phones/end points based on proprietary technology. If I choose this route and purchase these proprietary endpoints, I am surprised when I discover that …guess what? They don’t talk to other standards-based end points. What does that mean? It means you are forced to remain exclusively tied to these end points, or you need to buy 3rd party end points that have written this proprietary code directly into the end point itself. This limits your choice, as there are few vendors that choose to tailor their products in this way. If I do decide to change manufacturers over time, I will have no investment protection whatsoever. What will happen when new devices come on to the market? How long will it take the manufacturer to write code to support these proprietary implementations if at all? Do you really want to limit your options when you don’t have to?”

Is taking a Cisco Phone upgrading it to SIP then registering it with anything but CUCM even supported, how about registering a third party handset to CUCM? It may work sure but what about the user experience? Even on the Cisco developer page it’s referred to as Cisco SIP. If I look at Cisco’s developer documents it refers to proprietary and nonstandard SIP headers and identification services. Are you telling me even Cisco has proprietary extensions inside SIP on the line side? But I thought this is what the blog was advocating against. Right? Does that mean to get full use of a generic SIP phone I may have to code specifically for CUCM line side SIP specifications? Wouldn’t SCCP fall into this category along with Cisco Phones that are closely tied to the network through CDP? Sounds like a case against Cisco and not for it. While Cisco has made efforts to move toward SIP the blog post disregards where they have come from, the fact they use their own proprietary SIP extensions and where most Cisco voice customers are still today.

In the end I am not sure if large competitive over sights or lack of self-analysis is more disturbing about this blog post. Cisco has come to the conclusion that using common standards (SIP), marginally adopted drafts (H.265), home grown standards (IME, TIP), proprietary technology (SCCP, CDP) mixed with network based security (VLANs, VPNs and Tunneling) somehow qualifies them to judge the rest of the industry. Stacie’s final recap says it all:

“Let’s recap. What does implementing proprietary technology get you — more complexity, more infrastructure to deploy, manage and troubleshoot, more capex, more opex cost, less scalability and less end point choice.”

I guess that counts out Cisco.

VoIPNorm