Running FreePBX Distro with Sangoma phones (P400/P500 era). It’s been up for years now (at least 5). I’m getting reports that folks are not happy with the call quality and people have a hard time with intelligibility. It’s not cutting in and out, but it seems like the bitrate is low or perhaps an inferior codec is being used.
As expected, no one can tell me whether it’s always been like this or if it’s a new problem, but since nothing has changed, my guess is it has always been this way.
Our ISP is just Comcast/Xfinity business and I think we’re at 300 / 30 Mbps speed tier. Networking is Ubiquiti UDM Pro and Unifi switches. Phones are on a VLAN with VoIP QoS set up. We’re using Voip.ms for DIDs.
Without any real information we can’t determine what is causing the issue and therefore can’t really offer solutions for it. We’re going to need to need more details.
Upstream Provider (codec) → voip.ms (codec) → Asterisk → Phone (codec). Alongside speaker/microphone involved at each side.
The codec between voip.ms and Asterisk is configurable, as is the codec between Asterisk and the phone. If the codec is the same on each side then Asterisk generally just shuffles stuff around untouched.
That’s the general flow of media. You have to isolate it further, for example doing a packet capture will allow you to playback the audio from Wireshark, allowing you to hear the audio was received from voip.ms to eliminate it as a factor.
What details do you need? I haven’t even looked for what the current settings are or know where to find them…
That said, the first thing in my mind is whether there are settings that can or should be adjusted from a new installation… or what are the defaults? Are they on the lower quality conservative side so that things “just work” out of the box?
When does the issue happen?
Is it when X calls are happening?
Does it happen on every call?
Can you reproduce the issue?
What type of system is this (CPU/RAM)?
What version of FreePBX and Asterisk is running?
Is the system doing other things like call recording?
Is the issue on both sides of the call or just one (inbound or outbound)?
Is it real or virtual?
If virtual, what else is the host doing?
If virtual, is it local, or in which cloud?
Is it contending with high volume users for internet access?
Is the issue only happening with internal calls? You can’t call in to test? Or have them call you? Yes, you can enable call recording to see if it exists at the PBX.
I’d remove gsm. It is a low quality codec, and is, effectively, obsolete, as there are better low bit rate codecs. I’d also take out g.726, as it is a low bit rate codec, although better quality than GSM.
Although it is often described as negotiated, there is only limited negotiation. In particular, for outgoing calls, the other side can use any of the codecs configured for the endpoint, and can switch between them during the call. As such, the only way of knowing what codecs are used require logging every RTP packet, e.g. with RTP debugging.
If you want the best codec used, you should configure only the best one supported for each endpoint. For providers, that is likely to be either G.711 (alaw or mulaw, according to country), or G.722 (g722). G.722 has higher audio bandwidth, at the cost of more noise. Mobile networks generally use lower quality codecs than the PSTN.
The only reason for allowing multiple codecs on a trunk is if the other side is not able to transcode, so must pass through the codec from its far side.
Asterisk can be to limit itself to the best codec that is in a received offer, and also configured for the endpoint, when answering, in which case incoming media will use that codec, and, although allowed to use other codecs from the incoming offer, Asterisk will only use the codec from its response. However, if you configure multiple codecs, for an endpoint, they will all be offered on outgoing calls, and Asterisk can’t control which one(s) will be used, for the incoming media.
(Endpoints may support codecs that are higher quality than the PSTN in your country can support, but there is no point in going beyond the PSTN capability, when using a provider. It is possible that such higher quality codecs might be used if a VoIP path exists all the way to the final destination.)