SIP ——瞭解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

轉自 http://blog.sina.com.cn/s/blog_4b839a1b010082xy.html

另外可以參考 http://wenku.baidu.com/view/5b291a620b1c59eef8c7b403.html