SIP Response Status Code control detailed

SIP Reply Message Status code
and function

Type Status Code status description
Temporary response (1XX) trying is in process
180 ringing ringing
181 Call being forwarder calls are forward
Line queue
181* Session Progress Sessions

Session succeeded (2XX) OK session succeeded

Redirect (3XX) multiple multiple selection
Moved Permanently permanent move
302 moved temporaily temporary movement
305 Use Proxy User agent
380 Alternative Service Alternative services

Request failed (4XX) Bad Request
401unauthorized unauthorized
402 payment required pay requirement
403 Forbidden prohibit
404 Not f Ound not found
405 method No allowed is not allowed
406 not acceptable unacceptable
407 Proxy Authentication required proxy requires authentication
408 Request Timeout Timeout
410 gone leave
413 request entity too requested entity too large
Large 414 request-url long request URL too long
415 Unsupported media type is not supported by
416 unsupported URL scheme does not support URL scheduling
420 bad extension undesirable extension
421 extension requ Ired need to extend &NBSP
423 interval too brief interval is too short
to temporarily unavailable temporary failure
481 call/transaction does not exi St Call/transaction does not exist
482 loop detected discovery Loop
483 Too many hops the number of hops is too many
484 address incomplete addresses are not complete
485 ambiguous r> 486 busy here is busy.
487 request terminated requested termination
488 not acceptable here request unacceptable
491 request pending pending Requests
493 undecipherable not recognizable

Server failed (5XX) server Internal error server internal errors
501 Not implemented is not executable
502 Bad Gateway
Invalid 503 Service Unavailable Services
504 Server time-out servers timeout
505 version not supported is not supported
513 message too large messages are too large

Global error (6XX) busy everywhere all 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 answer codes are properly applied, and only the appropriate ones are indicated in the fold. Other http/1.1 answer codes should not be used. Also, SIP defines a new answer code series, 6xx.

1 Temporary answer 1xx
A temporary response, a message-nature response, flags that the other server is processing the request and has not decided on the final answer. It should send a 1xx response when the server processing the request requires more than 200ms to produce an end response.
Note that 1XX responses are not reliably transmitted. They do not cause the client to send an ACK reply. A temporary (1xx) response can contain a message body, including a session description.
1.1 Trying
This response indicates that the next node's server has received the request and has not performed the specific action of the request (for example, when the database is being opened). This response, like other temporary responses, was planted with UAC to transfer invite requests. The trying answer differs from other ad hoc responses, where it is never forwarded to the upstream stream by a stateful proxy.
1.2 180 ringing
UA receives the invite request and attempts to prompt the user. This response should be born with a local back bell.
1.3 818 call is being forwarded (calls forwarded)
The server can use this answer code to indicate that the call is being forwarded to another destination collection.
1.4 Queued
This answer should be sent 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 callee resumes receiving the call, he returns the appropriate termination response. For this call state, you can have a phrase that indicates the reason, such as: "5 calls queued;expected waiting is 15minutes". The server can give several Queued answers to tell the caller to queue (such as queuing up front, etc.).
1.5 183 Session Progress
183 (Session Progress) answers the progress information that prompts you to establish a dialog. Reason-phrase (a sentence that expresses the reason), header field, or message body can be used to prompt for more information about the call progress.
2 Success Information 2xx
This answer 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 the new location information, or to be forwarded to satisfy the call.
3.1 Multiple choices
The requested address has multiple choices, each with its own address, and the user or (UA) can select the appropriate communication terminal and forward the request to this address.
A response can contain a resource attribute that is allowed in the Accept request header domain with each location, so that the user or UA can select the most appropriate address to forward the request. No MIME type is defined for a message body that does not have this answer.
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 with an address list. UA can use the Contact header field to automatically forward or require the user to confirm forwarding. However, this specification does not define the criteria for automatic forwarding.
If the caller can be found at multiple addresses and the server is unable or unwilling to forward the request, this answer can be used for the caller.
3.2 Moved permently
When a user cannot be found at the address specified by Request-uri, the requesting client should try again using the new address indicated by the Contact header field (20.10). The requester should update the local directory, address Book, and user address cache with this new value and send it to this/these listed addresses in subsequent requests.
3.3 302 moved temporarily
The requesting party should send the request back to the new address (20.10) as indicated by this Contact header field. The Request-uri of the new request should use the value indicated by the Contact header field for this answer.
The Expires (20.19 knots) in the answer or the expires parameter of the Contact header field defines the life cycle of the contacts URI. UA or proxy cache This URI in this life cycle. If there is no strict validity, the address is only valid this time and cannot be saved in future transactions.
If the value of the Contact header field for the cache fails, 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 the proxy indicated in the Contact header field. The Contact header field specifies the URI of a proxy. The object receiving this answer should resend this single 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 answer. 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 situation where a request for a specific server response has failed. The client should not retry the same request without changing the request. (For example, add the appropriate authentication information). However, the same request to a different server may be successful.
4.1 Bad Request
A syntax error in the request. Reason-phrase should mark this detailed grammatical error, such as "Missing Call-id header field."
4.2 401 Unauthorized
The request requires user authentication. This response is generated by the UAS and registered server, when 407 (proxy authentication Required) is generated by the proxy server.
4.3 402 Payment Required
Reserved/later used
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
Server returns final information: The user does not exist on the domain specified by Request-uri. This response is also generated when Request-uri domain does not match the domain that received the request.
4.6 405 method is not allowed
The server supports methods in Request-line, but this method is not allowed for addresses in this request-uri.
The answer must include a Allow header field that contains a list of methods allowed for the specified address.
4.7 Not acceptable
The resource in the request will only cause an error that the content cannot receive outside the accept header in the request.
4.8 407 Proxy Authentication Required
This return code and 401 (unauthorized) are class four, but flag the client should first pass authentication on proxy. For SIP access to authentication, see section 26 and section 22.3.
This return code is used for application access to the gateway (for example, telephone gateways) and is rarely used by the caller for authentication.
4.9 408 Request Timeout
Over 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 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 easy to detect, whether the resource disappears temporarily or permanently, then a 404 (not Found) should be returned.
4.11 413 Request entities are too large.
The server refused to process the request because the requested entity exceeded the size that the server wanted or could handle. This server should shut down the connection to prevent the client from issuing the request again.
If this 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 rejected the request because the Request-uri exceeded the length that the server was able to handle.
4.13 415 Unsupported Media Type
The server refused to process the request because the server does not support the format of the requested message body. This server must return a accept,accpet-encoding, or accept-language header field list, depending on the type of failure of the content. UAC handles this response according to the method defined in section 8.1.3.5.
4.14 416 Unsupported URI Scheme
The server terminated processing the request because it did 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 as indicated in the Proxy-require (20.29) or Require (20.32) header field in the request. The server must list unsupported extensions in the unsupported header field. UAC handles this response see 8.1.3.5
4.16 421Extension Required
UAS requires a specific extension to handle the request, but the extension is not listed in the requested supported header domain. The answer with this answer must contain a require header field that lists the required extensions.
UAS should not use this answer 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 according to the baseline SIP-compatible method and the client-supported extensions.
4.17 423 Interval Too Brief
The server rejects the request because the resource refresh time (or valid time) set in the request is too short. This answer can be used to register the server to reject registration requests that have a short expiration date for the contact header domain. The usage of this response and the associated Min-expires header fields are described and explained in the 10.2.8,10.3,20.23 section.
4.18 Temporarily unavailable
The request successfully reached the caller's terminal system, but the callee is currently unavailable (for example, no login, or login but status is not able to communicate, or have "Do not Disturb" tag). The response should mark an appropriate retry-after time in the text. This user is also likely to be valid elsewhere (not known on this server). Reason-phrase (reason) should be prompted for more detailed reasons why the callee is temporarily unavailable. This value should be set by UA. The Status Code 486 (Busy here) can be used to more precisely indicate the specific reason for the failure of this request.
This status code can also be the forwarding service or the proxy server returned, because they found that the Request-uri specified user exists, but does not have a suitable 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 dialog 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 a max-forwards (20.22) header field is 0
4.22 484 Address Incomplete
The server received a request and its request-uri is incomplete. There should be an additional description of the information in the reason phrase. This status code can overlap with the dial. In the and dial-up overlap, the client does not know the length of the dialing string. It sends a string that increases the length and prompts the user to enter more strings until the 484 (address incomplete) answer is not present.
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 will cause damage to users or organizations in the security and privacy. It must be possible for the configuration to decide whether to replace the answer with 404 (notfound), or to prohibit the use of a possible selection list for ambiguous addresses.
An example of an answer to a request with Request-uri:
Sip:lee@example.com:
sip/2.0 485 ambiguous
Contact:carol Lee <sip:carol.lee@example.com>
Contact:ping Lee <sip:p.lee@example.com>
Contact:lee M.foote <sips:lee.foote@example.com>
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 a different address choice. So for 3xx, automatic selection system or continuous search is effective, but for 485 (ambiguous) response, must be user intervention.
4.24 486 Busy here
When the caller's terminal system is successfully contacted, but the callee is currently unable to answer the call on the terminal system, the response should be returned to the caller for a more appropriate time 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 a status code (Busy everywhere) should be returned.
4.25 487 Request Terminated
The request was terminated by bye or cancel. This answer will never respond to the cancel request itself.
4.26 488 Not acceptable
This answer has the same meaning as 606 (not acceptable), but only applies to the specific resources indicated by Request-uri, which may be acceptable elsewhere.
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 answer is like a message body that responds to the options request (OK).
4.27 491 Request Pending
In the same conversation, UAS received a request that a dependent request is being processed. 14.2 Describes how this situation should be resolved.
4.28 493 undecipherable
UAS received a request that contained an encrypted mime and did not know or provided an appropriate decryption key. This response can contain a single package body that contains the appropriate public key, which is used to encrypt the UAS in this communication. Details are described in section 23.2.
5 Server Failure 5xx
A 5xx response is a failure response given when the server itself fails.
5.1 Server Internal Error
The server encountered an unknown condition and could not continue processing the request. The client can display a specific error condition and can retry the request after a few seconds.
If this is a temporary situation, the server should retry the request after the Retry-after header domain flag client has been in a few seconds.
5.2 501 Not implemented
The server does not implement related request functionality. This response should be returned when the UAS does not recognize the requested method and the method is not supported by each user. (Proxy forwards the request without regard to the requested method).
Note that 405 (method is not allowed) is because the server implements the request, but the request method is not supported in a particular request.
5.3 502 Bad Gateway
If the server, as a gateway or proxy, receives an illegal response from the downlink server (this response corresponds to a request that the server forwards to the downlink server in order to complete the request).
5.4 503 Service Unavailable
Server temporarily unavailable due to temporary overload or server management. The server can add a retry-after to the response to have the client retry the request. If no retry-after points out, 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 you should not forward other requests to this server within the time specified in the Retry-after header domain.
As an alternative to 503 (Service unavaliable), the server can reject the connection or throw the request out.
5.5 504 Server Time-out
The server did not receive a prompt response on an external server. This external server is used by this server to access the processing of this request. If the Expires header field in the request received from the upstream server times out, a 408 (Request TimeOut) error should be returned.
5.6 505 Version Not supported
The server does not support the corresponding SIP version. A server is unable to process a request with the same major version number provided by the client, which can result in such an error message.
5.7 Message to Large
The server was unable to process the request because the message length was longer than the processing length.
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 was successfully contacted, but the called party was in a busy state and did not intend to answer the phone. This response can be more specific by adding a Retry-after header field to tell the caller how long to continue the call. If the caller does not wish to be prompted for a refusal, the callee should use 603 (decline). This answer can only be used when the terminal system knows that no other terminal node, such as a voice mail system, can access the user. Otherwise, a 486 (Busy here) answer should be returned.
6.2 603 decline
When the device is successfully accessed to the callee, the user explicitly does not want to answer. This response can be more specific by adding a Retry-after header field to tell the caller how long to continue the call. This answer is only given when 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 that the user information Request-uri in the request does not exist anywhere
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.
606 (notacceptable) answer means that the user wants to communicate, but the session description is not fully supported. A 606 (not acceptable) answer can contain a list of causes in the warning header field to explain why the session description cannot be supported. The warning reason code is listed in section 20.43.
In the answer, a message body containing a media compatibility description can appear, which 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 do not need to be frequently needed, and that this media negotiation may not be required when a new user is invited to join an existing session. This depends on whether the invited initializer needs to process 606 (not acceptable).
This answer can only be sent when the client knows that no other terminal can handle the request.