[VoiceOps] Lack of Quality Industry-wide

Tue Oct 6 16:48:47 EDT 2015

You guys are discovering the dirty little secrets of voice service and why Quality of Service (QoS) has fallen of a cliff... I have been doing int’l voice termination and networks for nearly 30 years now and back then it was “big-iron” switches and dedicated circuits costing lots of money... with monthly expense high, a carrier had to properly cost justify every connection and pay attention to the results..QoS was NOT a problem and pretty much everything connected and sounded well.

Then VoIP came along and as the MBA’say, “Barriers to entry” disappeared... lots and lots of small operators came along with little QoS rules and started hawking their wares...on the demand side, telco’s became indiscriminate about who and how many  they inter-connected with since it did not cost much for a voip connection (compared to nailed up TDM circuits!)

and on it went,, 10 years later and no real standardization of QoS has been created. Companies have services with names like “standard quality service” translate this to “cheap but nothing works” and “premium quality” which is better..  Nowadays, with USA AND Int’l voice termination, carriers spend their efforts on managing the rates (not the QoS) lest they screw up and go negative margins, get cherry picked or increase rate disputes (the bane of our industry..)

We need standardization like you reference and our company is building an online system to develop exactly those standard of quality with Int’l voice.  as a short term solution, we do NOT deal with “a-z standard rates” since there is no way we can test the thousands of rate destinations. Instead we accept only one or two int’l destinations from any one vendor and then we manually test prior to production routing.. this is pretty much the only way you can now guarantee any sort of QoS. Hopefully we will come up with better long term solutions in the years to come.

Paul Stamoulis                         +1 212 444 3003

www.OneStopTel.net<http://www.onestoptel.net/>   Thousands of Carriers...One Connection!
Onestopcorp and Onestoptel monitors and reads all emails as only business emails are permitted to be sent and received. Onestopcorp  also monitors emails for compliance reasons and to ensure that no unauthorized disclosure of confidential information is passed via the email system. This email and any attachments are confidential. It is intended for the recipient only. If you are not the intended recipient, any use, disclosure, distribution, printing or copying of this email is unauthorized. If you have received this email in error please immediately notify the sender by replying to this email and delete the email from your computer. The contents of any attachment to this email may contain software viruses, which could damage your own computer system. While Onestopcorp has taken every reasonable precaution to minimize this risk, we cannot accept liability for any damage, which you sustain as a result of software viruses. You should carry out your own virus checks before opening the attachment.

From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Ivan Kovacevic
Sent: Tuesday, October 06, 2015 2:29 PM
To: Anthony Orlando <avorlando at yahoo.com>; Peter Beckman <beckman at angryox.com>; voiceops at voiceops.org
Subject: Re: [VoiceOps] Lack of Quality Industry-wide

We have had to cook up our own monitoring and right now it consists of:

a)      OPTIONS/ping/latency/jitter monitoring of IP addresses for each vendor

b)      Near real time monitoring with email alerts and CDR examples whenever each vendor falls out of bounds on:

Percentage of connected calls (with a breakdown of TOP 5 SIP failure responses (503, 404, 403, etc).

Percentage of PDD calls (8 seconds or more)

This is a pretty blunt tool, but it has helped identify cases where a vendor goes completely down or has systemic problems that are noticeable to customers.

We have been reaching out to carriers proactively, problem CDRs are sent along with the alert email, which makes it easy to forward. However I am not sure, doing so actually improves anything. The penalty box approach may work better.

Best Regards,

Ivan Kovacevic
Vice President, Client Services
Star Telecom | www.startelecom.ca<http://www.startelecom.ca/> | SIP Based Services for Contact Centers | LinkedIn<http://www.linkedin.com/company/star-telecom-www.startelecom.ca-?trk=top_nav_home>
From: VoiceOps [mailto:voiceops-bounces at voiceops.org<mailto:voiceops-bounces at voiceops.org>] On Behalf Of Anthony Orlando via VoiceOps
Sent: Tuesday, October 06, 2015 12:19 PM
To: Peter Beckman <beckman at angryox.com<mailto:beckman at angryox.com>>; VoiceOps <voiceops at voiceops.org<mailto:voiceops at voiceops.org>>
Subject: Re: [VoiceOps] Lack of Quality Industry-wide

You are correct Peter.  It's a  constant struggle.  For years I used a product from Empirix called Intelisight.  It gave us the ability to monitor carriers (and other managed objects) with defined sets of KPI's.  Once I saw a carrier have issues (PDD, quality, excessive 503's) I used to call them and tell them they had a problem.  Hours or days later they would resolve.  I got away from that practice and just routed around them.   Funny how they notice that.  Once the issue was resolved I put them in a penalty box and slowly added traffic.  Once they realized I was measuring their performance and there would be financial repercussions it's amazing how the quality of their under lying carriers improved.  My carrier ticket count dropped by 25-30%.

________________________________
From: Peter Beckman <beckman at angryox.com<mailto:beckman at angryox.com>>
To: VoiceOps <voiceops at voiceops.org<mailto:voiceops at voiceops.org>>
Sent: Tuesday, October 6, 2015 10:27 AM
Subject: [VoiceOps] Lack of Quality Industry-wide

In the last 3 months I've been consistently frustrated by my carriers.

    "3-4 minutes is acceptable delay for delivery of SMS messages."

    "Our termination change now throws 504s instead of 503s 20-50% of the
      time and adds 2-3 seconds of delay to your call attempts. We didn't
      notice, and though you did, it's been 3 days and we haven't fixed it.
      Sorry!"

    "There was an outage? Works for me now!"

    "Someone upstream is intentionally dropping SMS messages. But we can't
      say who it is, and we can't get them to fix it because they aren't our
      carrier."

Does the industry just suck at knowing when their stuff is broken, or only
react when enough customers complain? Do carriers simply not instrument,
monitor or graph metrics of their operations and proactively monitor and
fix issues?

My Thresholds:
    * SMS delivery end-to-end: Under 10 seconds
    * 503 Route Advance: Under 1 second
    * Response/Notice to termination/API/origination/server outage: 20 minutes
    * Fix a major issue (or provide a fix timeline): 3 days

Too many times in the last few months _I_ have been the canary in the
carrier's coal mine bringing attention to places where their operations are
broken or delayed. And even then, unless I escalate to management (like CEO
level), things move at the speed of a sloth. Most of the time it seems I
monitor my carrier's infrastructure more closely than they do.

I hope and dream of the unicorn carrier -- such great operational awareness
and execution that it doesn't matter how great their customer service is,
I'll never have to talk to them.

Beckman
---------------------------------------------------------------------------
Peter Beckman                                                  Internet Guy
beckman at angryox.com<mailto:beckman at angryox.com>                                http://www.angryox.com/
---------------------------------------------------------------------------
_______________________________________________
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/20151006/e3e4507f/attachment-0001.html>