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 in §21.6.2 opens: “The callee’s machine was successfully contacted but the user explicitly does not wish to or cannot participate.” The same section says the response is returned only when the client knows no other endpoint will answer, and it may 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’s definition of 600 Busy Everywhere says a callee who would rather not give a reason for refusing uses 603 instead. 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 December 2020 call blocking order required SIP 607 or 608 (with ISUP cause 21 on TDM legs), and a 2021 order on reconsideration temporarily allowed plain 603. Standards work at ATIS and the SIP Forum then produced a purpose-built variant: SIP 603+, defined in ATIS-1000099 and adopted on August 16, 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 using reasonable analytics must use SIP 603+ exclusively for that notification on IP networks. The order was published in the Federal Register on March 24, 2025, and the rule took effect 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, as the order puts it (¶17), the record shows 603+ “will provide more information to providers more quickly than SIP code 608, and likely at lower cost to providers.”

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. The order (¶15) excludes blocking from a do-not-originate list, blocking ordered by FCC notification, and blocking a customer requested without analytics. 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 §4.1.1, it carries exactly one cause, either Q.850;cause=21 or SIP;cause=603, plus a quoted text field and a location parameter. Two illustrative examples that follow the ATIS-1000099 format (the example.com values are placeholders):

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@example.com;id=blk-0001";location=RLN

Reading it:

• v=analytics1 — a version tag identifying the notification format.
• url= / email= / tel= — at least one redress contact for the blocking party: an HTTPS URL, an email address, or an E.164 phone number. This is the address you use to dispute the block.
• id= — an optional identifier the blocking provider adds to help with redress, such as a call ID or a blocking-reason ID. Capture it: quoting it in your redress request helps the blocking provider find the decision.
• location= — a tag identifying where in the call path the block occurred. RLN is the network serving the called party, TN a transit network, and LN the originating network; RPN and LPN mark private networks.

ATIS-1000099 (§4.1.3) requires a transit network to forward a 603+ transparently: no change to the response code, no edits beyond the headers used to forward it, and no retry. FCC 25-15 (¶21) adds that any IP provider receiving a 603+ must pass on “the full header, including all mandatory text fields.” 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 rule, 47 CFR 64.1200(k)(9), keeps ISUP cause 21 (“call rejected”) with cause location “user” as the notification on TDM networks. A 603+ crossing into TDM must map to cause 21. Coming back the other way, a cause 21 whose location is “user” must map to SIP 603 or 603+. That rule matters because RFC 3398, the ISUP-to-SIP mapping standard, turns SIP 603 into cause 21 but maps cause 21 back to 403 Forbidden.

Cause 21 also carries no redress text. So a block that crossed a TDM segment can reach you as a plain 603, and FCC 25-15 (¶24) still allows that when a provider receives cause 21 and cannot tell whether the block was analytics-based.

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 id= value if there is one. This channel has teeth: 47 CFR 64.1200(k)(8) requires blocking providers to publish a single point of contact for blocking-error complaints and to give 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 Potential Spam label playbook 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 Enforcement Bureau removed providers with deficient filings in August 2025 orders (DA 25-694, DA 25-737). 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 how to fix a rejected media offer.

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, apart from the plain 603 a cause-21 TDM leg can produce. 603+ carries that job.

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.