SIP response codes explained: complete 1xx to 6xx reference

A SIP response code is a three-digit number a server returns to say what happened to a request. The first digit is the class and carries most of the meaning: 1xx means work is in progress, 2xx means success, 3xx redirects, 4xx means this request failed at this destination, 5xx means this server failed, and 6xx means the answer is no everywhere. The remaining two digits identify the specific condition. All codes are recorded in the IANA Session Initiation Protocol (SIP) Parameters registry, which notes that every code is defined by RFC 3261 unless a later specification is cited against it.

Reading them well is mostly a matter of not over-reading them. A code tells you what one element decided about one request. It does not tell you who generated it, why the element behind it made that choice, or whether the same request would fail on another route.

Quick facts

The six classes, and what each one obliges the network to do

The class is not a severity label. It is an instruction about what to do next, and getting that instruction right is the whole reason codes are grouped this way. Learn the six behaviours before you look up any individual number.

1xx Provisional. The request arrived and processing continues. Provisional responses do not end the transaction and are not acknowledged. Their practical job is visible in gateway behaviour: RFC 3398 notes that a 100 triggers no telephone-network signalling at all and exists only to stop the sender retransmitting the INVITE.

2xx Success. The request succeeded. For INVITE this means the call has been answered, and the caller acknowledges with ACK.

3xx Redirection. The target moved. The response carries one or more Contact addresses and the caller is expected to try them.

4xx Request failure. This destination will not accept this request as it stands. Some 4xx codes are genuinely about the request, such as a missing credential or an unsupported body. Others describe the state of the called user.

5xx Server failure. This server could not process a request that may be perfectly valid. This is the class that failover logic should react to, because another server may succeed with the identical request.

6xx Global failure. The answer is no for this user, not merely for this address. The consequence is behavioural, not rhetorical: as RFC 8688 restates for the 608 code, a proxy receiving a 6xx should cancel pending transactions and must not create new branches.

Where responses appear in a call

An INVITE can collect any number of provisional responses, but exactly one final response, and every final response is acknowledged with ACK. That is worth stating plainly because it explains a code that confuses people constantly: when a caller gives up before answer, the CANCEL gets its own 200, and the original INVITE still needs one final response and one only.

That final response is 487 Request Terminated. RFC 3398 shows the same sequence at a gateway: on CANCEL, a 200 confirms the CANCEL, a 487 completes the INVITE transaction, and a release message goes to the telephone side with cause 16, normal clearing.

1xx Provisional

The 180 and 183 distinction matters for billing and for user experience. A gateway sends 180 when the telephone network reports the subscriber is free, and 183 when it needs a media path for an announcement or tone. Treating 183 as ringing produces silent calls; treating it as answer produces charged calls that were never answered.

2xx Success

3xx Redirection

Redirects deserve care in wholesale voice. Following a 3xx sends a new request to an address chosen by someone else, which has cost and fraud implications. Most carrier-facing platforms restrict this by policy rather than following redirects blindly.

4xx Request failure

5xx Server failure

6xx Global failure

The 607 and 608 pair is worth understanding properly, because it is the only part of the code space designed around call blocking. RFC 8688 defines 608 for the case where an intermediary such as an analytics engine rejects the call, and draws an explicit contrast with 607, where a human at the called endpoint indicated the call was unwanted. The specification notes that in some jurisdictions this distinction matters, since a machine’s statistical judgement should not be recorded downstream as a person’s decision.

RFC 8688 also builds in a redress path. A 608 from a conforming intermediary carries a Call-Info header with the purpose parameter set to jwscard, pointing to a signed jCard that tells the blocked caller how to contact whoever blocked them. The signature is not decoration: the specification requires it so that a spoofed 608 cannot send callers to an address of an attacker’s choosing.

One more detail in that document is directly useful to anyone running legitimate outbound campaigns. It records that some call-blocking services return 604 Does Not Exist Anywhere as a blocking strategy, warns that other network elements may read that literally as the user not existing, and observes that in many jurisdictions such false signalling is illegal. If your outbound reporting counts 604 as invalid numbers, some of those numbers are fine and you are quietly discarding them.

The codes that get confused

SIP codes and Q.850 causes

Most calls that matter commercially cross between SIP and the telephone network at least once, and at that boundary a gateway translates between SIP response codes and Q.850 cause values. RFC 3398 specifies the recommended mapping in both directions.

Coming from the telephone network, the recommended translations include:

Going the other way:

Four details in that specification save a lot of argument later.

The tables are not symmetric. Cause 19 maps to 480, and 480 maps back to cause 18. A call that crosses two gateways can therefore arrive with a different cause than it left with. Reporting built only on the final value will disagree between hops, and neither side is wrong.

Defaults absorb everything unmapped. An unlisted cause becomes 500, and an unlisted SIP code becomes cause 31, normal unspecified. A large bucket of cause 31 in a report usually means codes are being flattened somewhere, not that many calls ended normally but unspecified.

Some causes have no SIP equivalent at all. RFC 3398 gives cause 44, requested circuit or channel not available, as the example: the correct behaviour is for the originating switch to try another circuit, not to fail the call, so nothing is sent to the SIP side.

Cause location changes the answer. The same rejection can surface as 403 or 603 depending on whether the network or the user is recorded as the origin.

Cause values can also travel alongside the SIP code rather than being replaced by it. The IANA registry lists Q.850 as a registered Reason protocol, with the cause value carried in decimal, which is how a gateway can send 503 while still telling you the underlying cause was congestion.

One curiosity for anyone reading the specification closely: the SIP to cause table lists 504 twice, once for Server Time-out mapping to cause 102, and once against the Version Not Supported label, which is code 505.

Reading a code in a multi-hop call

A response code arrives without a return address. In a call that passes through a session border controller and two carriers, the code you see was generated by whichever element decided to stop, and that is often not the destination network.

Three habits make diagnosis faster.

Check who generated it before deciding what it means. The Via headers show the path the response travelled. A 503 from your first hop and a 503 relayed from four hops away call for entirely different responses.

Read Reason and Warning headers, not just the code. A Q.850 Reason value tells you what the telephone side actually said. A Warning header on a 488 or 606 tells you which media parameter was unacceptable, which is exactly what the code omits.

Correlate with the media path. A clean 200 followed by silence is not a signalling problem. Codes describe signalling decisions and say nothing about whether audio flowed.

Practical triage

Where didlogic fits

Response codes are the shared vocabulary between a customer platform and the carriers behind it, and they are where support conversations in wholesale voice usually start. didlogic provides the SIP trunking and international voice termination layer that sits between a platform and the destination networks, so the codes a customer receives are a mixture of decisions made locally, decisions made in transit, and causes translated from telephone networks at the far end.

That mixture is the reason a code alone rarely settles a question. Useful diagnosis pairs the code with the direction, the destination, the route and the timestamp, which is the same information a carrier needs in order to look at the other side of the same call. For outbound programmes running at volume, such as dialler traffic, tracking the distribution of codes per destination over time is more informative than any single failed call, because it separates a genuine routing fault from normal rejection behaviour on a given network.

FAQs

Are SIP response codes the same as HTTP status codes?
They share the class structure and several numbers, but they are separate registries with separate meanings. SIP adds a sixth class, 6xx, that HTTP does not have, and codes such as 486 or 480 exist only in SIP.

Which SIP codes mean the call was answered?
Only 2xx. A 183 with media can sound like a connected call, but the call is not answered until a 2xx arrives and is acknowledged.

Why do I get 480 from one carrier and 486 from another for the same number?
Because each is translating a telephone-network cause using its own rules, and because different networks release calls with different causes for similar situations. The RFC 3398 mappings are recommendations, not obligations.

What does 487 mean if nobody cancelled the call?
Something upstream cancelled it. A caller hanging up, an origination-side ring timer, or a forking proxy abandoning one branch will all produce a 487 on the branch that was terminated.

Is 503 always congestion?
No. It signals a temporary inability to handle the request, which covers congestion, maintenance and some policy conditions. Check whether a Retry-After or a Q.850 Reason value accompanies it.

Can I add my own response codes?
Not usefully. The Response Codes subregistry requires an RFC, and receiving elements will treat any unrecognised code according to its class digit.

Which codes should trigger failover to another route?
5xx conditions are the natural candidates because the request may succeed elsewhere. 6xx explicitly should not, since the answer is meant to apply to the user everywhere. Treatment of 4xx depends on the code: 403 and 404 usually indicate that retrying the same request will fail again.

Continue learning

• What is SIP?
• What is SIP trunking?
• Voice codecs: G.711, G.729, Opus and HD voice
• Caller ID reputation and spam likely labels
• International voice termination