February 2025: STIR/SHAKEN and Anonymous Calls

STIR/SHAKEN has revolutionized caller authentication in phone networks, introducing much-needed transparency and accountability to combat fraud and illegal calls. However, it is not uncommon for an Originating Service Provider (OSP) to have issues supporting legitimate calls that request privacy. These anonymous calls may be marked as potential spam or even blocked by some Terminating Service Providers (TSP). 

This article has the objective of defining where the disconnect exists and how to solve the issue.

Understanding SIP and Privacy

To understand the issues with STIR/SHAKEN implementations and privacy calls it is important to go over the established mechanisms and standards for privacy calling within SIP. Most problems with anonymous calling start with a From header liks this:

From: “Anonymous” <sip:Anonymous@annoymous.invalid>; tag=12345

While the above header is valid, it is the underlying use, or lack thereof, of SIP headers as defined by RFC3323 and RFC3325 that will determine the effective use of privacy in a STIR/SHAKEN enabled network. Let's dive further:

The role of the P-Asserted-Identity header

As it names suggests, the P-Asserted-Identity (P is for Private) header (short for PAI) is a mechanism to assert the identity of a user originating a call. The PAI header provides a network-verified and network-asserted identity of the user making a call.

When a user requests Privacy, the user agent client INVITE carries an anonymous From header and can optionally add a P-Preferred-Identity header. The network elements can apply specific treatment to the P-Preferred-Identity header and strip it before it leaves the network having asserted the caller with the insertion of the P-Asserted-Identity header. To properly request privacy a UAC should also include the Privacy: id header.

A call requesting privacy from the user client arrives like:

INVITE sip:+14085551212@network.example SIP/2.0
   Via: SIP/2.0/TCP useragent.network.example;branch=z9hG4bK-124
   To: <sip:+14085551212@network.example>
   From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
   Call-ID: 245780247857024504
   CSeq: 2 INVITE
   Max-Forwards: 70
   Privacy: id

A call processed by core network elements is enhanced with a PAI like this:

INVITE sip:+14085551212@proxy.pstn.net SIP/2.0
   Via: SIP/2.0/TCP useragent.network.example;branch=z9hG4bK-124
   To: <sip:+14085551212@network.example>
   From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=9802748
   Call-ID: 245780247857024504
   CSeq: 2 INVITE
   Max-Forwards: 69
   P-Asserted-Identity: <sip:+19995551234@network.example>
   Privacy: id

While RFC3325 became a standard in 2003, to this date it is not uncommon to see INVITEs with a Remote-Party-ID SIP header (RPID). The RPID header is an older proprietary header used to convey the caller's identity in a network, almost identical to the issue the P-Asserted-Identity resolves and standardized. RPID never became a standard and any modern network should replace RPID with PAI; this is a function network elements like an SBC support. Additionally, the exclusive use of an anonymous From header without a corresponding PAI will not yield the desired outcome.

One more thing is that RFC3325 suggests, it is recommended the the P-Asserted-Identity header fields SHOULT NOT be removed unless local private policies prevent it. Removal of the PAI may cause services based on Asserted Identity to fail.  This last part connects the dots with the STIR and ATIS standards we will explain shortly.

Privacy and SHAKEN

While the P-Asserted-Identity header allows a network to assert caller identity for its users, it lacks the security of cryptographic digital signatures, such as those introduced in a SHAKEN PASSPorT.  A SHAKEN PASSPorT contains the originating telephone number (orig TN) as one of different elements to validate the integrity of a call.

As defined in ATIS-1000074 and RFC 8224 (which defines interactions between privacy and STIR standards) The CSCF of the originating service provider (i.e., Service Provider A) adds a P-Asserted-Identity header field asserting the Caller ID of the originating SIP UA. The CSCF then initiates an originating trigger to the STI-AS for the INVITE.  This helps clarify the weight of the P-Asserted-Identity over a From when it is present.

The P-Asserted-Identity created by trusted network elements, unlike a From header, holds a definitive identity for the originator. Furthermore, as defined in RFC 8224, the syntax or ABNF for telephone number fields within a SHAKEN PASSPorT is of the form:

RFC 8224                      SIP Identity                 February 2018
             tn-spec =  1*tn-char
             tn-char = "#" / "*" / DIGIT

which means a alpha user such as anonymous, restricted or blocked fall outside the spec. While we have not mentioned it yet, a P-Asserted-Identity will contain a valid user telephone number and in the case of private calls, request privacy through the Privacy: id header. This makes the PAI ideal to meet the requirements of the telephone number claims in a SHAKEN PASSPorT. While STIR/SHAKEN does not changes the nature of privacy, the use of P-Asserted-Identity and Privacy:id as opposed to other mechanisms to request privacy are essential to making calls with privacy work.

Closing the Gap

As a Service Provider, it is important to understand how 1) privacy calls are handled in your network prior to call signing (STI-AS) and 2) how calls requesting privacy leave your network. 

A best common practice is to follow the rules defined in RFC 3325 in conjunction with RFC 8224 and ATIS 1000074. 

Do you need to verify how private calls are made from your network and how they are verified from a STIR/SHAKEN perspective? Give our SHAKEN Echo Number a try: https://test-shaken.sansay.cloud.