Microsoft Lync as Enterprise Voice....No Thanks

There is a lot of hype in the marketplace about Microsoft Lync and how it is a great enterprise voice platform. While I do like the Lync product for  IM and presence I believe it has some flaws when it comes to some conferencing situations and enterprise voice. Before I go any further I want to remind the readers of this article that you are reading my blog and as such contains my opinions. I definitely welcome a healthy discussion and I do not claim to be the all knowing expert in all things.

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.

Microsoft Lync Dial In Conferencing Problem

I'm sorry, I am having trouble accessing the system right now, Goodbye.......

If I never hear that phrase again it will be too soon. We recently implemented Microsoft Lync for IM, Presence, and Conferencing between Lync clients. That seems to work great, in fact I think it is one of the best and affordable options available for those features. The rub for me comes in when the subject of using Lync as a phone system is brought up (hold your opinions until later).

Since I am not very comfortable with Lync as a phone system and I have to support these systems I have been working on integrating Lync and Cisco Unified Communications Manager. As many of you will know the best option for bringing that integration is through CUCILync. So far, CUCILync seems to work pretty good, but there are definitely some caveats of integrating the two systems.

Now you know what my communications platform is shaping up to be. Essentially, I want to use Cisco for voice and point to point video calls then use Lync for IM, Presence, and Conferencing.

I got all of this working and when I started testing Lync Dial-in Conferencing I could only get it to work when joining the meeting using a Lync client (which is NOT dial-in).

Here's the flow:

Dial Into a Meeting That is In Progress (Leader has joined)
1. I start a meeting using my Lync client.
2. I dial into the meeting from the PSTN.
3. I hear the auto attendant and go through the menus to log in as a guest.
4. I can see a guest in my meeting via my Lync client.
5. The PSTN call shows connected, but there is no audio.
6. Approx. 45 seconds passes and the auto attendant says "I'm sorry, I am having trouble accessing the system right now, Goodbye."
7. The PSTN call drops, but my meeting stays in progress and other participants using the Lync client still work.

Dial Into a Meeting That is NOT In Progress (Leader has NOT joined)
1. I dial into the meeting before joining with my Lync client. At this point the PSTN call is the only participant and the call is being held in the lobby.
2. I can listen to hold music on the PSTN call for as long as I would like and the call will not drop.
3. I join the meeting as a leader from my Lync client.
4. My PSTN call is placed in the meeting.
5. I can see a guest has joined the meeting in my Lync client
6. The PSTN call is connected, but again no audio.
7. Approx. 45 seconds passes and the auto attendant says "I'm sorry, I am having trouble accessing the system right now, Goodbye."
8. The PSTN call drops, but my meeting stays in progress and other participants using the Lync client still work.

This little problem took about a week to figure out, and I did have a ticket open with Microsoft. Hopefully, this article will save you some time. Originally, when our Lync conferencing server was set up we were using Public conferences so each user would always have the same conference ID number. It should also be mentioned that Public conferences is the default setting.

Through days of going through logs with Microsoft we found that this option doesn't seem to work well with PSTN callers dialing in. We had to change the default conference type from public to private.

Here's the Lync Server Management Shell commands I used:

1. Set-CsMeetingConfiguration -AssignedConferenceTypeByDefault $false
This command sets the default meeting type.
True = Public meetings by default
False = Private meetings by default
The Lync default value is True, I had to change it to False.

2. Set-CsMeetingConfiguration -EnableAssignedConferenceType $false
This command indicates whether users are allowed to schedule public meetings. Again, the difference between public and private is the conference ID number. Public uses the same conference ID every time. Private uses a new conference ID every time.
True = Allowed to schedule public meetings
False = Not allowed to schedule public meetings
The Lync default value is True, I had to change it to False.

After changing these Shell commands I could successfully dial into a Lync conference and participate from the PSTN. This little incident just further solidified my love hate relationship with the Microsoft PowerShell. Sure, its easy to make big changes with a single command, but first you have to find and identify the obscure command to use. I could be wrong, but it is my understanding that there is no way to make these changes in the Lync Control Panel GUI.