SIP Cause Codes — Complete Reference
Every standard SIP response code defined in RFC 3261 and subsequent RFCs, with plain-language explanations and troubleshooting tips. Use the search and category filters above to find what you need quickly.
1xx
Provisional Responses
Informational — the request is being processed100
Trying
The next-hop server has received the INVITE and is working to route the call. This provisional response stops the UAC from retransmitting the INVITE under UDP and indicates the request has entered the network.
Tip: If you never see a 100 Trying, check that your INVITE is reaching the proxy. Firewall or DNS resolution failures are the usual culprits.
180
Ringing
The called party's user agent has located the user and is alerting them (phone ringing). The calling party should hear a ringback tone at this point. No SDP is required in this response.
Tip: Long delays before 180 typically point to slow DNS lookups or overloaded proxies in the signalling path.
181
Call Is Being Forwarded
The called party has set up call forwarding and the proxy is redirecting the INVITE to another destination. The caller may optionally hear a special information tone or announcement.
Tip: Verify the forwarding destination is valid. Chains of forwards can cause 483 Too Many Hops if the Max-Forwards counter expires.
182
Queued
The called party is temporarily unavailable but the server has queued the call rather than rejecting it. The call will be connected when the callee becomes available, or rejected after a timeout.
Tip: Common in call-centre ACD queues. Monitor queue depth and timeout settings to avoid callers waiting indefinitely.
183
Session Progress
Conveys information about the progress of the call. Often carries an SDP body to establish an early media path so the caller hears in-band audio (custom ringback, IVR prompts, announcements) before the call is answered.
Tip: If early media is not playing, confirm the 183 contains an SDP answer and that your endpoint supports early media negotiation.
199
Early Dialog Terminated
Sent by a UAS to indicate that an early dialog has been terminated. Defined in RFC 6228, it allows the UAC to release resources associated with early dialogs that will never transition to established dialogs.
Tip: Useful in forked INVITE scenarios. Ensure your UAC properly handles this response to free up media resources for terminated forks.
2xx
Success Responses
The request was successfully received, understood, and accepted200
OK
The request has succeeded. For INVITE, this means the callee has accepted the call and the response contains an SDP answer. The UAC must send an ACK to complete the three-way handshake and establish the dialog.
Tip: If audio is one-way after a 200 OK, the issue is almost always in the SDP media negotiation or NAT traversal — not the signalling.
202
Accepted
The request has been accepted for processing, but the processing has not yet been completed. Used with REFER requests (RFC 3515) to indicate the REFER was accepted and a NOTIFY will follow with the outcome.
Tip: After receiving 202, the referrer should wait for NOTIFY messages with the subscription state. The actual transfer result is conveyed in those NOTIFYs.
204
No Notification
Defined in RFC 5839, this response indicates that the request was successful but the subscriber has indicated it does not wish to receive NOTIFY requests for this subscription. Reduces unnecessary signalling traffic.
Tip: Used in event subscription scenarios to suppress NOTIFYs. Confirm both endpoints support RFC 5839 before relying on this behaviour.
3xx
Redirection Responses
Further action is needed to complete the request300
Multiple Choices
The address resolved to several choices, each with its own specific location. The user or UAC can select a preferred contact from the Contact header field list and redirect the request to that URI.
Tip: Present the options to the user or implement a selection algorithm. The q-value parameter in each Contact header indicates relative preference.
301
Moved Permanently
The user can no longer be found at the Request-URI address. The Contact header provides the new permanent URI. The client should update any address books or cached routes and retry the request at the new address.
Tip: Update the AOR-to-contact binding in your registrar or routing tables. Continuing to send to the old URI will keep generating 301s.
302
Moved Temporarily
The callee has temporarily moved to a different URI provided in the Contact header. The client should retry the request at the new address but continue to use the original URI for future requests.
Tip: Commonly used for call forwarding. Do not cache the redirect permanently — the Expires parameter (if present) tells you how long it is valid.
305
Use Proxy
The requested resource must be accessed through the proxy specified in the Contact header. The UAC should direct the same request to the indicated proxy server instead of the destination directly.
Tip: Ensure the proxy in the Contact header is reachable and the UAC is configured to follow 305 redirects. Some endpoints ignore this response.
380
Alternative Service
The call was not successful, but alternative services are possible. The body of the response contains a description of the alternatives, typically indicating a different communication method or service.
Tip: Rarely seen in practice. Check the response body for an XML or text description of available alternative services the caller may use.
4xx
Client Error Responses
The request contains bad syntax or cannot be fulfilled by this server400
Bad Request
The request could not be understood due to malformed syntax. The Reason phrase may provide more detail. The client should not repeat the request without modifications to the message structure.
Tip: Capture a packet trace and inspect the SIP message for malformed headers, missing mandatory fields, or encoding errors. Check the Warning header if present.
401
Unauthorized
The request requires user authentication. The UAS or registrar includes a WWW-Authenticate header with a challenge. The UAC must retry the request with a valid Authorization header containing the correct credentials.
Tip: Verify username, password, and authentication realm. A 401 on REGISTER usually means bad credentials; on INVITE it may mean your proxy requires authentication for outbound calls.
403
Forbidden
The server understood the request but refuses to fulfil it. Unlike 401, providing credentials will not help. The request should not be repeated. This often indicates an ACL or policy-based rejection.
Tip: Check server-side ACLs, IP whitelists, calling plan restrictions, or codec policy. The Reason header may contain additional detail about the rejection.
404
Not Found
The user does not exist at the domain specified in the Request-URI. The server has definitive information that the user does not exist. This is different from 480 (temporarily unavailable) where the user may return.
Tip: Confirm the dialled number or SIP URI is correct. Check the registrar to see if the user/extension has been provisioned and is registered.
405
Method Not Allowed
The method specified in the Request-Line (e.g., INFO, MESSAGE, UPDATE) is not allowed for the address identified by the Request-URI. An Allow header field listing the valid methods should be present in the response.
Tip: Check the Allow header in the response to see which methods are supported. Common when sending MESSAGE or REFER to endpoints that only handle INVITE/REGISTER.
406
Not Acceptable
The resource identified by the request is only capable of generating responses with content characteristics that are not acceptable according to the Accept headers sent in the request.
Tip: Examine the Accept, Accept-Encoding, and Accept-Language headers in your request. Adjust them to match the content types the server can provide.
407
Proxy Authentication Required
Similar to 401, but indicates the client must first authenticate with the proxy. The proxy sends a Proxy-Authenticate header with a challenge. The UAC retries with a Proxy-Authorization header.
Tip: Check proxy credentials (may differ from registrar credentials). Ensure your UAC handles the Proxy-Authenticate challenge/response cycle correctly.
408
Request Timeout
The server could not produce a response within a suitable amount of time. The client did not produce a request within the time the server was prepared to wait. The client may repeat the request without modification.
Tip: Usually means the destination UAS is unreachable or unresponsive. Check network connectivity, firewall rules, and whether the callee device is online and registered.
410
Gone
The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be permanent. Unlike 404, the server knows the resource previously existed here.
Tip: The user or resource was explicitly deprovisioned. Remove it from your routing tables. Contact the domain administrator to verify the account status.
412
Conditional Request Failed
Defined in RFC 3903, the server cannot fulfil the request because a precondition (e.g., an If-Match header) was not met. Used with SIP PUBLISH to ensure event state is updated atomically using entity-tags.
Tip: Refresh the entity-tag by issuing a new PUBLISH without an If-Match header, then use the returned SIP-ETag for subsequent conditional updates.
413
Request Entity Too Large
The server refuses to process the request because the message body is larger than the server is willing or able to handle. The SDP, XML body, or other payload exceeds the configured size limit.
Tip: Reduce the size of the message body. If sending large SDP with many codec lines, trim unnecessary codecs. Check the server's max message size configuration.
414
Request-URI Too Long
The server refuses to process the request because the Request-URI is longer than the server is willing to interpret. This is rare in SIP but can occur with heavily parameterised URIs.
Tip: Simplify the Request-URI by removing unnecessary parameters. If a proxy is appending routing information to the URI, check its configuration.
415
Unsupported Media Type
The server does not support the content type of the message body, or the content encoding or content language is not acceptable. The Accept header in the response shows what content types are supported.
Tip: Ensure Content-Type is set to application/sdp for INVITE or the appropriate MIME type for the payload. Check the Accept header in the response for supported types.
416
Unsupported URI Scheme
The server cannot process the request because the URI scheme in the Request-URI is not one it understands. For example, using a tel: URI when the server only handles sip: or sips: schemes.
Tip: Convert the URI to a supported scheme (e.g., tel: to sip: with user=phone parameter) or route through a gateway that handles the translation.
417
Unknown Resource-Priority
The server does not understand the Resource-Priority header namespace or priority value in the request (RFC 4412). The request used a priority level that the network does not recognise or support.
Tip: Verify the Resource-Priority namespace and value are valid for your network. This header is used in emergency services (GETS/WPS) and priority call networks.
420
Bad Extension
The server did not understand a protocol extension specified in a Require or Proxy-Require header. The Unsupported header in the response lists the extensions that are not supported.
Tip: Move the extension from Require to Supported header if it is optional, or upgrade the server to support the required extension. Check the Unsupported header in the response.
421
Extension Required
The UAS needs a particular extension to process the request, but the extension is not listed in the Supported header of the request. The Require header in the response lists the needed extensions.
Tip: Add the extension listed in the response's Require header to your request's Supported header, or ensure your UAC can handle the extension.
422
Session Interval Too Small
The Session-Expires value in the request is too small for the server (RFC 4028). The response contains a Min-SE header indicating the minimum session timer interval the server will accept.
Tip: Increase your Session-Expires value to at least the Min-SE value returned in the 422 response. Typical minimum is 90 seconds; many networks require 1800 seconds.
423
Interval Too Brief
The registration expiration time in the REGISTER request is too short. The response contains a Min-Expires header indicating the minimum registration interval the registrar will accept.
Tip: Increase the Expires value in your REGISTER to match or exceed the Min-Expires value in the 423 response. Common minimum is 60–3600 seconds.
424
Bad Location Information
Defined in RFC 6442, the request contained location information (Geolocation header) that was malformed, unreachable, or otherwise unusable by the server for location-based routing (e.g., emergency calls).
Tip: Validate the PIDF-LO XML document referenced in the Geolocation header. Ensure the location URI is reachable and the format conforms to RFC 4119.
428
Use Identity Header
The server requires an Identity header (RFC 8224 / STIR-SHAKEN) to process the request. The request was sent without caller identity verification, which the network policy mandates.
Tip: Configure your originating SBC or proxy to add a STIR/SHAKEN Identity header with a valid PASSporT token signed by a trusted certificate authority.
429
Provide Referrer Identity
The server requires a valid Referred-By token (RFC 3892) for the REFER request. The server needs to verify the identity of the party initiating the call transfer for security or policy reasons.
Tip: Include a signed Referred-By header in your REFER request. The token allows the recipient to verify the identity of the entity that initiated the transfer.
430
Flow Failed
Defined in RFC 5626 (SIP Outbound), a specific flow to a user agent instance has failed. The proxy could not deliver the request over the registered flow (persistent connection) to the target UA.
Tip: The UA should re-register using a new flow (connection). Check NAT keep-alive intervals and ensure the persistent TCP/TLS connection has not been dropped.
433
Anonymity Disallowed
The request was rejected because it was anonymous (Privacy header set to id or header). The server or network policy requires caller identification and does not allow anonymous calls.
Tip: Remove the Privacy header or set it to "none". Some networks (emergency services, regulatory compliance) require full caller identification.
436
Bad Identity-Info
The Identity-Info header in the request contains a URI that the server cannot dereference to obtain the certificate for validating the Identity header. The certificate URL is unreachable or invalid.
Tip: Ensure the URI in the Identity-Info header is publicly accessible via HTTPS and returns a valid X.509 certificate. Check for DNS and TLS issues.
437
Unsupported Certificate
The server obtained the certificate from the Identity-Info URI but cannot validate it. The certificate may be self-signed, expired, revoked, or issued by an untrusted certificate authority.
Tip: Use a certificate issued by a trusted STIR/SHAKEN CA. Verify the certificate chain is complete, the certificate has not expired, and it is not on any revocation list.
438
Invalid Identity Header
The Identity header signature is invalid. The server retrieved the certificate and checked the signature but it does not match the request content. The request may have been tampered with in transit.
Tip: Ensure no intermediate proxies are modifying signed headers after the Identity signature is applied. Regenerate the signature if the From header or other signed fields change.
439
First Hop Lacks Outbound Support
Defined in RFC 5626, the UA attempted to use SIP Outbound (registering with the outbound option-tag) but the first proxy in the path does not support the outbound mechanism.
Tip: Either upgrade the first-hop proxy to support RFC 5626, or disable the outbound option in the UA's registration and rely on standard registration with NAT keep-alives.
440
Max-Breadth Exceeded
Defined in RFC 5765, the request would have caused the server to fork to more targets than the Max-Breadth header allows. This prevents amplification attacks from excessively forking requests.
Tip: Increase the Max-Breadth value in the request if legitimate, or review the routing configuration to reduce the number of forked destinations.
469
Bad Info Package
Defined in RFC 6086, the INFO request references an Info Package that the server does not support or recognise. The Recv-Info header in the response lists the acceptable Info Packages.
Tip: Check the Recv-Info header in the response to see which Info Packages are supported. Ensure both sides have negotiated Info Package support during dialog setup.
470
Consent Needed
Defined in RFC 5360, the request cannot be processed because the source has not been granted permission (consent) by the relay to send requests to the target URI. A consent-based communication framework is in use.
Tip: The sender must obtain consent from the relay's permissions document. Follow the URI in the response to initiate the consent process before retrying.
480
Temporarily Unavailable
The callee's endpoint is valid but currently not reachable — the device is offline, has DND enabled, or the user is temporarily away. The Retry-After header may indicate when to retry.
Tip: The most common "can't reach the phone" error. Verify the callee's device is online, registered, and not in Do Not Disturb mode. Check NAT/firewall for registration expiry.
481
Call/Transaction Does Not Exist
The UAS received a request that does not match any existing dialog or transaction. This typically happens when a BYE or re-INVITE is sent for a call that the server no longer has state for (e.g., after a restart).
Tip: Check Call-ID, From-tag, and To-tag for consistency. This often occurs after server failover or when a dialog has already been terminated by the other side.
482
Loop Detected
The server detected a routing loop — the request was received at a proxy that had already forwarded it. The server detected its own address in the Via header, indicating a circular routing path.
Tip: Review your proxy's routing rules for circular references. Check dial plans, call forwarding chains, and ensure the proxy adds its Via header before forwarding.
483
Too Many Hops
The Max-Forwards header reached zero before the request arrived at its destination. Each proxy decrements this counter, and at zero the request is rejected to prevent infinite loops.
Tip: Default Max-Forwards is 70. If you hit this, you likely have a routing loop. Trace the Via headers to find which proxies are involved in the loop.
484
Address Incomplete
The Request-URI was incomplete — the dialled number does not have enough digits for the dial plan to route it. The server may send overlap dialling information or expect additional digits.
Tip: The user likely dialled too few digits. Check the dial plan pattern matching. In ISDN/SIP interworking, ensure overlap dialling is handled correctly.
485
Ambiguous
The Request-URI is ambiguous — the address resolved to multiple users and the server cannot determine which one was intended. The response may contain a list of possible matches in Contact headers.
Tip: Use a more specific URI or select from the alternatives provided in the Contact headers of the response. Review your user provisioning for duplicate entries.
486
Busy Here
The callee's endpoint was contacted successfully but the user is currently busy and does not wish to take the call at this time. The caller should receive a busy tone. The user may be available at other endpoints.
Tip: This is a per-device busy signal (unlike 600 Busy Everywhere). Check if call waiting is disabled. Consider routing to voicemail or an alternative endpoint on busy.
487
Request Terminated
The request was terminated by a CANCEL from the client or by a BYE. This is a normal response that confirms the INVITE transaction was properly cancelled before it was answered. Not an error condition.
Tip: This is expected behaviour when the caller hangs up before the call is answered. If unexpected, check for SIP timers or call-control logic sending premature CANCELs.
488
Not Acceptable Here
The request was understood but the specific resource cannot accept it because one or more aspects (codec, bandwidth, encryption) are not acceptable. A Warning header or SDP in the response may describe what is acceptable.
Tip: The most common codec mismatch error. Check the SDP offer/answer for a common codec. Ensure at least one audio codec (e.g., G.711 PCMU/PCMA) is offered by both sides.
489
Bad Event
The server does not understand the event package specified in the Event header of a SUBSCRIBE or NOTIFY request (RFC 6665). The Allow-Events header in the response lists supported event packages.
Tip: Check the Allow-Events header in the response. Common event packages include "message-summary" (voicemail MWI), "presence", "dialog", and "refer".
491
Request Pending
The server received a request (typically a re-INVITE) while it was still processing a previous request in the same dialog. SIP does not allow overlapping transactions within a dialog, so the new request is rejected.
Tip: Implement the retry mechanism from RFC 3261 section 14.1: wait a random time (0–2 seconds for the UAC, 2.1–4 seconds for the UAS) before retrying the re-INVITE.
493
Undecipherable
The request contained an S/MIME encrypted body that the server cannot decrypt. The server may lack the private key, the encryption algorithm is unsupported, or the encrypted content is corrupted.
Tip: Verify the recipient's public key/certificate is correct and current. Ensure both sides support the same S/MIME encryption algorithms and have exchanged valid certificates.
494
Security Agreement Required
Defined in RFC 3329, the server requires a security mechanism agreement before processing the request. The response contains a Security-Server header listing the server's supported security mechanisms.
Tip: Include a Security-Client header in your request listing your supported mechanisms (e.g., tls, digest, ipsec-3gpp) and negotiate with the Security-Server values in the response.
5xx
Server Error Responses
The server failed to fulfil an apparently valid request500
Server Internal Error
The server encountered an unexpected condition that prevented it from fulfilling the request. This is a generic catch-all error indicating a software bug, misconfiguration, or resource exhaustion on the server.
Tip: Check the server logs for stack traces or error details. Common causes include database failures, out-of-memory conditions, and unhandled exceptions in routing scripts.
501
Not Implemented
The server does not support the functionality required to fulfil the request. The SIP method (e.g., PRACK, UPDATE, INFO) is recognised but not implemented on this server.
Tip: Unlike 405 (method not allowed for a specific URI), 501 means the entire server lacks support for the method. Upgrade the server software or use an alternative method.
502
Bad Gateway
The server, acting as a gateway or proxy, received an invalid response from a downstream server. The response from the next hop was malformed, unrecognisable, or violated the SIP protocol.
Tip: Investigate the downstream server. Capture a trace at the proxy to see the malformed response it received. Check for SIP/protocol version mismatches between peers.
503
Service Unavailable
The server is temporarily unable to process the request due to overloading or maintenance. A Retry-After header may indicate when the service will be available. The request may succeed if retried later.
Tip: The most critical server error in production. Monitor server CPU, memory, and session counts. Implement SIP overload controls (RFC 7339) and failover to backup servers.
504
Server Time-out
The server did not receive a timely response from a downstream server it accessed while attempting to process the request. This is the proxy/gateway equivalent of 408 Request Timeout.
Tip: Check connectivity to downstream servers. Verify DNS resolution and ensure the downstream peer is operational. Adjust Timer C (proxy INVITE transaction timeout) if needed.
505
Version Not Supported
The server does not support the SIP protocol version specified in the request line. The only standardised version is SIP/2.0. This error indicates a malformed request line or a non-SIP protocol being sent.
Tip: Ensure the request line reads "SIP/2.0". This error sometimes appears when non-SIP traffic (e.g., HTTP) is sent to a SIP port by mistake.
513
Message Too Large
The message length exceeds the maximum the server can process. Unlike 413 (which is about the body), 513 refers to the entire SIP message including headers. Common over UDP where messages exceeding the MTU must use TCP.
Tip: Switch to TCP or TLS transport for large messages. If using UDP, reduce the number of headers, Via entries, or Record-Route entries. RFC 3261 recommends TCP for messages over 1300 bytes.
555
Push Notification Service Not Supported
Defined in RFC 8599, the server does not support the push notification service (PNS) identified in the request. Used in mobile VoIP where devices rely on push notifications (APNs, FCM) to wake up for incoming calls.
Tip: Verify the pn-provider, pn-param, and pn-prid parameters in the Contact header match a push service the server supports. Ensure server-side push configuration is complete.
580
Precondition Failure
The server is unable or unwilling to meet some of the preconditions specified in the request (RFC 3312). Quality-of-service resource reservation or other preconditions for the session could not be satisfied.
Tip: Check QoS resource availability. If using preconditions for bandwidth reservation (e.g., in IMS networks), ensure the PCRF/policy server grants the required resources.
6xx
Global Failure Responses
The request cannot be fulfilled at any server600
Busy Everywhere
The callee is busy and does not wish to take the call at this time. Unlike 486 (Busy Here) which applies to one device, 600 means the user is busy on all registered endpoints and no alternative should be tried.
Tip: The caller should hear a busy tone. No point trying alternative contacts. Route to voicemail or implement callback functionality if available.
603
Decline
The callee's machine was successfully contacted but the user explicitly does not wish to or cannot participate. The Retry-After header may indicate a better time to call. This is a deliberate rejection.
Tip: The user actively rejected the call (pressed "Decline"). This is intentional — do not retry automatically. Route to voicemail or provide feedback to the caller.
604
Does Not Exist Anywhere
The server has authoritative information that the user indicated in the Request-URI does not exist anywhere in the network. This is the global version of 404 — no other server should be tried.
Tip: The number/URI is definitively invalid network-wide. Verify the destination address. If porting a number, ensure the routing database has been updated across all carriers.
606
Not Acceptable
The user's agent was contacted successfully but some aspects of the session description (codecs, bandwidth, media types) are not acceptable. A Warning header or body describes what is unacceptable. Unlike 488, this is global — no other endpoint will work.
Tip: Check the Warning header for specific issues. Ensure your SDP offers a broad set of standard codecs. This often occurs when only wideband codecs are offered to a narrowband-only network.
607
Unwanted
Defined in RFC 8197, the callee or a network element acting on their behalf has determined that the call is unwanted (spam, robocall). This provides explicit feedback to the network that the call was not welcome.
Tip: This response feeds into call analytics and reputation systems. If your legitimate calls receive 607, check your STIR/SHAKEN attestation level and caller ID reputation.
608
Rejected
Defined in RFC 8688, an intermediary (such as an analytics engine or call-blocking service) has rejected the call on behalf of the callee. The call was blocked by a network-level call screening service before reaching the user.
Tip: Unlike 607 (user feedback), 608 is a network-level block. Check if your originating number is on a blocklist, verify STIR/SHAKEN attestation, and review your calling patterns for spam-like behaviour.
No SIP codes match your search. Try a different code number or keyword.