Codec-Order

[MichaHidd]

I know there are a lot of topics that deal with the order of codecs.

Since the sound is very bad when transcoding from G711 to G722, I would configure the 3cx system in such a way that I get the following result:

The (external) caller/called party supports G722, then the call is to be conducted continuously with the G722 codec. If G722 is not supported, the G711 codec (PCMA/PCMU) should be used throughout.
Internal calls should only be coded in G722.

So far, I either get the result that all calls are carried out with G711, or the G711 calls are transcoded in G722, and then the sound is very tinny.

 

[eddv123]

Unfortunately my German isn't as good as your English, however what I can say about codec order is that you need to be careful of which you select based on what the provider supports.

For example GAMMA in the UK only support G711 and G729 (and only G729 if you set it as so) where some providers (Voxbone for example) support a whole suite of them.

Ensure you check what you set on 3CX and what is supported by the provider. If there is a codec incompatibility issue most likely the provider will respond with a "488 not acceptable here".

 

[MichaHidd]

Sorry! Now I have translated it into English.
My Provider supports G.711 A Law und G.711 U Law and G.722.
I want to use G.722 continuously, if the remote station also uses G.722, otherwise G.711 A-Law/U-Law.

 

[eddv123]

So you can set your codes on the extensions on the PBX and the trunk for this provider as such. It should flow down from top to bottom, check in a Wireshark capture also to see if the settings are being adhered to by both parties also.

 

[JohnS_3CX]

Please note that if you have recordings enabled or PBX Delivers Audio on the extensions taking part in the call, then transcoding will also take place.

 

[AWS2P]

Do you have enough bandwith for G722 with external calls?
To avoid transcoding and stay in audio quality, set codec in prefered order expected by your sip provider, do this everywhere, extensions, app, webclient

 

[MichaHidd]

Order: G722-G711a-G711b
But then I get the following result when a call comes in (or out) with G.711:
Povider -- 3cx = G.711
3cx - extensions = transcoding to G.722 which sounds bad

bandwith QoS ,Min 10 MBIT
Extension: PBX Delviers Audio is disabled
SIP-Trunk: PBX Delivers Audio is enabled

 

[AWS2P]

even if your trunk is set as order: G722-G711a-G711b , it's not sure at all an incoming call use G722 as first codec, perhaps on caller side G722 is not an option.

 

[MichaHidd]

I was hoping that if someone on the caller side uses G.711, it will be passed through without transcoding. But I haven't found a way to stop transcoding yet.
When I would set G722-G711a/b only for the Trunk and G711 a/b - G722 for the extension and the caller side use G.722 in would be also transcode to G711 a/b.

 

[JohnS_3CX]

Hi @MichaHidd

Firstly, do you use recordings or need to have PBX Delivers Audio on any extensions at the moment?

 

[MichaHidd]

I dont use recordings and I don't think, that Ihe PBX has to deliver audio to any extensions.

 

[JohnS_3CX]

Also because this has been discussed before, you may want to read an older thread where I go into more detail on the how/when transcoding takes place and suggest a G.711-across-the-board solution that will minimize the number of scenarios that transcoding takes place. It is not in favor of HD codecs, but it will improve the audio overall since transcoding will not be taking place.

https://www.3cx.com/community/threads/call-quality-transcoding.67494/page-2#post-293490

 

[MichaHidd]

That means I have to do without HD if I always want to get a reasonable sound quality.

Otherwise 3cx is a top solution, but other software solutions do this much better, as cparker_RCT has already complained.

So as a wish for improvement for 3cx
either
the quality of the transcoding from G711 to G722 is significantly improved (the transcoding from G722 to G711 works much better)
or
there is a possibility to set that transcoding is avoided if possible and a lower level codec is agreed upon.

 

[JohnS_3CX]

This may be considered at a later stage of course, but as far as I'm aware it will remain as-is for the moment.