🔎 SIP Response Code Lookup
Search any SIP code and get what it means in practice — not just the RFC wording.
46 codes
The next hop received your INVITE and is working on it. Purely informational — if the dialog stalls here, the problem is downstream, not with your request.
The callee's device is alerting. If the caller hears nothing at this point, you have a media/ringback issue, not a signalling one.
The call is being redirected to another destination.
The callee is temporarily unavailable and the call has been queued rather than rejected.
Early media — the far end is sending audio (ringback, an IVR, or a carrier announcement) before the call is answered. If you get 183 and then silence, suspect NAT or a one-way RTP path.
The request succeeded. For an INVITE this means the call is answered and media should be flowing.
Request accepted for processing — commonly seen with REFER (call transfer) and SUBSCRIBE.
Several possible destinations were returned; the client picks one.
The user has a new permanent address — update your dialplan or registration target.
Call forwarding. Very common in carrier setups. Check the Contact header for where it's being sent; a redirect loop here is a classic cause of failed calls.
The request must be routed through the proxy given in the Contact header.
The call failed, but an alternative service (such as voicemail) is available.
Malformed request — a missing or corrupted header. Often a SIP ALG on a router mangling packets in transit. Disabling SIP ALG is the usual fix.
Authentication challenge from a registrar. Normal as the first step of registration: the device should retry with credentials. Repeated 401s mean the secret is wrong.
The server understood you but refuses. In practice: wrong credentials, an IP not on the carrier's allow-list, calling a prefix you aren't permitted, or a disabled account. One of the most common trunk failures.
The dialled number or user does not exist on that server. Check the dialplan, the number format (E.164 vs national), and whether the extension is actually registered.
The method (INVITE, REFER, etc.) is recognised but not permitted here — common when attempting a transfer the far end doesn't allow.
Same as 401 but issued by a proxy rather than a registrar. Retry with proxy credentials.
No response in time. Usually a network path problem, a firewall silently dropping SIP, or a dead far end. Check whether signalling reaches the destination at all.
The user existed but has been permanently removed.
The message body is too big for the server to process.
The body format isn't understood — typically an SDP the far end can't parse.
A protocol extension listed in the Require header isn't supported by the server.
The requested session timer is shorter than the server allows. Raise the session-expires value.
The registration expiry you asked for is shorter than the server permits. Increase your registration interval.
The destination exists but isn't reachable right now — the extension is unregistered, the device is offline, or Do Not Disturb is on. Check registration status first.
A message arrived referencing a dialog the far end has no record of — often a BYE for a call already torn down, or lost state after a restart.
The request came back to a server it had already passed through. A routing or forwarding loop in the dialplan.
Max-Forwards reached zero. Almost always a routing loop between servers.
The dialled number appears truncated. Common with overlap dialling or a dialplan pattern matching too early.
The callee is on another call or has rejected it. A normal, expected outcome — not a fault.
The INVITE was cancelled before answer, normally because the caller hung up or another branch of a forked call picked up. Expected alongside a CANCEL.
Codec mismatch — the two ends share no common codec, or SDP negotiation failed. Check allowed codecs on both sides, and whether SRTP/DTLS is required by one end but not offered by the other. Extremely common on new trunks.
The Event package in a SUBSCRIBE isn't supported by the server (BLF/presence setups).
A re-INVITE arrived while another was still in progress — the two ends collided. Usually resolves itself on retry.
The server could not decrypt the S/MIME body.
The far end broke while handling a valid request. Check that server's own logs — the fault is not in your request.
The server doesn't support the method at all.
A gateway received an invalid response from the server it was relaying to.
The server is overloaded, in maintenance, or rejecting due to capacity/rate limits. On a carrier trunk it often means channel limits reached or the account is suspended.
An upstream server didn't respond in time.
The message exceeded what the server accepts — often a large UDP packet that should be sent over TCP instead.
The callee is busy at every location, and no other endpoint will accept the call.
The callee explicitly rejected the call. Carriers also use 603 as a generic refusal for blocked or barred destinations.
The number is definitively invalid — no location has it.
Some aspect of the session description was unacceptable to the callee.
How to read SIP response codes
SIP borrows its response structure from HTTP, so the first digit tells you the category before you know anything else:
- 1xx — provisional; the request is in progress.
- 2xx — success.
- 3xx — redirection; the call should go somewhere else.
- 4xx — client error; something about your request was wrong.
- 5xx — server error; your request was fine, the far end failed.
- 6xx — global failure; refused everywhere, don't retry elsewhere.
The 4xx/5xx split matters most when troubleshooting: a 4xx points at your configuration, while a 5xx points at theirs. Knowing which side owns the problem saves a lot of time before you open a carrier ticket.
The codes you'll actually hit
In day-to-day VoIP work a handful dominate. 403 Forbidden is almost always credentials or an IP allow-list. 488 Not Acceptable Here is a codec or SRTP mismatch. 480 Temporarily Unavailable means the extension isn't registered. 408 Request Timeout means signalling never arrived. And 400 Bad Request on an otherwise healthy setup very often means a router's SIP ALG is rewriting packets in flight.
Seeing these codes in Asterisk
Connect to the CLI and raise verbosity with asterisk -rvvv, then enable SIP tracing for the stack you run — pjsip set logger on for PJSIP, or sip set debug on for the older chan_sip. You'll see the full request and response exchange, including the response code and any reason phrase the far end attached, which is often more specific than the code itself.
A response code tells you what was refused; the headers tell you why. Always read the accompanying Warning or Reason header if one is present — carriers frequently explain the real cause there while returning a generic 403 or 503.
Frequently asked questions
What does SIP 488 Not Acceptable Here mean?
The two ends could not agree on media. Either they share no common codec, or one side requires encrypted media (SRTP/DTLS) that the other isn't offering. Compare the codec lists in both configurations and check the SDP in a trace.
Why do I get 403 Forbidden on a SIP trunk?
The carrier recognised the request and deliberately refused it. The usual causes are a wrong password, the calling IP not being registered on the carrier's allow-list, a number format the carrier rejects, or calling a destination the account isn't permitted to reach.
Is SIP 486 Busy Here an error?
No. It's the normal response when the callee is already on a call or actively rejects it. You don't need to fix anything unless you're getting it when the extension is genuinely free.
Why does the call connect but there's no audio?
Signalling and media travel separately in SIP. A 200 OK means signalling succeeded; audio is RTP on entirely different ports, and it's usually NAT or a firewall blocking that RTP range that causes one-way or no audio. See why VoIP calls have no audio and NAT and SIP.
Related reading: how to read Asterisk logs and fixing “extension not registered” in FreePBX.