SIP Response Codes: The Operator's Reference

SIP response codes are the three-digit status codes a SIP server returns for every request, grouped into six classes: 1xx provisional, 2xx success, 3xx redirection, 4xx client error, 5xx server error, and 6xx global failure. The first digit tells you who failed and whether retrying makes sense; the specific code tells you why. The tables below cover every code you will realistically see in production — what the RFC actually says each one means, and what it usually means when your carrier sends it. For the INVITE-to-answer call flow these responses belong to, start with how SIP trunking works.

The six response classes

The class — the first digit — carries most of the routing decision. The classes are defined in RFC 3261 §21:

The 4xx/6xx distinction is the one that matters for dialer and failover logic: a 4xx failed here, a 6xx failed everywhere.

The codes you will actually see on a trunk

RFC 3261 defines dozens of codes. These are the ones that show up in real trunk CDRs and SIP traces, with the RFC meaning and the usual trunk-context cause.

Call progress and success

4xx — request failures

Less common but legitimate: 405 Method Not Allowed, 407 Proxy Authentication Required (the proxy-side twin of 401), 410 Gone, and 484 Address Incomplete (short-dialed or overlap-dialed numbers).

5xx — server failures

501 Not Implemented and 504 Server Time-out round out the class.

6xx — global failures

Because 6xx is a global failure, route-advancing on any of these wastes attempts and looks like redial abuse to analytics engines. Fail the call and diagnose.

Two codes that changed, and where to go deeper

603 no longer means what RFC 3261 says it means. Since March 25, 2026, per FCC order 25-15, the required notification when a US provider blocks a call based on analytics is SIP 603 with the reason phrase “Network Blocked” plus a Reason header — the variant known as 603+. Plain 603, 607, and 608 may no longer be used for that purpose, apart from one TDM interworking case. If your outbound traffic is drawing 603s, the reason phrase and Reason header tell you whether a human declined or a blocking engine did — and the header carries a redress contact. Full breakdown, including what to do about it, in our guide to SIP 603, 603+, and analytics blocking.

606 is the “fix your SDP” code. It shares its meaning with 488 — the offered media was not acceptable — but the scope differs: 488 says this hop cannot take the offer and the call may succeed elsewhere; 606 says no endpoint for this user will accept it. Codec lists, media types, and negotiation fixes are covered in the next section.

606 and 488: fixing a rejected media offer

Both codes mean the far end was reached but could not accept the session your SDP described. RFC 3261 §21.6.4 names the requested media, bandwidth, or addressing style as the parts that can fail. The difference is scope, and scope decides whether failover is worth anything: a 488 may succeed on another route, and a 606 will not. 406 Not Acceptable is unrelated despite the name; it concerns the Accept header, not the SDP.

Two optional parts of the response do most of the diagnosis. A 606 or 488 MAY carry a Warning header, and RFC 3261 defines warning codes for this case: 304 (media type not available), 305 (incompatible media format), and 306 (attribute not understood). The response MAY also carry a body describing the media the far end does support, as application/sdp by default. When that body is present, offer only what appears in both.

Work the causes in this order:

• Codec mismatch. Your offered codecs and the far end’s have no overlap, such as a G.729-only offer to a G.711-only endpoint. Align the lists, or transcode at your PBX or SBC.
• Media-type mismatch. A video or T.38 m= line offered to an audio-only endpoint. Remove the unsupported stream from the offer.
• Bandwidth or addressing. A b= limit the far end cannot honor, or a c= media address it cannot reach. Remove the constraint or correct the address your system advertises.
• Encryption mismatch. An offer that requires SRTP sent to an endpoint that only does plain RTP, or the reverse.

If one destination rejects you, look at that endpoint. If every call on a trunk draws 488 or 606, look at your own codec and media settings first. Change one thing at a time, and test with a single call before restoring traffic.

How Asterisk turns these codes into hangup causes

Asterisk translates a received SIP failure into a Q.850 hangup cause, the number you see in ${HANGUPCAUSE}. In the Asterisk source, chan_sip (hangup_sip2cause, checked in the 20 branch) and PJSIP (ast_sip_hangup_sip2cause, checked in the current tree) map the codes below identically.

Asterisk’s list also covers rarer codes, such as 410 Gone (NUMBER_CHANGED, 22); the last two rows apply only to codes it does not name.

The table explains a common CDR trap. A 403 from your carrier and a 603+ from a blocking engine both land as cause 21, so the hangup cause alone cannot tell an authentication problem from analytics blocking. Neither can it separate a hop-level 488 from a global 606. Keep SIP traces, or log the SIP response code itself, whenever the distinction matters.

How to triage an unfamiliar response

1. Read the class first. 4xx: fix the request or try another route. 5xx: the far-end server broke; failover is reasonable, especially on 503. 6xx: definitive — stop retrying.
2. Read the reason phrase and headers. A 603 with “Network Blocked” is analytics blocking, not a decline. A 606 or 488 may carry a Warning header naming the unacceptable media attribute. 480, 486, 500, and 503 may carry Retry-After.
3. Confirm who sent it. A response generated by your own SBC or a mid-path proxy points at different fixes than one from the terminating carrier. The Via stack in the trace tells you.
4. Correlate across calls. One 503 is noise; a burst of 503s on one route is a capacity event — the SIP 503 deep dive walks the full cause ladder, and SIP 403 has its own. Rising 603s concentrated on specific calling numbers is a caller ID reputation problem, not a signaling problem.

Frequently asked questions

What is the difference between a 4xx and a 6xx failure?

Scope. A 4xx means the request failed at the specific server that answered — a modified request or a different route can still succeed. A 6xx means the server has definitive information about the user: no route to that user will succeed, so route-advancing is pointless. That is why 488 (this hop cannot accept your media) and 606 (no endpoint anywhere will) are separate codes with the same underlying reason.

Should my dialer retry on a 5xx response?

Cautiously. RFC 3261 allows a retry after several seconds on a 500, and 503 explicitly invites trying an alternate server — 503 is the standard trigger for failover routing, and it may carry a Retry-After header telling you how long to wait. What you should not do is hammer the same route immediately, and you should never auto-retry a 6xx response at all: it is a global failure, and repeated attempts read as redial abuse.

Why do I see 487 in my CDRs so often?

Because 487 Request Terminated is not an error. It is returned when a request ends via CANCEL or BYE before answer — in practice, the caller (or the dialer) abandoned the attempt while the far end was still ringing. In outbound dialer traffic a healthy share of 487s is normal. Treat a sudden change in the 487 rate as a signal about pacing or answer timing, not as a trunk fault.

---

Every code in this reference shows up in the real-time CDRs on SIPNEX SIP trunks — we are an FCC-licensed carrier, so the responses you reconcile are the responses we log. If you are staring at a trace full of 603s or 606s, the sections above will get you most of the way — and if the problem is your current route, test a SIPNEX trunk against it.