[VoiceOps] Who do we call - 3rd plus party carrier issues affecting local customers

[Ross Tajvar]

In my experience, filing an FCC complaint does a lot to motivate someone
(usually someone with some away) from the carrier in question to speak to
you.

On Tue, Aug 20, 2019, 10:45 PM Jamie Montgomery <
Jamie.Montgomery at comporium.com> wrote:

> Greetings..
>
>
>
> Looking for the proper way to identify a third party carrier..
>
>
>
> We have had a monthlong ongoing issue with external calls into our switch
> with terrible quality. It’s random, but it’s calls to ported numbers into
> one of our CLEC areas. When an affected call comes in, it is reported as
> static or delay. We have obtained an audio capture of a couple of these
> calls from the ingress point of our TDM network, and the audio is severely
> delayed and choppy as if it was delayed within an IP network. We’re
> assuming the call has been routed through an IP low-cost carrier somewhere.
> (Working with T-Mobile below, we found that their switches would route
> calls that originates and terminates locally in South Carolina through
> Washington state carriers.)
>
>
>
> All of the calls with an issue come into us from a legacy ATT tandem, but
> not all of the calls from the ATT tandem are affected. We’ve been trying to
> get in touch with ATT for a month, and have recently spoken to some people
> with no resolution. We continue to call them daily. We worked with T-Mobile
> on issues with their wireless customers calling our CLEC customers
> experiencing this problem. The guys at T-Mobile were excellent to work
> with. (They reached out to their 3rd party carrier Inteloquent who had
> rerouted calls away from CenturyLink, which resolved calls from T-Mobile
> devices.) We’re getting dozens of trouble calls a day from several of our
> CLEC customers on calls originating from many other sources (Verizon, local
> ILEC  landlines, etc.). We’ve explained to our customer that the trouble is
> not ours, that we’re doing our best to track down the problem carrier, but
> we’re been notified by our customers that we’re going to lose them,
> regardless.
>
>
>
> Our last idea is to file a complaint with the FCC, but that’s leaving
> issues unresolved. My questions to the community are:
>
>    - What’s the most effective way to zero in on the problem carrier  to
>    troubleshoot the issue?
>    - What legal means do we have to empower somebody to support us in
>    finding the issue?
>    - What would you do if your hands were tied like ours seem to be?
>    - (What other questions should I be asking the community that come to
>    mind?)
>
>
>
> My background is switching and some at work experience of the SS7 network.
> I’m of the opinion that I’m not the most qualified in our organization to
> engage the FCC or twist ATT’s arm to work with us.. but no one else beside
> the on-point technician is making any effort. Internal responsibilities
> aside: How do we make the extra effort to keep our customers?
>
>
>
> I appreciate the time you took from your day reading this.
>
>
>
> *Jamie Montgomery | Comporium*
>
> Network Facilities Engineering | Voice Network Engineering Associate
>
> www.comporium.com
>
> jamie.montgomery at comporium.com
>
>
> *The information contained in this e-mail message and any attachments
> thereto are confidential, privileged, or otherwise protected from
> disclosure, and are intended for the use of the individual or entity named
> above. Dissemination, distribution or copying of this message and any
> attachments by anyone other than the intended recipient, or an employee or
> agent responsible for delivering the message to the intended recipient, is
> prohibited. If you have received this communication in error, please
> immediately notify the sender by telephone or e-mail and destroy the
> original message, attachments, and all copies.*
>
>
> _______________________________________________
> 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/20190820/9ef0f76f/attachment-0001.htm>