+100 for voipmonitor Thanks, Glenn (Mobile) On May 23, 2017 12:49 PM, "Mark Wiater" <mark.wiater at greybeam.com> wrote: From time to time we have some remote clients who are facing voice quality
issues on their endpoints and I have no real good way of troubleshooting or pin pointing the problem.
While it's not completely free, I couldn't live without voipmonitor for this very use. I install a sensor in the client network on a mirror port or on the phone system and get to see exactly what they see, from a voip perspective. The collection software is open source but the gui is invaluable. _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Voip Monitor <https://www.voipmonitor.org/whmcs/aff.php?aff=13> +1 On Tue, May 23, 2017 at 3:52 PM, Glenn Geller (VDOPh) <ggeller at vdo-ph.com> wrote:
+100 for voipmonitor
Thanks, Glenn (Mobile)
On May 23, 2017 12:49 PM, "Mark Wiater" <mark.wiater at greybeam.com> wrote:
From time to time we have some remote clients who are facing voice
quality issues on their endpoints and I have no real good way of troubleshooting or pin pointing the problem.
While it's not completely free, I couldn't live without voipmonitor for this very use. I install a sensor in the client network on a mirror port or on the phone system and get to see exactly what they see, from a voip perspective.
The collection software is open source but the gui is invaluable.
_______________________________________________ VoiceOps mailing list 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
-- Izzy Goldstein Chief Technology Officer Main: (212) 477-1000 x 2085 <(212)%20477-1000> Direct: (929) 477-2085 Website: www.telego.com <http://www.telego.net/> <http://www.telego.com/> Confidentiality Notice: This e-mail may contain confidential and/or privileged information. If you are not the intended recipient or have received this e-mail in error please notify us immediately by email reply and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Any views or opinions presented in this email are solely those of the author and do not necessarily represent those of TeleGo (T). Employees of TeleGo are expressly required not to make defamatory statements and not to infringe or authorize any infringement of copyright or any other legal right by email communications. Any such communication is contrary to TeleGo policy and outside the scope of the employment of the individual concerned. TeleGo will not accept any liability in respect of such communication, and the employee responsible will be personally liable for any damages or other liability arising. TeleGo Hosted PBX <https://youtu.be/DaT8YAZ4V0w>
It all depends on where the problem is being introduced. 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. With a monitoring system, you might be able to capture the RTP and listen to it. With an expert ear, that might ascertain the source of the problem In order to measure truly end-to-end from the analog interface of the headset [or even from an acoustic interface if necessary], normal practice is to transmit an audio speech file into the analog interface ?of the endpoint and do an Intrusive speech quality management.? The standard is PESQ or more latterly POLQA. POLQA Is an ITU-T standard, has the ?benefit of over 20 years collective research and development from ?over 6 research labs, ?combined with testing against ?a database of over 850,000 subjective? assessments. When measured accurately, it has 97% correlation with human subjective experience i.e. MOS? [ITU-T recommendation P.800] and 1 or 2 such test solutions will also give you analysis that assists you determine the root cause of the impairment From: VoiceOps <voiceops-bounces at voiceops.org> on behalf of "Glenn Geller (VDOPh)" <ggeller at vdo-ph.com> Date: Tuesday, May 23, 2017 at 1:52 PM To: Mark Wiater <mark.wiater at greybeam.com> Cc: "Voiceops.org" <voiceops at voiceops.org> Subject: Re: [VoiceOps] VoIP Testing +100 for voipmonitor Thanks, Glenn (Mobile) On May 23, 2017 12:49 PM, "Mark Wiater" <mark.wiater at greybeam.com> wrote: From time to time we have some remote clients who are facing voice quality issues on their endpoints and I have no real good way of troubleshooting or pin pointing the problem. While it's not completely free, I couldn't live without voipmonitor for this very use. I install a sensor in the client network on a mirror port or on the phone system and get to see exactly what they see, from a voip perspective. The collection software is open source but the gui is invaluable. _______________________________________________ VoiceOps mailing list 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
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.
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> on behalf of Mark Wiater <mark.wiater at greybeam.com> Date: Tuesday, May 23, 2017 at 2:37 PM To: "Voiceops.org" <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 https://puck.nether.net/mailman/listinfo/voiceops
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
I suppose the really interesting question is: as a fraction of everyday voice quality issues in the VoIP industry, what proportion is accounted for by packet loss, jitter and/or network? That would determine the ROI on more boutique tools that purport to analyse the acoustic/bearer spectrum. -- Alex
Thank you for all the suggestions will definitely check out Homer & Voip Monitor. I really just need to be sure there are no issues on my end (server side) so that I can confidently tell the client its their home network and why. On 5/23/2017 10:58 PM, Richard Jobson wrote: 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 _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops
participants (7)
-
abalashov＠evaristesys.com -
anthony.caiozzo＠telchemy.com -
ggeller＠vdo-ph.com -
igoldstein＠telego.net -
jm8269＠outlook.com -
mark.wiater＠greybeam.com -
richard＠teraquant.com