When you attempt a call between two networks, SIP response codes convey important information.
Session Initiation Protocol (SIP) is a call and response protocol used to initiate, maintain, and terminate multimedia sessions within VoIP applications. Simply put, these internet-hosted multimedia sessions can integrate voice, video, and messaging into a call. SIP response codes are three-digit numerical messages that contain information sent by the User Agent Server (UAS) to the User Agent Client (UAC). SIP response codes provide information about the status of the call.
There are six SIP response code class types. The first digit of each code indicates the class of the code. Codes beginning with the number 1 are known as "provisional" codes, and codes beginning with numbers 2-6 are known as "final" codes. Provisional SIP codes are sent up until a call is connected; final codes confirm whether or not the connection was successful.
Related articles
"SIP response codes are the language of communication systems, enabling efficient and effective call management. By understanding these codes, businesses can proactively address issues, ensure smoother call operations, and provide a better experience for their customers."
— Bandwidth Communications, Enterprise VoIP Solutions Provider
You don't need to memorize the different types of SIP codes, but it can be helpful to have a reference sheet handy and a general idea of what each code indicates. For detailed troubleshooting guidance, consult the Telnyx SIP Response Codes documentation and the SIP Trunking Methods/Requests & Responses guide. Here are the most common types of SIP response codes:
A 1xx SIP response code can be sent at any time while a connection is being established. According to RFC 3261, the core SIP specification maintained by the IETF, provisional responses indicate that the server is performing further action and does not yet have a definitive response. Here are some common 1xx codes:
A call request has been received, and an unspecified action (such as consulting a database) is being taken on behalf of the call request.
An invite has been received by the User Agent Server (UAS), which is now attempting to alert the user.
The SIP call is being forwarded to another endpoint.
Provides information about the progress of a SIP call.
Notifies upstream SIP entities that an early dialog has been terminated.
The 2xx response codes are used to indicate that a SIP request has been successfully received, understood, and accepted. You'll typically see the following versions:
A request has succeeded.
A UAS has received and understood the request, but it may not have been authorized or processed by the server.
A request was successful, but a response will not be received.
These codes inform the User Agent Client (UAC) about redirections and the different routes available to get to the UAS. When building cloud IVR systems or custom call flows, understanding redirection codes helps you create intelligent routing logic. Commonly received examples include:
A request address returned several choices, each with their own specific locations. In this case, the UA can select a preferred endpoint to redirect the request to that specific location.
A user can no longer be found at the address used in the request. A new address will be given in the contact header field, which can be retried by the requesting client. The new address should be saved and used in all future invite requests.
A new address will be given in the contact header field, which can be retried by the requesting client. This address should not be saved for future invite requests.
A proxy must be used to access the required destination. The specified proxy will be displayed in the contact field.
The call failed, but the message body describes alternatives.
The 4xx response codes indicate that something went wrong while processing the message, and the request cannot be fulfilled. Understanding these error codes is essential for troubleshooting SIP issues effectively. There are quite a few client error SIP response codes, including:
A request could not be understood.
A request requires user authentication.
The server understood the request, but is refusing to fulfill it.
A server has definitive information that the user does not exist at that particular domain.
Similar to the 401 (not authorized) code, but in this case the client must authenticate itself with the proxy.
A server could not produce a response within a suitable time frame.
A server is refusing to service the request because the message body is in a format not supported by the server for the particular request method.
The callee's end system was contacted successfully but the callee is busy.
The request was terminated by the user or the server before completion.
The request was not acceptable due to issues with the media capabilities offered in the SDP (Session Description Protocol).
5xx responses relate to server error issues and are mostly generated by proxy servers, location servers, and redirect servers. The SIP trunking architecture involves multiple server types, and understanding these errors helps identify where issues originate. They include:
A server was prevented from fulfilling the request by an unexpected condition.
A functionality required to fulfill the request is not supported by the server.
When attempting to fulfill the request, a server received an invalid response from a downstream server.
Temporary overloading or maintenance of a server means it is currently unable to process the request. The client should attempt to forward the request to another server.
When attempting to process the request, a server did not receive a timely response from the external server.
The SIP protocol version in the request is not supported by the server.
Finally, the 6xx response codes relate to global failure issues, meaning the request cannot be fulfilled at any server. They include:
A callee's end system was contacted successfully but the callee is busy.
A callee's end system was successfully contacted but the user does not wish to or cannot participate.
Information the user indicated in the request Uniform Resource Identifier (URI) does not exist.
A user wishes to communicate, but they cannot adequately support the session described.
The called party did not want this call from the calling party.
The call has been rejected by the carrier, often due to fraud prevention measures.
"SIP drove the transition in telecommunications from hardware to software, based on IP technologies. The protocol's response codes provide invaluable diagnostic information that can be used to enhance the overall quality and reliability of communication services."
— Jonathan Rosenberg, Primary Author of RFC 3261 and CTO at Five9. Rosenberg is recognized as a pioneer in VoIP development and was named one of MIT Technology Review's top innovators under 35.
The codes listed above are the most common codes, but there are additional codes you may encounter. For developer implementation details, refer to the Telnyx SIP Trunking Quickstart and Configuration Guides:
| Response | Status |
|---|---|
| 182 | Queued |
| 402 | Payment Required |
| 403 | Forbidden |
| 405 | Method Not Allowed |
| 406 | Not Acceptable |
| 410 | Gone |
| 411 | Length Required |
| 412 | Conditional Request Failed |
| 413 | Request Entity Too Large |
| 414 | Request URI Too Long |
| 416 | Unsupported URI Scheme |
| 417 | Unknown Resource Priority |
| 420 | Bad Extension |
| 421 | Extension Required |
| 422 | Session Interval Too Small |
| 423 | Interval Too Brief |
| 424 | Bad Location Information |
| 425 | Bad Alert Message |
| 428 | Use Identity Header |
| 429 | Provide Referrer Identity |
| 430 | Flow Failed |
| 433 | Anonymity Disallowed |
| 436 | Bad Identity Info |
| 437 | Unsupported Certificate |
| 438 | Invalid Identity Header |
| 439 | First Hop Lacks Outbound Support |
| 440 | Max Breadth Exceeded |
| 469 | Bad Info Package |
| 470 | Consent Needed |
| 480 | Temporarily Unavailable |
| 481 | Call/Transaction Does Not Exist |
| 482 | Loop Detected |
| 483 | Too Many Hops |
| 484 | Address Incomplete |
| 485 | Ambiguous |
| 486 | Busy Here |
| 487 | Request Terminated |
| 488 | Not Acceptable Here |
| 489 | Bad Event |
| 491 | Request Pending |
| 493 | Undecipherable |
| 494 | Security Agreement Required |
| 505 | Version Not Supported |
| 513 | Message Too Large |
| 555 | Push Notification Service Not Supported |
| 580 | Precondition Failure |
| 607 | Unwanted |
| 608 | Rejected |
SIP, together with VoIP, enables businesses to build customized telephony systems. SIP trunks reduce the amount of infrastructure your business needs: you can add many channels to a single SIP trunk, which allows you to have multiple phone lines. Without SIP trunks, you'd need to pay for individual lines each time you hired a new employee. SIP protocol and SIP trunking features enhance your VoIP system to create a robust, scalable, and flexible communication solution for your business.
For businesses looking to leverage SIP technology, understanding the relationship between SIP trunking and DID numbers is essential for proper configuration. You can also learn more about common SIP terms and their meanings to better understand the VoIP ecosystem.
Contact our team of experts to learn how SIP trunking can transform your business communications.
Want help decoding SIP response codes? Join our subreddit.
