Cisco vs. Microsoft

[deanwebb]

I've heard a little bit about the clash of titans in the VoIP realm... Cisco seems to be the best tech, but MSFT has the lowest price. Question to the voice guys, what's your take on the differences between the two vendors?

[scottsee]

We are in the middle of a lync migration from 2010 to 2013. It's rough, there are a lot of moving parts. We are using 2911's for SBC with kemp load balancing. From an architecture standpoint lync takes a lot of planning and resources to deploy correctly. I don't know what the costs are, but wen you add in the redundant hardware requirements (vm and physical clustering, live migration, shared block storage)the server licensing and SBC hardware I would argue it's more expensive.... Plus it's a bitch to manage.. Unified messaging from microsoft requires administration knowledge from Server, AD, Exchange and Lync... I've never been involved with cisco voice deployment so I can't speak from experience..

Additionally, phones come in 3 flavors. Lync certified, compatible and unsupported... I spend 2 weeks with poloycom and lync consultants working on dropped service and getting basic 911 working on "lync compatible phones"...

Lastly... ShoreTel is by VOIP background, you can train a monkey to administer those systems!!!! Solid product

From iPad

[that1guy15]

I hope to hell I am not around when they decide to support voice/video over lync in my current role. Systems admins are struggling to get our domain up to par for lync right now as it is.

Nope, nope and HELL nope!!

[Seittit]

If you guys could see our list of firewall rules for Lync...good lord.

That being said, it's a pretty reliable system once it's up and running.

[deanwebb]

Microsoft is the king of "oh, just open up *all* the ports" for an app. On a Juniper SSG, I need four separate service groups for the AD services.

[Otanx]

Microsoft is the king of "oh, just open up *all* the ports" for an app. On a Juniper SSG, I need four separate service groups for the AD services.

This. The Windows rules are the ugliest ones on our devices.

If I remember correctly it is the RPC service MS wants ports 5000 - 65535 open. There is a KB article on how to limit these ports. Our Windows guys did this, and it works sometimes, but some things ignore the restriction, and pick a port outside of the limited range. Then they blame us, we blame them, someone calls MS, and finds out that for that application their is a special way to restrict the RPC ports it uses. That then becomes a GPO setting that must be documented, and tracked.

-Otanx

[wintermute000]

The main problem with Lync is because its administered by microsoft guys...

CUCM is no walk in the park either, its increasingly complex/unwieldy and uses a convoluted logic that has no alignment with any other IP-PBX vendor or common standards. They even (intentionally) break the RFC compliancy of the SIP stack in their SIP firmware.


I remember when we wanted to sell simple conference bridges on our CUCM cluster (as out of the box 8.6.x only supported meet-mes i.e. no password conferences). THe Cisco solution required a white paper to describe and involved spinning up a bunch of extra servers as well as tying it into webex/whatever cloud solution they were flogging. We ended up spinning up an Asterisk server instead with a SIP trunk back to CUCM, I had a proof of concept working in a single afternoon.

Carrier / cloud based SIP will take over both. Point a phone @ an IP address (which will be the provider SBC doing the proxy registration), provision an account on the provider side, stop worrying about it. With systems like Broadsoft (20 million endpoints on one cluster... ) you can even register your chat/phone control clients or smartphone VOIP applications the same way. Land-line call rates are already a commodity and in house PBX systems will follow.

[Dieselboy]

They even (intentionally) break the RFC compliancy of the SIP stack in their SIP firmware.

Any reference to that where I can read up?

I manage our Cisco Jabber set up. Was rough at first since their app simply didn't do what it was supposed to do. Also as they have no product alignment across Windows and Apple Mac platforms so people on Windows could do certain things but when a Windows person spoke to an Apple person, some features were lost. Cisco now have a roadmap to align the features and there are less and less problems with each release as they tidy themselves up.

[packetherder]

Any reference to that where I can read up?

I manage our Cisco Jabber set up. Was rough at first since their app simply didn't do what it was supposed to do. Also as they have no product alignment across Windows and Apple Mac platforms so people on Windows could do certain things but when a Windows person spoke to an Apple person, some features were lost. Cisco now have a roadmap to align the features and there are less and less problems with each release as they tidy themselves up.

More anecdotes, but every linux SIP client I tried fell on its face with CUCM. Definitely some non-compliant stuff going on. Unfortunate too, since there's not an official linux client from cisco.

[wintermute000]

I don't have an official reference except pages after pages of asterisk forums

When I tried interop with Broadsoft and/or asterisk I quickly found anything with version 9 SIP firmware or above was sending alien space-language on certain functions e.g. fall forward, not even SIP. Corroborated quickly with various interwebz posts, basically on 7940/42s version 8 firmware is the last one that is remotely sip complaint. Even then due to CUCM it is retarded and has no concept of a SIP proxy because in CUCM land there is no SBC or separate SIP proxy, so you have to resort to dirty hacks like DNS round robin for your SBC registration redundancy. The details are getting sketchy now (around 2 years ago) but trust me Cisco just does not want to play in the SIP compliant playground (notice how no SP or VOIP provider goes anywhere near them for voice).

[RHochstenbach]

I've been working with both sides (Microsoft Lync and Cisco Jabber), and Lync is absolutely horrible to implement. We've spent over a year to deploy this, together with several Microsoft Gold Partners. Cisco Jabber has been much easier to implement for us. We provide this for our customers, so we use these environments daily. Microsoft on the other hand is still going to win this, mainly because they already have a foot in the door at most companies. I've spoken with different people at Microsoft, and they have this strategy of offering Lync at a discounted price or even for free. That's something Cisco can't compete against. This will be the same battle as the web browser battle in the 90s between IE and Netscape. Netscape was much better, but IE won because it was shipped with Windows (which almost everybody was using already).

[deanwebb]

Exactly. MSFT may not be booming along like it did in the nineties, but it'll be damned if it loses any market share.

[wintermute000]

I've been working with both sides (Microsoft Lync and Cisco Jabber), and Lync is absolutely horrible to implement. We've spent over a year to deploy this, together with several Microsoft Gold Partners. Cisco Jabber has been much easier to implement for us. We provide this for our customers, so we use these environments daily. Microsoft on the other hand is still going to win this, mainly because they already have a foot in the door at most companies. I've spoken with different people at Microsoft, and they have this strategy of offering Lync at a discounted price or even for free. That's something Cisco can't compete against. This will be the same battle as the web browser battle in the 90s between IE and Netscape. Netscape was much better, but IE won because it was shipped with Windows (which almost everybody was using already).

This seems true (using existing AD leverage to get foot in the door) but its also their greatest problem - the army of retarded MCSEs that have to build and administer it.
Have observed multinational MSP struggle with a 2 day Lync outage because a cert expired and it basically took 2 days to get a non-braindead 'level 3' engineer who understood basic PKI (of course, they managed the CA as well, standard enterprise CA model). Also, lord help you for any SIP/SBC related issues or changes.
You think its bad getting router guys to dabble in VOIP? Wait till you watch MS jockeys try it. I'm not even going to start on QoS ROFL.... Throw in the generally poor level of 'tech' that exists in the MS realm and its fun times

[deanwebb]

There was a time when MCSE meant something... and then the paper MCSEs showed up... but even those weren't as bad as the dumping MCSEs...

[RHochstenbach]

This seems true (using existing AD leverage to get foot in the door) but its also their greatest problem - the army of retarded MCSEs that have to build and administer it.
Have observed multinational MSP struggle with a 2 day Lync outage because a cert expired and it basically took 2 days to get a non-braindead 'level 3' engineer who understood basic PKI (of course, they managed the CA as well, standard enterprise CA model). Also, lord help you for any SIP/SBC related issues or changes.
You think its bad getting router guys to dabble in VOIP? Wait till you watch MS jockeys try it. I'm not even going to start on QoS ROFL.... Throw in the generally poor level of 'tech' that exists in the MS realm and its fun times

I've seen MCSE and even MCITP guys panic when they where presented with a CLI (before the MS Powershell era). And they call themselves IT Professionals. In my opinion an IT professional should be able to work with Windows, Linux (especially using the CLI), know at least one scripting language and have some understanding (at least basic understanding) of networking, troubleshooting and PKI.

I remember an issue where we had a conflicting ARP entry in one of our switches due to an IP conflict. One of my colleagues (who is MCITP certified) was surprised that he found this conflicting MAC address in all the other switches on that broadcast domain, as he was under the assumption that MAC addresses don't pass a switch because they would be NAT'ed somehow. And they call themselves IT professionals