乱翻 之 RFC3262 -PRACK

news/2024/7/6 0:04:11 标签: rack, header, 扩展, authorization, table, c
cle class="baidu_pl">
cle_content" class="article_content clearfix">
content_views" class="htmledit_views">

SIP 中临时响应的可靠性

本文档定义了SIP中提供可靠临时响应消息的一个class="tags" href="/tags/KuoZhan.html" title=扩展>扩展方法。该class="tags" href="/tags/KuoZhan.html" title=扩展>扩展使用一个可选
的标签100rel且定义了临时响应告知(PRACK)方法。


RFC3261使用请求-响应协议来开始并管理通信会话。SIP定义了两种响应
:临时响应和最终响应。最终响应传输请求处理的结果࿰c;并使用可靠传输方式。
临时响应告知正在处理请求࿰c;在3261中不是可靠传输的。

后来在某些情况下发现可靠性非常重要࿰c;包括与PSTN交互的场景。因此࿰c;一个可选
的能力需要用来支持临时响应的可靠传输。

该可靠性机制模仿目前对INVITE请求的2xx最终响应的可靠性机制。这些请求定期地
由TU(事务用户)传输直到一个单独的事务࿰c;收到一个ACK表示接受到了由UAC发出
的2XX响应。对于INVITE的2XX响应和ACK消息是端到端的可靠传输。为了达到临时响
应的可靠性࿰c;我们使用类似的方法。可靠临时响应由TU使用指数backoff方式进行重
传。这些重传在收到PRACK后结束。PRACK请求扮演了和ACK同样的角色࿰c;只不过是对
应临时响应。这是一个很重要的区别。PRACK是一个普通的SIP消息࿰c;就像BYE那样。
因此࿰c;它的可靠性通过每个有状态代理服务器来保证“HOP-BY-HOP”(跳至跳)的
可靠性。和BYE一样࿰c;不同于ACK,PRACK有自己的响应。

每个临时响应都有一个序列号(sequence number), 携带在响应的RSeq头字段。
PRACK包含一个RAck头字段࿰c;表明了它所确认的临时响应的序列号。该确认不是累积
的࿰c;本说明建议一次只发一个明显临时响应࿰c;以控制拥塞。

3 UAS 行为

当初始INVITE包含一个支持(Supported)头字段带有可选标签100rel。UAS可能发
送任何非100临时响应来可靠地回应INVITE࿰c;本说明不允许除对应INVITE之外的临时
可靠响应࿰c;class="tags" href="/tags/KuoZhan.html" title=扩展>扩展定义了新的方法来建立对话可能会使用这种机制。

当初始INVITE包换一个必须(Required)头字段带有可选标签100rel。如果UAS不愿
意接受࿰c;它必须使用420(错误的class="tags" href="/tags/KuoZhan.html" title=扩展>扩展)携带不支持的带有可选标签100Rel的头字段
拒绝初始请求。

UAS不允许对100临时响应进行可靠传输。只有101到199可以可靠传输。如果请求既
没有Supported或Require头字段来表明这个特性࿰c;UAS不允许可靠地发送临时响应

100Trying响应只能逐跳传输。因为这个原因࿰c;我们描述地端到端地可靠机制不能使
用。???

可以作为代理的成员(element)也能发送可靠的临时响应。这种情况下࿰c;它在这个
事务中作为UAS。但是࿰c;它不能对带有一个标签的To头字段的任何请求做可靠临时响
应。这意味着一个代理不能对对话中发送的请求生成可靠临时响应。不同于UAS࿰c;当
代理成员(element)收到一个不匹配可靠临时响应的PRACK࿰c;该PRACK必须被代理。

为什么UAS可能想发送一个可靠的临时响应࿰c;有如下几个理由:第一࿰c;如果INVITE事务
可能需要时间来产生最终响应。如3261中13.3.1.1章节谈论的࿰c;UAS将需要发送定期的
临时响应来向代理请求一个事务的“class="tags" href="/tags/KuoZhan.html" title=扩展>扩展”。需求是一个代理会每隔3分钟收到请求࿰c;但
是因为丢包地可能性UAS需要更频繁地发送请求(建议间隔一分钟)。作为一个更有效
率的解决方案UAS可以可靠地发送响应。这样UAS应该每隔2.5分钟发送一个临时响应。
class="tags" href="/tags/KuoZhan.html" title=扩展>扩展事务中使用可靠临时响应是建议性地。

剩余地讨论假设初始请求包换一个Supported或Require头字段列出100rel,并且有一个
临时响应被可靠的传输。

临时响应被可靠传输是有UAScore根据3261 8.2.6章节的程序来构造的。另外࿰c;它必须
包含Require头字段带有可选标签100rel和Rseq头字段。


UAS可能发送任何非100临时响应来可靠地回应INVITE࿰c;事务中第一个可靠临时响应的头
字段的值必须在1和2**31-1之间。建议从这个范围内均一地选择。Rseq编号空间用于
一个单独地事务。这个意味着对于不同请求的临时响应可能使用相同的Rseq值。

可靠临时响应可能包含一个包体。会话描述的用途在第五章介绍。

可靠临时响应被定期地传输到事务层。间隔从T1妙开始࿰c;然后每隔双倍地时间重传
一次(T1在3261中17章节定义)。一旦传输到服务层事务࿰c;它将被加到一个内部未确认
可靠临时响应列表。事务层将转发每个从UAScore中传过来的重传。

这个和2xx响应的重传不同࿰c;2xx的间隔时间是T2秒。这是因为ACK的重传是由一个2xx接
收来触发的࿰c;但PRACK的重传独立于1xx的接收。

当从UACore中收到一个匹配的PRACK那么可靠临时响应的重传就结束。PRACK就像对话中
的其他请求一样࿰c;UAScore 根据3261 的8.2 ࿰c;12.2.2 章节程序来处理。一个匹配的
PRACK定义类似为在同一会话里的响应࿰c;它的方法࿰c;Cseq-num和 响应号在Rack头字段匹配࿰c;
分别的对应于可靠临时响应的Cseq的方法࿰c;序列号和可靠临时响应中的Rseq中的序列号。

如果UAcore收到一个PRACK请求不匹配任何未确认可靠临时响应࿰c;UAS必须给PRACK返回一
个481响应。如果PRACK匹配一个未确认可靠临时响应࿰c;那么它必须回复一个2xx响应。UAS
可以通过这点来取人临时响应已被有序接收。它应当停止可靠临时响应的重传࿰c;并且必须
将它从未确认临时响应列表中去掉。

如果一个可靠临时响应重传了64×T1秒仍未接收到匹配的PRACK࿰c;UAS应当用5xx响应拒绝初
始请求。

如PRACK包含一个会话描述࿰c;它将如5章节中所描述的进行处理。如果PRACk包含其他类型的
消息体࿰c;这个消息体会按ACK中的消息体的方式进行处理。

在请求的第一个可靠临时响应被确认后࿰c;UAS可能会发送额外的可靠临时响应。UAS必须在
在第一个被确认后才能发送第二个可靠临时响应。第一个可靠临时响应会有特别的处理因
为它负责传递初始序列号。如果额外的可靠在第一个被确认之前发送࿰c;UAS不能确定他们
是否被顺序收到。

接下来的针对相同请求的每个可靠临时响应中Rseq的值必须精确地进行加一操作。Rseq序
号不允许循环。因为初始第一个选择小于2**31 - 1࿰c;但是最大地值是2**32 - 1࿰c;每个请
求可以有超过2**31个临时可靠响应࿰c;这个值绰绰有余。

UAS可能在收到所有未确认可靠临时响应地PRACK之前发送对于这个请求的最终响应࿰c;除非
最终响应是2xx并且所有的未确认可靠临时响应都包含一 个会话描述。在这种情况下࿰c;它
必须在所有临时响应都被确认后才能发送最终响应。如果UAS在所有可靠响应仍未确认前
发送最终响应࿰c;那么它不应当继续重传未确认可靠临时响应࿰c;但是它必须准备处理针对于
这些响应的PRACK请求。UAS在发送了一个对于请求的最终响应后不允许再发送新的可靠临
时响应(与未确认响应的的重传相对立)。

4.UAC 行为

当UAC建立了一个新的请求࿰c;它可以坚持对该请求进行临时响应的可靠传送。为了实现该能
力࿰c;它在请求中插入了一个带100rel可选标签的Require头字段。带100rel可选标签的
Require头字段只能在INVITE请求中使用࿰c;尽管SIP的class="tags" href="/tags/KuoZhan.html" title=扩展>扩展可能允许其他的请求方法使用它。
                            Header field          where   PRACK
               ___________________________________
               Accept                  R       o
               Accept                 2xx      -
               Accept                 415      c
               Accept-Encoding         R       o
               Accept-Encoding        2xx      -
               Accept-Encoding        415      c
               Accept-Language         R       o
               Accept-Language        2xx      -
               Accept-Language        415      c
               Alert-Info              R       -
               Alert-Info             180      -
               Allow                   R       o
               Allow                  2xx      o
               Allow                   r       o
               Allow                  405      m
               Authentication-Info    2xx      o
               Authorization           R       o
               Call-ID                 c       m
               Call-Info                       -
               Contact                 R       -
               Contact                1xx      -
               Contact                2xx      -
               Contact                3xx      o
               Contact                485      o
               Content-Disposition             o
               Content-Encoding                o
               Content-Language                o
               Content-Length                  t
               Content-Type                    *
               CSeq                    c       m
               Date                            o
               Error-Info           300-699    o
               Expires                         -
               From                    c       m
               In-Reply-To             R       -
               Max-Forwards            R       m
               Min-Expires            423      -
               MIME-Version                    o
               Organization                    -

               Table 1: Summary of class="tags" href="/tags/HEADER.html" title=header>header fields, A--O
              
               Header field              where      PRACK
            __________________________________________
            Priority                    R          -
            Proxy-Authenticate         407         m
            Proxy-Authenticate         401         o
            Proxy-Authorization         R          o
            Proxy-Require               R          o
            Record-Route                R          o
            Record-Route             2xx,18x       o
            Reply-To                               -
            Require                                c
            Retry-After          404,413,480,486   o
                                     500,503       o
                                     600,603       o
            Route                       R          c
            Server                      r          o
            Subject                     R          -
            Supported                   R          o
            Supported                  2xx         o
            Timestamp                              o
            To                          c          m
            Unsupported                420         m
            User-Agent                             o
            Via                         c          m
            Warning                     r          o
            WWW-Authenticate           401         m

            Table 2: Summary of class="tags" href="/tags/HEADER.html" title=header>header fields, P--Z
           
           
如果UAC不一定要求使用可靠临时响应࿰c;但只是表明如果UAS需要发送那么它会支持࿰c;
带100rel可选标签的Supported头字段必须出现在请求当中。UAC应该在所有的INVITE
请求中加入该字段。

如果收到了一个初始请求的临时响应࿰c;并且响应包含带100rel可选标签的Require
头字段࿰c;那么响应会被可靠地传送。如果响应是一个100(trying)(非101~199)
c;那么这个可选标签必须忽略࿰c;如下的过程将不会用到。

如果对话还没建立那么临时响应必须建立一个对话。

假设响应被可靠地传输࿰c;UAC必须建立一个PRACK的新请求。这个请求与之前的临时
响应是处于同一对话中的。(事实上࿰c;这个临时响应可能已经建立了这个对话)。
PRACK请求可能包含消息体࿰c;根据他们的类型和部署来说明该消息体。???

请注意PRACK就如对话中其他的非INVITE请求。特殊的是࿰c;一个UAC在它收到已确认
的临时响应的重传是不会重传PRACK请求࿰c;尽管这样做不会产生一个协议错误。

一旦收到一个可靠的临时响应࿰c;对应该响应的重传必须遗弃。当它的会话ID࿰c;Cseq
和Rseq和原始的响应匹配时我们认为这个响应是个重传。UAC必须包含一个序列号来
表明最近接收到的针对初始请求的顺序可靠临时响应。这个序列号将一直维持直到
接收到初始请求的最终响应。它的值必须用对初始请求的第一个可靠临时响应中Rseq
头字段值来进行初始化。

处理对于同一个初始请求的后续可靠临时响应遵循以上的规则࿰c;区别在于:可靠
临时响应保证是顺序的。结果是,如果UAC接收到同一另外一个可靠临时响应࿰c;并且
它的Rseq值不比前一个序列号的值高(大)࿰c;那么该响应不能够用PRACK来确认。目
前的实现是可能是抛弃这个响应࿰c;或者缓存该响应以期收到丢失的响应。

UAC在最终响应后可能确认接收到的可靠临时响应也可能丢弃。

5.Offer/Answer 模型和PRACK

3261描述了在哪些消息中可以出现请求和应答。基于那些模型࿰c;本class="tags" href="/tags/KuoZhan.html" title=扩展>扩展提供了offer和
answer模型的新交互方式。

如果INVITE包含一个offer࿰c;那么UAS可能在一个可靠临时响应中产生一个answer(假设
UAC支持这些方法)。那么导致在完成这个电话之前就已经建立一个会话。类似的࿰c;如果
一个可靠临时响应是第一个发回给UAC的可靠消息࿰c;并且INVITE不带有offer࿰c;那么offer
必须在那个可靠临时响应中出现。

如果UAC接收到一个可靠临时响应带了offer(发生在当UAC发送了一个不带offer的INVITE
情况下࿰c;这导致第一个可靠临时响应将包含offer)࿰c;它必须在PRACK中生成一个answer。
如果UAC接收到了一个带有answer的可靠临时响应࿰c;它将可能在PRACK中生成一个附加的
offer。如果UAS收到带offer的PRACK࿰c;它必须在PRACK对应的2xx中携带answer。

一旦收到或者发出一个answer࿰c;UA应当根据offer和answer中的参数来建立会话࿰c;就算初始
的INVITE还没有被响应。

如果UAS将一个会话描述放在了任何一个当INVITE接收时还没有被确认的可靠临时响应中时࿰c;
UAS必须延迟发送2xx直到该临时响应被确认。否则࿰c;1xx响应的可靠性没有办法得到保证࿰c;
在offer和answer交互的正常操作中需要可靠性保证。

所有支持这个class="tags" href="/tags/KuoZhan.html" title=扩展>扩展的用户代理必须支持3261中13.2章节所描述的offer/answer交互的所有可能
的规则。如基于INVITE和PRACK作为请求࿰c;2xx和可靠的1XX作为非失败的可靠响应。

6. PRACK方法的定义

本说明定义了一个新的SIP方法࿰c;PRACK。语意如上表述。表1࿰c;2是从3261的表2和3中针对这个
新方法class="tags" href="/tags/KuoZhan.html" title=扩展>扩展出来的。

7. 头字段定义

本说明定义了两个新的头字段࿰c;RAck和RSeq。表3是从3261的表2和3中针对这俩个新头字段
class="tags" href="/tags/KuoZhan.html" title=扩展>扩展出来的。

7.1 RSeq
Rseq头字段是用于临时响应的可靠传输。它包含一个单一数值:1到2**32 -1.关于它的用途请
参照第三章。

例:RSeq:988789
Header field  where  proxy ACK BYE CAN INV OPT REG PRA
      ______________________________________________________
      RAck            R           -   -   -   -   -   -   m
      RSeq           1xx          -   -   -   o   -   -   -


      Table 3: RAck and RSeq Header Fields


7.2 RAck
    RAck头字段在PRACK请求中发送以支持临时响应的可靠性。它包含两个数字和
    一个方法标签。第一个数字是从被确认的临时响应中的RSeq头字段中获得的。
    第二个数字和方法是从被确认的响应中的CSeq中获取的。RAck头字段中的方法
    名是区分大小写的。
   
    例: RAck:776656 1 INVITE
   
8 IANA 考虑事项

本说明注册了一个单一的可选标签100rel。

100rel
描述:本可选标签是为了保证临时响应的可靠传输。当它出现在Supported头字段
的时候࿰c;表明UA可以发送或接收可靠临时响应࿰c;当出现在请求的Require头字段时
c;表明UAS必须可靠地发送所有地临时响应。 当出现在一个可靠临时响应的Require
头字段时࿰c;表明该响应将被可靠地传输。


9 安全考虑

攻击者可以注入PRACK请求来强迫可靠临时响应停止重传。因为这些响应可以传达
重要的信息࿰c;PRACK消息应该可以像其他的请求那样接收认证。认证过程定义参见
3261。

10.收集的BNF
   RACKm        =  %x50.52.41.43.4B ; PRACK in caps
   Method        =  INVITEm / ACKm / OPTIONSm / BYEm
                    / CANCELm / REGISTERm / PRACKm
                    / extension-method
   RAck          =  "RAck" HCOLON response-num LWS CSeq-num LWS Method
   response-num  =  1*DIGIT
   CSeq-num      =  1*DIGIT
   RSeq          =  "RSeq" HCOLON response-num


cle>

http://www.niftyadmin.cn/n/1825822.html

相关文章

【BUG历险记】vivado报错:binding vhdl entity ‘ xxxxx ‘does not have port ‘ xxxxx ‘解决方案

🏔【BUG历险记】vivado报错:binding vhdl entity xxxxx does not have port xxxxx 解决方案 问题描述 我在编写雷达的脉冲压缩仿真时,先例化了FFT和复数乘法器,并仿真验证通过了;再例化IFFT,结果仿真时…

JavaScript 常用功能总结

2019独角兽企业重金招聘Python工程师标准>>> 编吐血整理加上翻译,太辛苦了~求赞! 本文主要总结了JavaScript 常用功能总结,如一些常用的JS 对象,基本数据结构,功能函数等,还有一些常用的设计模式…

IIS7保存配置文件及导入、导出、备份、还原

IIS6下想要保存配置,只需在图形界面下点右键保存即可,但windows 2008下的IIS7却没有这样的选项,IIS7的配置文件有好几个,在c:\windows\system32\inetsrv\config文件夹下,如果需要手动去备份,只要复制一份co…

思科交换机简单配置(机房!!!)

show interfaces status 查看端口的基本状态信息 show ip interfaces brief 查看包括IP信息在内的端口简要状态信息 >en #conf t #int fa/gi #sw mo acc #sw acc vlan xx转载于:https://www.cnblogs.com/jcksb/p/8548088.html

经典算法复习-插入排序算法

温习《数据结构C语言版》&#xff0c;看到排序算法&#xff0c;感觉看不懂。 写到代码实现下&#xff0c;花费了很久才搞出来。 实现的跟书本上的有点不一样哦&#xff0c;不喜勿喷。 参考文章&#xff1a; http://blog.csdn.net/hguisu/article/details/7776068 #include <…

vmware centos6.6 64位 kvm虚拟化安装配置

参考资料&#xff1a;http://taokey.blog.51cto.com/4633273/1540873 http://www.server-world.info/en/note?osCentOS_6&pkvm&f1http://koumm.blog.51cto.com/703525/1288795http://www.361way.com/category/v ... d-automation/page/3做这个实验&#xff0c;需要我们…

[python]range和xrange的区别

参见->这里转载于:https://www.cnblogs.com/DLarTisan/p/8557226.html