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

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

2020-11-18 09:17:22   作者:james.zhu   来源:Asterisk开源派   评论:0  点击:


  接SIP协议规范RFC3261中文分享-24,继续UAS Processing。
  13.3 UAS Processing
  13.3.1 Processing of the INVITE
  UAS core将会从事务层收到INVITE请求。它首先执行的是请求处理流程,参考Section 8.2,这个流程适用于内部请求和dialog的外部请求。
  假设那些流程完成执行步骤没有生成响应,此UAS core还会执行其他的步骤:
  1. 如果此请求是一个INVITE请求,这个INVITE请求包含一个Expires header的话,UAS core设置一个定时器,并且定时器时长表示了header的值。当触发定时器以后,这个请求会被认为超时。如果这个请求超时是在UAS已生成最终响应之前,487 (Request Terminated)响应应该被生成。
  2. 如果此请求是一个mid-dialog 请求的话,需要根据各自method独立处理流程描述的来处理,具体的处理流程首先采用 Section 12.2.2。它也可能修改会话,Section 14 提供了更多细节。
  3. 如果请求在To header中有一个tag标签,但是dialog identifier不能匹配任何已存dialogs,UAS 可能已经崩溃,已重启,或者不同的UAS可能收到了请求(可能是失败的UAS)。在这种情况下,Section 12.2.2 提供了一个指南确保获得一个稳定的处理流程。
  从这里开始的流程和后续的流程假设此INVITE是一个dialog外部的请求,并且其目的是为了创建一个新会话。
  此INVITE可能包含一个会话描述,这种情况是UAS出现在一个这个会话的offer消息中。这是非常可能的,用户已经是那个会话中的一个参与方,甚至于此INVITE是一个dialog外部的INVITE。这种情况可以发生在多播会议,用户被其他参与方邀请加入会议中。如果需要的话,此UAS可以在会话描述中使用 identifiers来检测重复身份。
  例如,SDP 包含一个会话ID和在origin (o)行的版本号。如果此用户已经是会话中的一员,并且包含了在会话描述的会话参数没有任何改变,UAS 可以接受这个INVITE请求(发送一个2xx响应,无需提示此用户)。
  如果此INVITE没有包含任何的会话描述,UAS最终被邀请加入一个会话中,并且UAC已经被要求由UAS提供会话offer消息。此INVITE必须在它的第一个非失败可靠性消息中提供此offer返回到此UAC端。在此规范中,就是一个对此INVITE的2xx响应消息。
  UAS能够指示处理状态,接受,转发和拒绝此邀请的能力。在这些所有场景中,UAS通过流程来构建一个响应消息,流程的处理方式参考Section 8.2.6。
  13.3.1.1 Progress
  如果UAS不能马上应答请求的话,它可以选择对UAC指示一些呼叫状态(例如,指示电话正在振铃)。这个指示状态通过发送一些临时响应来实现,临时响应取值介于101和199之间。这些临时响应创建早期的dialogs,因此需要遵从Section 12.1.1 章节的内容,和 Section 8.2.6章节的内容。一个UAS只要它愿意,它可以发送多个临时响应。多个临时响应中的每个临时响应必须表示同一dialog ID。不过,这些响应不是可靠传输实现的。
  如果UAS期望一个延迟时间来应答这个INVITE,它将需要请求一个拓展时间防止代理取消这个事务。当在一个事务中,响应之间的时间间隔超过三分钟,代理有取消事务的选择权。为了防止代理权限事务,UAS必须每分钟发送一个非100的临时响应来应对丢失临时响应的可能性。
  当用户被执行了呼叫停靠或者配合PSTN网络工作时(例如没有应答呼叫,进入了IVR流程),INVITE事务可以在这个拓展的时间段继续执行下去。
  13.3.1.2 The INVITE is Redirected
  如果UAS决定转发此呼叫时,需要发送一个3xx响应。一个300 (Multiple Choices),301 (Moved Permanently)或302 (Moved Temporarily)应该包含一个Contact头,这个contact头包含一个或者多个新地址的URLs,这些新地址将会在
  转发呼叫中使用。这个响应被传输到INVITE服务器事务层,事务层处理它的重传。
  13.3.1.3 The INVITE is Rejected
  经常看到的场景是系统呼叫方不能启动或不能再进行额外的呼叫。在这种状态下,应该符合一个486 (Busy Here)。如果UAS知道,无任何系统端资源来接受呼叫时,一个600 (Busy Everywhere)响应应该被返回。但是,好像UAS知道这种情况,因此通常不会使用响应。响应被传递到INVITE 服务器端事务层,事务层将处理重传流程。
  UAS 应该返回一个488 (Not Acceptable Here)响应,实际上,UAS通过一个拒绝的offer来实现,这个offer包含在INVITE中。这样的响应应该包括一个告警头域值,这个值解释offer被拒绝的原因。
  13.3.1.4 The INVITE is Accepted
  UAS core产生一个2xx响应消息。这个响应创建了一个dialog,因此按照Section 12.1.1 的处理流程来执行,另外还有Section 8.2.6流程。
  对INVITE的一个2xx响应应该包含Allow头和Supported头,并且可能包含Accept 头。包括这些头的话,无需侦测UAS功能,在呼叫期间允许UAC决定UAS所提供的功能和其拓展。
  如果INVITE请求包含一个offer消息,并且UAS还没有发送answer消息的话, 2xx响应必须包含一个answer消息。如果此INVITE没有包含offer消息的话,如果UAS还没有发送offer的话,2xx 必须包含一个offer消息。
  一旦响应构建后,响应会被传递到INVITE 服务器事务层。注意,INVITE 服务器事务收到最终响应,传递到传输层后,INVITE服务器事务将被销毁。因此,直到ACK抵达之前,事务层定期直接发送响应消息到传输层是非常必要的。2xx响应被传递到传输层,同时携带一个定时器,定时器从T1秒开始计算,然后针对每个重传定时器时间翻倍计算,直到T1定时器时间设置到了T2秒。(T1和T2定义在Section 17)。当收到针对此响应的ACK请求后,响应重传退出。这里,如何退出不取决于发送响应所使用的传输协议。
  因为2xx通过端对端被重传,因此,在UAS和UAC之间可能有多个hops,这些hops支持的UDP。为了保证经过这些hops的可靠传输,尽管在UAS的传输是可靠性,响应消息也需要定期重传。
  如果在64*T1秒内,服务器端没有收到ACK,服务器重发这个2xx响应,此dialog是被确认的,但是,此会话应该结束。结束会话使用BYE请求消息,具体描述在Section 15章节。
【免责声明】本文仅代表作者本人观点,与CTI论坛无关。CTI论坛对文中陈述、观点判断保持中立,不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。请读者仅作参考,并请自行承担全部责任。

相关阅读:

专题

CTI论坛会员企业