了解PRACK
概述
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
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
總結
- 上一篇： 国服6月23日上线！《暗黑破坏神：不朽》
- 下一篇： 一道解决的非常漂亮的算法题