That’s what I thought, thank you for clarifying. I was just confused because of the language in Paul’s previous explanation—no fault of his.
But in the bottom of the barrel, it will leave some folks with a conundrum about what to do when XYZTelecom sends their good conversational traffic through their peer A, and their crappier traffic through their peer B. But I suppose that is the very dilemma that this technique is meant to force. — Sent from mobile, with due apologies for brevity and errors. > On Sep 2, 2020, at 3:01 PM, Mark Lindsey <[email protected]> wrote: > > SHAKEN doesn't record the chain (like you'd see with Via headers, for > example) of Intermediate Providers who handle the call. There's only one > Identity header and it is to be passed unchanged from the origin point to the > terminating Voice Service Provider. > > When the Identity header with PASSporT arrives at the final Voice Service > Provider, that recipient can determine who created the PASSporT and then make > judgments. For example, there has been a lot of discussion in FCC filings > about "reputation" of service providers. Perhaps you could subscribe to a > Reputation database to determine what to do with the calls. > > For example, "This call got an A level attestation from XYZTelecom, but > XYZTelecom has a 5% score in the reputation database, so I'm going to treat > it as if this call is likely a nuisance call." > > > > Mark R Lindsey, SMTS | +1-229-316-0013 | [email protected] | https://ecg.co/lindsey/ > > > > >> On Sep 2, 2020, at 2:52 PM, Alex Balashov <[email protected]> wrote: >> >> Thank you, that’s very clear and sums it all up! >> >> One lingering question: even without providing a fully attestable chain of >> custody, if the call took a route A -> B -> C, are signatures cumulative >> such that I could block calls attested by B coming through C? Or am I >> constrained to blocking a certain level of attestation only through the >> last/proximate peering hop (C) that directly touches me? >> >> I suppose success is going to come down to the on-the-ground realities, >> political viability, etc of taking that “block attested calls from carrier >> X” step. >> >> — >> Sent from mobile, with due apologies for brevity and errors. >> >>>> On Sep 2, 2020, at 2:47 PM, Paul Timmins <[email protected]> wrote: >>>> >>> >>> The solution is that you sign your calls with your certificate. Carriers >>> aren't doing LNP dips to verify the number is really yours, they're >>> trusting your attestation (A: yes, the caller id is verified, B: it comes >>> from our customer, but not verified, C: "this touched our switches, good >>> luck with it"). If you attest total nonsense as A, or send tons of nonsense >>> in general, people start blocking calls you sign. >>> >>> >>> >>> It really verifies who is sending the call, and what that company says the >>> call is verified, not a full chain of custody of the number back to the >>> NANPA/PA. Could you attest A a call from "0" or "911", or "999-999-9999"? >>> Yes, you could. It'd work for a while, til someone said "Wow, Alex's SPID >>> is signing tons of bullshit. Let's block attested calls from his SPID" >>> >>> >>> >>> -Paul >>> >>> >>> >>> From: VoiceOps <[email protected]> on behalf of Alex Balashov >>> <[email protected]> >>> Sent: Wednesday, September 2, 2020 2:42 PM >>> To: VoiceOps >>> Subject: Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup >>> >>> LCR or no LCR, using a termination vendor that is different to one’s >>> origination vendor for a given CID is more normal than not in VoIP. I would >>> guess it’s the default wholesale use-case. Origination and termination are >>> very different business models with radically different economics. >>> >>> I’m not clear on what the official STIR/SHAKEN solution to this is. I >>> assume it’s delegated certificates as Jared suggested. >>> >>> — >>> Sent from mobile, with due apologies for brevity and errors. >>> >>>> On Sep 2, 2020, at 2:39 PM, Carlos Alvarez <[email protected]> wrote: >>>> >>>> >>>> If I understand correctly, no as long as your providers are all supporting >>>> this. What I think you mean is that you get origination/DIDs from say >>>> Bandwidth, and you use LCR to route calls to whoever is cheapest? There >>>> are ways to work with that challenge as long as your carriers are ready to >>>> do so. >>>> >>>>> On Wed, Sep 2, 2020 at 11:28 AM Jared Geiger <[email protected]> wrote: >>>>> If we purchase our numbers through wholesalers, would we need delegated >>>>> certificates if we are sending an outbound call through a vendor that is >>>>> not the wholesaler we got the number from? >>>>> >>>>>> On Wed, Sep 2, 2020 at 7:22 AM Dave Frigen <[email protected]> wrote: >>>>>> There is a STIR-SHAKEN process of registering and testing with the Policy >>>>>> Administrator (PA) as a certified Service Provider (SP) before you can >>>>>> purchase SHAKEN token certificates from a Certificate Authority (CA) and >>>>>> begin to engage in using the technology. This is not a walk in the park. >>>>>> Transnexus is one of two public CA's in the U.S. today. They are experts >>>>>> on >>>>>> the subject and can help you through both processes. In order to get the >>>>>> best call attestation you must prove to the PA and CA that you are a bono >>>>>> fide service provider and not a bad-acting enterprise on a network that >>>>>> deserves lesser attestation levels. >>>>>> >>>>>> One of the registration requirements is a SP 's access to valid national >>>>>> phone number pools. This has been very confusing for some resale >>>>>> providers >>>>>> that purchase and use numbers from wholesalers only. If your organization >>>>>> does not have it's own numbering resources, you can register using your >>>>>> wholesale provider's numbering pool data. Don't assume you have to >>>>>> register >>>>>> with the FCC and possess your own pool of numbers to become a registered >>>>>> SHAKEN SP. >>>>>> >>>>>> SHAKEN ROBO call mitigation is a new frontier, and obtaining the best >>>>>> attestation level possible for a SP is essential to the SP and the SHAKEN >>>>>> ecosystem. Register and test for the best attestation level possible. >>>>>> Transnexus is a seasoned expert on the subject and a U.S. registered CA >>>>>> with >>>>>> the PA. >>>>>> >>>>>> Dave >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: VoiceOps <[email protected]> On Behalf Of Mary Lou >>>>>> Carey >>>>>> Sent: Tuesday, September 1, 2020 5:36 PM >>>>>> To: Dovid Bender <[email protected]> >>>>>> Cc: Voiceops.org <[email protected]> >>>>>> Subject: Re: [VoiceOps] Outsourcing STIR/SHAKEN Setup >>>>>> >>>>>> I'm a Carrier Consultant who's been helping CLEC, IXC, Paging, Wireless >>>>>> and >>>>>> VOIP carriers install and maintain their PSTN networks for the the last >>>>>> 20 >>>>>> years. I can help clients get their FCC Certification to become a >>>>>> STIR/SHAKEN carrier as well as Numbering Resources, NPAC / LSR training, >>>>>> etc >>>>>> (if you need those pieces). Once my clients get their certification, I >>>>>> refer >>>>>> them to TransNexus. Jim and his team can help you with the process of >>>>>> turning your STIR/SHAKEN services up. >>>>>> >>>>>> MARY LOU CAREY >>>>>> BackUP Telecom Consulting >>>>>> Office: 615-791-9969 >>>>>> Cell: 615-796-1111 >>>>>> >>>>>> On 2020-08-31 05:37 AM, Dovid Bender wrote: >>>>>> > Hi, >>>>>> > >>>>>> > Does anyone have a recommendation for a company that get us everything >>>>>> > needed for STIR/SHAKEN setup? By setup I mean helping us file to get a >>>>>> > cert etc. From the small research I have done there is a lot of >>>>>> > fragmented information out there and it would be easier for us to pay >>>>>> > someone else to do this then invest our own time to take care of this. >>>>>> > >>>>>> > TIA. >>>>>> > >>>>>> > Regards, >>>>>> > >>>>>> > Dovid >>>>>> > _______________________________________________ >>>>>> > VoiceOps mailing list >>>>>> > [email protected] >>>>>> > https://puck.nether.net/mailman/listinfo/voiceops >>>>>> _______________________________________________ >>>>>> VoiceOps mailing list >>>>>> [email protected] >>>>>> https://puck.nether.net/mailman/listinfo/voiceops >>>>>> >>>>>> _______________________________________________ >>>>>> VoiceOps mailing list >>>>>> [email protected] >>>>>> https://puck.nether.net/mailman/listinfo/voiceops >>>>> _______________________________________________ >>>>> VoiceOps mailing list >>>>> [email protected] >>>>> https://puck.nether.net/mailman/listinfo/voiceops >>>> _______________________________________________ >>>> VoiceOps mailing list >>>> [email protected] >>>> https://puck.nether.net/mailman/listinfo/voiceops >> _______________________________________________ >> VoiceOps mailing list >> [email protected] >> https://puck.nether.net/mailman/listinfo/voiceops > > Mark R Lindsey, SMTS | +1-229-316-0013 | [email protected] | https://ecg.co/lindsey/ >
_______________________________________________ VoiceOps mailing list [email protected] https://puck.nether.net/mailman/listinfo/voiceops
