Every failed SIP call returns a code, and most of them are misread. The number does not tell you what went wrong so much as where to look — and the difference between a 403 and a 404 is the difference between an hour of wasted debugging and a two-minute fix.
The families, before the individual codes
SIP borrowed its numbering from HTTP, and the first digit carries most of the meaning:
- 1xx — in progress. 100 Trying, 180 Ringing, 183 Session Progress. Nothing is wrong.
- 2xx — success. 200 OK is the call being answered.
- 3xx — redirected somewhere else.
- 4xx — your side of the conversation has a problem. This is where most real faults live.
- 5xx — the server you are talking to has a problem.
- 6xx — a global refusal: nowhere will accept this call.
That split matters. A 4xx is usually yours to fix; a 5xx usually is not.
403 Forbidden
The far end understood you perfectly and refused. On a trunk this is nearly always authentication or authorisation: the source IP is not on the access list, the credentials are wrong, or the destination is blocked on your account.
Check, in this order: is the IP you are actually sending from the one registered on the trunk? Has the office broadband changed address? Is the destination prefix one your account is permitted to dial? A 403 on a single destination and not others is almost always a blocked-prefix rule doing its job.
404 Not Found
The number does not exist as dialled. Nine times out of ten this is a formatting problem rather than a genuinely dead number.
Check the dialled string in the trace, not in the dialplan. Leading zeros stripped, a missing country code, an 11-digit UK number sent without the 44, a stray space from a copy-paste — all present as 404. Compare a working call and a failing one side by side and the difference is usually obvious.
403 and 404 get confused constantly403 means "I know who you are and you may not do that". 404 means "there is nothing at that address". If you are checking credentials on a 404, or checking number format on a 403, you are looking in the wrong place.
408 Request Timeout
You sent something and nothing came back within the timer. Usually a network path problem rather than a call problem: a firewall dropping UDP, an ALG mangling packets, or a route that has gone dark.
If 408s appear on every destination at once, look at connectivity. If they appear on one, it is the far end.
480 Temporarily Unavailable
The destination exists but nothing is registered or answering right now. On an internal call it usually means the handset has lost registration. On an outbound call to a mobile it can simply mean the phone is off.
Persistent 480s on internal extensions point at registration expiry — a NAT timeout shorter than the registration interval is the classic cause.
486 Busy Here
Genuinely busy. The line, the queue or the channel limit is full. This is the one code that is often not a fault at all.
Worth watching as a trend, though: a rising 486 rate on inbound calls means your channel count is too small and callers are being turned away. See our note on sizing SIP channels.
487 Request Terminated
The call was cancelled before it was answered — almost always the caller hanging up while it was still ringing. Normal, and not something to chase unless the ring time before it is suspiciously short.
503 Service Unavailable
The far end is up but cannot take the call: a carrier at capacity, a route withdrawn, or a gateway in trouble. On a well-built platform a 503 should trigger failover to the next carrier rather than failing the call outright.
If you see 503s reaching your users, ask your provider whether the fallthrough is configured — the whole point of least cost routing is that the second choice exists.
What to capture before you report it
Three things make a fault solvable in one exchange instead of five: the full dialled number as it left your system, the time to the minute with the timezone, and the Call-ID from the trace. With those, the call can be found in seconds. Without them, the first reply will only ask for them.
Our support is an engineer who reads the SIP trace, not a script.
Talk to us
