正文

SIP的RFC中文文档(RFC3261)(8)2005-12-15 14:46:00

【评论】 【打印】 【字体: 】 本文链接:http://blog.pfan.cn/ddtme/8256.html

分享到:

8.2 UAS特性

UAS在处理对话外的请求的时候,有一组规则需要遵守,这组规则与方法无关。12节指明了一个方法来判定一个请求是否在一个对话里。

注意,请求的处理是原子级别的。如果请求被处理,那么这个请求的相关状态一定是一起更新的。如果它被拒绝了,那么这个请求的所有相关状态一定是没有改变的。

UASs应当遵循本节所规定的顺序来处理请求。(就是说,首先是身份认证,然后是方法判定,然后是头域,然后按照本文规定处理剩余部分)

8.2.1 方法判定

当请求被认证(或者身份认证被忽略),UAS必须首先判定这个请求的方法。如果UAS发现自己不能处理这个请求的方法的时候,它必须给出一个405(方法不支持)的应答。产生应答的步骤在8.2.6节规定,并且UAS必须在给出的405(方法不支持)应答中增加一个Allow头域。这个Allow头域必须列明哪些方法UAS支持。Allow头域的说明在20.5节。

如果请求中的方法是服务器所支持的,那么处理将继续。

8.2.2 包头判断

如果UAS不认识请求中的包头域(就是说,包头域不在本规范中定义或者不在任何扩展中定义),那么服务器必须忽略掉这个包头域并且继续处理本请求。UAS必须忽略任何处理本请求所不需要的长得畸形的包头域。

8.2.2.1 TO Request-URI

To头域包含了由From域描述的发送者发出的请求的原始接受者。原始接受者可能是也可能不是正在处理这个请求的UAS,取决于呼叫转移或者其他的proxy操作。当TO域值和自身不相符的情况下,UAS可以自行决定是否接收这个请求。但是,我们依旧是建议UAS处理这个请求,甚至TO这个头域是以他们不认识的URI方案表达的(比如一个tel:URI),或者To头域并非指向这个自身处理的UAS。当然,另外一方面来说,如果UAS决定拒绝这个请求,它应该产生一个403(禁止访问)的状态码,并且交给服务器的transaction层来发送。

但是,Request-URI确定UAS来处理这个请求。如果Request-URI使用了一个UAS所不支持的方案(比如tel:URI),那么UAS应当拒绝这个请求,并且给出拒绝代码416(不支持的URI方案)。如果Request-URI并没有指明本UAS来处理这个请求,那么UAS应当给出一个404(未找到)的应答。比如,一个UA使用REGISTER方法来绑定它的address-of-record到一个特定的联系地址,将会收到Request-URI等于那个特定联系地址的请求。

其他潜在的Request-URI资源包括建立和刷新对话的UA发出的请求和应答的Contact头域。

8.2.2.2 合并的请求

如果请求的To头域中没有tag标志,UAS的处理核心必须检查基于正在进行的transactions上的请求。如果接收到的请求和正在处理的transaction的请求中的头域From tag,Call-ID,CSeq精确匹配了,但是请求并不匹配那个事务(基于事务匹配机制17.2.3节),UAS核心应该产生一个482(检测到循环)应答并且给服务器的transaction层发送。

这是由于相同的请求通过不同的路径到达UAS,很多情况下是由于分支的原因。UAS处理了第一个请求并且给其他所有这个请求以482(检测到循环)应答。

8.2.2.3 Require

如果请求的各项要素通过了UAS的判定,那么如果存在Require头域,接下来就是检查Require头域。Require头域是UAC用来通知UAS应该用什么样的SIP扩展来处理本请求的。Require的格式在20.32节中有介绍。如果UAS不支持请求的Require头域中的option-tag列表,那就必须产生一个420应答(错误的扩展)。并且UAS必须添上Unsupported头域,里边填上刚才接收到的请求的Require头域中,哪些options是自己所不支持的。

需要注意的是,RequireProxy-Require禁止出现在SIP CANCEL请求中,或者回应给非2xx应答的ACK请求中。就算出现了在处理的时候也必须被忽略。并且回应给2xx应答的ACK请求必须只能包含在初始请求(在这个ACK请求之前的请求)中包含的RequireProxy-Require所规定options,这样才能保证服务端能够正确处理。

例子:

UAC->UAS: INVITE sip:watson@bell-telephone.com SIP/2.0

Require: 100rel

UAS->UAC: SIP/2.0 420 Bad Extension

Unsupported: 100rel

这个特性(Unsupported)是为了保证客户-服务端都能够无阻碍的交互,除非是options对方不支持(就像上边的例子说明的一样)。对于相互匹配的客户-服务端(相互匹配的意思就是客户端Require的正好是服务端支持的),那么这些请求、应答将会处理的非常迅速,减少了一个请求的往返协商的浪费。另外,这个也避免了客户端不知道服务端到底不支持那些特性扩展。

某些特性扩展只对终端(endsystem)有效例如呼叫处理域等等。

 

8.2.3 内容处理

UAS支持客户端请求中要求的扩展支持后,UAS要检查消息头域描述的消息体部分。如果UAS并不支持消息体部分的类型(Content-Type指明),语言(Content-Language指明),编码(Content-Encoding指明),并且这个消息体部分并非可选的消息体(Content-Disposition头域指明),UAS必须回应一个415错误应答(不支持的媒体类型)应答。并且如果不支持请求中包含的消息体的正文类型,那么在应答中必须包含UAS所支持的消息体的类型列表(在Accept头域中指明)。如果不支持请求包含的消息体的encoding方式,那么应答中必须包含Accept-Encoding头域列明服务端支持的encoding方式。如果请求中的语言部分不支持,那么就必须在应答中包含Accept-Language头域列明支持的语言。在这些检查之外,消息体正文的处理依赖于方法和类型(method and type)。关于处理内容相关的头域的进一步的资料在7.420.1120.15节。

8.2.4 应用扩展

如果UAS希望应用一部分SIP扩展,那么不可以在产生应答的时候做SIP扩展,除非这个扩展是在请求中的Supported头域中指明了的。如果这个扩展并没有在本请求的Supported头域中指明,那么服务端必须基于基准SIP给出应答,或者给出已知客户端支持的扩展应答。在极少数情况下,如果服务端不用扩展就无法处理请求,那么服务端应该发送421(需要扩展支持)应答。这个应答说明如果没有适当的扩展就无法给出正确的应答。在应答中需要的扩展必须在应答中的Require头域中指出。我们并不推荐这个方法,因为它会降低协同工作的能力。

除了421应答之外的其他应答中,如果需要应用扩展,那么这些扩展需要在421的应答中的Require头域中列明。当然,服务端不允许使用没有在请求中的Supported头域中列明的扩展。因此,应答中的Require头域只会包含标准的RFCs的扩展option tags

8.2.5 处理请求

当所有的检查都通过了以后,UAS根据方法决定如何处理请求。第10节讲述了REGISTER请求的处理,11节讲述了OPTIONS请求的处理,13节讲述了INVITE的处理,15节讲述了BYE的处理。

8.2.6 产生应答

UAS产生应答,需要遵守接下来的几个小节中讲述的步骤产生一个应答。

在本节没有描述的应答代码的其他的行为,也可能会跟据应答代码的不同而要求。当创建应答的步骤完成之后,UAS将应答交给收到这个请求的服务端的transaction去处理。

8.2.6.1 发送一个临时应答

很多情况下,在与方法无关的应答规范中,在非INVITE请求的情况下,我们都要求UAS不应该发送临时应答给请求者。在这种情况下,UAS应该尽快发送一个终结应答给非INVITE请求。

当需要产生一个100Trying)应答的时候,所有对应请求中包头的Timestamp域必须也拷贝到这个应答包头(就是说如果请求中有Timestamp,应答中也必须有timestamp)。而且如果应答有延时,那么UAS应该在这个Timestamp上增加延时的值。这个数值必须包含了接收请求和发送应答的时间,用秒来计数。

8.2.6.2 包头和Tags

应答中的From头域必须和请求中的From头域相等。应答中的Call-ID头域必须和请求中的Call-ID头域相等。应答中的Cseq头域必须和请求中的Cseq头域相等。应答中的Via头域必须和请求中的Via头域相等,而且顺序也必须相等。如果请求中包含了To tag,那么应答中的To头域必须和请求中的To头域相等。如果请求中的To头域并不包含Tag,那么应答中的To头域的URI必须和请求中的TO头域的URI相等;此外,UAS还必须增加一个TagTo头域上(100trying)应答是一个例外,在100中可能已经存在了一个tag)。这就提供了一个UAS正在应答的标志,也许就是对话ID的一部分。对同一个请求来说,它的应答必须有相同的tag标志,包括终结应答和临时应答(同样100trying)除外)。生成tag的步骤在19.3节。

8.2.7 无状态UAS行为

无状态UAS就是说UAS本身不保持事务的状态。但是它在发送对应请求的应答之后并不保存请求的状态。如果无状态UAS接收到了一个重新发送的请求,它会重新产生一个应答并且重新发送应答,就像它接收到的是一个第一个请求一样(就像是新请求而不是重发的请求一样)。只有当相同请求的处理会导致相同的应答的时候,这个UAS才会是无状态的。例如:这条规则排除了无状态的登记服务。无状态的UAS并不包含一个transaction层;他们直接从通讯层接收请求和发送应答。

无状态的UAS通常用于处理不需要身份认证的请求,而且这些请求的应答是可以预期的。如果当不需要身份认证的请求被作为有状态的UAS来处理,那么大量的不需要身份认证的请求会造成服务器大量的事务状态,可能会导致UAS的处理非常慢,甚至中断处理,这样就导致了DoSdenial of service)状态。在26.1.5节中有进一步的描述。

无状态的UAS有下列重要的特性:

o 无状态的UAS不许发送临时应答(1xx

o 无状态的UAS必须忽略ACK请求

o 无状态的UAS必须忽略CANCEL请求

o To头域必须依据无状态的规则来产生-就是说对于相同的请求,产生相同的tag标记。19.3节有讲tag标记。

对于其他情况而言,无状态的UAS遵循有状态的UAS的规则。对于一个新请求来说,同一个UAS可以是有状态的,也可以是无状态的。

8.3 重定向服务器

在某些架构下,可以透过重定向机制,来降低proxy服务器上的路由请求的压力,从而提高消息转发的效率。重定向允许服务器在一个请求的应答中,推送路由信息到客户端,这样就可以做到把自己从后续的消息流中脱离出来,但是同时又能提供准确的请求定位服务。当请求的发起者接收到转发的应答之后,他会重新产生一个基于接收到的URIs)的请求。从network的中央转发到最边缘,转发机制可以适用于跨度很大的网络。

转发服务器在逻辑上是通过一个服务器的transaction层建立的,他作为transaction user可以访问某些类型的位置服务(参见第10节有关注册服务器和位置服务的说明)。这个位置服务可以很方便的用数据库里边的一个URI对应多个地址URI(可能在这个地址找到对应的客户)来实现。

一个重定向服务器并不发出任何指向它自己的请求。接收到任何一个非CANCEL的请求之后,服务器要么拒绝这个请求,要么从位置服务器上找到这个请求应该去的其他位置然后返回一个3xx的终结应答。对于合法的CANCEL请求,它应该返回一个2xx的应答。这个应答将会结束掉SIP事务。重定向服务器在整个SIP事务中位置事务的状态。在重定向服务器之间检测循环死锁应该是客户端的责任。

当重定向服务器给请求方返回一个3xx应答的时候,它会在Contact头域填写一组(一个或者多个)其他位置信息。如果需要指明这个Contact数据的生存周期,可以在Contact头域添加一个”expires”参数。Contact头域包含指向新位置的URI或者可以试试看的用户名,或者就是简单的附加通讯参数等等。301(永久去除)或者302(临时去除)应答同样可以指定和原始请求一样的目的位置和用户名,但是会附加像不同的服务器或者多点传送地址、或者SIPUDPTCP传输等等这样的通讯参数。

重定向服务器必须不能重定向一个请求到它自己的Request-URI列表中的地址;但是倘若那个URI并没有指向自己,重定向服务器可以路由这个请求到目的URI,或者可以返回一个404拒绝。

 

如果一个客户端正在使用外出的proxy,并且这个proxy实际上是重定向请求,那么就可能出现无限重定向循环。

 

注意,Contact头域的值可能指向一个与原始呼叫者无关的资源。比如,一个SIPPSTN(本地电话网)网关的呼叫可能被转递给一个特别的说明,比如你所呼叫的电话号码已经改为….”Contact应答头域可以包含任何合适的能处理这个呼叫对方的URI,并不限于SIP URI。比如,它可以是电话,传真,或者IRC(如果有支持和定义的话)或者一个mailto:(RFC 2368[32] URL。在26.4.4节讲述了对SIPS URI到非SIPS URI的实现和限制。

 

Contact头域中的”expires”参数指明了这个URI的生存周期。这个参数的值是以秒作为单位的。如果这个参数没有提供,那么这个”expires”的缺省是有Expires头域所指定的。这个参数中如果设置了非法的值,那么都应改更改成为缺省的3600。这提供了对RFC2543的向后兼容,RFC2543允许在这个头域中填写绝对时间。在本协议中,如果这个expires填写了绝对时间,那么就会当作是非法的值,就会被当作是3600

 

重定向服务器必须忽略自己所不能理解的特性(包括不认识的头域,不认识的Require中的option tag,甚至是不认识的方法名),并且带着问题处理这个请求的重定向。

阅读(7650) | 评论(0)


版权声明:编程爱好者网站为此博客服务提供商,如本文牵涉到版权问题,编程爱好者网站不承担相关责任,如有版权问题请直接与本文作者联系解决。谢谢!

评论

暂无评论
您需要登录后才能评论,请 登录 或者 注册