Telephony, like email or any other public communication channel, is limited by the weakest link, and for telephony that is the PSTN. A switched network that utilises protocols like SS7, ISDN, and TDM, none of which ever envisioned that somebody picking up a physical phone, from the physical location, over a physical copper wire could be anything other than that phone number allocated to it.

Fast forward to the evil scum-filled future of today, and with the widespread use of 'internet telephony' and SIP Trunks meaning that anybody can get and use a telephone number from pretty much anywhere in the world. And what's also incredibly easy to achieve, is to configure their system to identify as almost ANY number. Meaning that you can no longer trust that the person calling you is actually calling from the number you see on your device.

This article will not be a deep dive, but it will be pretty comprehensive and dip into some of the history and context around this topic. To make up for it, I've strategically inserted memes to try and keep your attention on this page. Enjoy!

How do we stop the scammers?

After all this is what we're all trying to achieve...

Option one, that I personally like, is to keep them talking for as long as possible so they are not able to use that time targeting vulnerable and unsuspecting victims.

I look back fondly to the time when I kept a person talking for nearly 20 minutes who was trying to tell me they could improve the quality of my phone calls if I just provided my personal details with them to confirm it was my account. So I acted my heart out apologising for the quality of the call being so bad I couldn't hear them and if only somebody was able to fix it for me I would pay dearly.

What can I say, I must be a convincing actor...

But the time that I'm most proud is this little childish gem of how the call ended after them trying to convince me that I'm paying too much and asking if I would like a discount on my current contract? What did I say?...

Yeah, I'd like a discount.... a discount on YO MUMMA!

I laughed... they hung up. I'm not a vindictive person, but I did enjoy a brief moment thinking about the expression on their face as they had the sudden realisation that they've lost their mark and wasted their own time and effort, and I also like to think that perhaps in that moment there was a subtle shift in the balance towards justice, but then also feel sad for the situation they must be in to resort to that line of work in the first place. It couldn't have been their first choice for a career.

Option two, is for everybody to come together and agree to build additional functionality or extensions on top of existing protocols. If you've ever had experience with SMTP and saw the arrival of STARTSSL vs TLS and then the various S/MIME and even SPF/DKIM and various other related security measures, they you will likely know how potentially useless they can be unless fully supported and implemented correctly with everybody you're communicating with.

STIR/SHAKEN Overview

Let's break this down...

What is STIR?

Secure Telephony Identity Revisited (STIR) was created by the Internet Engineering Task Force (IETF) as a way to add a digital certificate to SIP when a call is setup for the terminating side to validate the authenticity of that caller.

It's a collection of RFCs that cover the following topics:

• RFC 8224 - Authenticated Identity Management in the Session Initiation Protocol (SIP)
  • This talks about how certificates can be used in SIP messages regarding identities.
• RFC 8225 - PaSSporT: Personal Assertion Token
  • This talks about how a certificates and tokens can be created and validated. Which is an evolution of RFC 4474 regarding SIP Headers for providing authentication around identity, which itself is an extension of RFC 3261 which is the document that defines SIP and in this context the 'identity' specific headers such as FROM, PAI, PPI, etc - which are not authenticated in any way whatsoever by default.
• RFC 8226 - Secure Telephone Identity Credentials: Certificates
  • This talks about how to trust certificates, therefore trust the numbers.

What is SHAKEN?

Other than a laborious but pun-worthy attempt to create a James Bond related name when combined with STIR, which is exactly what it is... SHAKEN comes from "Signature-based Handling of Asserted information using toKENs"... to the people that worked tirelessly to come up with the name instead of focussing on the content, I applaud you.

SHAKEN is a way to actually implement the various RFCs that make up STIR and extend it suit North American telephony to so it conveys additional information on the level of confidence (called the attestation level), as well as a 'governance model for distributing certificates' to uniquely identify the origin of the calls etc.

• RFC 8588 - Personal Assertion Token (PaSSporT) Extension for Signature-based Handling of Asserted information using toKENs (SHAKEN)
  • This talks about how RFC 8225 (PaSSporT) should be used based on guidance from ATIS and SIP Forum IP-NNI Task Group to include that stuff I just mentioned, where you not reading?

What is the ATIS/SIP Forum IP-NNI Task Force?

I did say this wasn't a deep-dive, but if you're like me - any acronym presents as a rabbit hole that needs investigating. So I'll quickly say...

ATIS are the "Alliance for Telecommunications Industry Solutions" which is a US-based non-profit organisation that's funded and run by the hundreds of member companies that all have some sort of stake in the telecommunications industry.

The SIP Forum, are another non-profit organisation, again made up of member companies, but they act more like a community to lead and facilitate other working groups (like ATIS).

The IP-NNI Task Force (Network to Network Interface Task Force) is a joint/combined effort comprising of ATIS and SIP Forum together - and their focus in this task force is how different IP-based technologies interface among service providers and where possible work nicely with other legacy technologies that are still around.

And with all those large corporate bodies paying good old fashioned cash just to be part of something that sets the standards and influences how the industry operates, the industry they operate in, and therefore influences the flow of money, it's surprising I didn't even mention lobbying once.

Global Coverage?

With the question mark in the heading, you can probably guess correctly that despite the multiple forums, task forces, and countless paid up full-member organisations involved trying their best, that it's simply not global.

Nope, far from it, let's just take one example of the UK. Ofcom, the UK's communications regulator worked with the UKCTA advisory body, and has assessed the technologies in great depth, and in June 2023 ultimately rejected it.

And in bold they write...

Call authentication and STIR/SHAKEN is not the solution

And they go on to mention that since 2019 only US and Canada have implemented STIR/SHAKEN, and France reportedly have it 'under development'. Other countries such as Australia and Singapore are opting for 'other measures' instead. And according to Scamwatch data, whatever it is that's being done in Australia is showing positive decreases in the amount of money lost due to scams - which is a broader remit than simply decreasing the amount of robocalls by introducing a trust level for the number you see on your phone. And many other countries combat fraudulent activity by performing a KYC (Know Your Customer) check, where individual employee's personal identification documents are required to get a work phone number, and proof is required on the number of employees so you can't get significantly more numbers than people. Anyway, there's plenty of other options that seem to work well, but I digress...

Back to Ofcom's response, and I quote this part because I love the way they've chosen to word it:

STIR/SHAKEN is a technology that has proven to be useful for the elevation of trust in good calls, but implementing this technology does not stop spoofed or fraudulent calls. There is no current technology that will substitute for aggressive enforcement against the bad actors, originating scam or fraudulent calls

And one final quote purely for my own pleasure, which is what this blog is ultimately about.

Proceeding incrementally and in a more technology-neutral way will allow UK stakeholders to benefit from learnings STIR/SHAKEN that have proved to be ineffective.

Which, all together, means despite it's help in increasing the confidence in good calls, it's not seen as being effective for preventing bad calls. And amongst everything else it's incredibly difficult/impossible to work across borders and geographies, so if you want to scam somebody just send it as an international call, problem solved.

So yeah, it's basically just US and Canada, which just so happens to be where the few large companies that will benefit from all the carriers and resellers who will have to pay for their certificates, just so happen to be located. (And no I've not looked into it at all, but let's face it, why let facts get in the way of a sensationalised rhetoric for theatrical and divisive purposes, if it's good enough for privately owned mainstream media... opps, there I go again).

And if you think about it, like my brain curses me to do... this is like most other preventative measures that idiotic bureaucrats that have positions elevated beyond their ability across the government tend to introduce (regardless of how good the underlying technical idea or purest of intentions may be), it relies on criminals to play by the rules, which they're not really well known for doing.

For example, don't get me started on Drone Laws in the USA, specifically the abysmally idiotic 'Remote ID' regulations.

Back on topic, you can imagine following situation with a carrier

Hi, I'm a telephony reseller, and can say that all the calls I transmit to the network from my customers are legitimate. Because my customers pay me lots of money to say so. Can I get some numbers please?

If/when they get caught... or the fines get too much.

Hi, I'm a totally different telephony reseller, and I will say that all the calls I transmit to the network are legitimate. Can I get some numbers please?

I'm sure they're not put off by occasionally having to set up a new bank accounts and company names etc.

The downside for legitimate usage

As you can probably tell by my tone so far, I'm not totally excited, nor am I currently getting remotely moist at the thought of STIR/SHAKEN. That's possibly because of many life-experience wearing me down.. Consider this...

You have a very common situation where a bunch of contact center agents need to call out to customers and present a single unified telephone number. Bog standard CLI spoofing or masking. Every company with a marketing department would jump at the chance to stick their mucky influential branding finger in all the pies.. 1-800-freelunch is calling again, yay!

But let's say that phone number is actually held with a different carrier because it's toll-free and forwarded, or it's hooked up directly to some fancy 3rd party marketing analysis system with chatbots and all sorts of AI triage to force a caller to go through painful questions before routing the call to a real person via their real number.

So now the carrier has to deal with the paperwork and alterations to their system to prove that they have checked and can confirm the level of confidence they have on the numbers they DON'T host - but their customer DOES legally own (perhaps by a different legal entity under an umbrella group of companies and now they're asking for whatever might be required to prove there is a link between them); and that this non-hosted / customer-owned number is legitimately being used by the people who are trying to use it... and that's originating from the carrier's own network. (Thanks for following all of the inappropriate punctuation in that needlessly long, multi-layered sentence).

All that just to show a customer's main-line number on some of their outbound calls.

Has Ofcom in the UK killed STIR/SHAKEN?

They may have been the first, but certainly won't be the only regulator to point out the holes in the current plan outweigh the effort to implement and operate, leaving way for something else to come along and actually work.

And who better than the US to once again be the best country to disprove their own advice. Which is that STIR/SHAKEN will rapidly expand and get introduced everywhere that a PSTN line exists because they are simply the best, better than all the rest...

Calls with STIR/SHAKEN C-Attestation Almost 6 Times More Likely to Be Robocalls than Unsigned Calls | Commsrisk

One billion bad calls were ‘authenticated’ during June by systems which were supposed to protect Americans from bad…

CommsriskEric Priezkalns

Can you believe it? This is around the same time Twitter started charging for blue ticks, and the fiasco which completely eroded all confidence in the 'authenticity' of the platform's 'verified' users.

So, yes, yes I can believe it. Scammers have the money and the motivation to exploit the systems designed to catch them out. And just like somebody being able to buy a blue tick, scammers/robocallers/whatever you classify the people that make unwanted or nuisance calls, have done it already - bit of a backfire there considering that even being classified with low confidence is better than not classified at all, that's a smart move if it was intentional.

So, have Ofcom they killed STIR/SHAKEN? Probably not, but I hope they've managed to stop it in its tracks and shown countries they don't have to blindly follow the US in fear of being left behind. You can hold out for something better, don't settle, you're worth it!

What's happening in 2025?

Now, ok, to be clear, that article above was from a few years ago, and technology never sleeps. And from 20th June 2025, the rules will change somewhat.

The "Eighth Report and Order" (released in November 2024) outlines the following things...

Firstly it blames carriers for not implementing STIR/SHAKEN properly, insinuating that they caused the situation outlined in the above article. But that's an aside. 😅

1. Each 'voice service provider' must use their own certificates, and can no longer rely on the next hop carrier's STIR/SHAKEN signing solution.
2. Not only that, but the 'voice service provider' is now solely responsible for attesting the calls they originate. The authentication and decision making 'buck' stops with them.
3. Entry in the FCC's Robocall Mitigation Database is also dependant on using their own certificates as above, or they'll be removed, which will likely impact the delivery of calls from their network/customers.

Who is a Voice Service Provider?

The TRACED Act 2019, oh yeah, that's the origin of all of this, and I've not even mentioned it... it stands for Telephone Robocall Abuse Criminal Enforcement and Deterrence. So now you know. Moving on...

Annoyingly 'voice service provider' isn't explicitly defined in the Act, but it does define 'voice service' as...

VOICE SERVICE.—The term ‘‘voice service’’— (A) means any service that is interconnected with the public switched telephone network and that furnishes voice communications to an end user using resources from the North American Numbering Plan or any successor to the North American Numbering Plan adopted by the Commission under section 251(e)(1) of the Communications Act of 1934 (47 U.S.C. 251(e)(1)); and (B) includes— (i) transmissions from a telephone facsimile machine, computer, or other device to a telephone facsimile machine; and (ii) without limitation, any service that enables real-time, two-way voice communications, including any service that requires internet protocol-compatible customer premises equipment (commonly known as ‘‘CPE’’) and permits out-bound calling, whether or not the service is one-way or two-way voice over internet protocol.

That is generally interpreted as any originating or terminating service provider, but not an intermediary service provider that merely handles calls between other carriers that are originating, or terminating calls. Whereas those were generally included by the similar definitions used in other acts and has also been generally adopted prior this by the industry, which was a cause for some confusion. 🤡

To sum up, any company that's handling calls to/from end-customers via their own equipment would be classed as a 'voice service provider' and therefore obligated to implement STIR/SHAKEN themselves.

What do I need to know?

Right then, here we go... here's a list of things and their meanings and how they all fit together so you can sound informed and knowledgeable at your next dinner party or social gathering at the pub.

How to become a voice service provider

To become a voice service provider (also known as an authorised provider), you'll need:

• to be registered with the FCC and contributing to the USF.
• have an Operating Company Number (OCN) from the National Exchange Carrier Association (NECA).

The OCN is used to obtain a Service Provider Policy Token... which leads me nicely on to...

Service Provider Policy (SPC) Token

The voice service provider uses their OCN to get the SPC Token from the the Secure Telephone Identity (STI) Policy Administrator, this token is used in the process to get a signing certificate.

Policy Administrator

This is the organisation that is responsible for all of this really, at least at a country-level or some other agreed geographic jurisdiction.

In the US, the 'Policy Administrator' responsibility has been granted to a company called iconnectiv^®. And they maintain a list of approved Certification Authorities on their website.

Certification Authorities

These are companies approved by the Policy Administrator in the country or region they're responsible for. Certification Authorities can issue certificates for authorised providers.

Authorised Providers

These are the 'voice service providers' with certificates and have correctly implemented STIR/SHAKEN so they can both validate terminated calls, as well as the most important part which is they can sign the calls that originate from them and therefore also determine the attestation level for that call.

Attestation Indicator

This refers to the 'levels' that are referenced in the SHAKEN RFC, can you remember the number? I can't, let me google it again, 2 secs... RFC 8588 😉. But that's just a pit-stop link to another source. They're actually defined in ATIS-1000074

Full Attestation

Also known as "A", this full attestation means the voice service provider is satisfied that all of the following conditions are true.

• they are responsible for the origination of the call
• has a direct authenticated relationship with the customer and can identify the customer
• has established a verified association with the telephone number used for the call

In this situation the voice service provider is attesting that THEIR customer is making the call through them, and can "legitimately" use the telephone number that appears as the CLI (i.e., the Caller ID).

And the decision around the 'legitimately' part being up to the provider means, and I quote from ATIS here, "the service provider's reputation may be directly dependant on how rigorous they have been in making this assertion".

Partial Attestation

Also known as "B", this partial attestation requires the voice service provider to be satisfied that the following are all true:

• they are responsible for the origination of the call - same as above
• has a direct authenticated relationship with the customer and can identify the customer - same as above
• has NOT established a verified association with the telephone number being used for the call

Essentially this level is the voice service provider saying "I know who made this call, but I've no idea who's number that is". I'm imagining this will be flagged by your operator as 'possible spam' if you received that call.

But I can see a problem with this, 99% of all business phone systems have the ability to forward calls, or simultaneously ring your mobile when your office phone rings... In that scenario, the BEST score that call would ever get is a "B".. because the Caller ID being presented by your phone system would be the person calling you, and YOU don't own their number, nor do you have any claim over using that number for your calls.. do you? Well, that's where the discretion of the voice service provider comes in, I'd personally say that was a legitimate use-case to present that original number on your outgoing call, but how am I going to ensure my platform can reliably determine that each call that attempts to present a 'non owned number' is a legitimate forwarded call, or any other use-case that I'm willing to stake MY reputation on.

Will it mean that all sim-ring or forwarded calls will be marked as possible spam? or that people will start re-configuring their phone systems to NOT present the caller ID on the forwarded call to get that "A" rating? Meaning that no employee will answer a call 'from themselves' if they're out and on the move, like how nobody answers anonymous calls already?

I guess, ideally, the system could pass on the SHAKEN attestation and signing details from the original caller, but wait, they can't because it's a different call - this isn't the case of an intermediary voice service provider taking a call from one carrier and handing it off to another. So the next option could be for the voice service provider to 'trust' the incoming attestation, and therefore 're-sign' the outgoing forwarded call.. but that means that the requirements are not satisfied, they DO NOT have a direct relationship with the originator, nor do they have the proof the number was theirs to use.

I have so many questions... but let's at least try and finish this blog before I need to buy additional hosting space for how long it's getting.

Gateway Attestation

Finally the last options here is "C", gateway attestation doesn't require anything at all really.

• has no relationship with the originator of the call

This is the lowest level, and basically no attestation or authentication has happened at all, I'm not sure how different this is to handling an unsigned call, except that an unsigned call might not be spam, but one with gateway attestation has no way to determine that either has it? Except perhaps through the lack of any other signed attestation level to say it's good. I'm imagining this level will be flagged by your operator as 'likely spam' if you received that call.

If you've paid attention you might be thinking, wait a minute, that article about more attested calls were spam that unattested calls means that it's working then right? so it's is a good thing the ratio is higher? You also might be thinking why on earth am I reading this hot garbage of a topic. For the sake of my sanity, let's assume it's the former.

Considering that "C" is essentially "I have no confidence in the caller, or the number of this call"... then it sounds like it's working as intended, and surely then it's expected that something given that level IS actually likely to be spam? So, as I said, it's working, yeah? But yet it still falls short of the whole damn point it was introduced for...

How do I know? Well, here's a graph using data from YouMail's Robocall Index (seemingly the most respected and most authoritative source of spam and nuance call data in the US), this shows the number of robocalls calls each month, since the TRACED Act was released in December 2019, and how it's impacted the amount of robocalls, the dotted line is Excel's 'linear trend line'.

Erm, yeh, do you see it? I don't. Seems like it's going up.

But that's just one more thing that I'll touch on in this article that builds up to the very valid point I make at the end (even if I do say so myself).

B.t.w., The big dip on the left of this chart, was when the world first started reacting to the outbreak of the COVID-19 pandemic and many countries went into lockdown so people couldn't sit in their cramped, inhumane, call centers to make any calls, nuisance or otherwise.

What might explain the trendline a little: is the Act was released in 2019, but the date for it to be implemented in the US was June 30th 2021, and because carriers were able to apply for an extension, a year after the initial deadline - in June 2022 - only 12% of carriers had actually completed their implementation, and that's according to TransUnion, along with this other statistic that as many as 67% of carriers had not even began to implement STIR/SHAKEN at that time.

Ways to Implement STIR/SHAKEN

Voice service providers have three options to implement their SHAKEN obligations under the Act:

• Hosted SHAKEN - use a 3rd party public or private cloud hosted solution to sign calls originating from the voice service provider's platform. Many reputable companies advertise this service, the voice service provider MUST determine the correct attestation level for each call, and use their own certificate for signing.
• Carrier SHAKEN - similar to the hosted option, but handled by the 'next hop' carrier through a contractual agreement for PSTN egress services. Even with this approach, the of the voice service provider MUST STILL determine the correct attestation level for each call, and the carrier must use the voice service provider's certificate.
• SHAKEN Software - this is commercially available software that can be installed/deployed and run 'in-house' by the voice service provider. Needless to say, the voice service provider MUST determine the correct attestation level for each call in this scenario anyway, and obviously they would also need to use their own certificate for signing too.

So every avenue requires the voice service provider to get a certificate and be instrumental in determining their trust level of each call, and signing the call with the appropriate attestation level.

How to sign a call

So, if you've made it this far you're probably working for a telephony service provider (i.e., a reseller or aggregator that sells direct to end-customers), and you want to know how to be a good little provider and not a criminal.

Assuming you've complied with all of the above requirements and have your chosen SHAKEN solution in place and operational...

The process is incredibly similar to any other 'public key infrastructure' (PKI) technique. It's essentially X.509, the same thing that underpins all TLS and HTTPS encrypted website traffic.

The resulting signature for the call is generated by the voice service provider's authentication service (hosted, carrier, or software), and inserted as an 'Identity' header.

SIP Identity Header Example

The value of the SIP Identity header is a JWT token (you'll be familiar with JSON Web Token if you've done any API calls or work with bearer tokens/access tokens from OAuth, OpenID Connect, etc).

The JWT token is made up of a header, the payload, and your signature. Followed by some clear text parameters.

SHAKEN JWT Header Details

• "alg" is used to specify the encryption algorithm used. e.g., "ES256" which is standard for JWTs.
• "typ" is used to specify the token type used. e.g., "passport"
• "ppt" is used to specify the PaSSporT type used. e.g., "shaken"
• "x5u" is used to specify the X.509 Certificate URL that was used to sign this token.

SHAKEN JWT Payload Details

• "attest" is the parameter that contains the A, B, or C attestation level.
• "dest" is the parameter that contains the destination telephone number, i.e., the called number.
• "iat" is the issued at timestamp in Unix Epoch format.
• "orig" is the parameter that contains the originating telephone number, i.e., the Caller ID presented on the call that all this relates to.
• "origid" is the parameter that contains an opaque string (i.e., uniquely identifies something without giving away what it identifies) so that the voice service provider can trace the call back to the data center, node, access network, customer, customer's trunk, or any other interconnecting nodes, or device classes, or absolutely anything else that needs to be used as evidence to prove the reputation or identification to trace it back to the source etc. This is usually a GUID/UUID that the provider generates from their environment, probably lives in a spreadsheet and never looked at, that kind of thing.

SHAKEN JWT Signature Details

Nothing to explain about this really, this is the linchpin of the whole thing, this is the digital signature that 'proves' the rest is correct and has not been tampered with.

SHAKEN Additional Parameter Details

These are sent in clear text after the JWT itself in the same header:

• "info" contains the URL of the X.509 Certificate that was used to sign this call, this parameter MUST match the x5u parameter from inside the JWT.
• "alg" is the encryption algorithm, again this will be ES256.
• "ppt" as above, will be "shaken" since that's the PaSSporT type being used.

SHAKEN Certificate Signing Process Overview

I joke, I joke... It's as simple as 1,2,3,4,5

1. receive a call from your customer (i.e., a SIP INVITE)
2. send the details to your authentication service that's pre-configured to use your certificate
3. get the signature back along with the other details to create the JSON Web Token
4. Add that token and corresponding additional parameters into an SIP Identity header in the INVITE
5. Fire and forget, your work here is done.

Oh, this will obviously add a bunch of bytes to your SIP INVITE, and if you're using UDP Trunks you may already be butting up to the maximum MTU size, meaning you may have to reconfigure all of your infrastructure to at least support TCP if not TLS to handle the larger messages, if you don't already.

SHAKEN Certificate Validation Process Overview

1. receive a call to one of your customers
2. take the JWT and decode it's payload, and check it against the signature using your very own authentication service
3. the authentication service will get the certificate from the URL provided, and follow the chain back up to the Certificate Authority that signed it, and validate that against the Policy Authority at the top of the tree, or 'root' as IT people decided to call it🌳
4. If it's valid allow the call through, and wash your hands of it
5. If it's not valid, YOLO, send it, don't sent it, tell your customer, don't tell your customer, it's totally up to you and your conscience as a terminating carrier.

Wait what? That last point can't be right, surely....

Receiving calls with SHAKEN

And this is yet another case where it's a nice idea, but falls apart.

Basically nothing is mandated, you don't have to take any action at all based on the attestation level of a call, or if it doesn't have one at all, you can just deliver all the calls as you did previously if you liked, marvellous huh?

It's up to each terminating carrier to decide what to do, they are well within their rights to drop the call completely, or they could reject the call and let the person know via some sort of notification, or they could let it go through with or without some additional notification happening.

Basically they have no obligation to do anything based on the attestation level, but they are permitted to use the attestation level as part of their call analytics and robocall mitigation approaches.

So it's basically whatever idea the marketing team cooks up to scare customers and to attract them as their new carrier, in the glimmer of hope that they'll get less nuisance calls.

I'm actually laughing to myself right now, imagining how that legitimate sales call would go...

Hello, are you interested in getting less spam calls? is your current provider not giving you a quality service? would you like improved quality, and a discount?... erm. please don't ask for a discount on my mum again like last time.

And meanwhile each call you get, will mean that somebody, somewhere will have paid for the privilege of their carrier adding a little digitally signed squiggle that says:

Hiya, this is the highest level of assurance I can give..., I'm the carrier that this call originated from, you may have never heard of me in your life, and I might only have a handful of customers with suspicious names, but anyway, I'm relatively sure they are who they say they are, and that they have some kind of self-claimed right to use this number that I've decided to believe. You can do whatever you like with this information.

I've highlighted the important fundamental parts to STIR/SHAKEN, that you'll notice are also practically useless.

Basically it doesn't matter what's said between the highlighted bits, and that's the whole point I'm trying to make, and I believe a significant reason why the UK have rejected it as a solution as it fails to effectively provide any prevention to illegitimate CLI spoofing.

So what should you do?

Follow the rules, obviously. Stick a 'remote ID' device on your drone so you can be tracked when you're not up to nefarious activities.

And if you're a carrier operating in the US, you should sign all of the calls that originate from your platform, to say that you have documented proof you know the customer is who they say they are, and you have checked that they own or are using that number for legitimate purposes, or if not, mark them down to a B, since you have no real control over what the receiving carrier decides to do about it anyway. Hell, mark it as a C for all the good it might do.

Let me know when the next ride off this planet is due to depart. Bon voyage!