It is quite obvious the big market players are competing to own the “Unified Communications” space. I put quotes around Unified Communications because that definition seems to vary depending on who you talk to. Big name players such as Microsoft, Cisco, Avaya, Siemens, Polycom, the list goes on, have taken strides to create their own Unified Communications solutions. It’s no secret that big acquisitions are made by these large companies to add a feature to their UC solution set, then try to market the products as their own creation. I’ll leave the research of these acquisitions to the readers doing.
The first attack on Microsoft Unified Communications solutions seems to be the fact that they don’t offer native solutions for certain….”areas”….of Unified Communications. Again, Unified Communications is defined by all the players differently, so the boundaries of what should be native and what can be 3rd party is blurred and simply lies within the eye of the beholder. Two very common attacks we hear in the market is; Microsoft Lync needs Gateways and Microsoft Lync doesn’t offer a Call Center Solution natively. My answer to the Gateway myth – False. My answer to the Call Center Myth – So? Let’s go down the Gateway path, shall we?
- Gateways are absolutely not required for Lync Server 2013 Voice, it just depends on what you are trying to accomplish. To elaborate on this more, I put the most obvious interop scenarios in bullet point:
- PBX Interop – Indeed to interop with traditional TDM PBX’s, a gateway is needed with Lync if you want to keep the integration between the 2 systems On-Net. Lync 2013 has moved into the 21st century and well beyond the age of TDM circuits. Lync Server prefers SIP trunking so that is how it is designed. In order for traditional TDM PBX’s to interoperate with any SIP only system, a gateway most likely will be needed in between. Now keep in mind, depending on your desired goals, coupled with the Telco provider and proper planning, a gateway may not be necessary On-Net. Really, it just depends on a design and what makes sense in your environment to get from A-B.
- IPPBX Interop – Again, a gateway is not required in all cases. If you read up on Microsoft’s Unified Communications OIP website, you’ll quickly see that Microsoft Lync if fully capable of Direct SIP with Alcatel-Lucent, Avaya and Cisco. Granted, proper planning and desired goals of the interop must be kept in mind as some functionality may not work between the 2 systems without a gateway. If your IPPBX is not listed on the OIP, it absolutely does not mean direct sip will not work with Lync, it just means it was not tested or may not have passed all the requirements by Microsoft. Take SnomOne IPPBX as an example; direct sip connection from SnomOne to Lync works great, but there may be functionality missing such as REFER support or the ability to DNSLB to multiple Mediation servers as an example, which could be a disqualification to become certified. The reasoning of these limitations should be shared between all vendors and the blame should not be solely put on the shoulders of Microsoft. Just know that at least Microsoft calls them out publically so you know before you invest.
- ITSP Sip Trunking – Session Border Controllers “SBC” are the gateways to provide this kind of connectivity. But once again, if you read up on the OIP, do your research and reach out to your ITSP, these SBCs may be provided or not needed as Lync can accept a direct connect in some scenarios. This is more of a requirement from the ITSP and the type of protocol used. Microsoft Lync is designed to use STANDARD based TCP protocol for secure SIP communications where some ITSP’s only provide UDP so something has to be in the middle to convert that communication from UDP to TCP. Once again, this is not a Microsoft Lync limitation as some competing vendors like to preach.
- Gateways for Video and Lync Server 2010/2013
- H.263 – It’s once again false to assume a third party gateway is needed for video interop. Lync Server absolutely uses a proprietary video codec and that is no secret; it’s called RTV. There are plenty of arguments as to why Microsoft chose the RTV direction years and years ago, but nonetheless, it is in their video stack. Also in the video stack Pre-Lync Server 2013, was H.263 STANDARD based video codec. Lync and OCS had no issues integrating with various video platforms with H.263, not all systems, but a good share. Granted, the video quality was limited to CIF, but nonetheless, a 3rd party gateway investment was not “required”.
- H.264 SVC – I’m not a video expert by any stretch, but I do know that H.264 SVC video codec is a standard and it has replaced H.263 in the Lync video stack. On the Lync Server TechNet planning pages, one can view the technical details surrounding H.264 and Lync. So the argument about “Lync does not use standard based video” is absolutely false and very well documented on the interwebs. As a side note, it must also be called out that RTV is no longer the default video codec in Lync, as H.264 replaced RTV as the default and preferred video codec. The reason, and only reason RTV remains in the stack, is for backward compatibility. If Microsoft was trying to pigeon hole your video infrastructure, ask yourself, would they choose H.264 as their default video codec? Don’t be fooled by the competitor’s gospel.
- Excellent Video Reference – If you so desire to argue video interop in Lync and the use of SVC, I challenge you to reach out to fellow Lync expert and highly respected MVP Jeff Schertz for the video deep dive your heart desires. Hold on to your hat… http://blog.schertz.name/2012/07/video-interoperability-in-lync-2013/
Next up is the Call Center argument
- I don’t have much factual information here as to why Lync does not offer a Call Center solution. But I do know that Lync offers an IVR solution that is acceptable in many scenarios. In fact, outside the obvious call centers we call for things like Cell Phone support as an example and similar companies, I’d challenge the “need” for a call center when a watered down IVR may be adequate. Now, I’m not saying I would walk into an organization whose revenue stream is generated off of a huge call center and attempt to sell them native Lync as that makes no sense. We know Lync is not that solution and that is simply not the targeted customer base anyway. (Remember we are desiging and deploying a Unified Communications solution, not a call center solution) This also doesn’t mean there aren’t 3rd party solutions that bolt on to Lync that can solve the Call Center challenge. There are plenty available on the market so if Lync Server is deployed for back office, providing substantial savings to you and you are wanting to learn how it could extend into the call center, do research and you’ll find plenty of solutions. Ask yourself, does Call Center fall under “Unified Communications” anyway?
If you are considering Lync Server as your UC solution I can speak for the Microsoft UC System Integrators and customer community that you will absolutely not be pigeon holed to proprietary codec’s, you won’t need an abundance of 3rd party hardware and you won’t be on an interop island secluded from the rest of the industry or be denied the ability to interop with your current investments. I do ask one thing of all organizations whom read this blog trying to get answers before you make your next UC investment; Ask around and try not to take any one vendors word for what the rest of the market is doing. Evaluate all our solutions and let the solution do the talking for itself. Microsoft Lync may or may not work for you, but don’t let it be because some uneducated and uniformed salesman said so.
I welcome your comments
