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:
- If a Communicator client is participating in the conference call. Communicator 2007 and 2007 R2 do not support the G.722 codec.
- 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:
- From the main Monitoring Server Reports home page
- 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’
- Click on the hyperlink for the conference, to bring up the Conference Detail Report.
- 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:
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.
Old post, but any idea if this >25ms RTT for SIREN still the same in Skype for Business? I’m guessing this information was only available in the Master course…
Hi Korbyn, I am not sure to be honest, that was many many moons ago.
I do know the SfB client has similar logic – if round trip or other metrics degrade too much it will downgrade the codec. The logic gets so complicated based on where the client is calling, you are better to attach WireShark or use the native Windows client Tracing and find out which codecs are used under specific conditions.
I’ve used the Tracing log to find this out before (as described here: https://www.c21video.com/technical-papers/skype-for-business/appendix-d–how-to-check-pc-for-sfb-codecs). Let me know what you find out! 🙂
Lastly, this is a really good article which describes what the optimal network characteristics are for the SfB client: https://blogs.technet.microsoft.com/skypehybridguy/2017/08/11/assess-your-networks-readiness-for-skype-for-business-online/. If these aren’t met, the client will likely start downgrading depending on the scenario.
Hope that helps,
Hi,
if the Peer-2-Peer call codec is downgraded, does it also remain at low quality for the entire length of the call, or in case the network becomes good, the P2P call can get dynamically back to high quality?
Hi Richard,
In a Lync audio ** conference ** scenario (2+ participants) – which this blog post is focused on – once the codec is downgraded to Siren it remains downgraded for the duration of the call.
Lync peer-to-peer audio calls use the RTAudio wideband or narrowband codec (http://technet.microsoft.com/en-us/library/gg413004.aspx) and I need to refresh my memory on the downgrade criteria – if P2P does any downgrading at all.
I’ll see if I can get that answer for you.
Curtis
Thanks Curtis,
yes I am completely aware what this post is about, so I just wanted to be a little bit offtopic with the P2P scenario 🙂 I am definitely sure Lync/OCS does downgrade P2P calls as well, however I dont have any information -or at least its buried deep inside technet- if Lync can upgrade the downgraded codec in case the network becomes healthy again.
Yes, there is very little information about codec selection in the P2P case (and in general). I’ve updated the blog entry to include some information about the P2P scenario.
In a nutshell Lync-to-Lync audio does downgrade the codec if the average round trip time (RTT) is too high.
What I am not 100% sure of, and your question was specifically about, is whether it upgrades the codec if the RTT goes back to being good (i.e. low). I am told from a credible source that “it will remain downgraded it the RTT remains high” which implies that it will upgrade if the network conditions improve. I will verify that in my lab when I have a chance.
Hope that helps 🙂
Curtis
I confirmed tonight that the codec will be upgrade in a Lync P2P audio scenario if the RTT improves.
Thanks for the update, somewhere back in my mind I definitely had such a memo, back from the old OCS days 🙂
[…] scenarios can also trigger a fallback to Siren regardless of the client types in attendance. A previous article from Lync MVP Curtis Johnstone covers this specific behavior in more […]
[…] Выбор кодека для конференций […]
[…] Audio Codec Selection in Conferences | Inside Lync Posted on July 9, 2012 by johnacook http://blog.insidelync.com/2012/06/the-lync-2010-client-audio-codec-selection… Share this:StumbleUponDiggRedditLike this:LikeBe the first to like […]
[…] affect the bandwidth consumed by that client and the audio quality. See my previous blog entry on The Lync 2010 Client Audio Codec Selection in Conferences for information on how the client adapts to changing network […]
[…] (64kbps) or Siren(16kbps). Read MVP Curtis Johnstone’s post on what codec is used when: http://blog.insidelync.com/2012/06/the-lync-2010-client-audio-codec-selection-in-conferences/ For more information on Media Traffic Network Usage see this TechNet article: […]
[…] explaining a behavior change in the audio codec selection by the Lync 2010 client in conferences: http://blog.insidelync.com/2012/06/the-lync-2010-client-audio-codec-selection-in-conferences/ Share and […]