3CX Transcoding issue?

[Quenten Grasso]

Hi, All,

We are having a strange issue on our new 3CX system; it sounds like its transcoding all audio to a considerably lesser quality codec.

Basically the issue is whenever the audio goes via the PBX, e.g. if we enable call recording this audio sounds crystal clear inside recorded call wav files, The audio that is delivered back to the phones sounds like it been re-encoded to a considerably lesser quality codec.

A little about our configuration,
KVM Hypervisor (Proxmox VE 4.4)
Were using Debian 8 SC, 3CX 15.x (latest version) w/ Yealink T46G & T46S Phones Also 3CX. (Softphones seem to experience the same issues.)
4vCPU E5-2650v2
8GB RAM
200GB SSD Disk

We have several sites connected via Private Ethernet WAN Services, and our System is hosted in our Datacentre, low lantecy and uncongested WAN links.

The Yealink phones talk Peer 2 Peer, and this is using The G.722 codec and is very clear audio across all sites.

In troubleshooting, we have all of our phones/extensions configured to use only G.722, and our SIP Provider supports G.722 as well, so we have removed all of the other codecs that I have been able to find manually from the SIP Trunks and phones as well.

Including removing the other codecs from the order list from the following files and restarting our PBX VM.

/var/lib/3cxpbx/Bin/3CXPhoneSystem.ini
LocalCodecs = G722
ExternalCodecs = G722

/usr/share/3cxpbx/skel/Bin/3CXPhoneSystem.ini
LocalCodecs=G722
ExternalCodecs=G722

/usr/share/3cxpbx/skel/Instance1/Bin/3CXPhoneSystem.ini
LocalCodecs=G722
ExternalCodecs=G722

Any suggestions?

Regards,
Quenten

 

[Quenten Grasso]

bump?

 

[aberry]

I am curious also. I have noticed this also, but our SIP provider does not support any wideband codecs. It does seem like when the PBX is handling the audio it is encoded at a low rate, and I have not found any way to adjust that. In version 14 we could use higher quality recordings for music on hold as well, but now those are forced to be low quality recordings. Are there any 3CX support people that could provide more information on this?

 

[NickD_3CX]

Don't rule out the possibility that the communication between your SIP Trunk Provider and 3CX may be G722, but your Providers connection to the downstream provider may be degraded.

My advice would be to run a packet capture and analyze the audio that leaves the 3CX Server towards the provider, then compare it to what you actually hear on the far side. If you are using G722, Wireshark won't decode that, so you might have trouble analyzing it. I know there are other professional capture analyzing tools that decode it, but I am not aware of a free alternative that can do this. Or you could just switch to using G711 for the test, it is by far the most used codec so audio quality should not be an issue with that to the point that you are describing it.

 

[Quenten Grasso]

Thanks for the replies,


What I am really struggling with is the audio quality if we use the “PBX Delivers Audio” and/or using the “Call Recording” option the recording wav file and the Wireshark capture is pretty much crystal clear, However what we get back at the handset sounds like something that’s pretty much rubbish IMHO. Nothing like Peer 2 Peer calls at G722.

Our host and VM’s have plenty of resources, and I have tried another host just to ensure it was not a host level issue.

Also, its worth to note we can not blame the SIP Provider as we are not even using the SIP trunk to the SIP Provider were just talking about going via 3CX using the options above.

Any Suggestions?

Cheers,
Quenten

 

[NickD_3CX]

Then this becomes easier to pinpoint. What I would do is switch the phones back to using G711 (only because wireshark can decode it), then:

• Start a capture on the calling Yealink phone from its interface
• Start a capture on the called Yealink phone from its interface
• Start a capture on the 3CX server

The call between the 2 phones. Then you can analyze the audio the way it leaves the calling phone, how it reaches the 3CX server, how it leaves the 3CX server and how it reaches the destination phone. This can then help you pinpoint where the issue is coming from. Of course do this with Call Recording on so that you can also compare the captured audio with the imprinted audio on the file.