SIP协议应答码-2-zt

上一篇 / 下一篇  2013-11-28 16:29:17 / 个人分类:sipp

转自:http://blog.csdn.net/zljjava/article/details/7889267

4.24 486 Busy Here

当成功联系到被叫方的终端系统,但是被叫方当前在这个终端系统上不能接听这个电话,那么应答应当回给呼叫方一个更合适的时间在Retry-After头域重试。这个用户也许在其他地方有效,比如电话邮箱系统等等。如果我们知道没有其他终端系统能够接听这个呼叫,那么应当返回一个状态码600Busy Everywhere)。 

4.25 487 Request Terminated

请求被BYE或者CANCEL所终止。这个应答永远不会给CANCEL请求本身回复。 

4.26 488 Not Acceptable Here

这个应答和606Not 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不考虑请求的方法而转发请求)。 

注意405Method Not Allowed)是因为服务器实现了这个请求方法,但是这个请求方法在特定请求中不被支持。 

5.3 502 Bad Gateway

如果服务器,作为gateway或者proxy存在,从下行服务器上接收到了一个非法的应答(这个应答对应的请求是本服务器为了完成请求而转发给下行服务器的)。 

5.4 503 Service Unavailable

由于临时的过载或者服务器管理导致的服务器暂时不可用。这个服务器可以在应答中增加一个Retry-After来让客户端重试这个请求。如果没有Retry-After指出,客户端必须就像收到了一个500Server Internal Error)应答一样处理。 

客户端(proxy或者UAC)收到503Service Unavailable)应当尝试转发这个请求到另外一个服务器处理。并且在Retry-After头域中指定的时间内,不应当转发其他请求到这个服务器。 

作为503(Service Unavaliable)的替代,服务器可以拒绝连接或者把请求扔掉。 

5.5 504 Server Time-out

服务器在一个外部服务器上没有收到一个及时的应答。这个外部服务器是本服务器用来访问处理这个请求所需要的。如果从上行服务器上收到的请求中的Expires头域超时,那么应当返回一个408Request 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头域更明确的告诉呼叫方多久以后可以继续呼叫。如果被叫方不希望提示拒绝的原因,被叫方应当使用603Decline)。只有当终端系统知道没有其他终端节点(比如语音邮箱系统)能够访问到这个用户的时候才能使用这个应答。否则应当返回一个486Busy Here)的应答。

6.2 603 Decline

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

6.3 604 Does Not Exists Anywhere

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

6.4 606 Not Acceptable

当成功联系到一个UA,但是会话描述的一些部分比如请求的媒体,带宽,或者地址类型不被接收。 

606NotAcceptable)应答意味着用户希望通讯,但是不能充分支持会话描述。606Not Acceptable)应答可以在Warning头域中包含一个原因列表,用于解释为何会话描述不能被支持。警告原因代码在20.43节中列出。 

在应答中,可以出现一个包含媒体兼容性描述的消息体,这个消息体的格式根据INVITE请求中的Accept头域指出的格式进行规格化(如果没有Accept头域,那么就是application/sdp),就像给OPTIONS亲求的200(OK)应答中的消息一样。

我们希望这些媒体协商不要经常需要,并且当一个新用户被邀请加入已经存在的会话的时候,这个媒体协商可能不需要。这取决于邀请的初始化者是否需要对606Not Acceptable)进行处理。 

这个应答只有当客户端知道没有其他终端能够处理这个请求的时候才能发出。


TAG: 协议 应答码 SIP sip

 

评分:0

我来说两句

Open Toolbar