SIP failure codes are the closest thing wholesale voice has to an error log, and most of them are more specific than they look. Knowing which side of the interconnect a code points at saves a great deal of time before anyone opens a ticket.
This is not the full RFC 3261 list. It is the subset that turns up in real traffic, grouped by what you should actually do about it.
Key takeaways
- 4xx means this request failed. 5xx means the server failed. 6xx means the call was refused everywhere.
- 403 and 407 are almost always your configuration, not the carrier's routing.
- 404, 484 and 488 point at number formatting and codec negotiation.
- 480, 486 and 487 are usually normal call outcomes, not faults.
- 503 in volume is the one that genuinely warrants a call to your carrier.
The three families
SIP borrows its response structure from HTTP, and the first digit carries most of the meaning.
| Family | Means | Points at |
|---|---|---|
| 4xx | This specific request failed | Your request, or the dialled number |
| 5xx | The server could not process it | The carrier or an upstream network |
| 6xx | Refused globally, do not retry | The called party, definitively |
The distinction between 4xx and 5xx matters more than any individual code. A 4xx says something about this call. A 5xx says something about the network, which means it will likely affect the next call too.
Codes that mean check your own configuration
403 Forbidden. The request was understood and refused. This is an authorisation failure, not a routing one: an IP that is not allow-listed, credentials that have rotated, a caller ID the account may not present, or a destination prefix the account is not enabled for. If a 403 appears on a route that worked yesterday, something changed on the account, not on the route.
407 Proxy Authentication Required. Credentials were missing or wrong. On a trunk that has been running for months, this usually means a password change propagated somewhere it should not have, or a device re-registered with stale config.
488 Not Acceptable Here. Codec negotiation failed: the two ends could not agree on an audio format. Very common when one side offers only G.729 and the other only G.711, or when a device offers a codec list the carrier does not support.
Codes about the number itself
404 Not Found. The number does not exist on the terminating network. In wholesale traffic, a 404 in volume almost always means number formatting rather than genuinely dead numbers: a missing country code, a retained national trunk prefix, or E.164 formatting applied inconsistently.
484 Address Incomplete. The dialled number was too short to route. Classic symptom of overlap dialling, or of a dial plan sending digits before the full number has been collected.
485 Ambiguous. The number matched more than one possible destination. Rare, and nearly always a dial plan problem on the originating side.
Codes that are not faults at all
These three account for a large share of "failed" calls and mostly represent normal human behaviour.
486 Busy Here. The called party is on another call. This is a successful delivery: the network reached the destination and the destination said no. It counts against ASR and in favour of NER, which is exactly why those two metrics need reading together.
480 Temporarily Unavailable. The destination was reachable but could not take the call: device not registered, handset out of coverage, subscriber barred. Individually normal. In volume against a single destination, it starts to suggest a routing or registration problem rather than coincidence.
487 Request Terminated. The caller hung up before the call was answered. Ordinary on outbound campaigns, and worth excluding from failure analysis entirely.
The one worth escalating
503 Service Unavailable. The element that received the call could not process it. Congestion, a capacity ceiling, or a downstream failure being passed back up the chain.
A handful of 503s is unremarkable. A sustained pattern is the clearest signal in this list that the problem is upstream of you, and it is the code most worth quoting when you open a ticket, along with the destination prefix, a timestamp, and the Call-ID of a failing call.
500 Server Internal Error and 502 Bad Gateway carry the same implication with less specificity: something broke on the carrier side.
Working through a failure
When failures spike, the sequence that resolves things fastest is:
- Group the failures by response code first, then by destination prefix. One code dominating one prefix is a very different problem from a spread.
- Check whether the code is 4xx or 5xx. That alone decides whether you are looking at your own configuration or someone else's network.
- For 4xx, compare a failing call against a working one to the same country.
- For 5xx in volume, collect the Call-ID, timestamp and prefix before escalating. A ticket with those three fields moves considerably faster than one without.