sip错误代码报告

《sip错误代码报告》由会员分享，可在线阅读，更多相关《sip错误代码报告（17页珍藏版）》请在装配图网上搜索。

1、1xx = 通知性应答 100 正在尝试 180 正在拨打 181 正被转接 182 正在排队 183 通话进展2xx = 胜利应答 200 OK 202 被接受：用于转介3xx = 转接应答 300 多项选择 301 被永久迁移 302 被短暂迁移 305 运用代理服务器 380 替代服务4xx = 呼叫失败 400 呼叫不当 401 未经授权：只供注册机构运用，代理服务器应运用代理服务器授权407 402 要求付费（预订为将来运用) 403 被禁止的 404 未发觉：未发觉用户 405 不允许的方法 406 不行接受 407 须要代理服务器授权 408 呼叫超时：在预定时间内无法找到用户

2、410 已消逝：用户曾经存在，但已从今处消逝 413 呼叫实体过大 414 呼叫URI过长 415 不支持的媒体类型 416 不支持的URI方案 420 不当扩展：运用了不当SIP协议扩展，服务器无法理解该扩展 421 须要扩展 423 时间间隔过短 480 短暂不行运用 481 通话/事务不存在 482 检测到循环 483 跳数过多 484 地址不全 485 模糊不清 486 此处太忙 487 呼叫被终止 488 此处不行接受 491 呼叫待批 493 无法解读：无法解读 S/MIME文体部分5xx = 服务器失败 500 服务器内部错误 501 无法实施：SIP呼叫方法在此处无法实施 50

3、2 不当网关 503 服务不行运用 504 服务器超时 505 不支持该版本：服务器不支持SIP协议的这个版本 513 消息过长6xx = 全局失败 600 各处均忙 603 拒绝 604 无处存在 606 不行运用代码详解：SIP协议应答码应答代码应答码是包含了，并且扩展了HTTP/1.1应答码。并不是全部的HTTP/1.1应答码都适当应用，只有在折里指出的是适当的。其他HTTP/1.1应答码不应当运用。并且，SIP也定义了新的应答码系列，6xx。1 临时应答1xx临时应答，也就是消息性质的应答，标记了对方服务器正在处理恳求，并且还没有确定最终的应答。假如服务器处理恳求须要花200ms以上才

4、能产生终结应答的时候，它应当发送一个1xx应答。留意1xx应答并不是牢靠传输的。他们不会导致客户端传送一个ACK应答。临时性质的（1xx）应答可以包含消息体，包含会话描述。1.1 100 Trying这个应答表示下一个节点的服务器已经接收到了这个恳求并且还没有执行这个恳求的特定动作（比如，正在打开数据库的时候）。这个应答，就像其他临时应答一 样，种植了UAC重新传送INVITE恳求。100(Trying)应答和其他临时应答不同的是，在这里，它恒久不会被有状态proxy转发到上行流中。1.2 180 RingingUA收到INVITE恳求并且试图提示给用户。这个应答应当出世化一个本地回铃。1.3

5、 818 Call is Being Forwarded(呼叫被转发)服务器可以用这个应答代码来表示呼叫正在转发到另一个目的地集合。1.4 182 Queued当呼叫的对方短暂不能接收呼叫的时候，并且服务器确定将呼叫排队等候，而不是拒绝呼叫的时候，那么就应当发出这个应答。当被叫方一旦复原接收呼叫，他会返回合适的终结应答。对于这个呼叫状态，可以有一个表示缘由的短语，比如：”5 calls queued;expected waiting time is 15minutes”。服务器可以给出好几个182（Queued）应答告知呼叫方排队的状况（比如排队靠前了等等）。1.5 183 会话进度183（S

6、ession Progress）应答用于提示建立对话的进度信息。Reason-Phrase（表达缘由的句子）、头域或者消息体可以用于提示呼叫进度的更消息的信息。2 胜利信息2xx这个应答表示恳求是胜利的。2.1 200 OK恳求已经处理胜利。这个信息取决于不同方法的恳求的应答。3 转发恳求3XX3xx系列的应答是用于提示用户的新位置信息的，或者为了满意呼叫而转发的额外服务地点。3.1 300 Multiple Choices恳求的地址有多个选择，每个选择都有自己的地址，用户或者（UA）可以选择合适的通讯终端，并且转发这个恳求到这个地址。应答可以包含一个具有每一个地点的在Accept恳求头域中允

7、许的资源特性，这样用户或者UA可以选择一个最合适的地址来转发恳求。没有未这个应答的消息体定义MIME类型。这些地址选择也应当在Contact头域中列出（20.10节）。不同于HTTP，SIP应答可以包含多个Contact头域或者一个Contact头域 中具有一个地址列表。UA可以运用Contact头域来自动转发或者要求用户确认转发。不过，本规范没有定义自动转发的标准。假如被叫方可以在多个地址被找到，并且服务器不能或者不情愿转发恳求的时候，可以运用这个应答来给呼叫方。3.2 301 Moved Permently当不能在Request-URI指定的地址找到用户的时候，恳求的客户端应当运用Cont

8、act头域(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。假如没有严格的有效时见，那么这个地址仅仅本次有效，

9、并且不能在以后的事务中保存。假如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呼叫不成工，但是可以尝试另外的服务。另外的服务在应答的消息体中定义。消息体的格式在这里没有定义，

10、可能在以后的规范中定义。4 恳求失败4xx4xx应答定义了特定服务器响应的恳求失败的状况。客户端不应当在不更改恳求的状况下重新尝试同一个恳求。（例如，增加合适的认证信息）。不过，同一个恳求交给不同服务器或许就会胜利。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

11、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头域，这个头域包含了指定地址允许的方法列

12、表。4.7 Not Acceptable恳求中的资源只会导致产生一个在恳求中的Accept头域外的，内容无法接收的错误。4.8 407 Proxy Authentication Required这个返回码和401（Unauthorized）很类四，但是标记了客户端应当首先在proxy上通过认证。SIP对认证的访问请参见26节和22.3节。这个返回码用于应用程序访问通讯网关（比如，电话网关），而很少用于被叫方要求认证。4.9 408 Request Timeout在一段时间内，服务器不能产生一个终结应答，例如，假如它无法与时确定用户的位置。客户端可以在稍后不更改恳求的内容然后重新尝试恳求。4.1

13、0 410 Gone恳求的资源在本服务器上已经不存在了，并且不知道应当把恳求转发到哪里。这个问题将会使永久性的。假如服务器不知道，或者不简单检测，这个资源消逝是临时性质的还是永久性质的，那么应当返回一个404（Not Found）。4.11 413恳求实体过大。服务器拒绝处理恳求，因为这个恳求的实体超过了服务器希望或者能够处理的大小。这个服务器应当关闭连接避开客户端重发这个恳求。假如这个状况是短暂的，那么服务端应当包含一个Retry-After头域来表明这是一个短暂的故障，并且客户端可以过一段时间再次尝试。4.12 414 Request-URI Too Long服务器拒绝这个恳求，因为Req

14、uest-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-Re

15、quire(20.29)或者Require(20.32)头域所指出的协议扩展。服务器必需在Unsupported头域中列出不支持的扩展。UAC处理这个应答请参见8.1.3.54.16 421Extension RequiredUAS须要特定的扩展来处理这个恳求，但是这个扩展并没有在恳求的Supported头域中列出。具有这个应答码的应答必需包含一个Require头域列出所须要的扩展。UAS不应当运用这个应答除非它真的不能给客户端供应有效的服务。相反，假如在Support头域中没有列出须要的扩展，服务器应当依据基准的SIP兼容的方法和客户端支持的扩展来进行处理。4.17 423 Interval

16、 Too Brief服务器因为在恳求中设置的资源刷新时间（或者有效时间）过短而拒绝恳求。这个应答可以用于注册服务器来拒绝那些Contact头域有效期过短的注册恳求。这个应答的用法和相关的Min-Expires头域在10.2.8,10.3,20.23节中介绍和说明。4.18 480 Temporarily Unavailable恳求胜利到达被叫方的终端系统，但是被叫方当前不行用（例如，没有登陆，或者登陆了但是状态是不能通 讯，或者有”请勿打搅”的标记）。应答应当在Retry-After中标记一个合适的重发时间。这个用户也有可能在其他地方是有效的（在本服务器中不知 道）。Reason-Phrase

17、(缘由短句)应当提示更具体的缘由，为什么被叫方短暂不行用。这个值应当是可以被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服务器接收到了

18、一个恳求包含的Max-Forwards(20.22)头域是04.22 484 Address InComplete服务器接收到了一个恳求，它的Request-URI是不完整的。在缘由短语中应当有附加的信息说明。这个状态码可以和拨号交叠。在和拨号交叠中，客户端不知道拨号串的长度。它发送增加长度的字串，并且提示用户输入更多的字串，直到不在出现484（Address Incomplete）应答为止。4.23 485 AmbiguousRequest-URI是不明确的。应答可以在Contact头域中包含一个可能的明确的地址列表。这个提 示列表肯囊个在平安性和隐私性对用户或者组织造成破坏。必需能够由配置

19、确定是否以404（NotFound）代替这个应答，又或者禁止对不明确的地址运用 可能的选择列表。给带有Request-URI的恳求的一个应答例子：sip: turbot.xulanyears :SIP/2.0 485 AmbiguousContact: David.QianContact: Leo HuuContact: M.Foote部分email和语音邮箱系统供应了这个功能。这个状态码和3xx状态码不同：对于300来说，它是假定同一个人或者服务有不同的地址选择。所以对3xx来说，自动选择系统或者连续查找就有效，但是对485（Ambiguous）应答来说，肯定要用户的干预。4.24 486

20、Busy Here当胜利联系到被叫方的终端系统，但是被叫方当前在这个终端系统上不能接听这个电话，那么应答应当回给呼叫方一个更合适的时间在Retry-After头域 重试。这个用户或许在其他地方有效，比如电话邮箱系统等等。假如我们知道没有其他终端系统能够接听这个呼叫，那么应当返回一个状态码600（Busy Everywhere）。4.25 487 Request Terminated恳求被BYE或者CANCEL所终止。这个应答恒久不会给CANCEL恳求本身回复。4.26 488 Not Acceptable Here这个应答和606（Not Acceptable）有相同的含义，但是只是应用于Re

21、quest-URI所指出的特定资源不能接受，在其他地方恳求可能可以接受。包含了媒体兼容性描述的消息体可以出现在应答中，并且依据INVITE恳求中的Accept头域进行规格化（假如没有Accept头域，那么就是application/sdp）。这个应答就像给OPTIONS恳求的200(OK)应答的消息体一样。4.27 491 Request Pending在同一个对话中，UAS接收到的恳求有一个依靠的恳求正在处理。14.2描述了这种状况应当怎样解决。4.28 493 UndecipherableUAS接收到了一个恳求，包含了一个加密的MIME,并且不知道或者没有供应合适的解密密钥。这个应答可以包

22、含单个包体，这个包体包含了合适的公钥，这个公钥用于给这个UAS通讯中加密包体运用的。细微环节描述在23.2节。5 Server Failure 5xx5xx应答是当服务器本身故障的时候给出的失败应答。5.1 500 Server Internal Error服务器遇到了未知的状况，并且不能接着处理恳求。客户端可以显示特定的错误状况，并且可以在几秒种以后重新尝试这个恳求。假如这个状况是临时的，服务器应当在Retry-After头域标记客户端过多少秒钟之后重新尝试这个恳求。5.2 501 Not Implemented服务器没有实现相关的恳求功能。当UAS不相识恳求的方法的时候，并且对每一个用户都

23、无法支持这个方法的时候，应当返回这个应答。（proxy不考虑恳求的方法而转发恳求）。留意405（Method Not Allowed）是因为服务器实现了这个恳求方法，但是这个恳求方法在特定恳求中不被支持。5.3 502 Bad Gateway假如服务器，作为gateway或者proxy存在，从下行服务器上接收到了一个非法的应答（这个应答对应的恳求是本服务器为了完成恳求而转发给下行服务器的）。5.4 503 Service Unavailable由于临时的过载或者服务器管理导致的服务器短暂不行用。这个服务器可以在应答中增加一个Retry-After来让客户端重试这个恳求。假如没有Retry-Af

24、ter指出，客户端必需就像收到了一个500（Server Internal Error）应答一样处理。客户端（proxy或者UAC）收到503（Service Unavailable）应当尝试转发这个恳求到另外一个服务器处理。并且在Retry-After头域中指定的时间内，不应当转发其他恳求到这个服务器。作为503(Service Unavaliable)的替代，服务器可以拒绝连接或者把恳求扔掉。5.5 504 Server Time-out服务器在一个外部服务器上没有收到一个与时的应答。这个外部服务器是本服务器用来访问处理这个恳求所须要的。假如从上行服务器上收到的恳求中的Expires头域超

25、时，那么应当返回一个408（Request TimeOut）错误。5.6 505 Version Not Supported服务器不支持对应的SIP版本。服务器是无法处理具有客户端供应的相同主版本号的恳求，就会导致这样的错误信息。5.7 Message To Large服务器无法处理恳求，因为消息长度超过了处理的长度。6 Global Failures 6xx6xx应答意味这服务器给特定用户有一个最终的信息，并不只是在Request-URI的特定实例有最终信息。6.1 600 Busy Everywhere胜利联系到被叫方的终端系统，但是被叫方处于忙的状态，并不准备接听电话。这个应答可以通过增

26、加一个 Retry-After头域更明确的告知呼叫方多久以后可以接着呼叫。假如被叫方不希望提示拒绝的缘由，被叫方应当运用603（Decline）。只有当 终端系统知道没有其他终端节点（比如语音邮箱系统）能够访问到这个用户的时候才能运用这个应答。否则应当返回一个486（Busy Here）的应答。6.2 603 Decline当胜利访问到被叫方的设备，但是用户明确的不想应答。这个应答可以通过增加一个Retry-After头域更明确的告知呼叫方多久以后可以接着呼叫。只有当终端知道没有其他任何终端设备能够响应这个呼叫的势能才能给出这个应答。6.3 604 Does Not Exists Anywhe

27、re服务器验证了在恳求中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）进行处理。这个应答只有当客户端知道没有其他终端能够处理这个恳求的时候才能发出。