SIP Status Code

SIP Reply Message Status code
and feature

Type Status Code status description
Temporary response (1XX) Trying is in process
Ringing ringing
181 call being forwarder is forward
182 Queue Queue
181* Session Progress Sessions

Session success (2XX) OK session succeeded

Redirect (3XX) multiple multiple options
301 Moved Permanently permanent mobile
302 moved temporaily temporary movement
305 Use Proxy User agent
380 Alternative service Replacement services

Request failed (4XX) The error request
401unauthorized is not authorized
402 payment required pay request
403 Forbidden Forbidden
404 Not Found
405 Method No allowed methods are not allowed
406 not acceptable unacceptable
407 Proxy Authentication required proxy requires authentication
408 Request Timeout Request timed out
410 gone left
413 request entity too large requested entities too large
414 request-url too long request URL too long
415 unsupported Media type not supported
416 unsupported URL scheme unsupported URL plan
420 bad extension poor extension
421 extension required need to be extended  
423 interval too brief interval too short
480 temporarily unavailable temporary invalidation
481 call/transaction does not exist call/transaction not present
482 Loop detected discovery Loop
483 Too many hops hop count too many
484 address incomplete addresses incomplete
485 ambiguous unclear
486 busy here busy
487 requests terminated request terminated
488 not acceptable here request unacceptable
491 request pending pending request
493 undecipherable Unrecognized

Server failed (5XX) server Internal Error internal errors
501 not implemented non-executable
502 Bad Gateway
503 Service Unavailable Not available
504 Server Time-out timeout
505 version not supported is not supported
513 message too large messages too big

Global error (6XX) busy everywhere full busy
603 Decline Discard
604 does not exist anywhere does not exist
606 Not acceptable unacceptable
SIP Response Code (details below)

The answer code is included, and the http/1.1 answer code is extended. Not all http/1.1 response codes are properly applied, only in the fold. Other http/1.1 answer codes should not be used. Also, SIP defines a new answer code series, 6xx.

1 Temporary response 1xx
A temporary response, which is the nature of the message, is a sign that the other server is processing the request and has not yet decided on the final answer. It should send a 1xx response when the server is processing a request that takes more than 200ms to produce an end-of-answer.
Note that the 1XX response is not transmitted reliably. They do not cause the client to deliver an ACK response. The temporary (1xx) answer can contain the message body, which contains the session description.
1.1 Trying
The answer indicates that the server of the next node has received the request and has not performed a specific action on the request (for example, when the database is being opened). This response, like any other temporary response, planted the UAC to resend the invite request. The Trying response differs from the other ad hoc response, where it is never forwarded to the upstream stream by a stateful proxy.
1.2 Ringing
UA receives the invite request and attempts to prompt the user. This response should be born with a local ring back.
1.3 818 Call is Being forwarded (calls forwarded)
The server can use this answer code to indicate that a call is being forwarded to another destination collection.
1.4 182 Queued
This response should be issued when the caller is temporarily unable to receive the call, and the server decides to queue the call instead of rejecting the call. When the called party resumes receiving the call, he returns the appropriate termination answer. For this call state, there can be a phrase that represents the reason, such as: "5 calls queued;expected waiting time is 15minutes". The server can give several 182 (Queued) answers that tell callers to queue up (for example, queued up, and so on).
1.5 183 Session Progress
183 (Session Progress) answers the progress information used to prompt the dialog. Reason-phrase (the sentence that expresses the reason), the Head field, or the message body can be used to prompt for more information about the progress of the call.
2 Success Information 2xx
This response indicates that the request was successful.
2.1 OK
The request has been processed successfully. This information depends on the response of the request of the different methods.
3 Forwarding Request 3XX
The answer to the 3XX series is the additional service location that is used to prompt the user for new location information, or to be forwarded to meet the call.
3.1 Multiple Choices
The requested address has multiple choices, each with its own address, the user or (UA) can select the appropriate communication terminal, and forward the request to this address.
An answer can include a resource attribute that is allowed in the Accept request header domain for each location so that the user or UA can select the most appropriate address to forward the request. The MIME type is not defined for the message body without this response.
These address selections should also be listed in the Contact Header field (section 20.10). Unlike the Http,sip answer, you can include multiple contact header fields or a Contact header field that has an address list. UA can use the Contact header field to automatically forward or ask the user to confirm the forwarding. However, this specification does not define the standard for automatic forwarding.
If the called party can be found at more than one address and the server cannot or is unwilling to forward the request, it can be used to give the caller the answer.
3.2 301 Moved permently
When the user cannot be found at the address specified by Request-uri, the requesting client should retry with the new address indicated by the Contact header field (20.10). The requestor should use this new value to update the local directory, address Book, and user address cache, and in subsequent requests, send to this/these listed addresses.
3.3 302 Moved temporarily
The requesting party should resend the request to the new address (20.10) as indicated in the Contact header field. The Request-uri of the new request should use the value indicated by the Contact header field of this reply.
The lifetime of this contact URI is defined in the Expires (section 20.19) or the expires parameter of the Contacts Header field in the answer. The UA or proxy caches the URI for this lifetime. If there is no strict effective, then this address is only valid this time, and cannot be saved in future transactions.
If the value of the Contact header field of the cache fails, then the Request-uri of the forwarded request should try again. The temporary URI can be invalidated faster than the timeout and can have a new temporary URI.
3.4 305 Use Proxy
The requested resource must be accessed through a proxy indicated in the Contact header field. The Contact header field specifies the URI of a proxy. The object that receives the reply should resend the individual request through this proxy. 305 (UseProxy) must be produced by UAS.
3.5 380 Alternative Service
The call is not working, but you can try another service. Additional services are defined in the message body of the reply. The format of the message body is not defined here and may be defined in a later specification.
4 Request failed 4xx
The 4xx answer defines a scenario in which a request for a particular server response failed. The client should not retry the same request without changing the request. (for example, increase the appropriate authentication information). However, the same request may be successful if it is given to a different server.
4.1 Bad Request
The syntax error in the request. Reason-phrase should flag this detailed syntax error, such as "Missing Call-id header Field".
4.2 401 Unauthorized
The request requires user authentication. This response is generated by UAS and the registered server, when 407 (proxy authentication Required) is the proxy server.
4.3 402 Payment Required
Reserved/later use
4.4 403 Forbidden
The service side supports this request, but refuses to execute the request. It is not necessary to increase the authentication information, and the request should not be retried.
4.5 404 Not Found
The server returns the final message: The user does not exist on the domain specified by the Request-uri. This response is also generated when Request-uri domain does not match the domain that received the request.
4.6 405 Method not allowed
The server supports methods in Request-line, but it is not allowed to apply this method to addresses in this request-uri.
The answer must include an Allow header field that contains a list of methods allowed for the specified address.
4.7 Not acceptable
The resource in the request only causes an error that the content cannot receive in the request outside of the accept header.
4.8 407 Proxy Authentication Required
This return code and 401 (unauthorized) are class four, but the client should first pass the authentication on the proxy. For SIP authentication access, see sections 26 and 22.3.
This return code is used for application access to the communication gateway (for example, telephone gateways) and is seldom used for authentication by the called party.
4.9 408 Request Timeout
During a period of time, the server cannot produce an end response, for example, if it cannot determine the user's location in a timely manner. The client can then retry the request without changing the content of the request at a later time.
4.10 410 Gone
The requested resource does not already exist on this server and does not know where to forward the request. This problem will be permanent. If the server does not know, or is not easily detected, whether the resource disappears temporarily or permanently, then a 404 (not Found) should be returned.
4.11 413 Request entity is too large.
The server refused to process the request because the entity of the request exceeded the size that the server wanted or could handle. This server should close the connection to prevent the client from re-sending the request.
If the situation is temporary, then the server should include a Retry-after header field to indicate that this is a temporary failure, and the client can try again over time.
4.12 414 Request-uri Too Long
The server rejects this request because Request-uri exceeds the length that the server can handle.
4.13 415 Unsupported Media Type
The server is not supported due to the format of the requested message body, so it refuses to process this request. This server must return a accept,accpet-encoding, or accept-language header domain list, based on the type of failure of the content. UAC handles this response based on the method defined in section 8.1.3.5.
4.14 416 Unsupported URI Scheme
The server terminated processing this request because it does not support the URI scheme in Request-uri. The client handles this reply reference 8.1.3.5.
4.15 Bad Extension
The server does not know the protocol extension indicated in Proxy-require (20.29) or Require (20.32) header fields in the request. The server must list the unsupported extensions in the unsupported header domain. UAC handles this response see 8.1.3.5
4.16 421Extension Required
UAS requires a specific extension to handle this request, but the extension is not listed in the requested Supported header field. An answer with this answer code must contain an require header field that lists the required extensions.
UAS should not use this response unless it really does not provide a valid service to the client. Conversely, if the required extensions are not listed in the support header domain, the server should be processed based on the baseline SIP-compliant methods and the extensions supported by the client.
4.17 423 Interval Too Brief
The server rejected the request because the resource refresh time (or validity time) set in the request was too short. This response can be used to register the server to reject registration requests that have a short validity period for the contact header domain. The usage of this answer and the associated Min-expires header fields are described and explained in the 10.2.8,10.3,20.23 section.
4.18 480 Temporarily unavailable
The request successfully arrives at the called Party's terminal system, but the called Party is currently unavailable (for example, no login, or login but the status is not able to communicate, or there is a "do Not Disturb" tag). The answer should mark a suitable retry-after in the time of the re-send. This user is also likely to be valid elsewhere (not known in this server). Reason-phrase (reason) should be prompted for more detailed reasons why the called party is temporarily unavailable. This value should be set by UA. The Status Code 486 (Busy here) can be used to more precisely represent the specific cause of this request failure.
This status code can also be returned by the forwarding service or proxy server, as they find that the Request-uri specified user exists, but there is no appropriate current forwarding address for the user.
4.19 481 call/transaction Does not Exist
This state indicates that the UAS received the request but did not match the existing conversation or transaction.
4.20 482 Loop Detected
A loop was detected by the server (16.3/4)
4.21 483 Too Many Hops
The server received a request containing the Max-forwards (20.22) header domain is 0
4.22 484 Address Incomplete
The server received a request and its request-uri is incomplete. There should be an additional information description in the reason phrase. This status code can overlap with dial-up. In and dial-up overlaps, the client does not know the length of the dial string. It sends a string that increments the length and prompts the user to enter more strings until the 484 (Address incomplete) answer appears.
4.23 485 ambiguous
The Request-uri is not clear. The answer can include a possible explicit address list in the Contact header field. This list of hints is a compromise for users or organizations in terms of security and privacy. It must be possible for the configuration to decide whether to replace this answer with 404 (NotFound), or to disallow the use of a possible selection list for ambiguous addresses.
An example of a response to a request with Request-uri:
Sip:[email protected]:
sip/2.0 485 ambiguous
Contact:carol Lee <sip:[email protected]>
Contact:ping Lee <sip:[email protected]>
Contact:lee m.foote <sips:[email protected]>
Part of the email and voice mail system provides this functionality. This status code differs from the 3XX status code: For 300来, it is assumed that the same person or service has different address choices. Therefore, for 3xx, automatic selection of the system or continuous search is effective, but for 485 (ambiguous) response, must be user intervention.
4.24 486 Busy here
When the called Party's terminal system is successfully contacted, but the called party is currently unable to answer the call on the terminal system, the answer should be returned to the caller at a more appropriate time to retry in the Retry-after header domain. This user may be available elsewhere, such as a phone-mail system, and so on. If we know that no other terminal system can answer this call, then we should return a status code of (Busy Everywhere).
4.25 487 Request Terminated
The request was terminated by bye or cancel. This response will never reply to the cancel request itself.
4.26 488 not acceptable here
This response and 606 (not acceptable) have the same meaning, but only the specific resources indicated by Request-uri are unacceptable, and requests from other places may be acceptable.
The body of the message containing the media compatibility description can appear in the answer and be normalized according to the Accept header field in the Invite request (if there is no Accept header field, then APPLICATION/SDP). This response is like the message body that answers the options request (OK).
4.27 491 Request Pending
In the same conversation, the request received by UAS has a dependent request being processed. 14.2 Describes how such a situation should be resolved.
4.28 493 undecipherable
The UAS received a request that contained an encrypted mime and did not know or provided the appropriate decryption key. This response can contain a single package containing the appropriate public key, which is used to encrypt the packet in the UAS communication. Details are described in section 23.2.
5 Server Failure 5xx
A 5xx response is a failure response that is given when the server itself fails.
5.1 Server Internal Error
The server encountered an unknown situation and could not continue processing the request. The client can display a specific error condition, and can retry the request in a matter of seconds.
If this condition is temporary, the server should retry the request after the Retry-after header domain flags the client for a few seconds.
5.2 501 Not implemented
The server did not implement the related request function. This answer should be returned when UAS does not recognize the requested method and is not able to support this method for every user. (Proxy forwards the request regardless of the requested method).
Note that 405 (method not allowed) is because the server implements this request method, but this request method is not supported in a particular request.
5.3 502 Bad Gateway
If the server is present as a gateway or proxy, an illegal response is received from the downstream server (the response request is forwarded by the server to the downstream server in order to complete the request).
5.4 503 Service Unavailable
The server is temporarily unavailable due to temporary overloading or server management. The server can add a retry-after to the response to allow the client to retry the request. If no retry-after indicates, the client must be treated as if it received a (Server Internal Error) reply.
The client (proxy or UAC) receives 503 (Service unavailable) should attempt to forward this request to another server for processing. And within the time specified in the Retry-after header domain, no other requests should be forwarded to this server.
As an alternative to 503 (Service unavaliable), the server can either reject the connection or discard the request.
5.5 504 Server Time-out
The server did not receive a prompt response on an external server. This external server is required for this server to access the processing of this request. If the Expires header field in the request received from the upstream server times out, then a 408 (Request TimeOut) error should be returned.
5.6 505 Version Not supported
The server does not support the corresponding SIP version. The server is unable to process a request with the same major version number provided by the client, which can cause such an error message.
5.7 Message to Large
The server cannot process the request because the message length exceeds the length of the processing.
6 Global Failures 6xx
6XX response means that the server has a final message for a particular user, not just a specific instance of Request-uri.
6.1 Busy Everywhere
The terminal system of the called Party is successfully contacted, but the called party is in a busy state and is not going to answer the call. This answer can be more explicit by adding a Retry-after header domain to tell the caller how long later the call can continue. The called Party should use 603 (decline) if the called Party does not wish to indicate the reason for the rejection. This answer can only be used when the terminal system knows that no other endpoint, such as a voice mail system, can access the user. Otherwise, a 486 (Busy here) response should be returned.
6.2 603 decline
When the device is successfully accessed to the called party, but the user does not want to reply explicitly. This answer can be more explicit by adding a Retry-after header domain to tell the caller how long later the call can continue. This response can only be given if the terminal knows that no other terminal device can respond to the potential energy of the call.
6.3 604 Does not Exists Anywhere
The server verifies the user information that is Request-uri in the request, where none exists
6.4 606 Not acceptable
When a UA is successfully contacted, some parts of the session description, such as the requested media, bandwidth, or address type are not received.
The 606 (notacceptable) response means that the user wants to communicate, but does not fully support the session description. The 606 (not acceptable) answer can include a reason list in the warning header field to explain why the session description cannot be supported. The warning reason codes are listed in section 20.43.
In the answer, a message body containing the media compatibility description can appear, and the format of the message body is normalized according to the format indicated by the Accept header field in the Invite request (if there is no Accept header field, then APPLICATION/SDP), Just like the message in the answer to the Options Pro (OK).
We hope that these media consultations are not often required, and that this media negotiation may not be required when a new user is invited to a session that already exists. This depends on whether the invited initializer needs to process 606 (not acceptable).
This response can only be issued if the client knows that no other terminal can handle the request.

SIP Status Code