SIP Response Codes: The Complete Guide to 1xx, 2xx, 3xx, 4xx, 5xx, and 6xx

Every SIP call ends in one of about thirty status codes, and the code is the single most reliable signal you have for what actually happened. A call that fails with 486 Busy Here tells you something completely different from one that fails with 503 Service Unavailable, even though the caller hears the same fast-busy tone in both cases. Reading the code is the first thing any voice engineer does when a call doesn’t complete, and the difference between guessing at a fault and finding it is usually just knowing what each code means and what behavior it triggers in the rest of the network.

This article is the reference for every SIP response code you are likely to see in production. We cover the six classes (1xx provisional, 2xx success, 3xx redirection, 4xx client error, 5xx server error, 6xx global failure), the specific codes within each class, the retransmission and retry behavior each one is supposed to trigger, and how a Session Border Controller normalizes response codes between vendors that disagree on which code to send. For the message-by-message context of where these codes appear in a call, the companion piece SIP Call Flow Explained walks through a complete trace; for the protocol fundamentals, SIP Signaling Fundamentals covers the roles, headers, and architecture.

The Six Response Code Classes

SIP response codes follow the same six-class structure as HTTP, defined in RFC 3261. The first digit identifies the class, the remaining two digits identify the specific code within the class. The class is the most important piece because it controls how the rest of the network is expected to react: whether to keep waiting, retry on a different path, give up entirely, or treat the call as completed.

1xx Provisional responses confirm the request is being processed. They are not final, do not end the transaction, and are not acknowledged. The caller’s user agent stops retransmitting the request once a 1xx arrives, but the call is not yet resolved.

2xx Success responses indicate the request succeeded. For an INVITE, 2xx means the call has been answered and an ACK must follow to complete the three-way handshake. 2xx is the only class that establishes a dialog.

3xx Redirection responses direct the caller to try a different URI. The original request did not succeed, but the response carries a Contact header pointing to an alternative location where the call should be retried.

4xx Client Failure responses indicate the request itself had a problem the caller can correct: bad syntax, missing authentication, an endpoint that is busy, a number that does not exist. The request should not be retried unchanged at the same destination.

5xx Server Failure responses indicate the request was syntactically valid but the server could not fulfill it. Unlike 4xx, the same request may succeed against a different server, so 5xx is the class that typically triggers route advance to a secondary path.

6xx Global Failure responses indicate the request cannot be fulfilled by any server, anywhere. A 6xx code stops fork attempts at proxies, terminates parallel hunt groups, and tells the caller not to try alternative routes.

1xx Provisional Responses

Provisional responses keep the SIP transaction alive while the network figures out what to do next. They have no body in most cases, never trigger ACK, and serve mainly to stop retransmission and to inform the caller that something is happening. A call cannot complete on a 1xx alone; a final response (2xx through 6xx) must always follow.

100 Trying is sent by the next SIP hop the moment it accepts the INVITE for processing. It is strictly hop-by-hop, never reaches the caller’s screen as an event, and exists for one reason: to tell the upstream user agent to stop retransmitting the INVITE while the next hop does its work. If you see no 100 Trying in a UDP trace, you are looking at a transport problem before you are looking at a SIP problem.

180 Ringing is the end-to-end provisional response from the destination endpoint indicating that the called party is being alerted. This is the code that causes the caller’s phone to play local ringback. Some carriers and PBXs prefer to generate ringback themselves by sending 183 Session Progress with early media instead, which lets them inject network announcements (number unobtainable, please hold) before the call is even answered.

181 Call Is Being Forwarded is a courtesy provisional indicating that the call has been redirected to a different endpoint. It is rarely used in modern networks because forwarding is usually handled transparently by 3xx redirection or by an SBC rewriting the destination.

182 Queued tells the caller that the destination has accepted the call but placed it in a queue, typically in a contact center where all agents are busy. It is a way to keep the dialog alive without ringing while the caller waits.

183 Session Progress is the most consequential provisional after 100 and 180. It indicates progress and, critically, can carry an SDP body that establishes early media before the call is answered. Carriers use 183 with early media to play announcements, ringback tones, or in-band post-dial delays. Misconfigured early media is a common source of one-way audio complaints because the caller hears the carrier’s announcement but the actual called endpoint never sees a media path until 200 OK.

Reliable provisional responses (PRACK, defined in RFC 3262) extend this class with acknowledgments so that 1xx messages do not get lost on lossy links. PRACK is mandatory for some interconnects (notably Microsoft Teams Direct Routing under certain configurations) and optional elsewhere.

2xx Success Responses

Success responses are short and consequential. A 2xx to an INVITE establishes a dialog, which means routing state must be maintained at every intermediary until the call ends with BYE.

200 OK is the success response for almost every SIP request. To an INVITE, it means the call has been answered and the response body contains the callee’s SDP answer that completes the media negotiation. To a BYE, it confirms the dialog has been torn down. To a CANCEL, it acknowledges the cancellation itself, separately from the 487 Request Terminated that will be sent for the original INVITE. To an OPTIONS, it returns the responder’s supported methods and codecs, which is how SIP keepalive monitoring works.

202 Accepted indicates the request has been accepted for processing but the outcome is not yet known. It is most commonly seen as the response to a REFER request during call transfer: the transferee acknowledges that it will attempt the transfer and will report progress through NOTIFY messages inside the dialog.

The defining behavior of any 2xx response to INVITE is that it must be acknowledged with an ACK, and the ACK is end-to-end. Unlike every other request, the ACK for a 2xx travels in its own transaction and must traverse the same Record-Route path as the original INVITE. Forgetting that Record-Route exists is a common source of “call answers but immediately drops” tickets in trace analysis.

3xx Redirection Responses

Redirection responses tell the caller to try a different URI. The response includes one or more Contact headers naming the new target, and the caller’s user agent (or the intermediary handling redirection on its behalf) is expected to retry the request against those Contacts.

300 Multiple Choices lists several possible destinations and lets the caller pick. It is rare in production because most SIP user agents do not present multiple choices to the user; the call either succeeds against the first Contact or fails.

301 Moved Permanently indicates the called party has a permanent new address and caches should be updated to reflect it. It is uncommon in voice networks but appears in registration scenarios.

302 Moved Temporarily is by far the most useful 3xx in production. The caller should retry the request against the URI in the Contact header for this call only, without caching the new address. Fraud-prevention and STIR/SHAKEN integrations often return 302 to redirect a call from one trunk group to another based on real-time scoring. Least-cost routing systems use 302 to steer a call to a different carrier without the originating endpoint knowing the route has changed.

305 Use Proxy instructs the caller to retry through a specific proxy. It is almost never seen in production carrier networks.

380 Alternative Service suggests the call should be attempted through a different service entirely (for example, a different protocol). It is occasionally used when a SIP endpoint cannot accept a call but knows about a related service that can.

The practical thing to know about 3xx responses is that not every device handles them the same way. A SIP proxy or B2BUA usually consumes the 3xx itself, retries the request on behalf of the caller, and either succeeds with a 200 OK or returns a different failure code to the original caller. A bare user agent without that logic will simply fail the call when it cannot follow the redirect. This is one of the most common reasons calls “work from the SBC but fail from the endpoint” during testing.

4xx Client Failure Responses

The 4xx class covers everything wrong with the request itself. The request will not succeed if retried unchanged against the same destination, but it may succeed if the caller corrects the problem (adds credentials, fixes the URI, changes the method) or chooses a different destination.

Authentication and Authorization

401 Unauthorized is sent by a UAS that requires the caller to authenticate before processing the request. The response carries a WWW-Authenticate header with a realm and a nonce, and the caller is expected to retry the same request with an Authorization header containing the digest. SIP trunking providers and PBXs that require registration challenge new INVITEs with 401.

407 Proxy Authentication Required is the same idea but issued by an intermediate proxy rather than the final endpoint. The challenge appears in a Proxy-Authenticate header and the response goes back as Proxy-Authorization. The most common cause of “registration works but calls fail” is a realm mismatch in the 407 challenge between the SBC and the upstream provider.

403 Forbidden means the caller is identified and authenticated but is not allowed to make this request. Common triggers include calling from an IP that is not on the carrier’s ACL, attempting to dial a number outside the assigned range, or failing STIR/SHAKEN attestation. 403 is final and the caller should not retry without changing something first.

Address and Method Problems

400 Bad Request indicates the request was malformed: a missing required header, a syntactically invalid URI, an unparseable body. Some carriers return 400 when they receive a header they consider non-compliant, which is one of the reasons SIP normalization is a foundational SBC function.

404 Not Found means the destination URI does not exist at the responding server. In production, 404 is overloaded: a real “number does not exist” returns 404, but so does an ACL miss on some platforms, and some fraud-prevention services use 404 to indicate “no fraud detected, route advance to the next path.” On ProSBC, the default behavior of stopping the call on 404 is commonly overridden to “continue call” specifically so that fraud-prevention return codes feed correctly into the route logic.

405 Method Not Allowed indicates the responder does not support the SIP method that was requested. The response includes an Allow header listing the methods that are supported, which is useful for diagnostics. A REGISTER sent to a server that only accepts INVITE will return 405 with Allow listing INVITE, ACK, BYE, and CANCEL.

415 Unsupported Media Type usually means the SDP body offered a codec or media type the responder cannot handle. The response includes an Accept header listing what would be acceptable, which lets the caller try again with a narrower SDP offer.

Timeout and Endpoint State

408 Request Timeout is returned when the network has been holding the request long enough that any sensible response should have come back. It is generated by intermediaries when no downstream response is received within the SIP timer interval (Timer B, typically 32 seconds for UDP), and it tells the caller that the destination was unreachable for some unspecified reason.

410 Gone indicates the destination address used to exist but is permanently no longer in service. Some carriers use it instead of 404 to distinguish “we know this number used to work” from “this number is unknown.”

480 Temporarily Unavailable is sent by the called endpoint when it does not want to take the call right now but the address is otherwise valid. It is the standard response when a no-answer timer expires (the phone rang and rang and rang) and the call is given up before being answered. 480 means the call reached the endpoint and the endpoint rejected it on its own policy, which is different from 408 where the call never got that far.

484 Address Incomplete tells the caller that the dialed number appears to be a partial dial string. The caller should collect more digits and retry. It is largely a legacy of enbloc dialing in TDM-to-SIP gateways.

486 Busy Here is the called endpoint’s “I am on another call” response. The dialog ends immediately and the caller’s user agent typically plays a busy tone. 486 is a single-endpoint code: the called party is busy, but a different endpoint for the same user (a second line, a mobile twin) might still be reachable.

487 Request Terminated is the response to an INVITE that has been canceled before it was answered. It is the SIP-side bookend to a CANCEL request: when Alice hangs up while still hearing ringback, Bob’s side sends a 200 OK to the CANCEL itself and a 487 to the original INVITE. Misreading 487 as a failed call instead of an abandoned call is a common source of incorrect ASR (Answer-Seizure Ratio) metrics in raw CDR analysis.

488 Not Acceptable Here indicates the called endpoint understood the request but cannot accept the session as offered, almost always due to an SDP problem: an incompatible codec list, a media type the endpoint does not support, a port range it cannot use. It is the codec-negotiation failure most often seen between carriers running different default codec orders.

491 Request Pending handles a race condition where both sides of a dialog send a re-INVITE at almost the same moment. The losing side returns 491, waits a short randomized interval, and retries.

5xx Server Failure Responses

The 5xx class is the troubleshooter’s friend: it means the request itself was fine but the responder could not fulfill it, which strongly implies a different server might succeed. Most route advance and failover behavior in production is driven by 5xx codes.

500 Server Internal Error is the generic “something is wrong with me” code. The responder accepted the request but encountered a problem it cannot describe more specifically. Persistent 500 from a single carrier usually points to a software fault on that carrier’s switch.

501 Not Implemented indicates the request method is recognized but the server does not implement it. A REFER sent to a carrier that does not support call transfer will return 501.

502 Bad Gateway means the server received an invalid response from a downstream server. In a chain of SBCs and proxies, 502 from the upstream usually means the downstream returned something that could not be parsed or that violated the contract.

503 Service Unavailable is the workhorse of failover. It tells the caller that the server is temporarily overloaded or under maintenance and that the same request should be retried elsewhere. Most carrier-side rate-limiting returns 503 once a session cap is hit, which is exactly the signal the caller’s SBC needs to advance to a backup trunk.

504 Server Time-out indicates the server did not receive a timely response from a server it was relying on. It is the chained-system equivalent of 408.

505 Version Not Supported indicates the SIP version in the request line is not supported. Effectively a museum piece: SIP 2.0 has been the only deployed version for two decades.

The reason 5xx codes matter for route design is that they almost always justify route advance. A correctly configured SBC should map 5xx responses received from any single carrier into a “try the next route” decision, while 4xx responses generally should not advance (the request itself was rejected, retrying it against a different carrier will rarely succeed). The exception is the overloaded 404 case mentioned earlier.

6xx Global Failure Responses

A 6xx response is the strongest form of “no” in SIP. It tells the caller that the request cannot be fulfilled by any server in any location, so route advance and parallel forking should both stop. In a hunt group or load-balancing setup that would normally try several destinations in sequence, a 6xx received from any one of them terminates the whole hunt.

600 Busy Everywhere means the called user is busy on every endpoint they have registered. Unlike 486 Busy Here, which is per-endpoint, 600 is per-user. A proxy that is forking an INVITE to a desk phone, a mobile twin, and a softphone will stop forking the moment any one of them returns 600.

603 Decline indicates the called party affirmatively rejected the call (pressed the decline button). The caller should not retry. 603 is also commonly used by fraud-prevention services to indicate “this call should be blocked”; in that context, the SBC must terminate the call rather than advance to a backup route. ProSBC’s default of “continue call” on 603 is explicitly overridden in fraud-integrated deployments so that a 603 from the scoring service correctly stops the call dead.

604 Does Not Exist Anywhere tells the caller that the destination address is not in service anywhere on the responding network. It is rare in modern SIP because 404 has effectively eaten its use case.

606 Not Acceptable is the global-failure counterpart to 488 Not Acceptable Here. It indicates that the session described in the request cannot be accepted by any server, often because the codec or session parameters fall completely outside what the responding network supports.

In practice, 6xx responses are rarer than 4xx and 5xx. When you see one, treat it as authoritative: the request will not succeed on any retry path.

Reading Response Codes in a Production Trace

The retransmission and retry behavior tied to each class is what determines how a SIP call actually behaves in production. Memorizing the codes is the easy part; predicting how the rest of the network reacts to each one is the harder skill, and it is the difference between troubleshooting and guessing.

On UDP transport, the caller’s user agent retransmits the INVITE on an exponential backoff (Timer A, starting at 500ms) until a provisional or final response arrives. The 100 Trying that the next hop sends back is what stops the retransmission. If you see the same INVITE seven times in a trace with no response, you are looking at a transport reachability problem, not a SIP problem; the next hop is not even processing the request. TCP and TLS transport do not retransmit because the transport layer handles delivery, so a stuck call on TCP looks completely different in a trace from a stuck call on UDP.

Final responses to an INVITE always require ACK. The shape of the ACK depends on the response: an ACK for a 2xx is end-to-end and goes in its own transaction, while an ACK for a 3xx through 6xx is hop-by-hop and is part of the original INVITE transaction. A missing ACK after 200 OK is the single most common reason for “the call answers but drops after a few seconds” symptoms, because the called endpoint will tear down the dialog when its retransmissions of the 200 OK go unacknowledged.

Provisional responses never require ACK. A 1xx that goes unanswered does nothing harmful by itself, but a 1xx that is followed by silence (no final response, no further provisionals) is a strong signal that something downstream has stopped processing. PRACK is the exception in environments that enable it: a reliable 1xx (a 1xx with a Require: 100rel header) does need to be acknowledged with PRACK.

The interplay between 4xx and 5xx determines route advance. A well-designed SBC routing script treats 5xx as “try the next route,” treats most 4xx as “stop, this call cannot succeed,” and applies per-code overrides for the messy real-world cases (404 used as fraud-clearance, 503 used as capacity rejection from a healthy carrier, 603 used to block a fraudulent call). Getting these overrides right is what makes the difference between a deployment with 5% failed-but-retryable calls and one with 0.1%.

How an SBC Normalizes Response Codes Between Dialects

Every carrier and every PBX vendor returns slightly different response codes for the same underlying condition. One carrier sends 503 when a session cap is hit; another sends 486. One PBX returns 480 when a user is logged out; another returns 404. The endpoints downstream of these inconsistencies are usually not smart enough to treat them as equivalent, so calls fail that should have advanced, and calls that should have stopped instead advance and rack up minutes against fraudulent destinations.

This is the part of SIP interoperability where an SBC earns its keep. A B2BUA SBC like ProSBC sees the response on the inbound leg and generates a fresh response on the outbound leg, which means it can rewrite the code, change which routing decision it triggers, and add or strip Reason headers as needed. The Reason Cause Mapping feature lets each NAP (trunk group) override the default per-code behavior: 404 can be set to “continue call” so that a fraud-scoring service’s clear response advances to the next route; 603 can be set to “stop call” so that the same scoring service’s block response actually stops it; 302 can be set to “process call routing” so that a redirection from least-cost-routing is consumed by the SBC rather than forwarded upstream; 503 can be set to “continue call” on a healthy primary so that a capacity rejection fails over cleanly.

The same mechanism handles vendor-dialect translation in the simpler direction. A downstream 503 Service Unavailable can be translated to a 486 Busy Here upstream when the upstream system handles 486 better. A 488 Not Acceptable Here can be normalized to a 415 Unsupported Media Type when an older PBX expects 415. A vendor-proprietary X-header carrying additional cause information can be stripped, or, the inverse, a Reason header with a Q.850 cause value can be injected when bridging from a TDM gateway so that the upstream SIP carrier sees the full PSTN failure context.

This same control over response codes is what makes SIP header manipulation and B2BUA architecture the right answer for multi-vendor interconnects, Microsoft Teams Direct Routing, and any environment where three or more carriers, two or more PBX vendors, and a UCaaS platform all need to peer through the same edge.

Quick Troubleshooting Reference

The codes in the wild that you will see most often, what they actually mean in production, and the first thing to check when each one appears:

401 / 407 (authentication challenge) means the request needs credentials. If retry with the credentials still fails, check that the realm in the challenge matches what the caller is configured to authenticate against, and that the SIP digest algorithm (MD5 or SHA-256) is supported on both sides.

403 Forbidden after authentication means an ACL or policy is blocking the call. Check the source IP against the ACL on the responder, and check STIR/SHAKEN attestation if the carrier enforces minimum attestation levels.

404 Not Found means either the number does not exist or the responder is using 404 as a “no match” signal. Confirm the number is provisioned and, if the responder is a fraud-scoring service, that 404 is mapped to “continue call” in the SBC.

408 Request Timeout means nothing downstream answered. Check transport reachability first (is UDP/5060 actually open?) before assuming a SIP-level problem.

480 Temporarily Unavailable means the endpoint exists and is refusing the call right now. Check the no-answer timer, do-not-disturb state, or registration status of the destination.

486 Busy Here means the called endpoint is on another call. If 486 appears at scale on a single trunk, suspect that session caps are being hit and the carrier is returning 486 instead of the more accurate 503.

487 Request Terminated is not a failure: it is the bookend to a CANCEL. Filter 487 out of failure metrics; report it under abandoned calls instead.

488 Not Acceptable Here is a codec or SDP problem. Compare the offered codec list to the responder’s supported codecs, and check whether the SBC is forcing a codec the downstream does not support.

503 Service Unavailable at the edge of a trunk almost always means the carrier is overloaded or rate-limiting. Confirm the SBC’s route advance behavior is configured to fail over on 503; if it is not, this is your first fix.

603 Decline from a fraud-scoring service is a block decision. Confirm that the SBC’s Reason Cause Mapping for 603 is set to “stop call” on that NAP so the block actually terminates the call.

Conclusion

SIP response codes are a small, structured vocabulary that carries almost every signal a voice engineer needs to read a call. Six classes, fewer than thirty codes in regular production use, and a consistent set of rules about which codes trigger retransmission, which require ACK, which justify route advance, and which terminate the call dead. The codes themselves are stable; what varies between deployments is which exact code each vendor returns for which underlying condition, and that variance is precisely where an SBC’s response-code mapping does the work of making a multi-vendor network behave like a single coherent system.

For voice engineers building SIP trunking interconnects, deploying Teams Direct Routing, or troubleshooting failed calls in a multi-carrier environment, fluency in these codes (what each one means, what behavior it triggers, when a carrier is using it idiomatically) is the foundation everything else builds on. The companion SIP call flow walkthrough shows the codes in the context of a complete trace; this article is the dictionary you keep open next to it.