[VoiceOps] Call Quality

Mon Jun 14 13:07:58 EDT 2021

Transcoding is something that’s not been mentioned here yet. Especially with the growth of Microsoft Teams using Silk audio codec driving wideband telephony and all voice arriving from a wireless network needs to be transcoded before going to the PSTN which is clamped at G.711 narrowband.

Packet loss & jitter (and latency which is not part of normal voice clarity measurements) cause poor voice quality as perceived by the user. Maybe they don’t have QoS set for voice on their LAN/ customer premises, or likely gets stripped off as it comes in over ISP/access link/last Mile.

Congestion, CPU utilization, audio set up (microphone etc.)  and other impairments introduced by the desktop/PC/Softphone (transmitting & receiving) will also impact call quality

+ anything processing audio in the network such as a transcoder.

The “MOS” value you typically see from a packet monitoring system is derived from R factor and only takes into account packet loss and jitter. But the user experience is based on the AUDIO they receive. the only MOS measurement to quantify this is AUDIO MOS or PESQ/POLQA MOS and involves transmitting an audio file across the network and comparing it with its reference.

if you're concerned about customs complaining poor UX, record a small sample of their audio coming from them (with their permission of course, usual waivers etc.] and send it back to them as a pcap, so they can listen to it for themselves. If you need any help decoding anything other than G.711 in Wireshark, let us know.

Many Thanks & Best Regards,

Richard Jobson
Teraquant Corporation
ph: 719 488 1003
d/l: (719) 766-8523
www.teraquant.com<http://www.teraquant.com/>
richard at teraquant.com
https://www.linkedin.com/in/uc-expert-monitoring/

Network Monitoring and Service Assurance - Speech Quality Experts (PESQ/POLQA) and Active Testing - Reporting – HPBX - Session Border Controllers – SDN and SD-WAN - Big Data Analytics and fraud detection and protection.

--
NOTICE: This electronic mail transmission may contain confidential information and is intended only for the person(s) named. Any use, copying, or disclosure by any other person is strictly prohibited. If you have received this transmission in error, please notify the sender via e-mail.

From: VoiceOps <voiceops-bounces at voiceops.org> on behalf of Tim Bray via VoiceOps <voiceops at voiceops.org>
Reply-To: Tim Bray <tim at kooky.org>
Date: Monday, June 14, 2021 at 3:23 AM
To: Mike Hammett <voiceops at ics-il.net>, <voiceops at voiceops.org>
Subject: Re: [VoiceOps] Call Quality

Hi,

It depends on your definition of pipes not too overloaded.   And I'm presuming from mention of pipes that you mean network induced call quality problems.

Usually bufferbloat.   Routers with too much memory cause a lot of latency at the point of a fast to slow transition in the network.

And this can be caused by anything from a crappy DSL router on upstream, and somebody emails a large attachment during a call.   Or it can be something like a unsupported 100meg optic on the customer side of a juniper edge router on a 10gig core.    Customer does a download, latency goes nuts and all the phone calls sound naff.

Tools to test.

fast.com and press the `Show more info` button.   Forget the bandwidth figures, and look at the difference between the loaded and unloaded latency.  If a big difference, you have a problem.

http://www.dslreports.com/speedtest  This will give a bufferbloat score.  Then look at the results, and scroll down a bit and it will show you upload and download latency figures for idle, downloading and uploading.    (This is one of the most amazing tools, and I'd love a way to pay them some money each month to support the service.  They were struggling a bit at some stage.)

Tim

On 13/06/2021 19:11, Mike Hammett wrote:
I've heard a variety of complaints and concerns over the years about call quality. How are these quality issues introduced? As long as pipes and equipment aren't overloaded, where is a quality issue to come from?

Obviously, the closer you are to the handsets, the less opportunity there is for issues. What else is there to take into account?

-----
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com

Midwest Internet Exchange
http://www.midwest-ix.com

_______________________________________________

VoiceOps mailing list

VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org>

https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20210614/199c2633/attachment.htm>