I have been working with Lync for a little while now and as a result I have done a lot of research and troubleshooting. During the process of implementation and testing I have learned a lot about Lync's nuts and bolts. I will attempt to explain why I personally do not believe Lync is ready to be an enterprise voice system. I do believe Lync could be a good voice platform for a small to medium business if you have a good network in place and you aren't trying to make too many calls over a WAN connection. Now, let's get past the shiny paint job and look under the hood.
1. Call Admission Control (CAC)
Call Admission Control is an umbrella term for the mechanisms and practices of regulating traffic volume on a network, particularly when speaking of voice and video traffic. Call Admission Control can also be used to provide a certain level of voice and video quality or a certain level of performance on a network. Typically CAC is most important on slower WAN or internet connections.
When Microsoft originally put OCS on the market they would tell you that there was no need for Call Admission Control and Quality of Service (QoS). (More on QoS in a minute) Microsoft believed that their codec, RTAudio could handle it all dynamically (More on RTAudio later too). In a small to medium business with no WAN links on your network you probably could go without CAC and if it were really small you could try it without QoS, but not in an enterprise.
Microsoft's answer was to add CAC policies when Lync hit the market. Now you would think the problem was solved right? Nope. CAC in a Lync environment takes place at the application layer. While the Lync approach to CAC can limit the number of Lync sessions routed over a particular network link it has no idea how much traffic is actually on that network link. The application layer is not network aware. The only way you could have a reliable CAC approach using Lync CAC is if you dedicated a network link for the purpose of carrying Lync sessions. Once anything else runs on that network link you are risking over subscription. CAC still needs to happen at the network layer.
Another flaw I see in their CAC implementation is the reliance on the receiver end Lync client. Yep, the client, not the server. If you are in site A and you make a Lync call to site B and the network connection between the sites has a CAC policy associated to it here's how it works.
When the Lync clients in site A and B load up they get a CAC policy from the server they register with. When site A client calls site B client it will be up to the site B client to decide if the CAC policy will allow the call. If your network link is already congested you just sent even more traffic over that network link just to get your call denied. If you ask me, that's bad design.
2. Quality of Service (QoS)
It is true that Microsoft supports DiffServ for QoS tagging, but QoS and CAC are all off by default. My big gripe with the way they implement QoS is how complex it is.
You have to create policies for in the Lync server for each these services, roles, and applications:
- A/V Conferencing service
- A/V Conferencing Server
- A/V Edge service
- Application sharing engine
- Mediation server
- Response Group application
- Conference Announcement service
- Application based on the Unified Comunications Managed API (UCMA)
You can use Active Directory to push QoS policies to any Windows 7 or Windows Vista clients which doesn't sound too bad, but if you have any older Windows operating systems such as XP you will need a group policy to enable the packet scheduler service. Then each client machine will need the Lync Server Management Shell installed. After the shell is installed you will need to run two commands to get your voice and audio packets to tag for QoS. After that, in my opinion the Lync Server Management Shell should be uninstalled. Depending on your environment you could end up in a very high touch situation.
3. RTAudio Codec
I am sure I will take some heat for this bullet. Let me start off by saying I don't mind the RTAudio codec. I actually think it is pretty decent, but there are some pretty serious implications to consider.
RTAudio is a codec that provides algorithms for dynamic compression, but it does these compression changes over the course of a few seconds. It also provides for some error correction, but the most dangerous gotcha in my opinion is its ability to detect a lossy network and send redundant packets. What's that? You say that sounds really good?
Well, if you have a fully remote workforce I agree. If most of your calls are going over the internet redundant packets are great! You should use any means necessary to try and guarantee your packets get to the destination. However, if you are making a lot of calls across a WAN link and it gets congested you do NOT want all the calls going over the WAN link to start doubling their packets. If you had 20 calls running over a link that gets congested you just turned 20 calls into 40! A small business may never run into this situation, but an enterprise surely will. Some people will say "buy more bandwidth", but that is not a practical solution and it is definitely not a quick or inexpensive fix. RTAudio is a codec best suited for internet telephony solutions. I would rather not use it in my enterprise.
4. Conferencing Bandwidth
A small business could even run into an issue here. In this section I am referring to multimedia conferences. In other words, conferences that involve video, screen sharing, audio, etc. Each conference participant will get approximately 550k-700k media stream. Let's say we have one engineer in the US talking to three engineers in China. That will be up to four media streams traversing our WAN link to China. Anywhere from 2.2-2.8 Meg is being used up by only four people in a conference. A small business may be able to handle that over a WAN link, but we have conferences with 20- 30 people regularly. This is not a recipe for scaling out. Microsoft will tell you that hundreds can be in a conference. In theory I am sure they can, but in practice you are better off using a service like GoToMeeting or WebEx.
In summary, I think Lync has some potential and I think there are aspects of it that are great today, but in my opinion enterprise voice is a bit of a stretch. I am sure there are examples of it working out there. I am not saying it can't work, but I am saying it isn't as great as the marketing would have you believe. In my opinion there are some fundamental technology flaws that need to be addressed. If you choose to roll with Lync as an enterprise voice system I would tread carefully and do plenty of testing.