It sounds like you have done more than half the troubleshooting already. I would continue to work the AT&T escalation angle as it sounds they should be the ones in a position to identify the trouble route and resolve it.
Maybe through out the idea of a potential FCC complaint by someone in your organization it could help move things along. Good luck On Tue, Aug 20, 2019 at 7:45 PM Jamie Montgomery < jamie.montgom...@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.montgom...@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@voiceops.org > https://puck.nether.net/mailman/listinfo/voiceops > -- Brandon Svec 15106862204 voice | fax | sms teamonesolutions.com 14729 Catalina St. San Leandro, CA 94577 .ılı.ılı. Cisco Meraki CMNA
_______________________________________________ VoiceOps mailing list VoiceOps@voiceops.org https://puck.nether.net/mailman/listinfo/voiceops