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 how these responses fit into the INVITE/200/ACK flow itself, start with what SIP is and how a call sets up.

The six response classes

The class — the first digit — carries most of the routing decision. Defined in RFC 3261:

Class	Name	What it tells you
1xx	Provisional	Request received, still being processed. Informational — the call is progressing.
2xx	Success	The request succeeded.
3xx	Redirection	Try a different location for this user.
4xx	Client error	The request failed at this server. Fix the request or try another route — a modified retry can succeed.
5xx	Server error	The server itself failed. The request may be valid; another server may handle it.
6xx	Global failure	The server has definitive information about the user, not just this route. Retrying elsewhere is expected to fail — do not route-advance.

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

Code	RFC meaning	On a trunk, usually
100 Trying	Next hop received the request and is processing; stops INVITE retransmissions	Normal — the carrier acknowledged your INVITE
180 Ringing	The user agent is alerting the user; may trigger local ringback	Normal — far end ringing
183 Session Progress	Call-progress information not otherwise classified; often carries early media SDP	In-band ringback or announcements from the carrier
200 OK	Request succeeded	Call answered; REGISTER or OPTIONS accepted

4xx — request failures

Code	RFC meaning	On a trunk, usually
401 Unauthorized	Request requires authentication (from a UAS or registrar; proxies use 407)	Normal digest-auth challenge — resend with credentials. Repeated 401s mean wrong password
403 Forbidden	Server understood but refuses; authorization will not help, do not repeat	Bad trunk credentials or IP ACL, blocked destination (e.g., international), unfunded account
404 Not Found	User does not exist at the domain in the Request-URI	Invalid or unallocated number; wrong dial plan or number format
408 Request Timeout	Server could not respond in time; client may retry later	Far end unresponsive; a SIP ALG or firewall eating responses; carrier timeout
480 Temporarily Unavailable	Callee contacted but currently unavailable; may carry Retry-After	Unregistered endpoint behind the number; invalid forwarding target; mobile off-network
486 Busy Here	Callee not willing or able to take additional calls at this end system	Genuine busy; all channels or call-appearance slots in use at that endpoint
487 Request Terminated	Request ended by a BYE or CANCEL	Caller hung up before answer — normal in dialer traffic, not an error
488 Not Acceptable Here	Same meaning as 606, but only for this Request-URI; may succeed elsewhere	Codec/SDP mismatch on this hop; SRTP or T.38 negotiation failure
491 Request Pending	UAS had a pending request in the same dialog (glare)	Simultaneous re-INVITEs — hold/transfer races

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

Code	RFC meaning	On a trunk, usually
500 Server Internal Error	Unexpected condition; client may retry after several seconds	Carrier SBC or switch fault; a malformed-but-parseable request tripping the far end
502 Bad Gateway	Gateway or proxy received an invalid response downstream	Broken downstream or PSTN gateway interop
503 Service Unavailable	Temporary overload or maintenance; client should try an alternate server; may carry Retry-After	Carrier congestion or capacity cap, maintenance windows — the expected trigger for failover routing

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

6xx — global failures

Code	RFC meaning	On a trunk, usually
600 Busy Everywhere	Busy at all end systems; sent only when no other endpoint (e.g., voicemail) will answer	Rare on trunks — busy with global knowledge
603 Decline	Callee contacted but explicitly will not or cannot participate; may carry Retry-After	Historically a hard reject or DND. On US networks today: overwhelmingly analytics-based call blocking — check the reason phrase
604 Does Not Exist Anywhere	Authoritative: the user does not exist anywhere	Rare; a definitively bad number
606 Not Acceptable	User’s agent reached, but the session description (media, bandwidth, addressing) is not acceptable anywhere	Global SDP/codec incompatibility — fix the offer, do not re-route

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. 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 SIP 606 Not Acceptable troubleshooting guide.

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. Rising 603s concentrated on specific calling numbers is a caller ID reputation problem, not a signaling problem.

Frequently asked questions

What are SIP response codes?

SIP response codes are three-digit status codes defined in RFC 3261 that a SIP server returns for every request. They are grouped into six classes by first digit: 1xx provisional, 2xx success, 3xx redirection, 4xx client error, 5xx server error, and 6xx global failure. The class tells you where the failure sits and whether a retry makes sense; the individual code narrows down why.

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.

What does SIP 603 mean today?

RFC 3261 defines 603 Decline as the called party explicitly refusing the call. On US networks since March 25, 2026, however, FCC order 25-15 requires providers that block calls based on analytics to signal it with SIP 603 carrying the reason phrase “Network Blocked” and a Reason header — the 603+ variant. So a 603 in your CDRs today is far more likely to be a blocking engine than a human. Check the reason phrase and Reason header to tell the two apart.

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 deep dives above will get you most of the way — and if the problem is your current route, test a SIPNEX trunk against it or compare our published rates.