Sip 响应状态码功能对照详解

SIP应答消息状态码与类型 状态码 状态说明
临时应答(1XX) 100 Trying 正在处理中
180 Ringing 振铃
181 call being forwarder 呼叫正在前向
182 queue 排队
181* session progress 会话进行

会话成功(2XX) 200 OK 会话成功
重定向(3XX) 300 multiple 多重选择
301 moved permanently 永久移动
302 moved temporaily 临时移动
305 use proxy 用户代理
380 alternative service 替代服务
请求失败(4XX) 400 bad request 错误请求
401unauthorized 未受权
402 payment required 付费要求
403 forbidden 禁止
404 not found 未发现
405 method no allowed 方法不容许
406 not acceptable 不可接受
407 proxy authentication required 代理须要认证
408 request timeout 请求超时
410 gone 离开
413 request entity too large 请求实体太大
414 request-url too long 请求URL太长
415 unsupported media type 不支持的媒体类型
416 unsupported url scheme 不支持的URL计划
420 bad extension 不良扩展
421 extension required 须要扩展
423 interval too brief 间隔过短
480 temporarily unavailable 临时失效
481 call/transaction does not exist 呼叫/事务不存在
482 loop detected 发现环路
483 too many hops 跳数太多
484 address incomplete 地址不完整
485 ambiguous 不明朗
486 busy here 这里忙
487 request terminated 请求终止
488 not acceptable here 这里请求不可接受
491 request pending 未决请求
493 undecipherable 不可辨识

服务器失败(5XX) 500 server internal error 服务器内部错误
501 not implemented 不可执行
502 bad gateway 坏网关
503 service unavailable 服务无效
504 server time-out 服务器超时
505 version not supported 版本不支持
513 message too large 消息太大

全局性错误(6XX) 600 busy everywhere 全忙
603 decline 丢弃
604 does not exist anywhere 不存在
606 not acceptable 不可接受
SIP应答代码(如下是详细内容)

应答码是包含了，而且扩展了HTTP/1.1应答码。并非全部的HTTP/1.1应答码都适当应用，只有在折里指出的是适当的。其余HTTP/1.1应答码不该当使用。而且，SIP也定义了新的应答码系列，6xx。
1 临时应答1xx
临时应答，也就是消息性质的应答，标志了对方服务器正在处理请求，而且尚未决定最后的应答。若是服务器处理请求须要花200ms以上才能产生终结应答的时候，它应当发送一个1xx应答。
注意1xx应答并非可靠传输的。他们不会致使客户端传送一个ACK应答。临时性质的（1xx）应答能够包含消息体，包含会话描述。
1.1 100 Trying
这个应答表示下一个节点的服务器已经接收到了这个请求而且尚未执行这个请求的特定动做（好比，正在打开数据库的时候）。这个应答，就像其余临时应答一 样，种植了UAC从新传送INVITE请求。100(Trying)应答和其余临时应答不一样的是，在这里，它永远不会被有状态proxy转发到上行流中。
1.2 180 Ringing
UA收到INVITE请求而且试图提示给用户。这个应答应当出世化一个本地回铃。
1.3 818 Call is Being Forwarded(呼叫被转发)
服务器能够用这个应答代码来表示呼叫正在转发到另外一个目的地集合。
1.4 182 Queued
当 呼叫的对方暂时不能接收呼叫的时候，而且服务器决定将呼叫排队等候，而不是拒绝呼叫的时候，那么就应当发出这个应答。当被叫方一旦恢复接收呼叫，他会返回 合适的终结应答。对于这个呼叫状态，能够有一个表示缘由的短语，好比：”5 calls queued;expected waiting time is 15minutes”。服务器能够给出好几个182（Queued）应答告诉呼叫方排队的状况（好比排队靠前了等等）。
1.5 183 会话进度
183（Session Progress）应答用于提示创建对话的进度信息。Reason-Phrase（表达缘由的句子）、头域或者消息体能够用于提示呼叫进度的更消息的信息。
2 成功信息2xx
这个应答表示请求是成功的。
2.1 200 OK
请求已经处理成功。这个信息取决于不一样方法的请求的应答。
3 转发请求3XX
3xx系列的应答是用于提示用户的新位置信息的，或者为了知足呼叫而转发的额外服务地点。
3.1 300 Multiple Choices
请求的地址有多个选择，每一个选择都有本身的地址，用户或者（UA）能够选择合适的通信终端，而且转发这个请求到这个地址。
应答能够包含一个具备每个地点的在Accept请求头域中容许的资源特性，这样用户或者UA能够选择一个最合适的地址来转发请求。没有未这个应答的消息体定义MIME类型。
这些地址选择也应当在Contact头域中列出（20.10节）。不一样于HTTP，SIP应答能够包含多个Contact头域或者一个Contact头域 中具备一个地址列表。UA可使用Contact头域来自动转发或者要求用户确认转发。不过，本规范没有定义自动转发的标准。
若是被叫方能够在多个地址被找到，而且服务器不能或者不肯意转发请求的时候，可使用这个应答来给呼叫方。
3.2 301 Moved Permently
当不能在Request-URI指定的地址找到用户的时候，请求的客户端应当使用Contact头域(20.10)所指出的新的地址从新尝试。请求者应当用这个新的值来更新本地的目录，地址本，和用户地址cache，而且在后续请求中，发送到这个/这些列出的地址。
3.3 302 Moved Temporarily
请求方应当把请求从新发到这个Contact头域所指出的新地址(20.10)。新请求的Request-URI应当用这个应答的Contact头域所指出的值。
在应答中的Expires(20.19节)或者Contact头域的expires参数定义了这个Contact URI的生存周期。UA或者proxy在这个生存周期内cache这个URI。若是没有严格的有效时见，那么这个地址仅仅本次有效，而且不能在之后的事务 中保存。
若是cache的Contact头域的值失败了，那么被转发请求的Request-URI应当再次尝试一次。临时URI能够比超时时间更快的失效，而且能够有一个新的临时URI。
3.4 305 Use Proxy
请求的资源必须经过Contact头域中指出的proxy来访问。Contact头域指定了一个proxy的URI。接收到这个应答的对象应当经过这个proxy从新发送这个单个请求。305（UseProxy）必须是UAS产生的。
3.5 380 Alternative Service
呼叫不成工，可是能够尝试另外的服务。另外的服务在应答的消息体中定义。消息体的格式在这里没有定义，可能在之后的规范中定义。
4 请求失败4xx
4xx应答定义了特定服务器响应的请求失败的状况。客户端不该当在不更改请求的状况下从新尝试同一个请求。（例如，增长合适的认证信息）。不过，同一个请求交给不一样服务器也许就会成功。
4.1 400 Bad Request
请求中的语法错误。Reason-Phrase应当标志这个详细的语法错误，好比”Missing Call-ID header field”。
4.2 401 Unauthorized
请求须要用户认证。这个应答是由UAS和注册服务器产生的，当407（Proxy Authentication Required）是proxy服务器产生的。
4.3 402 Payment Required
保留/之后使用
4.4 403 Forbidden
服务端支持这个请求，可是拒绝执行请求。增长验证信息是没有必要的，而且请求应当不被重试。
4.5 404 Not Found
服务器返回最终信息：用户在Request-URI指定的域上不存在。当Request-URI的domain和接收这个请求的domain不匹配的状况下， 也会产生这个应答。
4.6 405 Method Not Allowed
服务器支持Request-Line中的方法，可是对于这个Request-URI中的地址来讲，是不容许应用这个方法的。
应答必须包括一个Allow头域，这个头域包含了指定地址容许的方法列表。
4.7 Not Acceptable
请求中的资源只会致使产生一个在请求中的Accept头域外的，内容没法接收的错误。
4.8 407 Proxy Authentication Required
这个返回码和401（Unauthorized）很类四，可是标志了客户端应当首先在proxy上经过认证。SIP对认证的访问请参见26节和22.3节。
这个返回码用于应用程序访问通信网关（好比，电话网关），而不多用于被叫方要求认证。
4.9 408 Request Timeout
在一段时间内，服务器不能产生一个终结应答，例如，若是它没法及时决定用户的位置。客户端能够在稍后不更改请求的内容而后从新尝试请求。
4.10 410 Gone
请求的资源在本服务器上已经不存在了，而且不知道应当把请求转发到哪里。这个问题将会使永久性的。若是服务器不知道，或者不容易检测，这个资源消失是临时性质的仍是永久性质的，那么应当返回一个404（Not Found）。
4.11 413请求实体过大。
服务器拒绝处理请求，由于这个请求的实体超过了服务器但愿或者可以处理的大小。这个服务器应当关闭链接避免客户端重发这个请求。
若是这个状况是暂时的，那么服务端应当包含一个Retry-After头域来代表这是一个暂时的故障，而且客户端能够过一段时间再次尝试。
4.12 414 Request-URI Too Long
服务器拒绝这个请求，由于Request-URI超过了服务器可以处理的长度。
4.13 415 Unsupported Media Type
服务器因为请求的消息体的格式本服务器不支持，因此拒绝处理这个请求。这个服务器必须根据内容的故障类型，返回一个Accept，Accpet-Encoding,或者Accept-Language头域列表。UAC根据8.1.3.5节定义的方法处理这个应答。
4.14 416 Unsupported URI Scheme
服务器因为不支持Request-URI中的URI方案而终止处理这个请求。客户端处理这个应答参照8.1.3.5。
4.15 Bad Extension
服务器不知道在请求中的Proxy-Require(20.29)或者Require(20.32)头域所指出的协议扩展。服务器必须在Unsupported头域中列出不支持的扩展。UAC处理这个应答请参见8.1.3.5
4.16 421Extension Required
UAS须要特定的扩展来处理这个请求，可是这个扩展并无在请求的Supported头域中列出。具备这个应答码的应答必须包含一个Require头域列出所须要的扩展。
UAS不该当使用这个应答除非它真的不能给客户端提供有效的服务。相反，若是在Support头域中没有列出须要的扩展，服务器应当根据基准的SIP兼容的方法和客户端支持的扩展来进行处理。
4.17 423 Interval Too Brief
服务器由于在请求中设置的资源刷新时间（或者有效时间）太短而拒绝请求。这个应答能够用于注册服务器来拒绝那些Contact头域有效期太短的注册请求。这个应答的用法和相关的Min-Expires头域在10.2.8,10.3,20.23节中介绍和说明。
4.18 480 Temporarily Unavailable
请求成功到达被叫方的终端系统，可是被叫方当前不可用（例如，没有登录，或者登录了可是状态是不能通信，或者有”请勿打扰”的标记）。应答应当在 Retry-After中标志一个合适的重发时间。这个用户也有可能在其余地方是有效的（在本服务器中不知道）。Reason-Phrase(缘由短句) 应当提示更详细的缘由，为何被叫方暂时不可用。这个值应当是能够被UA设置的。状态码486（Busy Here）能够用来更精确的表示本请求失败的特定缘由。
这个状态码也能够是转发服务或者proxy服务器返回的，由于他们发现Request-URI指定的用户存在，可是没有一个给这个用户的合适的当前转发的地址。
4.19 481 Call/Transaction Does Not Exist
这个状态表示了UAS接收到请求，可是没有和现存的对话或者事务匹配。
4.20 482 Loop Detected
服务器检测到了一个循环(16.3/4)
4.21 483 Too Many Hops
服务器接收到了一个请求包含的Max-Forwards(20.22)头域是0
4.22 484 Address InComplete
服务器接收到了一个请求，它的Request-URI是不完整的。在缘由短语中应当有附加的信息说明。这个状态码能够和拨号交叠。在和拨号交叠中，客户端 不知道拨号串的长度。它发送增长长度的字串，而且提示用户输入更多的字串，直到不在出现484（Address Incomplete）应答为止。
4.23 485 Ambiguous
Request-URI是不明确的。应答能够在Contact头域中包含一个可能的明确的地址列表。这个提示列表肯囊个在安全性和隐私性对用户或者组织造 成破坏。必须可以由配置决定是否以404（NotFound）代替这个应答，又或者禁止对不明确的地址使用可能的选择列表。
给带有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>
部分email和语音邮箱系统提供了这个功能。这个状态码和3xx状态码不一样：对于300来讲，它是假定同一我的或者服务有不一样的地址选择。因此对3xx来讲，自动选择系统或者连续查找就有效，可是对485（Ambiguous）应答来讲，必定要用户的干预。
4.24 486 Busy Here
当成功联系到被叫方的终端系统，可是被叫方当前在这个终端系统上不能接听这个电话，那么应答应当回给呼叫方一个更合适的时间在Retry-After头域 重试。这个用户也许在其余地方有效，好比电话邮箱系统等等。若是咱们知道没有其余终端系统可以接听这个呼叫，那么应当返回一个状态码600（Busy Everywhere）。
4.25 487 Request Terminated
请求被BYE或者CANCEL所终止。这个应答永远不会给CANCEL请求自己回复。
4.26 488 Not Acceptable Here
这个应答和606（Not Acceptable）有相同的含义，可是只是应用于Request-URI所指出的特定资源不能接受，在其余地方请求可能能够接受。
包含了媒体兼容性描述的消息体能够出如今应答中，而且根据INVITE请求中的Accept头域进行规格化（若是没有Accept头域，那么就是application/sdp）。这个应答就像给OPTIONS请求的200(OK)应答的消息体同样。
4.27 491 Request Pending
在同一个对话中，UAS接收到的请求有一个依赖的请求正在处理。14.2描述了这种状况应当怎样解决。
4.28 493 Undecipherable
UAS接收到了一个请求，包含了一个加密的MIME,而且不知道或者没有提供合适的解密密钥。这个应答能够包含单个包体，这个包体包含了合适的公钥，这个公钥用于给这个UAS通信中加密包体使用的。细节描述在23.2节。
5 Server Failure 5xx
5xx应答是当服务器自己故障的时候给出的失败应答。
5.1 500 Server Internal Error
服务器遇到了未知的状况，而且不能继续处理请求。客户端能够显示特定的错误状况，而且能够在几秒种之后从新尝试这个请求。
若是这个状况是临时的，服务器应当在Retry-After头域标志客户端过多少秒钟以后从新尝试这个请求。
5.2 501 Not Implemented
服务器没有实现相关的请求功能。当UAS不认识请求的方法的时候，而且对每个用户都没法支持这个方法的时候，应当返回这个应答。（proxy不考虑请求的方法而转发请求）。
注意405（Method Not Allowed）是由于服务器实现了这个请求方法，可是这个请求方法在特定请求中不被支持。
5.3 502 Bad Gateway
若是服务器，做为gateway或者proxy存在，从下行服务器上接收到了一个非法的应答（这个应答对应的请求是本服务器为了完成请求而转发给下行服务器的）。
5.4 503 Service Unavailable
因为临时的过载或者服务器管理致使的服务器暂时不可用。这个服务器能够在应答中增长一个Retry-After来让客户端重试这个请求。若是没有Retry-After指出，客户端必须就像收到了一个500（Server Internal Error）应答同样处理。
客户端（proxy或者UAC）收到503（Service Unavailable）应当尝试转发这个请求到另一个服务器处理。而且在Retry-After头域中指定的时间内，不该当转发其余请求到这个服务器。
做为503(Service Unavaliable)的替代，服务器能够拒绝链接或者把请求扔掉。
5.5 504 Server Time-out
服务器在一个外部服务器上没有收到一个及时的应答。这个外部服务器是本服务器用来访问处理这个请求所须要的。若是从上行服务器上收到的请求中的Expires头域超时，那么应当返回一个408（Request TimeOut）错误。
5.6 505 Version Not Supported
服务器不支持对应的SIP版本。服务器是没法处理具备客户端提供的相同主版本号的请求，就会致使这样的错误信息。
5.7 Message To Large
服务器没法处理请求，由于消息长度超过了处理的长度。
6 Global Failures 6xx
6xx应答意味这服务器给特定用户有一个最终的信息，并不仅是在Request-URI的特定实例有最终信息。
6.1 600 Busy Everywhere
成功联系到被叫方的终端系统，可是被叫方处于忙的状态，并不打算接听电话。这个应答能够经过增长一个Retry-After头域更明确的告诉呼叫方多久以 后能够继续呼叫。若是被叫方不但愿提示拒绝的缘由，被叫方应当使用603（Decline）。只有当终端系统知道没有其余终端节点（好比语音邮箱系统）能 够访问到这个用户的时候才能使用这个应答。不然应当返回一个486（Busy Here）的应答。
6.2 603 Decline
当成功访问到被叫方的设备，可是用户明确的不想应答。这个应答能够经过增长一个Retry-After头域更明确的告诉呼叫方多久之后能够继续呼叫。只有当终端知道没有其余任何终端设备可以响应这个呼叫的势能才能给出这个应答。
6.3 604 Does Not Exists Anywhere
服务器验证了在请求中Request-URI的用户信息，哪里都不存在
6.4 606 Not Acceptable
当成功联系到一个UA,可是会话描述的一些部分好比请求的媒体，带宽，或者地址类型不被接收。
606（NotAcceptable）应答意味着用户但愿通信，可是不能充分支持会话描述。606（Not Acceptable）应答能够在Warning头域中包含一个缘由列表，用于解释为什么会话描述不能被支持。警告缘由代码在20.43节中列出。
在应答中，能够出现一个包含媒体兼容性描述的消息体，这个消息体的格式根据INVITE请求中的Accept头域指出的格式进行规格化（若是没有Accept头域，那么就是application/sdp），就像给OPTIONS亲求的200(OK)应答中的消息同样。
咱们但愿这些媒体协商不要常常须要，而且当一个新用户被邀请加入已经存在的会话的时候，这个媒体协商可能不须要。这取决于邀请的初始化者是否须要对606（Not Acceptable）进行处理。
这个应答只有当客户端知道没有其余终端可以处理这个请求的时候才能发出。