　　隨著基于SIP協(xié)議應(yīng)用場(chǎng)景的增加，目前企業(yè)融合通信和語(yǔ)音呼叫中幾乎絕大部分的場(chǎng)景中都使用了SIP協(xié)議。但是，和傳統(tǒng)的PSTN相比，因?yàn)橐恍┢渌蛩氐挠绊�，很多人�?duì)于基于SIP協(xié)議所提供的終端，接入設(shè)備和軟交換仍然缺乏信心。客戶(hù)可能仍然對(duì)SIP呼叫中出現(xiàn)的問(wèn)題有著非常大的擔(dān)心。這些擔(dān)心也是正常的。事實(shí)上，為了進(jìn)一步提升SIP呼叫的穩(wěn)定性，SIP協(xié)議本身針對(duì)傳輸響應(yīng)處理方面也做了一些拓展，使用這些拓展用來(lái)進(jìn)一步保證SIP協(xié)議傳輸響應(yīng)的穩(wěn)定性。另外，為了保證更新的網(wǎng)絡(luò)（IMS）正常工作以及和傳統(tǒng)PSTN的兼容性，在SIP拓展中，使用了100rel/PRACK的拓展功能，可選標(biāo)簽100rel是SIP響應(yīng)消息中一個(gè)比較常用的拓展功能，這個(gè)拓展是通過(guò)PRACK method來(lái)進(jìn)行定義的。關(guān)于100rel拓展的定義，SIP拓展協(xié)議專(zhuān)門(mén)針對(duì)其屬性做了規(guī)范說(shuō)明，此說(shuō)明在RFC3262中定義。今天，我們針對(duì)RFC3262結(jié)合相關(guān)SIP拓展的相關(guān)技術(shù)話(huà)題做一個(gè)完整概述，并且針對(duì)實(shí)際業(yè)務(wù)場(chǎng)景中的一些問(wèn)題進(jìn)行討論，希望對(duì)讀者有所幫助。

　　1、背景介紹

　　如果熟悉SIP響應(yīng)的讀者都一定知道，請(qǐng)求和響應(yīng)是信令協(xié)商的基本手段。在RFC3261中規(guī)定了響應(yīng)的定義，響應(yīng)主要分為最終響應(yīng)和臨時(shí)響應(yīng)。根據(jù)其概念名稱(chēng)，讀者也大致理解了最終響應(yīng)和臨時(shí)響應(yīng)的基本含義。簡(jiǎn)單來(lái)說(shuō)，最終響應(yīng)是可靠的，而臨時(shí)響應(yīng)是臨時(shí)的，不可靠的響應(yīng)。根據(jù)RFC3261-7.2的說(shuō)明，其定義是：

　　1xx: Provisional -- request received, continuing to process the request;

　　https://tools.ietf.org/html/rfc3261#section-7.2

　　在針對(duì)臨時(shí)響應(yīng)的定義中，讀者可以非常明確地知道，對(duì)端已經(jīng)收到請(qǐng)求，對(duì)端正在處理其請(qǐng)求。以下示例說(shuō)明了啟用PRACK的和使用最終響應(yīng)處理的呼叫：

　　在當(dāng)前的呼叫環(huán)境中，包括現(xiàn)代的IMS網(wǎng)絡(luò)中，呼叫需要經(jīng)過(guò)多個(gè)網(wǎng)絡(luò)環(huán)境和處理路徑，需要更多的協(xié)商和資源支持。因此，在實(shí)際呼叫流程中可能發(fā)生更多的問(wèn)題，對(duì)端需要耗費(fèi)一定的時(shí)間來(lái)處理請(qǐng)求，具體需要處理的內(nèi)容很多，包括：編碼協(xié)商，對(duì)端服務(wù)器資源不足，會(huì)話(huà)時(shí)間太長(zhǎng)，編碼能力匹配問(wèn)題，QoS，承載服務(wù)，和PSTN接續(xù)時(shí)間太長(zhǎng)都會(huì)導(dǎo)致響應(yīng)丟失的問(wèn)題。因此，為了保證對(duì)端有充足的時(shí)間處理請(qǐng)求，UAS先返回一個(gè)臨時(shí)響應(yīng)通知對(duì)端本地正在處理這個(gè)請(qǐng)求，現(xiàn)在僅發(fā)一個(gè)臨時(shí)性的響應(yīng)。

　　2、UAS工作方式說(shuō)明

　　根據(jù)RFC3262的說(shuō)明，只要初始的請(qǐng)求包含了一個(gè)Supported，它的可選項(xiàng)是100rel，UAS可以對(duì)INVITE發(fā)送任何非100的響應(yīng)。這里的初始請(qǐng)求的響應(yīng)是一個(gè)臨時(shí)的可靠性響應(yīng)。此規(guī)范除了支持INVITE以外，不支持其他的可靠性臨時(shí)響應(yīng)的method。如果初始請(qǐng)求包含了Require頭域，其包含了100rel可選項(xiàng)的話(huà)，UAS必須發(fā)送一個(gè)非100臨時(shí)可靠響應(yīng)。如果UAS不愿意那樣處理的話(huà)，它必須拒絕此初始請(qǐng)求，返回一個(gè)420響應(yīng)（Bad Extension），并且在響應(yīng)消息中包含一個(gè)Unsupported 頭域，可選項(xiàng)是100rel。具體示例，參考后續(xù)介紹。

　　根據(jù)RFC3262說(shuō)明，UAS一定不能通過(guò)100（Trying）發(fā)送可靠的響應(yīng)。UAS只能通過(guò)101到109中間的響應(yīng)碼發(fā)送臨時(shí)可靠響應(yīng)。如果請(qǐng)求中既不包含Supported 頭域也不包含Require頭來(lái)表示臨時(shí)可靠響應(yīng)功能的話(huà)，UAS一定不能發(fā)送臨時(shí)可靠響應(yīng)。

　　100（Trying）響應(yīng)只能支持hop-by-hop之間的響應(yīng)。因?yàn)榇嗽颍@里討論的可靠性機(jī)制是介于end-to-end的響應(yīng)，因此不能使用100（Trying）。這里，關(guān)于end-to-end 和hop-by-hop的使用方式，讀者一定要小心理解，因?yàn)楦鞣Nmethod涉及了代理之間的通信和用戶(hù)身份安全的問(wèn)題。例如，BYE method是end-to-end之間的處理，而CANCEL是hop-by-hop的請(qǐng)求處理。

　　在一些場(chǎng)景中，一個(gè)網(wǎng)絡(luò)要素可以當(dāng)作proxy來(lái)使用，此proxy也可以可靠臨時(shí)響應(yīng)。其工作方式類(lèi)似于一個(gè)UAS，它的作用就是作為一個(gè)事務(wù)功能。但是，它不能?chē)L試發(fā)送攜帶To頭標(biāo)簽的請(qǐng)求。這里，一個(gè)proxy不能對(duì)已經(jīng)在一個(gè)dialog內(nèi)容中發(fā)送過(guò)的請(qǐng)求生成可靠臨時(shí)響應(yīng)。簡(jiǎn)單來(lái)說(shuō)，就是已在一個(gè)dialog中發(fā)送過(guò)請(qǐng)求內(nèi)容的，就不能對(duì)其請(qǐng)求生成臨時(shí)可靠響應(yīng)。當(dāng)然，不像UAS一樣，當(dāng)proxy的一個(gè)網(wǎng)絡(luò)要素收到一個(gè)PRACK時(shí)，這個(gè)PRACK不能匹配任何未處理的可靠臨時(shí)響應(yīng)，此PRACK必須經(jīng)過(guò)代理格式化處理。

　　很多讀者可能有疑問(wèn)，為什么UAS可能會(huì)發(fā)送可靠臨時(shí)響應(yīng)？我們?cè)诖宋恼轮幸灿懻摿岁P(guān)于響應(yīng)之前的準(zhǔn)備工作的問(wèn)題，讀者可參考。這里，其中的一個(gè)原因就是，如果INVITE事務(wù)需要耗費(fèi)一定的時(shí)間生成最終響應(yīng)，UAS響應(yīng)經(jīng)過(guò)一定的流程來(lái)做出最終響應(yīng)，為了保證有足夠的時(shí)間來(lái)回復(fù)最終響應(yīng)，并且能夠保持事務(wù)的正常狀態(tài)，因此，在回復(fù)最終響應(yīng)前，需要一個(gè)周期性的臨時(shí)響應(yīng)消息返回到請(qǐng)求對(duì)象端。因此，拓展功能100rel是一個(gè)必要的選擇，也是規(guī)范推薦的使用方式。

　　在UAS的核心構(gòu)件中，針對(duì)UAS的臨時(shí)可靠響應(yīng)處理流程是根據(jù)RFC3261的8.2.6章節(jié)處理。讀者可查閱讀者歷史文章了解處理流程。除了遵守其處理流程以外，臨時(shí)可靠響應(yīng)必須包含一個(gè)Require 頭，支持100rel可選項(xiàng)和一個(gè)RSeq頭域。在事務(wù)中的第一次可靠臨時(shí)響應(yīng)中的這個(gè)RSeq頭的取值必須介于1到2**31-1之間。此規(guī)范推薦此值取值范圍一律在此范圍之內(nèi)。不同請(qǐng)求的臨時(shí)響應(yīng)可以使用同樣的RSeq數(shù)值。

　　響應(yīng)管理也需要定時(shí)器來(lái)處理。在規(guī)范說(shuō)明中，可靠臨時(shí)響應(yīng)會(huì)周期性的定期傳輸?shù)绞聞?wù)層。通過(guò)T1定時(shí)器來(lái)實(shí)現(xiàn)定時(shí)傳輸，如果重新傳輸?shù)脑?huà)，則對(duì)T1定時(shí)器翻倍設(shè)置。關(guān)于T1定時(shí)器的規(guī)范說(shuō)明，讀者可以參考RFC3261的17章節(jié)。一旦可靠臨時(shí)響應(yīng)被傳輸?shù)搅朔⻊?wù)器的事務(wù)層后，可靠臨時(shí)響應(yīng)就會(huì)被添加到一個(gè)內(nèi)部未確認(rèn)的可靠臨時(shí)響應(yīng)列表中，等待處理。事務(wù)層會(huì)把重傳的響應(yīng)數(shù)據(jù)發(fā)送到UAS core中。

　　當(dāng)UA core收到一個(gè)匹配的PRACK后，可靠臨時(shí)響應(yīng)的重傳就退出處理機(jī)制。收到PRACK后，UAS對(duì)對(duì)PRACK進(jìn)行處理，處理流程和其他的method一樣。關(guān)于PRACK的處理，讀者可查閱RFC3261的第八章節(jié)和第十二章節(jié)。

　　在RFC3262中，匹配PRACK是這樣定義的。在同一dialog中，響應(yīng)和其請(qǐng)求的所攜帶的參數(shù)匹配。具體包括，響應(yīng)中RAck頭中的method，CSeq-num和response-num需要匹配請(qǐng)求中的CSeq，RSeq的臨時(shí)響應(yīng)消息。

　　如果UA core收到的PRACK請(qǐng)求，這個(gè)請(qǐng)求不能匹配列表中任何一個(gè)的未確認(rèn)可靠臨時(shí)響應(yīng)數(shù)值。UAS必須回復(fù)一個(gè)PRACK，返回481錯(cuò)誤響應(yīng)碼。如果這個(gè)PRACK請(qǐng)求不能匹配任何未確認(rèn)可靠臨時(shí)響應(yīng)，對(duì)端必須對(duì)它返回一個(gè)2xx響應(yīng)。這里，UAS可以確認(rèn)，已經(jīng)收到臨時(shí)響應(yīng)，這些響應(yīng)正在被按序處理。PRACK應(yīng)該退出可靠臨時(shí)響應(yīng)的重傳流程，并且必須從未確認(rèn)的可靠臨時(shí)響應(yīng)列表中移除。

　　如果在一定時(shí)間內(nèi)沒(méi)有收到重傳響應(yīng)怎么辦呢？在RFC3262中說(shuō)明，如果在64×T1秒內(nèi)，重新傳輸?shù)目煽颗R時(shí)響應(yīng)沒(méi)有收到相應(yīng)的PRACK反饋，UAS必須拒絕此初始請(qǐng)求，并且返回一個(gè)5xx響應(yīng)消息。

　　對(duì)于發(fā)送可靠臨時(shí)響應(yīng)的方式，本規(guī)范也做了進(jìn)一步的說(shuō)明。在第一個(gè)可靠臨時(shí)響應(yīng)被確認(rèn)接收以后，UAS可以發(fā)送其他的可靠臨時(shí)響應(yīng)。這里一定要注意，直到第一個(gè)可靠臨時(shí)響應(yīng)確認(rèn)以后，UAS才能發(fā)送第二個(gè)可靠臨時(shí)響應(yīng)。本規(guī)范推薦前一個(gè)可靠臨時(shí)響應(yīng)沒(méi)有被確認(rèn)之前，一定不能發(fā)送接下來(lái)的可靠臨時(shí)響應(yīng)。如果第一個(gè)可靠臨時(shí)響應(yīng)還沒(méi)有被確認(rèn)，緊接著發(fā)送后續(xù)的可靠臨時(shí)響應(yīng)的話(huà)，UAS不能確認(rèn)這些可靠臨時(shí)響應(yīng)的接收順序。

　　對(duì)于同樣一個(gè)請(qǐng)求，在后續(xù)的可靠臨時(shí)響應(yīng)中的RSeq值必須是大于1。簡(jiǎn)單來(lái)說(shuō)，就是后一個(gè)可靠臨時(shí)響應(yīng)比前一個(gè)大1。

　　對(duì)于UAS來(lái)說(shuō)，其實(shí)，在發(fā)送臨時(shí)響應(yīng)過(guò)程中可能也存在一些特別的情況，例如何時(shí)發(fā)送最終響應(yīng)。規(guī)范中有明確的說(shuō)明，除非最終響應(yīng)是2xx，并且未確認(rèn)的可靠臨時(shí)響應(yīng)的其中一個(gè)響應(yīng)中包含了會(huì)話(huà)描述，否則，在收到所有對(duì)未確認(rèn)可靠臨時(shí)響應(yīng)的PRACK之前，UAS可以發(fā)送對(duì)初始請(qǐng)求發(fā)送一個(gè)最終響應(yīng)。那種情況下，在它們的臨時(shí)響應(yīng)完全被確認(rèn)之前，UAS一定不能發(fā)送最終響應(yīng)，需要等到那些臨時(shí)響應(yīng)被完全確認(rèn)以后才能發(fā)送最終響應(yīng)。如果可靠響應(yīng)仍然是未確認(rèn)狀態(tài)時(shí)，如果UAS不能發(fā)送最終響應(yīng)的話(huà)，UAS不應(yīng)該繼續(xù)重傳這些未確認(rèn)的可靠臨時(shí)響應(yīng)。這時(shí)，UAS必須準(zhǔn)備處理剩下的PRACK的響應(yīng)。對(duì)UAS來(lái)說(shuō)，它對(duì)請(qǐng)求發(fā)送了一個(gè)最終響應(yīng)以后，一定不能發(fā)送一個(gè)新的可靠臨時(shí)響應(yīng)。

　　3、UAC工作方式說(shuō)明

　　在上個(gè)章節(jié)我們討論了UAS使用100rel的工作方式�，F(xiàn)在，我們討論100rel在UAC端的工作方式。根據(jù)rfc3262的說(shuō)明，當(dāng)UAC創(chuàng)建一個(gè)新的請(qǐng)求時(shí)，它可以插入一個(gè)可靠臨時(shí)響應(yīng)。具體的做法是，在請(qǐng)求中添加一個(gè)頭域Require，攜帶100rel可選項(xiàng)標(biāo)簽。注意，這個(gè)Require頭和100rel可選標(biāo)簽只能出現(xiàn)在INVITE method中，不能出現(xiàn)在其他的method中。具體的頭域查看RFC3262的table1和table2，那兩個(gè)table中有完整介紹。

　　如果UAC不希望一直使用可靠臨時(shí)響應(yīng)的話(huà)，它僅表示支持臨時(shí)響應(yīng)，而且UAS又需要UAC發(fā)送一個(gè)可靠臨時(shí)響應(yīng)的話(huà)，UAC必須在請(qǐng)求中添加一個(gè)Supported 頭域，攜帶一個(gè)100rel可選標(biāo)簽。UAC應(yīng)該包括這個(gè)頭域在所有的INVITE中。

　　關(guān)于此處理方式具體的示例，讀者可查閱PJSIP中100rel的代碼說(shuō)明。

　　If the UAC wants to mandate 100rel support, it can specify PJSIP_INV_REQUIRE_100REL in the options argument when calling pjsip_inv_create_uac（）. In this case, PJSIP will add 100rel tag in the Require header of the outgoing INVITE request.

　　https://www.pjsip.org/pjsip/docs/html/group__PJSIP__100REL.htm

　　如果收到一個(gè)針對(duì)初始請(qǐng)求的臨時(shí)響應(yīng)，響應(yīng)中包含了一個(gè)Require頭和100rel可選標(biāo)簽項(xiàng)，這個(gè)響應(yīng)是一個(gè)可靠臨時(shí)響應(yīng)。如果這個(gè)響應(yīng)是100（Trying）的話(huà)，必須忽略它的可選標(biāo)簽，也不能使用下面的處理流程。
　　這里，我們開(kāi)始討論具體的處理流程。如果沒(méi)有創(chuàng)建dialog的話(huà)，臨時(shí)響應(yīng)一定要?jiǎng)?chuàng)建一個(gè)dialog。這里，假設(shè)傳輸可靠響應(yīng)，UAC必須創(chuàng)建一個(gè)新的PRACK請(qǐng)求。這個(gè)請(qǐng)求通過(guò)dialog關(guān)聯(lián)的臨時(shí)響應(yīng)被發(fā)送出去，PRACK可以包含一個(gè)自己的消息體，繼續(xù)其消息體是按照其格式來(lái)解析。

　　注意，在一個(gè)dialog中，處理重傳時(shí)，PRACK請(qǐng)求和其他的非INVITE請(qǐng)求一樣。具體來(lái)說(shuō)，當(dāng)收到一個(gè)臨時(shí)響應(yīng)重傳，并且這個(gè)重傳正在被確認(rèn)時(shí)，UAC不應(yīng)該重傳PRACK請(qǐng)求。提醒讀者，盡管UAC那樣做，但是也不會(huì)導(dǎo)致協(xié)議錯(cuò)誤。

　　一旦收到一個(gè)可靠臨時(shí)響應(yīng)，那個(gè)響應(yīng)重傳必須馬上丟棄。那么，我們?nèi)绾闻袛嗍且粋€(gè)重傳響應(yīng)呢？規(guī)范規(guī)定，當(dāng)響應(yīng)的dialog ID，CSeq和RSeq匹配了原始的響應(yīng)中的這些參數(shù)時(shí)，這個(gè)響應(yīng)就是重傳響應(yīng)。UAC中必須包含一個(gè)序列號(hào)，這個(gè)序列號(hào)可以表示針對(duì)初始請(qǐng)求所收到的最新的可靠臨時(shí)響應(yīng)。這個(gè)序列號(hào)必須一直包含在響應(yīng)中，直到收到針對(duì)初始請(qǐng)求的最終響應(yīng)。這個(gè)值必須是在初始請(qǐng)求的第一個(gè)可靠臨時(shí)響應(yīng)的RSeq中定義。

　　處理后續(xù)的可靠臨時(shí)響應(yīng)和初始請(qǐng)求處理的規(guī)則是一樣的。但是，還有一些不同，其原則是：可靠臨時(shí)需要保證其傳輸順序。因此，針對(duì)同樣的請(qǐng)求，如果UAC收到其他的可靠臨時(shí)響應(yīng)，而且它的RSeq值不大于序列號(hào)值的話(huà)，這個(gè)響應(yīng)一定不是在PRACK中被確認(rèn)的，并且UAC一定不要繼續(xù)處理這個(gè)響應(yīng)。使用這個(gè)響應(yīng)的部署環(huán)境可以丟棄這個(gè)響應(yīng)，或者對(duì)其做一個(gè)緩沖處理，用來(lái)支持可能丟失的響應(yīng)。

　　UAC可以在最終響應(yīng)以后確認(rèn)收到的可靠臨時(shí)響應(yīng)，也可以丟棄這些可靠臨時(shí)響應(yīng)。

　　4、Offer/Answer模式和PRACK的處理方式討論

　　Offer/Answer模式是SIP協(xié)議的一個(gè)非常重要的概念。在RFC3261中有具體的規(guī)范說(shuō)明。筆者也曾經(jīng)發(fā)布了很多關(guān)于這個(gè)概念的介紹，讀者可以查閱歷史文檔做進(jìn)一步的理解。同樣，在SIP的拓展協(xié)議中-PRACK也支持同樣的處理方式。接下來(lái)，我們具體討論一下如何在PRACK中使用Offer/Answer的模式。

　　如果在請(qǐng)求中提供了一個(gè)offer，UAC可以在可靠臨時(shí)響應(yīng)中生成一個(gè)answer（這里假設(shè)，UAC支持它們）。這樣的話(huà)，它們之間就會(huì)創(chuàng)建一個(gè)會(huì)話(huà)。同樣的道理，如果一個(gè)可靠臨時(shí)響應(yīng)是第一個(gè)可靠消息，這個(gè)消息返回到UAC，并且此INVITE沒(méi)有包含一個(gè)offer的話(huà)，必須在那個(gè)可靠臨時(shí)響應(yīng)中添加一個(gè)offer。

　　這里，我們討論關(guān)于UAC收到offer或者answer的處理方式。如果UAC收到了一個(gè)可靠臨時(shí)響應(yīng)，攜帶一個(gè)offer，它必須在PRACK中生成一個(gè)answer。如果UAC收到一個(gè)可靠臨時(shí)響應(yīng)，攜帶一個(gè)answer，它可以在PRACK中生成其他offer。如果UAS收到一個(gè)PRACK，攜帶了一個(gè)offer，UAS必須對(duì)此PRACK在2xx中包含一個(gè)answer。

　　一旦answer被發(fā)送或接收，即使原始INVITE自己本身還沒(méi)有收到回復(fù)，UA應(yīng)該創(chuàng)建基于offer/answer的參數(shù)來(lái)會(huì)話(huà)。

　　當(dāng)INVITE被接受時(shí)，如果UAS已經(jīng)在可靠臨時(shí)響應(yīng)中包含了會(huì)話(huà)描述，這個(gè)可靠臨時(shí)響應(yīng)未被確認(rèn)，UAS必須推遲發(fā)送2xx，一直到這個(gè)臨時(shí)需要被確認(rèn)。否則，1xx的可靠性不能被保證，并且可靠性操作需要offer/answer交互的適當(dāng)操作才能完成。

　　規(guī)范明確說(shuō)明，所有支持此SIP拓展可靠性響應(yīng)協(xié)議的代理必須支持offer/answer交互模式，此模式工作方式是基于rfc3261中13章節(jié)的規(guī)則來(lái)處理。基于目前INVITE和PRACK存在的請(qǐng)求，2xx和可靠性1xx作為非失敗可靠響應(yīng)。

　　在rfc3262中定義了PRACK，具體語(yǔ)法，讀者可以參考rfc3262的tabel 1，table 2和RFC3261中的table3。

　　在本規(guī)范中定義了兩個(gè)新的頭域，包括RAck和RSeq。在臨時(shí)響應(yīng)中，RSeq是用來(lái)支持參數(shù)的可靠性。RAck頭是通過(guò)PRACK請(qǐng)求定義的，用來(lái)支持臨時(shí)響應(yīng)的可靠性。RAck包含兩個(gè)號(hào)碼和一個(gè)method標(biāo)簽。第一個(gè)號(hào)碼數(shù)值是被確認(rèn)的臨時(shí)響應(yīng)中的RSeq頭的值，第二個(gè)號(hào)碼值和method是從被確認(rèn)響應(yīng)中的CSeq中拷貝出來(lái)的數(shù)值和method。在RAck頭中的method名稱(chēng)是對(duì)大小寫(xiě)敏感的名稱(chēng)。例如：

　　RAck: 776656 1 INVITE

　　5、其他相關(guān)問(wèn)題討論

　　很多情況下，關(guān)于PRACK的請(qǐng)求處理涉及了很多具體的環(huán)境。筆者歸納了幾個(gè)檢測(cè)時(shí)容易出現(xiàn)的問(wèn)題進(jìn)行討論。

　　在某些環(huán)境下，我們經(jīng)�？赡苡龅浇K端或者服務(wù)器端是否支持PRACK請(qǐng)求的問(wèn)題。很多時(shí)候，我們可能需要及時(shí)調(diào)整設(shè)備或者服務(wù)器端的設(shè)置就可以解決問(wèn)題�，F(xiàn)在我們給讀者一個(gè)示例，讓讀者理解開(kāi)啟或者關(guān)閉PRACK的處理流程：

　　通過(guò)以上流程，結(jié)合我們前面討論的rfc3262，讀者可以非常清楚了解PRACK的處理過(guò)程。一些用戶(hù)仍然對(duì)100rel的協(xié)商非常迷惑，筆者這里耗費(fèi)一點(diǎn)時(shí)間專(zhuān)門(mén)針對(duì)具體的業(yè)務(wù)場(chǎng)景做一個(gè)簡(jiǎn)單總結(jié)。具體到實(shí)際的UAS/UAC環(huán)境中，100rel可選項(xiàng)的處理完全取決于哪一側(cè)的請(qǐng)求狀態(tài)和是否開(kāi)啟關(guān)閉（Supported/Require頭）。例如以下幾個(gè)不同場(chǎng)景最終協(xié)商的結(jié)果：

　　注意，這是一般的協(xié)商過(guò)程。在其他終端設(shè)備的處理可能有一些不同，這結(jié)果完全取決于接入網(wǎng)關(guān)和服務(wù)器端的兼容性設(shè)置。

　　有時(shí)，用戶(hù)可能在SIP消息中看到一個(gè)和PRACK相關(guān)的頭域-precondition。Precondition是另外一個(gè)比較大的討論話(huà)題，此頭值在RFC3312/RFC4031中做了非常詳細(xì)的定義，其中也包括了Precondition和Offer/Answer模式交互的關(guān)系，示例如下：

SIP/2.0 183 Session Progress
Max-Forwards: 70
Via: SIP/2.0/TCP [2001:0:0:2::1]:5060;branch=z9hG4bK932432170smg;transport=TCP
From: <sip:310410123456789@one.att.net>;tag=2763466811
To: <sip:0123456789;phone-context=one.att.net@one.att.net;user=phone>;tag=1111111111
Call-ID: 2270680280
CSeq: 1 INVITE
Contact: <sip:0123456789@[2001:0:0:2::2]:65094;transport=tcp>
Record-Route: <sip:[2001:0:0:2::2];lr>
Content-Type: application/sdp
Require: precondition // Indicate "precondition" is required
Require: 100rel // Indicate "PRACK" is Required
RSeq: 1
Content-Length: 763
Privacy: none

　　很多呼叫在3GPP和非3GPP網(wǎng)絡(luò)呼叫中，Preconditon協(xié)商中仍然有失敗的可能：

　　圖片來(lái)自于3GPP規(guī)范

　　當(dāng)前，我們的手機(jī)呼叫已經(jīng)在移動(dòng)網(wǎng)絡(luò)IMS中廣泛使用。手機(jī)呼叫的流程需要經(jīng)過(guò)更多節(jié)點(diǎn)的處理。在每個(gè)節(jié)點(diǎn)都需要耗費(fèi)一定的時(shí)間。其協(xié)商過(guò)程也非常復(fù)雜。為了為讀者提供一個(gè)比較全面的呼叫流程設(shè)置情況，讀者可以參考相對(duì)完整的示例來(lái)進(jìn)一步學(xué)習(xí)。以下是一個(gè)LTE網(wǎng)絡(luò)中手機(jī)呼叫的協(xié)商流程（包括了100 trying，183， 180的基本使用場(chǎng)景）：

　　圖片來(lái)自于：https://telecomtutorial.info/volte-call-flow/

　　因?yàn)槲恼缕年P(guān)系，筆者這里不再做過(guò)多介紹。讀者可以查閱以上圖片鏈接，針對(duì)LTE呼叫的流程做具體了解。當(dāng)然，在3GPP中，關(guān)于IMS中的SIP呼叫協(xié)商流程涉及了大概54個(gè)請(qǐng)求響應(yīng)消息內(nèi)容（如果沒(méi)有記錯(cuò)的話(huà)），這里不能一一介紹。

　　另外，在3GPP網(wǎng)絡(luò)中有針對(duì)UAS/AUC關(guān)于PRACK頭中的Supported和Require的一些調(diào)整，并且3GPP組織對(duì)其給出了一些建議（查閱3GPP T Release 6 37 R 29.962 V6.1.1或者更新版本）。用戶(hù)需要根據(jù)具體的網(wǎng)絡(luò)環(huán)境和3GPP的說(shuō)明做進(jìn)一步的了解。筆者沒(méi)有查閱中國(guó)的IMS網(wǎng)絡(luò)中關(guān)于和RFC3262的兼容性說(shuō)明，中國(guó)在3GPP網(wǎng)絡(luò)的規(guī)范也有一些調(diào)整。這些調(diào)整可能會(huì)影響實(shí)際SIP呼叫的使用，所以，讀者一定要注意。

　　如果我們把應(yīng)用場(chǎng)景縮小到一般的企業(yè)業(yè)務(wù)場(chǎng)景中，看看接入網(wǎng)關(guān)和服務(wù)器端的使用狀態(tài)。有時(shí)，一些網(wǎng)關(guān)產(chǎn)品和服務(wù)器端存在兼容性問(wèn)題。很多時(shí)候，可能是服務(wù)器端或者終端沒(méi)有開(kāi)啟PRACK選項(xiàng)支持。一些網(wǎng)關(guān)產(chǎn)品和服務(wù)器都可能包含三種設(shè)置方式：默認(rèn)關(guān)閉PRACK，Supported和Require PRACK。因此用戶(hù)可以檢查雙方關(guān)于PRACK的設(shè)置來(lái)解決這些問(wèn)題。當(dāng)然，如果出現(xiàn)了三種設(shè)置的話(huà)，事實(shí)上，根據(jù)雙方配置的平臺(tái)，經(jīng)過(guò)協(xié)商以后，終端和服務(wù)器端就會(huì)產(chǎn)生多種響應(yīng)結(jié)果。這完全取決于UAC和UAS的協(xié)商結(jié)果：

　　具體的呼叫跟蹤記錄示例，網(wǎng)關(guān)側(cè)成功的呼叫（183/200 ）：

16:32:35.762 CALL（SIP）（00:0004:00） SENT 183 Session Progress Reliable （100rel） to 10.129.45.102:8000 UDP
16:32:35.782 CALL（SIP）（00:0004:00） RCVD PRACK from 10.129.45.102:8000 Cseq:2 with Via sent-by: 10.129.45.102 UDP
16:32:35.782 CALL（SIP）（00:0004:00） SENT 200 OK PRACK to 10.129.45.102:8000 UDP

　　網(wǎng)關(guān)測(cè)失敗呼叫示例（420 錯(cuò)誤碼）：

21:16:47.845 CALL（SIP）（01:00004:00） SENT 421 Extension Required [PRACK support is required] to 10.129.45.104:5060 Cseq:1
21:18:09.286 CALL（SIP）（01:00005:00） SENT 420 Bad Extension [Unsupported SIP request arrived at L3UA-TUC] to 10.129.45.104:5060 Cseq:1

　　6、總結(jié)

　　筆者通過(guò)5個(gè)篇幅的內(nèi)容，具體介紹關(guān)于SIP拓展協(xié)議RFC3262和100rel拓展，PRACKmethod的使用協(xié)商方式。首先，我們介紹了臨時(shí)響應(yīng)的具體內(nèi)容，為什么使用臨時(shí)響應(yīng)，以及涉及的相關(guān)協(xié)議RFC3262。然后，我們介紹了如何在UAS和UAC端處理100rel/PRACK。當(dāng)然，UAS/UAC的協(xié)商過(guò)程是非常復(fù)雜的，很多細(xì)節(jié)需要讀者根據(jù)實(shí)際的配置才能決定。接下來(lái)，我們介紹了關(guān)于RFC3262中幾個(gè)主要的定義和Offer/Answer模式下的配合PRACK交互的流程。最后，我們針對(duì)一些在業(yè)務(wù)場(chǎng)景中具體的使用方式和終端/服務(wù)器端配置所產(chǎn)生的響應(yīng)做了比較詳細(xì)地分析。

　　另外，筆者這里提醒讀者，關(guān)于SIP拓展協(xié)議RFC3262的100rel處理涉及了3GPP中非常復(fù)雜的流程。在實(shí)際部署環(huán)境中還要配合運(yùn)營(yíng)商的網(wǎng)絡(luò)來(lái)調(diào)整終端和SIP服務(wù)器端的配置，包括具體的呼叫業(yè)務(wù)流程操作都可能出現(xiàn)問(wèn)題。筆者水平有限，這里僅是拋磚引玉，讀者仍然需要對(duì)照具體的規(guī)范來(lái)排查。

　　筆者再次提醒，如果讀者使用開(kāi)源的媒體服務(wù)器，例如Asterisk（建議使用PJSIP）或者FreeSWITCH，用戶(hù)一定要開(kāi)啟100rel的相關(guān)選項(xiàng)，包括Supported和Require選項(xiàng)。

　　參考資料：

　　https://tools.ietf.org/html/rfc3262

　　https://tools.ietf.org/html/rfc4032

　　https://www.ietf.org/rfc/rfc3312.txt

　　https://www.3gpp.org/technologies/keywords-acronyms/97-lte-advanced

　　https://telecomtutorial.info/volte-call-flow/

　　https://wiki.freepbx.org/

　　https://tools.ietf.org/html/rfc3960

　　https://github.com/alticelabs/asterisk-i/blob/master/p019_prack_support/asterisk-i-p019-prack-support.patch