[VoiceOps] All carriers must get their STIR/SHAKEN certificate by June 30th!

[Jeff Waddell]

You can obtain the IPES OCN without the FCC Numbering Waiver - I know this
first hand as that's exactly what we did

>From the looks of it, the OCN process took about 48 hours for them to issue
it.

Jeff

On Tue, Jun 6, 2023 at 10:36 PM Nathan Anderson via VoiceOps <
voiceops at voiceops.org> wrote:

> Hmm, so after going back and reviewing other things, including re-reading
> some old posts (Mary's included!) from this here mailing list, there seems
> to be some ambiguity and conflicting information.  I certainly don't want
> to be guilty of misinforming people, so I'll just follow up & summarize
> here, presenting the one possibility I see as a workaround to this problem:
>
> I think the change Mary was referring to was in the STI-PA policy, laying
> out requirements for service providers who want access to STI-PA SPC
> tokens.  Originally, they were:
>
> 1. Have a current (most recent complete calendar year) 499A filed.
> 2. Have an OCN.
> 3. Have direct access to numbering resources.
>
> In Q2 2021, requirement #3 was removed and replaced with a new one:
>
> 3. List yourself in the RMP database.
>
> Where the ambiguity comes in is that, despite the official STI-PA policy
> removing this particular requirement, they still require an OCN (#2), and
> as pointed out before, it can't just be an OCN of any type.  Only an OCN of
> a type "that is eligible for Numbering Resource assignments" is acceptable
> to them, and what I took away from this was that the numbering resource
> access requirement hasn't actually been rescinded.  It's seemingly still
> there, just no longer explicitly spelled out in the top 3 requirements...if
> they intended for that to not be a requirement any longer, they really
> biffed it by creating this chicken-and-egg problem when they limited the
> types of approved OCNs.
>
> There seems to be some support for the idea (incl. from Mary!:
> https://puck.nether.net/pipermail/voiceops/2021-May/008895.html) that it
> is now possible to obtain an IPES OCN from NECA without first petitioning
> the FCC for a VoIP numbering resource waiver.  NECA themselves seems to be
> of two minds about this: page 4 of
> https://www.neca.org/docs/default-source/public---business-solutions/code-administration/na_procedures0422.pdf?sfvrsn=2b358470_8
> only lists the requirements Mary stated in her May 2021 post that I linked
> to, but the page at
> https://www.neca.org/business-solutions/company-codes/company-code-request-instructions
> says IPES is "only permitted with an FCC waiver".
>
> Okay, so...which is it?
>
> I suppose one way to resolve this ambiguity, in favor of the argument that
> no FCC waiver is required for interconnected VoIP providers, is thusly:
>
> * STI-PA will only grant SPC tokens to providers who have a type of OCN
> "that is eligible for Numbering Resource assignments"
>
> * The list of specific OCN types that fall under this category are
> presented at
> https://www.neca.org/business-solutions/company-codes/company-code-request-instructions
> and "IPES" is in the list
>
> * But perhaps NECA will assign IPES OCNs without requiring that you
> produce an FCC numbering waiver for your company, as long as you provide
> the documentation outlined at
> https://www.neca.org/docs/default-source/public---business-solutions/code-administration/na_procedures0422.pdf
>
> * The parenthetical of "(only permitted with an FCC waiver)" on the NECA
> page only means that if you hold an IPES OCN and *want* access to numbers,
> you still have to separately petition the FCC for the waiver...but is not
> meant to imply that you can only be *granted* an IPES OCN after having
> first obtained such a waiver (another ambiguity! the parenthetical could
> arguably be read either way!).  Meaning you can hold an IPES OCN *without*
> having access to numbering resources, though you could *get* access at any
> time simply by going through the waiver process with the FCC.
>
> In which case, you could argue that none of these seemingly contradictory
> requirements are actually in conflict: IPES OCNs are *eligible* (key word)
> for numbering resources, even if you yourself have not yet been granted
> that eligibility status by the FCC.  So as long as you come to the STI-PA
> with an IPES OCN, they won't also try to confirm that you have the FCC
> waiver, and since the IPES OCN is in the list of approved OCN types, you
> are good to go?
>
> Ugh, the mental gymnastics required to arrive at such a conclusion are
> exhausting...you'd think somebody with some authority (e.g., FCC, NECA,
> STI-GA) could unambiguously just state the facts in a central, public
> location one way or the other.
>
> Does anybody here have any first-hand experience with obtaining an IPES
> OCN *and* being approved as a SPC-token-eligible carrier by iconectiv
> *without* having obtained the FCC numbering waiver?
>
> -- Nathan
>
> -----Original Message-----
> From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Nathan
> Anderson via VoiceOps
> Sent: Tuesday, June 6, 2023 5:54 PM
> To: 'Mary Lou Carey'
> Cc: 'Voice Ops'
> Subject: Re: [VoiceOps] All carriers must get their STIR/SHAKEN
> certificate by June 30th!
>
> Also note that not all OCN types are accepted by STI-PA.  Whatever OCN you
> supply to them MUST be of one of the types "that is eligible for Numbering
> Resource assignments" (page 3 @
> https://authenticate.iconectiv.com/sites/authenticate/files/2021-10/Service_Provider_Guidelines_Issue_6.pdf
> ).
>
> So, for example, none of the reseller OCN types (e.g., LRSL) would be
> eligible.
>
> NECA provides a list of specific OCN types that are eligible for numbering
> resources here:
> https://www.neca.org/business-solutions/company-codes/company-code-request-instructions
>
> They list IPES among them, of course, but with the note that it's "only
> permitted with an FCC waiver".
>
> I believe it was this chain of logic (STI-PA only allows specific OCN
> types, NECA lists them, IPES is among them but specifically says you must
> get an FCC waiver) that led me to conclude that the FCC numbering
> authorization waiver was *still a requirement* specifically if you were
> going the *IPES* route.  I have not been able to find anything that
> specifically exempts / rescinds this requirement.
>
> Note that you don't have to actually *have* or even *seek* your own
> numbering resources.  You just have to be *eligible* to do so.  The OCN
> type you have been granted serves as proof to the STI-PA that this is the
> case.
>
> -- Nathan
>
> -----Original Message-----
> From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Nathan
> Anderson via VoiceOps
> Sent: Tuesday, June 6, 2023 5:39 PM
> To: 'Mary Lou Carey'
> Cc: 'Voice Ops'
> Subject: Re: [VoiceOps] All carriers must get their STIR/SHAKEN
> certificate by June 30th!
>
> That note about RMP vs. numbering authorization might be *technically*
> correct purely from the perspective of what the STI-PA themselves
> requires.  But my understanding is that to obtain an IPES OCN, you still
> need to jump through the FCC numbering authorization hoops.  So
> effectively, the requirement to petition the FCC for numbering
> authorization still applies to the vast majority of interconnected VoIP
> providers, *unless* you apply for an OCN type *other* than the IPES one.
> Would love to know if I'm misreading this..(I'll try to go back and refresh
> myself on what led me to this conclusion, too...perhaps the "9th hour" you
> refer to was so late that this change you are talking about didn't happen
> until well after June 1st of last year?)
>
> Also yes, if you apply for CLEC OCN, then that is done state by state and
> not nationally.  We went this route because 1) we already had obtained
> CPCNs from the states we operate in some time ago, and just hadn't done
> anything with them 2) we have no plans to expand our local coverage area
> anytime soon, 3) we were concerned enough last year by the 30-day FCC
> comment period & whether we would get approval "in time", that CLEC OCNs
> seemed like they would actually be faster to obtain (since we could
> immediately apply to NECA for OCNs and not have to wait on the FCC at all
> for anything).
>
> The thing that made it a pain was just that initially NECA had quibbles
> with us about the copies of the CPCNs that we provided to them, and it took
> a bunch of back-and-forth communication and argumentation to convince them
> to accept them.  Which they finally did, and in the end, it still took less
> than 30 days.  And we had enough time to spare after that, that we were
> able to apply to the STI-PA, and finally to sign up with a SHAKEN CA and
> buy a cert, and bring the tech stack online on our side to support all of
> this new infrastructure, all before the June 30 deadline.  Not sure we
> could have made it if we had been forced to go the IPES route instead (it
> would have been cutting it VERY close, assuming it would have even been
> possible).
>
> Again, this just had to do with our *particular* circumstances & timing at
> the time, so I'm not trying to advise that anybody else do it this way...in
> fact I'd actively join you in discouraging it.  Go the IPES route if
> possible.  The main problem is that if there is anybody at this point who
> isn't yet signing their calls, and they don't even have an OCN yet,
> well...we're now already into the first full week of June.  So if my
> understanding is correct that specifically the *IPES* type OCN does still
> require numbering authorization thumbs-up from the FCC in order to obtain
> one, then it would be absolutely impossible for such an entity to meet the
> June 30 2023 deadline while pursuing that strategy.
>
> -- Nathan
>
> -----Original Message-----
> From: Mary Lou Carey [mailto:marylou at backuptelecom.com]
> Sent: Tuesday, June 6, 2023 2:23 PM
> To: Nathan Anderson
> Cc: Peter Beckman; 'Voice Ops'
> Subject: Re: [VoiceOps] All carriers must get their STIR/SHAKEN
> certificate by June 30th!
>
> Just so you know there were a few changes made to the process in the 9th
> hour of the deadline last year. The Robocall Mitigation plan took the
> place of the requirement to get a VOIP numbering authorization from the
> FCC. So you just need to file a Robocall Mitigation Plan - not the FCC
> Numbering Authorization.
>
> Secondly, CLEC OCNs are assigned by state but if you're VOIP, one OCN
> (aka company code) is assigned for the whole country. The IPES OCN
> covers both interconnected VOIP and non-Interconnected VOIP. Clearly a
> mistake in my opinion because you can't tell a non-interconnected VOIP
> from an Interconnected VOIP but that's the way it is.
>
> You don't want to get a CLEC, Resale or ULEC OCN if you're a VOIP
> provider. It's most advantageous to get the IPES OCN.
>
> MARY LOU CAREY
> BackUP Telecom Consulting
> Office: 615-791-9969
> Cell: 615-796-1111
>
> On 2023-06-02 06:09 PM, Nathan Anderson wrote:
> > Mary's right: there are a lot of moving parts and "hidden costs" to
> > doing this.  What follows is largely a "brain dump" on what I know
> > based on what we went through last year.
> >
> > Presumably if you are here on VoiceOps and asking about getting a
> > cert, you likely are a 499 filer already.
> >
> > On top of that, though, as pointed out, you need a STI-PA token issued
> > to you by the Policy Administrator in order to request a SHAKEN cert
> > from one of the approved vendors...the STI-PA essentially "vets" you
> > as an eligible telecom in advance, and then issues you a token, which
> > you in turn have to submit to your SHAKEN CA vendor of choice when you
> > apply to them for a cert.  The CA has to validate the token you
> > submitted before they can issue the certificate to you.  Unlike with
> > the SHAKEN cert, which is similar to a SSL/TLS cert in that there are
> > many certificate authorities competing with one another for your
> > business, the STI-PA contract has been awarded to a single company:
> > iconectiv.  You need to go to them and get set up in their system.
> >
> > In order to be approved by the STI-PA, though, you need to have an OCN
> > issued to your company if you don't have one already.  The
> > STI-PA/iconectiv will ask you for this when you sign up with them, and
> > you can't proceed without one.  The company that administers all OCN
> > assignments is NECA.
> >
> > As far as costs go, the OCN allocation is a one-time fee, and the
> > prices are published here:
> > https://www.neca.org/business-solutions/company-codes  ...the STI-PA
> > fees are annual and based on your telecom revenues as reported on your
> > most recent 499A filing.  I can't remember the exact number, but I
> > want to say it's a very small percentage, perhaps even under 1%.  But
> > of course there is some "minimum" absolute $ number that it will never
> > be lower than, heh.  (Quickly looked that up; looks like that minimum
> > annual figure is $825.)  Then there are of course whatever costs you
> > have to pay to consultants or lawyers to help you put all of these
> > puzzle pieces together, which I think was what Mary was largely
> > addressing.
> >
> > I think what Peter was specifically asking about, though, was the cost
> > for the actual SHAKEN certificate itself, and what vendor to use for
> > that.  iconectiv maintains an up-to-date list of approved SHAKEN CAs
> > that you can pick from:
> > https://authenticate.iconectiv.com/approved-certification-authorities
> > Vast majority of them don't like to publish their prices & you have to
> > ask.  From the research I did last year, pricing basically starts at
> > ~$1,000/year, and that's on the LOW side: the average annual price is
> > actually much higher than that from most CAs.  What I can tell you is
> > that we chose to go with Sansay.  Theirs was not only the lowest price
> > by far, but their system and policies were also the most reasonable
> > out of all the SHAKEN CAs that I talked to by a *mile*.  (As just one
> > example, you essentially get unlimited cert reissues during the year,
> > while many other CAs will charge you if you need to revoke a
> > compromised cert and request a new one.)  They went WELL out of their
> > way to help me get onboarded and running, too.  Can't say enough good
> > things about them; just everything about the experience of working
> > with them has been top-notch.  It's almost like they actually wanted
> > my business!!  I recommend reaching out to Carlos Perez w/ Sansay (you
> > can find him hanging out here @ VoiceOps)...he is the man.
> >
> > From just a purely pain-in-the-tuchus perspective, the most difficult
> > process to get through of all the aforementioned ones was definitely
> > obtaining our OCN allocation.  But that could just be because of our
> > particular unique circumstances...we chose to tackle it ourselves
> > rather than farm it out, and we applied as a CLEC.  If you are purely
> > an interconnected VoIP provider, though, and not an actual CLEC, I
> > have to imagine that taking the IPES "golden path" is going to prove
> > to be much less of a hassle.  This will require that you apply to the
> > FCC for a "VoIP Numbering Authorization" before you apply for your
> > OCN:
> >
> https://www.fcc.gov/wireline-competition/competition-policy-division/numbering-resources/general/voip-numbering
> > -- do note that this has an inherent 30-day built-in wait time, since
> > the FCC requires that your application be open to public comment for a
> > 30 day period before they make a ruling.  Which means, unfortunately,
> > that if you haven't already started this process by this point, you
> > aren't going to be able to obtain your OCN before June 30, much less
> > an actual SHAKEN cert.
> >
> > Once you finally have your OCN, you also need to make sure you have a
> > documented robocall mitigation plan filed with the FCC at
> > https://fccprod.servicenowservices.com/rmd?id=rmd_welcome before
> > iconectiv will get you set up on the STI-PA side.  Also, once you
> > finally have your SHAKEN cert and are actively signing calls, you need
> > to go back to the FCC robocall mitigation database and update your
> > entry in the database to reflect the fact that you are now STIR/SHAKEN
> > compliant.
> >
> > On the tech stack side, you need to host your SHAKEN cert on a public
> > server so that other telecoms who receive calls from your users can
> > validate that the calls that you are signing are indeed authentic.
> > And your outgoing calls need to include a new field within the SIP
> > headers called "Identity", which is a Base64-encoded version of the
> > signature for that particular call (signed by your private key), along
> > with the URL pointing at your public cert (which is also embedded
> > within the encrypted signature, so when it's decrypted and the two
> > match, that validates that the public cert located at that URL is
> > indeed yours).  The payload of the "Identity" header is called a
> > PASSporT (yet another in a series of groan-worthy backronyms...)
> >
> > Virtually all of the SHAKEN cert providers also offer end-to-end
> > solutions for VoIP providers that take care of all of this for you:
> > they'll host your public cert for you on their servers, and many even
> > offer a cloud API or SIP proxy service that will sign your calls for
> > you (by also storing your private key in a secure location on their
> > side & either generating the Identity header for your and sending it
> > back to you so that you can include it in the call, or by having you
> > send your SIP INVITEs to their proxy where they'll just add it to the
> > SIP header for you before they pass the INVITE on to your termination
> > provider).  Of course, all these extra services often have additional
> > costs associated with them.  Once again, we elected to implement our
> > own solution, and I based it largely on Signalwire's open source
> > "libstirshaken" codebase: https://github.com/signalwire/libstirshaken
> > -- this can integrate directly with FreeSwitch if that's what you use,
> > but in our case I just built the included command-line "stirshaken"
> > demo utility, and shell out to that to generate the PASSporTs which
> > then get added to the SIP header for our outgoing INVITEs.
> >
> > Hope that at least some part of this proves helpful, and good luck,
> >
> > -- Nathan
> >
> > -----Original Message-----
> > From: Mary Lou Carey [mailto:marylou at backuptelecom.com]
> > Sent: Friday, June 2, 2023 1:16 PM
> > To: Peter Beckman
> > Cc: Nathan Anderson; 'Voice Ops'
> > Subject: Re: [VoiceOps] All carriers must get their STIR/SHAKEN
> > certificate by June 30th!
> >
> > I can only give you a ballpark price because it depends on what you
> > need
> > to be done. You need to have an OCN, 499 filer ID, and Robocall
> > Mitigation plan in place before you can apply for the STI-PA.  If you
> > have those in place already the cost is obviously less.
> >
> > I have someone that does the filings for my clients. If a company needs
> > everything she charges between $1200-$1500 range not including the NECA
> > fee for the OCN. If the company already has everything except the
> > STI-PA
> > registration then you're looking in the $300 - $500 range. The variance
> > in cost just depends on whether or not there are any issues with your
> > 499 status.
> >
> > MARY LOU CAREY
> > BackUP Telecom Consulting
> > Office: 615-791-9969
> > Cell: 615-796-1111
> >
> > On 2023-06-02 02:48 PM, Peter Beckman wrote:
> >> What is the most affordable and fast way to get a cert? E.g. how much
> >> should one pay, and to whom?
> >>
> >> On Fri, 2 Jun 2023, Mary Lou Carey via VoiceOps wrote:
> >>
> >>> VOIP carriers were not typically considered facilities-based because
> >>> they didn't have their own switch, circuits, or NXXs connected to the
> >>> ILECs. Now they can get their own NXXs if they get numbering
> >>> authorization from the FCC, but their PSTN connections still have to
> >>> ride another carrier's network to be connected to the ILEC so they
> >>> still fall under non-Facilities based like resellers do.
> >>>
> >>> The only companies that are still exempt are the ones whose entire
> >>> networks are completely operated via SS7 trunking. The only reason
> >>> they are allowed to be exempt is that STIR/SHAKEN doesn't work well
> >>> on
> >>> an SS7 network. Since no one has been able to figure out a way to
> >>> solve that problem, they can't require them to be compliant. So if
> >>> any
> >>> portion of your network operates on VOIP, then you need to get a
> >>> STIR/SHAKEN certificate for that portion of your network.
> >>>
> >>> Sucks I know, but
> >>>
> >>>
> >>>
> >>> MARY LOU CAREY
> >>> BackUP Telecom Consulting
> >>> Office: 615-791-9969
> >>> Cell: 615-796-1111
> >>>
> >>> On 2023-06-01 09:23 PM, Nathan Anderson via VoiceOps wrote:
> >>>> Thanks both to you and Mary Lou for your thoughtful responses.
> >>>>
> >>>> Okay, so just to be clear, the remaining carriers for whom the June
> >>>> 2023 deadline applies to are providers who provide dialtone to
> >>>> end-users via POTS, but who originate at least some of the calls
> >>>> from
> >>>> those end-users to the PSTN via an IP peer/trunk, and it is
> >>>> specifically those calls that they now need to start signing but
> >>>> were
> >>>> exempt from doing so until a month from now?  And the reason that
> >>>> they
> >>>> didn't have to implement a year ago (but pure IP-based
> >>>> interconnected
> >>>> VoIP providers with < 100K subs *did*) is because § 64.6304(a)(1)(i)
> >>>> only applies to "non-facilities-based" providers, and if a telecom
> >>>> is
> >>>> building and maintaining POTS circuits to end-users, they are
> >>>> facilities-based by definition?
> >>>>
> >>>> This gets us into the weeds on the definition of "facilities-based".
> >>>> I assume that the "facilities" in question must be facilities with
> >>>> traditional telecom switching equipment (either analog or TDM).  So
> >>>> even if you run your own pure IP network end-to-end with no
> >>>> underlying
> >>>> leased circuits, and outright own your physical data centers where
> >>>> you
> >>>> house and run all of your own routers and SIP proxies, if 100% of
> >>>> your
> >>>> voice subscriber base is provisioned via VoIP, even if the
> >>>> end-user's
> >>>> VoIP equipment is talking to a server that you own, run, and
> >>>> maintain
> >>>> in your own data center "facilities", you still do not count as a
> >>>> "facilities-based" telecom, correct?
> >>>>
> >>>> Is there some "minimum" amount of actual TDM you can be running on
> >>>> your network in order for you to meet the definition of -- or claim
> >>>> for yourself the status of -- "facilities-based"?  If someone had
> >>>> zero
> >>>> POTS circuits built to any of their end-users & all of their users
> >>>> are
> >>>> connected to their voice network via VoIP, but they have a single
> >>>> ICA
> >>>> with a single LEC, a TDM trunk between them and that LEC (where they
> >>>> immediately gateway the TDM traffic to/from IP as it ingresses or
> >>>> egresses their network), and a presence on the SS7 network...are
> >>>> they
> >>>> now considered to be "facilities-based"?  And would they similarly
> >>>> have had all of their IP-trunked origination (calls that weren't
> >>>> going
> >>>> out via their TDM connection to the LEC) exempted until this year,
> >>>> if
> >>>> they had under 100K subs?
> >>>>
> >>>> As far as my question about white-labeling service goes, to be
> >>>> clear,
> >>>> we aren't in this category and have been signing our customers'
> >>>> calls
> >>>> with our own SHAKEN cert for the past year.  But I know of plenty of
> >>>> other providers of similar size & scale (regional ISP whose bread
> >>>> and
> >>>> butter is internet connectivity, but with a small sprinkling of VoIP
> >>>> on top) who want to have a VoIP offering for various reasons, but
> >>>> simply outsource 100% of the VoIP component to a white-labeler.
> >>>> They
> >>>> bill the customer for the service, and presumably have a 499
> >>>> Filer-ID
> >>>> and file As and Qs with USAC, but they have nothing to do with the
> >>>> underlying voice service...ATAs get drop-shipped to customers from
> >>>> the
> >>>> white-labeler when service is ordered, the ISP doesn't have any hand
> >>>> in the provisioning, they don't operate a single SIP proxy or media
> >>>> gateway, they have zero numbering resources of their own and zero
> >>>> ICAs
> >>>> with other carriers, etc.  It's like the interconnected VoIP
> >>>> equivalent to reselling an ILEC analog POTS line...they're just a
> >>>> middle-man when it comes to billing (and thus, as an indirect
> >>>> result,
> >>>> to collecting and remitting USF) and front-line support.
> >>>>
> >>>> Now of course, many wholesale origination providers these days
> >>>> support
> >>>> having you house your SHAKEN cert on their server & will sign your
> >>>> outgoing calls for you with your own cert, and even those that don't
> >>>> do this will still pass your own signature/Identity header in the
> >>>> SIP
> >>>> INVITEs you send to them unmolested.  But to be able to do the
> >>>> latter,
> >>>> you need to be running a SIP proxy or B2BUA somewhere between the
> >>>> end-user and your wholesale provider, which these other providers
> >>>> I'm
> >>>> talking about aren't doing.  And it's not at all clear to me that
> >>>> most?/many?/any? *white-label* interconnected VoIP providers are set
> >>>> up to do the former...they're all STIR/SHAKEN compliant of course,
> >>>> but
> >>>> I'd guess they are signing all of the calls they originate with
> >>>> their
> >>>> own cert.
> >>>>
> >>>> That's only an educated guess on my part, of course, since I've been
> >>>> looking around even after asking here, and have yet to find any
> >>>> first-
> >>>> or even second-hand accounts one way or the other.
> >>>>
> >>>> -- Nathan
> >>>>
> >>>> -----Original Message-----
> >>>> From: David Frankel [mailto:dfrankel at zipdx.com]
> >>>> Sent: Thursday, June 1, 2023 1:45 PM
> >>>> To: 'Mary Lou Carey'; Nathan Anderson
> >>>> Cc: 'Voice Ops'
> >>>> Subject: RE: [VoiceOps] All carriers must get their STIR/SHAKEN
> >>>> certificate by June 30th!
> >>>>
> >>>> I am not an attorney; this is not legal advice.
> >>>>
> >>>> The (primary) purpose of STIR/SHAKEN was not to help the ITG. The
> >>>> purposes
> >>>> are to (at the terminating or called-party end of the call) identify
> >>>> the
> >>>> entity responsible for originating the call, and allow that entity
> >>>> to
> >>>> signal
> >>>> what they know about the association between the caller and the
> >>>> calling
> >>>> number.
> >>>>
> >>>> We are just about to the point (end of this month) where virtually
> >>>> all
> >>>> providers are required to sign the calls they originate and send
> >>>> onward via
> >>>> IP. That includes providers that serve so-called POTS customers
> >>>> (when
> >>>> those
> >>>> POTS customers place calls sent via other providers). See 47 CFR §
> >>>> 64.6301(a)(2)
> >>>>
> >>>> This applies to the ORIGINATING provider. The expectation, as made
> >>>> clear in
> >>>> the implementing specs and regulations, is that the originating
> >>>> provider
> >>>> KNOWS who the caller is. ATIS says (ATIS-1000088): "Has a direct
> >>>> authenticated relationship with the customer and can identify the
> >>>> customer."
> >>>>
> >>>> If you are a reseller and you are the one with the "direct
> >>>> authenticated
> >>>> relationship with the customer" then your (A- or B-) signature
> >>>> should
> >>>> be on
> >>>> the calls. As noted, you can get a SHAKEN token and delegate the
> >>>> signing to
> >>>> your underlying provider. But it will be your name, and your
> >>>> reputation, on
> >>>> the calls.
> >>>>
> >>>> If you are an underlying provider and you do NOT know who the
> >>>> customer is,
> >>>> then insist that your reseller get a token and either sign the calls
> >>>> or
> >>>> delegate that to you (with their token). If you do not know anything
> >>>> about
> >>>> the caller, then you are risking your reputation (and perhaps more)
> >>>> by
> >>>> signing those calls.
> >>>>
> >>>> More of my thoughts on this topic are here:
> >>>>
> https://legalcallsonly.org/attestation-inflation-the-abcs-of-signing-calls/
> >>>>
> >>>> If you find the regulations confusing, your best bet is to play it
> >>>> safe.
> >>>> That would mean signing calls with your OWN token when your direct
> >>>> customer
> >>>> is the one initiating the calls (that is, they are the "caller" for
> >>>> legal
> >>>> purposes and they are going to take responsibility for conformance
> >>>> of
> >>>> the
> >>>> calls to ALL the applicable regulations -- and there are many,
> >>>> including
> >>>> TCPA, TSR, fraud, and state statutes). You, as the originating
> >>>> provider,
> >>>> still have a set of responsibilities here -- see 47 CFR §
> >>>> 64.1200(n)(3) as
> >>>> ONE EXAMPLE. If the calls come to you from an entity that is not the
> >>>> one
> >>>> initiating the calls, then insist that the calls are signed when you
> >>>> get
> >>>> them (or that your customer provides you with their token so you can
> >>>> affix
> >>>> their signature).
> >>>>
> >>>> As Mary Lou indicates, you are playing Russian roulette if you are
> >>>> originating calls and they do not bear your signature. And your
> >>>> underlying
> >>>> provider is doing the same if they are accepting those calls
> >>>> unsigned
> >>>> and
> >>>> sending them onward.
> >>>>
> >>>> The FCC has a Further Notice of Proposed Rulemaking that is open for
> >>>> comment
> >>>> RIGHT NOW on the topic of "Third-Party Caller ID Authentication."
> >>>> The
> >>>> FNPRM
> >>>> is available here:
> >>>> https://docs.fcc.gov/public/attachments/FCC-23-18A1.pdf.
> >>>> See starting at paragraph 97. Initial public comments on this FNPRM
> >>>> are due
> >>>> June 5 (Monday) and Reply Comments are due a month later. You'll be
> >>>> able to
> >>>> read (and file) comments here:
> >>>>
> >>>
> https://www.fcc.gov/ecfs/search/search-filings/results?q=(proceedings.name:(
> >>>> %2217-97%22)). Once comments are filed the FCC will likely issue an
> >>>> Order in
> >>>> due course, which may be clarifying or confusing or both or neither.
> >>>>
> >>>> David Frankel
> >>>> ZipDX® LLC
> >>>> St. George, UT USA
> >>>> Tel: 1-800-FRANKEL (1-800-372-6535)
> >>>> Visit My Robocall Blog
> >>>>
> >>>> -----Original Message-----
> >>>> From: VoiceOps <voiceops-bounces at voiceops.org> On Behalf Of Mary Lou
> >>>> Carey
> >>>> via VoiceOps
> >>>> Sent: Thursday, June 1, 2023 2:01 PM
> >>>> To: Nathan Anderson <nathana at fsr.com>
> >>>> Cc: Voice Ops <voiceops at voiceops.org>
> >>>> Subject: Re: [VoiceOps] All carriers must get their STIR/SHAKEN
> >>>> certificate
> >>>> by June 30th!
> >>>>
> >>>> US telecom brain trust? Wow......I don't even know what to say, but
> >>>> I'm
> >>>> thinking I should send my 21-year-old your way because he thinks
> >>>> he's
> >>>> a lot
> >>>> smarter than I am. LOL!
> >>>>
> >>>> Im going to preface my response by saying I'm not sure anyone knows
> >>>> exactly
> >>>> what the ruling means because I've called the FCC and STI-GA
> >>>> multiple
> >>>> times
> >>>> to ask specific questions like yours. Any time my question gets too
> >>>> detailed, I've been told to go read the ruling myself because they
> >>>> aren't
> >>>> attorneys and don't want to give legal advice that would steer me in
> >>>> the
> >>>> wrong direction. I don't know of any attorneys that have felt so
> >>>> comfortable
> >>>> discussing the details of the network that they have gone out on a
> >>>> limb to
> >>>> explain it to everyone either, so I can only tell you what I think
> >>>> based on
> >>>> what I've been told to date.
> >>>>
> >>>> My understanding from talking to the FCC and STI-GA is that the
> >>>> purpose of
> >>>> STIR/SHAKEN was to help the ITG identify all the players in the
> >>>> industry so
> >>>> the ITG can more easily shut down the bad players and if necessary
> >>>> the
> >>>> providers that enable those bad players. To me, that means
> >>>> regardless
> >>>> of
> >>>> whether a company has its own network,  leases another carrier's
> >>>> network, or
> >>>> resells services, the FCC wants to identify every player in the
> >>>> network. We
> >>>> can debate which networks are exempt and which networks aren't, but
> >>>> ultimately there's not a lot you can do if the powers that be decide
> >>>> your
> >>>> network should be compliant and it's not.
> >>>>
> >>>> The choice to get a STIR/SHAKEN certificate is ultimately up to each
> >>>> company. They can either play it safe and get a token or they can
> >>>> play
> >>>> Russian Roulette with their business and not get a token. To date,
> >>>> I've seen
> >>>> the FCC/ITG give non-compliant carriers 30 days to become compliant,
> >>>> but
> >>>> that's not always enough time. I don't know if that is going to
> >>>> change after
> >>>> the deadline, but it could. It's not that difficult to get your own
> >>>> certificate and if another carrier is already signing your calls
> >>>> it's
> >>>> not
> >>>> that much more cost-wise to have your own certificate. So to me it's
> >>>> better
> >>>> to be safe than sorry.
> >>>>
> >>>> I hope that helps,
> >>>>
> >>>> MARY LOU CAREY
> >>>> BackUP Telecom Consulting
> >>>> Office: 615-791-9969
> >>>> Cell: 615-796-1111
> >>>>
> >>>> On 2023-05-31 09:33 PM, Nathan Anderson via VoiceOps wrote:
> >>>>> I do find this a little confusing.
> >>>>>
> >>>>> It's already clear that POTS service has been made exempt "until
> >>>>> further notice".  So when the small operators exemption deadline
> >>>>> was
> >>>>> pushed up from end of June 2023 to end of June 2022, that -- by
> >>>>> logical deduction -- could only have included small interconnected
> >>>>> VoIP operators (which I believe was made explicitly clear anyway,
> >>>>> but
> >>>>> even if it had been ambiguous in the language, ...).
> >>>>>
> >>>>> So, out of all the interconnected VoIP operators in the States
> >>>>> large
> >>>>> OR small...who the heck is left who HASN'T already been required to
> >>>>> have it implemented on their network by this point??  I don't
> >>>>> understand who this June 2023 deadline applies to: the POTS circuit
> >>>>> providers aren't covered by it, and all sizes of interconnected
> >>>>> VoIP
> >>>>> providers should have already implemented it a year ago at the
> >>>>> latest.
> >>>>>
> >>>>> Another question that occurs to me (I could probably find the
> >>>>> answer
> >>>>> to this question with a little searching, but since I'm already
> >>>>> here
> >>>>> talking to the U.S. telecom brain-trust): would a provider who
> >>>>> merely
> >>>>> supplies white-labeled service from another interconnected VoIP
> >>>>> provider and slaps their own name on it be required to obtain their
> >>>>> own SHAKEN cert, and have the underlying VoIP provider sign any of
> >>>>> their customers' calls with that cert instead of a cert belonging
> >>>>> to
> >>>>> the actual VoIP provider, even if the white-labeler/reseller has
> >>>>> literally nothing to do with the network at all that services the
> >>>>> calls?
> >>>>>
> >>>>> -- Nathan
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of
> >>>>> Michael Graves via VoiceOps
> >>>>> Sent: Wednesday, May 31, 2023 1:12 PM
> >>>>> To: Mary Lou Carey; Alex Balashov
> >>>>> Cc: voiceops at voiceops.org
> >>>>> Subject: Re: [VoiceOps] All carriers must get their STIR/SHAKEN
> >>>>> certificate by June 30th!
> >>>>>
> >>>>> There was an extension for "small" providers (under 100k lines)
> >>>>> ends
> >>>>> on June 30, 2023.
> >>>>>
> >>>>> That extension was basically was targeting rural LECs. It was
> >>>>> amended
> >>>>> so it only included those who have physical infrastructure to their
> >>>>> clients.
> >>>>>
> >>>>> Those who do not operate such legacy infrastructure are supposed to
> >>>>> be
> >>>>> signing their calls as of June 30, 2022.
> >>>>>
> >>>>> There are further "gateway" orders about how any operator is
> >>>>> supposed
> >>>>> to handle calls arriving on their network that are not signed.
> >>>>>
> >>>>> Michael Graves
> >>>>> mgraves at mstvp.com
> >>>>> o: (713) 861-4005
> >>>>> c: (713) 201-1262
> >>>>> sip:mgraves at mjg.onsip.com
> >>>>>
> >>>>> -----Original Message-----
> >>>>> From: VoiceOps <voiceops-bounces at voiceops.org> On Behalf Of Mary
> >>>>> Lou
> >>>>> Carey via VoiceOps
> >>>>> Sent: Wednesday, May 31, 2023 2:46 PM
> >>>>> To: Alex Balashov <abalashov at evaristesys.com>
> >>>>> Cc: voiceops at voiceops.org
> >>>>> Subject: Re: [VoiceOps] All carriers must get their STIR/SHAKEN
> >>>>> certificate by June 30th!
> >>>>> Importance: High
> >>>>>
> >>>>> Any carrier that provides originating VOIP or a combination of
> >>>>> originating VOIP / PSTN /  Wireless VOICE services needs to get its
> >>>>> own certificate. My understanding is that only those who provide
> >>>>> PSTN-only voice services do not need to have their own STIR/SHAKEN
> >>>>> token because the technology still does not support it.
> >>>>>
> >>>>> Mary Lou Carey
> >>>>> (615) 796-1111
> >>>>>
> >>>>> MARY LOU CAREY
> >>>>> BackUP Telecom Consulting
> >>>>> Office: 615-791-9969
> >>>>> Cell: 615-796-1111
> >>>>>
> >>>>> On 2023-05-31 02:11 PM, Alex Balashov wrote:
> >>>>>> Hi Mary Lou,
> >>>>>>
> >>>>>> Thank you for this.
> >>>>>>
> >>>>>> A stupid - and certainly belated - question: how exactly is a
> >>>>>> carrier
> >>>>>> defined, in the letter of the regulations underlying this
> >>>>>> deadline?
> >>>>>> Or to put it another way: who, as a VoIP service provider of one
> >>>>>> sort
> >>>>>> or another, _doesn't_ have to get their own token?
> >>>>>>
> >>>>>> -- Alex
> >>>>>>
> >>>>>>> On May 31, 2023, at 1:46 PM, Mary Lou Carey via VoiceOps
> >>>>>>> <voiceops at voiceops.org> wrote:
> >>>>>>>
> >>>>>>> Hey all,
> >>>>>>>
> >>>>>>> I just wanted to send out a reminder that the drop dead date for
> >>>>>>> all
> >>>>>>> carriers to get THEIR OWN STIR/SHAKEN certificate is coming up on
> >>>>>>> June 30th. You can still have an underlying carrier sign your
> >>>>>>> calls
> >>>>>>> for you, but they must sign with YOUR token......not their own!
> >>>>>>> You
> >>>>>>> have to register with the STI-PA to start the process at this
> >>>>>>> link:
> >>>>>>>
> >>>>>>> https://authenticatereg.iconectiv.com/register
> >>>>>>>
> >>>>>>> You must have your own IPES Company Code (aka OCN) and 499 filer
> >>>>>>> ID
> >>>>>>> to get a STIR/SHAKEN certificate. Just getting the certificate
> >>>>>>> can
> >>>>>>> take up to several weeks so please don't wait until the last
> >>>>>>> minute
> >>>>>>> to get one. I would hate to see anyone's network get shut down
> >>>>>>> because they aren't signing their calls as per the FCC
> >>>>>>> guidelines.
> >>>>>>>
> >>>>>>> MARY LOU CAREY
> >>>>>>> BackUP Telecom Consulting
> >>>>>>> Office: 615-791-9969
> >>>>>>> Cell: 615-796-1111
> >>>>>>> _______________________________________________
> >>>>>>> VoiceOps mailing list
> >>>>>>> VoiceOps at voiceops.org
> >>>>>>> https://puck.nether.net/mailman/listinfo/voiceops
> >>>>> _______________________________________________
> >>>>> VoiceOps mailing list
> >>>>> VoiceOps at voiceops.org
> >>>>> https://puck.nether.net/mailman/listinfo/voiceops
> >>>>> _______________________________________________
> >>>>> VoiceOps mailing list
> >>>>> VoiceOps at voiceops.org
> >>>>> https://puck.nether.net/mailman/listinfo/voiceops
> >>>>> _______________________________________________
> >>>>> VoiceOps mailing list
> >>>>> VoiceOps at voiceops.org
> >>>>> https://puck.nether.net/mailman/listinfo/voiceops
> >>>> _______________________________________________
> >>>> VoiceOps mailing list
> >>>> VoiceOps at voiceops.org
> >>>> https://puck.nether.net/mailman/listinfo/voiceops
> >>>> _______________________________________________
> >>>> VoiceOps mailing list
> >>>> VoiceOps at voiceops.org
> >>>> https://puck.nether.net/mailman/listinfo/voiceops
> >>> _______________________________________________
> >>> VoiceOps mailing list
> >>> VoiceOps at voiceops.org
> >>> https://puck.nether.net/mailman/listinfo/voiceops
> >>>
> >>
> >>
> ---------------------------------------------------------------------------
> >> Peter Beckman
> >> Internet
> >> Guy
> >> beckman at angryox.com
> >> https://www.angryox.com/
> >>
> ---------------------------------------------------------------------------
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20230607/d870ddb9/attachment-0001.htm>