【IMS】SIP应答消息状态码与功能详解(二)

前面给大家介绍了临时应答(1XX) 、会话成功(2XX)以及重定向(3XX)三类应答消息代码,今天继续介绍客户端请求失败(4xx)、服务器失败(5XX)及全局性错误(6XX)三类应答消息代码。
SIP协议架构.jpg

4)客户端请求失败4xx 
4xx应答定义了特定服务器响应的请求失败的情况。客户端不应在不更改请求的情况下重新尝试同一个请求。(例如,增加合适的认证信息)。不过,同一个请求交给不同服务器也许就会成功。 
  •  400 Bad Request 

请求中的语法错误。Reason-Phrase应当标志这个详细的语法错误,比如”Missing Call-ID header field”。 
  • 401 Unauthorized 

请求需要用户认证。这个应答是由UAS和注册服务器产生的,而407(Proxy Authentication Required)是proxy服务器产生的。 
  • 402 Payment Required 

保留/以后使用 
  • 403 Forbidden 

服务端支持这个请求,但是拒绝执行请求。增加验证信息是没有必要的,并且请求应当不被重试。 
  • 404 Not Found 

服务器返回最终信息:用户在Request-URI指定的域上不存在。当Request-URI的domain和接收这个请求的domain不匹配的情况下, 也会产生这个应答。 
  • 405 Method Not Allowed 

服务器支持Request-Line中的方法,但是对于这个Request-URI中的地址来说,是不允许应用这个方法的。 
应答必须包括一个Allow头域,这个头域包含了指定地址允许的方法列表。
  • 406 Not Acceptable 

请求中的资源只会导致产生一个在请求中的Accept头域外的,内容无法接收的错误。 
  • 407 Proxy Authentication Required 

这个返回码和401(Unauthorized)很类似,但是标志了客户端应当首先在proxy上通过认证。
这个返回码用于应用程序访问通讯网关(比如,电话网关),而很少用于被叫方要求认证。 
  • 408 Request Timeout 

在一段时间内,服务器不能产生一个终结应答,例如,如果它无法及时决定用户的位置。客户端可以在稍后不更改请求的内容然后重新尝试请求。 
  • 410 Gone 

请求的资源在本服务器上已经不存在了,并且不知道应当把请求转发到哪里。这个问题将会是永久性的。
如果服务器不知道,或者不容易检测,这个资源消失是临时性质的还是永久性质的,那么应当返回一个404(Not Found)。 
  • 413 Request Entity Too Large 

服务器拒绝处理请求,因为这个请求的实体超过了服务器希望或者能够处理的大小。这个服务器应当关闭连接避免客户端重发这个请求。 
如果这个情况是暂时的,那么服务端应当包含一个Retry-After头域来表明这是一个暂时的故障,并且客户端可以过一段时间再次尝试。 
  • 414 Request-URI Too Long 

服务器拒绝这个请求,因为Request-URI超过了服务器能够处理的长度。 
  • 415 Unsupported Media Type 

服务器由于请求的消息体的格式本服务器不支持,所以拒绝处理这个请求。这个服务器必须根据内容的故障类型,返回一个Accept,Accpet-Encoding,或者Accept-Language头域列表。
  • 416 Unsupported URI Scheme 

服务器由于不支持Request-URI中的URI方案而终止处理这个请求。 
  • 420 Bad Extension 

服务器不知道在请求中的Proxy-Require(20.29)或者Require(20.32)头域所指出的协议扩展。服务器必须在Unsupported头域中列出不支持的扩展。
  • 421 Extension Required 

UAS需要特定的扩展来处理这个请求,但是这个扩展并没有在请求的Supported头域中列出。具有这个应答码的应答必须包含一个Require头域列出所需要的扩展。 
UAS不应当使用这个应答除非它真的不能给客户端提供有效的服务。相反,如果在Support头域中没有列出需要的扩展,服务器应当根据基准的SIP兼容的方法和客户端支持的扩展来进行处理。 
  • 423 Interval Too Brief 

服务器因为在请求中设置的资源刷新时间(或者有效时间)过短而拒绝请求。这个应答可以用于注册服务器来拒绝那些Contact头域有效期过短的注册请求。
  • 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: 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)应答来说,一定要用户的干预。 
  • 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接收到的请求有一个正在处理。 
  • 493 Undecipherable 

UAS接收到了一个请求,包含了一个加密的MIME,并且不知道或者没有提供合适的解密密钥。
这个应答可以包含单个包体,这个包体包含了合适的公钥,这个公钥用于给这个UAS通讯中加密包体使用的。
SIP消息1.gif

5)服务器失败5xx 
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 

服务器无法处理请求,因为消息长度超过了处理的长度。 
 
6)全局性错误6xx 
6xx应答意味这服务器给特定用户有一个最终的信息,并不只是在Request-URI的特定实例有最终信息。 
  • 600 Busy Everywhere 

成功联系到被叫方的终端系统,但是被叫方处于忙的状态,并不打算接听电话。
这个应答可以通过增加一个Retry-After头域更明确的告诉呼叫方多久以 后可以继续呼叫。如果被叫方不希望提示拒绝的原因,被叫方应当使用603(Decline);只有当终端系统知道没有其他终端节点(比如语音邮箱系统)能 够访问到这个用户的时候才能使用这个应答,否则应当返回一个486(Busy Here)的应答。
  • 603 Decline 

谢绝,当成功访问到被叫方的设备,但是用户明确的不想应答。
这个应答可以通过增加一个Retry-After头域更明确的告诉呼叫方多久以后可以继续呼叫。
只有当终端知道没有其他任何终端设备能够响应这个呼叫的势能才能给出这个应答。 
  • 604 Does Not Exists Anywhere 

服务器验证了在请求中Request-URI的用户信息,哪里都不存在。 
  • 606 Not Acceptable 

当成功联系到一个UA,但是会话描述的一些部分比如请求的媒体,带宽,或者地址类型不被接收。 
606(NotAcceptable)应答意味着用户希望通讯,但是不能充分支持会话描述。
606(Not Acceptable)应答可以在Warning头域中包含一个原因列表,用于解释为何会话描述不能被支持。
在应答中,可以出现一个包含媒体兼容性描述的消息体,这个消息体的格式根据INVITE请求中的Accept头域指出的格式进行规格化(如果没有Accept头域,那么就是application/sdp),就像给OPTIONS亲求的200(OK)应答中的消息一样。 
我们希望这些媒体协商不要经常需要,并且当一个新用户被邀请加入已经存在的会话的时候,这个媒体协商可能不需要。这取决于邀请的初始化者是否需要对606(Not Acceptable)进行处理。 
这个应答只有当客户端知道没有其他终端能够处理这个请求的时候才能发出。
 
关于SIP应答消息状态码与功能详解就到这里,后续如果有相关的疑问可以关注公众号或者加入微信群进行讨论和交流!
 
网优俱乐部1.jpg

如果你喜欢本文内容,对你的工作和学习有帮助或者想获取更多信息,就赶紧把我的公众号关注起来吧!
云端拾贝.jpg

 
 
 
0
2018-10-19

0 个评论

要回复文章请先登录注册