您当前的位置是:  首页 > 资讯 > 国内 >
 首页 > 资讯 > 国内 >

SIP协议规范RFC3261中文分享-12

2019-11-26 15:37:13   作者:james.zhu    来源:Asterisk开源派   评论:0  点击:


  接前面章节。
  8.2.4 Applying Extensions
  当生成响应消息时,UAS不能直接期望使用拓展功能,除非在请求中的头Supported头中已经表示支持了这个拓展。如果所希望的拓展不能被支持的话,服务器应该仅依赖基本的SIP和其他客户端所支持的拓展来处理。在极少情况下,服务器没有拓展的话就不能处理请求,这个服务器可以发送一个421(Extension Required)响应消息。这个响应消息表示,如果没有具体的拓展功能,服务器端不能生成一个规范的响应。这些服务器端所需要支持的拓展必须包括在响应消息中的Require头中。规范不推荐这种操作方式,因为,一般情况下,因为它会破坏流程的兼容性处理。
  任何在non-421响应中列出的拓展功能必须包含在响应消息的Require头列表中。
  当然,服务器端也不能使用没有在请求的Supported头中列出的拓展。因此,响应消息中的 Require 头就会只能包含在标准RFCs中多定义的可选标签。
  8.2.5 Processing the Request
  假设前面讨论的所有子章节都通过的话,UAS的处理就会进入到和method相关的处理流程。Section 10 涵盖REGISTER 请求,Section 11 涵盖OPTIONS 请求,Section 13 涵盖INVITE 请求,最后,Section 15 涵盖BYE请求。
  8.2.6 Generating the Response
  当UAS希望对请求构建一个响应时,UAS必须遵守一般的处理流程。这些处理流程会在下面的子章节中进行说明。另外,对于一些非常具体的响应码的处理问题,这里没有规范具体的细节,也可不做要求。
  一旦所有和创建响应消息所关联的流程完成以后,UAS负责返回到服务器事务层,这里是它收到请求的地址。
  8.2.6.1 Sending a Provisional Response
  对生成响应来说,一个主要的不具体到某个method的原则是,UASs对非INVITE不应该发送临时响应消息。相反,UASs应该尽快对非INVITE请求生成一个最终响应消息。
  当生成100 (Trying)响应时,重新在在请求中的任何Timestamp头必须拷贝到这个 100 (Trying)响应中。如果在生成响应时有延迟,UAS应该在Timestamp头中添加一个延迟数值。这个延迟数值必须包含响应发送时间值和接收请求时间值,此值以秒为单位。
  8.2.6.2 Headers and Tags
  响应消息中的From必须和请求中的From头相同。响应中的Call-ID头必须和请求中的Call-ID相同。响应中的CSeq必须和请求中的CSeq相同。响应中的Via头必须和请求中的Via头相同,而且保持相同的顺序。
  如果在请求中包含了一个To tag标签,响应中的To必须和请求中的To头相同。但是,如果在请求中没有包含To头值,在响应中回复中,To头中的URL必须和请求中To头的URL相同;另外,在响应回复中,UAS必须在To标签中增加一个标签(支持100(trying)异常响应)。这样处理的目的是确认UAS正在响应处理,也可能因为这个异常响应会生成一个dialog ID组件。同样的标签使用在此请求的所有响应中,包括最终响应和临时响应(除了100(trying以外))。对此标签生成的流程在中Section 19.3定义。
  8.2.7 Stateless UAS Behavior
  无状态UAS是一种不保存事务状态的UAS。它通常会转发请求,而且协议发送后会丢弃UAS的状态消息。 如果一个无状态UAS收到请求重发,此UAS会重新生成响应,重新发送响应,就像它对第一个请求回复一样。一个UAS不能是无状态模式,除非这个method的请求处理总导致同样的响应(如果请求是确认的)。无状态注册不遵守此规则。无状态UASs不涉及事务层;UASs直接收到传输层请求后,直接对传输层返回响应。
  无状态UAS的基本功能是处理无需验证的请求,这些请求面对响应问题。如果无验证请求是通过有状态UAS来处理的话,那么就会导致这些无验证请求产生大量的事务状态,这些事务状态数据会导致在UAS端呼叫处理速度放慢,影响UAS处理性能,可能立刻生成了拒绝攻击服务的条件。更多关于拒绝攻击服务的内容,查阅Section 26.1.5。
  无状态UAS的最重要处理方式包括以下几个方面:
  • 无状态UAS一定不能发送临时响应(1xx)。
  • 无状态UAS一定不能重回响应消息。
  • 无状态UAS必须忽略ACK请求。
  • 无状态UAS必须忽略CANCEL请求。
  • 响应中的To头域值必须以一种无状态的方式生成,这种生成方式对同样的请求生成同样的标签,此方式的目的是保持标签的一致性。更多关于标签构成,参考Section 19.3。
  关于其他方面的处理规范,无状态UAS和有状态UAS是一样的。对每个新请求来说,UAS可以以有状态方式或无状态方式操作。
  8.3 Redirect Servers
  在一些技术架构中,代理服务器的目的是为了降低处理负载,这些代理服务器可能是负责处理路由请求和优化信令路径的强健性,都是通过重定向方式进行转发处理。
  重定向处理允许服务器端对请求在响应中推送路由消息,返回给客户端,因此,重定向会把自己踢出此环路的事务处理中,定位到请求的目标地址。当请求发起方收到了重新定位响应以后,发起方会基于收到的URL地址重新发送一个新的请求。通过从网络核心传输URLs到其网络边界,重定向允许相关网络拓展性。
  重定向服务器逻辑上由一个服务器事务层和一个事务用户构成。事务用户可以访问某些定位服务(参考Section 10 获得更多注册和定位服务详情)。定位服务实际上是一个数据库,数据库映射单个URL地址和一个或多个可选地址,这些地址是URL的目标地址。
  重定向服务器自己不能发起任何属于自己的SIP请求。收到了一个请求以后(除了CANCEL请求以外),服务器可以拒绝此请求或从定位服务收集可选地址,然后返回一个最终响应3xx。
  对于格式非常规范的CANCEL请求,重定位服务器应该返回一个2xx响应。这个响应表示结束SIP事务处理。重定位服务器保持一个完整SIP事务的状态。这是客户端的责任,用来检测介于重定向服务器之间的前转环路。
  当重定向服务器对请求返回一个3xx响应时,定向服务器会在Contact头中插入查询到的定位地址列表。 同时,在Contact头中增加一个“expires”参数值,此值表示Contact数据中地址的生命周期。
  Contact头中包含URLs,并且提供新的地址和用户名来尝试,或者简单提供指定的额外传输参数。301 (Moved Permanently)或302 (Moved Temporarily)响应可能也提供同样地址和用户名,这个用户名是初始请求的目标地址,但是设定了额外的传输参数值,例如尝试不同的服务器或组播地址,或者传输方式的相关,例如从UDP传输修改为TCP传输,或者相反处理。
  不管怎样,重定位服务器一定不能重定位一个请求到一个URL,这个URL和一个在Request-URI 的URL相同;相反,服务器可以代理转发这个请求到目的地URL,或者拒绝此请求,返回一个404响应。
  如果客户端正在使用一个outbound proxy,并且重新定位此请求,这里可能产生一个潜在的无限重定位环路。
  注意,一个 Contact头可能涉及不同的源地址,而不是初始呼叫的源地址。例如,一个SIP呼叫连接到PSTN网关,网关可能需要提供一个特别的语音说明(例如,您拨打的号码已经被修改)。
  一个Contact响应消息头可以包含任何恰当的URL值,这个值表示被呼叫方已经被连接,也不仅局限于SIP URLs地址。例如,它可以包含电话的URLs地址,传真或irc(如果有定义的话)或一个mailto: (RFC 2368 [32]) 邮件地址。Section 26.4.4 讨论了 重定位处理中SIPs URL到一个non-SIPS URI的影响和局限性。
  Contact头中的“expires”参数表示URL的生命周期。此值以秒为单位计算。如果没有提供此参数的话,以Expires头中的数值决定URL的生命周期。如果出现异常值的话,此值应该视为等同于3600。
  这种方式提供了一种最大程度的可能,保证了和RFC2534向后兼容,这也支持了一个在这个头中的绝对时间值。如果收到了一个绝对时间的话,它将会被视为异常值,默认的时间为3600。
  重定位服务器一定要忽略某些功能(包括无法识别的头域格式,任何在Require中的未知可选标签,甚至于未知的method名称),和某些存在问题的重定位请求。
  未完继续……
 
   
  关注微信公众号:asterisk-cn,获得有价值的Asterisk行业分享
  Asterisk freepbx,FreeSBC技术文档:www.freepbx.org.cn
  融合通信商业解决方案,协同解决方案首选产品:www.hiastar.com
  Asterisk / FreePBX / FreeSBC中国合作伙伴,官方qq技术分享群(3000人):589995817
 
【免责声明】本文仅代表作者本人观点,与CTI论坛无关。CTI论坛对文中陈述、观点判断保持中立,不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。请读者仅作参考,并请自行承担全部责任。

相关热词搜索: SIP协议

上一篇:SIP协议规范RFC3261中文分享-11

下一篇:最后一页

专题

CTI论坛会员企业