VoIP.infoThe independent guide to business communications.
VoIP.info Knowledge library

SIP response codes

Interpret a SIP status in the context of its method, transaction and the system that sent it.

Reviewed 2026-10-14Foundational

Explore SIP response codes

SIP response reference

SIP 100 Trying

The next SIP hop has begun processing the request. This provisional response is normal progress, not proof that a phone is ringing.

Read guide →
SIP response reference

SIP 180 Ringing

The receiving side reports that alerting is being attempted. This is normal provisional signaling and is not a final answer.

Read guide →
SIP response reference

SIP 183 Session Progress

The receiver provides provisional session-progress information. It can participate in early-media handling, but 183 alone does not guarantee that usable audio is present.

Read guide →
SIP response reference

SIP 200 OK

The request succeeded under the responding system’s processing. Its practical meaning depends on the request method identified by CSeq.

Read guide →
SIP response reference

SIP 301 Moved Permanently

The requested address has a new permanent location represented by the redirect information. This is a routing instruction, not ordinary ringing.

Read guide →
SIP response reference

SIP 302 Moved Temporarily

The request should be retried at a temporary alternate location indicated by the response. It does not permanently redefine the called identity.

Read guide →
SIP response reference

SIP 400 Bad Request

The recipient cannot process the request because it considers the message malformed. The code alone does not identify the exact invalid field.

Read guide →
SIP response reference

SIP 401 Unauthorized

The server requests authentication or rejects an unauthenticated attempt. An initial 401 challenge can be a normal part of SIP registration or calling.

Read guide →
SIP response reference

SIP 403 Forbidden

The recipient understood the request but refuses it. This is a policy or authorization rejection; it does not universally mean the password is incorrect.

Read guide →
SIP response reference

SIP 404 Not Found

The recipient does not find the addressed user or resource in the domain it is handling. It is a SIP routing result, not an HTTP web-page error.

Read guide →
SIP response reference

SIP 407 Proxy Authentication Required

A SIP proxy challenges the request for proxy authentication. A challenge followed by a compatible authorized retry can be normal.

Read guide →
SIP response reference

SIP 408 Request Timeout

The request did not receive a timely result under the processing path that produced the response. It does not identify a single universal network cause.

Read guide →
SIP response reference

SIP 480 Temporarily Unavailable

The addressed user is temporarily unavailable under the recipient’s handling. Availability and routing state need examination; the code is not a hardware diagnosis.

Read guide →
SIP response reference

SIP 481 Call/Transaction Does Not Exist

The recipient cannot associate the request with the expected existing call or transaction. This often matters for in-dialog operations and cancellation.

Read guide →
SIP response reference · RFC 3261 Max-Forwards and 483 semantics plus current Asterisk PJSIP documentation reviewed September 27, 2026; no proxy, PBX, carrier, dialplan, route or live request tested

SIP 483 Too Many Hops

The request reached a server with Max-Forwards at zero. Preserve the responding hop and request path before treating the result as a routing loop.

Read guide →
SIP response reference

SIP 486 Busy Here

The called endpoint is busy at this location. This is a normal possible call outcome and does not assert that every possible destination is unavailable.

Read guide →
Reference · IETF RFC 3261 and current Asterisk PJSIP troubleshooting, logging and call-flow test documentation reviewed September 28, 2026; no endpoint, PBX, proxy, provider, timer, fork or live call tested

SIP 487 Request Terminated: trace the cancellation owner

Bind 487 to the original pending request, then find the matching CANCEL, expiry or dialog termination without treating a normal abandoned call as a carrier fault.

Read guide →
SIP response reference

SIP 488 Not Acceptable Here

The proposed session parameters cannot be accepted at this destination. In voice deployments, media negotiation is a useful first area to investigate.

Read guide →
SIP response reference

SIP 500 Server Internal Error

The server encountered an unexpected condition that prevented it from completing the request. The response is a starting point for server-side evidence.

Read guide →
SIP response reference · IETF RFC 3261, RFC 4475 and current Asterisk PJSIP troubleshooting and hangup-cause documentation reviewed September 28, 2026; no endpoint, PBX, proxy, provider, method, module, transaction or live call was tested

SIP 501 Not Implemented: identify the unsupported function

Bind 501 to the exact method, responder and transaction before deciding whether the function is unknown, unavailable on that SIP leg or incorrectly invoked.

Read guide →
SIP response reference

SIP 502 Bad Gateway

A gateway or proxy received an invalid response from a downstream server while attempting to fulfill the request. The problematic interaction can be beyond your endpoint.

Read guide →
SIP response reference

SIP 503 Service Unavailable

The server cannot currently handle the request, for example because of temporary overload or maintenance. The response may include Retry-After guidance.

Read guide →
SIP response reference

SIP 504 Server Time-out

A server did not receive a timely response from an external server it accessed while processing the request. The waiting component and downstream dependency matter.

Read guide →
SIP response reference · IETF RFC 3261 and current Asterisk hangup-cause, PJSIPHangup, Dial, HANGUPCAUSE and PJSIP diagnostic documentation reviewed September 28, 2026; no endpoint, PBX, proxy, provider, busy policy, dialplan, voicemail route or live call tested

SIP 600 Busy Everywhere

The callee is busy and the responder knows that no other endpoint, including voicemail, will answer this request.

Read guide →
SIP response reference

SIP 603 Decline

The called party or responsible system explicitly declines the session under global-failure semantics. It is broader than a single endpoint reporting busy here.

Read guide →
SIP response reference · IETF RFC 3261 and current Asterisk hangup-cause, HANGUPCAUSE, PJSIPHangup and PJSIP diagnostic documentation reviewed September 28, 2026; no endpoint, PBX, proxy, provider, directory, number, route, dialplan or live request tested

SIP 604 Does Not Exist Anywhere

The responding server has authoritative information that the user in the Request-URI does not exist anywhere.

Read guide →
SIP response reference · IETF RFC 3261 and current Asterisk hangup-cause, PJSIP codec-negotiation, hangup inspection and PJSIP diagnostic documentation reviewed September 28, 2026; no endpoint, PBX, proxy, provider, codec, SDP, media path, dialplan or live request tested

SIP 606 Not Acceptable

The user's agent was reached, but the user cannot adequately support the described session and no other endpoint is expected to answer.

Read guide →
Reference · RFC 3261, RFC 3311 and RFC 6141; implementation behavior requires the loaded endpoint configuration and an exact-version trace

SIP 491 Request Pending: overlapping re-INVITE or UPDATE

Identify the same-dialog offer collision, distinguish 491 from the related 500 overlap case and verify the randomized retry.

Read guide →
Reference · SIP standards, including the RFC 6026 INVITE transaction update; implementation behavior requires an exact-version trace

SIP 422 Session Interval Too Small

Use Min-SE to diagnose a session-timer interval rejected during call establishment or refresh.

Read guide →
Reference · SIP standards, including the RFC 6026 INVITE transaction update; implementation behavior requires an exact-version trace

SIP 423 Interval Too Brief: rejected registration expiry

Find the registrar’s minimum binding lifetime and verify that the next registration honors it.

Read guide →
SIP response reference · RFC 3261 and RFC 5621 reviewed September 27, 2026; no user agent, proxy, PBX, request body or retry was tested

SIP 415 Unsupported Media Type

The server rejected a request because a required message body format, content encoding, language or body-handling context was unsupported.

Read guide →
SIP response reference · RFC 3261, RFC 6665 and RFC 4475 reviewed September 28, 2026; no user agent, notifier, subscription, request, response body or retry was tested

SIP 406 Not Acceptable

The responder could not generate a response body in any format allowed by the request's Accept header; bind it to the method and application before changing media policy.

Read guide →
SIP response reference · RFC 3261, RFC 5393 and RFC 7332 loop-detection semantics plus current Asterisk PJSIP and dialplan documentation reviewed September 28, 2026; no proxy, B2BUA, PBX, provider, route or live request tested

SIP 482 Loop Detected

A SIP element detected that the same routing calculation returned a request to itself; distinguish that loop from a legitimate spiral and Max-Forwards exhaustion.

Read guide →
SIP response reference · RFC 3261 section 21.4.22, RFC 4504 device requirements and current Asterisk PJSIP, dialplan and hangup-cause documentation reviewed September 28, 2026; no endpoint, PBX, proxy, provider, number plan, route or live request tested

SIP 484 Address Incomplete

The responding server considered the Request-URI incomplete. Preserve the exact request, responder and addressing policy before adding, stripping or retrying digits.

Read guide →
Reference · IETF RFC 3261 and current Asterisk hangup-cause and PJSIP documentation reviewed September 28, 2026; no endpoint, PBX, proxy, provider, directory, address, contact or live request tested

SIP 485 Ambiguous: preserve the possible target set

Treat 485 as an ambiguous Request-URI decision, preserve privacy controls and require a deliberate target choice rather than an automatic retry.

Read guide →
SIP response reference · RFC 6665 and current Asterisk PJSIP subscription documentation reviewed September 28, 2026; no notifier, subscriber, event package, resource, module or live transaction tested

SIP 489 Bad Event: verify the event package

Bind 489 to the exact SUBSCRIBE responder and Event token before changing presence, BLF, MWI or body-format settings.

Read guide →
SIP response reference · RFC 3261, the IANA SIP option-tag registry and current Asterisk PJSIP 100rel documentation reviewed September 28, 2026; no endpoint, proxy, PBX, option tag, request or live call tested

SIP 420 Bad Extension: inspect Require and Unsupported

Bind 420 to the exact request, responder and unsupported option tag before changing media, routing or generic SIP headers.

Read guide →
SIP response reference · RFC 3261, RFC 3262, the IANA SIP option-tag registry and current Asterisk PJSIP 100rel documentation reviewed September 28, 2026; no endpoint, PBX, proxy, option tag, request, provisional response or live call tested

SIP 421 Extension Required: inspect Supported and Require

Bind 421 to the exact request, user-agent server and required option tag before changing feature or media settings.

Read guide →
SIP response reference · RFC 6442 and current Asterisk geolocation documentation reviewed September 28, 2026; no endpoint, PBX, proxy, provider, location object, dereference, emergency route or live call tested

SIP 424 Bad Location Information: inspect Geolocation-Error

Bind 424 to the exact request, location value and Geolocation-Error code before changing emergency-routing or privacy policy.

Read guide →
SIP response reference · RFC 8876, the IANA SIP registry and current Asterisk PJSIP header and debugging documentation reviewed September 28, 2026; no sensor, aggregator, PBX, proxy, PSAP, CAP payload, emergency route or live alert tested

SIP 425 Bad Alert Message: inspect AlertMsg-Error

Bind 425 to one non-interactive emergency MESSAGE, its CAP alert and registered AlertMsg-Error before changing routing or body handling.

Read guide →
SIP response reference · RFC 8224, RFC 9410, the IANA SIP registry and current Asterisk STIR/SHAKEN documentation reviewed September 28, 2026; no PBX, endpoint, provider, certificate, Identity header, policy or live call tested

SIP 428 Use Identity Header: prove policy and signing authority

Bind 428 to one request, verifier and Identity policy before changing STIR/SHAKEN signing, attestation or caller-ID handling.

Read guide →
SIP response reference · RFC 8224, RFC 9410, the IANA SIP registry and current Asterisk STIR/SHAKEN documentation reviewed September 28, 2026; no PBX, verifier, provider, URL, certificate, cache, Identity header or live call tested

SIP 436 Bad Identity Info: trace credential retrieval

Bind 436 to every Identity credential reference and the verifier's failed retrieval evidence before changing trust or signing policy.

Read guide →
SIP response reference · RFC 8224, RFC 9410, the IANA SIP registry and current Asterisk STIR/SHAKEN documentation reviewed September 28, 2026; no PBX, verifier, provider, CA, certificate, CRL, algorithm, Identity header or live call tested

SIP 437 Unsupported Credential: separate trust from retrieval

Bind 437 to an acquired Identity credential, its trust chain and supported algorithms before changing CA or signature policy.

Read guide →
SIP response reference · RFC 8224, RFC 9410, the IANA SIP registry and current Asterisk STIR/SHAKEN documentation reviewed September 28, 2026; no PBX, verifier, provider, PASSporT, Identity header, signature or live call tested

SIP 438 Invalid Identity Header: validate the PASSporT

Preserve every Identity field and reconstruct its supported PASSporT before changing signing, transit or verification policy.

Read guide →
SIP response reference · IANA's SIP response-code registry, RFC 3892, RFC 6585, Skyetel's current SIP Registration limitations and Asterisk's current outbound-registration and diagnostic guidance were reviewed October 8, 2026; no provider account, PBX, registration object, referral, token, credential, request rate, response, retry timer, availability result or call was inspected or tested

SIP 429 Provide Referrer Identity

The registered SIP 429 asks for valid referrer identity; it is not HTTP 429 Too Many Requests, even when a provider reuses the number for a local registration policy.

Read guide →

Locate the response family

  1. 1xx ProvisionalRequest is progressing
  2. 2xx SuccessRequest succeeded
  3. 3xx RedirectionAnother destination
  4. 4xx Request failureInterpret this request
  5. 5xx Server failureServer could not fulfil
  6. 6xx Global failureFailure across destinations

Read the status with its request method and call leg. For example, 200 after REGISTER confirms a binding; it does not prove an INVITE succeeded.

Start with the request

A response code is not a complete root-cause report. Identify the request method and the call leg before interpreting it. A 200 to REGISTER does not mean an INVITE succeeded, and an initial authentication challenge can be normal.

Understand the classes

1xx responses describe provisional progress. 2xx indicate success for the relevant request. 3xx provide redirection. 4xx describe request failures, 5xx server failures and 6xx global failures under SIP semantics. Each specific code has its own meaning and operational context.

Follow intermediaries

A PBX can terminate one leg and create another. An upstream failure may be translated before the handset sees it. Keep a bounded sequence from both sides where available, including timestamps and sanitized identifiers.

Use the reference practically

Choose the observed code below for its meaning, diagnostic checks and common misinterpretations. The entries distinguish normal progress from failures and explain what the code cannot establish by itself. For a user-facing symptom without a clear response, start in troubleshooting.

Do not import HTTP names into SIP by number alone

SIP 429 is registered as Provide Referrer Identity, while HTTP 429 means Too Many Requests. A provider may document a local SIP reuse of the HTTP-style phrase, but the 429 diagnostic keeps that interface rule separate from the IANA SIP registry.

Verify the first final response when Asterisk rejects a call

For an incoming Asterisk PJSIP policy rejection, the PJSIPHangup diagnostic compares the requested 4xx–6xx code with the first final response, upstream rewrite and caller behavior.

A DIDWW response code and a rerouting trigger are not the same fact

DIDWW publishes destination and system response meanings, while the trunk group separately selects which disconnect codes trigger another member. Use the DIDWW trunk-group diagnostic to compare the observed result with the configured rerouting set.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Continue your research

Diagnostic · IANA's SIP response-code registry, RFC 3892, RFC 6585, Skyetel's current SIP Registration limitations and Asterisk's current outbound-registration and diagnostic guidance were reviewed October 8, 2026; no provider account, PBX, registration object, referral, token, credential, request rate, response, retry timer, availability result or call was inspected or tested

A provider returns SIP 429 Too Many Requests

Preserve the method, reason phrase and responder, then separate a provider-local registration throttle from SIP 429's registered referrer-identity meaning.

Read guide →
Guide · Current Asterisk branch 23 PJSIPHangup and Hangup application documentation, hangup-cause inspection and mapping guidance, and RFC 3261 reviewed October 14, 2026; PJSIPHangup is documented since Asterisk 18.21.0, 20.6.0 and 21.1.0, accepts a numeric 400 through 699 response or supported PJSIP response name, must run on an incoming PJSIP channel before any other final response, terminates dialplan execution and maps the selected SIP response into an Asterisk or ISDN cause, while installed release, loaded channel driver, channel direction, prior provisional or final responses, transaction state, mapping, upstream rewriting and caller behavior remain deployment specific; no PBX, module, dialplan, channel, request, response, cause, packet, endpoint, trunk or call was inspected or tested

Asterisk PJSIPHangup: return one final SIP response safely

Place one explicit 4xx, 5xx or 6xx final response on the incoming PJSIP transaction before answer, then keep SIP, translated cause and caller outcome separate.

Read guide →
Diagnostic · Current Asterisk branch 23 PJSIPHangup and Hangup application documentation, hangup-cause inspection and mapping guidance, and RFC 3261 reviewed October 14, 2026; PJSIPHangup is documented since Asterisk 18.21.0, 20.6.0 and 21.1.0, accepts a numeric 400 through 699 response or supported PJSIP response name, must run on an incoming PJSIP channel before any other final response, terminates dialplan execution and maps the selected SIP response into an Asterisk or ISDN cause, while installed release, loaded channel driver, channel direction, prior provisional or final responses, transaction state, mapping, upstream rewriting and caller behavior remain deployment specific; no PBX, module, dialplan, channel, request, response, cause, packet, endpoint, trunk or call was inspected or tested

Asterisk PJSIPHangup returns the wrong response or 200 was already sent

Find the first final SIP response, prove the current channel and application availability, then correct one policy or timing owner without rewriting evidence after answer.

Read guide →
Troubleshooting · DIDWW failover, trunk-group and response-code documentation updated October 7–8, 2026 was reviewed October 14, 2026; it documents priority, weight, ringing timeout, selected re-routing disconnect codes, capacity controls, DNS SRV and a separate CDR for each routing attempt, but no account, DID, trunk group, endpoint, DNS answer, capacity state, request, response, CDR stream, failover event, media stream or live call was inspected or tested

DIDWW inbound trunk group does not try the next trunk

Prove DID assignment, trunk-group membership, priority and weight, the configured rerouting-code set, ringing timeout, capacity and every DIDWW CDR attempt before changing a working inbound route.

Read guide →