Skip to content

SIP response codes

A SIP response code tells you what happened to a request. Which of them mean “down” is a narrower question than most monitoring tools assume: a server has to be working in order to tell you it is forbidden, busy, or not accepting that method.

The rule SIP Sentry applies to signalling checks is simple, and it is worth stating before the tables:

Any final response below 500 means the far end is alive and processing SIP. Responses in the 5xx range mean it is broken. No response at all is ambiguous — it may be a policy that drops SIP from unknown sources — so it is treated as degraded rather than down.

The monitor column below is how SIP Sentry classifies the code on an OPTIONS or REGISTER check. It is not the same as whether a call would have succeeded, which is a different question with a different answer for most 4xx codes.

1xx — provisional

The request was received and processing continues. Provisional responses never end a transaction on their own.

Code Name What it means in practice Monitor
100 Trying The next hop took the INVITE. Stops retransmissions, promises nothing. up
180 Ringing The far end is alerting a user. up
181 Call Is Being Forwarded A proxy is redirecting the call onward. up
182 Queued Held in a queue rather than rejected. Common on contact-centre platforms. up
183 Session Progress Early media — ringback or a carrier announcement — is on its way. up

2xx — success

Code Name What it means in practice Monitor
200 OK The request succeeded. For OPTIONS, the far end is healthy and answered. up
202 Accepted Used with REFER and SUBSCRIBE. Accepted, outcome not yet known. up

3xx — redirection

The request should be retried somewhere else. Seen mostly from redirect servers and least-cost routing platforms.

Code Name What it means in practice Monitor
300 Multiple Choices Several possible destinations offered in Contact headers. up
301 Moved Permanently Update your routing; the user has moved for good. up
302 Moved Temporarily Classic call-forwarding and failover redirect. up
305 Use Proxy The request must go through the proxy named in Contact. up
380 Alternative Service Rejected, but here is another way to reach the service. up

4xx — request failure

The most common family, and the one most often misread as an outage. Nearly all of these are policy or routing decisions made by a working server.

Code Name What it means in practice Monitor
400 Bad Request Malformed message. Usually a header your equipment emits that the far end rejects. up
401 Unauthorized Digest challenge from a registrar. Expected as the first REGISTER answer. up
403 Forbidden Authenticated or not, policy says no. Almost always an IP allowlist or a wrong realm. up
404 Not Found The user in the Request-URI does not exist here. Frequently a dial-plan or number-porting problem. up
405 Method Not Allowed The server does not serve this method. Very common answer to OPTIONS on an SBC, and entirely healthy. up
407 Proxy Authentication Required Like 401, but from a proxy rather than a registrar. up
408 Request Timeout No answer within the transaction timer. Usually a firewall, NAT, or a next hop that vanished. degraded
410 Gone The user existed and no longer does. up
415 Unsupported Media Type Codec mismatch in the SDP. The signalling worked; the media negotiation did not. up
420 Bad Extension A Require header asked for something unsupported. up
422 Session Interval Too Small Your session timer is shorter than the far end allows. up
423 Interval Too Brief Your REGISTER expiry is shorter than the registrar permits. Re-register with its minimum. up
480 Temporarily Unavailable Nobody registered, do-not-disturb, or an endpoint that has gone offline. up
481 Call/Transaction Does Not Exist The dialog the far end thought existed is gone. Often follows a restart at one end. up
482 Loop Detected Your routing sends the call back where it came from. up
483 Too Many Hops Max-Forwards hit zero — a routing loop by another name. up
484 Address Incomplete Overlap dialling, or a number sent before it was complete. up
486 Busy Here The endpoint is busy. The signalling path is intact. up
487 Request Terminated The caller hung up before answer, or CANCEL arrived. Normal. up
488 Not Acceptable Here No common codec, or SDP the far end will not accept. The usual cause of a call that fails instantly after ringing. up
491 Request Pending Two re-INVITEs crossed. Retry after a moment. up

5xx — server failure

These are the ones that matter. The far end is telling you that it, not your request, is the problem.

Code Name What it means in practice Monitor
500 Server Internal Error Something broke inside the far end: a crashed process, an unreachable database, a full disk. down
501 Not Implemented The method is not supported by the server at all. down
502 Bad Gateway A proxy got an invalid response from the next hop. The fault is one step further away. down
503 Service Unavailable Overload, CPS limit exceeded, all channels busy, or a platform in maintenance. The most common carrier-side outage code. down
504 Server Time-out A proxy waited for a downstream server and gave up. down
513 Message Too Large The request exceeded what the server will process — usually a huge SDP over UDP. down
580 Precondition Failure Requested QoS preconditions cannot be met. down

6xx — global failure

A 6xx applies to the user everywhere, not just at this server, so a proxy should stop trying alternatives.

Code Name What it means in practice Monitor
600 Busy Everywhere Busy on every branch that was tried. up
603 Decline The user actively rejected the call. Also used by carriers to block a destination. up
604 Does Not Exist Anywhere No such user, anywhere. up
606 Not Acceptable The session description is unacceptable at every location. up

The two you will chase most

503 Service Unavailable

A 503 from a carrier is a capacity statement far more often than a fault statement. Work through, in order: whether you have exceeded the calls-per-second the contract allows, whether every channel on the trunk is in use, whether the far end is in a maintenance window, and only then whether the platform has genuinely failed. A 503 carrying a Retry-After header is telling you explicitly to back off rather than retry immediately.

If the 503 is coming from your platform, look at CPU and memory first, then at whatever the SIP process depends on — a registrar that cannot reach its database answers 503 while looking perfectly healthy from the network.

408 Request Timeout

A 408, or a timeout with no response at all, almost never means “the server is down”. It means your request or its answer did not survive the round trip. The usual causes, in the order they turn up: a firewall dropping SIP from an address it does not recognise, a NAT binding that expired between keepalives, an SBC configured to silently discard traffic from unknown sources, and only then an actually dead host.

This is precisely why SIP Sentry treats a timeout as degraded rather than down, and why it will not page you on a single one. See REGISTER check safety for how the same caution is applied to authentication failures.