Good catch. I just casually scrolled through the list of companies in the Robocall Mitigation Database & stumbled across a Panamanian company and an Australian company that both claim to have "complete" STIR/SHAKEN implementations. Yet I can confirm that neither company shows up either in the 499 Filer ID database, nor in iconectiv's list of Service Provider accounts that they have authorized to have access to the STI-PA and to generate SP tokens. The FCC FRNs for both companies were also generated fairly recently. I wonder if these foreign companies got concerned about making sure that international calls originating from their networks were getting signed with a high attestation on ingress into the U.S., arranged for this to be the case with whomever they are interconnecting with over on our shores, thought that they had to be listed in the RMD for some reason (do they? Are int'l telecoms required to be in the RMD and file an actual mitigation plan if they want to originate calls to the U.S.?), also assumed/misunderstood that having another party sign & attest their calls for them is enough to claim a "complete" implementation, and so that's why they filed the way they did. (Trying to be generous / assume the best here.) Since implementing S/S in the U.S. requires a 499 Filer ID, it is actually kind of infuriating that the RMD does not have 499 Filer ID as a required field on their form. That would nip this issue right in the bud if they did. -- Nathan -----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Markus via VoiceOps Sent: Thursday, July 6, 2023 1:07 PM To: voiceops at voiceops.org Subject: Re: [VoiceOps] STIR/SHAKEN warning! Am 04.07.2023 um 07:35 schrieb Paul Timmins:
What if I'm an European telecom operator and have US-based end-users (via SIP) who are calling to the US and who would like to signal their United States A-number to the called party?
What if I'm an European telecom operator and have Euro end-users (via SIP) who are calling to the US and who would like to signal their European A-number to the called party?
If I try to register here - https://authenticatereg.iconectiv.com/register - "Country: United States" is hard-coded.
Is there a way for Euro TSPs to get STIR/SHAKEN without creating a US entity/company just for this purpose?
I'm pretty sure it's the job of whoever is providing gateway services into the USA to sign the call, and that anyone in the STIR/SHAKEN system in the US has some sort of regulatory nexus here where they could be held legally responsible. It's all about finding a throat to choke if there's misconduct.
I asked iconectiv that question and now I have clarity: Me: "I have some fundamental questions about STIR/SHAKEN: What if I'm an European telecom operator and have US-based end-users (via SIP) who are calling to the US and who would like to signal their United States A-number to the called party? -> Do we need to get a STIR/SHAKEN certificate? [...]" iconectiv: "The revised SPC token Access Policy requires providers seeking to register with the STI-Policy Administrator (STI-PA) to: 1) Have a current form 499A on file with the FCC; 2) Have been assigned an Operating Company Number (OCN); [...] Me: "Since registering as 499A and getting an own OCN is only possible for US companies, I figure getting a STIR/SHAKEN certificate through you is currently not possible for non-US companies. Is that correct?" iconectiv: "That is correct." The confusion also came from the fact that many non-US companies that registered in the Robocall Mitigation Database - https://fccprod.servicenowservices.com/rmd?id=rmd_listings - chose "Complete STIR/SHAKEN implementation" or "Partial STIR/SHAKEN implementation", which, unless they also have a US subsidiary, seems to be a lie. Probably they chose something that looked cool in the dropdown box, or were too lazy to develop a Robocall Mitigation Plan (this is what you gotta upload as DOCUMENT if you choose "No STIR/SHAKEN implementation". I also noticed some non-US companies just uploaded some random document to the database, like a high school report or just some random letters or words... so much about the quality of that database. Good luck Markus _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
I checked in with iconectiv to get a bit more clarification. iconectiv does not speak authoritatively as to what it takes to get a 499A filer ID, nor an OCN. Of course, I don't either. You should go to the respective authorities (USAC and NECA) to make your applications. There ARE foreign entities with 499A filer IDs. For example: https://apps.fcc.gov/cgb/form499/499detail.cfm?FilerNum=834713 Their address is in Singapore. You'll find that they have a SHAKEN token (listed by iconectiv as an Authorized Provider). Also this one in Hong Kong: https://apps.fcc.gov/cgb/form499/499detail.cfm?FilerNum=834534 And this one in Canada: https://apps.fcc.gov/cgb/form499/499detail.cfm?FilerNum=832443 Also both listed by iconectiv as Authorized Providers. iconectiv may ask you for a US address, but they won't send you any mail. Thus, you can see that foreign providers CAN get SHAKEN tokens. For 499A filing, you'll probably need a US address for legal service of documents; there are third party agents you can engage for this. Perhaps that address is also good for iconectiv. Point is, you can navigate this if you so choose, and I'm sure you can make it through the NECA process as well to obtain an OCN. I don't have any reason to believe that the examples given above were created through some nefarious process. The best reason I heard (really) for a foreign entity being "unable" to obtain a SHAKEN token: "We didn't attempt to get one." That said, there are also plenty of specious Robocall Mitigation Database filings, including false certification as to S/S implementation, and garbage filed as a Robocall Mitigation Plan. Those providers are presumably on thin ice, as the FCC has recently revised their own rules to make it easier for them to delist such filings from the RMD.
participants (2)
-
dfrankel＠zipdx.com -
nathana＠fsr.com