Audio quality in WebClient vs desktop on same machine

[kernelpanic25]

Relatively new to 3CX, configuring a server for deployment in a month or so. I have handsets (Yealink T46S) that have excellent audio quality both internal and external calls. Extensions, SIP and general settings all have G711u/PCMU as priority and Wireshark shows a constant stream of RTP G.711 PCMU packets when placing a test call to an outside phone.

Using my laptop (hardwired, same network as PBX, WAN for PBX is a DIA fiber trunk), the now discontinued macOS desktop softphone also has good audio quality. Wireshark shows constant stream of RTP G.711 PCMU packets when placing a test call to an outside phone.

However, when using the Chrome extension on the same laptop on the same network, audio quality is terrible. Calling the same external phone system auto attendant used in the other tests gives choppy, robotic, tinny audio. Wireshark shows that the RTP packets are using the G.711 PCMU codec as intended. There are however UDP packets of non constant length between every single RDP packet. I am a novice in Wireshark, but so far this is the only evidence I have found to explain any difference between the Chrome extension and the IP phone or desktop softphone.

Short version is the chrome extension audio quality is unusable for deployment. Any thoughts or next steps? Thanks!

 

[kernelpanic25]

Additional info - audio quality from WebClient using *777 is also low quality. PBX provides audio is enabled for SIP but disabled for extensions. Also, when I am quality testing from the WebClient by calling an external, non-3CX auto attendant, it sometimes does not properly respond to my extension dialing, so at least some of the DTMF packets are being dropped. This does not happen from deskphone or desktop softphone.

 

[JohnS_3CX]

Hi Joey,

From your description I can pick out a few things that may be causing this.

1. The webclient uses Opus predominantly (it's based on the WebRTC standard), so when it calls any destination that is not using Opus as its primary codec, the PBX needs to transcode the audio to whatever the recipient side has*

2. Make a call from Webclient to Webclient (without recording enabled or PBX Delivers audio on either of the two extensions). This test should make an Opus to Opus call which is the best quality available, and will now mainly be limited by the headset and mic being used. If bluetooth headsets are being used I would expect a drop in quality similar to early GSM. If relatively-good quality wired headsets are used, then you should instantly notice the difference.

3. DTMF tones were not always delivered when you call an external destination (from webclient only) that does not support RFC2833 standard DTMF. This should be addressed in our next update.



* = Just to clarify, Opus is the highest priority, not the only codec. G711 and G722 are supported amongst others.

 

[Grant Moxom]

@JohnS_3CX This is the same issue I have - the problem is as you said that OPUS is the priority codec for outgoing calls. This means all calls get automatically transcoded to G711 which causes serious quality loss in the webclient. Incoming calls use G711 and are great quality, outgoing use OPUS, transcode and terrible quality. Is there ANY way you guys can change this? It makes the web client impossible to use as the quality loss is significant. It's ok for basic calls, but all day calls you have too many people unable to effectively hear. And I really want to use the webclient!

 

[JohnS_3CX]

@Grant Moxom at the moment no, but the future may hold some changes.

 

[kernelpanic25]

@JohnS_3CX I tried a call webclient to webclient and that audio was fantastic, it is definitely not a headphone issue. I have tested with Plantronics C5220s with Hub installed and integration recognized by 3CX webclient, and Sennheiser Game ONE. Wireshark doesn't seem to show protocol, just a bunch of UDP packets, but excellent audio. Still tinny and terrible calling out to other systems though due to the transcoding. Can anything be done to improve transcoding performance? This is on a quad core 3.7GHz on premise server with 32GB of RAM and the Dashboard usually only shows 1% CPU utilization during test calls. Not sure why it wouldn't be able to transcode better while still maintaining acceptably low latency.

Also re: the DTMF issue, it does not appear to fail all of the time, but I have had failed tests using the webclient but no failed tests using a deskphone or the desktop softphone. The other very annoying thing about the webclient and DTMF dialing is that once the call has begun and you bring up the keypad, you can no longer use the number keys on your keyboard, but have to mouse click the numbers instead. Definitely a feature request there!

 

[SteveITS]

Interesting. I am not saying you're wrong, but I just made some test calls to one person and the quality difference was perceptible but not very, at least to either of us. We're using G.711 U-law/PCMU as the primary codec everywhere (trunks, Settings/General, extensions).

 

[JohnS_3CX]

It's perceptible but it can sound different to each of us based on the mic of the other side, the speaker on our side and above all the individual person's auditory perception. So each person's opinion of what is acceptable will vary on this point, even when comparing the exact same scenario on the exact same hardware.

 

[Grant Moxom]

@JohnS_3CX @SteveITS it also depends on the trunk you're using.
For example I use Twilio as my trunk. Twilio "Accepts" OPUS - however in reality it doesn't and just transcodes it. That transcoding happens by Twilio and I find the transcoding introduces a lot of hiss on "s" sounds and makes the quality very noticeably worse on both sides. On users calling 6 hours a day this is VERY recognisable.
I'm not sure what would happen if the transcoding happened in the 3cx end - perhaps it is a better transcoding - however it's impossible to make that happen I think because twilio DOES accept the format.
Again though it DOES work perfectly if someone calls me and I pickup on the webclient. Do you find the same @JoeyS - if you call your webclient from a mobile phone (a standard call) is the quality significantly better?

 

[SteveITS]

Ah. In the SIP trunk, options tab, can you remove Opus? You should be able to control your outgoing codecs... That could well be relevant since our SIP only supports G.711 U-law and G.729 so those are the only ones listed on our SIP trunks.

 

[Grant Moxom]

Ah. In the SIP trunk, options tab, can you remove Opus? You should be able to control your outgoing codecs... That could well be relevant since our SIP only supports G.711 U-law and G.729 so those are the only ones listed on our SIP trunks.

I already did that but the webclient ignores all codec preferences- no unfortunately this is a known limitation with their implementation of WebRTC - the answer I've had so far is that WebRTC defaults to OPUS and they can't change that - but WebRTC DOES let you change your default codec - there's a flag to select codec priority. So it SHOULD be possible.