We have a new customer that has an increasing number of TNs they can't call. I've traced them all down to going through our local Frontier tandem. Calls from other phone numbers on our network are fine. Two of the numbers are with Frontier, just another ratecenter off of that tandem. The third we know of goes to VZW. I submit a ticket to Frontier with source number, destination number, and call date\time for the last set of problem calls, all within the previous 24 hours, out of our Metaswitch SAS. Frontier replies: Per Software Engineering/DBA: Did not find mention call in IRIS (SS7), did find at that time a call to 815-824-XXXX, not 815-824-YYYY. SS7 show that call at 14:51 came in on DNC tgn 1011, GN089085, OPC=005-092-136 and terminate to DeKalb switch. Verified incoming call in switch, switch not blocking terminating to line. **31 - Normal. Unspecified. This cause is used to report a normal event only when no other cause in the normal class applies**. Found no trouble in switch translations/routing. Status: Cleared Awaiting Cust Verification So we have a very different definition of "cleared". I call a problem cleared when it's resolved, not when the reason can't be found. So Frontier: 1. Can't find one of the three calls I sent them. 2. Doesn't chase the problem to the end of the line. 3. Clarifies that the ISUP error I'm getting means they don't have a reason for it to be closed, so probably not a normal circumstance. 4. Doesn't investigate why there's an unclassified release. How can I incentivize Frontier to actually figure this out? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com
Honestly the reply you got was more then I would've expected from any ILEC. This lack of care is par for the course for them. The way I read their reply however is "Trouble isn't in my department, go open a ticket elsewhere". And might be indicating that the reject is coming from somewhere further downstream. Such as they attempted to alert the line but it was busy. And they passed that back to you as a CC31 because... reasons. But this is a routing/translations guy, not an access guy. So he doesn't know. The ILEC's are so compartmentalized that the person that handled this ticket doesn't even know where you'd go from there other than it's not his/her problem. If I were you, I'd try sending the call to IQ or some other LD carrier and see if you get the same results. Atleast with the Frontier called TN's (2 of the 3), you know they're terminating back to that same tandem regardless of if it's from you or IQ, or whoever. Try the same call with different ANI's, Different results? Maybe the end user is subscribed to some service that is blocking the call..etc. Best of luck! ________________________________ From: VoiceOps <voiceops-bounces at voiceops.org> on behalf of Mike Hammett via VoiceOps <voiceops at voiceops.org> Sent: Friday, September 30, 2022 2:35 PM To: VoiceOps <voiceops at voiceops.org> Subject: [VoiceOps] Tandem Dropping Calls We have a new customer that has an increasing number of TNs they can't call. I've traced them all down to going through our local Frontier tandem. Calls from other phone numbers on our network are fine. Two of the numbers are with Frontier, just another ratecenter off of that tandem. The third we know of goes to VZW. I submit a ticket to Frontier with source number, destination number, and call date\time for the last set of problem calls, all within the previous 24 hours, out of our Metaswitch SAS. Frontier replies: Per Software Engineering/DBA: Did not find mention call in IRIS (SS7), did find at that time a call to 815-824-XXXX, not 815-824-YYYY. SS7 show that call at 14:51 came in on DNC tgn 1011, GN089085, OPC=005-092-136 and terminate to DeKalb switch. Verified incoming call in switch, switch not blocking terminating to line. **31 - Normal. Unspecified. This cause is used to report a normal event only when no other cause in the normal class applies**. Found no trouble in switch translations/routing. Status: Cleared Awaiting Cust Verification So we have a very different definition of "cleared". I call a problem cleared when it's resolved, not when the reason can't be found. So Frontier: 1. Can't find one of the three calls I sent them. 2. Doesn't chase the problem to the end of the line. 3. Clarifies that the ISUP error I'm getting means they don't have a reason for it to be closed, so probably not a normal circumstance. 4. Doesn't investigate why there's an unclassified release. How can I incentivize Frontier to actually figure this out? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com
Calls through Bandwidth were successfuls, the last carriers (Frontier and VZW) don't have anything going on with my customer's TN. *sigh* Back to Frontier. I called Friday to escalate, but now the ticket in VFO is closed, so I'm sure that'll be wonderful to get them to act on now. It's the same tandem town\CO, but aren't LD tandems and local tandems different, or is that separation history and they just all get dropped on the same box now? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Nick Olsen" <Nick at 141networks.com> To: "VoiceOps" <voiceops at voiceops.org>, "Mike Hammett" <voiceops at ics-il.net> Sent: Friday, September 30, 2022 3:30:48 PM Subject: Re: Tandem Dropping Calls Honestly the reply you got was more then I would've expected from any ILEC. This lack of care is par for the course for them. The way I read their reply however is "Trouble isn't in my department, go open a ticket elsewhere". And might be indicating that the reject is coming from somewhere further downstream. Such as they attempted to alert the line but it was busy. And they passed that back to you as a CC31 because... reasons. But this is a routing/translations guy, not an access guy. So he doesn't know. The ILEC's are so compartmentalized that the person that handled this ticket doesn't even know where you'd go from there other than it's not his/her problem. If I were you, I'd try sending the call to IQ or some other LD carrier and see if you get the same results. Atleast with the Frontier called TN's (2 of the 3), you know they're terminating back to that same tandem regardless of if it's from you or IQ, or whoever. Try the same call with different ANI's, Different results? Maybe the end user is subscribed to some service that is blocking the call..etc. Best of luck! From: VoiceOps <voiceops-bounces at voiceops.org> on behalf of Mike Hammett via VoiceOps <voiceops at voiceops.org> Sent: Friday, September 30, 2022 2:35 PM To: VoiceOps <voiceops at voiceops.org> Subject: [VoiceOps] Tandem Dropping Calls We have a new customer that has an increasing number of TNs they can't call. I've traced them all down to going through our local Frontier tandem. Calls from other phone numbers on our network are fine. Two of the numbers are with Frontier, just another ratecenter off of that tandem. The third we know of goes to VZW. I submit a ticket to Frontier with source number, destination number, and call date\time for the last set of problem calls, all within the previous 24 hours, out of our Metaswitch SAS. Frontier replies: Per Software Engineering/DBA: Did not find mention call in IRIS (SS7), did find at that time a call to 815-824-XXXX, not 815-824-YYYY. SS7 show that call at 14:51 came in on DNC tgn 1011, GN089085, OPC=005-092-136 and terminate to DeKalb switch. Verified incoming call in switch, switch not blocking terminating to line. **31 - Normal. Unspecified. This cause is used to report a normal event only when no other cause in the normal class applies**. Found no trouble in switch translations/routing. Status: Cleared Awaiting Cust Verification So we have a very different definition of "cleared". I call a problem cleared when it's resolved, not when the reason can't be found. So Frontier: 1. Can't find one of the three calls I sent them. 2. Doesn't chase the problem to the end of the line. 3. Clarifies that the ISUP error I'm getting means they don't have a reason for it to be closed, so probably not a normal circumstance. 4. Doesn't investigate why there's an unclassified release. How can I incentivize Frontier to actually figure this out? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com
I would contact your SS7 provider and have them do a trace on it to figure out where it's dropping. If it's with Frontier, then you can put in another trouble ticket and tell them you have proof it's a problem with their network. You'll need to request it be escalated because they keep closing your trouble tickets with no resolution. If you can't get anywhere with that, just keep contacting them through multiple routes. For example, reach out to their NPAC contact for an escalation contact for routing issues. Chat with their online troubleshooting people to request an escalation. Unfortunately with the RBOCs and ILECs, some don't respond until they are about to get their hand slapped so if nothing else works file a complaint with the PUC. Some people just take joy in making it hard for competitors to fix their routing problems but they can only do that so long before they look bad. I've found being the consistent squeaky wheel that is firm and professional yet won't take no for an answer is what eventually gets you where you need to be. You might get called a few names along the way, but only by people who didn't want to do their job right in the first place. Frontier's online troubleshooting chat link https://frontier.com/login?target=2f6163636f756e74#/troubleshooting MARY LOU CAREY BackUP Telecom Consulting Office: 615-791-9969 Cell: 615-796-1111 On 2022-10-03 10:34 AM, Mike Hammett via VoiceOps wrote:
Calls through Bandwidth were successfuls, the last carriers (Frontier and VZW) don't have anything going on with my customer's TN.
*sigh* Back to Frontier. I called Friday to escalate, but now the ticket in VFO is closed, so I'm sure that'll be wonderful to get them to act on now.
It's the same tandem town\CO, but aren't LD tandems and local tandems different, or is that separation history and they just all get dropped on the same box now?
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest Internet Exchange http://www.midwest-ix.com
-------------------------
From: "Nick Olsen" <Nick at 141networks.com> To: "VoiceOps" <voiceops at voiceops.org>, "Mike Hammett" <voiceops at ics-il.net> Sent: Friday, September 30, 2022 3:30:48 PM Subject: Re: Tandem Dropping Calls
Honestly the reply you got was more then I would've expected from any ILEC. This lack of care is par for the course for them.
The way I read their reply however is "Trouble isn't in my department, go open a ticket elsewhere". And might be indicating that the reject is coming from somewhere further downstream. Such as they attempted to alert the line but it was busy. And they passed that back to you as a CC31 because... reasons. But this is a routing/translations guy, not an access guy. So he doesn't know.
The ILEC's are so compartmentalized that the person that handled this ticket doesn't even know where you'd go from there other than it's not his/her problem.
If I were you, I'd try sending the call to IQ or some other LD carrier and see if you get the same results. Atleast with the Frontier called TN's (2 of the 3), you know they're terminating back to that same tandem regardless of if it's from you or IQ, or whoever. Try the same call with different ANI's, Different results? Maybe the end user is subscribed to some service that is blocking the call..etc.
Best of luck!
-------------------------
From: VoiceOps <voiceops-bounces at voiceops.org> on behalf of Mike Hammett via VoiceOps <voiceops at voiceops.org> Sent: Friday, September 30, 2022 2:35 PM To: VoiceOps <voiceops at voiceops.org> Subject: [VoiceOps] Tandem Dropping Calls
We have a new customer that has an increasing number of TNs they can't call. I've traced them all down to going through our local Frontier tandem. Calls from other phone numbers on our network are fine. Two of the numbers are with Frontier, just another ratecenter off of that tandem. The third we know of goes to VZW.
I submit a ticket to Frontier with source number, destination number, and call date\time for the last set of problem calls, all within the previous 24 hours, out of our Metaswitch SAS.
Frontier replies:
Per Software Engineering/DBA: Did not find mention call in IRIS (SS7), did find at that time a call to 815-824-XXXX, not 815-824-YYYY. SS7 show that call at 14:51 came in on DNC tgn 1011, GN089085, OPC=005-092-136 and terminate to DeKalb switch. Verified incoming call in switch, switch not blocking terminating to line. **31 - Normal. Unspecified. This cause is used to report a normal event only when no other cause in the normal class applies**. Found no trouble in switch translations/routing.
Status: Cleared Awaiting Cust Verification
So we have a very different definition of "cleared". I call a problem cleared when it's resolved, not when the reason can't be found.
So Frontier: 1. Can't find one of the three calls I sent them. 2. Doesn't chase the problem to the end of the line. 3. Clarifies that the ISUP error I'm getting means they don't have a reason for it to be closed, so probably not a normal circumstance. 4. Doesn't investigate why there's an unclassified release.
How can I incentivize Frontier to actually figure this out?
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest Internet Exchange http://www.midwest-ix.com _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
*nods* I've been working this escalation chain from Frontier's wholesale site. https://wholesale.frontier.com/-/media/WholesaleDocs/repair-contact-and-esca... We get our SS7 services via TNS, but we have DS1\DS3 trunks into Frontier for local and long distance tandems. They also happen to be the ILEC in most of the rate centers around here, including where two of the three problem TNs are. I probably reached the translations guy who said it wasn't his problem and closed the ticket, without bouncing it to anyone else to look into. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Mary Lou Carey" <marylou at backuptelecom.com> To: "Mike Hammett" <voiceops at ics-il.net> Cc: "VoiceOps" <voiceops at voiceops.org> Sent: Monday, October 3, 2022 12:12:53 PM Subject: Re: [VoiceOps] Tandem Dropping Calls I would contact your SS7 provider and have them do a trace on it to figure out where it's dropping. If it's with Frontier, then you can put in another trouble ticket and tell them you have proof it's a problem with their network. You'll need to request it be escalated because they keep closing your trouble tickets with no resolution. If you can't get anywhere with that, just keep contacting them through multiple routes. For example, reach out to their NPAC contact for an escalation contact for routing issues. Chat with their online troubleshooting people to request an escalation. Unfortunately with the RBOCs and ILECs, some don't respond until they are about to get their hand slapped so if nothing else works file a complaint with the PUC. Some people just take joy in making it hard for competitors to fix their routing problems but they can only do that so long before they look bad. I've found being the consistent squeaky wheel that is firm and professional yet won't take no for an answer is what eventually gets you where you need to be. You might get called a few names along the way, but only by people who didn't want to do their job right in the first place. Frontier's online troubleshooting chat link https://frontier.com/login?target=2f6163636f756e74#/troubleshooting MARY LOU CAREY BackUP Telecom Consulting Office: 615-791-9969 Cell: 615-796-1111 On 2022-10-03 10:34 AM, Mike Hammett via VoiceOps wrote:
Calls through Bandwidth were successfuls, the last carriers (Frontier and VZW) don't have anything going on with my customer's TN.
*sigh* Back to Frontier. I called Friday to escalate, but now the ticket in VFO is closed, so I'm sure that'll be wonderful to get them to act on now.
It's the same tandem town\CO, but aren't LD tandems and local tandems different, or is that separation history and they just all get dropped on the same box now?
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest Internet Exchange http://www.midwest-ix.com
-------------------------
From: "Nick Olsen" <Nick at 141networks.com> To: "VoiceOps" <voiceops at voiceops.org>, "Mike Hammett" <voiceops at ics-il.net> Sent: Friday, September 30, 2022 3:30:48 PM Subject: Re: Tandem Dropping Calls
Honestly the reply you got was more then I would've expected from any ILEC. This lack of care is par for the course for them.
The way I read their reply however is "Trouble isn't in my department, go open a ticket elsewhere". And might be indicating that the reject is coming from somewhere further downstream. Such as they attempted to alert the line but it was busy. And they passed that back to you as a CC31 because... reasons. But this is a routing/translations guy, not an access guy. So he doesn't know.
The ILEC's are so compartmentalized that the person that handled this ticket doesn't even know where you'd go from there other than it's not his/her problem.
If I were you, I'd try sending the call to IQ or some other LD carrier and see if you get the same results. Atleast with the Frontier called TN's (2 of the 3), you know they're terminating back to that same tandem regardless of if it's from you or IQ, or whoever. Try the same call with different ANI's, Different results? Maybe the end user is subscribed to some service that is blocking the call..etc.
Best of luck!
-------------------------
From: VoiceOps <voiceops-bounces at voiceops.org> on behalf of Mike Hammett via VoiceOps <voiceops at voiceops.org> Sent: Friday, September 30, 2022 2:35 PM To: VoiceOps <voiceops at voiceops.org> Subject: [VoiceOps] Tandem Dropping Calls
We have a new customer that has an increasing number of TNs they can't call. I've traced them all down to going through our local Frontier tandem. Calls from other phone numbers on our network are fine. Two of the numbers are with Frontier, just another ratecenter off of that tandem. The third we know of goes to VZW.
I submit a ticket to Frontier with source number, destination number, and call date\time for the last set of problem calls, all within the previous 24 hours, out of our Metaswitch SAS.
Frontier replies:
Per Software Engineering/DBA: Did not find mention call in IRIS (SS7), did find at that time a call to 815-824-XXXX, not 815-824-YYYY. SS7 show that call at 14:51 came in on DNC tgn 1011, GN089085, OPC=005-092-136 and terminate to DeKalb switch. Verified incoming call in switch, switch not blocking terminating to line. **31 - Normal. Unspecified. This cause is used to report a normal event only when no other cause in the normal class applies**. Found no trouble in switch translations/routing.
Status: Cleared Awaiting Cust Verification
So we have a very different definition of "cleared". I call a problem cleared when it's resolved, not when the reason can't be found.
So Frontier: 1. Can't find one of the three calls I sent them. 2. Doesn't chase the problem to the end of the line. 3. Clarifies that the ISUP error I'm getting means they don't have a reason for it to be closed, so probably not a normal circumstance. 4. Doesn't investigate why there's an unclassified release.
How can I incentivize Frontier to actually figure this out?
----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com
Midwest Internet Exchange http://www.midwest-ix.com _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
If the LERG/OCN doesn?t designate a local tandem there is no local tandem and the call must be sent to the Access tandem or to carrier. If you are performing a LNP query and the LRN does not subtend Frontier they will not route the call. Generally if you don?t perform a LNP query and the pre-LNP NPA-NXX belongs to in this case, Frontier, Frontier will perform the LNP query, route the call and assess LNP, switching and transport charges to the originating LEC/you if the number is ported. Sending a log or call record with OPC / DPC and time stamp along with the ticket helps eliminate confusion if you are able to do that. In my experience ISUP 31 does indicate a routing/translation issue. Mark Timm Switch Engineer Aureon 7760 Office Plaza Drive South West Des Moines , IA 50266 Mark.Timm at aureon.com 515-830-0478 www.Aureon.com This message contains confidential information and is intended only for the intended recipients. If you are not an intended recipient you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. From: VoiceOps <voiceops-bounces at voiceops.org> On Behalf Of Mike Hammett via VoiceOps Sent: Monday, October 3, 2022 10:34 AM To: Nick Olsen <Nick at 141networks.com> Cc: VoiceOps <voiceops at voiceops.org> Subject: Re: [VoiceOps] Tandem Dropping Calls [External Email] This message was sent from outside the company with a URL. Please do not click links unless you recognize the source of this email and know the content is safe. Calls through Bandwidth were successfuls, the last carriers (Frontier and VZW) don't have anything going on with my customer's TN. *sigh* Back to Frontier. I called Friday to escalate, but now the ticket in VFO is closed, so I'm sure that'll be wonderful to get them to act on now. It's the same tandem town\CO, but aren't LD tandems and local tandems different, or is that separation history and they just all get dropped on the same box now? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ________________________________ From: "Nick Olsen" <Nick at 141networks.com<mailto:Nick at 141networks.com>> To: "VoiceOps" <voiceops at voiceops.org<mailto:voiceops at voiceops.org>>, "Mike Hammett" <voiceops at ics-il.net<mailto:voiceops at ics-il.net>> Sent: Friday, September 30, 2022 3:30:48 PM Subject: Re: Tandem Dropping Calls Honestly the reply you got was more then I would've expected from any ILEC. This lack of care is par for the course for them. The way I read their reply however is "Trouble isn't in my department, go open a ticket elsewhere". And might be indicating that the reject is coming from somewhere further downstream. Such as they attempted to alert the line but it was busy. And they passed that back to you as a CC31 because... reasons. But this is a routing/translations guy, not an access guy. So he doesn't know. The ILEC's are so compartmentalized that the person that handled this ticket doesn't even know where you'd go from there other than it's not his/her problem. If I were you, I'd try sending the call to IQ or some other LD carrier and see if you get the same results. Atleast with the Frontier called TN's (2 of the 3), you know they're terminating back to that same tandem regardless of if it's from you or IQ, or whoever. Try the same call with different ANI's, Different results? Maybe the end user is subscribed to some service that is blocking the call..etc. Best of luck! ________________________________ From: VoiceOps <voiceops-bounces at voiceops.org<mailto:voiceops-bounces at voiceops.org>> on behalf of Mike Hammett via VoiceOps <voiceops at voiceops.org<mailto:voiceops at voiceops.org>> Sent: Friday, September 30, 2022 2:35 PM To: VoiceOps <voiceops at voiceops.org<mailto:voiceops at voiceops.org>> Subject: [VoiceOps] Tandem Dropping Calls We have a new customer that has an increasing number of TNs they can't call. I've traced them all down to going through our local Frontier tandem. Calls from other phone numbers on our network are fine. Two of the numbers are with Frontier, just another ratecenter off of that tandem. The third we know of goes to VZW. I submit a ticket to Frontier with source number, destination number, and call date\time for the last set of problem calls, all within the previous 24 hours, out of our Metaswitch SAS. Frontier replies: Per Software Engineering/DBA: Did not find mention call in IRIS (SS7), did find at that time a call to 815-824-XXXX, not 815-824-YYYY. SS7 show that call at 14:51 came in on DNC tgn 1011, GN089085, OPC=005-092-136 and terminate to DeKalb switch. Verified incoming call in switch, switch not blocking terminating to line. **31 - Normal. Unspecified. This cause is used to report a normal event only when no other cause in the normal class applies**. Found no trouble in switch translations/routing. Status: Cleared Awaiting Cust Verification So we have a very different definition of "cleared". I call a problem cleared when it's resolved, not when the reason can't be found. So Frontier: 1. Can't find one of the three calls I sent them. 2. Doesn't chase the problem to the end of the line. 3. Clarifies that the ISUP error I'm getting means they don't have a reason for it to be closed, so probably not a normal circumstance. 4. Doesn't investigate why there's an unclassified release. How can I incentivize Frontier to actually figure this out? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com
*nods* Frontier doesn't make it easy to send them logging information from my side, short of source, destination, time. We do our own LNP and route accordingly. It is pretty simple, though. All of the rate centers off of this tandem have Frontier as an ILEC, so I just pulled all of the NPA-NXXes in those towns and throw them at the tandem. Some of them we do have (I forget the telco speak for this) direct peering with a few of the Frontier switches. I have had some cases where a non-ILEC operator was on a different tandem that I would have expected, so I had to carve those out, but the above method has largely held up. The first ticket I threw at them, they couldn't even find two out of the three calls, and they just happened within 2 hours of ticket submission. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Mark Timm" <Mark.Timm at aureon.com> To: "Mike Hammett" <voiceops at ics-il.net>, "Nick Olsen" <Nick at 141networks.com> Cc: "VoiceOps" <voiceops at voiceops.org> Sent: Monday, October 3, 2022 2:39:18 PM Subject: RE: Tandem Dropping Calls If the LERG/OCN doesn?t designate a local tandem there is no local tandem and the call must be sent to the Access tandem or to carrier. If you are performing a LNP query and the LRN does not subtend Frontier they will not route the call. Generally if you don?t perform a LNP query and the pre-LNP NPA-NXX belongs to in this case, Frontier, Frontier will perform the LNP query, route the call and assess LNP, switching and transport charges to the originating LEC/you if the number is ported. Sending a log or call record with OPC / DPC and time stamp along with the ticket helps eliminate confusion if you are able to do that. In my experience ISUP 31 does indicate a routing/translation issue. Aureon.com Mark Timm ? Switch Engineer Aureon 7760 Office Plaza Drive South West Des Moines , IA 50266 Mark.Timm at aureon.com 515?830?0478 www.Aureon.com Facebook YouTube Twitter LinkedIn This message contains confidential information and is intended only for the intended recipients. If you are not an intended recipient you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. From: VoiceOps <voiceops-bounces at voiceops.org> On Behalf Of Mike Hammett via VoiceOps Sent: Monday, October 3, 2022 10:34 AM To: Nick Olsen <Nick at 141networks.com> Cc: VoiceOps <voiceops at voiceops.org> Subject: Re: [VoiceOps] Tandem Dropping Calls [External Email] This message was sent from outside the company with a URL. Please do not click links unless you recognize the source of this email and know the content is safe. Calls through Bandwidth were successfuls, the last carriers (Frontier and VZW) don't have anything going on with my customer's TN. *sigh* Back to Frontier. I called Friday to escalate, but now the ticket in VFO is closed, so I'm sure that'll be wonderful to get them to act on now. It's the same tandem town\CO, but aren't LD tandems and local tandems different, or is that separation history and they just all get dropped on the same box now? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Nick Olsen" < Nick at 141networks.com > To: "VoiceOps" < voiceops at voiceops.org >, "Mike Hammett" < voiceops at ics-il.net > Sent: Friday, September 30, 2022 3:30:48 PM Subject: Re: Tandem Dropping Calls Honestly the reply you got was more then I would've expected from any ILEC. This lack of care is par for the course for them. The way I read their reply however is "Trouble isn't in my department, go open a ticket elsewhere". And might be indicating that the reject is coming from somewhere further downstream. Such as they attempted to alert the line but it was busy. And they passed that back to you as a CC31 because... reasons. But this is a routing/translations guy, not an access guy. So he doesn't know. The ILEC's are so compartmentalized that the person that handled this ticket doesn't even know where you'd go from there other than it's not his/her problem. If I were you, I'd try sending the call to IQ or some other LD carrier and see if you get the same results. Atleast with the Frontier called TN's (2 of the 3), you know they're terminating back to that same tandem regardless of if it's from you or IQ, or whoever. Try the same call with different ANI's, Different results? Maybe the end user is subscribed to some service that is blocking the call..etc. Best of luck! From: VoiceOps < voiceops-bounces at voiceops.org > on behalf of Mike Hammett via VoiceOps < voiceops at voiceops.org > Sent: Friday, September 30, 2022 2:35 PM To: VoiceOps < voiceops at voiceops.org > Subject: [VoiceOps] Tandem Dropping Calls We have a new customer that has an increasing number of TNs they can't call. I've traced them all down to going through our local Frontier tandem. Calls from other phone numbers on our network are fine. Two of the numbers are with Frontier, just another ratecenter off of that tandem. The third we know of goes to VZW. I submit a ticket to Frontier with source number, destination number, and call date\time for the last set of problem calls, all within the previous 24 hours, out of our Metaswitch SAS. Frontier replies: Per Software Engineering/DBA: Did not find mention call in IRIS (SS7), did find at that time a call to 815-824-XXXX, not 815-824-YYYY. SS7 show that call at 14:51 came in on DNC tgn 1011, GN089085, OPC=005-092-136 and terminate to DeKalb switch. Verified incoming call in switch, switch not blocking terminating to line. **31 - Normal. Unspecified. This cause is used to report a normal event only when no other cause in the normal class applies**. Found no trouble in switch translations/routing. Status: Cleared Awaiting Cust Verification So we have a very different definition of "cleared". I call a problem cleared when it's resolved, not when the reason can't be found. So Frontier: 1. Can't find one of the three calls I sent them. 2. Doesn't chase the problem to the end of the line. 3. Clarifies that the ISUP error I'm getting means they don't have a reason for it to be closed, so probably not a normal circumstance. 4. Doesn't investigate why there's an unclassified release. How can I incentivize Frontier to actually figure this out? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com
To close the loop... This morning Frontier reported an errant CIC code being sent with the call, but didn't know if that was the cause or not. My own troubleshooting proved that out. I ended up checking Metaswitch and found a variety of other customers with bad CIC codes entered. No idea why they haven't had issued, but I'll have our people fix all of them. Once I fixed the CIC code for the problem customer, I found that one of the three numbers was rejected for no destination, verifying to me that NPANXX isn't on that tandem and removing it from that NV table. Frontier called 15 seconds after I implemented the last fix. I explained everything to the guy that called and he said, "That's not the strangest thing we've had lately, but it sure is up there." I feel vindicated when the other party is as confused as I am, but then embarrassed when it was a silly garbage in\garbage out problem. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Mike Hammett via VoiceOps" <voiceops at voiceops.org> To: "Mark Timm" <Mark.Timm at aureon.com> Cc: "VoiceOps" <voiceops at voiceops.org> Sent: Monday, October 3, 2022 3:03:29 PM Subject: Re: [VoiceOps] Tandem Dropping Calls *nods* Frontier doesn't make it easy to send them logging information from my side, short of source, destination, time. We do our own LNP and route accordingly. It is pretty simple, though. All of the rate centers off of this tandem have Frontier as an ILEC, so I just pulled all of the NPA-NXXes in those towns and throw them at the tandem. Some of them we do have (I forget the telco speak for this) direct peering with a few of the Frontier switches. I have had some cases where a non-ILEC operator was on a different tandem that I would have expected, so I had to carve those out, but the above method has largely held up. The first ticket I threw at them, they couldn't even find two out of the three calls, and they just happened within 2 hours of ticket submission. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Mark Timm" <Mark.Timm at aureon.com> To: "Mike Hammett" <voiceops at ics-il.net>, "Nick Olsen" <Nick at 141networks.com> Cc: "VoiceOps" <voiceops at voiceops.org> Sent: Monday, October 3, 2022 2:39:18 PM Subject: RE: Tandem Dropping Calls If the LERG/OCN doesn?t designate a local tandem there is no local tandem and the call must be sent to the Access tandem or to carrier. If you are performing a LNP query and the LRN does not subtend Frontier they will not route the call. Generally if you don?t perform a LNP query and the pre-LNP NPA-NXX belongs to in this case, Frontier, Frontier will perform the LNP query, route the call and assess LNP, switching and transport charges to the originating LEC/you if the number is ported. Sending a log or call record with OPC / DPC and time stamp along with the ticket helps eliminate confusion if you are able to do that. In my experience ISUP 31 does indicate a routing/translation issue. Aureon.com Mark Timm ? Switch Engineer Aureon 7760 Office Plaza Drive South West Des Moines , IA 50266 Mark.Timm at aureon.com 515?830?0478 www.Aureon.com Facebook YouTube Twitter LinkedIn This message contains confidential information and is intended only for the intended recipients. If you are not an intended recipient you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. From: VoiceOps <voiceops-bounces at voiceops.org> On Behalf Of Mike Hammett via VoiceOps Sent: Monday, October 3, 2022 10:34 AM To: Nick Olsen <Nick at 141networks.com> Cc: VoiceOps <voiceops at voiceops.org> Subject: Re: [VoiceOps] Tandem Dropping Calls [External Email] This message was sent from outside the company with a URL. Please do not click links unless you recognize the source of this email and know the content is safe. Calls through Bandwidth were successfuls, the last carriers (Frontier and VZW) don't have anything going on with my customer's TN. *sigh* Back to Frontier. I called Friday to escalate, but now the ticket in VFO is closed, so I'm sure that'll be wonderful to get them to act on now. It's the same tandem town\CO, but aren't LD tandems and local tandems different, or is that separation history and they just all get dropped on the same box now? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Nick Olsen" < Nick at 141networks.com > To: "VoiceOps" < voiceops at voiceops.org >, "Mike Hammett" < voiceops at ics-il.net > Sent: Friday, September 30, 2022 3:30:48 PM Subject: Re: Tandem Dropping Calls Honestly the reply you got was more then I would've expected from any ILEC. This lack of care is par for the course for them. The way I read their reply however is "Trouble isn't in my department, go open a ticket elsewhere". And might be indicating that the reject is coming from somewhere further downstream. Such as they attempted to alert the line but it was busy. And they passed that back to you as a CC31 because... reasons. But this is a routing/translations guy, not an access guy. So he doesn't know. The ILEC's are so compartmentalized that the person that handled this ticket doesn't even know where you'd go from there other than it's not his/her problem. If I were you, I'd try sending the call to IQ or some other LD carrier and see if you get the same results. Atleast with the Frontier called TN's (2 of the 3), you know they're terminating back to that same tandem regardless of if it's from you or IQ, or whoever. Try the same call with different ANI's, Different results? Maybe the end user is subscribed to some service that is blocking the call..etc. Best of luck! From: VoiceOps < voiceops-bounces at voiceops.org > on behalf of Mike Hammett via VoiceOps < voiceops at voiceops.org > Sent: Friday, September 30, 2022 2:35 PM To: VoiceOps < voiceops at voiceops.org > Subject: [VoiceOps] Tandem Dropping Calls We have a new customer that has an increasing number of TNs they can't call. I've traced them all down to going through our local Frontier tandem. Calls from other phone numbers on our network are fine. Two of the numbers are with Frontier, just another ratecenter off of that tandem. The third we know of goes to VZW. I submit a ticket to Frontier with source number, destination number, and call date\time for the last set of problem calls, all within the previous 24 hours, out of our Metaswitch SAS. Frontier replies: Per Software Engineering/DBA: Did not find mention call in IRIS (SS7), did find at that time a call to 815-824-XXXX, not 815-824-YYYY. SS7 show that call at 14:51 came in on DNC tgn 1011, GN089085, OPC=005-092-136 and terminate to DeKalb switch. Verified incoming call in switch, switch not blocking terminating to line. **31 - Normal. Unspecified. This cause is used to report a normal event only when no other cause in the normal class applies**. Found no trouble in switch translations/routing. Status: Cleared Awaiting Cust Verification So we have a very different definition of "cleared". I call a problem cleared when it's resolved, not when the reason can't be found. So Frontier: 1. Can't find one of the three calls I sent them. 2. Doesn't chase the problem to the end of the line. 3. Clarifies that the ISUP error I'm getting means they don't have a reason for it to be closed, so probably not a normal circumstance. 4. Doesn't investigate why there's an unclassified release. How can I incentivize Frontier to actually figure this out? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
participants (4)
-
Mark.Timm＠aureon.com -
marylou＠backuptelecom.com -
Nick＠141networks.com -
voiceops＠ics-il.net