[VoiceOps] Call quality issue / survey
nathana at fsr.com
Mon Mar 11 19:41:59 EDT 2013
The good (5083) call was terminated by Zayo f.k.a 360Networks. I'm still not entirely clear on who is terminating the bad (5084) call. The media gateway IP is from a range apparently used by a hosting company. I suspect that the term aggregator we are using is sending it on to another aggregator who is masking the ultimate destination by proxying the media through a host of theirs; I say this because I've seen plenty of non-Alaska calls that have also sent us media from that same IP, and those calls have been perfectly fine.
From: compuwizz at gmail.com [mailto:compuwizz at gmail.com] On Behalf Of Jared Geiger
Sent: Monday, March 11, 2013 3:04 PM
To: Nathan Anderson
Cc: Hiers, David; voiceops at voiceops.org
Subject: Re: [VoiceOps] Call quality issue / survey
If you end up having a lot of Alaska calls, contact ACS Alaska to connect with them directly. They would give you the best clarity since they own and operate the number.
I tested out many of my providers calling the actual number 19074596715 to see if I could stumble upon the one that clicked and sounded horrible. All of mine sounded like the 5083 number with the leading music and uniform volume. Some had more jitter than others. I'm really curious to see what ACS sounds like though. The reseller who used to use ACS no longer is selling to me though so I can't test.
On Mon, Mar 11, 2013 at 5:31 PM, Nathan Anderson <nathana at fsr.com> wrote:
On Monday, March 11, 2013 6:45 AM, Hiers, David <mailto:David.Hiers at adp.com> wrote:
> 208-301-5083: Good quality. Sounds like a waveform codec.
> 208-301-5084: Mostly unacceptable quality. Sounds like a vocoder codec.
*ding* *ding* *ding*! We have a winner! (Runner-up goes to Jared who also touched on the codec issue.)
Although everybody picked the same recording in the end, what David points out is exactly what I had noticed and was looking for in the responses: one sounded like a land-line. The other sounded like a bad cell phone call. This is why I was encouraging people to NOT run the test from a cell phone: because you'd be on the receiving end of an actual voice-optimized codec, which would mask the issue somewhat.
In response to Jared's comment that...
On Saturday, March 09, 2013 9:40 AM, Jared Geiger <> wrote:
> [...] neither seemed to have the warmth and clarity I would
> expect from a full ulaw path the whole way through.
...I suspect that is partly an issue with the source material. And who knows what kind of equipment the end-user has or how it is hooked up to the telco (iffy analog loops?). But there are no noticeable compression artifacts when you listen to the one from 5083, and there are in the 5084 recording. This is despite the fact that the audio stream that was delivered to us was, in fact, G.711u. Somehow, some way, the audio stream is getting encoded with a lossy compression scheme of some kind, and then transcoded back to G.711u before being handed off to us.
I suspect more is going on here, though, than the simple transcoding (although that is obviously part of it). The long connection times, the annoyingly loud "pop" at the beginning of the call when it's finally being connected, occasional scratchiness/static on the line, inconsistent volume levels during a call, wildly inconsistent volume levels *between* calls (some are super-low the entire time)...these are all problems that we are regularly and constantly seeing with calls to this entire rate center as a whole.
The person who initially responded to my ticket about this said he couldn't hear the issue, thus this post. I wanted to know whether I was crazy or not.
First Step Internet, LLC
nathana at fsr.com
VoiceOps mailing list
VoiceOps at voiceops.org
More information about the VoiceOps