March 2026: Understanding the new 603+ standard

The new Robocall Call Notification standard (ATIS-1000099), commonly referred to as 603+, introduces a consistent way for networks to communicate why a suspected unwanted robocall was blocked. Unlike traditional SIP responses, which often provide little to no context, 603+ enables call treatment transparency by carrying meaningful information back toward the originating party.

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.

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. 

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 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 to facilitate investigation.