概述
SIP定義了兩種應(yīng)答：臨時（provisional)和最終（final）。
最終應(yīng)答傳送的是請求處理的結(jié)果，是可靠性的（reliably）。而臨時應(yīng)答傳送的是處理過程的信息，由RFC3261是非可靠的。
但是由現(xiàn)在的情況看來，特別是與PSTN交互過程中發(fā)現(xiàn)：臨時應(yīng)答也應(yīng)該是可靠的。

RFC3262定義了一種SIP可選的擴展方法——PRACK（provisionalack），用于支持臨時應(yīng)答的可靠性。它的實現(xiàn)機制如下：
借鑒了INVITE請求的2**應(yīng)答的可靠性機制：通過構(gòu)造新的事務(wù)來重發(fā)ACK來確認接收到了2**應(yīng)答，這種可靠性是端點到端點（end-to-end）的。對于1**（除100外）的應(yīng)答，使用PRACK來終止該應(yīng)答的重發(fā)。PRACK是對臨時應(yīng)答而言，不同于ACK，是一種跟BYE一樣的正常SIP消息。所以它的可靠性是點到點（hop-by-hop）的，且具有應(yīng)答。

每個臨時響應(yīng)都有一個順序號，在于RSeq頭域中。而PRACK消息包括了RAck頭域，指示回應(yīng)的臨時相應(yīng)的順序號，且不具有積累效果。


UAS行為
如果請求INVITE的頭域Supported中包括選項100rel，UAS可能發(fā)送可靠性臨時響應(yīng)；如果請求INVITE的頭域Require中包括選項100rel，UAS必須發(fā)送可靠性臨時響應(yīng)，否則發(fā)送420(Bad Extension)且Unsupported頭域中包括選項100rel。
但是，如果請求中不滿足以上任一情況，則不能支持可靠臨時相應(yīng)。

UAS需要發(fā)送可靠臨時相應(yīng)原因：
多種原因。其中之一為根據(jù)RFC3261,如果UAS需要一段時間來處理請求，UAS需要發(fā)送臨時相應(yīng)消息給Proxies來“延時（extention）”，因為Proxy一般只保留請求上下文3分鐘，所以為了避免丟失消息，常需要1分鐘重發(fā)一次。而使用可靠臨時相應(yīng)只需2分半鐘重發(fā)一次。

可靠臨時響應(yīng)的構(gòu)建：
只需在RFC3261的基礎(chǔ)上進行一些補充：必須包括Require頭域（包括100rel選項）和RSeq頭域（值為1到2**32-1，是對話中是唯一的）。

PRACK和臨時響應(yīng)的匹配：
PRACK首先必須和臨時相應(yīng)在同一個對話之中，RAck中的方法、CSeq-num和response-num分別對應(yīng)于臨時響應(yīng)CSeq中的方法、CSeq中的序號和RSeq的序號。

如果接受到的PRACK無法找到相匹配的臨時相應(yīng)，則回應(yīng)481；否則回應(yīng)2**，并停止該臨時相應(yīng)的重發(fā)。
如果在64*T1時間內(nèi)沒有接收到PRACK，則UAS回應(yīng)5**。
在第一個可靠響應(yīng)得到回應(yīng)，才可以發(fā)送第二個可靠相應(yīng)。對于同一個請求，第二個可靠相應(yīng)的RSeq比第一個大1。

UAS可以在可靠臨時響應(yīng)未收到PRACK情況下發(fā)送最終應(yīng)答，除了以下情況：最終響應(yīng)為2**且其中一個臨時相應(yīng)中有媒體描述。如果最終響應(yīng)已經(jīng)發(fā)送，則臨時相應(yīng)的重發(fā)和新的臨時消息發(fā)送都不能進行。


UAC行為
如果需要可靠臨時應(yīng)答，則在INVITE請求的Require頭域中包含100rel選項，而其他方法中的Require中不能包含該選項；如果將可靠臨時應(yīng)答的需求的決定權(quán)交給UAS，則應(yīng)在INVITE的頭域Supported中包含100rel選項。
當(dāng)頭域Require中包含100rel的臨時消息到來時，且臨時消息非100，說明臨時消息是可靠的。UAC接下來在對話中建立PRACK請求，跟其它在對話中建立的非INVITE請求一樣，UAC不應(yīng)在接收到重發(fā)的可靠臨時應(yīng)答時重發(fā)PRACK，即使重發(fā)不會引起協(xié)議錯誤。

一個臨時應(yīng)答到來時，如果dialog ID、CSeq、和RSeq跟之前的一樣時，該應(yīng)答視為重發(fā)，該應(yīng)答必須被丟棄。所以，UAC需要記錄RSeq值直到最終應(yīng)答的到來。
如果新的一個臨時應(yīng)答到來時，需要判斷RSeq是否比之前的值大。如果不是的話，則不能回應(yīng)PRACK,可以丟棄該臨時應(yīng)答或緩存起來以等待沒有到來的老的臨時應(yīng)答。

如果在最終應(yīng)答到來之后收到臨時應(yīng)答，可以回應(yīng)或直接丟棄。


Offer/Answer模型和PRACK方法
（詳見RFC3262或之后的關(guān)于Offer/Answer的文章）

注：
1）RFC3262中不支持除INVITE外其它方法的可靠性臨時響應(yīng)，除非是能建立對話的擴展方法。
2）UAS不能發(fā)送可靠的100臨時相應(yīng)。因為100響應(yīng)一般是hop-by-hop的，即消息的可靠性在于hop的兩端之間，而不在于端到端之間；而這里實現(xiàn)的可靠性是端到端之間的，即接受消息初始發(fā)送和最終接受方，能滿足消息真正交互成功。但是PRACK的可靠性又是hop-by-hop的，即PRACK方法的消息交互依靠的是hop之間的確認。


參考：
RFC3262

總結(jié)

以上是生活随笔為你收集整理的了解PRACK的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。