A previous article entitled Media Codes in Lync 2013 covered the introduction of the SILK narrowband and wideband audio codecs from Skype into the Lync 2013 desktop client.  Since posting that article Microsoft has also added SILK support into the various Lync 2013 mobile clients, which means that some call scenarios like mobile-to-mobile Lync calls are already using SILK Wideband as the primary audio codec for those calls.

While this new behavior for Lync audio calls is not made evident directly to the user by the client it can be validated by reviewing the Peer-to-Peer Session detail reports from the Lync Monitoring Server.

The following image shows only the relevant data clipped from the Media Quality Report of a test audio call between an iPhone and an Android phone both running the latest Lync 2013 mobile clients.

Both audio streams are reported as using SILKWide which is the wideband SILK audio codec.  A Sample Rate of 16000 denotes wideband codecs while a value of 8000 means it is a narrowband codec. (There is one exception to this rule which is called out later in this article).

To understand how SILK was used for this peer-to-peer Lync audio call a capture of the SIP messages generated during the call setup will show which audio codecs the clients advertise to each other.

The Session Description Protocol (SDP) data in a SIP INVITE message sent by a 2013 mobile client currently advertises the following codec capabilities for receiving audio streams:

m=audio 37124 RTP/AVP 104 9 111 0 8 103 97 13 118 101
a=x-ssrc-range:2668972645-2668972645
a=rtcp-fb:* x-message app send:dsh recv:dsh
a=rtcp-rsize
a=label:main-audio
a=x-source:main-audio
a=rtpmap:104 SILK/16000
a=fmtp:104 useinbandfec=1; usedtx=0
a=rtpmap:9 G722/8000
a=rtpmap:111 SIREN/16000
a=fmtp:111 bitrate=16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:103 SILK/8000
a=fmtp:103 useinbandfec=1; usedtx=0
a=rtpmap:97 RED/8000
a=rtpmap:13 CN/8000
a=rtpmap:118 CN/16000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

As explained in the previous article the m=audio line declares all of the client’s supported audio codecs and lists them each by their payload type in order of preference.  The other client in the conversation also sends its own list in return.

The first payload listed is 104 which is SILK wideband, as denoted by the 16000 clock rate.  When negotiating an audio call with another Lync endpoint which supports this same codec it will be used by default.  A mobile to mobile or a mobile to desktop client call would utilize SILK wideband unless some other event (like constrained bandwidth) triggers the selection of a more appropriate (and less-preferred) codec.  Additionally the use of in-band Forward Error Correction (FEC) is defined (useinbandfec=1) after the initial declaration of the SILK codecs.

Yet a mobile client joining a conference call, thus negotiating media directly with the Lync AVMCU, will not use SILK as it is not currently supported by the Lync AVMCU.  That call would instead leverage the first compatible codec which happens to be the next in the list: G.722 (9).

Looking closely at the list above shows that these mobile clients do not include Real-Time Audio (RTA) which could be construed as an indication of a move away from RTA as the primary audio codec for Lync peer calls.  In head-to-head tests SILK has consistently outperformed the other Lync wideband audio codecs.  Although the wideband version of SILK requires slightly more bandwidth than the wideband version of RTAudio it is much less than G.722 and also can perform better is less than ideal network conditions. That makes it a great option for the mobile clients which are at best on a Wi-Fi network and at worst using a cellular data network; both of which are lossy networks.

Also note that (as explained in this article) G.722 is incorrectly declared in SDP as a narrowband codec with a clock rate of 8000Hz even though it is truly a wideband audio codec.

The following table compares the quoted bitrates for the different wideband audio codecs in peer-to-peer sessions only. 

Each value in the table includes the column before it as additional overhead, like when Real-Time Protocol (RTP) control messages and Forward Error Correction (FEC) data are stacked on.  When planning for media bandwidth on the network it is best to use the FEC value for any calculations as there is also some level of packet loss or delay in wireless networks to contend with.  Using only the payload value is not indicative of the actual bandwidth which could potentially be consumed by a single stream.

Be aware that to-date Lync to Skype audio calling is still using the v1 gateway model explained in the previous article so audio sessions between the Lync mobile clients and Skype clients are not yet utilizing SILK in a direct peer-to-peer model in the way that Lync peer calls function.  The v2 model for Skype interoperability with Lync 2013 is still pending a release form Microsoft.