Solved Audio quality issues - hiss / static / incoherence with every codec and config I've tried for all call types

[lucasco]

I've tried numerous different configurations over the last few months, and cannot seem to make the audio on calls meet even basic quality levels. I have done the following:

1) Implemented 3CX as a Debian based VM on both Hyper-V and MS Azure.
2) Implemented 3CX on a Raspberry Pi 4B with 8GB RAM and fast SD card, which is the current main test machine now.
3) In each instance of configuration I have relentlessly played around with the various codecs to see if at least acceptable quality can be obtained.
4) Connected to the system with both Snom D345 handsets (both locally and via STUN, we have two handsets for testing) as well as the latest Windows and iOS clients.

Whenever I make a call from any device to another, or out via the SIP Trunk (which I've configured) to an external landline phone or mobile, the quality is at best 'fuzzy' with static everytime I talk or the other person does, and at worst it sounds like I have a strong lisp, as parts of the words are actually being lost or 'rounded off' in tranmission. To be clear, this problem is even evident when calling between the Windows 3CX client and iOS client even when ONLY allowing them to use the Opus protocol (which I understand should be approximately CD quality sound?).

Is there something I'm missing in the wider configuration of the system beyond just setting the codecs? Perhaps there are settings for controlling wider compression and echo cancellation, etc?

I really, really want to love 3CX and make it my firm's new phone system, but at present the quality is so bad and unpredicatable that this isn't going to happen until this can be addressed. I'm happy to be told I'm doing something wrong, but from extensively reading the guides and manual I have no idea what, I'm just utterly frustrated after months of trying to get this to work properly!

Many thanks to anyone who can advise

 

[cobaltit]

You're doing something wrong! There, are you happy?

Seriously though, if 3CX caused audio issues then you'd see tons of complaints so it's something unique to your environment.

I'd start from scratch using a 3CX trial license in the cloud (assuming you are in a supported location), 3CX client on the iPhone and test that first.

 

[lucasco]

Thanks for your reply

Yeah, I've genuinely started to wonder if my sanity is intact.... Before posting on here I've literally been battling this on and off since about April as I thought it must be something I'm doing wrong. As above, lots of different setups have been tried. And to be clear, I've started totally from scratch at least 4 times on different platforms (Azure, Hyper-V, Intel PC and now Raspberry Pi have all been tried, some with multiple new setups).

Do you have any thoughts on what area I could be looking at? Are there any areas in the web admin to tweak things like echo cancellation, etc? I have found a few other posts with people talking about audio distortion issues, but these didn't quite seem to be exactly the problem I'm facing.

Cheers

 

[AWS2P]

OPUS is an heavy wide band codec and perhaps not alwyas supported on devices.
So fisrt try your test with most common codec like G711 U or A

To apply G711 you need to change codec order everywhere,in extensions, App, Trunk and set G711 in first . Then you need to reprovision phones to apply new order, then do a call test.

 

[N_G]

You say "the SIP trunk". Is it a supported and tested premium quality SIP trunk? As cobatit suggested, use a hosted by 3CX, connect android or iOS app. Leave defaults and check call quality.

 

[JohnS_3CX]

Hi @lucasco

I can give you some good practices advice so you can troubleshoot. In this example, we will attempt to use a single codec across the board and see if this will help you. We will use PCMA as a preference, since this is a widely used codec

1. In the PBX Settings > General you can set PCMA/PCMU at the top like so:


2. In your SIP trunk you can also set the codecs like this, provided your trunk supports them which most do.

Note: ignore the different name, PCMA = G.711 A-law (it's just the technical name of the same codecs)



3. In each of your extensions, under their Provisioning > 3CX App you can also set the priority to be the same:


This should now practically ensure that PCMA (aka G.711 A-law) will be used across the board.

4. You should delete and reprovision your 3CX Windows client and 3CX Mobile app accounts to ensure they receive the codec order too.

5. Now when you make a call internally extension-to-extension you should have clear audio (G.711 is a fairly good codec, even though not CD quality) and I would not expect to hear any noise or static at all. If this is ok, you can then proceed to make an external call too, and again you should hear no noise/static. Then you can receive an incoming call and confirm that the quality is again the same regardless of who initiated the call

Note: do not enable recordings or PBX Delivers Audio under your extensions Options menu for now


Let us know how it goes, and especially if the internal calls sound better vs trunk-based calls!

 

[lucasco]

Thanks Guys, appreciate all your input on this.

JohnS - particularly useful, that's exactly the kind of baseline I wanted to check-off against. I'm certain I've tried the configuration with only the PCMA codec in play across all areas you've listed previously, but I now can't help but wonder whether the issue that stopped this working at the time was being caused by a secondary problem that is now no longer present in my test implementation on the Raspberry Pi install.

Also, to take your above suggestion to the extreme, I've implemented so that ONLY the PCMA protocol is usable between all handsets and softphones, not just priority 1, just in case it was not following the dictated priority before. Perhaps by forcing it to only use the one option, this is helping, and it's the first time I've done this with this specific protocol (whereas I have prioritised it before now)

I've run tests between the Snom, Windows client and iOS app (having reprovisioned them all and checked they only display the one protocol option), as well as out on the SIP Trunk, and the quality now seems to be acceptable. It is a bit more 'pixelated' than I'm used to hearing on our ISDN legacy phone system, but the hiss appears to be gone. So thanks very much for the baseline that helped with this, very appreciated.

Before closing off the question I'm going to run a lot more tests with the present config, including making a few more proper calls to outside lines to my colleague's normal mobiles. Then I'll move on to trying to re-introduce wider band codecs such as G.722 and Opus. But it's looking promising and I'm grateful for this info. I will report back on here in the next couple of days.

Cheers very much!

 

[AWS2P]

you can use G722 for internal calls really good quality sound

 

[JohnS_3CX]

You are welcome and I'm glad it was helpful in your testing.

Please note that the provider you use can also make a difference, especially if external calls tend to sound different than internal calls (even when the same codec is used across the board). Depending on where/how they route calls, they may get transcoded along the way and change the audio characteristics.

Our supported providers should give you good and reliable quality, in case you shopping for a new provider, and they have been tested and verified to work well with 3CX through our interop program (where any interested provider can also join) https://www.3cx.com/partners/voip-providers/

 

[lucasco]

Thanks, John.

I've done very extensive testing over the weekend, and have made several conclusions.

I'm still convinced that at points I've had the codecs all set to PCMA / G711A and had inexplicable distortion issues. I've no idea why, but the fact it's occured on multiple clean setups is a bit weird. Having followed your baseline settings it has continued to be consistently good on G711A on the present setup, so thank you again even if I don't know what's changed in the background of the system.

Re the SIP Trunk, indeed the provider (Dial9) is not officially supported, and I've always allowed / assumed that any external calls from 3CX having issues should be blamed on the SIP Trunk first. Calls out through the SIP Trunk when all phones are set to G711A (the only protcol the 9Dial SIP Trunk supports) works adequately enough. When using different protocals locally (for example G729 between Snom handsets) calling out through the SIP Trunk works, but the quality gets notably worse. I can only assume there is some loss in the conversion between different protocols on the fly.

In addition, having tested G722 and G729 extensively internally, whilst the quality is higher than G711A in some ways, there is a little more hiss in the background. Not anywhere near like before, but it actually makes me favour the lower definition G711A. It might be a lower bit-rate but the hiss now seems to be gone altogether when using solely this protocol.

In the immediate, I'm going to be ordering up a Beronet ISDN to SIP Trunk convertor (I believe this is fully supported by 3CX) as we're stuck on our ISDN contract for the best part of the next year. When we do come to go the proper SIP Trunk route I will be signing up with a 3CX certified provider. 9Dial are very cheap and great for at least testing purposes so I don't want to knock them, but I'm sure a provider like Gamma are going to offer higher quality protocols and connections.

Thanks again for your help - I think it's coming together now and just wanted to share what I'd tested for anyone else battling with sound quality issues

Cheers!

 

[AWS2P]

If I was you I'll think twice before buying anISDN gateway for only one year. GW is not low cost device so perhaps you are better to pay to terminate your isdn contract and subscribe to SIP provider directly

 

[lucasco]

Thanks aws2p.

I massively oversimplified our reasons for going with this as I didn't want to detract from the topic too much (merely to state we won't be using a Dial9 unsupported SIP Trunk in production, but something that is supported).

Being locked into the contract is part of the issue with our ISDN, however the cost of the remaining ISDN contract is actually not much less that the cost of the Beronet unit. But there's a lot of other considerations relating to our existing system and infrastructure, with the need to be able to trial and test things before making the transition, and the Beronet unit will buy us considerable flexibility at not a great cost in real terms. It will allow us to test 3CX and run it in production with ISDN, then manage the transition to proper SIP Trunking in a far more leisurely manner. Given the problems created by COVID this will be a far more manageable approach too, as we don't need to entertain getting a new physical line install done at this point.

It's also worth noting the unit I'm going for has 2 x analogue ports (in addition to 4 channel BRI ISDN), so even when we switch from the ISDN, the plan is to use the unit permenantly for receiving faxes - but that's a project that'll be long down the road!

Cheers

 

[AWS2P]

You're always able to contract commercial offers for analog or ISDN lines ?
In France that's no more available, SIP is the only one way to go

 

[lucasco]

Yes, in the UK ISDN is still available and will be supported until 2025. Not that I'd promote anyone getting it! BT are not looking after the infrastructure so well and we will look to move from it to a SIP Trunk provider in summer 2021 Because of the deal I negotiated some years back, when we finally do move to true SIP it probably won't actually save us any money, but it will obviously be a superior setup

 

[lucasco]

Thanks for all the input on this. Repeating a modified version of the baselines suggested by JohnS_3CX in post #6 ultimately led to the 3CX server behaving, so if this question can be marked off as answered by admin staff and closed for further contributions that would be great. Cheers!