The Lync 2010 Client Audio Codec Selection in Conferences

An update was recently released to knowledge base article 2614343 which describes a Lync 2010 Client update from November 2011. This update enabled the use of the RTAudio narrowband codec for WAN communication to a Lync 2010 Mediation server without the use of Call Admission Control (CAC).

What is more significant about this update (imho), and easily missed, is that this Lync 2010 client update also affects the audio codec selection used by Lync 2010 client during a conference. The change in codec selection during a conference wasn’t previously advertised in the knowledge base article, so it was updated to reflect that. A more detailed description of the change is described in this post.

The default behavior of the Lync client in audio conferences has always been to use the G.722 codec and to downgrade to the Siren codec in either of the following situations:

  1. If a Communicator client is participating in the conference call. Communicator 2007 and 2007 R2 do not support the G.722 codec.
  2. If the Lync client detects that available bandwidth is too low for any applicable Lync Call Admission Control (CAC) policies.

The change in codec selection introduced in the November 2011 Cumulative Update (http://support.microsoft.com/kb/2514982) adds a third scenario which which will cause the Lync 2010 client to downgrade to the Siren codec:

3.  If the Lync client detects a network round-trip time of greater than 25ms.

This scenario was aimed to help Lync customers that do not have CAC deployed. Knowing the exact behavior of the end-points (clients) involved in an audio call or conference is really important when troubleshooting audio quality issues – IT Professionals need to make sense of the associated data is in the log files and QoE records. It is also important for gauging the network impact of Lync.

Here are some additional important points to consider about this behavior change in the Lync client:

  • The Lync client continuously checks for an average network round-trip time of > 25 ms, and it must exceed this value for a specified duration (not just a single occurrence) for the codec switch to happen. The exact window of sampling depends on many factors.
  • The 25 ms was an initial value aimed at detecting a minimal network quality to support G.722. The exact measurement could change in future updates.
  • Once the codec is downgraded to Siren, it remains downgraded for the duration of the call.
  • The codec that is recorded in the associated QoE conference database record is the codec in use at the end of the call.

It is also worth noting that the Microsoft team has engineered the Lync client so that application and desktop sharing does not impact audio, so that is independent

If you have the Lync Monitoring role deployed and access to the Quality of Experience (QoE) metrics, the codec used by all participants is available in the QoE User Activity report. You can view this report as follows:

  1. From the main Monitoring Server Reports home page
  2. Choose User Activity report
    • specify the participant URI in the ‘User URI prefix’ field
    • specify your date range and narrow the results by specifying an activity type of ‘Conference’
  3. Click on the hyperlink for the conference, to bring up the Conference Detail Report.
  4. Under Conference Modalities, click “Media quality” link beneath the participant you are interested in.

Thanks to Tom Pacyk for helping locate where the audio codec is displayed in the QoE reports.

Here is a sample screen shot from this QoE report showing the a participant codec that has been downgraded to Siren:

image

The Lync Peer-to-Peer Behavior

This blog article was initially focused on the behavior of the audio codec in the conference scenario, but here are a few notes about the P2P scenario.

Lync peer-to-peer audio calls use the RTAudio Wideband or Narrowband codec (http://technet.microsoft.com/en-us/library/gg413004.aspx).

The audio codec can be downgraded based on a number of reasons such as the available bandwidth, the server policy, the remote client codec support (e.g. Communicator 2007 client), or the remote Gateway not supporting wideband.

For the available bandwidth reason, the Lync client will detect and use Round Trip Time (RTT) averages and if the RTT is too high, it will downgrade the codec to RTAudio narrowband.  If the RTT remains high throughout the duration of the call, it will remain downgraded.

Be Sociable, Share!

12 comments to The Lync 2010 Client Audio Codec Selection in Conferences

You must be logged in to post a comment.