I've heard from several clients that their upstream carrier told them they don't need to worry about being STIR/SHAKEN compliant because they are taking care of everything for them. THAT IS NOT CORRECT! Every phone company is required to have its own certificate/token! It doesn't matter if you're a reseller or a facilities-based carrier. Whoever bills the customer is the carrier of record and is responsible for signing the customer's calls with THEIR OWN certificate/token. While an upstream carrier can sign calls for your company, they must sign with YOUR certificate/token - not their own because they don't have a direct connection with your customer. Please understand that you're putting your network at risk when you share a token with another company because there's no way to differentiate between traffic when it's all under the same certificate/token. If your upstream carrier signs all their customer's traffic with their token, it only takes one bad customer to shut their whole network down. The only way to protect your company from other companies' mistakes is to make sure your upstream carrier is signing your calls with your certificate/token. One may not think they can get away with using someone else's certificate/token because it would be difficult to monitor the call stream for offenders. Let me just tell you the ITG can easily compare the Robocall Mitigation Database with the Approved Carriers list to locate the companies that don't have their own certificate/token. They don't need to look at traffic to determine that. Please don't play Russian roulette with your company because it's not worth losing your whole business over the cost of a certificate/token. Getting your own certificate/token can take anywhere from 2 weeks to 2 months depending on where you are in the process. From what I've heard, the FCC will start blocking traffic in August so if you haven't started the process....do so now! MARY LOU CAREY BackUP Telecom Consulting Office: 615-791-9969 Cell: 615-796-1111
Like Mary Lou, I'd like to help all voice service providers get their STIR/SHAKEN implementations up and running. And it's crucial to do verification as well as attestation! <https://www.linkedin.com/pulse/stirshaken-how-investigators-can-tell-youre-c...> There are a lot of good options -- I'm personally seeing a lot of activity around Neustar, Sansay, and Transnexus. I personally like to implement the HTTPS REST interface, but most implementations are doing it with SIP and 302. I think I've configured over 10 different variations so far. There are tons of technical methods. BUT... the rules on this third-party SHAKEN are not completely clear cut; I tell my clients that "the jury is still out," because the FCC is still seeking comment on whether this is appropriate. I'm expecting rules to be issued clarifying it. To read more about where the FCC is on this, see the section starting at Paragraph 99 in FCC-23-18A1 published March 17, 2023: We seek comment on whether, and under what circumstances, a third party may authenticate calls on behalf of a provider with A- or B-level attestations consistent with the ATIS standards. Pursuant to ATIS-1000074, in order to apply a B-level attestation for a call, the signing party must originate the call onto the IP-based service network and have a direct authenticated relationship with the customer.An A-level attestation additionally requires the signing provider to establish a verified association with the telephone number used for the call.341 Can a third-party authenticating a call on behalf of an originating provider satisfy all or any these criteria, and if so, how? Does the answer to that question depend on the nature of the relationship between the originating provider and the third party? For instance, is it possible for a third party that is a wholesale provider for a reseller, or an intermediate provider, to apply A- or B-level attestations on behalf of an originating provider in a manner that complies with the ATIS attestation-level criteria, but not a different type of third party? Are there third parties authenticating calls on behalf of originating providers that can only apply C-level attestations under the ATIS criteria? If commenters contend that third parties can meet the ATIS criteria for signing calls with A- and B-level attestations because they effectively stand in the shoes of the originating provider with the direct relationship with the customer, we ask that they specify the legal bases for that conclusion, e.g., the specific grounds for an agency theory, if any, and/or how the terms of the ATIS standards may be construed to include the third-party arrangement. To the extent commenters contend that third parties may satisfy the criteria to sign calls with A- or B-level attestations, what information must be shared between originating providers and third parties for those attestation levels to be applied, is that information sharing occurring, and does it implicate any legal or public interest concerns, including privacy concerns? Read it here: https://docs.fcc.gov/public/attachments/FCC-23-18A1.pdf Mark R Lindsey | +1-229-316-0013 | mrl at ecg.co | Schedule a Meeting <https://ecg.co/lindsey/schedule> | Newsletter <https://www.linkedin.com/newsletters/mark-lindsey-voice-7021614437413330944/>
On Jun 30, 2023, at 17:00, Mary Lou Carey via VoiceOps <voiceops at voiceops.org> wrote:
I've heard from several clients that their upstream carrier told them they don't need to worry about being STIR/SHAKEN compliant because they are taking care of everything for them.
THAT IS NOT CORRECT! Every phone company is required to have its own certificate/token!
It doesn't matter if you're a reseller or a facilities-based carrier. Whoever bills the customer is the carrier of record and is responsible for signing the customer's calls with THEIR OWN certificate/token. While an upstream carrier can sign calls for your company, they must sign with YOUR certificate/token - not their own because they don't have a direct connection with your customer.
Please understand that you're putting your network at risk when you share a token with another company because there's no way to differentiate between traffic when it's all under the same certificate/token. If your upstream carrier signs all their customer's traffic with their token, it only takes one bad customer to shut their whole network down. The only way to protect your company from other companies' mistakes is to make sure your upstream carrier is signing your calls with your certificate/token.
One may not think they can get away with using someone else's certificate/token because it would be difficult to monitor the call stream for offenders. Let me just tell you the ITG can easily compare the Robocall Mitigation Database with the Approved Carriers list to locate the companies that don't have their own certificate/token. They don't need to look at traffic to determine that.
Please don't play Russian roulette with your company because it's not worth losing your whole business over the cost of a certificate/token. Getting your own certificate/token can take anywhere from 2 weeks to 2 months depending on where you are in the process. From what I've heard, the FCC will start blocking traffic in August so if you haven't started the process....do so now!
MARY LOU CAREY BackUP Telecom Consulting Office: 615-791-9969 Cell: 615-796-1111 _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Thanks for the input, Mark! I'm going to call my contacts at the FCC as well and ask specifically what their stance o this is because from what I've heard they plan to start enforcing STIR/SHAKEN in August. That could be devastating to many since so many of the underlying carriers have been telling their clients they don't need their own certificate/token. MARY LOU CAREY BackUP Telecom Consulting Office: 615-791-9969 Cell: 615-796-1111 On 2023-06-30 05:28 PM, Mark R Lindsey wrote:
Like Mary Lou, I'd like to help all voice service providers get their STIR/SHAKEN implementations up and running. And it's crucial to do verification as well as attestation! [1]
There are a lot of good options -- I'm personally seeing a lot of activity around Neustar, Sansay, and Transnexus. I personally like to implement the HTTPS REST interface, but most implementations are doing it with SIP and 302. I think I've configured over 10 different variations so far. There are tons of technical methods.
BUT... the rules on this third-party SHAKEN are not completely clear cut; I tell my clients that "the jury is still out," because the FCC is still seeking comment on whether this is appropriate. I'm expecting rules to be issued clarifying it.
To read more about where the FCC is on this, see the section starting at Paragraph 99 in FCC-23-18A1 published March 17, 2023:
We seek comment on whether, and under what circumstances, a third party may authenticate calls on behalf of a provider with A- or B-level attestations consistent with the ATIS standards. Pursuant to ATIS-1000074, in order to apply a B-level attestation for a call, the signing party must originate the call onto the IP-based service network and have a direct authenticated relationship with the customer.An A-level attestation additionally requires the signing provider to establish a verified association with the telephone number used for the call.341 Can a third-party authenticating a call on behalf of an originating provider satisfy all or any these criteria, and if so, how? Does the answer to that question depend on the nature of the relationship between the originating provider and the third party? For instance, is it possible for a third party that is a wholesale provider for a reseller, or an intermediate provider, to apply A- or B-level attestations on behalf of an originating provider in a manner that complies with the ATIS attestation-level criteria, but not a different type of third party? Are there third parties authenticating calls on behalf of originating providers that can only apply C-level attestations under the ATIS criteria? If commenters contend that third parties can meet the ATIS criteria for signing calls with A- and B-level attestations because they effectively stand in the shoes of the originating provider with the direct relationship with the customer, we ask that they specify the legal bases for that conclusion, e.g., the specific grounds for an agency theory, if any, and/or how the terms of the ATIS standards may be construed to include the third-party arrangement.
To the extent commenters contend that third parties may satisfy the criteria to sign calls with A- or B-level attestations, what information must be shared between originating providers and third parties for those attestation levels to be applied, is that information sharing occurring, and does it implicate any legal or public interest concerns, including privacy concerns?
Read it here: https://docs.fcc.gov/public/attachments/FCC-23-18A1.pdf
Mark R Lindsey | +1-229-316-0013 | mrl at ecg.co | Schedule a Meeting [2] | Newsletter [3]
On Jun 30, 2023, at 17:00, Mary Lou Carey via VoiceOps <voiceops at voiceops.org> wrote:
I've heard from several clients that their upstream carrier told them they don't need to worry about being STIR/SHAKEN compliant because they are taking care of everything for them.
THAT IS NOT CORRECT! Every phone company is required to have its own certificate/token!
It doesn't matter if you're a reseller or a facilities-based carrier. Whoever bills the customer is the carrier of record and is responsible for signing the customer's calls with THEIR OWN certificate/token. While an upstream carrier can sign calls for your company, they must sign with YOUR certificate/token - not their own because they don't have a direct connection with your customer.
Please understand that you're putting your network at risk when you share a token with another company because there's no way to differentiate between traffic when it's all under the same certificate/token. If your upstream carrier signs all their customer's traffic with their token, it only takes one bad customer to shut their whole network down. The only way to protect your company from other companies' mistakes is to make sure your upstream carrier is signing your calls with your certificate/token.
One may not think they can get away with using someone else's certificate/token because it would be difficult to monitor the call stream for offenders. Let me just tell you the ITG can easily compare the Robocall Mitigation Database with the Approved Carriers list to locate the companies that don't have their own certificate/token. They don't need to look at traffic to determine that.
Please don't play Russian roulette with your company because it's not worth losing your whole business over the cost of a certificate/token. Getting your own certificate/token can take anywhere from 2 weeks to 2 months depending on where you are in the process. From what I've heard, the FCC will start blocking traffic in August so if you haven't started the process....do so now!
MARY LOU CAREY BackUP Telecom Consulting Office: 615-791-9969 Cell: 615-796-1111 _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Links: ------ [1] https://www.linkedin.com/pulse/stirshaken-how-investigators-can-tell-youre-c... [2] https://ecg.co/lindsey/schedule [3] https://www.linkedin.com/newsletters/mark-lindsey-voice-7021614437413330944/
I would love an update here. We are an ultra tiny MSP, and have been told all along by the major ULCs we use that we?re fine. They are signing, all good. This is a monstrous change relative to our size and capital. On Jul 3, 2023 at 11:09:33 AM, Mary Lou Carey via VoiceOps < voiceops at voiceops.org> wrote:
Thanks for the input, Mark! I'm going to call my contacts at the FCC as well and ask specifically what their stance o this is because from what I've heard they plan to start enforcing STIR/SHAKEN in August. That could be devastating to many since so many of the underlying carriers have been telling their clients they don't need their own certificate/token.
MARY LOU CAREY BackUP Telecom Consulting Office: 615-791-9969 Cell: 615-796-1111
On 2023-06-30 05:28 PM, Mark R Lindsey wrote:
Like Mary Lou, I'd like to help all voice service providers get their
STIR/SHAKEN implementations up and running. And it's crucial to do
verification as well as attestation! [1]
There are a lot of good options -- I'm personally seeing a lot of
activity around Neustar, Sansay, and Transnexus. I personally like to
implement the HTTPS REST interface, but most implementations are doing
it with SIP and 302. I think I've configured over 10 different
variations so far. There are tons of technical methods.
BUT... the rules on this third-party SHAKEN are not completely clear
cut; I tell my clients that "the jury is still out," because the FCC
is still seeking comment on whether this is appropriate. I'm expecting
rules to be issued clarifying it.
To read more about where the FCC is on this, see the section starting
at Paragraph 99 in FCC-23-18A1 published March 17, 2023:
We seek comment on whether, and under what circumstances, a third
party may authenticate calls on behalf of a provider with A- or
B-level attestations consistent with the ATIS standards. Pursuant to
ATIS-1000074, in order to apply a B-level attestation for a call,
the signing party must originate the call onto the IP-based service
network and have a direct authenticated relationship with the
customer.An A-level attestation additionally requires the signing
provider to establish a verified association with the telephone
number used for the call.341 Can a third-party authenticating a call
on behalf of an originating provider satisfy all or any these
criteria, and if so, how? Does the answer to that question depend on
the nature of the relationship between the originating provider and
the third party? For instance, is it possible for a third party that
is a wholesale provider for a reseller, or an intermediate provider,
to apply A- or B-level attestations on behalf of an originating
provider in a manner that complies with the ATIS attestation-level
criteria, but not a different type of third party? Are there third
parties authenticating calls on behalf of originating providers that
can only apply C-level attestations under the ATIS criteria? If
commenters contend that third parties can meet the ATIS criteria for
signing calls with A- and B-level attestations because they
effectively stand in the shoes of the originating provider with the
direct relationship with the customer, we ask that they specify the
legal bases for that conclusion, e.g., the specific grounds for an
agency theory, if any, and/or how the terms of the ATIS standards
may be construed to include the third-party arrangement.
To the extent commenters contend that third parties may satisfy the
criteria to sign calls with A- or B-level attestations, what
information must be shared between originating providers and third
parties for those attestation levels to be applied, is that
information sharing occurring, and does it implicate any legal or
public interest concerns, including privacy concerns?
Read it here: https://docs.fcc.gov/public/attachments/FCC-23-18A1.pdf
Mark R Lindsey | +1-229-316-0013 | mrl at ecg.co | Schedule a Meeting [2]
| Newsletter [3]
On Jun 30, 2023, at 17:00, Mary Lou Carey via VoiceOps
<voiceops at voiceops.org> wrote:
I've heard from several clients that their upstream carrier told
them they don't need to worry about being STIR/SHAKEN compliant
because they are taking care of everything for them.
THAT IS NOT CORRECT! Every phone company is required to have its own
certificate/token!
It doesn't matter if you're a reseller or a facilities-based
carrier. Whoever bills the customer is the carrier of record and is
responsible for signing the customer's calls with THEIR OWN
certificate/token. While an upstream carrier can sign calls for your
company, they must sign with YOUR certificate/token - not their own
because they don't have a direct connection with your customer.
Please understand that you're putting your network at risk when you
share a token with another company because there's no way to
differentiate between traffic when it's all under the same
certificate/token. If your upstream carrier signs all their
customer's traffic with their token, it only takes one bad customer
to shut their whole network down. The only way to protect your
company from other companies' mistakes is to make sure your upstream
carrier is signing your calls with your certificate/token.
One may not think they can get away with using someone else's
certificate/token because it would be difficult to monitor the call
stream for offenders. Let me just tell you the ITG can easily
compare the Robocall Mitigation Database with the Approved Carriers
list to locate the companies that don't have their own
certificate/token. They don't need to look at traffic to determine
that.
Please don't play Russian roulette with your company because it's
not worth losing your whole business over the cost of a
certificate/token. Getting your own certificate/token can take
anywhere from 2 weeks to 2 months depending on where you are in the
process. From what I've heard, the FCC will start blocking traffic
in August so if you haven't started the process....do so now!
MARY LOU CAREY
BackUP Telecom Consulting
Office: 615-791-9969
Cell: 615-796-1111
_______________________________________________
VoiceOps mailing list
VoiceOps at voiceops.org
Links:
------
[1]
https://www.linkedin.com/pulse/stirshaken-how-investigators-can-tell-youre-c...
[2] https://ecg.co/lindsey/schedule
[3]
https://www.linkedin.com/newsletters/mark-lindsey-voice-7021614437413330944/
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
My understanding is that they can still sign for you, but they should be signing with YOUR certificate/token and not their own. That only adds the cost of the certificate/token to your budget. MARY LOU CAREY BackUP Telecom Consulting Office: 615-791-9969 Cell: 615-796-1111 On 2023-07-03 01:45 PM, Carlos Alvarez via VoiceOps wrote:
I would love an update here. We are an ultra tiny MSP, and have been told all along by the major ULCs we use that we?re fine. They are signing, all good. This is a monstrous change relative to our size and capital.
On Jul 3, 2023 at 11:09:33 AM, Mary Lou Carey via VoiceOps <voiceops at voiceops.org> wrote:
Thanks for the input, Mark! I'm going to call my contacts at the FCC as well and ask specifically what their stance o this is because from what I've heard they plan to start enforcing STIR/SHAKEN in August. That could be devastating to many since so many of the underlying carriers have been telling their clients they don't need their own certificate/token.
MARY LOU CAREY BackUP Telecom Consulting Office: 615-791-9969 Cell: 615-796-1111
On 2023-06-30 05:28 PM, Mark R Lindsey wrote:
Like Mary Lou, I'd like to help all voice service providers get their
STIR/SHAKEN implementations up and running. And it's crucial to do
verification as well as attestation! [1]
There are a lot of good options -- I'm personally seeing a lot of
activity around Neustar, Sansay, and Transnexus. I personally like to
implement the HTTPS REST interface, but most implementations are doing
it with SIP and 302. I think I've configured over 10 different
variations so far. There are tons of technical methods.
BUT... the rules on this third-party SHAKEN are not completely clear
cut; I tell my clients that "the jury is still out," because the FCC
is still seeking comment on whether this is appropriate. I'm expecting
rules to be issued clarifying it.
To read more about where the FCC is on this, see the section starting
at Paragraph 99 in FCC-23-18A1 published March 17, 2023:
We seek comment on whether, and under what circumstances, a third
party may authenticate calls on behalf of a provider with A- or
B-level attestations consistent with the ATIS standards. Pursuant to
ATIS-1000074, in order to apply a B-level attestation for a call,
the signing party must originate the call onto the IP-based service
network and have a direct authenticated relationship with the
customer.An A-level attestation additionally requires the signing
provider to establish a verified association with the telephone
number used for the call.341 Can a third-party authenticating a call
on behalf of an originating provider satisfy all or any these
criteria, and if so, how? Does the answer to that question depend on
the nature of the relationship between the originating provider and
the third party? For instance, is it possible for a third party that
is a wholesale provider for a reseller, or an intermediate provider,
to apply A- or B-level attestations on behalf of an originating
provider in a manner that complies with the ATIS attestation-level
criteria, but not a different type of third party? Are there third
parties authenticating calls on behalf of originating providers that
can only apply C-level attestations under the ATIS criteria? If
commenters contend that third parties can meet the ATIS criteria for
signing calls with A- and B-level attestations because they
effectively stand in the shoes of the originating provider with the
direct relationship with the customer, we ask that they specify the
legal bases for that conclusion, e.g., the specific grounds for an
agency theory, if any, and/or how the terms of the ATIS standards
may be construed to include the third-party arrangement.
To the extent commenters contend that third parties may satisfy the
criteria to sign calls with A- or B-level attestations, what
information must be shared between originating providers and third
parties for those attestation levels to be applied, is that
information sharing occurring, and does it implicate any legal or
public interest concerns, including privacy concerns?
Read it here: https://docs.fcc.gov/public/attachments/FCC-23-18A1.pdf
Mark R Lindsey | +1-229-316-0013 | mrl at ecg.co | Schedule a Meeting [2]
| Newsletter [3]
On Jun 30, 2023, at 17:00, Mary Lou Carey via VoiceOps
<voiceops at voiceops.org> wrote:
I've heard from several clients that their upstream carrier told
them they don't need to worry about being STIR/SHAKEN compliant
because they are taking care of everything for them.
THAT IS NOT CORRECT! Every phone company is required to have its own
certificate/token!
It doesn't matter if you're a reseller or a facilities-based
carrier. Whoever bills the customer is the carrier of record and is
responsible for signing the customer's calls with THEIR OWN
certificate/token. While an upstream carrier can sign calls for your
company, they must sign with YOUR certificate/token - not their own
because they don't have a direct connection with your customer.
Please understand that you're putting your network at risk when you
share a token with another company because there's no way to
differentiate between traffic when it's all under the same
certificate/token. If your upstream carrier signs all their
customer's traffic with their token, it only takes one bad customer
to shut their whole network down. The only way to protect your
company from other companies' mistakes is to make sure your upstream
carrier is signing your calls with your certificate/token.
One may not think they can get away with using someone else's
certificate/token because it would be difficult to monitor the call
stream for offenders. Let me just tell you the ITG can easily
compare the Robocall Mitigation Database with the Approved Carriers
list to locate the companies that don't have their own
certificate/token. They don't need to look at traffic to determine
that.
Please don't play Russian roulette with your company because it's
not worth losing your whole business over the cost of a
certificate/token. Getting your own certificate/token can take
anywhere from 2 weeks to 2 months depending on where you are in the
process. From what I've heard, the FCC will start blocking traffic
in August so if you haven't started the process....do so now!
MARY LOU CAREY
BackUP Telecom Consulting
Office: 615-791-9969
Cell: 615-796-1111
_______________________________________________
VoiceOps mailing list
VoiceOps at voiceops.org
Links:
------
[1]
https://www.linkedin.com/pulse/stirshaken-how-investigators-can-tell-youre-c...
[3]
https://www.linkedin.com/newsletters/mark-lindsey-voice-7021614437413330944/
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
Am 30.06.2023 um 23:00 schrieb Mary Lou Carey via VoiceOps:
I've heard from several clients that their upstream carrier told them they don't need to worry about being STIR/SHAKEN compliant because they are taking care of everything for them.
THAT IS NOT CORRECT! Every phone company is required to have its own certificate/token!
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?
On Jul 3, 2023, at 8:05 PM, Markus via VoiceOps <voiceops at voiceops.org> wrote:
Am 30.06.2023 um 23:00 schrieb Mary Lou Carey via VoiceOps:
I've heard from several clients that their upstream carrier told them they don't need to worry about being STIR/SHAKEN compliant because they are taking care of everything for them. THAT IS NOT CORRECT! Every phone company is required to have its own certificate/token!
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. The liability would be on whoever sells you service. I think the long term idea is that other STIs would set up around the world over time and there would be a collection of root certificates much like browser SSL stacks, so you could authenticate calls that came in from other countries and tie them back to a regulatory regime that can hold them responsible. Unless Mary has a different idea of what the plan is? -Paul
Some additional perspective on STIR/SHAKEN signing requirements. This is not legal advice; for that, turn to your qualified attorney well-versed in applicable telecommunications regulations (US Federal and State). Several relevant STIR/SHAKEN regulations are here: https://www.law.cornell.edu/cfr/text/47/part-64/subpart-HH. In particular, ? 64.6301(a)(2) says that "a voice service provider shall ... Authenticate caller identification information for all SIP calls it originates and that it will exchange with another voice service provider or intermediate provider and, to the extent technically feasible, transmit that call with authenticated caller identification information to the next voice service provider or intermediate provider in the call path." ? 64.6300(a) says "The term 'authenticate caller identification information' refers to the process by which a voice service provider attests to the accuracy of caller identification information transmitted with a call it originates." What Mary has said is consistent with this. If you are the originating Voice Service Provider, the call must be authenticated by you -- it must carry your signature. You can instruct somebody else to apply your signature per your specifications (including the level of attestation). But if you are the originating provider, the signature has to be yours. ? 64.6300(n) says "voice service" is one that "furnishes voice communications to an end user using resources from the North American Numbering Plan." So if your caller is using +1 numbers, then presumably you are a voice service provider covered by these rules. The rule doesn't specify whether you (or your customer) have to be in the United States or not; so I assume the rules apply globally. Also, interestingly, this particular rule doesn't seem to exclude NANP numbers that are not USA numbers, so the rule appears to apply to those calling with Canadian numbers and other non-USA +1 numbers. Different people might read the rule differently regarding FROM and TO numbers. Some might argue that if the FROM number is NOT a NANP number, even if the TO number is, then the rules do not apply. But it seems clear that if the call is FROM a NANP number, TO a NANP number, then you as the originating service provider would be required to authenticate that call with your signature (regardless of where in the world you and/or your customer are located). Paul alluded to limitations on the FCC's authority with respect to geography -- at least constraints on their ability to enforce. The FCC controls their Robocall Mitigation Database, and they do require downstream providers to only accept calls from other providers listed in the database. So by delisting a provider (wherever in the world that provider is), the FCC can restrict that provider's access to the US network. See 47 CFR ? 64.6305(e)(1) & (2). (2) is applicable to foreign providers that use "North American Numbering Plan resources that pertain to the United States in the caller ID field to send voice traffic to residential or business subscribers in the United States." So a US downstream provider could, if they so choose, accept calls from a foreign provider NOT listed in the RMD as long as the call has a non-USA number in the caller-ID field. There are new obligations (several of which went into effect this month) on so-called Gateway providers -- US-based providers that take calls from foreign providers. These are in 47 CFR ? 64.6303 and 6305 and generally require Gateway providers to sign unsigned calls. This gets to Paul's "throat to choke" point. The cost for a Service Provider to get their own SHAKEN token (so that their signature can appear on the calls they originate) is not egregious. You need an OCN, which NECA will give you for a one-time charge of $475. The STI-PA, iconectiv, charges an annual fee based on revenue to be registered as a SHAKEN service provider; the minimum is $500 for 2023 (as far as I can tell). You will then need to engage an STI-CA (certificate authority) to generate your certificate(s) for call signing. The STI-CA marketplace appears to be competitive, as confirmed by other commenters. As far as I know, it is possible for non-USA-based service providers to participate in this process; I see what I believe to be foreign entities registered on the iconectiv site (https://authenticate.iconectiv.com/authorized-service-providers-authenticat e). As mentioned, the FCC has on-going formal rule-making processes happening as we speak. You can see (and participate in) some of the relevant discussion here: https://www.fcc.gov/ecfs/search/search-filings/results?q=(proceedings.name:( %2217-97%22)+AND+submissiontype.description:(%22COMMENT%22%20OR%20%22REPLY%2 0TO%20COMMENTS%22%20OR%20%22NOTICE%20OF%20EXPARTE%22)). This public docket will see a lot more action tomorrow (Wednesday), which is the due-date for so-called "Reply Comments." The compliance burden for voice service providers does seem to be ever-increasing. This is not new or unique. Many tech businesses (not just telecoms) have evolving burdens for data privacy and security compliance (think GDPR); there are finance compliance burdens (think processing credit cards); the list goes on. The good news in telecom is that over the past couple of decades other costs have come down tremendously, which created the business opportunity in the first place. Compliance is a fact of life. If ultimately the compliance costs grow to the point that certain segments of your business are not profitable, then it is time to exit those segments. David Frankel
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
To answer your question regarding 499s and OCNs, foreign companies can acquire both. If you want to message me privately, I can give you the contact information of the person I refer foreign companies to. MARY LOU CAREY BackUP Telecom Consulting Office: 615-791-9969 Cell: 615-796-1111 On 2023-07-06 03:07 PM, Markus via VoiceOps wrote:
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
participants (6)
-
caalvarez＠gmail.com -
dfrankel＠zipdx.com -
lindsey＠e-c-group.com -
marylou＠backuptelecom.com -
paul＠timmins.net -
universe＠truemetal.org