<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Once signed, you just pass it on with
its existing signature. Only the originator signs it. It could
technically have multiple headers, but that's not the intent.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">As for on the ground realities, I can
only point out that out of 8008 possibly signed inbound calls in
the last 24 hours (only my intelliquent SIP trunks have the
ability to pass the identity header right now):<br>
</div>
<div class="moz-cite-prefix">319 have attest A, <br>
</div>
<div class="moz-cite-prefix">None have attest B,<br>
</div>
<div class="moz-cite-prefix">2 have Attest C</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">310 of the calls were T-Mobile, 5 were
comcast, and 6 were other.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Out of the last 10,000 calls I have
originated toward the STIR/SHAKEN routes (which covers about 2
hours), I signed:</div>
<div class="moz-cite-prefix">2643 have attest A</div>
<div class="moz-cite-prefix">4695 have attest B (this is our default
where I haven't explicitly verified the customer is only sending
numbers that are theirs)</div>
<div class="moz-cite-prefix">244 have attest C (this gets triggered
if there's a header indicating the call was redirected)</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">It's really not as complicated as
people are making it out to be. Transnexus has been great to work
with, as has Inteliquent.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">-Paul<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 9/2/20 2:52 PM, Alex Balashov wrote:<br>
</div>
<blockquote type="cite"
cite="mid:391E4E6A-05E0-4D32-8461-032340843D6D@evaristesys.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
Thank you, that’s very clear and sums it all up!
<div><br>
</div>
<div>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?
<div><br>
</div>
<div>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.<br>
<br>
<div dir="ltr">—
<div>Sent from mobile, with due apologies for brevity and
errors.</div>
</div>
<div dir="ltr"><br>
<blockquote type="cite">On Sep 2, 2020, at 2:47 PM, Paul
Timmins <a class="moz-txt-link-rfc2396E" href="mailto:ptimmins@clearrate.com"><ptimmins@clearrate.com></a> wrote:<br>
<br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr">
<div id="divtagdefaultwrapper"
style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;"
dir="ltr">
<p>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.</p>
<p><br>
</p>
<p>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"</p>
<p><br>
</p>
<p>-Paul<br>
</p>
<br>
<br>
<div style="color: rgb(0, 0, 0);">
<hr tabindex="-1" style="display:inline-block;
width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font
style="font-size:11pt" face="Calibri, sans-serif"
color="#000000"><b>From:</b> VoiceOps
<a class="moz-txt-link-rfc2396E" href="mailto:voiceops-bounces@voiceops.org"><voiceops-bounces@voiceops.org></a> on behalf of
Alex Balashov <a class="moz-txt-link-rfc2396E" href="mailto:abalashov@evaristesys.com"><abalashov@evaristesys.com></a><br>
<b>Sent:</b> Wednesday, September 2, 2020 2:42 PM<br>
<b>To:</b> VoiceOps<br>
<b>Subject:</b> Re: [VoiceOps] Outsourcing
STIR/SHAKEN Setup</font>
<div> </div>
</div>
<div>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.
<div><br>
</div>
<div>I’m not clear on what the official STIR/SHAKEN
solution to this is. I assume it’s delegated
certificates as Jared suggested.<br>
<br>
<div dir="ltr">—
<div>Sent from mobile, with due apologies for
brevity and errors.</div>
</div>
<div dir="ltr"><br>
<blockquote type="cite">On Sep 2, 2020, at 2:39
PM, Carlos Alvarez <a class="moz-txt-link-rfc2396E" href="mailto:caalvarez@gmail.com"><caalvarez@gmail.com></a>
wrote:<br>
<br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">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.</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed,
Sep 2, 2020 at 11:28 AM Jared Geiger <<a
href="mailto:jared@compuwizz.net"
moz-do-not-send="true">jared@compuwizz.net</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">
<div dir="ltr">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?</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On
Wed, Sep 2, 2020 at 7:22 AM Dave
Frigen <<a
href="mailto:dfrigen@wabash.net"
target="_blank"
moz-do-not-send="true">dfrigen@wabash.net</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">
There is a STIR-SHAKEN process of
registering and testing with the
Policy<br>
Administrator (PA) as a certified
Service Provider (SP) before you can<br>
purchase SHAKEN token certificates
from a Certificate Authority (CA) and<br>
begin to engage in using the
technology. This is not a walk in the
park.<br>
Transnexus is one of two public CA's
in the U.S. today. They are experts on<br>
the subject and can help you through
both processes. In order to get the<br>
best call attestation you must prove
to the PA and CA that you are a bono<br>
fide service provider and not a
bad-acting enterprise on a network
that<br>
deserves lesser attestation levels. <br>
<br>
One of the registration requirements
is a SP 's access to valid national<br>
phone number pools. This has been very
confusing for some resale providers<br>
that purchase and use numbers from
wholesalers only. If your organization<br>
does not have it's own numbering
resources, you can register using your<br>
wholesale provider's numbering pool
data. Don't assume you have to
register<br>
with the FCC and possess your own pool
of numbers to become a registered<br>
SHAKEN SP.<br>
<br>
SHAKEN ROBO call mitigation is a new
frontier, and obtaining the best<br>
attestation level possible for a SP is
essential to the SP and the SHAKEN<br>
ecosystem. Register and test for the
best attestation level possible.<br>
Transnexus is a seasoned expert on the
subject and a U.S. registered CA with<br>
the PA. <br>
<br>
Dave<br>
<br>
<br>
-----Original Message-----<br>
From: VoiceOps <<a
href="mailto:voiceops-bounces@voiceops.org"
target="_blank"
moz-do-not-send="true">voiceops-bounces@voiceops.org</a>>
On Behalf Of Mary Lou Carey<br>
Sent: Tuesday, September 1, 2020 5:36
PM<br>
To: Dovid Bender <<a
href="mailto:dovid@telecurve.com"
target="_blank"
moz-do-not-send="true">dovid@telecurve.com</a>><br>
Cc: Voiceops.org <<a
href="mailto:voiceops@voiceops.org"
target="_blank"
moz-do-not-send="true">voiceops@voiceops.org</a>><br>
Subject: Re: [VoiceOps] Outsourcing
STIR/SHAKEN Setup<br>
<br>
I'm a Carrier Consultant who's been
helping CLEC, IXC, Paging, Wireless
and<br>
VOIP carriers install and maintain
their PSTN networks for the the last
20<br>
years. I can help clients get their
FCC Certification to become a<br>
STIR/SHAKEN carrier as well as
Numbering Resources, NPAC / LSR
training, etc<br>
(if you need those pieces). Once my
clients get their certification, I
refer<br>
them to TransNexus. Jim and his team
can help you with the process of<br>
turning your STIR/SHAKEN services up.<br>
<br>
MARY LOU CAREY<br>
BackUP Telecom Consulting<br>
Office: 615-791-9969<br>
Cell: 615-796-1111<br>
<br>
On 2020-08-31 05:37 AM, Dovid Bender
wrote:<br>
> Hi,<br>
> <br>
> Does anyone have a recommendation
for a company that get us everything <br>
> needed for STIR/SHAKEN setup? By
setup I mean helping us file to get a
<br>
> cert etc. From the small research
I have done there is a lot of <br>
> fragmented information out there
and it would be easier for us to pay <br>
> someone else to do this then
invest our own time to take care of
this.<br>
> <br>
> TIA.<br>
> <br>
> Regards,<br>
> <br>
> Dovid<br>
>
_______________________________________________<br>
> VoiceOps mailing list<br>
> <a
href="mailto:VoiceOps@voiceops.org"
target="_blank"
moz-do-not-send="true">VoiceOps@voiceops.org</a><br>
> <a
href="https://puck.nether.net/mailman/listinfo/voiceops"
rel="noreferrer" target="_blank"
moz-do-not-send="true">
https://puck.nether.net/mailman/listinfo/voiceops</a><br>
_______________________________________________<br>
VoiceOps mailing list<br>
<a href="mailto:VoiceOps@voiceops.org"
target="_blank"
moz-do-not-send="true">VoiceOps@voiceops.org</a><br>
<a
href="https://puck.nether.net/mailman/listinfo/voiceops"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
<br>
_______________________________________________<br>
VoiceOps mailing list<br>
<a href="mailto:VoiceOps@voiceops.org"
target="_blank"
moz-do-not-send="true">VoiceOps@voiceops.org</a><br>
<a
href="https://puck.nether.net/mailman/listinfo/voiceops"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
</blockquote>
</div>
_______________________________________________<br>
VoiceOps mailing list<br>
<a href="mailto:VoiceOps@voiceops.org"
target="_blank" moz-do-not-send="true">VoiceOps@voiceops.org</a><br>
<a
href="https://puck.nether.net/mailman/listinfo/voiceops"
rel="noreferrer" target="_blank"
moz-do-not-send="true">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
</blockquote>
</div>
<span>_______________________________________________</span><br>
<span>VoiceOps mailing list</span><br>
<span><a class="moz-txt-link-abbreviated" href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a></span><br>
<span><a class="moz-txt-link-freetext" href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a></span><br>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
VoiceOps mailing list
<a class="moz-txt-link-abbreviated" href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a>
<a class="moz-txt-link-freetext" href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a>
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>