HTTP status Error

500 is a server error
400 is a clinet Error
300 route change
200 OK



The response code, although it is sip, is also applicable to HTTP, but adds something

Response Code
The response code is included, and the HTTP/1.1 response code is extended. Not all HTTP/1.1 Response codes are properly applied, but only pointed out in the discount. Other HTTP/1.1 Response codes should not be used. In addition, SIP also defines a new response code series, 6xx.

1. Temporary response 1xx
A temporary response, that is, a message response, indicates that the other server is processing the request and has not yet decided on the final response. If it takes more than ms for the server to process the request to generate an end response, it should send a 1xx response.
Note that 1xx responses are not reliably transmitted. They will not cause the client to send an ACK response. A temporary (1xx) response can contain a message body and a session description.
1.1 100 trying
This response indicates that the server of the next node has received the request and has not executed the specific action of the request (for example, when the database is being opened ). This response, like other temporary responses, has been planted with UAC to resend INVITE requests. The 100 (trying) response is different from other temporary responses. Here, it will never be forwarded to the upstream stream by a stateful proxy.
1.2 180 ringing
UA receives the invite request and tries to prompt the user. This response should generate a local response.
1.3 818 call is being forwarded (Call forwarded)
The server can use this response code to indicate that the call is being forwarded to another destination set.
1.4 182 queued
When the caller is temporarily unable to receive the call, and the server decides to wait in queue for the call, rather than rejecting the call, the server should send this response. When the called party resumes receiving the call, it will return an appropriate final response. For this call status, there can be a phrase indicating the reason, such as: "5 callqueued; Expected waiting time is 15minutes ". The server can provide several 182 (queued) Responses to inform the caller of the queue (for example, the queue is in front of the queue ).
1.5 183 session progress
The 183 (session progress) response is used to indicate the progress of the conversation. Reason-phrase (a sentence that expresses the reason), header domain, or message body can be used to display more information about the call progress.
2. Successful message 2XX
This response indicates that the request is successful.
2.1 200 OK
The request has been processed successfully. This information depends on the response of requests of different methods.
3 forwarding request 3xx
The 3xx series of responses are used to indicate the user's new location information or to forward additional service locations to meet the call requirements.
3.1 300 multiple choices
There are multiple choices for the requested address. Each choice has its own address. The user or (UA) can select an appropriate communication terminal and forward the request to this address.
A response can contain a Resource feature that is allowed in the accept request header domain at each location, so that the user or ua can select the most appropriate address to forward the request. The message body that does not have this response defines the MIME type.
These addresses should also be listed in the contact header field (section 20.10 ). Unlike HTTP, a SIP response can contain multiple contact header domains or a contact header domain with an address list. UA can use the Contact Header domain for automatic forwarding or ask the user to confirm the forwarding. However, this specification does not define the automatic forwarding standard.
If the called party can be found at multiple addresses and the server cannot or is unwilling to forward the request, this response can be used to send the request to the caller.
3.2 301 moved permently
When the user cannot be found at the address specified by request-Uri, the requested client should try again using the new address specified by the Contact Header domain (20.10. The requester should use this new value to update the local directory, address book, and user address cache, and send it to these listed addresses in subsequent requests.
3.3 302 moved temporarily
The requester should re-send the request to the new address (20.10) specified in the contact header domain ). The request-Uri of the new request should use the value specified by the contact header field in the response.
The expires (section 20.19) in the response or the expires parameter in the contact header field defines the lifecycle of the contact Uri. UA or proxy caches the URI in this lifecycle. If there is no strict validity period, this address is only valid this time and cannot be saved in future transactions.
If the value of the contact header field in the cache fails, the request-Uri of the forwarded request should be tried again. A temporary URI can expire faster than the timeout time and have a new temporary Uri.
3.4 305 use proxy
The requested resource must be accessed through the proxy specified in the contact header. The contact header specifies the URI of a proxy. The object receiving this response should resend this single request through this proxy. 305 (useproxy) must be generated by UAS.
3.5 380 alternative service
The call fails, but you can try another service. In addition, the Service is defined in the Response Message Body. The message body format is not defined here and may be defined in future specifications.
4. Request failed 4xx
The 4xx response defines the failure of the Request returned by a specific server. The client should not retry the same request without changing the request. (For example, add appropriate authentication information ). However, the same request may be successfully sent to different servers.
4.1 400 bad request
Syntax Error in the request. Reason-phrase should mark this detailed syntax error, such as "Missing Call-ID header field ".
4.2 401 unauthorized
User authentication is required for the request. This response is generated by the UAS and registration server. When 407 (proxy authentication required) is generated by the proxy server.
4.3 402 payment required
Reserved/used later
4.4 403 Forbidden
The server supports this request, but the request is rejected. Adding verification information is unnecessary and requests should not be retried.
4.5 404 not found
The server returns the final information: the user does not exist in the domain specified by request-Uri. This response is also generated when the domain of request-Uri does not match the domain that receives the request.
4.6 405 method not allowed
The server supports the method in request-line, but the method cannot be applied to the address in the request-Uri.
The response must include an allow header field that contains the list of methods allowed by the specified address.
4.7 not acceptable
The requested resource will only generate an error outside the accept header of the request and the content cannot be received.
4.8 407 proxy authentication required
This return code is similar to 401 (unauthorized), but it indicates that the client must first pass authentication on the proxy. For more information about access to the authentication service, see sections 26 and 22.3.
This return code is used by the application to access the communication gateway (such as the Telephone Gateway), but rarely used by the callee for authentication.
4.9 408 request timeout
Within a period of time, the server cannot generate an ending response, for example, if it cannot determine the user's location in a timely manner. The client can try again later without changing the request content.
4.10 410 gone
The requested resource does not exist on this server and you do 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, a 404 (not found) error should be returned ).
4.11 413 the Request Entity is too large.
The server rejects the request because the request entity exceeds the size that the server wants or can process. The server should close the connection to prevent the client from sending this request again.
If this is temporary, the server should contain a retry-after header to indicate that this is a temporary fault and the client can try again later.
4.12 414 request-URI Too Long
The server rejects this request because the request-Uri exceeds the length that the server can process.
4.13 415 unsupported media type
The server rejects the request because the request message body format is not supported by the server. The server must return an ACCEPT, accpet-encoding, or accept-Language Header domain list based on the fault type of the content. UAC processes this response according to the method defined in section 8.1.3.5.
4.14 416 unsupported URI Scheme
The server terminates the request because it does not support the URI scheme in request-Uri. For the client to process this response, see 8.1.3.5.
4.15 bad Extension
The server does not know the Protocol extensions specified by the proxy-require (20.29) or require (20.32) header in the request. The server must list unsupported extensions in the unsupported header field. For how UAC handles this response, see 8.1.3.5
4.16 421 extension required
UAS requires a specific extension to process this request, but this extension is not listed in the supported header domain of the request. The response with this response code must contain a require header domain to list the required extensions.
UAS should not use this response unless it really cannot provide valid services to the client. Conversely, if the required extensions are not listed in the support header domain, the server should handle them based on the benchmark sip-compatible method and client-supported extensions.
4.17 423 interval too brief
The server rejects the request because the resource refresh time (or validity period) set in the request is too short. This response can be used to register servers to reject registration requests with too short contact header domain validity periods. The usage of this response and the related min-expires header fields are described and described in sections 10.2.8, 10.3, and 20.23.
4.18 480 temporarily unavailable
The request has successfully arrived at the terminal system of the called party, but the called party is currently unavailable (for example, if you have not logged on, or logged on, but cannot communicate, or you have a "do not disturb" flag ). The response should be retried-after with a suitable resend time. This user may also be valid elsewhere (not known on the server ). Reason-phrase (reason short) should prompt more detailed reasons why the called party is temporarily unavailable. This value should be set by UA. The 486 (busy here) status code can be used to more accurately indicate the specific cause of the Request failure.
This status code can also be returned by the forwarding service or the proxy server because they find that the user specified by request-Uri exists, but there is no suitable address for the user to forward.
4.19 481 call/transaction does not exist
This status indicates that the UAS receives the request but does not match the existing dialog or transaction.
4.20 482 loop Detected
The server detects a loop (16.3/4)
4.21 483 too average hops
The server receives a request containing the max-forwards (20.22) header field 0.
4.22 484 address incomplete
When the server receives a request, its request-Uri is incomplete. Additional information should be included in the reason phrase. This status code can overlap with dialing. The client does not know the length of the dialing string when it overlaps with the dialing. It sends a string with an increased length and prompts the user to enter more strings until the 484 (address incomplete) response does not appear.
4.23 485 ambiguous
The request-Uri is not clear. A Possible Clear address list can be contained in the contact header. This prompt list may cause damage to users or organizations in terms of security and privacy. You must be able to determine whether to replace this response with 404 (notfound) by configuration, or disable the use of possible selection lists for ambiguous addresses.
An example of a response to a request with request-Uri:
SIP: lee@example.com:
Sip/2.0 485 ambiguous
Contact: Carol Lee
Contact: Ping Lee
Contact: Lee M. Foote
Some email and voice mail systems provide this function. This status code is different from the 3xx status code: for 300, it assumes that the same person or service has different address options. Therefore, for 3xx, automatic system selection or continuous search is effective, but for 485 (ambiguous) responses, user intervention is required.
4.24 486 busy here
When the caller successfully contacts the caller's terminal system, but the caller cannot answer the call on the terminal system, then the response should be sent back to the caller at a more appropriate time in the retry-after header domain for retry. This user may be valid elsewhere, such as the phone and email system. If we know that no other terminal system can answer this call, we should return a status code 600 (busy everywhere ).
4.25 487 request terminated
The request is terminated by bye or cancel. This response will never reply to the cancel request itself.
4.26 488 not acceptable here
This response has the same meaning as 606 (not acceptable), but it is only applied to the specific resource specified by request-Uri and may be accepted elsewhere.
A Message Body Containing the media compatibility description can appear in the response and be normalized Based on the accept header field in the invite request (if there is no accept header field, it is application/SDP ). This response is like the message body that responds to the options request 200 (OK.
4.27 491 request pending
In the same dialog, the request received by UAS has a dependent request being processed. 14.2 describes how this situation should be solved.
4.28 493 undecipherable
UAS receives a request that contains an encrypted mime and does not know or provide a suitable decryption key. This response can contain a single packet body, which contains the appropriate public key used to encrypt the packet body in UAS communication. Details are described in section 23.2.
5 Server failure 5xx
The 5xx response is a failure response provided when the server itself fails.
5.1 500 server internal error
The server encounters an unknown situation and cannot continue to process the request. The client can display specific error conditions and try the request again after several seconds.
If this is temporary, the server should try the request again after the retry-after header domain marks how many seconds the client has passed.
5.2 501 not implemented
The server does not implement related request functions. When UAS does not know the Request Method and does not support this method for every user, it should return this response. (Proxy forwards the request without considering the request method ).
Note that 405 (method not allowed) is because the server implements this request method, but this request method is not supported in a specific request.
5.3 502 Bad Gateway
If the server exists as a gateway or proxy, an invalid response is received from the downstream server (the request corresponding to this response is forwarded to the downstream server to complete the request ).
5.4 503 service unavailable
The server is temporarily unavailable due to temporary overload or server management. This server can add a retry-after in the response to allow the client to retry the request. If no retry-after clause is specified, the client must process the request as if it received a 500 (server internal error) response.
When the client (proxy or UAC) receives the 503 (Service unavailable) request, it should try to forward the request to another server for processing. In addition, other requests should not be forwarded 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.
5.5 504 server time-out
The server does not receive a prompt response on an external server. This external server is used by this server to access and process 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. The server cannot process requests with the same major version number provided by the client, which leads to such an error.
5.7 message to large
The server cannot process the request because the message length exceeds the processing length.
6 Global failures 6xx
The 6xx response indicates that the server provides a final message to a specific user, not only when the request-Uri instance has final information.
6.1 600 busy everywhere
The caller is successfully contacted by the caller's terminal system. However, the caller is busy and does not intend to answer the call. You can add a retry-after header to explicitly tell the caller how long it will take to continue the call. If the called party does not want to prompt the reason for rejection, the called party should use decline ). This response can be used only when the terminal system knows that no terminal node (such as the voice mailbox system) can access this user. Otherwise, a 486 (busy here) response should be returned.
6.2 603 decline
When the caller's device is successfully accessed, the user explicitly does not want to respond. You can add a retry-after header to explicitly tell the caller how long it will take to continue the call. Only when the terminal knows that no other terminal device can respond to this call can this response be provided.
6.3 604 does not exists anywhere
The server verifies the user information of the request-URI in the request and does not exist anywhere.
6.4 606 not acceptable
When a UA is successfully connected, 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 cannot fully support the Session Description. 606 (not acceptable) a response can contain a reason list in the warning header to explain why the session description is not supported. The warning cause code is listed in section 20.43.
In the response, a message body containing the media compatibility description can appear. The message body format is normalized according to the format specified by the accept header field in the invite request (if there is no accept header field, it is application/SDP), just like the message in the 200 (OK) Response to options.
We hope that media negotiation is not frequently required. When a new user is invited to join an existing session, this media negotiation may not be required. This depends on whether the invited initiator needs to process 606 (not acceptable.
This response can be sent only when the client knows that no other terminal can process this request.