SIP signaling response status code

type	status code	Status description	Detailed explanation
provisional reply （1XX）	100 Trying	Processing	This response indicates that the next node's server has received the request and has not yet performed specific actions for the request (for example, when opening a database). This response, like other provisional responses, causes UAC to retransmit the INVITE request. The difference between the 100 (Trying) response and other temporary responses is that here it is never forwarded upstream by the stateful proxy.
	180 Ringing	Ring	The UA receives the INVITE request and attempts to prompt the user. This response should initiate a local ringback.
	181 Call being forwarder	call forwarded	The server can use this response code to indicate that the call is being forwarded to another set of destinations.
	182 Queue	queue	This response should be issued when the callee is temporarily unavailable and the server decides to queue the call rather than reject it. 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 calls queued; expected waiting time is 15minutes". The server can give several 182 (Queued) responses to tell the caller the queuing situation (such as being at the front of the queue, etc.).
	183 Session progress	Conversation in progress	The 183 (Session Progress) response is used to prompt progress information about establishing a conversation. Reason-Phrase (sentences expressing reasons), header fields, or message bodies can be used to provide more information about the progress of the call.
Session successful （2XX）	200 OK	Session successful	The request has been processed successfully. This information depends on the response to the request of different methods.
Redirect （3XX）	300 Multiple	multiple choices	There are multiple choices for the requested address, each choice has its own address. The user or (UA) can select the appropriate communication terminal and forward the request to this address.  The response MAY contain a resource attribute with each location allowed in the Accept request header field, so that the user or UA can choose the most appropriate address to forward the request to. There is no MIME type defined for the message body of this response.  These address options SHOULD also be listed in the Contact header field (Section 20.10). Unlike HTTP, SIP responses can contain multiple Contact header fields or a list of addresses in a Contact header field. The UA can use the Contact header field to automatically forward or ask the user to confirm the forwarding. However, this specification does not define standards for automatic forwarding.  This response can be used to give the caller if the called party can be found at multiple addresses and the server is unable or unwilling to forward the request.
	301 Moved permanently	move permanently	When the user cannot be found at the address specified by the 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 to this/these listed addresses on subsequent requests.
	302 Moved temporaily	temporary move	The requester should resend the request to the new address (20.10) indicated by the Contact header field. The Request-URI of the new request should use the value indicated by the Contact header field of this response.  The Expires (Section 20.19) in the response or the expires parameter in the Contact header field defines the lifetime of this Contact URI. UA or proxy caches this URI during this life cycle. If there is no strict validity time, then the address is only valid for this time and cannot be saved in future transactions.  If the value of the cached Contact header field fails, the Request-URI of the forwarded request SHOULD try again. A temporary URI can expire sooner than the timeout period, and a new temporary URI can be created.
	305 Use proxy	user agent	The requested resource must be accessed through the proxy indicated in the Contact header field. The Contact header field specifies a proxy URI. The object receiving this response should resend the single request through this proxy. 305 (UseProxy) must be generated by UAS.
	380 Alternative service	alternative services	The call doesn't work, but you can try another service. Additional services are defined in the response message body. The format of the message body is not defined here and may be defined in a future specification.
Request failed （4XX）	400 Bad request	Bad request	Syntax error in request. Reason-Phrase should flag this detailed syntax error, such as "Missing Call-ID header field".
	401 Unauthorized	unauthorized	The request requires user authentication. This response is generated by the UAS and the registration server, when 407 (Proxy Authentication Required) is generated by the proxy server.
	402 Payment required	Payment requirements	Keep/use later
	403 Forbidden	prohibit	The server supports this request, but refuses to execute the request. Adding authentication information is not necessary, and the request should not be retried.
	404 Not found	Not found	服务器返回最终信息：用户在Request-URI指定的域上不存在。当Request-URI的domain和接收这个请求的domain不匹配的情况下， 也会产生这个应答。
	405 Method no allowed	方法不允许	服务器支持Request-Line中的方法，但是对于这个Request-URI中的地址来说，是不允许应用这个方法的。  应答必须包括一个Allow头域，这个头域包含了指定地址允许的方法列表。
	406 Not acceptable	不可接受	请求中的资源只会导致产生一个在请求中的Accept头域外的，内容无法接收的错误。
	407 Provy authentication required	代理需要认证	这个返回码和401（Unauthorized）很类四，但是标志了客户端应当首先在proxy上通过认证。SIP对认证的访问请参见26节和22.3节。  这个返回码用于应用程序访问通讯网关（比如，电话网关），而很少用于被叫方要求认证。
	408 Request timeout	请求超时	在一段时间内，服务器不能产生一个终结应答，例如，如果它无法及时决定用户的位置。客户端可以在稍后不更改请求的内容然后重新尝试请求。
	410 Gone	离开	请求的资源在本服务器上已经不存在了，并且不知道应当把请求转发到哪里。这个问题将会使永久性的。如果服务器不知道，或者不容易检测，这个资源消失是临时性质的还是永久性质的，那么应当返回一个404（Not Found）。
	413 Request entity too large	请求实体太大	服务器拒绝处理请求，因为这个请求的实体超过了服务器希望或者能够处理的大小。这个服务器应当关闭连接避免客户端重发这个请求。  如果这个情况是暂时的，那么服务端应当包含一个Retry-After头域来表明这是一个暂时的故障，并且客户端可以过一段时间再次尝试。
	414 Request-url too long	请求URL太长	服务器拒绝这个请求，因为Request-URI超过了服务器能够处理的长度。
	415 Unsupported media type	不支持的媒体类型	服务器由于请求的消息体的格式本服务器不支持，所以拒绝处理这个请求。这个服务器必须根据内容的故障类型，返回一个Accept，Accpet-Encoding,或者Accept-Language头域列表。UAC根据8.1.3.5节定义的方法处理这个应答。
	416 Unsupported url scheme	不支持的URL计划	服务器由于不支持Request-URI中的URI方案而终止处理这个请求。客户端处理这个应答参照8.1.3.5。
	420 Bad extension	不良扩展	服务器不知道在请求中的Proxy-Require(20.29)或者Require(20.32)头域所指出的协议扩展。服务器必须在Unsupported头域中列出不支持的扩展。UAC处理这个应答请参见8.1.3.5
	421 Extension required	需要扩展	UAS需要特定的扩展来处理这个请求，但是这个扩展并没有在请求的Supported头域中列出。具有这个应答码的应答必须包含一个Require头域列出所需要的扩展。  UAS不应当使用这个应答除非它真的不能给客户端提供有效的服务。相反，如果在Support头域中没有列出需要的扩展，服务器应当根据基准的SIP兼容的方法和客户端支持的扩展来进行处理。
	423 interval too brief	间隔太短	服务器因为在请求中设置的资源刷新时间（或者有效时间）过短而拒绝请求。这个应答可以用于注册服务器来拒绝那些Contact头域有效期过短的注册请求。这个应答的用法和相关的Min-Expires头域在10.2.8,10.3,20.23节中介绍和说明。
	480 Temporarily unavailable	临时失效	请求成功到达被叫方的终端系统，但是被叫方当前不可用（例如，没有登陆，或者登陆了但是状态是不能通讯，或者有”请勿打扰”的标记）。应答应当在 Retry-After中标志一个合适的重发时间。这个用户也有可能在其他地方是有效的（在本服务器中不知道）。Reason-Phrase(原因短句) 应当提示更详细的原因，为什么被叫方暂时不可用。这个值应当是可以被UA设置的。状态码486（Busy Here）可以用来更精确的表示本请求失败的特定原因。  这个状态码也可以是转发服务或者proxy服务器返回的，因为他们发现Request-URI指定的用户存在，但是没有一个给这个用户的合适的当前转发的地址。
	481 call/Transaction does not exist	呼叫/事务不存在	这个状态表示了UAS接收到请求，但是没有和现存的对话或者事务匹配。
	482 loop detected	发现环路	服务器检测到了一个循环(16.3/4)
	483 too many hops	跳数太多	服务器接收到了一个请求包含的Max-Forwards(20.22)头域是0
	484 address incomplete	地址不完整	服务器接收到了一个请求，它的Request-URI是不完整的。在原因短语中应当有附加的信息说明。这个状态码可以和拨号交叠。在和拨号交叠中，客户端 不知道拨号串的长度。它发送增加长度的字串，并且提示用户输入更多的字串，直到不在出现484（Address Incomplete）应答为止。
	485 ambiguous	不明朗	Request-URI是不明确的。应答可以在Contact头域中包含一个可能的明确的地址列表。这个提示列表肯囊个在安全性和隐私性对用户或者组织造 成破坏。必须能够由配置决定是否以404（NotFound）代替这个应答，又或者禁止对不明确的地址使用可能的选择列表。  给带有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]>  部分email和语音邮箱系统提供了这个功能。这个状态码和3xx状态码不同：对于300来说，它是假定同一个人或者服务有不同的地址选择。所以对3xx来说，自动选择系统或者连续查找就有效，但是对485（Ambiguous）应答来说，一定要用户的干预。
	486 busy here	这里忙	当成功联系到被叫方的终端系统，但是被叫方当前在这个终端系统上不能接听这个电话，那么应答应当回给呼叫方一个更合适的时间在Retry-After头域 重试。这个用户也许在其他地方有效，比如电话邮箱系统等等。如果我们知道没有其他终端系统能够接听这个呼叫，那么应当返回一个状态码600（Busy Everywhere）。
	487 request terminated	请求终止	请求被BYE或者CANCEL所终止。这个应答永远不会给CANCEL请求本身回复。
	488 not acceptable here	这里请求不可接受	这个应答和606（Not Acceptable）有相同的含义，但是只是应用于Request-URI所指出的特定资源不能接受，在其他地方请求可能可以接受。  包含了媒体兼容性描述的消息体可以出现在应答中，并且根据INVITE请求中的Accept头域进行规格化（如果没有Accept头域，那么就是application/sdp）。这个应答就像给OPTIONS请求的200(OK)应答的消息体一样。
	491 request pending	未决请求	在同一个对话中，UAS接收到的请求有一个依赖的请求正在处理。14.2描述了这种情况应当怎样解决。
	493 undecipherable	不可辨识	UAS接收到了一个请求，包含了一个加密的MIME,并且不知道或者没有提供合适的解密密钥。这个应答可以包含单个包体，这个包体包含了合适的公钥，这个公钥用于给这个UAS通讯中加密包体使用的。细节描述在23.2节。
服务器失败 (5XX)	500 server internal error	服务器内部错误	服务器遇到了未知的情况，并且不能继续处理请求。客户端可以显示特定的错误情况，并且可以在几秒种以后重新尝试这个请求。  如果这个情况是临时的，服务器应当在Retry-After头域标志客户端过多少秒钟之后重新尝试这个请求。
	501 not implemented	不可执行	服务器没有实现相关的请求功能。当UAS不认识请求的方法的时候，并且对每一个用户都无法支持这个方法的时候，应当返回这个应答。（proxy不考虑请求的方法而转发请求）。  注意405（Method Not Allowed）是因为服务器实现了这个请求方法，但是这个请求方法在特定请求中不被支持。
	502 bad gateway	坏网关	如果服务器，作为gateway或者proxy存在，从下行服务器上接收到了一个非法的应答（这个应答对应的请求是本服务器为了完成请求而转发给下行服务器的）。
	503 service unavailable	服务无效	由于临时的过载或者服务器管理导致的服务器暂时不可用。这个服务器可以在应答中增加一个Retry-After来让客户端重试这个请求。如果没有Retry-After指出，客户端必须就像收到了一个500（Server Internal Error）应答一样处理。  客户端（proxy或者UAC）收到503（Service Unavailable）应当尝试转发这个请求到另外一个服务器处理。并且在Retry-After头域中指定的时间内，不应当转发其他请求到这个服务器。  作为503(Service Unavaliable)的替代，服务器可以拒绝连接或者把请求扔掉。
	504 server time-out	服务器超时	服务器在一个外部服务器上没有收到一个及时的应答。这个外部服务器是本服务器用来访问处理这个请求所需要的。如果从上行服务器上收到的请求中的Expires头域超时，那么应当返回一个408（Request TimeOut）错误。
	505 version not supported	版本不支持	服务器不支持对应的SIP版本。服务器是无法处理具有客户端提供的相同主版本号的请求，就会导致这样的错误信息。
	513 message too large	消息太大	服务器无法处理请求，因为消息长度超过了处理的长度。
全局性错误(6XX)	600 busy everywhere	全忙	成功联系到被叫方的终端系统，但是被叫方处于忙的状态，并不打算接听电话。这个应答可以通过增加一个Retry-After头域更明确的告诉呼叫方多久以 后可以继续呼叫。如果被叫方不希望提示拒绝的原因，被叫方应当使用603（Decline）。只有当终端系统知道没有其他终端节点（比如语音邮箱系统）能 够访问到这个用户的时候才能使用这个应答。否则应当返回一个486（Busy Here）的应答。
	603 decline	丢弃	当成功访问到被叫方的设备，但是用户明确的不想应答。这个应答可以通过增加一个Retry-After头域更明确的告诉呼叫方多久以后可以继续呼叫。只有当终端知道没有其他任何终端设备能够响应这个呼叫的势能才能给出这个应答。
	604 does not exist anywhere	不存在	服务器验证了在请求中Request-URI的用户信息，哪里都不存在
	606 not acceptable	不可接受	当成功联系到一个UA,但是会话描述的一些部分比如请求的媒体，带宽，或者地址类型不被接收。  606（NotAcceptable）应答意味着用户希望通讯，但是不能充分支持会话描述。606（Not Acceptable）应答可以在Warning头域中包含一个原因列表，用于解释为何会话描述不能被支持。警告原因代码在20.43节中列出。  在应答中，可以出现一个包含媒体兼容性描述的消息体，这个消息体的格式根据INVITE请求中的Accept头域指出的格式进行规格化（如果没有Accept头域，那么就是application/sdp），就像给OPTIONS亲求的200(OK)应答中的消息一样。  我们希望这些媒体协商不要经常需要，并且当一个新用户被邀请加入已经存在的会话的时候，这个媒体协商可能不需要。这取决于邀请的初始化者是否需要对606（Not Acceptable）进行处理。  这个应答只有当客户端知道没有其他终端能够处理这个请求的时候才能发出。