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

14 comments:

  1. Microsoft has nothing proprietary within any of it's products including Lync then?

    Microsoft Lync supports Blackberry and Symbian which both have a larger market share than WP8?

    How many other UC manufacturers in the top 10 support WP8?

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

    I guess that counts out Microsoft at well.

    ReplyDelete
  2. I never said Microsoft doesn't use proprietary technology, every UC vendor does in some form. I am not presenting a blog that says other wise either. I think you missed the point of this post. Its about Cisco misrepresenting its position on standards, not a commentary on Microsoft.

    Yes there are apps that support Blackberry and Symbian with Lync and WP8 has only just released so I suspect that they do both have a larger market share but current market trends indicate this is not going to be permanent.

    I have no idea how many UC vendors support WP but you could also say they are limiting choice by not supporting it if they don't. Seeing both Blackberry and Symbian have a shrinking user base it would make sense to support WP which seems to be growing.

    http://wmpoweruser.com/the-us-windows-phone-market-share-grew-50-between-q2-and-q3-2012/

    Thanks for your comment.

    ReplyDelete
  3. Cisco's CDP protocol was created well over 10 years before LLDP-MED was even approved, so that is kind of a bad example of Cisco pushing proprietary technology over established standards. Unless you are running something ancient, like 3500XL switches (which have been end of life for some time), this isn't that big of a deal, it's just a matter of making the relevant configuration changes. Yes, the configurations won't be as easy as if you are using a Cisco native solution, but that's something that no one should have the expectation of. Regardless, that doesn't change the fact that you can build an all Cisco solution using LLDP, or you can build a cross-vendor solution using LLDP.

    Same thing with SCCP versus SIP. SCCP was in production years before SIP was an approved standard. Yes, Cisco does a poor job of implementing "open" SIP, but that is one of the problems with SIP - the specification is too weak, and anyone can bastardize it pretty much as they see fit and still call it SIP. Still, you can get some degree of functionality out of "standard" SIP devices with CUCM, and you can get some degree of functionality out of Cisco SIP devices with other UC platforms. Sure, that isn't supported, and it's not going to work great, but it's not designed to work great. It's designed to deliver a minimal set of functionality so they can advertise "SIP Standard". They deliver that.

    As far as G.729 is concerned, yes, it is closed. But, it is still considered "industry standard". A protocol doesn't have to be open to be a standards-based protocol. I agree that G.729 isn't a great protocol, but it is very interoperable with a wide variety of vendors. In fact, any time I've done any kind of integration, I can pretty much plan on everyone supporting G.711 and G.729. I agree that H.265 is questionable, but I've yet to see any Cisco devices using it. Any vendor can talk about something all day long, but that doesn't change what they actually deliver. In fact, I don't care if they offer H.265 as an option, as long as it can fall back to H.264, which is a standard codec.

    As far as encryption for the call control traffic... I'm still on the fence about that one. As you said, you could encrypt your internal traffic, then have insecure trunks back to systems that do not support encryption. In some environments, such as those where call recording is required, I'm not sure you really get an advantage, because even the few recorders that support media encryption don't seem to support call control encryption (if they do, they sure aren't good at advertising it). If you have a very basic deployment, then full encryption makes sense. If you plan on integrating with anything else, those benefits start to disappear, one trunk at a time.

    There is really no sense in talking about Cisco's support of WP8, because their mobile phone client is pretty terrible on all platforms that it is available on anyways. Besides, MS supports their own mobile platform out of obligation, not because it is superior in some sense - they would look silly if they didn't.

    Agree with Anon about the quote certainly eliminating Microsoft - The infrastructure required for us to deploy Lync Enterprise Voice globally versus our CUCM deployment is ludicrous (according to what the Lync Planning Tool asks for), and the cost of adding the EV licenses to our ECals is far into the 6 figure range, and that doesn't even count the scads of Lync Enterprise Server licenses that the Planning Tool thinks we should have. Then, if we want branch survivability, we need more servers & licenses there. By the time it's all said and done, the maintenance is much higher as well. And we haven't even started talking about Voicemail!

    ReplyDelete
    Replies
    1. Hi Josh,
      Thanks for commenting. Good counter arguments and some interesting points. had to break this into two parts because of length.

      I agree that they did proprietary features before standards were well established which is the whole point of my post. There are reasons companies do this even sometimes in the face of an established standard but if you were to read the original Cisco post, you would think that Cisco are the sons of standardhood not to be challenged on their position. Different vendors, not just Microsoft, are at different points in their development life cycle and depending on when and where standards are used is a business decision just like the one to decide to move to a different PBX manufacture.
      But this wasn’t addressed or even considered in the post, it was merely we use standards (however poorly their implemented) so we are better type post. Things in reality are never that clear cut.

      In regards to G.729 as I mentioned in my post is widely implemented and an accepted standard. As you suggested it really is closed and a pretty poor codec for most modern networks. So if it’s closed and not that great what does it really buy you. Interop, sure, but last time I checked there are far more compelling reason to choose other codecs that make more sense and I have yet to see codecs be a blocker in any deployment. More to the point isn’t the original post meant to be about open standards not closed standards that are losing favor in light of new open standards like Opus etc.

      So partial encryption may not be the best answer but that in some regards is better than no encryption and let the network handle it, which to me makes no sense at all. That’s almost as bad as saying VLANs are a security feature in my opinion. To use Lync or for that matter Cisco UCM as an example you can do an end to end encrypted solution. So to say you should just leave it unencrypted to allow the network to handle it seems just plain stupid. Certainly using network encryption where encryption is not available to the native system may make sense but using native encryption capabilities of a system is typically easier to configure and deploy than VPN, Tunneling and VLANs between every component. I would also suggest network security would not be truly end to end unless you want a VPN running on your client all the time. Great way to clog down you network service.
      I love the point about their mobile client being terrible. While this may be true, having the widest available set of mobile clients is always going to serve you well regardless of their popularity at the time. There are basically 4 mainstream smartphone platforms at this point. iOS, Android, BB and WP. Anything less and you limit your own opportunities. Of course it only makes sense for MS to support their own platform but there certainly seems to be a growing fan base and support for this platform unlike RIM where they are hoping BB10 will save the company.

      Delete
    2. Part 2
      As to the points of your own deployment, I can only suggest you work with a qualified partner to best asses your environmental needs. The Planning Tool although uses Microsoft best practices isn’t perfect. Unless you have a lot of experience working Lync deployments and can fine tune the information from its output it has can present a skewed version of what’s required showing depending on the inputted variables. As to licensing servers for Lync there is only one functional role that requires licenses, the Front End. All other server roles, monitoring, archiving, Edge, SBA are considered no cost additional software and with Lync 2013 most servers roles are consolidated on to the Front End limiting the amount of servers that needed to deploy.
      In the end if you compare Cisco’s server foot print for all their UC offering (CUPS, CUCM, Webex, CER etc) and compare this to Lync you have quite a different outcome. Just comparing the CUCM foot print to Lync is not an apple to apples comparison.

      As for support your mileage may vary and I am not going to even attempt to offer a comparison. I will just say make the comparison apple to apples as Lync has more to offer than just voice.

      Thanks again for your comment and keeping it more on the constructive side.
      Cheers
      Chris

      Delete
    3. When it comes to telephony, every vendor has used proprietary elements at some point. Otherwise, you could plug any phone into any system and get it to work. When it comes to vendors who have supported open telephony standards, Cisco does have somewhat of a decent track record. They have supported SIP since at least the early 2000's. The oldest SIP firmware I see is from 7/24/2001, and that doesn't include whatever Selsius supported prior to the acquisition. That is well before MS was even in the game, so they do have at least one stone to throw from being in that position.

      When it comes to "Cisco SIP" versus "Standard SIP", MS certainly doesn't have a stone to throw. There are a whole range of Lync phones that won't work (or at least don't have anything in the data sheets about interop) with anything other than Lync (for example, Aastra sells Lync phones and SIP phones for example), so good work pushing for open standards there.

      Microsoft doesn't have any stones to throw when it comes to codec interop either. They are pushing RTA/RTV and even a proprietary version of WebRTC. MS has a long history of breaking interop in general, so until they start changing that tune, you really don't have a very defensible position when it comes to codecs. And where is MS support for Opus? Who's to say they won't bastardize that as well? Even though Cisco does have proprietary protocols, they do a much better job than MS at supporting a reasonable selection of industry protocols. Even Asterisk offers support for G.729 (at a cost), and I don't see anyone accusing them of not supporting open standards. Paying a licensing fee for use of a standard is pretty common in the telephony field (i.e. many of the technologies relating to GSM and CDMA require licensing fees). The way you write about it, it seems as though you feel that MS has a superior ideological position when it comes to licensing G.729. Why?

      Yes, we can debate the merits/demerits of G.729. But, that doesn't change the fact that it's here, and doesn't appear to be going away anytime in the immediate future. MS choosing not to support it is an act of hostility towards the industry, once again trying to establish themselves as the alpha male. And you're right, codecs are almost never a blocker. After all, you can always throw transcoders at that problem. That always makes for an excellent solution.

      When it comes to sizing - everyone wants you to work with an established partner, Cisco included. But, when you look at the sizing tools of MS versus Cisco (I used a fairly small company of 2000 users for my calculations - apparently this is still enough for the sizing tool to recommend most roles not be combined), the build for Cisco has a much smaller footprint than MS (and that is even including the fact that Cisco's build is way over-spec'ed as well, and that is with the full Cisco suite including On-Prem WebEx Meeting Servers). If the sizing tool is that far off from reality, than MS should fix it.

      Cisco's post hits right at home with a lot of the things that MS is doing. Is Cisco a son of standardhood? Of course not. But, when it comes to open telephony standards, I think they are the second tallest midget in the crowd aside from Asterisk.

      Delete
    4. Hi Josh,
      Part 1

      I think a lot of your comments are a little misinformed and you might want to check your facts before commenting again. I think we both agree though everyone does proprietary things which is by and large completely acceptable. No reason to keep restating this in different ways.

      While Microsoft’s entry into the Voice market was around 2004 with some early features in LCS the use of SIP has a long history back before LCS 2003 for the use of IM and presence. Cisco’s support of SIP didn’t start till well after the acquisition of Selsius with trunk side SIP in CUCM 4.0 in 2004 and line side SIP followed after that with the release of CUCM 5.0 which was in 2006 which is well after your comment indicated at 2001. I know this from working on Cisco deployments when they first started supporting line side SIP. So let’s be clear Cisco’s support of SIP was not before many of their competitors.

      I think you will find that on release of Lync Microsoft created specific firmware to guarantee the experience out of the gate not because of not following standards. As with any product evolution more of the phone manufactures are now releasing more generic SIP phones that meet Lync’s requirements around the experience and encryption which many generic vendors of SIP products could not in earlier revisions of their products. That fact that SNOM and others are releasing generic SIP phones that work with Lync speaks to Microsoft commitments to ensure not only the user experience is maintained but also following standards and publishing where they diverge to support their own extensions (which is exactly what Cisco has recently started doing). What good is a SIP phone if only half the feature buttons on the phone actually work and can’t meet the encryption requirements of the platform?

      So when Microsoft originally entered the voice market there were no codecs specifically designed or meet the criteria of being able to operate on uncontrolled networks. So they designed RTA and RTV to meet those requirements as they saw a need for it and there was no standard that meet that need. Similar to SCCP or CDP as you earlier stated with Cisco. G.729 although popular really didn’t perform well with high packet lose or jitter on IP Networks and also comes at a licensing cost which Microsoft decided not to pass onto the customer. G.729 is hardly forward looking either. So in the end hardly a hostile decision as you described but more of wanting to create a more futuristic platform less reliant on non-relevant standards that don’t translate well on an IP networks. I see less and less of G.729’s deployment as better more flexible codecs have come on to the market place so in the end I believe they did make a good decision while supporting other standards based codecs such as G.711 and G.722. This added no additional cost to the platform and they perform relatively well on IP networks albeit at a slightly higher bandwidth than RTAudio narrowband, although I am sure some would argue G.722 is equally capable in this area.

      Delete
    5. Part 2

      So while RTV has really done well on the platform and is widely supported by partners, Microsoft has realized that there are new standards that are have become widely accepted and hence the use of H.264 in Lync 2013 as the default video codec. Although H.264 has many flavors it is certainly more stable from a support perspective and well developed. Of course inclusion of new standards all happen as part of a product development life cycle with all manufactures including Cisco. A business decision every vendor makes, so are we to conclude that now its H.264 Microsoft is pushing that to because it’s the default? No, they made a business decision that the codec meet the requirements of the platform and so they decide to move on with the standard.

      WebRTC is an interesting topic but I am not sure where you get Microsoft is developing a proprietary version of it. In fact Microsoft is a major contributor to the standard with the W3C WebRTC Working group. Although they may be proposing something slightly different than what the original proposal of WebRTC it’s open for developers to download and provide feedback on as part of Microsoft Open Technologies, which is Microsoft’s open source subsidiary.

      http://blogs.msdn.com/b/interoperability/archive/2013/01/17/ms-open-tech-publishes-html5-labs-prototype-of-a-customizable-ubiquitous-real-time-communication-over-the-web-api-proposal.aspx

      Seeing as Microsoft has been in the business of developing OS’s and Browsers for the last 35 years I would think that their contribution is every bit as critical as Googles and more so than Cisco’s seeing as Microsoft is one of the leader browser implementers. In fact Opus which is being slated as MTI for WebRTC was developed with work from the Microsoft Skype division.

      http://blogs.skype.com/en/2012/09/skype_and_a_new_audio_codec.html

      So I have no idea what you input to the planning tool was and I doubt that you actually consulted anyone on your inputted accuracy either. I would suggest that I have never seen a 2000 user deployment that required server roles to be broken out to the level you’re suggesting so I can only assume that your variables you entered or your interpretation of the output is skewed. In fact depending on the requirements you could be deployed with little as 2 Lync servers and 1 Exchange UM server which would support all users for all Lync features, all virtualized. Hardily a sprawling server farm but your requirements may make this higher.

      It seems you are skewing the conversation to turn it into a MS versus Cisco conversation and I am fine with that but at least come with fact based argument as I have clearly shown you missed the mark on quite a few of your points. At the end of the day the point of my post was to point out that Cisco is guilty of the exact same thing they are accusing others in the industry of and nothing more. I just used historical and current evidence to back up my point of view which the original poster of the Cisco blog choose to ignore.

      Cheers
      Chris

      Delete
    6. I'm not sure where exactly I am misinformed. I'll clarify a few of the points to add some detail.

      I realize that CUCM didn't support line side (or trunk side) SIP until later - that wasn't the point I was making. Cisco supported SIP firmware on the phones themselves well before CUCM itself supported it (Firmware P0S30200.bin is dated July 24th, 2001).

      And yes, I get that MS created Lync specific firmware for feature support - however, if you were one of the early adopters, you can't take your phone elsewhere (at least, none of the data sheets I looked up claim that you could install SIP-standard firmware or even use the phone with non-Lync platforms).

      The way you discuss RTA/RTV, it almost sounds like Lync is never deployed to networks that have QoS in place. I assume that's not actually the case. I think the more accurate argument is that G.729 is not designed for use on the Internet. You also reference high-latency, but I'm not sure how high you are speaking of. I've used G.729 across MPLS links with latency over 200ms with no issues (in fact, I have a SIP trunk between Chicago and Sydney that averages 204ms that uses G.729; works like a charm). Jitter is more of a problem, but this is generally only a problem with awful Internet connections, not MPLS connections. So, yes - I get it. Lync is apparently primarily targeting customers without dedicated connections, and that facilitated the development of an Internet-tuned codec. That makes sense to me now.

      As far as WebRTC is concerned, MS is moving along with development of a non-standards-compliant version (CU-WebRTC), at least according to many sources. For one example:
      http://gigaom.com/2013/01/17/microsoft-cu-webrtc-prototype/

      I'm not sure how being a browser developer makes MS a better contributor to telephony than others. Especially with Opus being developed by Skype pre-MS acquisition (submitted to the IETF 9/2010 according to Wikipedia). And, just because Ford has made cars for 100 years doesn't mean I trust them to tell me what computer to buy.

      As far as the planning tool, I'll walk you through it. Accept all defaults for the first section, enter 2000 users, Virtualization = yes, 10% conferencing, 80% dial-in (my current company utilizes audio conferencing pretty heavily), 100% enabled, gateways w/PSTN, 100% enabled, Hardware load balancer (since that is what the planning tool recommends), everything else default. Again - if the planning tool is so far from reality that I am forced to consult with someone to come close, then the tool shouldn't even be around.

      You work for Microsoft. This became a Microsoft versus Cisco conversation as soon as you posted it to your blog. I don't believe I've excluded any facts here, so let me know specifics.

      Delete
    7. Part 1

      I stand corrected on the phone firmware. They supported it on phone so they could sell more phones. Excellent. In the end I am not sure what this proves to you now that you’re aware of other companies supporting SIP around the same time but for what’s it worth I stand corrected.

      I am not sure what your point is with your second point. I already explained the reasons for this and at the time SNOM had generic SIP phones available with the release of Lync so companies could buy a more generic phone that could be supported by other SIP platforms (at the same time if need be). Yes the Lync specific/Aries phones are not portable like the SNOM phones are but the customer had an option to choose one or the other. They weren’t locked into a sole provider for phone options and it’s been this way since Lync first launch and sometime before that with OCS. Other phone manufactures are now moving forward with similar offerings.

      Some companies do deploy QoS and others don’t. Some deploy it for phones and not other devices such as PC’s. It varies so much isn’t it better to look at the reality of the situation especially with work at home and BYOD where people expect service everywhere. As for the internet it’s the Wild West so no guarantee there either. So packet lose which I should have mentioned earlier is probably the area that G.729 is the most sensitive. Less that 1% of packet lose begins to degrade conversation. G.711 a little better with %10 and RTA around %20. So other than the most well controlled network where QoS is guaranteed G.729 will struggle to perform in an adequate fashion. I am glad you understand it now.

      So Microsoft is submitting the proposal to the W3c working group as part of the WebRTC development. I am not sure whats wrong with that. They can’t have an opinion considering they are building the browser that’s meant to implement the proposed standard? More to the point WebRTC is not a standard yet its still to be ratified so how is the proposal non-standards compliant? That’s why it’s a working group.

      Who said telephony was the sole reason for WebRTC? There are a bunch of services that could potentially benefit from WebRTC. Facebook is a good example. Granted UC providers will get a lot out of a web browser standard in a number of areas but don’t limit your thinking to just telephony. This is a browser standard for real time communications not a telephony standard.

      Delete
    8. As for Opus you may have a point that it was submitted before the acquisition but wasn’t ratified till after. So what does this mean? Microsoft stayed the course to see Opus ratified as a potential candidate codec for future versions of its own software and open for anyone else to use. I don’t see a downside here and shows Microsoft is using its new IP from Skype in a sensible fashion. You may not choose to trust Microsoft as a voice provider but there certainly many others that do. I am pretty sure I am not going to convince you otherwise but your mistrust seems to be misplaced going by some of your comments.

      Back to the planning tool and again I am not going to assume anything but the planning tool is a guide. I ran through your inputted variables from what you have provided using different scenarios for those you didn’t and came out with a pretty modest deployment using Lync enterprise edition all virtualized. Considering improvements in Lync 2013 this could also be improved upon but what’s makes the real difference is experience with the product. For example the planning tool recommends breaking out the AVMCU server and adding a Director but neither of these things are requirements for a single pool deployment with less than 10K users. For HA it recommends three front ends when really 2 would be capable of the load with 2000 users. So lots of variables and the planning tool errs on the higher side of things. Saying it shouldn’t be around is a bit a stretch as once you know and understand Lync it can provide a good way to provide an early estimates of the requirements from which you can fine tune. I have used it myself for that exact purpose as have many other consultants I know.

      Comparing it against Cisco, I bet if you included Remotes access (ASA’s), CUPS for Jabber, Webex or meeting place, CER for E911, Unity for voice mail, CUCM for telephony plus any other video conference resources required and made them all HA it would at minimum comparable and or a lot higher.

      I am certainly more direct than what’s Cisco’s post is and I make no apologies for that but the fact remains what I mentioned in my post certainly speaks to Cisco’s track record. I specifically avoided mentioning Microsoft or any other vendor in most cases as this was about Cisco’s track record in comparison to the original post. I am sorry you don’t get that and immediately went to a Cisco versus Microsoft position and couldn’t look at it more objectively. Of course I have a specific point of view but that doesn’t preclude me from being able to have an opinion, you just have to take that into account.

      Cheers
      Chris

      Delete
    9. I apologize that I misconstrued this as a Microsoft versus Cisco discussion. Cisco's blog post was pretty obviously targeted at Microsoft, and a retaliatory post from a Microsoft guy against Cisco gave the impression (to me at least) that this was a dual sided discussion. So, my apologizes for assuming that from the beginning.

      To some of your direct points about Cisco's post itself - what exactly is the benchmark for supporting "all major mobile OS’s? Should a UC provider base that on current market share? How many of the "top" OS's should be catered to? Anyone with more than 5,000,000 sales? 1,000,000? Or should it be a hard count, like the top 5? To be fair, Cisco supports (to some degree) the top 3 OS's by market share. It could also be said that they support every mobile OS that has more than 7,500,000 in sales in the last quarter. In fact, someone looking at market share would be focusing on Symbian (which was also at one point supported by Cisco) and Bada before targeting Windows Phone, but that's really beside the point. I don't fault them for sticking to whatever benchmark they are using.
      http://en.wikipedia.org/wiki/Mobile_operating_system#Market_share

      Granted, every customer is different, but if Windows Phone support is required, it looks like you've pretty much already chosen your solution - I can only find one UC vendor who acknowledges in their documentation that they support Windows Phone.

      As far as the message itself - this is something that was said by a marketing person, and it's clearly marketing speak. I wouldn't call the message confused, it's just especially vague - and no, the blog post was not made by a trusted adviser. That being said, Cisco (like many others) are just as pleased to just sell you stuff as they are to be a trusted adviser, so you could find statements from either side of the fence on that one.

      Does Cisco have a perfect track record? Certainly not. But, then again, they aren't at the bottom of the pack, either.

      Delete
    10. Thanks for your comments Josh. Its been a great discussion.

      Delete
  4. G.729 annoys me. We are supposed to make things better for our users - not lower their audio quality below what they would have expected to have even 50 years ago!

    ReplyDelete