Darwvin

SIP response codes explained: the complete reference with causes and fixes

SIP response codes from 1xx to 6xx with RFC 3261 meanings, the real causes of 401, 403, 480, 488 and 503, and how to fix each one.

Published 13 min read

Every SIP response carries a three-digit code, and its first digit sets the class: 1xx provisional, 2xx success, 3xx redirection, 4xx a failure from one server, 5xx a server failure, and 6xx a failure at every destination. Most failed registrations and calls end on a small set of codes. The table below gives the meaning and the first check for each, and the sections after it cover the causes that show up in real deployments.

Quick lookup table

CodeReason phraseUsual causeFirst check
100TryingRequest reached the next hopNothing
180RingingCallee is alertingNothing
183Session ProgressEarly media, such as ringbackSDP in the 183
401UnauthorizedDigest credentials wantedPassword, auth user, realm
403ForbiddenCredentials, source address or policy refusedServer log for this Call-ID
404Not FoundDialed user or domain unknownDialed number and domain
407Proxy Authentication RequiredTrunk or proxy wants credentialsTrunk credentials, Proxy-Authorization
408Request TimeoutUser location not found in timeRegistration, network path
423Interval Too BriefRequested expiry too shortMin-Expires value
480Temporarily UnavailableCallee not registered, or do not disturbRegistration, DND
481Call/Transaction Does Not ExistNo matching dialogRestarts, failover, live channels
484Address IncompleteNumber too short for the dial planDigits and overlap dialing
486Busy HereCallee busyNormal; check stuck calls if constant
487Request TerminatedCancelled before answerNormal after CANCEL
488Not Acceptable HereSDP offer not matched, for example no common codecCodecs and transport on both legs
491Request PendingRe-INVITE glareSimultaneous hold or transfer
500Server Internal ErrorServer faultServer logs
502Bad GatewayInvalid response from next hopRoute and SBC
503Service UnavailableOverload, maintenance, no free channelsChannel limit, Retry-After
504Server Time-outUpstream server did not answerUpstream reachability
600Busy EverywhereBusy, and no other destination will answerNormal
603DeclineCallee declinedNormal
604Does Not Exist AnywhereNumber unknown everywhereNumber format
606Not AcceptableSession description not acceptable anywhereCodecs and media

Codes and reason phrases follow RFC 3261 and the IANA SIP parameters registry. The reason phrase is for people: RFC 3261 says a client need not examine it, so match on the number.

Read the final response, not the first one

A 1xx response never causes an ACK (RFC 3261 section 21.1), so troubleshoot the final response that ends the INVITE or REGISTER. After a non-2xx answer to an INVITE, the client transaction sends the ACK itself (section 17.1.1.3), so an ACK after a 488 in a trace is normal. Servers may append their own text to the phrase, so match on the number.

Authentication failures: 401 and 407

SIP 401 Unauthorized

A 401 comes from an endpoint or registrar and means the request needs user authentication (RFC 3261 section 21.4.2). The client answers with a digest in an Authorization header and retries (sections 8.1.3.5 and 22.2). Causes to check:

  • Wrong password. Compare it character by character, including any generated password from your provider.
  • Auth user differs from the SIP user. Many providers issue a separate auth ID. Sending the phone number as the digest username fails every attempt with a 401.
  • Realm mismatch. The digest must use the realm from the challenge.
  • Algorithm mismatch. RFC 8760 adds SHA-256 and SHA-512/256 to SIP digest and treats MD5 as obsolete, so an MD5-only client cannot answer a SHA-256 challenge.
  • Stale nonce. A challenge with stale=true means the nonce expired. RFC 3261 section 22.1 allows a retry, so this is not a password problem.

The retry carries a header like this, trimmed:

REGISTER sip:pbx.example.net SIP/2.0
Authorization: Digest username="alice-auth", realm="pbx.example.net", nonce="7bd2c1e0", uri="sip:pbx.example.net", response="...", algorithm=MD5

To isolate the cause, register a second device with the same credentials. If that fails too, the credentials or account settings are wrong. If it works, compare the username, realm and algorithm in your client with the challenge in a capture.

SIP 407 Proxy Authentication Required

A 407 is the same challenge from a proxy, such as a SIP trunk edge. RFC 3261 section 21.4.8 covers the case where access to the channel itself, such as a telephony gateway, needs credentials. The retry carries a Proxy-Authorization header for the proxy's realm (section 22.3). A typical failure is a client that handles 401 but not 407, so the INVITE dies at the trunk edge. The first block is the challenge and the second the retry, trimmed:

SIP/2.0 407 Proxy Authentication Required
CSeq: 1 INVITE
Proxy-Authenticate: Digest realm="sip.example.net", nonce="3f9a0c51", algorithm=SHA-256

INVITE sip:+15551230000@sip.example.net SIP/2.0
CSeq: 2 INVITE
Proxy-Authorization: Digest username="trunk-user", realm="sip.example.net", nonce="3f9a0c51", uri="sip:+15551230000@sip.example.net", response="...", algorithm=SHA-256

Check that the client answers 407, and that the trunk credentials belong to the account that places outbound calls.

Refused requests: 403, 404 and 423

SIP 403 Forbidden

RFC 3261 section 21.4.4 defines 403 as a refusal: the server understood the request but is refusing to fulfill it, and authorization will not help. RFC 3261 also lets a server answer rejected credentials with 403 instead of a new challenge (section 22.1). An asterisk-dev thread from 2013 shows Asterisk replying "403 Forbidden (Bad auth)" to a failed REGISTER and argues that 403 is the wrong code there, so a 403 on REGISTER can mean a wrong password. Other causes:

  • Access lists. A provider that accepts traffic only from registered public addresses refuses everything else. A changed public IP can start producing 403s.
  • Account policy. A carrier may refuse a destination the account cannot call, or a call over its concurrent-call limit. Telnyx's developer documentation says a call over the configured limit gets a SIP 403 whose reason phrase begins "User channel limit exceeded" (as of October 2026).

Start with the server log for the Call-ID. Then check the source address in a capture, the account status and allowed destinations, and whether a second device with the same settings gets the same answer.

SIP 404 Not Found

RFC 3261 section 21.4.5 says the server knows the user does not exist at the domain in the Request-URI, and it also answers 404 when that domain is not one it handles. A 404 concerns where the request went, not your password. Check the number format (local or full international), the dial plan, and whether the domain matches the one the server serves, such as its hostname rather than an IP address.

SIP 423 Interval Too Brief

A registrar returns 423 when the expiry you requested is too short (section 21.4.17). RFC 3261 section 10.3 requires the response to carry a Min-Expires header. Raise the client's expiry to at least that value.

Routing and availability: 480, 481, 484 and the busy codes

SIP 480 Temporarily Unavailable

RFC 3261 section 21.4.18 says the callee was reached but is unavailable: not logged in, in a state that blocks the call, or with do not disturb enabled. Retry-After may suggest a better time. In practice, check whether the softphone is registered at all (an app that is asleep, a network change or an expired registration), whether the server still holds a live contact, and whether do not disturb is set. On Asterisk, these commands show endpoint state and registered contacts:

sudo asterisk -rx "pjsip show endpoints"
sudo asterisk -rx "pjsip show contacts"

If the callee has no live contact, fix the registration first. NAT-related registration trouble is covered in SIP and NAT explained.

SIP 481 Call/Transaction Does Not Exist

RFC 3261 section 21.4.19 defines 481 as a request that matches no dialog or transaction. In a live call, one side has lost the dialog, for example after a restart or failover. Compare the PBX's live channels, from sudo asterisk -rx "core show channels", with what the phones show.

SIP 484 Address Incomplete

RFC 3261 section 21.4.22 describes overlapped dialing: the client sends digits and keeps prompting until 484 stops. A complete number that still gets 484 points to a dial plan that expects more digits.

SIP 486, 600 and 603

486 means the callee was reached but cannot take another call there (section 21.4.24). 600 means no other endpoint will accept it (section 21.6.1), and 603 means the user declined (section 21.6.2). These are normal. If they hit calls that should ring, look for a stuck call on the PBX or a phone still in one.

SIP 487 Request Terminated

487 ends an INVITE that a CANCEL or BYE terminated before any answer (section 21.4.25). It is normal when a caller hangs up while the phone rings.

SIP 491 Request Pending

491 means a pending request already exists in the same dialog, typically a re-INVITE (section 21.4.27). Section 14.2 explains how the collision is resolved. It appears when both sides hold or transfer at once, so avoid the simultaneous change rather than retrying faster.

Media negotiation: 488 and 606

SIP 488 Not Acceptable Here

RFC 3261 section 21.4.26 gives 488 the meaning of 606, limited to the resource in the Request-URI, so the request may succeed elsewhere. Section 21.6.4 describes 606 as media, bandwidth or addressing that is not acceptable. A 488 may carry a body describing the callee's capabilities, so open it in a capture. Brekeke's SIP server documentation lists codec mismatch as a possible cause of both 415 and 488.

Two causes are typical:

  • No common audio codec. RFC 3264 section 6.1 says an answerer with no common format for a stream must reject that stream with port zero, and the whole session is rejected when no stream matches. An Opus-only offer to a G.711-only phone, with no transcoding, lands here.
  • Encryption or transport mismatch. An offer using RTP/SAVP (SRTP, RFC 3711) sent to an endpoint without SRTP can be rejected, so compare the m= transport on both legs.

The fix is a codec both legs share. PCMU and PCMA are static payload types 0 and 8 (RFC 3551 section 6), so any G.711 stack can match them. Opus uses a dynamic payload type set in the SDP (RFC 7587 section 4.1). In Asterisk PJSIP endpoints, disallow=all followed by allow=ulaw,alaw limits the offer to G.711. The option names come from the official pjsip.conf sample:

[1001]
type=endpoint
transport=transport-udp
disallow=all
allow=ulaw,alaw

A rejected stream appears in the answer as m=audio 0 RTP/AVP 0 8. Port 0 means no media flows on it.

Server and trunk failures: 408, 500, 502, 503 and 504

SIP 503 Service Unavailable

RFC 3261 section 21.5.4 defines 503 as temporary overload or maintenance. Retry-After is optional, and without it the client must treat the response as a 500. Trunks add one cause: RFC 3398 maps ISUP cause 34, "no circuit available", to SIP 503, so a 503 on an outbound call can mean no free channel. Carriers differ, though. The Telnyx example in the 403 section reports channel overflow as a 403.

Count live calls on the trunk against the channels you pay for, using sudo asterisk -rx "core show channels" on Asterisk. Then reduce concurrency or add channels, honor Retry-After, and check the provider's status. If your own SBC generates the 503, check its overload settings.

SIP 408 Request Timeout and 504 Server Time-out

408 means no response in time, for example because the user's location was not found in time (RFC 3261 section 21.4.9). 504 means a server in the path waited on an external server that did not answer (section 21.5.5). Test the route from the hop that sent the code to its next hop.

SIP 500 and 502

500 is an unexpected server condition, and the client may retry after several seconds (section 21.5.1). 502 means a gateway received an invalid response from downstream (section 21.5.3), which points at a route or an SBC whose next hop returned something invalid. Read the server log at the moment of failure.

Redirects and early media

A 302 tells the client to retry at the Contact address (RFC 3261 section 21.3.3). A softphone that ignores it fails the call, so check the Contact first.

A 183 can carry SDP, because provisional responses may contain session descriptions (section 21.1). That is how ringback or an IVR prompt reaches the caller before answer. If the client never plays it, the caller hears silence until the call is answered. The one-way audio runbook covers that case.

Let the softphone explain the failure

A table gives meanings, but a failed call needs the whole exchange. Darwvin Softphone's Call Doctor uses rule-based diagnostics to explain why a call failed or had bad audio, so you get the reason in plain terms. On the Linux desktop app, the SIP message ladder shows the exchange in order. Darwvin Softphone is in Early Access, available for Android and as a Linux desktop app, and its Windows and macOS desktop apps are still in development.

A debugging order that works

  1. Find the final response for the transaction that failed.
  2. Look up its number in the table and read the section above.
  3. Search the server log for the same Call-ID.
  4. Reproduce with one client, one destination and one codec.
  5. Capture the exchange and open it in sngrep:
sudo tcpdump -i any -n -s 0 -w sip-trace.pcap 'port 5060 or port 5061'
sngrep -I sip-trace.pcap

sngrep shows each SIP call as a flow, and opening a message shows its headers and SDP. SIP over TLS is encrypted, so for TLS calls read the codes from the server or client log.

FAQ

Is a 403 always an authentication problem?

No. RFC 3261 defines 403 as a refusal that authorization will not fix, and the causes include access lists and account policy. Some servers also send 403 for rejected credentials, so read the server log before you change a password or a firewall rule.

What is the difference between a 401 and a 407?

A 401 comes from the endpoint or registrar that owns the user. A 407 comes from a proxy in front of it, such as a trunk edge. The retry differs too: an Authorization header for a 401, a Proxy-Authorization header for a 407 (RFC 3261 sections 22.2 and 22.3).

Why do I get 480 when the app shows as online?

A 480 says the callee was reached but is unavailable. An expired registration or a do-not-disturb setting produces it even when the app looks online, so check the server's registration first.

What does 488 Not Acceptable Here mean for codecs?

It means the SDP offer could not be matched. The classic trigger is no codec in common between the two legs. Put G.711 (PCMU and PCMA) on both ends as a fallback, and check the encryption setting on each leg.

Should I retry after a 503?

Only after the Retry-After delay, if one was sent. Without it, RFC 3261 says to treat the response as a 500. On a trunk, a 503 can also mean every channel is busy, so lower the call rate before retrying.

References

Get product news by email

We use your address only for these emails. The unsubscribe link is in every email. Read our privacy policy.