概述
SIP定义了两种应答：临时（provisional)和最终（final）。
最终应答传送的是请求处理的结果，是可靠性的（reliably）。而临时应答传送的是处理过程的信息，由RFC3261是非可靠的。
但是由现在的情况看来，特别是与PSTN交互过程中发现：临时应答也应该是可靠的。

RFC3262定义了一种SIP可选的扩展方法——PRACK（provisionalack），用于支持临时应答的可靠性。它的实现机制如下：
借鉴了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