What is 603+?

603+ is an industry standard that enhances how SIP networks signal blocked or rejected calls based on analytics for suspected unwanted robocalls. It works in the reverse direction of the call path—from the terminating or intermediate network back toward the originating network—providing insight into:

• Why a call was blocked

• Where the blocking occurred

In early implementations, multiple SIP response codes were used (e.g., 607, 608, 603). To simplify adoption and ensure consistency, the industry aligned on:  SIP 603 with a standardized “Network Blocked” reason phrase and enhanced Reason header.

SBCs and proxies must preserve the original SIP 603+ response and Reason header end-to-end. Any normalization, remapping, or rewriting of the response may result in loss of diagnostic information and non-compliance with the standard. From a routing standpoint, a call rejected with a 603+ should not be re-attempted; the response represents a definitive call treatment decision and must be returned to the originating side.

An important clarification is that 603+ applies to explainable (analytics-based) blocking, not deterministic blocking such as Do-Not-Originate (DNO).

How 603+ Differs from Standard SIP 603

A 603+ response is distinguished from a traditional SIP 603 (“Decline”) in two key ways:

1. Status Line Reason Phrase

• Standard SIP 603 → Decline

• 603+ SIP Response → Network Blocked

This provides immediate indication that the rejection is network-driven, not user-driven.

2. Enhanced Reason Header

603+ requires the inclusion of a SIP Reason header (RFC 3326), encoded according to the standard. Any SIP 603 response without valid 603+ Reason header syntax should be treated as a normal 603 response.

Example 603+ Reason headers:

Reason: Q.850;cause=21;text="v=analytics1;url=https://example.com";location=LN

Reason: SIP;cause=603;text="v=analytics1;email=support@example.com";location=RLN

Reason: Q.850;cause=21;text="v=analytics1;url=https://example.com;email=support@example.com;tel=+12155551212;id=29016905-3bed-4c98-9423-03041160cc67";location=LN

The Reason header provides structured context about why a call was blocked, improved transparency, and more effective dispute resolution. Here are some real-world Reason headers we are observing:

1482015742;1439765248-39593900@[masked-ip];"Reason: SIP;cause=603;text=""v=analytics1;url=https://voicespamfeedback.com"";location=RLN";

1482015743;1439766227-39607490@[masked-ip];"Reason: SIP;cause=603;text=""v=analytics1;url=https://www.att.com/redressC;id=att2"";location=RLN";

1482015765;1439767952-39631560@[masked-ip];"Reason: SIP;cause=603;text=""v=analytics1;url=https://www.att.com/redressG;id=att1"";location=RLN";

1482015748;1439766671-39613930@[masked-ip];"Reason: SIP;cause=603;text=""v=analytics1;url=https://www.t-mobile.com/responsibility/consumer-info/additional-info/call-blocking-redress"";location=RLN";

1482015752;1439766977-39618090@[masked-ip];"Reason: SIP;cause=603;text=""v=analytics1;url=https://reportspam.spectrum.com"";location=RLN";

1482015778;1439768720-39641650@[masked-ip];"Reason: SIP;cause=603;text=""v=analytics1;url=https://reportarobocall.com"";location=RLN";

The above shows that the most common context is a website where action can be taken to dispute a rejection. We also see that RLN (i.e. blocking occurred in the network serving the called party) is the most common location of  blocking. 

What Problem Does 603+ Solve?

Historically, when calls were blocked via analytics:

• Terminating or transit networks could reject calls silently

• Transit or originating providers had no visibility into the reason

• Originating providers could not:

  • Dispute incorrect blocking

This would lead to legitimate calls being rejected without explanation, and being handled inconsistently between providers.

The adoption of 603+ standardizes call rejection for suspected unwanted robocalls. Each network in the call path is responsible for preserving the rejection and forwarding it to the upstream. From an Originating Service Provider perspective, the 603+ could be a great thing for identifying, diagnosing and as applicable disputing calls being rejected by analytics engines. We wrote a different article how the 603+ can facilitate the resolution of calls improperly labeled as spam.

When troubleshooting failed calls, providers should inspect the SIP Reason header within a 603+ response to determine the specific cause of blocking.

Real-World Example

Without 603+

1. Call originates from Carrier A

2. Intermediate Carrier B blocks the call

3. Carrier A sees:

   • Call failed

   • No explanation

With 603+

1. Carrier B blocks the call

2. Adds Reason header:

3. Carrier A can:

   • Identify the issue

   • Adjust traffic behavior

   • Work directly with the carrier rejecting the call (or analytics providers)

VSXi Support for 603+

Support for 603+ is available in VSXi 12.3.3.47 and later, with the following enhancements:

Reason Header Handling Improvements

• Reason header will pass through even when SIP Profile's Extraneous Header Hiding setting is enabled.

• Increased character length ensures full 603+ Reason header is preserved and forwarded.

• Optional Reason Header CDR logging. Full Reason header stored in a companion CDR file (.cadr) to facilitate investigation.

The Trusted CA List

The Trusted CA List serves as the anchor of trust for STI (Secure Telephone Identity) certificates. This curated list ensures only verified entities can participate in the STIR/SHAKEN ecosystem.

Key Characteristics

• Strict Approval Process: Only approved Certificate Authorities (STI-CAs) can be included in this list.
• Dynamic Nature: The list is not static but evolves with the deployment of new root certificates or changes in the CA landscape.

Before obtaining an STI certificate, Service Providers must present a Service Provider Code (SPC) token to their STI-CA of choice, proving their eligibility. This ensures only authorized Service Providers are able to obtain a valid certificate to sign their calls. 

The Certificate Revocation List

The Certificate Revocation List (CRL) is a security mechanism that maintains a current list of certificates that are no longer considered trustworthy. Unlike static blacklists, the CRL is a dynamic, carefully managed inventory of compromised or invalidated certificates.

Reasons for Certificate Revocation

Certificates can be revoked for various critical reasons:

• Security Compromise: When there's evidence that a private key has been breached.
• Ecosystem Removal: When a Service Provider is expelled from the STIR/SHAKEN ecosystem.
• Certificate Replacement: Revoking older certificates when new ones are issued to prevent potential misuse.
• Policy Violations: Addressing breaches of established operational guidelines.
• Organizational Changes: Reflecting changes in an organization's structure or operational status.

Revocation Request Process

The revocation process is rigorous and involves multiple stakeholders:

• Revocation requests can be initiated by Service Providers, the Policy Administrator (STI-PA), Certificate Authorities (STI-CA), Governance Administrator (STI-GA), or regulatory bodies.
• Every revocation request undergoes thorough authentication by the STI-PA before being added to the CRL.

How the Revocation and CA List Protect the Network

STIR/SHAKEN Verification Services (STI-VS), typically operated by Terminating Service Providers, play a crucial role in maintaining network security. These services:

• Continuously update the CRL and Trusted CA List.
• Validate STIR/SHAKEN signatures against established criteria.
• Automatically reject calls from revoked certificates.

Consider a Service Provider being suspended from the STIR/SHAKEN ecosystem. With a properly integrated STI-VS, such as Sansay NSS, the network can immediately and automatically reject all traffic associated with that provider's revoked certificates, ensuring swift and comprehensive protection.

Another example are certificates with self-signed signatures or a root certificate outside of the Trusted CA List. While the signature of these calls may appear legit, if the certificate was not issued by an authorized CA, then all of this traffic is to be rejected. 

The Certificate Revocation List and Trusted CA List are more than administrative tools—they are dynamic systems that protect the integrity of the ecosystem. These lists ensure that the STIR/SHAKEN ecosystem remains secure, reliable, and resilient.

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. 

How do I know if I'm compliant?

If you are unsure whether you comply with this order or not, we invite you use our SHAKEN Echo app. Calling our SHAKEN test platform will reveal what OCN and certificate are used to sign your calls. If you see that calls made to our platform have your OCN, you are compliant. To make your tests visit https://test-shaken.sansay.cloud

Implementation Obligations

The implementation obligation applies to all providers that originate calls and have control over the network infrastructure necessary to implement STIR/SHAKEN.

By requiring calls to be signed using the certificate of the provider with the implementation obligation, the STIR/SHAKEN governance model will be able to function as intended by making it easier to identify providers responsible for any authentication information transmitted with a call and facilitating enforcement remedies that may be needed for failures to comply with authentication requirements, including, for example, revocation of a provider’s SPC token by the Secure Telephone Identity Governance Authority (STI-GA).

All Originating Service Providers (obligated to implement STIR/SHAKEN) need to:

1. Obtain a STIR/SHAKEN certificate. To obtain a certificate, a Service Provider must:
   1. Have a current form 499A on file with the FCC;
   2. Have an Operating Company Number (OCN) from NECA
   3. Have certified with the FCC that it has implemented STIR/SHAKEN or complies with the FCC’s Robocall Mitigation Program requirements and is listed in the RMD, or that it has direct access to telephone numbers from the Toll-Free Number Administrator (TFNA).  
   4. Obtain an SPC token.
2. Certify to complete or partial implementation in the FCC Robocall Mitigation Database only if they have obtained an SPC token and STIR/SHAKEN certificate and sign calls with their certificate; and
3. Memorialize and maintain records of any third-party authentication agreement(s) they have entered into, subject to certain limitations.

The FCC describes acceptable implementations including 3rd parties under the following rules:

The provider with the STIR/SHAKEN implementation obligation: (1) makes all attestation level decisions,
consistent with the STIR/SHAKEN technical standards; and (2) ensures that all calls are signed using its
own certificate obtained from a STIR/SHAKEN Certificate Authority—not the certificate of a third party.

Compliance Deadline

The eight order was released on November 22, 2024 and establishes the following deadlines:

• 30 days after publication of this Report and Order in the Federal Register following OMB approval, or 
• 210 days after release of the Order, whichever is later. The Order was released on November 22, 2024.

The tentative compliance deadline is June 20, 2025.

Technical Implementation

The permitted third-party authentication rules offer new STIR/SHAKEN Originating Service Providers participants flexibility to to implement STIR/SHAKEN. A third-party authentication implementation looks like this:

1.  OSP unsigned traffic arrives at Intermediate Provider. OSP has an an agreement with the Intermedia Provider(s) to perform third-party call signing.
2. The Intermediate Provider, on a per-call basis, performs call authentication against the OSP's STI-AS system.  The STI-AS system uses the OSP's STIR/SHAKEN certificate obtained from an STI-CA after SPC token procedures from the STI-PA infrastructure.
3. All traffic sourced by the OSP and routed through the Intermediate Provider is signed with the OSP's certificate following attestation rules defined by the OSP.
4. The Terminating Service Provider (TSP) is performs call verification and despite the Intermedia Provider's efforts to technologically sign the call, sees the OSP in the SHAKEN digital signature as the originator of the call.

Why would a provider want to do 3rd-party call authentication?

While there are benefits to performing in-network call authentication, a provider trying to obtain compliance may want to opt for 3rd party call authentication for any of the following reasons.

1. Technical limitations. The provider's existing infrastructure may not support STIR/SHAKEN yet.
2. Limited resources. There are limited resources available to reach compliance in a timely matter.
3. Cost. 3rd-party call authentication may reduce the cost to implement STIR/SHAKEN.
4. Minimize risks. A provider may want to minimize risks associated with the STIR/SHAKEN implementation.

Whether you are looking at deploying 1st-party (in-network) or third-party call authentication, Sansay's STIR/SHAKEN solution is highly interoperable. We support SIP and REST interfaces and work with a large list of SBCs, PBXs and Switches.