VVX Default Codec issues with Skype for Business

For a while now I’ve seen a randomly occurring call issues with clients using VVX phones.  There would sometimes be one way audio, or mostly no audio at all, but the call was connected.  Mainly with Response Group calls, but more recently I’ve encountered it on VVX to VVX Skype calls.

Fortunately it was so very similar to an issue I hit with Telus Cell phones making calls to Skype4b users who were behind and AudioCodes gateway and a Telus SIP trunks, which boiled down to a codec mismatch involving AMR.  Once the AudioCodes was locked down to only negotiate G.711Mu, problem solved. (I might have blogged about this already…)

Here is a screenshot from my VVX 600, with the default list of codec’s, though not in the default order:

Here is the RTP (Realtime Transport Protocol) mapping from a SIP trace, in bold are matching codec’s:

a=rtpmap:115 G7221/32000
a=fmtp:115 bitrate=48000
a=rtpmap:112 G7221/16000
a=fmtp:112 bitrate=24000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:9 G722/8000

And now one from a Skype for Business server for an inbound PSTN call to the same VVX phone:

a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:115 x-msrta/8000
a=fmtp:115 bitrate=11800
a=rtpmap:13 CN/8000
a=rtpmap:118 CN/16000
a=rtpmap:97 RED/8000

Oh, wait, 115 is a matching code, but the codec is all wrong.  This turns out to be G722.1C (48 kbps) from the VVX list.  According to Polycom forums which reference a page not found anymore, this codec is or is related to Siren14, and definitely not msrta/8000 aka Microsoft Realtime Audio Narrow band.

I did blog about this previously, Response Groups and Polycom VVX’s , but I hadn’t the time to dig in and confirm the offending codec, and I believe I now have.  I was also 3/4 the way through writing this when I realized I’ve already brought this subject to light.

Now from VVX600 to Skype for Business User, again bold are matching codecs:

a=rtpmap:115 G7221/32000
a=fmtp:115 bitrate=48000
a=rtpmap:112 G7221/16000
a=fmtp:112 bitrate=24000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:9 G722/8000

From Skype for Business User to VVX 600

a=rtpmap:104 SILK/16000
a=fmtp:104 useinbandfec=1; usedtx=0
a=rtpmap:114 x-msrta/16000
a=fmtp:114 bitrate=29000
a=rtpmap:9 G722/8000
a=rtpmap:112 G7221/16000
a=fmtp:112 bitrate=24000
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:116 AAL2-G726-32/8000
a=rtpmap:115 x-msrta/8000
a=fmtp:115 bitrate=11800
a=rtpmap:97 RED/8000
a=rtpmap:13 CN/8000
a=rtpmap:118 CN/16000
a=rtpmap:119 CN/24000

In this call, and because of my horrible ordering, I wanted to see if G7221/16000 was actually a viable codec.  Turns out it is, and according to a Jeff Schertz blog post, it’s a Siren 7 variant and nothing to do with G722.

I wasn’t able to test a VVX to VVX Skype call, but I suspect what may be happening in that situation is that the VVX’s are thinking 115 G7221/32000 but the Frontend translates and negotiates 115 x-msrta/8000, but that’s just a theory.

Resolution Time

Clean up time, and I have previously talked about this, but now I have a little bit more backing, and new case scenarios of when it’s impactful.

Siren22, G.722.1C, Siren14 and G.729AB can all be removed.  They’re not going to be used in a Lync/Skype environment, and because of potential cross matching on rtpmap=115 (I don’t know if it’s MS or Polycom issue), G.722.1c has to go.

Order Preference, G.722, G.711Mu (or A depending on your region) and optionally keep G.722.1 (24 kbps).  In the environments where I’ve cleared up the issues, I did remove G.722.1, but it wasn’t till today that I discovered it was actually a viable codec, doesn’t mean I trust it though.

If you happen to have a VVX 600, toast the Video Codecs as well, the camera that came with the phone last worked in a Lync 2010 environment.

If you have a Provisioning server, here is a code snippet to clean up your codec’s:

<WEB video.codecPref.H261=”0″ video.codecPref.H263=”0″ video.codecPref.H2631998=”0″ video.codecPref.H264=”0″ voice.codecPref.G711_A=”3″ voice.codecPref.G711_Mu=”2″ voice.codecPref.G722=”1″ voice.codecPref.G7221.24kbps=”4″ voice.codecPref.G7221_C.48kbps=”0″ voice.codecPref.Siren14.48kbps=”0″ voice.codecPref.Siren22.64kbps=”0″ voice.codecPref.G729_AB=”0″ />

If you still have troubles with VVX to VVX Skype calls, change the 4 to a 0 and get rid of it too.

11 thoughts on “VVX Default Codec issues with Skype for Business”

  1. “If you happen to have a VVX 600, toast the Video Codecs as well, the camera that came with the phone last worked in a Lync 2010 environment.”

    What do you mean by this? The VVX600 camera (btw. is that the same as the vvx500 pluggable camera module?) is dysfunctional in lync2013/sfb environment???

    1. The camera is hardwired with limited codec’s, one specifically is H.263 that is supported with Lync 2010. Unfortunately that codec was dropped from support in 2013 and higher systems, which is why it doesn’t work with Lync 2013 or Skype for Business meetings or clients. It may still potentially work in a VVX to VVX video call, but that would be it.

  2. I’d remove the video codecs from the VVX 500/501s as well. I had to turn off that feature even though there wasn’t a camera attached due to occasional RGS calls being dropped. It’d try to answer with video and just drop the call.

    1. DruW/Korbyn: so in short, the Vvx500/600 camera is “100% money thrown out the window” for Lync203/Sfb platform usage? Vvx and PC client video call scenario-wise I mean. I am pissed off, if Polycom trying to hide this defect, and not being transparent enough to make it clear, that only vvx-to-vvx calls can use their overpriced webcam, not works if non-vvx participant is in the call as well.

      1. Polycom has never supported video calling in Lync 2013 and Skype for Business on the VVX platform and this is (or should be) a well-known limitation in the field. Apologies if this was not made evident to you. As Korbyn stated the current pluggable USB camera unit for VVX 50x/60x models is not capable for supporting X-H264UC or RTV which is used by Lync 2013/SfB clients. It does support standard H.263 AVC video which is used with Lync 2010.

        Although not supported in Lync 2013/SfB environments you can place VVX-to-VVX video calls which use H.264 AVC video between each other.

        1. Jeff: I appreciate your community effort clearing up this confusion.
          However referring to “well-known” limitations is a luxury that this IT industry cannot have. Subject to from where we are looking at it. Yes, it may be a well-known limitation to somebody who breaths VVX phones day and night. But for others seeing the “video” capability marked as “YES” in a VVX-SFB feature sheet would be very confusing, especially if only the “small letters” clarify video is actually only possible between 2 VVX endpoints, not between VVX and non-VVX.

  3. Based on what you’ve written, glad I went to the effort of disabling codecs last year. Thanks for the information. This is the full list that we use as our environment includes Polycom Trio 8800’s.

    1. Doh! XML code block fail.



  4. Hi Korbyn,
    I love the blog and have received a lot of help from this post and others. We have been troubleshooting the Polycom VVX500 / Skype for Business Server Response Group Delay issue for a few months now and installed the VVX 500 – 5.7.0 software update just released. I was told it should address the response group delay. At the same time, I played with the codecs to see what difference the codecs make in the time it takes for a caller to hear the receiver’s voice on answering a call through the response group. It seemed (anecdotally) that the delay was shorter with the G.711Mu-law codec as the top priority. Then I got rid of everything else but G.722 as the second priority. Everything seemed to work well when testing, and we deployed the settings across the company.
    Just a few minutes ago, a call came in and failed twice on answering. I am wildly guessing that my codecs may be the problem, so I added G.711A and G.722.1 (24 kbps) as priority 3 and 4. I will reattempt the test, but I am wondering if you can speak to the effect of codec / codec negotiation on this response delay and if the lack of G.711A or G.722.1 (24 kbps) would cause a failure to connect.
    Thank you again for a great blog!

    1. I’ve not had the time yet to retest the RGS group issue with a factory reset VVX phone to see if the codec issue has been addressed. In my troubleshooting, it was a mismatch of a=rtpmap:115 to two different codecs, one being MSRTA/8000, and G7221/32000 (aka G722.1C). G.711Mu is the North American version of G.711 and G.711Au is Europe and everywhere else I think, as is the primary codec of most PSTN Carriers. Some Cell phone carries sometime inject their onw codec’s, and you have to limit the available codec’s via the Gateway box you use. G.722.1 is the MS Siren compatible codec, which “may” be used primarily in Conference Calls, IF you’ve enabled that in your conferencing settings. It is off by default, and would not be used on a PSTN call, and either G711Mu or Au should be used (depending on if you are NA or Europe). The glitch I saw was rtpmap:115 (G722.1C) would occasionally be attempted, resulting in the call audio failure.

      The delay issue is a result of Response Group calls unfortunately not supporting Early Media and what happens is when the call connects, ALL the pent up media packets get sent at once, spiking the CPU on the phone. The CX600 had a significant problem with this, 10-15 second delays though later firmware did improve this down to 6-8 seconds. VVX400/500/600 series phones have a much more powerful processor and were able to push through this easier. 300’s I still heard about some complaints but not often.

      Generally speaking I try to gauge the customer, if 90% of their calls are PSTN calls, I’ll order the G711 to the top and then G722. If most of their calls are internal, or pc-to-pc calls, I’ll have G722 first then G711, mainly for bandwidth management. G.722.1 (24 kbps) is SIREN7 for MS, and depending on your Lync/Skype server environment, might be disabled and could be done away with.

      In your situation, confirm if your A-law or Mu-law for G.711, though not a problem to have both, just in case. G722 for sure. MS-RTA (narrow or wideband) simply isn’t available with VVX, so keep g722.1c out. I would check on other potential issues you might be having.

      A stretch, but if you are using a AudioCodes or Sonus Gateway, lock down the codec with your carrier. 99% of the calls may come in with G.711Mu, but if they’re a Cell carrier, they might throw in an AMR codec, so you’ll have to run a SIP trace to see what a=rtpmap’s are being offered in the SDP packet.

Leave a Reply

Your email address will not be published. Required fields are marked *