SIP Code 603 Declined — Now 'Network Blocked'

SIP code 603 is the Decline response: the called party was reached and explicitly refused the call. That was the RFC 3261 meaning. Today, on US networks, a 603 in your logs is far more likely to be something else entirely — since March 25, 2026, per FCC order 25-15, a carrier that blocks your call based on analytics must return SIP 603 with the reason phrase “Network Blocked” plus a Reason header, a variant the industry calls 603+. If code 603 is climbing in your CDRs, the question is no longer “who declined?” — it is “which network blocked this call, and what does the Reason header say?”

Below: the RFC 3261 meaning that still applies to genuine declines, the FCC standard that changed the code’s job in 2026, how to read a 603+ Reason header, and the redress path that gets blocked traffic flowing again. For the full class-by-class breakdown of every code a trunk operator actually sees, start with the SIP response codes guide.

Then: 603 meant a human said no

In RFC 3261, 603 Decline belongs to the 6xx class — global failures, where the server has definitive information about the user, not just one route to them. The RFC’s definition: the callee’s machine was successfully contacted, but the user explicitly does not wish to or cannot participate, and the response is returned only when the client knows no other endpoint will answer. The response may even carry a Retry-After header suggesting a better time to call.

Two design details from that definition still matter operationally:

• 6xx means stop. A 6xx is not “this route failed” — it is “this user is unreachable for this request, everywhere.” Retrying another route for the same number is expected to fail, which is why well-behaved carriers do not route-advance on it.
• 603 was the privacy-preserving reject. RFC 3261 notes that a callee who does not wish to reveal the reason for declining uses 603 instead of 600 Busy Everywhere. It was the deliberate, no-explanation “no” — a hard reject or DND at the far end.

For years, that is how trunk operators read it: a human (or their device) pressed decline. Then robocall enforcement repurposed the code.

Now: 603 “Network Blocked” means analytics blocking

US carriers run analytics engines that score inbound traffic and block calls that look like illegal robocalls. The FCC requires that blocked callers be told — immediately and in-band — so legitimate callers can seek redress when the analytics get it wrong. The signaling for that notification has moved around: the FCC’s 2020 Call Blocking Order required SIP 607 or 608 (with ISUP cause 21 on TDM legs), a 2021 reconsideration temporarily allowed plain 603, and industry standards work at ATIS and the SIP Forum then produced a purpose-built variant — SIP 603+, defined in ATIS-1000099, adopted in August 2022.

FCC order 25-15 (the Eighth Report and Order in CG Docket 17-59, adopted February 27, 2025) settled it: terminating providers that block calls based on reasonable analytics must use SIP 603+ exclusively for that notification on IP networks, effective March 25, 2026. Providers were directed to stop using the standard version of 603 — and 607 and 608 — for this purpose. The FCC chose 603+ over 608 in part because the record showed it delivers the information more quickly and likely at lower cost.

What makes a 603 a 603+ on the wire:

• The status line reason phrase is “Network Blocked” instead of RFC 3261’s “Decline.” That phrase is how you distinguish an analytics block from an ordinary decline at a glance.
• A Reason header is attached carrying machine-readable details about the block — covered in the next section.

Scope matters: the 603+ mandate applies to analytics-based blocking. Blocking from a do-not-originate list, blocking ordered by FCC notification, and blocking a customer requested without analytics are not covered by this requirement. And a plain 603 with the “Decline” reason phrase can still be a genuine decline — the far end refusing the call the old-fashioned way.

Anatomy of a 603+ Reason header

The Reason header is the redress mechanism. Under ATIS-1000099, it carries a cause — either Q.850;cause=21 or SIP;cause=603 — plus a quoted text field and a location tag. Two real-world shapes:

Reason: SIP;cause=603;text="v=analytics1;url=https://example.com;id=12345";location=LN
Reason: Q.850;cause=21;text="v=analytics1;email=redress@provider.com;id=e0c1913c-...";location=LN

Reading it:

• v=analytics1 — a version tag identifying the notification format.
• url= / email= / tel= — at least one redress contact for the blocking party. This is the address you use to dispute the block.
• id= — an optional unique event ID for the specific blocking event. Capture it: quoting the event ID in your redress request lets the blocking provider find the exact decision.
• location= — a tag identifying where in the call path the block occurred.

Intermediate carriers are expected to pass 603+ through untouched — no code remapping, no retries or route-advance, transparent header passing — so the Reason header your switch logs should be the one the blocking network generated. If your platform truncates or discards Reason headers in CDRs, fix that first; without the header, a 603+ tells you only that you were blocked, not by whom or how to dispute it.

On non-IP legs, there is no Reason header to carry. The FCC kept ISUP cause code 21 (“call rejected”) as the correct notification for TDM paths, with cause location “user” — consistent with RFC 3398, which maps SIP 603 to ISUP cause 21 and back. Providers on mixed TDM/IP paths must return the appropriately mapped code, so a call that transits legacy segments can still surface the block as cause 21 rather than a full 603+.

The fix path when 603+ shows up in your CDRs

A 603+ is not noise — it is a named blocking event with a built-in dispute channel. The working sequence:

1. Do not auto-retry. 603 is a 6xx global failure; retrying the same call over another route wastes attempts and makes your traffic pattern look worse to the same analytics engines. Configure your dialer to treat 603/603+ as terminal for that attempt.
2. Segment your CDRs by calling number. Track 603+ per outbound number, not just in aggregate. Numbers that repeatedly draw 603+ need investigation, rest, or replacement — a per-number view separates a reputation problem on two DIDs from a trunk-wide issue.
3. File redress with the blocking provider. Use the contact in the Reason header and include the event ID. This channel has teeth: FCC rules require blocking providers to maintain a dispute point of contact and to provide a status update on disputes within 24 hours. That redress path is the entire reason 603+ exists.
4. Check and manage caller-ID reputation. The analytics engines feeding carrier blocking decisions also feed spam labels, and the remediation overlaps: register your outbound numbers with the analytics providers and monitor how they score. Our caller-ID reputation management guide covers the registration and monitoring workflow.
5. Verify how your calls are signed. Analytics engines consider STIR/SHAKEN signing and attestation among many signals when scoring traffic. It is not a guarantee against blocking, but unsigned or gateway-attested traffic gives the engines less to trust — the difference is laid out in A-level vs. B-level attestation.
6. Audit your upstream carrier’s standing. Providers must be registered in the Robocall Mitigation Database for downstream carriers to accept their traffic, and the FCC has been actively removing providers with deficient filings. If your carrier’s standing is shaky, your traffic inherits the suspicion — here is how the Robocall Mitigation Database works.

If instead your failures are 606 or 488 — the far end objecting to your SDP rather than your identity — that is a media negotiation problem, not a blocking problem: see SIP code 606 Not Acceptable.

603 vs. 600, 604, 607, and 608

The neighboring codes sharpen what 603 does and does not mean:

• 600 Busy Everywhere — busy at every endpoint, with global knowledge. A callee who will not say why uses 603 instead.
• 604 Does Not Exist Anywhere — authoritative “this user does not exist.” Definitive bad number, unrelated to blocking.
• 607 Unwanted (RFC 8197) — a human at the target device flagged the call as unwanted. Person-initiated, not analytics-initiated.
• 608 Rejected (RFC 8688) — an intermediary, typically an analytics engine, rejected the call. This was the purpose-built analytics rejection code, and it lost: after March 25, 2026, neither plain 603, 607, nor 608 may be used for analytics-blocking notification in the US. 603+ carries that job alone.

Frequently asked questions

SIPNEX is an FCC-licensed carrier with its own STIR/SHAKEN SP certificate — outbound calls on your DIDs are signed directly with A-level attestation, and we are registered in the Robocall Mitigation Database. If your current provider’s traffic keeps drawing “Network Blocked,” start with the signing chain: how STIR/SHAKEN works, then talk to us about moving your trunks.