List of SIP response codes

Last updated

The Session Initiation Protocol (SIP) is a signaling protocol used for controlling communication sessions such as Voice over IP telephone calls. SIP is based on request/response transactions, in a similar manner to the Hypertext Transfer Protocol (HTTP). Each transaction consists of a SIP request (which will be one of several request methods), and at least one response. [1] : p11 

Contents

SIP requests and responses may be generated by any SIP user agent; user agents are divided into clients (UACs), which initiate requests, and servers (UASes), which respond to them. [1] : §8  A single user agent may act as both UAC and UAS for different transactions: [1] : p26  for example, a SIP phone is a user agent that will be a UAC when making a call, and a UAS when receiving one. Additionally, some devices will act as both UAC and UAS for a single transaction; these are called Back-to-Back User Agents (B2BUAs). [1] : p20 

SIP responses specify a three-digit integer response code, which is one of a number of defined codes that detail the status of the request. These codes are grouped according to their first digit as "provisional", "success", "redirection", "client error", "server error" or "global failure" codes, corresponding to a first digit of 1–6; these are expressed as, for example, "1xx" for provisional responses with a code of 100–199. [1] : §7.2  The SIP response codes are consistent with the HTTP response codes, although not all HTTP response codes are valid in SIP. [1] : §21 

SIP responses also specify a "reason phrase", and a default reason phrase is defined with each response code. [1] : §7.2  These reason phrases can be varied, however, such as to provide additional information [1] : §21.4.18  or to provide the text in a different language. [1] : §20.3 

The SIP response codes and corresponding reason phrases were initially defined in RFC 3261. [1] That RFC also defines a SIP Parameters Internet Assigned Numbers Authority (IANA) registry to allow other RFC to provide more response codes. [1] : §27  [2]

This list includes all the SIP response codes defined in IETF RFCs and registered in the SIP Parameters IANA registry as of 27 January 2023. This list also includes SIP response codes defined in obsolete SIP RFCs (specifically, RFC 2543), which are therefore not registered with the IANA; these are explicitly noted as such.

SIP responses may also include an optional Warning header, containing additional details about the response. The Warning contains a separate three-digit code followed by text with more details about the warning. [1] : §20.43  The current list of official warnings is registered in the SIP Parameters IANA registry.

1xx—Provisional Responses

100 Trying
Extended search being performed may take a significant time so a forking proxy must send a 100 Trying response. [1] : §21.1.1 
180 Ringing
Destination user agent received INVITE, and is alerting user of call. [1] : §21.1.2 
181 Call is Being Forwarded
Servers can optionally send this response to indicate a call is being forwarded. [1] : §21.1.3 
182 Queued
Indicates that the destination was temporarily unavailable, so the server has queued the call until the destination is available. A server may send multiple 182 responses to update progress of the queue. [1] : §21.1.4 
183 Session Progress
This response may be used to send extra information for a call which is still being set up. [1] : §21.1.5 
199 Early Dialog Terminated
Can be used by User Agent Server to indicate to upstream SIP entities (including the User Agent Client (UAC)) that an early dialog has been terminated. [3]

2xx—Successful Responses

200 OK
Indicates that the request was successful. [1] : §21.2.1 
202 Accepted
Indicates that the request has been accepted for processing, but the processing has not been completed. [4] : §7.3.1  [5] Deprecated. [6] : §8.3.1  [2]
204 No Notification
Indicates the request was successful, but the corresponding response will not be received. [7]

3xx—Redirection Responses

300 Multiple Choices
The address resolved to one of several options for the user or client to choose between, which are listed in the message body or the message's Contact fields. [1] : §21.3.1 
301 Moved Permanently
The original Request-URI is no longer valid, the new address is given in the Contact header field, and the client should update any records of the original Request-URI with the new value. [1] : §21.3.2 
302 Moved Temporarily
The client should try at the address in the Contact field. If an Expires field is present, the client may cache the result for that period of time. [1] : §21.3.3 
305 Use Proxy
The Contact field details a proxy that must be used to access the requested destination. [1] : §21.3.4 
380 Alternative Service
The call failed, but alternatives are detailed in the message body. [1] : §21.3.5 

4xx—Client Failure Responses

400 Bad Request
The request could not be understood due to malformed syntax. [1] : §21.4.1 
401 Unauthorized
The request requires user authentication. This response is issued by UASs and registrars. [1] : §21.4.2 
402 Payment Required
Reserved for future use. [1] : §21.4.3 
403 Forbidden
The server understood the request, but is refusing to fulfill it. [1] : §21.4.4  Sometimes (but not always) this means the call has been rejected by the receiver.
404 Not Found
The server has definitive information that the user does not exist at the domain specified in the Request-URI. This status is also returned if the domain in the Request-URI does not match any of the domains handled by the recipient of the request. [1] : §21.4.5 
405 Method Not Allowed
The method specified in the Request-Line is understood, but not allowed for the address identified by the Request-URI. [1] : §21.4.6 
406 Not Acceptable
The resource identified by the request is only capable of generating response entities that have content characteristics but not acceptable according to the Accept header field sent in the request. [1] : §21.4.7 
407 Proxy Authentication Required
The request requires user authentication. This response is issued by proxies. [1] : §21.4.8 
408 Request Timeout
Couldn't find the user in time. The server could not produce a response within a suitable amount of time, for example, if it could not determine the location of the user in time. The client MAY repeat the request without modifications at any later time. [1] : §21.4.9 
409 Conflict
User already registered. [8] : §7.4.10  Deprecated by omission from later RFCs [1] and by non-registration with the IANA. [2]
410 Gone
The user existed once, but is not available here any more. [1] : §21.4.10 
411 Length Required
The server will not accept the request without a valid Content-Length. [8] : §7.4.12  Deprecated by omission from later RFCs [1] and by non-registration with the IANA. [2]
412 Conditional Request Failed
The given precondition has not been met. [9]
413 Request Entity Too Large
Request body too large. [1] : §21.4.11 
414 Request-URI Too Long
The server is refusing to service the request because the Request-URI is longer than the server is willing to interpret. [1] : §21.4.12 
415 Unsupported Media Type
Request body in a format not supported. [1] : §21.4.13 
416 Unsupported URI Scheme
Request-URI is unknown to the server. [1] : §21.4.14 
417 Unknown Resource-Priority
There was a resource-priority option tag, but no Resource-Priority header. [10]
420 Bad Extension
Bad SIP Protocol Extension used, not understood by the server. [1] : §21.4.15 
421 Extension Required
The server needs a specific extension not listed in the Supported header. [1] : §21.4.16 
422 Session Interval Too Small
The received request contains a Session-Expires header field with a duration below the minimum timer. [11]
423 Interval Too Brief
Expiration time of the resource is too short. [1] : §21.4.17 
424 Bad Location Information
The request's location content was malformed or otherwise unsatisfactory. [12]
425 Bad Alert Message
The server rejected a non-interactive emergency call, indicating that the request was malformed enough that no reasonable emergency response to the alert can be determined. [13]
428 Use Identity Header
The server policy requires an Identity header, and one has not been provided. [14] : p11 
429 Provide Referrer Identity
The server did not receive a valid Referred-By token on the request. [15]
430 Flow Failed
A specific flow to a user agent has failed, although other flows may succeed. This response is intended for use between proxy devices, and should not be seen by an endpoint (and if it is seen by one, should be treated as a 400 Bad Request response). [16] : §11.5 
433 Anonymity Disallowed
The request has been rejected because it was anonymous. [17]
436 Bad Identity-Info
The request has an Identity-Info header, and the URI scheme in that header cannot be dereferenced. [14] : p11 
437 Unsupported Certificate
The server was unable to validate a certificate for the domain that signed the request. [14] : p11 
438 Invalid Identity Header
The server obtained a valid certificate that the request claimed was used to sign the request, but was unable to verify that signature. [14] : p12 
439 First Hop Lacks Outbound Support
The first outbound proxy the user is attempting to register through does not support the "outbound" feature of RFC 5626, although the registrar does. [16] : §11.6 
440 Max-Breadth Exceeded
If a SIP proxy determines a response context has insufficient Incoming Max-Breadth to carry out a desired parallel fork, and the proxy is unwilling/unable to compensate by forking serially or sending a redirect, that proxy MUST return a 440 response. A client receiving a 440 response can infer that its request did not reach all possible destinations. [18]
469 Bad Info Package
If a SIP UA receives an INFO request associated with an Info Package that the UA has not indicated willingness to receive, the UA MUST send a 469 response, which contains a Recv-Info header field with Info Packages for which the UA is willing to receive INFO requests. [19]
470 Consent Needed
The source of the request did not have the permission of the recipient to make such a request. [20]
480 Temporarily Unavailable
Callee currently unavailable. [1] : §21.4.18 
481 Call/Transaction Does Not Exist
Server received a request that does not match any dialog or transaction. [1] : §21.4.19 
482 Loop Detected
Server has detected a loop. [1] : §21.4.20 
483 Too Many Hops
Max-Forwards header has reached the value '0'. [1] : §21.4.21 
484 Address Incomplete
Request-URI incomplete. [1] : §21.4.22 
485 Ambiguous
Request-URI is ambiguous. [1] : §21.4.23 
486 Busy Here
Callee is busy. [1] : §21.4.24 
487 Request Terminated
Request has terminated by bye or cancel. [1] : §21.4.25 
488 Not Acceptable Here
Some aspect of the session description or the Request-URI is not acceptable. [1] : §21.4.26 
489 Bad Event
The server did not understand an event package specified in an Event header field. [4] : §7.3.2  [6] : §8.3.2 
491 Request Pending
Server has some pending request from the same dialog. [1] : §21.4.27 
493 Undecipherable
Request contains an encrypted MIME body, which recipient can not decrypt. [1] : §21.4.28 
494 Security Agreement Required
The server has received a request that requires a negotiated security mechanism, and the response contains a list of suitable security mechanisms for the requester to choose between, [21] : §§2.3.1–2.3.2  or a digest authentication challenge. [21] : §2.4 

5xx—Server Failure Responses

500 Internal Server Error
The server could not fulfill the request due to some unexpected condition. [1] : §21.5.1 
501 Not Implemented
The server does not have the ability to fulfill the request, such as because it does not recognize the request method. (Compare with 405 Method Not Allowed, where the server recognizes the method but does not allow or support it.) [1] : §21.5.2 
502 Bad Gateway
The server is acting as a gateway or proxy, and received an invalid response from a downstream server while attempting to fulfill the request. [1] : §21.5.3 
503 Service Unavailable
The server is undergoing maintenance or is temporarily overloaded and so cannot process the request. A "Retry-After" header field may specify when the client may reattempt its request. [1] : §21.5.4 
504 Server Time-out
The server attempted to access another server in attempting to process the request, and did not receive a prompt response. [1] : §21.5.5 
505 Version Not Supported
The SIP protocol version in the request is not supported by the server. [1] : §21.5.6 
513 Message Too Large
The request message length is longer than the server can process. [1] : §21.5.7 
555 Push Notification Service Not Supported
The server does not support the push notification service identified in a 'pn-provider' SIP URI parameter [22] : §14.2.1 
580 Precondition Failure
The server is unable or unwilling to meet some constraints specified in the offer. [23]

6xx—Global Failure Responses

600 Busy Everywhere
All possible destinations are busy. Unlike the 486 response, this response indicates the destination knows there are no alternative destinations (such as a voicemail server) able to accept the call. [1] : §21.6.1 
603 Decline
The destination does not wish to participate in the call, or cannot do so, and additionally the destination knows there are no alternative destinations (such as a voicemail server) willing to accept the call. [1] : §21.6.2  The response may indicate a better time to call in the Retry-After header field.
604 Does Not Exist Anywhere
The server has authoritative information that the requested user does not exist anywhere. [1] : §21.6.3 
606 Not Acceptable
The user's agent was contacted successfully but some aspects of the session description such as the requested media, bandwidth, or addressing style were not acceptable. [1] : §21.6.4 
607 Unwanted
The called party did not want this call from the calling party. Future attempts from the calling party are likely to be similarly rejected. [24]
608 Rejected
An intermediary machine or process rejected the call attempt. [25] This contrasts with the 607 (Unwanted) SIP response code in which a human, the called party, rejected the call. The intermediary rejecting the call should include a Call-Info header with "purpose" value "jwscard", with the jCard [26] with contact details. The calling party can use this jCard if they want to dispute the rejection.

Related Research Articles

The Dynamic Host Configuration Protocol (DHCP) is a network management protocol used on Internet Protocol (IP) networks for automatically assigning IP addresses and other communication parameters to devices connected to the network using a client–server architecture.

<span class="mw-page-title-main">HTTP</span> Application protocol for distributed, collaborative, hypermedia information systems

HTTP is an application layer protocol in the Internet protocol suite model for distributed, collaborative, hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web, where hypertext documents include hyperlinks to other resources that the user can easily access, for example by a mouse click or by tapping the screen in a web browser.

<span class="mw-page-title-main">IRC</span> Protocol for real-time Internet chat and messaging

IRC is a text-based chat system for instant messaging. IRC is designed for group communication in discussion forums, called channels, but also allows one-on-one communication via private messages as well as chat and data transfer, including file sharing.

The Session Initiation Protocol (SIP) is a signaling protocol used for initiating, maintaining, and terminating communication sessions that include voice, video and messaging applications. SIP is used in Internet telephony, in private IP telephone systems, as well as mobile phone calling over LTE (VoLTE).

SIMPLE, the Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions, is an instant messaging (IM) and presence protocol suite based on Session Initiation Protocol (SIP) managed by the Internet Engineering Task Force.

A Service record is a specification of data in the Domain Name System defining the location, i.e., the hostname and port number, of servers for specified services. It is defined in RFC 2782, and its type code is 33. Some Internet protocols such as the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) often require SRV support by network elements.

Diameter is an authentication, authorization, and accounting (AAA) protocol for computer networks. It evolved from the earlier RADIUS protocol. It belongs to the application layer protocols in the Internet protocol suite.

A Name Authority Pointer (NAPTR) is a type of resource record in the Domain Name System of the Internet.

The SIP URI scheme is a Uniform Resource Identifier (URI) scheme for the Session Initiation Protocol (SIP) multimedia communications protocol. A SIP address is a URI that addresses a specific telephone extension on a voice over IP system. Such a number could be a private branch exchange or an E.164 telephone number dialled through a specific gateway. The scheme was defined in RFC 3261.

<span class="mw-page-title-main">HTTP 403</span> HTTP status code indicating that access is forbidden to a resource

HTTP 403 is an HTTP status code meaning access to the requested resource is forbidden. The server understood the request, but will not fulfill it, if it was correct.

HTTP tunneling is used to create a network link between two computers in conditions of restricted network connectivity including firewalls, NATs and ACLs, among other restrictions. The tunnel is created by an intermediary called a proxy server which is usually located in a DMZ.

Peer-to-peer SIP (P2P-SIP) is an implementation of a distributed voice over Internet Protocol (VoIP) or instant messaging communications application using a peer-to-peer (P2P) architecture in which session control between communication end points is facilitated with the Session Initiation Protocol (SIP).

<span class="mw-page-title-main">HTTP location</span> Instruction by web server containing the intended location of a web page.

The HTTP Location header field is returned in responses from an HTTP server under two circumstances:

  1. To ask a web browser to load a different web page. In this circumstance, the Location header should be sent with an HTTP status code of 3xx. It is passed as part of the response by a web server when the requested URI has:
  2. To provide information about the location of a newly created resource. In this circumstance, the Location header should be sent with an HTTP status code of 201 or 202.
<span class="mw-page-title-main">WebSocket</span> Computer network protocol

WebSocket is a computer communications protocol, providing a simultaneous two-way communication channel over a single Transmission Control Protocol (TCP) connection. The WebSocket protocol was standardized by the IETF as RFC 6455 in 2011. The current specification allowing web applications to use this protocol is known as WebSockets. It is a living standard maintained by the WHATWG and a successor to The WebSocket API from the W3C.

<span class="mw-page-title-main">HTTP/1.1 Upgrade header</span> HTTP header field introduced in HTTP/1.1

The Upgrade header field is an HTTP header field introduced in HTTP/1.1. In the exchange, the client begins by making a cleartext request, which is later upgraded to a newer HTTP protocol version or switched to a different protocol. A connection upgrade must be requested by the client; if the server wants to enforce an upgrade it may send a 426 Upgrade Required response. The client can then send a new request with the appropriate upgrade headers while keeping the connection open.

The Session Initiation Protocol (SIP) is the signaling protocol selected by the 3rd Generation Partnership Project (3GPP) to create and control multimedia sessions with multiple participants in the IP Multimedia Subsystem (IMS). It is therefore a key element in the IMS framework.

<span class="mw-page-title-main">Well-known URI</span>

A well-known URI is a Uniform Resource Identifier for URL path prefixes that start with /.well-known/. They are implemented in webservers so that requests to the servers for well-known services or information are available at URLs consistent well-known locations across servers.

References

  1. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 Rosenberg, Jonathan; Schulzrinne, Henning; Camarillo, Gonzalo; Johnston, Alan; Peterson, Jon; Sparks, Robert; Handley, Mark; Schooler, Eve (June 2002). SIP: Session Initiation Protocol. IETF. doi: 10.17487/RFC3261 . RFC 3261.
  2. 1 2 3 4 Roach, Adam; Jennings, Cullen; Peterson, Jon; Barnes, Mary (17 April 2013) [Created January 2002]. "Response Codes". Session Initiation Protocol (SIP) Parameters. IANA.
  3. ↑ Holmberg, Christer (May 2011). Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog. IETF. p. 1. Abstract. doi: 10.17487/RFC6228 . RFC 6228.
  4. 1 2 Roach, Adam B. (June 2002). Session Initiation Protocol (SIP)-Specific Event Notification. IETF. doi: 10.17487/RFC3265 . RFC 3265.
  5. ↑ Fielding, Roy T.; Gettys, James; Mogul, Jeffrey C.; Nielsen, Henrik Frystyk; Masinter, Larry; Leach, Paul; Berners-Lee, Tim (June 1999). "202 Accepted". Hypertext Transfer Protocol -- HTTP/1.1. IETF. sec. 10.2.3. doi: 10.17487/RFC2616 . RFC 2616.
  6. 1 2 Roach, Adam (July 2012). SIP-Specific Event Notification. IETF. doi: 10.17487/RFC6665 . RFC 6665.
  7. ↑ Niemi, Aki (May 2010). "204 (No Notification) Response Code". In Willis, Dean (ed.). An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification. IETF. sec. 7.1. doi: 10.17487/RFC5839 . RFC 5839.
  8. 1 2 Handley, Mark; Schulzrinne, Henning; Schooler, Eve; Rosenberg, Jonathan (March 1999). SIP: Session Initiation Protocol. IETF. doi: 10.17487/RFC2543 . RFC 2543.
  9. ↑ Niemi, Aki, ed. (2004). ""412 Conditional Requset Failed" Response Code". Session Initiation Protocol (SIP) Extension for Event State Publication. IETF. sec. 11.2.1. doi: 10.17487/RFC3903 . RFC 3903.
  10. ↑ Schulzrinne, Henning; Polk, James (February 2006). "No Known Namespace or Priority Value". Communications Resource Priority for the Session Initiation Protocol (SIP). IETF. sec. 4.6.2. doi: 10.17487/RFC4412 . RFC 4412.
  11. ↑ Donovan, Steve; Rosenberg, Jonathan (April 2005). "422 Response Code Definition". Session Timers in the Session Initiation Protocol (SIP). IETF. sec. 6. doi: 10.17487/RFC4028 . RFC 4028.
  12. ↑ Polk, James; Rosen, Brian; Peterson, Jon (December 2011). "424 (Bad Location Information) Response Code". Location Conveyance for the Session Initiation Protocol. IETF. sec. 4.3. doi: 10.17487/RFC6442 . RFC 6442.
  13. ↑ Rosen, Brian; Schulzrinne, Henning; Tschofenig, Hannes; Gellens, Randall (September 2020). "425 (Bad Alert Message) Response Code". Non-interactive Emergency Calls. IETF. sec. 5.1. doi: 10.17487/RFC8876 . RFC 8876.
  14. 1 2 3 4 Peterson, Jon; Jennings, Cullen (August 2006). Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP). IETF. doi: 10.17487/RFC4474 . RFC 4474.
  15. ↑ Sparks, Robert J. (September 2004). "The 429 Provide Referrer Identity Error Response". The Session Initiation Protocol (SIP) Referred-By Mechanism. IETF. sec. 5. doi: 10.17487/RFC3892 . RFC 3892.
  16. 1 2 Jennings, Cullen; Mahy, Rohan; Audet, Francois, eds. (October 2009). Managing Client-Initiated Connections in the Session Initiation Protocol (SIP). IETF. doi: 10.17487/RFC5626 . RFC 5626.
  17. ↑ Rosenberg, Jonathan (December 2007). "433 (Anonymity Disallowed) Definition". Rejecting Anonymous Requests in the Session Initiation Protocol (SIP). IETF. sec. 5. doi: 10.17487/RFC5079 . RFC 5079.
  18. ↑ Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies. IETF. December 2008. doi: 10.17487/RFC5393 . RFC 5393.
  19. ↑ Session Initiation Protocol (SIP) INFO Method and Package Framework. IETF. January 2011. doi: 10.17487/RFC6086 . RFC 6086.
  20. ↑ Rosenberg, Jonathan; Willis, Dean (October 2008). "Definition of the 470 Response Code". In Camarillo, Gonzalo (ed.). A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP). IETF. sec. 5.9.2. doi: 10.17487/RFC5360 . RFC 5360.
  21. 1 2 Arkko, Jari; Torvinen, Vesa; Camarillo, Gonzalo; Niemi, Aki; Haukka, Tao (January 2003). Security Mechanism Agreement for the Session Initiation Protocol (SIP). IETF. doi: 10.17487/RFC3329 . RFC 3329.
  22. ↑ Push Notification with the Session Initiation Protocol (SIP). IETF. May 2019. doi: 10.17487/RFC8599 . RFC 8599.
  23. ↑ Rosenberg, Jonathan (October 2002). "Refusing an offer". In Camarillo, Gonzalo; Marshall, Bill (eds.). Integration of Resource Management and Session Initiation Protocol (SIP). IETF. sec. 8. doi: 10.17487/RFC3312 . RFC 3312.
  24. ↑ A SIP Response Code for Unwanted Calls. IETF. July 2017. doi: 10.17487/RFC8197 . RFC 8197.
  25. ↑ A Session Initiation Protocol (SIP) Response Code for Rejected Calls. IETF. December 2019. doi: 10.17487/RFC8688 . RFC 8688.
  26. ↑ RFC   7095
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.