Exactly that. The idea is collateral pain for misbehavior. Or attorneys
general knocking on doors wondering why they're allowing robocalls
through their network. Ideally both.
On 9/2/20 3:06 PM, Alex Balashov wrote:
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 <lind...@e-c-group.com> 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****|****m...@ecg.co
<mailto:m...@ecg.co>**|**https://ecg.co/lindsey/*
*
*
On Sep 2, 2020, at 2:52 PM, Alex Balashov <abalas...@evaristesys.com
<mailto:abalas...@evaristesys.com>> 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 <ptimm...@clearrate.com
<mailto:ptimm...@clearrate.com>> 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 <voiceops-boun...@voiceops.org
<mailto:voiceops-boun...@voiceops.org>> on behalf of Alex Balashov
<abalas...@evaristesys.com <mailto:abalas...@evaristesys.com>>
*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 <caalva...@gmail.com
<mailto:caalva...@gmail.com>> 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 <ja...@compuwizz.net
<mailto:ja...@compuwizz.net>> 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 <dfri...@wabash.net
<mailto:dfri...@wabash.net>> 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 <voiceops-boun...@voiceops.org
<mailto:voiceops-boun...@voiceops.org>> On Behalf Of Mary
Lou Carey
Sent: Tuesday, September 1, 2020 5:36 PM
To: Dovid Bender <do...@telecurve.com
<mailto:do...@telecurve.com>>
Cc: Voiceops.org <http://Voiceops.org>
<voiceops@voiceops.org <mailto:voiceops@voiceops.org>>
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
> VoiceOps@voiceops.org <mailto:VoiceOps@voiceops.org>
> https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________
VoiceOps mailing list
VoiceOps@voiceops.org <mailto:VoiceOps@voiceops.org>
https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________
VoiceOps mailing list
VoiceOps@voiceops.org <mailto:VoiceOps@voiceops.org>
https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________
VoiceOps mailing list
VoiceOps@voiceops.org <mailto:VoiceOps@voiceops.org>
https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________
VoiceOps mailing list
VoiceOps@voiceops.org <mailto:VoiceOps@voiceops.org>
https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________
VoiceOps mailing list
VoiceOps@voiceops.org <mailto:VoiceOps@voiceops.org>
https://puck.nether.net/mailman/listinfo/voiceops
*Mark R Lindsey, SMTS*| +1-229-316-0013|m...@ecg.co
<mailto:m...@ecg.co>|*https://ecg.co/lindsey/*
*
*
_______________________________________________
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops
