STIR/SHAKEN is a substantial technology aimed at stopping "robocalling" by targeting the unverifiability of Caller ID. The hypothesis is that if call recipients could really know who was calling, we could better judge whether we wanted to answer the call.
In November 2018, US Federal Communications Commission (FCC) sent letters to major Telephone Providers, including AT&T, Verizon, and Comcast, asking them to implement STIR/SHAKEN in 2019.
In Canada, the CRTC has required many providers to implement STIR/SHAKEN telephony validation within 2019.
Some of the major telephone providers have hinted they would have STIR/SHAKEN operating in their networks before summer, 2019. The goal is to provide a special display on telephone calls.
Display examples courtesy Richard Shockey, Shockey Consulting.
STIR/SHAKEN does not block any telephone calls. But when it is fully implemented, customers and Voice service providers may choose to block calls that do not come from a verifiable Caller ID. If you can't tell who's calling, you probably don't want to talk to them.
STIR/SHAKEN adds a new cryptographically-signed header to the SIP header of telephone call. Many SBCs block unknown headers, but the new Identity header should be allowed to pass through the network unchanged to allow the recipient to validate the call.
The Identity header will be computed by the "Authentication Service" function, and then added to the SIP message. The Identity header is expected to transit the network unchanged to the final recipient, who will verify it with the "Verification Service" function. The Identity header includes both the original calling party number, called party number, and also an indication of the confidence that the originator has in the validity of the caller ID -- i.e., the "attestation level". A "fully attested" call is one for which the Voice service provider has absolute confidence that the caller has the right to make a call from that telephone number.
It is possible for Voice service providers to wrongly "attest" ownership and validity of telephone numbers; they can produce Identity headers that they should not. If a Voice service provider is discovered to do this, then other service providers may choose not to trust anything signed by that "bad actor" Voice service provider. But doing this will require recipients to assess the quality of the Identity headers.
Because of this, the rules about deciding who can attest telephone calls are unresolved. The expectation in the US is that any company with the right to "own telephone numbers" -- i.e., they have an Operating Company Number, OCN -- will have the right to attest telephone calls.
Initially, the expectation is that service providers will Attest calls (i.e., including adding STIR/SHAKEN Identity headers) for telephone numbers directly assigned or ported to them. For example, if your number is ported to Comcast, and you both receive your calls through Comcast, and place your outbound calls through Comcast, then Comcast is in a perfect position to Attest your calls. But if you also need to place outbound called through another carrier, say, CenturyLink, then CenturyLink would not initially be able to Attest your calls. Your calls placed through Comcast may have the "Green Checkbox" of approval, but calls placed through CenturyLink would not. A method called Telephone Number - Proof of Possession, or TN-POP, is under development to accommodate this common and critical type of arrangement.
INVITE sip:+12155551213@tel.example1.net SIP/2.0
Via: SIP/2.0/UDP 10.36.78.177:60012;branch=z9hG4bK-524287-1--- 77ba17085d60f141;rport
Max-Forwards: 69
Contact: <sip:+12155551212@69.241.19.12:50207;rinstance=9da3088f36cc528e>
To: <sip:+12155551213@tel.example1.net>
From: "Alice"<sip:+12155551212@tel.example2.net>;tag=614bdb40
Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI
P-Asserted-Identity: "Alice"<sip:+12155551212@tel.example2.net>,<tel:+12155551212>
CSeq: 2 INVITE
Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO, MESSAGE, OPTIONS Content-Type: application/sdp
Date: Fri, 11 Jan 2019 19:23:38 GMT
Identity: eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwicHB0Ijoic2hha2VuIiwieDV1IjoiaHR0cDovL2NlcnQtYXV0aC5wb2Muc3lzLmNbWNhc3QubmV0L2V4YW1wbGUuY2VydCJ9eyJhdHRlc3QiOiJBIiwiZGVzdC6eyJ0biI6IisxMjE1NTU1MTIxMyJ9LCJpYXQiOiIxNDcxMzc1NDE4Iiwib3JpZyI6eyJ0biI64oCdKzEyMTU1NTUxMjEyIn0sIm9yaWdpZCI6IjEyM2U0NTY3LWU4OWItMTJkMy1hNDU2LTQyNjY1NTQ0MDAwMCJ9._28kAwRWnheXyA6nY4MvmK5JKHZH9hSYkWI4g75mnq9Tj2lW4WPm0PlvudoGaj7wM5XujZUTb_3MA4modoDtCA ;info=<http://cert.example2.net/example.cert>;alg=ES256
Content-Length: 153
v=0
o=- 13103070023943130 1 IN IP4 10.36.78.177
c=IN IP4 10.36.78.177
t=0 0
m=audio 54242 RTP/AVP 0
a=sendrecv
Example courtesy Martin Dolly, AT&T