GXP 2170 after 20Min bad audio

[Edwin Hop]

Using the Grandstream GXP2170 via STUN on 3CX. after ~20min on a conferance box the audio will be bad for 1minut, after that the audio is good for ~4min then it will be bad for 1minut, and good for ~4min repeated. We analysed the Audio streams in Wireshark but don't hear bad audio. We updated the fireware to the lasted 127 version but, problem still exist. Using a Yealink T42S in the same way, we don't have the bad audio problem. What can be the problem?

 

[JohnS_3CX]

Hi Edwin,

Was the packet capture done on the server side by any chance?

It might be best to perform the capture on the phone with RTP Packets option enabled to hear what the phone actually received or at least Wireshark on the same LAN as where the phone is locally installed since the PBX server may be sending good audio but we can't know for sure what reached the phone. Also were the problematic calls done with the same codec for both the GrandStream and the Yealink?

 

[Edwin Hop]

We did capture the RTP packets in the line to the phone. (mirror port on a switchs) On the grandstream and the Yealink the same codes are used 711.ulaw, but we tested it with 711.alaw on the grandstream but with the same result. after ~20min the audio goes bad.

 

[JohnS_3CX]

If the packets have been confirmed to have reached the device, and if the Yealink does not show the problem at the STUN site, I would suspect the GrandStream device is facing some issue when decoding and playing the audio, and I would expect this should most likely happen when you test the device locally too.

In this case I would reset the device and reprovision it via STUN to see if the problem persists. Then I would take the device locally to where the PBX is installed and see if the same issue continues (to see if we can isolate the problem being the device).

If you are on V15.5SP6 then the latest firmware you should have installed is 1.0.9.102

https://www.3cx.com/support/phone-firmwares/

 

[Edwin Hop]

We are running V15.5SP6 and have the same issue if we use the latest 3CX firmware 1.0.9.102 for the GrandStream. We tryed 711u, 711a, 722, 729 as codec's but all have the same issue. If we connect the GrandStream direct without STUN we don't see the ~20min bad audio issue. We tried this with several brand new GXP 2135 and GXP 2170 all with the same issue. Can the issue be related to a routing or firewall issue?

We tried this on two different 3CX installations both running on VMWare, one behind a Ubiquity firewall and one behind a Endian firewall. both with forwarded ports: 5000,5001,5060, 5090, 9000-11000.

This issue is easy reproducible, by calling 7000 and connect to the conference box an just listen to the wait audio. After ~20min the audio sounds bad.

The audio file attached is recorded after ~20min you can hear that after 28sec the audio returns to normal quality.

 

[Evolute IT]

We are running V15.5SP6 and have the same issue if we use the latest 3CX firmware 1.0.9.102 for the GrandStream. We tryed 711u, 711a, 722, 729 as codec's but all have the same issue. If we connect the GrandStream direct without STUN we don't see the ~20min bad audio issue. We tried this with several brand new GXP 2135 and GXP 2170 all with the same issue. Can the issue be related to a routing or firewall issue?

We tried this on two different 3CX installations both running on VMWare, one behind a Ubiquity firewall and one behind a Endian firewall. both with forwarded ports: 5000,5001,5060, 5090, 9000-11000.

This issue is easy reproducible, by calling 7000 and connect to the conference box an just listen to the wait audio. After ~20min the audio sounds bad.

The audio file attached is recorded after ~20min you can hear that after 28sec the audio returns to normal quality.

This can be caused by multiple phones connected by STUN. If so, try using a SBC instead. Multiple phones over STUN in the same network causes issues with NAT.

Also, try updating the firmware to 1.0.9.127. It is the latest 3CX version for GXP2170. (I use v16)

 

[Edwin Hop]

We installed a new 3CX server via the 3CX PBX express installer on the google cloud. Attached a Grandstream GXP2170 via STUN and started the test. After ~20min connected to the conf box, the same issue with bad audio occurred. The bad audio lasted ~1min after that the audio quality was good again.

 

[Evolute IT]

We installed a new 3CX server via the 3CX PBX express installer on the google cloud. Attached a Grandstream GXP2170 via STUN and started the test. After ~20min connected to the conf box, the same issue with bad audio occurred. The bad audio lasted ~1min after that the audio quality was good again.

Do you have SIP ALG activated in your firewall on the phone side? If yes, disable it.

 

[cobaltit]

So multiple STUN phones or SIP ALG wouldn't cause audio problems. Both of those would cause one-way audio type issues but audio quality comes down to a couple of things:

• Insufficient resources on the PBX
• Network quality problems (including insufficient resources on any devices in the network path such as a overloaded firewall)
• Occasionally it can be something with the handset itself although that is rare.

If this is only happening with the Grandstream phone and not the Yealink then I think you have your answer; use Yealink phones.

 

[Edwin Hop]

Just for completion. We tested the issue also on the v16 beta (google cloud) with the new firmware on the phone. But same issue after ~20min audio goes bad.

 

[JohnS_3CX]

Using the wireshark capture, you can also run the RTP Stream Analysis tool which will give you some more insight for jitter, packer loss, and sequence errors

 

[Edwin Hop]

No packet loss, no sequence errors, audio in the Wireshark capture on line to the phone is good. But the audio sounds bad on speaker of the phone.

 

[Evolute IT]

But the audio sounds bad on speaker of the phone.

When you say "speaker", you mean The speakerphone?

If so, have you tried the handset? Does it sound as bad?

Try changing the Ethernet cable?

If nothing works, contact Grandstream or your distributor for a replacement. It sounds like a defective unit.

 

[Evolute IT]

If this is only happening with the Grandstream phone and not the Yealink then I think you have your answer; use Yealink phones.

I don't want to be rude, but it may simply be the customer's choice to use Grandstream or maybe they already had these phones. You can't tell someone to not use a product, specially since GS phones are supported by 3CX.

It may simply be a defect, it happens.

 

[cobaltit]

Actually I can tell anyone anything I want, it's called freedom of speech . That being said I didn't tell him he can't use or not to use Grandstream. In my post I did mention it could be a phone defect. But if he has a Yealink phone and a Grandstream phone and they are operating in an identical environment where one works and the other is having trouble it's sometimes easier to go with the one that works and works consistently. Now if the OP has 100 Grandstream phones deployed then it's probably worth trying to resolve the issue.

Historically Yealink phones generally just work. The budget phones like Grandstream and Fanvil just don't work as consistently as the Yealink phones. Don't get me wrong I have some Grandstream and Fanvil phones deployed but they definitely weren't my phones of choice.

 

[Edwin Hop]

We think we found the problem, and fixed it. The 3CX default template for grandstream phones is setting the jitter buffer to a fixed size, after changing the jitter buffer to adaptive the problem doesn't exist anymore.

 

[Evolute IT]

We think we found the problem, and fixed it. The 3CX default template for grandstream phones is setting the jitter buffer to a fixed size, after changing the jitter buffer to adaptive the problem doesn't exist anymore.

Do you have QoS enabled on the network? If not, you're issue might be there.

Because 3CX uses fixed jitter for a reason. Using custom settings you won't be supported by 3CX (not fully).

 

[cobaltit]

We think we found the problem, and fixed it. The 3CX default template for grandstream phones is setting the jitter buffer to a fixed size, after changing the jitter buffer to adaptive the problem doesn't exist anymore.

Good find, thanks for sharing. As I understand it the manufacturer provides 3CX the firmware and template and they test it for compatibility. So if it is set to a fixed buffer in the template that was a Grandstream choice. I'm going to check to see what the Yealink is set to.

 

[cobaltit]

So I just checked the stock templates:

Grandstream

<!-- Jitter Buffer Type. 0 - Fixed, 1 - Adaptive. Default is 1 -->
    <!-- Number: 0, 1 -->
    <!-- Mandatory -->
    <P133>0</P133>

Yealink T4x

#Configure the type of jitter buffer; 0-Fixed, 1-Adaptive (default);
voice.jib.adaptive = 1

Why the Grandstream is set to fixed (especially when it is supposed to be adaptive by default) and the Yealink is set to adaptive is a question for 3CX.

@YiannisH_3CX Can you ask the responsible team to look into this?

 

[Evolute IT]

So I just checked the stock templates:

Grandstream

<!-- Jitter Buffer Type. 0 - Fixed, 1 - Adaptive. Default is 1 -->
    <!-- Number: 0, 1 -->
    <!-- Mandatory -->
    <P133>0</P133>

Yealink T4x

#Configure the type of jitter buffer; 0-Fixed, 1-Adaptive (default);
voice.jib.adaptive = 1

Why the Grandstream is set to fixed (especially when it is supposed to be adaptive by default) and the Yealink is set to adaptive is a question for 3CX.

@YiannisH_3CX Can you ask the responsible team to look into this?

I tried setting mine to Adaptive too. It seems to give me a less laggy voice and music.

Might worth testing in depth with Grandstream!