Codec order for inbound and outbound calls

Hi there!

FreePBX is overall working fine since it goes live a week ago but we are struggeling a bit with bad audioquality on external calls sometimes.

I want to check the codecs. We are using Phonerlite for Softphones and SNOM D345 hardphones. The Softphone codec order is: G722 | G711a | G711u | GSM | G726. The hardphones order is: g722,gsm,g726-32,g729,g723,pcmu,pcma,aal2-g726-32,telephone-event

In Asterisk SIP-settings the order is: G722 | G711a | G711u | GSM | G726 | G729 | G723

For the trunk Chan_SIP Outgoing, i’ve configured it:

Is that right - with the “&”? And is Asterisk set this order right for outgoing calls when G722 is on first place? What about the next menu “Incoming” - in this field, which is called ‘USER Details’, i also want the same codec-order. May i also put in like i did in the Outgoing PEER Details - is this working for Incoming calls also? And what about the SIP setting’s order - is this a general codec-order which overrides the trunk orders?

Thanks for any infos and help!

This is probably not a codec problem, but I suggest enabling either only alaw, or only g722&alaw.

With only alaw, you are assured of no quality degradation caused by transcoding, but you won’t ever enjoy a wideband connection. If your trunking provider (is it still Vodafone?) offers wideband connections to/from VoLTE, enabling g722 is worth it, even though there is a very slight degradation transcoding to alaw on other calls. Also, enabling g722 gives you top quality for calls within the office.

The most common cause of poor quality is packet loss and/or jitter caused by other traffic saturating your internet connection. ISP-related problems are next. In nearly all these cases, only one direction is affected. When you have the trouble, does it affect what the PBX user hears, what the remote party hears, or both? Both incoming and outgoing calls? When you have trouble and more than one call is in progress, do all calls go bad at the same time? What kind of internet connection do you have (cable, fiber, DSL, etc.)? What upload and download speeds should you have? What do you actually measure? What kind of router/firewall do you have? What QoS, if any, is implemented?

1 Like

Hi Stewart!
Thanks a lot for your extensive answer!

but I suggest enabling either only alaw, or only g722&alaw.

Okay, so enabling it within the trunk with “g722&alaw” on Outgoing and Incoming, right?

Yes, my provider is still Vodafone and it supports G722 as well.
And yes, normal calls within the office are pretty good over the time! Just on external calls we’re having a bit trouble. But mostly just on incoming calls - the caller hear us, but we are not hearing the caller…
But ONLY on incoming calls. Internal calls and outgoing calls are fine.

May i enable g722&alaw at the “incoming” tab in the trunk settings and only set these codecs also in the Sip settings order?

When you have the trouble, does it affect what the PBX user hears, what the remote party hears, or both?

  • Only we are not hearing the caller, but it seems to be only on landline-calls and it is not effected on incoming cellphone calls

When you have trouble and more than one call is in progress, do all calls go bad at the same time?

  • no, it’s just the call in time, and not all others - it hit’s just a “random” caller with this problem

Our internet connection is good enough, 100M/bit fiber

What kind of router/firewall do you have? What QoS, if any, is implemented?

  • Its a Sophos Firewall and we have checked that already for UDP and RTP
  • QoS is active on both sides, provider and us

Okay, i would like to set the following parameters in the trunk settings (Chan_SIP) in the Incoming and Outgoing tab:

Do you agree with this?

And set this order also in the SIP settings
Set these also in the softphones and hardphone’s codec order

I just think we’re struggeling with packet lost on RTP packets because of no-audio on incoming (landline) calls

How do i debug a specific or a random incoming call to see where the packet loss occurs?

I agree with your proposed settings, but I’m confused about your ‘no-audio’ comment. On the failing calls, do you hear a typical choppy voice problem (gaps of a fraction of a second)? Or does audio stop for more than one second at a time? Or does it go completely silent?

To start, the simplest test is to record the calls with the regular FreePBX record features and hear whether the recording has the problem.

There is a relatively new tool for capturing the raw packets on a per-call basis, which you can then analyze with Wireshark, .

On my own system, I run
tcpdump -s 0 -C 100 -W 100 -w rbuf -Z root &
which captures all packets into a ring buffer of 100 files of 100 MB each. This runs 24/7. When trouble is reported, I look at the timestamps of the files to find the one containing the bad call. Sometimes I’m unlucky and the call overlaps two files (which can be merged in Wireshark). Then, I use Wireshark commands to analyze the specific call. In some cases, having the raw stream is useful; you can see what else was going on at the same time.

1 Like

Okay, i set these parameters in the two trunk tabs and in the order of the sip settings and the soft- and hardphone-codec-order.

I asked the colleagues who’s having the failing calls and they say its just a silent line, no cracks, no hicks, no echo, gaps etc.

The command:

tcpdump -s 0 -C 100 -W 100 -w rbuf -Z root &

is used on the regular VM’s CLI, not in the freepbx-gui-cli tab, right?
Where does this command saves the files on the system?
The command is called “tcpdump”, we are using UDP, is this yet the right command also for UDP-SIP traffic?

Yes, and you must be root. The files get written into the current directory from which you run the command and are called rbuf00, rbuf01, …, rbuf99. When you have trouble and identify the relevant file, copy it (by sftp or whatever) to your workstation and open it in Wireshark.

If you discover the problem quickly (or traffic is low), the relevant file may be less than 100 MB and is still being written, in which case copy it to a temp file before moving it to your PC.

The program tcpdump actually captures raw Ethernet packets, so it’s not specific to TCP or even to IP.

1 Like

Alright - i try it out!
I can move the files via WINSCP and copy it to my workstation, thats fine.

Okay - so i’m looking for today how the quality is because of the codec-changes and i hope the best.
I try out tcpdump soon and report here later.

Thanks a lot, Stewart!


how do you stop the logging?
I set it up and it runs, but i want to check the files for a test and want to stop the logging. :smiley:
How did i do that?

The cli hangs in this command at the moment and the files are getting bigger.

It shouldn’t be hung. If you press enter do you see another prompt?

Just type
kill 90629
at the prompt, or in a new window if the first is really hung.

1 Like

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.