<html theme="default-light" iconset="color"><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head><body style="font-family: Helvetica,Arial,sans-serif;" 
text="#000000"><div style="font-family: Helvetica,Arial,sans-serif;">Good
 morning everyone.  I see my company got brought up here, and we are 
probably a good use case in the entire ecosystem to consider when it 
comes to Robocall mitigation.  What is my companies (or any other 
white-label resellers) responsibilities to it.<br><br>While we do not 
have a direct end-user relationship with the client, we do require that 
our resellers (smaller, regional ISPs primarily) have a direct 
relationship with the client that would meet all of Attestation A 
requirements.  This is actually fairly easy to have as an ISP rather 
than an MSP or other company that accepts any client to sign up for 
service (since an ISP has to visit the premise to install service 
generally).<br><br>Furthermore, every DID on our system is ported though
 our company (we primarily use IQNT, Bandwidth, and VI for our own 
Orig/Term) so we are verifying things like an LOA and last copy of 
bill.  <br><br>No calls are allowed to originate from our system that do
 not match a CLID that we have verified that client has authorization to
 use.  This prevents our clients (i.e. resellers) from spoofing CLID, 
and CNAME storage with our vendors can only be set via Atheral.<br><br>We
 do use ClearIP/TransNexus for STIR/SHAKEN but also for Telecom Fraud 
and Robocall protection.  If a user starts exhibiting robocall or 
fraudulent call behavior we shut that down immediately.  We also 
prohibit dialer traffic on our network or traffic poor call completion.<br><br>The
 legal advice we were given was that our resellers, all of whom file a 
499a, do not need to sign their own traffic.  We have always been very 
protective of our switching infrastructure (utilizing a Netsapiens 
switch with Ribbon SBCs in front) and the traffic that flows through 
it.  We do not bill per minute to our clients, so minimizing any 
potential fraudulent traffic is a key concern of ours to keep our costs 
low.<br><br>Of course, if the FCC goes a different direction we will 
change our stance.  I believe there isn't any reason to burden small, 
regional ISPs with the signature since our clients are almost 
exclusively de-minims and adds nothing to the traceback process.  If we 
get a traceback, we will work with the ISP or immediately kick them off 
our system.<br><br>Alianza (<a class="moz-txt-link-freetext" href="https://www.alianza.com/">https://www.alianza.com/</a>) has a very similar
 business model to ours although we mostly target different ISPs than we
 do.  I've not dug into how they or any other white-label reseller has 
interpreted the rules as they sit today, but I imagine most companies 
like ours are "the good actors" and not the ones that these regulations 
were intended to change behavior of.<br><br>Thank you!<br><div 
class="moz-signature"><br>
<table style="width: 318px; background: white none repeat scroll 0% 0%; 
border-collapse: collapse; height: 105px;" cellspacing="0" 
cellpadding="0" border="0">
<tbody><tr><td rowspan="1" 
style="width:139.6pt;border:none;border-right:solid #2E0C5F 
1.0pt;padding:20px 0px 0px 0px" halign="center" valign="top" width="186"><a
 href="https://atheral.com"><img 
src="cid:part1.2DBA9677.D6169AB1@atheral.com" alt="atheral-logo" 
v:shapes="Picture_x0020_4" style="width: 132px; height: 75px; padding: 
20px 0x 0px 0px; border: 0px solid;" moz-do-not-send="true">
                </a>
                </td>
                <td style="padding:0in 0in 0in 0in">
                <table style="width: 183px; border-collapse: collapse; 
height: 175px;" cellspacing="0" cellpadding="0" border="0">
                    <tbody>
                        <tr><td style="width:228.75pt;padding:0in 0in 
3.75pt 7.5pt" valign="top" width="305">
                            <p style="line-height:15.75pt">
                                <b><span 
style="font-size:14.0pt;font-family:Roboto;color:#2E0C5F">Daniel White</span></b><br>
                                <span 
style="font-size:10.0pt;font-family:Roboto;">Co-Founder<br></span>
                            </p>
                            <p style="line-height:12pt"><b>
                                <span 
style="font-size:10.0pt;font-family:Roboto;color:#2E0C5F">phone:</span></b><span
 style="font-size:10.0pt;font-family:Roboto;"> +1 (702) 470-2770</span><br>
                                <b><span 
style="font-size:10.0pt;font-family:Roboto;color:#2E0C5F">direct:</span></b><span
 style="font-size:10.0pt;font-family:Roboto;"> +1 (702) 470-2766</span><br>
                            </p>
                        </td></tr>
                    </tbody>
                </table>
            </td></tr></tbody>
        
</table>
<br>
</div><span>

</span><blockquote type="cite" 
cite="mid:8ce901d9b51d$2685eb10$7391c130$@zipdx.com" style="border: 0px 
none ! important;"><div xmlns="http://www.w3.org/1999/xhtml" 
class="__pbConvHr" style="margin:30px 25px 10px 25px;"><div 
style="width:100%;border-top:2px solid 
rgba(146,154,163,0.7);padding-top:10px;">   <div 
style="display:inline-block;white-space:nowrap;vertical-align:middle;width:49%;">
        <a style="color:#485664 
!important;padding-right:6px;font-weight:500;text-decoration:none 
!important;" href="mailto:voiceops@voiceops.org" moz-do-not-send="true">David
 Frankel via VoiceOps</a></div>   <div 
style="display:inline-block;white-space:nowrap;vertical-align:middle;width:48%;text-align:
 right;">     <font color="#909AA4"><span style="padding-left:6px">July 
12, 2023 at 6:01 PM</span></font></div>    </div></div><div 
xmlns="http://www.w3.org/1999/xhtml" class="__pbConvBody" 
__pbrmquotes="true" 
style="color:#909AA4;margin-left:24px;margin-right:24px;"><div>Nathan: 
Thanks for sharing your thinking and a specific example.<br><br>I can't 
speak for the FCC or the ITG (obviously) and they probably won't<br>weigh
 in here. But, as Mary has done, I can share what I hope is a<br>reasonably
 accurate perspective.<br><br>I hope, Nathan, that the key is your 
statement: "But sans any violations to<br>look into...how would they 
know?" And, I would add, why would they care? If<br>the group you 
describe isn't a bunch of trouble-makers, then surely there<br>are other
 fish to fry when it comes to compliance issues. Let's put our<br>focus 
on the ones that are actually wreaking havoc.<br><br>I hadn't heard of 
Atheral before, but I see that they have a SHAKEN token<br>per 
iconectiv, so they can sign calls. They list several customers on their<br>web
 page; I spot checked those and the ones I searched do NOT have tokens<br>but
 ARE registered in the Robocall Mitigation Database. I did see that a<br>couple
 of them had very nicely written Robocall Mitigation Plans (Zirkel,<br>for
 example, with Vistabeam in second place) that explained exactly how 
they<br>work with Atheral in terms of getting calls signed.<br><br>We 
could debate (and in fact, we are debating at the FCC) whether, for<br>example,
 it's OK for Atheral to sign calls with Atheral's token on behalf of<br>Zirkel.
 We might argue that Zirkel is the one with the direct authenticated<br>relationship
 with their customer, so it should be a Zirkel signature on<br>those 
calls. Or you can make a semantic argument that Atheral is the<br>"Originating
 Voice Service Provider" and that it is through their agent<br>Zirkel 
that they have the customer relationship. Zirkel explains how they<br>validate
 the phone numbers that their customers use, and pass that<br>information
 on to Atheral for proper attestation. It all appears to be on<br>the 
up-and-up. <br><br>Atheral has to understand that by putting the Atheral
 signature on calls<br>coming via Zirkel and others, Atheral is putting 
its own reputation on the<br>line. So Atheral is presumably motivated to
 ensure everybody plays nice,<br>which they probably do at least in part
 via their contractual agreements.<br><br>To my knowledge, the ITG does 
not "block traffic" or enforce rules about<br>tokens. The ITG is in the 
business of traceback, and it makes the<br>information it gathers 
through that process available, selectively, to<br>others that can then 
act on it. That includes not just government enforcers<br>but, for 
example, others in the call chain. If a particular provider is<br>involved
 in a traceback, they get visibility to whether their upstream is<br>responding
 to that traceback. If not, or if that upstream failed to sign a<br>call
 when they should have, then the downstream provider can initiate action<br>on
 its own with respect to that upstream.<br><br>Back to Atheral -- our 
RRAPTOR robocall surveillance platform has never<br>captured a 
problematic call with an Atheral signature. That doesn't mean we<br>know
 for certain that no "bad" robocalls flow via Atheral, but it's probably<br>safe
 to say that at the moment, Atheral and its customers aren't a cause of<br>great
 concern.<br><br>Lastly, thanks Nathan for the nice words about our test
 tool.<br><br>David Frankel<br>ZipDXR LLC<br>St. George, UT USA<br><br>-----Original
 Message-----<br>From: VoiceOps <a class="moz-txt-link-rfc2396E" href="mailto:voiceops-bounces@voiceops.org"><voiceops-bounces@voiceops.org></a> On
 Behalf Of Nathan Anderson<br>via VoiceOps<br>Sent: Wednesday, July 12, 
2023 4:21 PM<br>To: 'Voice Ops' <a class="moz-txt-link-rfc2396E" href="mailto:voiceops@voiceops.org"><voiceops@voiceops.org></a><br>Subject:
 Re: [VoiceOps] Update on STIR/SHAKEN<br><br>Personally, I'm quite 
curious to know how the ITG would even be identifying<br>these companies
 as being distinct from the wholesaler, at least without a<br>traceback 
request for an actual violation, where the investigation (that the<br>wholesaler
 would likely be not only cooperative with but actively involved<br>in) 
eventually revealed that all of the violations were originating from one<br>particular
 customer of theirs.  But sans any violations to look into...how<br>would
 they know?<br><br>In particular, when asking these questions, what I 
specifically have in mind<br>are wholesalers not like VI/Sangoma et al.,
 but more like e.g.<br><a class="moz-txt-link-freetext" href="https://atheral.com/">https://atheral.com/</a>, which carries traffic for a
 bunch of smaller regional<br>ISPs that want to offer VoIP but don't 
want any of the headaches associated<br>with doing so.  So most of them I
 presume literally own no infrastructure of<br>their own...no 
softswitch, no SBC, no nothing.  They might be 499 filers,<br>but that's
 likely the extent of their direct regulatory involvement.<br><br>I 
believe Daniel might be hanging around on this list, so perhaps he can<br>shed
 some light on how they have been advised to approach this (whether they<br>are
 signing all calls with their own SHAKEN cert/key, or whether they can<br>host
 SHAKEN certs owned by their customers and sign the end-users of that<br>customer's
 calls with that customer's own cert, or a mix of both).<br><br>-- 
Nathan<br><br>-----Original Message-----<br>From: VoiceOps 
[<a class="moz-txt-link-freetext" href="mailto:voiceops-bounces@voiceops.org">mailto:voiceops-bounces@voiceops.org</a>] On Behalf Of Mary Lou<br>Carey 
via VoiceOps<br>Sent: Wednesday, July 12, 2023 1:29 PM<br>To: 
<a class="moz-txt-link-abbreviated" href="mailto:voiceops@voiceops.org">voiceops@voiceops.org</a><br>Subject: [VoiceOps] Update on STIR/SHAKEN<br><br>I
 spoke with my FCC contact today and was told to read the last order 
issued<br>in March so his response wasn't crystal clear. He said the FCC
 is still in<br>the process of deciding which types of companies can 
sign with a third-party<br>vendor's token and which ones can't.<br><br>I
 told him my concern is that the ITG is going to start blocking traffic 
in<br>August and companies won't know that they aren't compliant because
 their<br>wholesale provider told them they were fine. I specifically 
asked, "If the<br>ITG decides a company should have had its own token, 
will you give them time<br>to get one?" He said they have a process for 
handling these issues, but he<br>didn't come out and say "Yes" so here's
 what I would suggest since the<br>process can sometimes take longer 
than the 30 days they give you to comply.<br><br><br>If you are using a 
third-party provider whose signing with their token. <br>At least 
complete the preliminary steps to qualify for your own STIR/SHAKEN<br>token.
 That way if they do come to you and tell you that you need to get it<br>on
 a moment's notice, you won't be fighting the clock so much. The<br>pre-requisites
 for filing with the STI-PA to become an approved carrier are:<br><br>1.
 Order your own OCN (aka company code from NECA) IPES is the correct 
type<br>for all VOIP carriers 2. Have your 499 up to date and fees paid.
 If you've<br>never filed a 499A yet, get your 499 filer ID and submit 
your first 499-A.<br>(All carriers delivering long-distance traffic in 
the US should have already<br>completed this step anyways).<br>3. 
Robocall Mitigation Plan filed.<br><br>There are multiple companies 
helping carriers get their STIR/SHAKEN<br>certificate, so it doesn't 
matter if you use my services or anyone else's. I<br>just want to make 
sure everyone is aware of what they need to do to make<br>sure their 
traffic doesn't get blocked because thats a lot harder to fix<br>than 
getting a certificate/token is!<br><br>MARY LOU CAREY<br>BackUP Telecom 
Consulting<br>Office: 615-791-9969<br>Cell: 615-796-1111<br>_______________________________________________<br>VoiceOps
 mailing list<br><a class="moz-txt-link-abbreviated" href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a><br><a class="moz-txt-link-freetext" href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a><br>_______________________________________________<br>VoiceOps
 mailing list<br><a class="moz-txt-link-abbreviated" href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a><br><a class="moz-txt-link-freetext" href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a><br><br>_______________________________________________<br>VoiceOps
 mailing list<br><a class="moz-txt-link-abbreviated" href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a><br><a class="moz-txt-link-freetext" href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a><br></div>

</div><div xmlns="http://www.w3.org/1999/xhtml" class="__pbConvHr" 
style="margin:30px 25px 10px 25px;"><div 
style="width:100%;border-top:2px solid 
rgba(146,154,163,0.7);padding-top:10px;">   <div 
style="display:inline-block;white-space:nowrap;vertical-align:middle;width:49%;">
        <a style="color:#485664 
!important;padding-right:6px;font-weight:500;text-decoration:none 
!important;" href="mailto:voiceops@voiceops.org" moz-do-not-send="true">Nathan
 Anderson via VoiceOps</a></div>   <div 
style="display:inline-block;white-space:nowrap;vertical-align:middle;width:48%;text-align:
 right;">     <font color="#909AA4"><span style="padding-left:6px">July 
12, 2023 at 4:20 PM</span></font></div>    </div></div><div 
xmlns="http://www.w3.org/1999/xhtml" class="__pbConvBody" 
__pbrmquotes="true" 
style="color:#909AA4;margin-left:24px;margin-right:24px;"><div>Personally,
 I'm quite curious to know how the ITG would even be identifying these 
companies as being distinct from the wholesaler, at least without a 
traceback request for an actual violation, where the investigation (that
 the wholesaler would likely be not only cooperative with but actively 
involved in) eventually revealed that all of the violations were 
originating from one particular customer of theirs.  But sans any 
violations to look into...how would they know?<br><br>In particular, 
when asking these questions, what I specifically have in mind are 
wholesalers not like VI/Sangoma et al., but more like e.g. 
<a class="moz-txt-link-freetext" href="https://atheral.com/">https://atheral.com/</a>, which carries traffic for a bunch of smaller 
regional ISPs that want to offer VoIP but don't want any of the 
headaches associated with doing so.  So most of them I presume literally
 own no infrastructure of their own...no softswitch, no SBC, no nothing.
  They might be 499 filers, but that's likely the extent of their direct
 regulatory involvement.<br><br>I believe Daniel might be hanging around
 on this list, so perhaps he can shed some light on how they have been 
advised to approach this (whether they are signing all calls with their 
own SHAKEN cert/key, or whether they can host SHAKEN certs owned by 
their customers and sign the end-users of that customer's calls with 
that customer's own cert, or a mix of both).<br><br>-- Nathan<br><br>-----Original
 Message-----<br>From: VoiceOps [<a class="moz-txt-link-freetext" href="mailto:voiceops-bounces@voiceops.org">mailto:voiceops-bounces@voiceops.org</a>] 
On Behalf Of Mary Lou Carey via VoiceOps<br>Sent: Wednesday, July 12, 
2023 1:29 PM<br>To: <a class="moz-txt-link-abbreviated" href="mailto:voiceops@voiceops.org">voiceops@voiceops.org</a><br>Subject: [VoiceOps] Update 
on STIR/SHAKEN<br><br>I spoke with my FCC contact today and was told to 
read the last order <br>issued in March so his response wasn't crystal 
clear. He said the FCC is <br>still in the process of deciding which 
types of companies can sign with <br>a third-party vendor's token and 
which ones can't.<br><br>I told him my concern is that the ITG is going 
to start blocking traffic <br>in August and companies won't know that 
they aren't compliant because <br>their wholesale provider told them 
they were fine. I specifically asked, <br>"If the ITG decides a company 
should have had its own token, will you <br>give them time to get one?" 
He said they have a process for handling <br>these issues, but he didn't
 come out and say "Yes" so here's what I <br>would suggest since the 
process can sometimes take longer than the 30 <br>days they give you to 
comply.<br><br><br>If you are using a third-party provider whose signing
 with their token. <br>At least complete the preliminary steps to 
qualify for your own <br>STIR/SHAKEN token. That way if they do come to 
you and tell you that you <br>need to get it on a moment's notice, you 
won't be fighting the clock so <br>much. The pre-requisites for filing 
with the STI-PA to become an <br>approved carrier are:<br><br>1. Order 
your own OCN (aka company code from NECA) IPES is the correct <br>type 
for all VOIP carriers<br>2. Have your 499 up to date and fees paid. If 
you've never filed a 499A <br>yet, get your 499 filer ID and submit your
 first 499-A. (All carriers <br>delivering long-distance traffic in the 
US should have already completed <br>this step anyways).<br>3. Robocall 
Mitigation Plan filed.<br><br>There are multiple companies helping 
carriers get their STIR/SHAKEN <br>certificate, so it doesn't matter if 
you use my services or anyone <br>else's. I just want to make sure 
everyone is aware of what they need to <br>do to make sure their traffic
 doesn't get blocked because thats a lot <br>harder to fix than getting a
 certificate/token is!<br><br>MARY LOU CAREY<br>BackUP Telecom 
Consulting<br>Office: 615-791-9969<br>Cell: 615-796-1111<br>_______________________________________________<br>VoiceOps
 mailing list<br><a class="moz-txt-link-abbreviated" href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a><br><a class="moz-txt-link-freetext" href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a><br>_______________________________________________<br>VoiceOps
 mailing list<br><a class="moz-txt-link-abbreviated" href="mailto:VoiceOps@voiceops.org">VoiceOps@voiceops.org</a><br><a class="moz-txt-link-freetext" href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a><br></div>

</div></blockquote><br></div></body></html>