In the previous two sections we looked at both audio and video bandwidth that can be consumed when using Lync 2013. What we learned is that audio bandwidth hasn’t changed between Lync 2010 and 2013 but video bandwidth on the otherhand has completely changed and needs to be discussed in any deployment of Lync Server 2013.
Lync gives you two options to control bandwidth when designing your Lync 2013 – Call Admission Control (CAC) and Conferencing Policies.
I won’t go too deep into how CAC works but you should know that when assigning Audio and Video session limits in your CAC policy they are of course a cumulative value and not based on an individual steam. So if your CAC policy is to limit to 500 Kbps per session that is all the user will get to support as many video streams as they consume or produce. I note this not because it’s a bad thing just that CAC will do exactly what you expect it to do.
The second option is conferencing policies. There are several new options that allow you to dictate exactly how much bandwidth can be consumed/sent and the behavior of the conference.
Enable participants to join with multiple video streams. This options when enabled allows the client to display the gallery view including the ability to see five active video streams as a given time. When this option is disabled, it reverts back to how Lync 2010 behaved and only shows a single active video stream at any given time. Essentially this limits the amount of bandwidth that can be received.
Allow Multiple Video Streams. This option instructs the client on if it should be allowed to send multiple streams for each video resolution requested as part of a conference. Keep in mind that a client can send up to five streams of video and that the average client will send two streams as part of a client – this average is what was found during the TAP process and of course your environment may be very different. This limits the amount of bandwidth that can be sent.
The next two options are available only via PowerShell.
TotalReceiveVideoBitRateKb – The max video bandwidth policy allows you to define the total amount of bandwidth a single users is allow to consume. This can be very helpful if the user is connected on the far end of a low bandwidth link and you want to make sure a single person can’t consume the entire network.
VideoBitRateKb – This setting allows you to essentially control the max resolution allow by Lync. For example, if you set a person to a max bit rate of 400kbps, this would prevent all HD resolutions. This has some advantages over CAC as it allows me to control bandwidth beyond a single value for the entire site. For example a CAC value of 400kbps might be good for all of employees but you need to allow a single conferencing room to have a value of 5000kbps because you want to allow HD from that system. This scenario would be difficult to design using CAC exclusively unless you carved out the conferencing room to its own subnet. Of course, a roaming person would be the disadvantage. If a home office employee who has no limits visits an office with low bandwidth they may accidently consume all network traffic.
In most deployments a combination of CAC and conferencing policies should be used. Lastly it should be noted that each of these values are defaulted at 50000 kbps, essentially allowing a user to do anything they want.
Its very precise and detailed
Your all the posts on “Bandwidth Planning for Lync 2013” were very much helpful, specifically considering the amount of complexity involved using the “bandwidth calculator” published by Microsoft.
So does a user conf policy take priority over a subnet’s CAC policy? Thinking LRS with user conf policy with different BW settings than the entire subnet CAC limits. However the LRS is in that actual subnet with CAC…just wondering if user conf will win out.