[VoiceOps] VoIP Testing

[Anthony Caiozzo]

Feeling the need to jump in here... Telchemy’s VQmon technology does integrate acoustic effects into its quality prediction…. When integrated into audio and video endpoints – like Polycom, Cisco, Yealink and Avaya have done (and whose technology I believe a number of list subscribers leverage on a daily basis) - VQMon incorporates analog metrics including signal, noise, and echo levels, which are not available using mid-stream analysis alone.  

 

Which then obviously relieves you from the need to listen to every / all calls.   It really is the better mousetrap.

 

Here’s a writeup we did a long while back on this:  <http://www.lovemytool.com/blog/2008/02/telchemy-1.html> http://www.lovemytool.com/blog/2008/02/telchemy-1.html 

 

Happy to answer more questions – if there are any.

 

-anthony

 

Anthony Caiozzo

Telchemy -  <http://www.telchemy.com> www.telchemy.com 

m: 617-312-5189 f: 678-387-3008

e:  <mailto:anthony.caiozzo at telchemy.com> anthony.caiozzo at telchemy.com

support: 1-866-TELCHEMY or  <http://www.telchemy.com/custportal> www.telchemy.com/custportal to open a ticket

Skype: acaiozzo

 

 

From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Richard Jobson
Sent: Tuesday, May 23, 2017 10:58 PM
To: Mark Wiater <mark.wiater at greybeam.com>; Voiceops.org <voiceops at voiceops.org>
Subject: Re: [VoiceOps] VoIP Testing

 

So assuming it’s not packet loss or jitter, it’s a problem associated with the endpoint? No tool monitoring packets is  going to alert you to this problem because it only appears in the audio .  you could take the time to listen to every suspect call. Or you could take your customers’ time and ask him to specify which calls are problematic and listen only to those

 

What does audio sound like if a softphone  is squeezed on CPU resources? Or maybe it’s echo or maybe it’s static or maybe it’s problems associated with Wi-Fi or maybe it’s cabling or connectors?  If You can ascertain the root cause simply by listing to the audio, then that’s fine.

 

It depends on the objectives.  If all you need to do is to be able to point to suspect equipment  and tell the customer to replace it and move on,  then above is fine. If you need to isolate this specific systematic problem in a population of endpoints,  demonstrate it to external vendor or  partner or provide best practices for call center Endpoints and setup, then  perhaps more investment in troubleshooting  to root cause might be justified.

 

“Horses for courses “ ☺

 

From: VoiceOps <voiceops-bounces at voiceops.org <mailto:voiceops-bounces at voiceops.org> > on behalf of Mark Wiater <mark.wiater at greybeam.com <mailto:mark.wiater at greybeam.com> >
Date: Tuesday, May 23, 2017 at 2:37 PM
To: "Voiceops.org" <voiceops at voiceops.org <mailto:voiceops at voiceops.org> >
Subject: Re: [VoiceOps] VoIP Testing

 

 

On 5/23/2017 4:18 PM, Richard Jobson wrote:

If the speech quality impairment is associated with the endpoint itself or any part of their headset gear, cabling etc. then monitoring on the IP packet network will not  analyze this


Of course you're right. But heck, if the problem doesn't manifest at the monitoring system in the clients local network, then you kinda know where the problem is, right? :-)

I don't argue your points about POLQA and such, but voipmonitor makes it pretty easy for me to identify root causes of client complaints kinda quickly. 


_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org <mailto: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/20170524/e7311fab/attachment.html>