乱翻 之 RFC3262.docx
《乱翻 之 RFC3262.docx》由会员分享，可在线阅读，更多相关《乱翻 之 RFC3262.docx（11页珍藏版）》请在冰豆网上搜索。
乱翻之RFC3262
乱翻之RFC3262－PRACK
----csdnlixin62001的专栏
SIP中临时响应的可靠性
本文档定义了SIP中提供可靠临时响应消息的一个扩展方法。
该扩展使用一个可选
的标签100rel且定义了临时响应告知（PRACK）方法。
RFC3261使用请求－响应协议来开始并管理通信会话。
SIP定义了两种响应
：
临时响应和最终响应。
最终响应传输请求处理的结果，并使用可靠传输方式。
临时响应告知正在处理请求，在3261中不是可靠传输的。
后来在某些情况下发现可靠性非常重要，包括与PSTN交互的场景。
因此，一个可选
的能力需要用来支持临时响应的可靠传输。
该可靠性机制模仿目前对INVITE请求的2xx最终响应的可靠性机制。
这些请求定期地
由TU（事务用户）传输直到一个单独的事务，收到一个ACK表示接受到了由UAC发出
的2XX响应。
对于INVITE的2XX响应和ACK消息是端到端的可靠传输。
为了达到临时响
应的可靠性，我们使用类似的方法。
可靠临时响应由TU使用指数backoff方式进行重
传。
这些重传在收到PRACK后结束。
PRACK请求扮演了和ACK同样的角色，只不过是对
应临时响应。
这是一个很重要的区别。
PRACK是一个普通的SIP消息，就像BYE那样。
因此，它的可靠性通过每个有状态代理服务器来保证“HOP－BY－HOP”（跳至跳）的
可靠性。
和BYE一样，不同于ACK,PRACK有自己的响应。
每个临时响应都有一个序列号（sequencenumber）,携带在响应的RSeq头字段。
PRACK包含一个RAck头字段，表明了它所确认的临时响应的序列号。
该确认不是累积
的，本说明建议一次只发一个明显临时响应，以控制拥塞。
3UAS行为
当初始INVITE包含一个支持（Supported）头字段带有可选标签100rel。
UAS可能发
送任何非100临时响应来可靠地回应INVITE，本说明不允许除对应INVITE之外的临时
可靠响应，扩展定义了新的方法来建立对话可能会使用这种机制。
当初始INVITE包换一个必须（Required）头字段带有可选标签100rel。
如果UAS不愿
意接受，它必须使用420（错误的扩展）携带不支持的带有可选标签100Rel的头字段
拒绝初始请求。
UAS不允许对100临时响应进行可靠传输。
只有101到199可以可靠传输。
如果请求既
没有Supported或Require头字段来表明这个特性，UAS不允许可靠地发送临时响应
100Trying响应只能逐跳传输。
因为这个原因，我们描述地端到端地可靠机制不能使
用。
？
？
？
可以作为代理的成员（element）也能发送可靠的临时响应。
这种情况下，它在这个
事务中作为UAS。
但是，它不能对带有一个标签的To头字段的任何请求做可靠临时响
应。
这意味着一个代理不能对对话中发送的请求生成可靠临时响应。
不同于UAS，当
代理成员（element）收到一个不匹配可靠临时响应的PRACK，该PRACK必须被代理。
为什么UAS可能想发送一个可靠的临时响应，有如下几个理由：
第一，如果INVITE事务
可能需要时间来产生最终响应。
如3261中13.3.1.1章节谈论的，UAS将需要发送定期的
临时响应来向代理请求一个事务的“扩展”。
需求是一个代理会每隔3分钟收到请求，但
是因为丢包地可能性UAS需要更频繁地发送请求（建议间隔一分钟）。
作为一个更有效
率的解决方案UAS可以可靠地发送响应。
这样UAS应该每隔2.5分钟发送一个临时响应。
在扩展事务中使用可靠临时响应是建议性地。
剩余地讨论假设初始请求包换一个Supported或Require头字段列出100rel,并且有一个
临时响应被可靠的传输。
临时响应被可靠传输是有UAScore根据32618.2.6章节的程序来构造的。
另外，它必须
包含Require头字段带有可选标签100rel和Rseq头字段。
UAS可能发送任何非100临时响应来可靠地回应INVITE，事务中第一个可靠临时响应的头
字段的值必须在1和2**31－1之间。
建议从这个范围内均一地选择。
Rseq编号空间用于
一个单独地事务。
这个意味着对于不同请求的临时响应可能使用相同的Rseq值。
可靠临时响应可能包含一个包体。
会话描述的用途在第五章介绍。
可靠临时响应被定期地传输到事务层。
间隔从T1妙开始，然后每隔双倍地时间重传
一次（T1在3261中17章节定义）。
一旦传输到服务层事务，它将被加到一个内部未确认
可靠临时响应列表。
事务层将转发每个从UAScore中传过来的重传。
这个和2xx响应的重传不同，2xx的间隔时间是T2秒。
这是因为ACK的重传是由一个2xx接
收来触发的，但PRACK的重传独立于1xx的接收。
当从UACore中收到一个匹配的PRACK那么可靠临时响应的重传就结束。
PRACK就像对话中
的其他请求一样，UAScore根据3261的8.2，12.2.2章节程序来处理。
一个匹配的
PRACK定义类似为在同一会话里的响应，它的方法，Cseq－num和响应号在Rack头字段匹配，
分别的对应于可靠临时响应的Cseq的方法，序列号和可靠临时响应中的Rseq中的序列号。
如果UAcore收到一个PRACK请求不匹配任何未确认可靠临时响应，UAS必须给PRACK返回一
个481响应。
如果PRACK匹配一个未确认可靠临时响应，那么它必须回复一个2xx响应。
UAS
可以通过这点来取人临时响应已被有序接收。
它应当停止可靠临时响应的重传，并且必须
将它从未确认临时响应列表中去掉。
如果一个可靠临时响应重传了64×T1秒仍未接收到匹配的PRACK，UAS应当用5xx响应拒绝初
始请求。
如PRACK包含一个会话描述，它将如5章节中所描述的进行处理。
如果PRACk包含其他类型的
消息体，这个消息体会按ACK中的消息体的方式进行处理。
在请求的第一个可靠临时响应被确认后，UAS可能会发送额外的可靠临时响应。
UAS必须在
在第一个被确认后才能发送第二个可靠临时响应。
第一个可靠临时响应会有特别的处理因
为它负责传递初始序列号。
如果额外的可靠在第一个被确认之前发送，UAS不能确定他们
是否被顺序收到。
接下来的针对相同请求的每个可靠临时响应中Rseq的值必须精确地进行加一操作。
Rseq序
号不允许循环。
因为初始第一个选择小于2**31-1，但是最大地值是2**32-1，每个请
求可以有超过2**31个临时可靠响应，这个值绰绰有余。
UAS可能在收到所有未确认可靠临时响应地PRACK之前发送对于这个请求的最终响应，除非
最终响应是2xx并且所有的未确认可靠临时响应都包含一个会话描述。
在这种情况下，它
必须在所有临时响应都被确认后才能发送最终响应。
如果UAS在所有可靠响应仍未确认前
发送最终响应，那么它不应当继续重传未确认可靠临时响应，但是它必须准备处理针对于
这些响应的PRACK请求。
UAS在发送了一个对于请求的最终响应后不允许再发送新的可靠临
时响应（与未确认响应的的重传相对立）。
4.UAC行为
当UAC建立了一个新的请求，它可以坚持对该请求进行临时响应的可靠传送。
为了实现该能
力，它在请求中插入了一个带100rel可选标签的Require头字段。
带100rel可选标签的
Require头字段只能在INVITE请求中使用，尽管SIP的扩展可能允许其他的请求方法使用它。
Headerfield 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 -
Table1:
Summaryofheaderfields,A--O
Headerfield 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
Table2:
Summaryofheaderfields,P--Z
如果UAC不一定要求使用可靠临时响应，但只是表明如果UAS需要发送那么它会支持，
带100rel可选标签的Supported头字段必须出现在请求当中。
UAC应该在所有的INVITE
请求中加入该字段。
如果收到了一个初始请求的临时响应，并且响应包含带100rel可选标签的Require
头字段，那么响应会被可靠地传送。
如果响应是一个100（trying）（非101～199）
，那么这个可选标签必须忽略，如下的过程将不会用到。
如果对话还没建立那么临时响应必须建立一个对话。
假设响应被可靠地传输，UAC必须建立一个PRACK的新请求。
这个请求与之前的临时
响应是处于同一对话中的。
（事实上，这个临时响应可能已经建立了这个对话）。
PRACK请求可能包含消息体，根据他们的类型和部署来说明该消息体。
？
？
？
请注意PRACK就如对话中其他的非INVITE请求。
特殊的是，一个UAC在它收到已确认
的临时响应的重传是不会重传PRACK请求，尽管这样做不会产生一个协议错误。
一旦收到一个可靠的临时响应，对应该响应的重传必须遗弃。
当它的会话ID，Cseq
和Rseq和原始的响应匹配时我们认为这个响应是个重传。
UAC必须包含一个序列号来
表明最近接收到的针对初始请求的顺序可靠临时响应。
这个序列号将一直维持直到
接收到初始请求的最终响应。
它的值必须用对初始请求的第一个可靠临时响应中Rseq
头字段值来进行初始化。
处理对于同一个初始请求的后续可靠临时响应遵循以上的规则，区别在于：
可靠
临时响应保证是顺序的。
结果是,如果UAC接收到同一另外一个可靠临时响应，并且
它的Rseq值不比前一个序列号的值高（大），那么该响应不能够用PRACK来确认。
目
前的实现是可能是抛弃这个响应，或者缓存该响应以期收到丢失的响应。
UAC在最终响应后可能确认接收到的可靠临时响应也可能丢弃。
5.Offer/Answer模型和PRACK
3261描述了在哪些消息中可以出现请求和应答。
基于那些模型，本扩展提供了offer和
answer模型的新交互方式。
如果INVITE包含一个offer，那么UAS可能在一个可靠临时响应中产生一个answer（假设
UAC支持这些方法）。
那么导致在完成这个电话之前就已经建立一个会话。
类似的，如果
一个可靠临时响应是第一个发回给UAC的可靠消息，并且INVITE不带有offer，那么offer
必须在那个可靠临时响应中出现。
如果UAC接收到一个可靠临时响应带了offer（发生在当UAC发送了一个不带offer的INVITE
情况下，这导致第一个可靠临时响应将包含offer），它必须在PRACK中生成一个answer。
如果UAC接收到了一个带有answer的可靠临时响应，它将可能在PRACK中生成一个附加的
offer。
如果UAS收到带offer的PRACK，它必须在PRACK对应的2xx中携带answer。
一旦收到或者发出一个answer，UA应当根据offer和answer中的参数来建立会话，就算初始
的INVITE还没有被响应。
如果UAS将一个会话描述放在了任何一个当INVITE接收时还没有被确认的可靠临时响应中时，
UAS必须延迟发送2xx直到该临时响应被确认。
否则，1xx响应的可靠性没有办法得到保证，
在offer和answer交互的正常操作中需要可靠性保证。
所有支持这个扩展的用户代理必须支持3261中13.2章节所描述的offer/answer交互的所有可能
的规则。
如基于INVITE和PRACK作为请求，2xx和可靠的1XX作为非失败的可靠响应。
6.PRACK方法的定义
本说明定义了一个新的SIP方法，PRACK。
语意如上表述。
表1，2是从3261的表2和3中针对这个
新方法扩展出来的。
7.头字段定义
本说明定义了两个新的头字段，RAck和RSeq。
表3是从3261的表2和3中针对这俩个新头字段
扩展出来的。
7.1RSeq
Rseq头字段是用于临时响应的可靠传输。
它包含一个单一数值：
1到2**32-1.关于它的用途请
参照第三章。
例：
RSeq：
988789
Headerfield where proxyACKBYECANINVOPTREGPRA
______________________________________________________
RAck R - - - - - - m
RSeq 1xx - - - o - - -
Table3:
RAckandRSeqHeaderFields
7.2RAck
RAck头字段在PRACK请求中发送以支持临时响应的可靠性。
它包含两个数字和
一个方法标签。
第一个数字是从被确认的临时响应中的RSeq头字段中获得的。
第二个数字和方法是从被确认的响应中的CSeq中获取的。
RAck头字段中的方法
名是区分大小写的。
例：
RAck：
7766561INVITE
8IANA考虑事项
本说明注册了一个单一的可选标签100rel。
100rel
描述：
本可选标签是为了保证临时响应的可靠传输。
当它出现在Supported头字段
的时候，表明UA可以发送或接收可靠临时响应，当出现在请求的Require头字段时
，表明UAS必须可靠地发送所有地临时响应。
当出现在一个可靠临时响应的Require
头字段时，表明该响应将被可靠地传输。
9安全考虑
攻击者可以注入PRACK请求来强迫可靠临时响应停止重传。
因为这些响应可以传达
重要的信息，PRACK消息应该可以像其他的请求那样接收认证。
认证过程定义参见
3261。
10.收集的BNF
RACKm = %x50.52.41.43.4B;PRACKincaps
Method = INVITEm/ACKm/OPTIONSm/BYEm
/CANCELm/REGISTERm/PRACKm
/extension-method
RAck = "RAck"HCOLONresponse-numLWSCSeq-numLWSMethod
response-num = 1*DIGIT
CSeq-num = 1*DIGIT
RSeq = "RSeq"HCOLONresponse-num
升级会员 