<html><body><div dir="ltr">
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.</div><div dir="ltr"><br></div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Jul 3, 2023 at 11:09:33 AM, Mary Lou Carey via VoiceOps <<a href="mailto:voiceops@voiceops.org">voiceops@voiceops.org</a>> wrote:<br></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" type="cite">
<div>
<div>
Thanks for the input, Mark! I'm going to call my contacts at the FCC as <br>well and ask specifically what their stance o this is because from what <br>I've heard they plan to start enforcing STIR/SHAKEN in August. That <br>could be devastating to many since so many of the underlying carriers <br>have been telling their clients they don't need their own <br>certificate/token.<br><br>MARY LOU CAREY<br>BackUP Telecom Consulting<br>Office: 615-791-9969<br>Cell: 615-796-1111<br><br>On 2023-06-30 05:28 PM, Mark R Lindsey wrote:<br><blockquote type="cite"> Like Mary Lou, I'd like to help all voice service providers get their<br></blockquote><blockquote type="cite"> STIR/SHAKEN implementations up and running. And it's crucial to do<br></blockquote><blockquote type="cite"> verification as well as attestation! [1]<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> There are a lot of good options -- I'm personally seeing a lot of<br></blockquote><blockquote type="cite"> activity around Neustar, Sansay, and Transnexus. I personally like to<br></blockquote><blockquote type="cite"> implement the HTTPS REST interface, but most implementations are doing<br></blockquote><blockquote type="cite"> it with SIP and 302. I think I've configured over 10 different<br></blockquote><blockquote type="cite"> variations so far. There are tons of technical methods.<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> BUT... the rules on this third-party SHAKEN are not completely clear<br></blockquote><blockquote type="cite"> cut; I tell my clients that "the jury is still out," because the FCC<br></blockquote><blockquote type="cite"> is still seeking comment on whether this is appropriate. I'm expecting<br></blockquote><blockquote type="cite"> rules to be issued clarifying it.<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> To read more about where the FCC is on this, see the section starting<br></blockquote><blockquote type="cite"> at Paragraph 99 in FCC-23-18A1 published March 17, 2023:<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite">> We seek comment on whether, and under what circumstances, a third<br></blockquote><blockquote type="cite">> party may authenticate calls on behalf of a provider with A- or<br></blockquote><blockquote type="cite">> B-level attestations consistent with the ATIS standards. Pursuant to<br></blockquote><blockquote type="cite">> ATIS-1000074, in order to apply a B-level attestation for a call,<br></blockquote><blockquote type="cite">> the signing party must originate the call onto the IP-based service<br></blockquote><blockquote type="cite">> network and have a direct authenticated relationship with the<br></blockquote><blockquote type="cite">> customer.An A-level attestation additionally requires the signing<br></blockquote><blockquote type="cite">> provider to establish a verified association with the telephone<br></blockquote><blockquote type="cite">> number used for the call.341 Can a third-party authenticating a call<br></blockquote><blockquote type="cite">> on behalf of an originating provider satisfy all or any these<br></blockquote><blockquote type="cite">> criteria, and if so, how? Does the answer to that question depend on<br></blockquote><blockquote type="cite">> the nature of the relationship between the originating provider and<br></blockquote><blockquote type="cite">> the third party? For instance, is it possible for a third party that<br></blockquote><blockquote type="cite">> is a wholesale provider for a reseller, or an intermediate provider,<br></blockquote><blockquote type="cite">> to apply A- or B-level attestations on behalf of an originating<br></blockquote><blockquote type="cite">> provider in a manner that complies with the ATIS attestation-level<br></blockquote><blockquote type="cite">> criteria, but not a different type of third party? Are there third<br></blockquote><blockquote type="cite">> parties authenticating calls on behalf of originating providers that<br></blockquote><blockquote type="cite">> can only apply C-level attestations under the ATIS criteria? If<br></blockquote><blockquote type="cite">> commenters contend that third parties can meet the ATIS criteria for<br></blockquote><blockquote type="cite">> signing calls with A- and B-level attestations because they<br></blockquote><blockquote type="cite">> effectively stand in the shoes of the originating provider with the<br></blockquote><blockquote type="cite">> direct relationship with the customer, we ask that they specify the<br></blockquote><blockquote type="cite">> legal bases for that conclusion, e.g., the specific grounds for an<br></blockquote><blockquote type="cite">> agency theory, if any, and/or how the terms of the ATIS standards<br></blockquote><blockquote type="cite">> may be construed to include the third-party arrangement.<br></blockquote><blockquote type="cite">> <br></blockquote><blockquote type="cite">> To the extent commenters contend that third parties may satisfy the<br></blockquote><blockquote type="cite">> criteria to sign calls with A- or B-level attestations, what<br></blockquote><blockquote type="cite">> information must be shared between originating providers and third<br></blockquote><blockquote type="cite">> parties for those attestation levels to be applied, is that<br></blockquote><blockquote type="cite">> information sharing occurring, and does it implicate any legal or<br></blockquote><blockquote type="cite">> public interest concerns, including privacy concerns?<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> Read it here: <a href="https://docs.fcc.gov/public/attachments/FCC-23-18A1.pdf">https://docs.fcc.gov/public/attachments/FCC-23-18A1.pdf</a><br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> Mark R Lindsey | +1-229-316-0013 | <a href="mailto:mrl@ecg.co">mrl@ecg.co</a> | Schedule a Meeting [2]<br></blockquote><blockquote type="cite"> | Newsletter [3]<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite">> On Jun 30, 2023, at 17:00, Mary Lou Carey via VoiceOps<br></blockquote><blockquote type="cite">> <<a href="mailto:voiceops@voiceops.org">voiceops@voiceops.org</a>> wrote:<br></blockquote><blockquote type="cite">> <br></blockquote><blockquote type="cite">> I've heard from several clients that their upstream carrier told<br></blockquote><blockquote type="cite">> them they don't need to worry about being STIR/SHAKEN compliant<br></blockquote><blockquote type="cite">> because they are taking care of everything for them.<br></blockquote><blockquote type="cite">> <br></blockquote><blockquote type="cite">> THAT IS NOT CORRECT! Every phone company is required to have its own<br></blockquote><blockquote type="cite">> certificate/token!<br></blockquote><blockquote type="cite">> <br></blockquote><blockquote type="cite">> It doesn't matter if you're a reseller or a facilities-based<br></blockquote><blockquote type="cite">> carrier. Whoever bills the customer is the carrier of record and is<br></blockquote><blockquote type="cite">> responsible for signing the customer's calls with THEIR OWN<br></blockquote><blockquote type="cite">> certificate/token. While an upstream carrier can sign calls for your<br></blockquote><blockquote type="cite">> company, they must sign with YOUR certificate/token - not their own<br></blockquote><blockquote type="cite">> because they don't have a direct connection with your customer.<br></blockquote><blockquote type="cite">> <br></blockquote><blockquote type="cite">> Please understand that you're putting your network at risk when you<br></blockquote><blockquote type="cite">> share a token with another company because there's no way to<br></blockquote><blockquote type="cite">> differentiate between traffic when it's all under the same<br></blockquote><blockquote type="cite">> certificate/token. If your upstream carrier signs all their<br></blockquote><blockquote type="cite">> customer's traffic with their token, it only takes one bad customer<br></blockquote><blockquote type="cite">> to shut their whole network down. The only way to protect your<br></blockquote><blockquote type="cite">> company from other companies' mistakes is to make sure your upstream<br></blockquote><blockquote type="cite">> carrier is signing your calls with your certificate/token.<br></blockquote><blockquote type="cite">> <br></blockquote><blockquote type="cite">> One may not think they can get away with using someone else's<br></blockquote><blockquote type="cite">> certificate/token because it would be difficult to monitor the call<br></blockquote><blockquote type="cite">> stream for offenders. Let me just tell you the ITG can easily<br></blockquote><blockquote type="cite">> compare the Robocall Mitigation Database with the Approved Carriers<br></blockquote><blockquote type="cite">> list to locate the companies that don't have their own<br></blockquote><blockquote type="cite">> certificate/token. They don't need to look at traffic to determine<br></blockquote><blockquote type="cite">> that.<br></blockquote><blockquote type="cite">> <br></blockquote><blockquote type="cite">> Please don't play Russian roulette with your company because it's<br></blockquote><blockquote type="cite">> not worth losing your whole business over the cost of a<br></blockquote><blockquote type="cite">> certificate/token. Getting your own certificate/token can take<br></blockquote><blockquote type="cite">> anywhere from 2 weeks to 2 months depending on where you are in the<br></blockquote><blockquote type="cite">> process. From what I've heard, the FCC will start blocking traffic<br></blockquote><blockquote type="cite">> in August so if you haven't started the process....do so now!<br></blockquote><blockquote type="cite">> <br></blockquote><blockquote type="cite">> MARY LOU CAREY<br></blockquote><blockquote type="cite">> BackUP Telecom Consulting<br></blockquote><blockquote type="cite">> Office: 615-791-9969<br></blockquote><blockquote type="cite">> Cell: 615-796-1111<br></blockquote><blockquote type="cite">> _______________________________________________<br></blockquote><blockquote type="cite">> VoiceOps mailing list<br></blockquote><blockquote type="cite">> <a href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a><br></blockquote><blockquote type="cite">> <a href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a><br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> Links:<br></blockquote><blockquote type="cite"> ------<br></blockquote><blockquote type="cite"> [1]<br></blockquote><blockquote type="cite"> <a href="https://www.linkedin.com/pulse/stirshaken-how-investigators-can-tell-youre-compliant-mark-lindsey/?trackingId=ooNgRZYHQ5eltXyut2F7dw==">https://www.linkedin.com/pulse/stirshaken-how-investigators-can-tell-youre-compliant-mark-lindsey/?trackingId=ooNgRZYHQ5eltXyut2F7dw==</a><br></blockquote><blockquote type="cite"> [2] <a href="https://ecg.co/lindsey/schedule">https://ecg.co/lindsey/schedule</a><br></blockquote><blockquote type="cite"> [3] <br></blockquote><blockquote type="cite"> <a href="https://www.linkedin.com/newsletters/mark-lindsey-voice-7021614437413330944/">https://www.linkedin.com/newsletters/mark-lindsey-voice-7021614437413330944/</a><br></blockquote>_______________________________________________<br>VoiceOps mailing list<br><a href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a><br><a href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
</div>
</div>
</blockquote>
</div></body></html>