- VoiceOps - lists.voiceops.org

"Timeout" on VoIP call traversing Verizon data
by mwiles＠akabis.com June 11, 2021

June 11, 2021

If there?s a Verizon cellular data guru monitoring here, I?d love to get your insight! Otherwise, let me toss this out to the group for thoughts and opinions please? We?re a Metaswitch shop, and use their MaX UC mobile softphone client (iPhone/Android). We had a customer using the MaX UC client on a long call? they were using Verizon cellular data (confirmed by IP address). At thirty (30) minutes into the call, the call ?dropped?. The call was re-established, and again, after thirty minutes, the call dropped. We?re pretty sure the user was in a static position (non-mobile)? and logically assume they were on the same cell tower for both calls that dropped (the Verizon IP was the same). Looking at Metaswitch SAS (their diagnostics tool), at the thirty minute mark, we send out a re-INVITE message to the softphone client? and we receive no reply? so after ten seconds, we breakdown the call assuming they?re gone. Then about eight seconds later, we see an INVITE message from the softphone?s same IP address (with the same Call ID)? however, it?s coming from a different port. So to be clear, the original call setup and connection was using 1.2.3.4:6789? then eight seconds after we ended the call with a BYE (assuming they were gone due to lack of reply), we get an INVITE (with the same Call ID) from 1.2.3.4:9876. Metaswitch looked at the diags from the softphone (we downloaded them), and they?re confirming that the softphone never received our re-INVITE at the 30 minute mark. Metaswitch also looked at the bug/crash logs on the softphone, and confirmed neither was the case. It almost sounds like a NAT thing going on? but I?m pretty ignorant when it comes to cellular data. It looks to me as if the Verizon side simply changed port numbers, and assumed we?d know maybe via mental telepathy? ? Has anyone had experience with such an occurrence? or any thoughts? Thank you! Mark

8 15

SHA Lookup
by voiceops＠ics-il.net June 4, 2021

June 4, 2021

When I have a call routing issue, I look up what the LRN is of the number I'm sending to. I then look up that NPA-NXX in telcodata.us to find who the incumbent is in that rate center. I then look up what the tandem information is for that incumbent switch. Then I know whether it is the tandem I'm connected to in that LATA or the other tandem. Telcodata.us doesn't always have that information. What's the path of least resistance to getting that data? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com

2 1

Can't Port from a Particular Rate Center
by voiceops＠ics-il.net June 4, 2021

June 4, 2021

Assuming the number isn't held by someone exempt from porting, what would prevent someone from being able to port a number from a particular rate center in a LATA they have coverage in? We picked up a particular carrier for our out-of-area needs and the first thing we throw at them in a LATA we know they have coverage in, they can't do. They have a non-useful reason why. When I started at this company, I made sure to port a bunch of numbers from all over our LATA to see what would happen. All successful. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com

1 0

CSR BTN
by voiceops＠ics-il.net June 4, 2021

June 4, 2021

Does a CSR have to have the specific number being ported or just any number on the account? We're testing a third party network that we'll utilize in the short-term for out-of-area usage. We ported some of our own numbers to our account at the third party. The CSRs arrived with the main BTN on the account, not the number being ported. Our porting person rejected the CSRs because they weren't for the number being ported. Of course she knew what number was being attempted because it was an internal operation, but normally she wouldn't. It's my thought that the CSR is a customer information verification process. We wouldn't know the number actually being ported until the LSR came. Does the name, address, account number, TN, etc. match an account you have? If so, great. Where can I find a good resource on the process and what's normally acceptable for rejections? Of course I said, "Let me verify this before we do anything" and then she replied to the CSRs rejecting. *sigh* I guess we'll really be testing all scenarios. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com

6 7

STIR/SHAKEN - Robocall Mitigation Plan
by marylou＠backuptelecom.com May 30, 2021

May 30, 2021

I've had several people ask some great questions about the Robocall Mitigation plan since I sent out my last e-mail so I just wanted to clarify who needs to file a Robocall Mitigation plan by June 30, 2021. All companies that sell or resell voice services of any type (VOIP, TDM, Wireless) OR any company that has an end user customer they provide DIDs to are considered telecom carriers. It does NOT matter if you use upstream providers or not. It does not matter if you use another carrier's certificate or not! If you provide DIDs to a paying customer for any reason you are considered a telecom carrier so you need to file a Robocall Mitigation Plan. For those of you who aren't familiar with me, you may be wondering why I bother to post about this. I've been a Telecom Carrier Consultant for the last 21 years and have helped over a hundred carriers (CLECs, ILECs, Paging, Satellite, and Wireless) install and maintain their facilities based networks. The reason I post information about this is not because I don't have enough work to do. It is because over the years I have seen certain parties we won't mention do anything and everything they can to put the small carriers out of business and I don't want anyone to be taken out because they didn't realize they needed to do something to comply. I am a firm believer that no company can be everything to everyone so there is a place in the world for all carriers that provide good services. I've had people coming to me from the beginning asking for help getting their STIR/SHAKEN certificate so I'm very familiar with the process and what the upstream carriers are telling their underlying carriers. I'm also very familiar with the many changes that have been made to the requirements for getting a certificate. It's been confusing for everyone involved and especially the mitigation plan because that started out as an alternative to getting a certificate but it's turned into something that is required of every carrier. So regardless of whether you've already turned up STIR/SHAKEN or you're using someone else's certificate.......make sure you file your Robocall Mitigation Plan. I am not the only consultant helping people get their paperwork done so they can qualify for a certificate, so there's no obligation to use my services. All I'm saying is that whether you do it on your own or you hire someone to help you, make sure you file your Robocall Mitigation plan by June 30th. For those of you who are already STIR/SHAKEN compliant, it just means you sign in and mark your company as compliant! MARY LOU CAREY BackUP Telecom Consulting Office: 615-791-9969 Cell: 615-796-1111

1 0

LRN and valid values
by beckman＠angryox.com May 27, 2021

May 27, 2021

Carrier A provided us a US NPANXX Rate Deck that had some values in it that were not valid, such as 732040. When asked about it, they claim that Access Tandem Codes are valid LRN values for operator services calls. Carrier B provides an API for us to query to get the LRN for a termination number, so we can rate it properly and implement our own LCR. Carrier B says LRNs will always be valid NPANXX values, and 732040 and similar would never be returned. I don't have access to the LERG, and frankly, even if I did, I'm not sure where I'd look to see who wins the conflict. Any suggestions? Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------

4 4

LRN and valid values
by Jamie.Montgomery＠comporium.com May 27, 2021

May 27, 2021

There is an entry for 732040A.. OCN refers back to Verizon of Jew Jersey. The Rate Center is all X's, so it's a special code of some kind.. cant be assinged to an originating number, I dont believe. Jamie M. ________________________________ From: VoiceOps <voiceops-bounces at voiceops.org> on behalf of voiceops-request at voiceops.org <voiceops-request at voiceops.org> Sent: Wednesday, May 26, 2021 4:12 PM To: voiceops at voiceops.org <voiceops at voiceops.org> Subject: [EXTERNAL] VoiceOps Digest, Vol 140, Issue 3 Send VoiceOps mailing list submissions to voiceops at voiceops.org To subscribe or unsubscribe via the World Wide Web, visit https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.neth… or, via email, send a message with subject or body 'help' to voiceops-request at voiceops.org You can reach the person managing the list at voiceops-owner at voiceops.org When replying, please edit your Subject line so it is more specific than "Re: Contents of VoiceOps digest..." Today's Topics: 1. LRN and valid values (Peter Beckman) 2. Re: LRN and valid values (Alex Balashov) 3. Re: LRN and valid values (Paul Timmins) 4. Robocall mitigation SCAM! (Mary Lou Carey) 5. Re: Robocall mitigation SCAM! (Mark Lindsey) 6. Re: Robocall mitigation SCAM! (Matthew Yaklin) ---------------------------------------------------------------------- Message: 1 Date: Tue, 25 May 2021 22:47:24 -0400 From: Peter Beckman <beckman at angryox.com> To: VoiceOps <voiceops at voiceops.org> Subject: [VoiceOps] LRN and valid values Message-ID: <alpine.BSF.2.20.2105252244540.46257 at nog2.angryox.com> Content-Type: text/plain; format=flowed; charset=US-ASCII Carrier A provided us a US NPANXX Rate Deck that had some values in it that were not valid, such as 732040. When asked about it, they claim that Access Tandem Codes are valid LRN values for operator services calls. Carrier B provides an API for us to query to get the LRN for a termination number, so we can rate it properly and implement our own LCR. Carrier B says LRNs will always be valid NPANXX values, and 732040 and similar would never be returned. I don't have access to the LERG, and frankly, even if I did, I'm not sure where I'd look to see who wins the conflict. Any suggestions? Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.angryo… --------------------------------------------------------------------------- ------------------------------ Message: 2 Date: Wed, 26 May 2021 00:02:51 -0400 From: Alex Balashov <abalashov at evaristesys.com> To: VoiceOps <voiceops at voiceops.org> Subject: Re: [VoiceOps] LRN and valid values Message-ID: <0D4FB8A5-31EB-42C3-82BB-E76A88E4B820 at evaristesys.com> Content-Type: text/plain; charset=utf-8 Where does this conflict emerge in practice? Do customers call numbers in this exchange? Do you get billed for calls (less any LRN dip fees) to this exchange even though none of your wholesale termination vendors can route it? ? Sent from mobile, with due apologies for brevity and errors. > On May 25, 2021, at 10:48 PM, Peter Beckman <beckman at angryox.com> wrote: > > ?Carrier A provided us a US NPANXX Rate Deck that had some values in it that > were not valid, such as 732040. > > When asked about it, they claim that Access Tandem Codes are valid LRN > values for operator services calls. > > Carrier B provides an API for us to query to get the LRN for a termination > number, so we can rate it properly and implement our own LCR. Carrier B > says LRNs will always be valid NPANXX values, and 732040 and similar would > never be returned. > > I don't have access to the LERG, and frankly, even if I did, I'm not sure > where I'd look to see who wins the conflict. > > Any suggestions? > > Beckman > --------------------------------------------------------------------------- > Peter Beckman Internet Guy > beckman at angryox.com https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.angryo… > --------------------------------------------------------------------------- > _______________________________________________ > VoiceOps mailing list > VoiceOps at voiceops.org > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.neth… ------------------------------ Message: 3 Date: Wed, 26 May 2021 04:54:19 +0000 From: Paul Timmins <ptimmins at clearrate.com> To: Peter Beckman <beckman at angryox.com> Cc: VoiceOps <voiceops at voiceops.org> Subject: Re: [VoiceOps] LRN and valid values Message-ID: <8EB46E7D-53C6-4675-BDCC-DD3D7511E989 at clearrate.com> Content-Type: text/plain; charset="us-ascii" How are you even getting operator assisted calls onto your network to begin with? Do you have an operator service you still pay for? > On May 25, 2021, at 10:47 PM, Peter Beckman <beckman at angryox.com> wrote: > > Carrier A provided us a US NPANXX Rate Deck that had some values in it that > were not valid, such as 732040. > > When asked about it, they claim that Access Tandem Codes are valid LRN > values for operator services calls. > > Carrier B provides an API for us to query to get the LRN for a termination > number, so we can rate it properly and implement our own LCR. Carrier B > says LRNs will always be valid NPANXX values, and 732040 and similar would > never be returned. > > I don't have access to the LERG, and frankly, even if I did, I'm not sure > where I'd look to see who wins the conflict. > > Any suggestions? > > Beckman > --------------------------------------------------------------------------- > Peter Beckman Internet Guy > beckman at angryox.com https://nam10.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.angryo… > --------------------------------------------------------------------------- > _______________________________________________ > VoiceOps mailing list > VoiceOps at voiceops.org > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.neth… ------------------------------ Message: 4 Date: Wed, 26 May 2021 14:38:53 -0500 From: Mary Lou Carey <marylou at backuptelecom.com> To: voiceops at voiceops.org Subject: [VoiceOps] Robocall mitigation SCAM! Message-ID: <978d2c6b8d26de81c4686156b823f5b3 at backuptelecom.com> Content-Type: text/plain; charset=US-ASCII; format=flowed I just heard through the grapevine that several companies have been shut down and/or threatened with the confiscation of their equipment for passing Robocall traffic. The companies that this happened to all claimed someone contacted them and told them to keep the TN/traffic up so they could help catch the offenders. Unfortunately, whoever is advising carriers to keep the traffic up is not on the up and up. The ITG and large carriers came in and shut them down because they continued to pass traffic that was identified as robocalls. If someone contacts your company about a trace back and advises you to keep the TNs / traffic up, DO NOT LEAVE IT UP! Document everything and turn down the Robocall traffic as soon as possible! Then send both the ITG and large carrier involved the account number and CDRs for the calls in question. Be safe out there.....it's getting crazy! MARY LOU CAREY BackUP Telecom Consulting Office: 615-791-9969 Cell: 615-796-1111 ------------------------------ Message: 5 Date: Wed, 26 May 2021 15:50:58 -0400 From: Mark Lindsey <lindsey at e-c-group.com> To: Mary Lou Carey <marylou at backuptelecom.com> Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] Robocall mitigation SCAM! Message-ID: <CBAAC14A-7815-4D2C-ADEA-64946F8F52C7 at e-c-group.com> Content-Type: text/plain; charset="us-ascii" Good tips, Mary Lou! Do you think there's potentially any good intentions behind the advice to leave the traffic up? In the cybersecurity space, authorities will say that if your network has been compromised, you shouldn't immediately shutdown the hacked systems. For example, just this past September, this Joint Cybersecurity Advisory (AA20-245A) from the US and a few other governments... https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fus-cert.c… Under actions to avoid: "Mitigating the affected systems before responders can protect and recover data - This can cause the loss of volatile data such as memory and other host-based artifacts. - The adversary may notice and change their tactics, techniques, and procedures." Mark R Lindsey, SMTS | +1-229-316-0013 | mark at ecg.co | https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fecg.co%2F… <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fecg.co%2F…> > On May 26, 2021, at 3:38 PM, Mary Lou Carey <marylou at backuptelecom.com> wrote: > > I just heard through the grapevine that several companies have been shut down and/or threatened with the confiscation of their equipment for passing Robocall traffic. The companies that this happened to all claimed someone contacted them and told them to keep the TN/traffic up so they could help catch the offenders. Unfortunately, whoever is advising carriers to keep the traffic up is not on the up and up. The ITG and large carriers came in and shut them down because they continued to pass traffic that was identified as robocalls. > > If someone contacts your company about a trace back and advises you to keep the TNs / traffic up, DO NOT LEAVE IT UP! Document everything and turn down the Robocall traffic as soon as possible! Then send both the ITG and large carrier involved the account number and CDRs for the calls in question. > > Be safe out there.....it's getting crazy! > > MARY LOU CAREY > BackUP Telecom Consulting > Office: 615-791-9969 > Cell: 615-796-1111 > _______________________________________________ > VoiceOps mailing list > VoiceOps at voiceops.org > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpuck.neth…

1 0

Caveat to the 2023 STIR/SHAKEN extension for small companies
by marylou＠backuptelecom.com May 26, 2021

May 26, 2021

One more thing.....I also found out that there's a caveat to the June 30, 2023 extension for small carriers. Although the FCC granted smaller carriers an extension to implement STIR/SHAKEN, that does not exempt your company from filing your Robocall Mitigation Plan by June 30th, 2021. So smaller carriers should get registered with the Robocall Mitigation Database ASAP and file your Robocall Mitigation plan by June 30, 2021. Then you will be given until June 30, 2023 to implement it. The mitigation database registration requires that you to have your FRNs and your 499 filing completed in order to submit your plan. Just trying to pass on all the information I run across because there's been so much confusion surrounding the process! MARY LOU CAREY BackUP Telecom Consulting Office: 615-791-9969 Cell: 615-796-1111

1 0

Robocall mitigation SCAM!
by marylou＠backuptelecom.com May 26, 2021

May 26, 2021

I just heard through the grapevine that several companies have been shut down and/or threatened with the confiscation of their equipment for passing Robocall traffic. The companies that this happened to all claimed someone contacted them and told them to keep the TN/traffic up so they could help catch the offenders. Unfortunately, whoever is advising carriers to keep the traffic up is not on the up and up. The ITG and large carriers came in and shut them down because they continued to pass traffic that was identified as robocalls. If someone contacts your company about a trace back and advises you to keep the TNs / traffic up, DO NOT LEAVE IT UP! Document everything and turn down the Robocall traffic as soon as possible! Then send both the ITG and large carrier involved the account number and CDRs for the calls in question. Be safe out there.....it's getting crazy! MARY LOU CAREY BackUP Telecom Consulting Office: 615-791-9969 Cell: 615-796-1111

4 5

STIR SHAKEN requirement due by June 30th
by marylou＠backuptelecom.com May 25, 2021

May 25, 2021

Just wanted to give everyone an update on STIR/SHAKEN because the due date to be compliant is June 30th and a few changes have been made to the process recently (Last one was May 10th). I just spoke with Michael Nemcik at the FCC on Friday and with Brent Struthers with the STI-GA this morning to verify all this information because there's been a lot of confusion about the process. The first change is that EVERY CARRIER needs to sign up for the mitigation database! Before you can comply with this final mitigation database step, you'll need: 1. 499 account (and FRNs for each associated company) 2. Company Code (aka OCN) 3. Robocall Mitigation Database plan NOTE: If you have not gotten a STIR/SHAKEN certificate AND/OR are not 100% compliant yet you'll have to submit the Robocall Mitigation Plan when you register for the database. There are only guidelines as to what your plan must include so you can write your own or get a consultant to help you! Follow the process below to sign up for the Mitigation Database. There is no pre-registration process to qualify for a token. You'll register and note that you are either fully compliant, partially compliant or not compliant at all. Don't tell them what you plan to be on June 30th - list what you are today. ONCE YOU ARE FULLY COMPLIANT, THEN YOU CAN LOG BACK IN AND CHANGE YOUR STATUS! Second change made earlier this year is that your company no longer needs to be certified as a CLEC, ILEC, IPES, or Wireless Carrier to get a STIR/SHAKEN certificate! If you' file 499s and have an agreement with a DID provider, you can get an OCN assigned and qualify for the STIR/SHAKEN certificate by completing the mitigation database process. Once your name has been published on the FCC site for the mitigation database, you can register with the STI-PA and work with a Certificate Authority to get a token and test your traffic. ------------------------------------------------------------------------- Below are the links for the Mitigation Database piece -------------------------------------------------------------------------: a. Associate your FRNs with your 499 filer ID. https://apps.fcc.gov/cores/html/Associate_Username_to_FRN.htm b. Sign up for Mitigation Database https://www.fcc.gov/licensing-databases/fcc-user-login?fromURI=https%3A%2F%… parm_uri%253D%25252Fnav_to.do%25253Furi%25253D%2525252Frmd%2525253Fid%2525253Drmd_landing 1). Answer your current status: (fully compliant, partially compliant, non-compliant) 2). Submit your "Robocall Mitigation Plan" 4. Register with the STI-PA https://authenticate.iconectiv.com/service-provider-authenticate 5. Select a Certificate Authority to assign your token and test with: https://authenticate.iconectiv.com/certification-authority-authenticate 6. If you have not filed as 100% compliant, go back into the mitigation database when you are done testing and revise your status to "100% compliant!" If you have any questions, just give me a call! MARY LOU CAREY BackUP Telecom Consulting Office: 615-791-9969 Cell: 615-796-1111

2 3