SIP Response Codes: A Practical Reference

SIP Signaling From the Wire Up: Part 7 of 12

SIP response codes follow the same pattern as HTTP: a three digit number where the first digit tells you the general category and the specific number tells you what happened. If you've ever seen a 404 error on a website, you already have the intuition for how this works.

The full SIP specification defines dozens of response codes, but in real world VoIP troubleshooting, you'll encounter a relatively small subset of them repeatedly. This post focuses on those, the codes that actually show up when you're reading a trace and trying to figure out why a call failed, why registration broke, or why a transfer didn't go through. Think of it as a field reference rather than a comprehensive catalog.

1xx: Provisional Responses

Provisional responses are informational. They tell the sender that the request was received and is being processed, but the final outcome hasn't been determined yet.

100 Trying

The proxy or server received the request and is working on it. This is a hop by hop response, meaning each proxy in the chain sends its own 100 Trying back to the previous hop. Its main purpose is to stop retransmissions. When SIP runs over UDP, the sender will keep resending the request until it gets some kind of response. A 100 Trying says "I got it, stop resending."

If you're looking at a trace and you see the caller sending multiple identical INVITEs with no 100 Trying in between, the initial INVITE isn't reaching the first proxy, or the 100 Trying isn't making it back. That's usually a firewall or routing issue.

180 Ringing

The callee's phone is ringing. When the caller's phone receives this, it plays a ringback tone. In a normal call, you'll see 180 Ringing after 100 Trying and before 200 OK.

If you see the INVITE reach the callee's phone (you can verify by capturing at both ends) but no 180 comes back, the callee's phone received the INVITE but isn't generating a ringing response. This could be a configuration issue on the phone, or the phone could be rejecting the call silently.

183 Session Progress

This one is important and often misunderstood. A 183 response typically includes an SDP body and signals that "early media" is available. Early media is audio that plays before the call is fully answered. The most common use case is ringback tones generated by the far end network rather than by the caller's phone, or IVR prompts that play before the call is picked up by a human.

When a caller hears a recorded message like "Please hold while we transfer your call" before anyone has technically answered, that audio is early media signaled by a 183 response.

In the trace, a 183 with SDP means the caller should start sending and receiving RTP even though the call hasn't been answered yet. If you see a 183 but the caller isn't hearing the early media, check whether the caller's phone or proxy supports early media, and whether the RTP path is working (same NAT and firewall considerations as with established calls).

2xx: Success

200 OK

The request succeeded. The meaning depends on what was requested. A 200 OK to an INVITE means the call was answered. A 200 OK to a REGISTER means registration was accepted. A 200 OK to a BYE means the hangup was acknowledged. A 200 OK to a CANCEL means the cancellation was received.

In INVITE transactions, the 200 OK typically carries an SDP answer body. If you're troubleshooting a call that connects but has no audio, the SDP in the 200 OK is one of the first things to check.

3xx: Redirection

301 Moved Permanently

The address being called has permanently moved to a different address. The response includes a Contact header with the new address. The caller's system should update its records and send the INVITE to the new location. This is sometimes used to implement permanent call forwarding.

302 Moved Temporarily

Same concept as 301, but the move is temporary. The caller should try the new address for this call but shouldn't update permanent records. Used for temporary call forwarding and some load balancing implementations.

In practice, not all SIP devices handle 3xx redirects correctly. Some older phones or PBX systems ignore them entirely. If you see a 302 in a trace and the call isn't being forwarded as expected, check whether the device receiving the 302 supports redirect handling.

4xx: Client Errors

This is the category you'll spend the most time in when troubleshooting. A 4xx response means the request itself had a problem.

400 Bad Request

The request was malformed in some way that the server can't process it. This is a catch all for syntax errors, missing required headers, or other problems with the message structure. The Reason phrase or a Warning header might give more detail about what specifically was wrong. SIP ALG mangling messages can produce 400 errors because the rewritten message ends up structurally invalid.

401 Unauthorized

Authentication is required and wasn't provided, or the provided credentials were incorrect. This is the standard challenge response used in SIP registration. The first REGISTER without credentials gets a 401 with a WWW-Authenticate header. The client should retry with credentials. If you see a 401, followed by an authenticated request, followed by another 401, the credentials are wrong. The phone will keep trying and keep failing, which you'll see as a repeating pattern in the trace.

403 Forbidden

The server understood the request and the credentials (if provided) but is refusing to fulfill it. This is different from 401. A 401 says "authenticate yourself." A 403 says "I know who you are, and the answer is no." Common causes include IP based access restrictions, calling permissions that don't allow the dialed number, or an administrative block on the account.

404 Not Found

The address in the Request-URI doesn't exist. Nobody is registered at that address, and the server doesn't know how to route to it. If you dial an extension that doesn't exist on the PBX, you'll get a 404. If a SIP trunk receives a call for a number that isn't configured in the routing table, you might get a 404.

407 Proxy Authentication Required

Identical in concept to 401, but it comes from a proxy rather than the endpoint server. The challenge header is Proxy-Authenticate instead of WWW-Authenticate, and the client should include a Proxy-Authorization header in the retry. Functionally, the troubleshooting approach is the same as for 401.

408 Request Timeout

The server couldn't produce a response within the expected time. In practice, you'll see 408 when the INVITE was forwarded to a phone that isn't responding. The proxy waited for a response, none came, and it timed out. Common when the callee's phone is offline but still appears registered (the registration hasn't expired yet), or when a firewall is blocking the forwarded INVITE.

A 408 is one of the more common codes you'll see in troubleshooting, and it almost always points to a reachability problem on the callee's side.

480 Temporarily Unavailable

The callee's endpoint is valid but not reachable right now. This is similar to 408 but implies the server has more information. Maybe the phone recently went offline, or the user has enabled a "do not disturb" setting that rejects calls without ringing.

486 Busy Here

The callee is busy. Their phone is already on a call and doesn't accept additional calls. This is the SIP equivalent of a busy signal.

487 Request Terminated

The request was cancelled. You'll see this when a caller hangs up while the phone is still ringing. The sequence is: INVITE, 180 Ringing, CANCEL, 200 OK (to the CANCEL), 487 Request Terminated (to the original INVITE), ACK (to the 487). This is normal behavior, not an error, despite being in the 4xx range.

488 Not Acceptable Here

The request was understood but the media parameters are unacceptable. In practice, this almost always means a codec mismatch. The INVITE offered codecs that the callee doesn't support. Check the SDP in the INVITE against the callee's configured codecs.

491 Request Pending

Both sides tried to modify the session at the same time (both sent re-INVITEs simultaneously). The side that receives a 491 should wait a random interval and retry. This is usually handled automatically and you rarely need to troubleshoot it, but seeing a lot of 491s might indicate a timing issue with hold/transfer operations.

5xx: Server Errors

500 Internal Server Error

Something went wrong on the server. This is the server saying "I tried to process your request but I failed, and it's my fault, not yours." Check the server's logs for more detail.

502 Bad Gateway

The server, acting as a proxy, received an invalid response from the next hop. This can indicate a problem with an intermediate proxy or SBC, or a misconfigured routing table that's sending calls to a nonexistent destination.

503 Service Unavailable

The server can't handle the request right now, usually because it's overloaded or undergoing maintenance. For SIP trunks, a 503 from the carrier might indicate trunk capacity has been reached or there's an outage on their side.

6xx: Global Failures

600 Busy Everywhere

The callee was contacted at multiple locations (maybe they have a desk phone and a softphone) and all of them are busy. This is like 486 but applies to all registered endpoints for the user.

603 Decline

The callee explicitly rejected the call. The call was offered and deliberately refused, as opposed to being unanswered or unavailable. Some implementations use 603 when a user presses the "reject" button on an incoming call.

Using response codes in troubleshooting

When you're working through a SIP trace, response codes are your primary indicators of what happened and where. The troubleshooting approach is:

Find the failed transaction by looking for the non-2xx final response. Look up the response code and understand what category of problem it represents. Then look at the context: what was the request? Where did the response come from? What were the headers in both the request and the response?

A 488 coming back from a carrier's SBC tells you the codec negotiation failed with the carrier. A 408 from your proxy tells you the callee's phone didn't respond. A 403 from the registrar tells you the account is blocked. The response code narrows your search from "something is broken" to a specific area of investigation.

Next up: Authentication and Security in SIP, covering how SIP handles credentials, what encryption options exist, and why toll fraud is a real threat.