PRACK简介

100rel扩展即是对中间状态响应的确认（即1xx的响应码）。

原先在sip里，只有针对invite 请求的200ok响应才会有ack，那么当中间状态响应携带重要的会话参数信息时，例如183响应，客户端是否收到响应就没有ack请求了，于是就定义了prack这一请求消息，即对中间状态响应的确认请求。

当sip发送者支持这一扩展时，及在support头域增加这个100rel消息，当server端给与1xx响应时，可以在头域里的require字段要求这一100rel 的能力。

此时，sip发送者，发送prack消息。

PRACK用于保证1**（除100外）的可靠传输，如果1**响应中的的Require头部中带有100rel这个参数，那么client端收到这个1**后，就需要发PRACK保证这个1**的可靠传输，当server端收到PRACK后，说对端已经收到了这个1**,此时server需要回PRACK 的200响应。

按照RFC3261,,如果请求中有100rel标志,UAS必须用可靠传输的方式发送非100的临时响应(101-199),如果UAS不愿意这样做,它必须利用420(Bad Extension)拒掉这个请求.
假设UAC接收到需要可靠传输的非100临时响应后（101－199）,它必须用PRACK方法创建一新请求发送给UAS，以确认已收到此响应,UAS会回应一200OK。

有的流程有PRACK，说明它有100rel的支持，没有PRACK说明不支持100rel。

UAC发起的INVITE中含有Supported: 100 rel,而UAS也支持该扩展并且在183响应中有Require:100rel，说明接下来会话中，对所有100以外的1xx响应，均要有PRACK回应。

uac如果不支持100rel，但uas要求支持100rel（Require:100rel），uac 发送CANCEL，切断会话。

uac如果不支持100rel，但uas也不支持或不要求支持100rel，只是在后面的过程中，uac 对应接收到的临时响应，如180，183等，不需要发送prack回应而已，与是否会出现183
没有关系。

100rel是一个任选标记，如果INVITE请求的Supported头域中包含该标记，说明发送请求的UAC支持PRACK扩展。

了解PRACK
概述
SIP定义了两种应答：临时（provisional)和最终（final）。

最终应答传送的是请求处理的结果，是可靠性的（reliably）。

而临时应答传送的是处理过程的信息，由RFC3261是非可靠的。

但是由现在的情况看来，特别是与PSTN交互过程中发现：临时应答也应该是可靠的。

RFC3262定义了一种SIP可选的扩展方法——PRACK（provisional ack），用于支持临时应答的可靠性。

它的实现机制如下：
借鉴了INVITE请求的2**应答的可靠性机制：通过构造新的事务来重发ACK来确认接收到了2**应答，这种可靠性是端点到端点（end-to-end）的。

对于1**（除100外）的应答，使用PRACK来终止该应答的重发。

PRACK是对临时应答而言，不同于ACK，是一种跟BYE 一样的正常SIP消息。

所以它的可靠性是点到点（hop-by-hop）的，且具有应答。

每个临时响应都有一个顺序号，在于RSeq头域中。

而PRACK消息包括了RAck头域，指示回应的临时相应的顺序号，且不具有积累效果。

UAS行为
如果请求INVITE的头域Supported中包括选项100rel，UAS可能发送可靠性临时响应；如果请求INVITE的头域Require中包括选项100rel，UAS必须发送可靠性临时响应，否则发送420 (Bad Extension)且Unsupported头域中包括选项100rel。

但是，如果请求中不满足以上任一情况，则不能支持可靠临时相应。

UAS需要发送可靠临时相应原因：
多种原因。

其中之一为根据RFC3261,如果UAS需要一段时间来处理请求，UAS需要发送临时相应消息给Proxies来“延时（extention）”，因为Proxy一般只保留请求上下文3分钟，所以为了避免丢失消息，常需要1分钟重发一次。

而使用可靠临时相应只需2分半钟
重发一次。

可靠临时响应的构建：
只需在RFC3261的基础上进行一些补充：必须包括Require头域（包括100rel选项）和RSeq头域（值为1到2**32-1，是对话中是唯一的）。

PRACK和临时响应的匹配：
PRACK首先必须和临时相应在同一个对话之中，RAck中的方法、CSeq-num和response-num分别对应于临时响应CSeq中的方法、CSeq中的序号和RSeq的序号。

如果接受到的PRACK无法找到相匹配的临时相应，则回应481；否则回应2**，并停止该临时相应的重发。

如果在64*T1时间内没有接收到PRACK，则UAS回应5**。

在第一个可靠响应得到回应，才可以发送第二个可靠相应。

对于同一个请求，第二个可靠相应的RSeq比第一个大1。

UAS可以在可靠临时响应未收到PRACK情况下发送最终应答，除了以下情况：最终响应为2**且其中一个临时相应中有媒体描述。

如果最终响应已经发送，则临时相应的重发和新的临时消息发送都不能进行。

UAC行为
如果需要可靠临时应答，则在INVITE请求的Require头域中包含100rel选项，而其他方法中的Require中不能包含该选项；如果将可靠临时应答的需求的决定权交给UAS，则应在INVITE的头域Supported中包含100rel选项。

当头域Require中包含100rel的临时消息到来时，且临时消息非100，说明临时消息是可靠的。

UAC接下来在对话中建立PRACK请求，跟其它在对话中建立的非INVITE请求一样，UAC不应在接收到重发的可靠临时应答时重发PRACK，即使重发不会引起协议错误。

一个临时应答到来时，如果dialog ID、CSeq、和RSeq跟之前的一样时，该应答视为重发，该应答必须被丢弃。

所以，UAC需要记录RSeq值直到最终应答的到来。

如果新的一个临时应答到来时，需要判断RSeq是否比之前的值大。

如果不是的话，则不能回应PRACK,可以丢弃该临时应答或缓存起来以等待没有到来的老的临时应答。

如果在最终应答到来之后收到临时应答，可以回应或直接丢弃。

Offer/Answer模型和PRACK方法
（详见RFC3262或之后的关于Offer/Answer的文章）
注：
1）RFC3262中不支持除INVITE外其它方法的可靠性临时响应，除非是能建立对话的扩展方法。

2）UAS不能发送可靠的100临时相应。

因为100响应一般是hop-by-hop的，即消息的
可靠性在于hop的两端之间，而不在于端到端之间；而这里实现的可靠性是端到端之间的，即接受消息初始发送和最终接受方，能满足消息真正交互成功。

但是PRACK的可靠性又是hop-by-hop的，即PRACK方法的消息交互依靠的是hop之间的确认。

参考：
RFC3262
===================================================== 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有自己的响应。

每个临时响应都有一个序列号（sequence number）, 携带在响应的RSeq头字段。

PRACK 包含一个RAck头字段，表明了它所确认的临时响应的序列号。

该确认不是累积的，本说明建议一次只发一个明显临时响应，以控制拥塞。

3 UAS 行为
当初始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根据3261 8.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的扩展可能允许其他的请求方法使用它。

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 *
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 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
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
T able 2: Summary of header fields, 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.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头字段
的时候，表明UA可以发送或接收可靠临时响应，当出现在请求的Require头字段时，表明UAS必须可靠地发送所有地临时响应。

当出现在一个可靠临时响应的Require 头字段时，表明该响应将被可靠地传输。

9 安全考虑
攻击者可以注入PRACK请求来强迫可靠临时响应停止重传。

因为这些响应可以传达
重要的信息，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。