How can I make the call Crystal Clear?

[Kane Wong]

Hi;

I just made my new 3CX system Go Live for 90 users, subject to the end user feedback, the calls are acceptable but the quality has room to improve. From system administrator point of view, what can I do to provide a Crystal Clear 3CX platform for company?

 

[rc179]

I'm new to the 3CX but long time on VOIP, and the simple answer is there are some things you can do on your network, but you are very limited on what you can do on the internet side. At 90 users you're probably too small to get the kind of peering agreements you would need with internet providers and carriers (did this up for a company doing 44K calls a day).

Assuming an on-prem system.

On the LAN, quality equipment with QoS configured throughout.

You may get better results with a different codec, but again, the carrier may be the determining factor here.

Clean up your LAN, get the QoS in place, get user opinions of internal and external calls. Check your internet connections for bandwidth utilization, latency, and jitter, make sure thats super clean.

And what are you comparing it to? I've seen some good VOIP but it doesn't have the frequency range of a legacy system, so you will lose your highs and lows. And "silence" is artificially inserted, people with sensitive hearing will notice this as strange, but they tend to get used to it quickly.

 

[carlosmarchi]

If the calls are just sounding muffy (not choppy or metalized), maybe you can also look into user equipment.

I certainly don't have the same long experience as @rc179 and he has pointed the most important infrastructure points, but the phone (or headset) itself can also play a good part on the quality (or at least how the users feel it). In my small sample base and not so many years, most users will usually better rate calls using IP Phones than most Softphones, and also rate better monoaural headsets specific for telephony compared to standard headsets.

And many times they really sound better comparing to some poor headphones, limited audiocards or sluggish computers. So, if you still/also have options for equipment, might worth trying different approaches.

 

[AWS2P]

Audio quality is also related to audio codec used, so first check each device has been set with right audio codec order to avoid audio trancode and audio quality loss.
Stay everywhere set in same order expected by your sip provider .

 

[JohnS_3CX]

Hi;

I just made my new 3CX system Go Live for 90 users, subject to the end user feedback, the calls are acceptable but the quality has room to improve. From system administrator point of view, what can I do to provide a Crystal Clear 3CX platform for company?

Hi Kane,

The very short answer: Have everyone use the webclient

The more realistic answer: this will depend on some factors you can control, and some that you cannot

1. External calls depend on the codec the SIP provider can handle, and even if you don't transcode the audio, they will do it for you and the quality will again be reduced (the other side calling you will usually not support high quality codecs)
2. Recording uses a lower quality codec to keep file sizes small, so if you enabled it the quality will be reduced
3. Not all devices support high quality codecs, when the caller uses higher quality than the recipient can handle, the audio will be transcoded and the quality will again drop.
4. Higher quality codecs can use more bandwidth and processing power, this may not always be desired for people on metered connections/low end hardware

As you can understand, everything is a compromise, but if you simply want to make clear internal calls from ext-to-ext, then the webclient is the easiest and quickest way.

 

[rc179]

If the calls are just sounding muffy (not choppy or metalized), maybe you can also look into user equipment.

I certainly don't have the same long experience as @rc179 and he has pointed the most important infrastructure points, but the phone (or headset) itself can also play a good part on the quality (or at least how the users feel it). In my small sample base and not so many years, most users will usually better rate calls using IP Phones than most Softphones, and also rate better monoaural headsets specific for telephony compared to standard headsets.

And many times they really sound better comparing to some poor headphones, limited audiocards or sluggish computers. So, if you still/also have options for equipment, might worth trying different approaches.

@carlosmarchi is spot on, quality equipment is important. I've never seen a softphone that is as good as a quality deskset. And I do mean quality, there are plenty of junk phones out there. And headset on a deskset needs to quality as well, Plantronics is my goto for headsets, has been forever.
The any of the supported phone on the 3CX should be good, just stay away from the softphones. They are convenient but can't keep up with a dedicated device.

 

[Kane Wong]

Hi Kane,

The very short answer: Have everyone use the webclient


The more realistic answer: this will depend on some factors you can control, and some that you cannot

1. External calls depend on the codec the SIP provider can handle, and even if you don't transcode the audio, they will do it for you and the quality will again be reduced (the other side calling you will usually not support high quality codecs)
2. Recording uses a lower quality codec to keep file sizes small, so if you enabled it the quality will be reduced
3. Not all devices support high quality codecs, when the caller uses higher quality than the recipient can handle, the audio will be transcoded and the quality will again drop.
4. Higher quality codecs can use more bandwidth and processing power, this may not always be desired for people on metered connections/low end hardware

As you can understand, everything is a compromise, but if you simply want to make clear internal calls from ext-to-ext, then the webclient is the easiest and quickest way.

Thank you!

 

[Kane Wong]

Thank you!

For using Yealink desk phone, the quality is fine, and if using the 3CX mobile app, it is acceptable but try to find the way to make it clear.

My server is a i5 with 8GB RAM Dell PC with Linux 3CX platform, the server is attached to a layer 3 switch with QoS turn on.

 

[Kane Wong]

If the calls are just sounding muffy (not choppy or metalized), maybe you can also look into user equipment.

I certainly don't have the same long experience as @rc179 and he has pointed the most important infrastructure points, but the phone (or headset) itself can also play a good part on the quality (or at least how the users feel it). In my small sample base and not so many years, most users will usually better rate calls using IP Phones than most Softphones, and also rate better monoaural headsets specific for telephony compared to standard headsets.

And many times they really sound better comparing to some poor headphones, limited audiocards or sluggish computers. So, if you still/also have options for equipment, might worth trying different approaches.

thank you for response. Yes, the desk phone is fine. Just check anything else can improve the quality on mobile app.

 

[rc179]

The mobile app is going to be tough. It's software on a general purpose OS/device, not a dedicated device like a phone set, and I'm not sure if it's audio would be recognized as priority traffic, I'd want to do a pcap to see if it's audio is tagged dscp or TOS/COS correctly. And they would need to be on your internal wifi, and it would need QoS, and their server connection would need to be to the private IP of the 3CX and not a public looped through a firewall. This would be a problem if you wanted it to work both on-site and remote.

So you may be getting that there are a lot of factors to this. You may be expecting too much from you mobile app. I tend to work my way up the ISO stack, make sure layers 1-4 are good then jump to 7. So make sure your wifi connectivity is good, reliable, not dropping Frames (frames not packets), then make sure you have good IP throughput, low latency and jitter, proper QoS. Then jump up to codec selection.

Since the sets are ok, there probably isn't an issue with the 3CX or the upstream carrier connections.

Good luck

 

[Kane Wong]

The mobile app is going to be tough. It's software on a general purpose OS/device, not a dedicated device like a phone set, and I'm not sure if it's audio would be recognized as priority traffic, I'd want to do a pcap to see if it's audio is tagged dscp or TOS/COS correctly. And they would need to be on your internal wifi, and it would need QoS, and their server connection would need to be to the private IP of the 3CX and not a public looped through a firewall. This would be a problem if you wanted it to work both on-site and remote.

So you may be getting that there are a lot of factors to this. You may be expecting too much from you mobile app. I tend to work my way up the ISO stack, make sure layers 1-4 are good then jump to 7. So make sure your wifi connectivity is good, reliable, not dropping Frames (frames not packets), then make sure you have good IP throughput, low latency and jitter, proper QoS. Then jump up to codec selection.

Since the sets are ok, there probably isn't an issue with the 3CX or the upstream carrier connections.

Good luck

Thank you for your feedback.

 

[cobaltit]

You might want to check the codecs. The 3CX app is probably defaulting to GSM where the desk phones are likely using G.711/ULAW. Try changing the codec for the 3CX App (via the management console) to G.711 and then re-provisioning and see if that helps.

 

[Kane Wong]

Thank you Cobaltit;

The codec I found for my 3CX App is in sequence list below..

GSM-FR
G729
G.711 U Law
G.711 A Law
G722

 

[SteveITS]

It would be so nice if the codecs could be reordered when editing multiple extensions...

 

[Kane Wong]

What impact if I remove all other codecs and just leaving "G.711 U Law", and Pros and Cons?

 

[cobaltit]

What impact if I remove all other codecs and just leaving "G.711 U Law", and Pros and Cons?

The impact and pros and cons are fairly obvious I think. Removing a codec eliminates it as an option when negotiating codecs. There's no need to remove them all. Just make g.711 first on the list. If that improves the quality (which I imagine it will) you can experiment from there.

 

[Kane Wong]

Thank you