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 | m...@ecg.co | Schedule a Meeting [2]
| Newsletter [3]
On Jun 30, 2023, at 17:00, Mary Lou Carey via VoiceOps
<voiceops@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@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops
Links:
------
[1]
https://www.linkedin.com/pulse/stirshaken-how-investigators-can-tell-youre-compliant-mark-lindsey/?trackingId=ooNgRZYHQ5eltXyut2F7dw==
[2] https://ecg.co/lindsey/schedule
[3]
https://www.linkedin.com/newsletters/mark-lindsey-voice-7021614437413330944/
_______________________________________________
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops
