Cisco Blogs


Cisco Blog > Collaboration

Deciding Upon a Collaboration Solution: Do Open Standards Still Matter?

While I was participating in a web conference from my home office, I started thinking about how much and how fast things have changed in the last decade around communications and how we use collaboration tools in the office, at home and on the road and most importantly the number of devices available to me so I CAN collaborate over distance.

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.

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.

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?

A Hypothetical Case  

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”.

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.

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.

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.

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?

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.

Now you tell me. Is it worth the cost?

Stacy

Tags: , , , , , , , , ,

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.

0 Comments.