筆者在前面的文章中已經(jīng)說明，opensips環(huán)境下的無狀態(tài)模式基本上沒有任何可支持的場景，一些用戶為了實(shí)現(xiàn)某個需求或者節(jié)省系統(tǒng)資源，提高處理能力，就使用了無狀態(tài)模式處理方式。但是，因?yàn)樗槐４媸聞?wù)狀態(tài)，所以不能對任何返回的響應(yīng)做處理。如果要進(jìn)行更多的SIP響應(yīng)處理，必須切換到有狀態(tài)模式進(jìn)行更多處理。
opensips學(xué)習(xí)筆記-關(guān)于stateless和stateful 模式討論和retransmissions演示
繼續(xù)接歷史文章的介紹，筆者這里通過使用無狀態(tài)的前轉(zhuǎn)函數(shù)來替換有狀態(tài)的轉(zhuǎn)發(fā)處理給大家演示為什么無狀態(tài)模式下沒有任何響應(yīng)處理。
在介紹無狀態(tài)跟蹤的示例之前，讀者首先需要了解幾個比較重要的功能和工具。
首先是“P-Hint“的工具使用，在opensips中，運(yùn)維人員可以使用“P-Hint”來對呼叫流程進(jìn)行跟蹤。可以在任何流程中打印自己的log來跟蹤呼叫。通過插入必要的定義log，可以判斷呼叫流程是否是按照自己的定義來進(jìn)行。
跟蹤完整的dialog流程
讀者需要了解無狀態(tài)模式和有狀態(tài)模式的使用的函數(shù)。這里，測試環(huán)境從前面測試的有狀態(tài)呼叫模式切換為一個無狀態(tài)的模式環(huán)境中。如果使用無狀態(tài)環(huán)境的話，用戶需要修改配置文件的設(shè)置。在route[relay]中使用forward（）替換t_relay（）。
route[relay] {
if （is_method（"INVITE"）） {
t_on_branch（"per_branch_ops"）;
t_on_reply（"handle_nat"）;
t_on_failure（"missed_call"）;
}
# t_relay（）;
forward（）; // 修改到了無狀態(tài)模式，直接前轉(zhuǎn)到目的地。
exit;
}
因?yàn)樾枰櫉o狀態(tài)的響應(yīng)消息傳來流程，所以需要在onreply_route[]打印輸出的跟蹤log：
onreply_route[handle_nat] {
append_hf（"P-hint: （3）reply through onreply_route[handle_nat]\r\n"）;
xlog（"incoming reply\n"）;
}
重新啟動openisps，重新注冊SIP賬號，sip 賬號呼叫另外一個SIP賬號，這里，基于無狀態(tài)模式的呼叫流程表面上和有狀態(tài)的模式的沒有什么不同。但是通過抓包工具可以看到，在onreply_route[]中沒有任何的 append_hf（）log。因?yàn)闊o狀態(tài)模式的呼叫沒有任何返回響應(yīng)。通過這樣的設(shè)置就可以確認(rèn)其無狀態(tài)模式的工作方式。
筆者今天討論的另外一個話題是關(guān)于opensips環(huán)境下關(guān)閉Record-Route的處理。Record-Route的概念和非常詳解筆者在歷史文檔從多個層面做過詳細(xì)說明，筆者可以參考以下文章，這里不再討論起概念。
- SIP系列講座-關(guān)于VIA和Record-Route header
- B2BUA/SBC/Proxy的SIP消息重構(gòu)和RFC7092詳解
- 會話邊界控制器（SBC）/SIP路由以及相關(guān)業(yè)務(wù)問題淺析
前面鏈接的幾篇文章非常詳細(xì)說明了其重要性。這里，為了快速了解一點(diǎn)Record-Route的用途，筆者簡單說明一下Record-Route的必要性：
- 需要處理網(wǎng)絡(luò)的地址轉(zhuǎn)換的處理業(yè)務(wù)（NAT，拓?fù)溥h(yuǎn)程，防火墻等）SBC業(yè)務(wù)的要求。
- 呼叫計(jì)費(fèi)CDR的作用
- 媒體處理的需要
- 管理和檢測dialog流程的必要
- 可能需要舉例呼叫鏈接的所有hops（有的hop也可以忽略）
今天，筆者通過opensips的示例來說明如何實(shí)現(xiàn)關(guān)閉Record-Route的處理。注意，在討論Record-Route關(guān)閉之前，讀者首先需要明確另外一個OpenSIPS中比較重要的一個變量概念-sequential requests（SR）。sequential requests（SR）是針對initinital request（SR）來說的。initinital request（SR）是一個比較乏的概念。簡單來說，initinital request，To header中沒有任何的tag參數(shù)。SR請求處理是基于每個record來進(jìn)行處理的。因?yàn)镾R是基于某個record處理的，相比IR處理，因?yàn)镾R不會重新經(jīng)過其他的路由邏輯，SR處理的速度更加快捷。
如果通過opensips開啟了Record-Route記錄的話，SIP呼叫會通過opensips返回另外一端。如果關(guān)閉了Record-Route的話，SIP的呼叫會通過contact頭直接呼叫到被呼叫方側(cè)終端。為了測試關(guān)閉Record-Route的示例場景，我們需要關(guān)閉Record-Route（）。
## record routing
if （!is_method（"REGISTER|MESSAGE"））
## record_route（）; 關(guān)閉Record-Route
if （!is_myself（"$rd"）） {
append_hf（"P-hint: outbound\r\n"）;
route（relay）;
}
重新啟動opensips，重新注冊SIP賬號進(jìn)行測試。通過呼叫流程的示例，抓包工具的檢查，讀者會發(fā)現(xiàn)關(guān)閉了Record-Route就看不到任何的BYE請求。當(dāng)然，此流程中也沒有可能看到其他的SR處理的消息。
筆者通過無狀態(tài)示例和關(guān)閉record_routing（）兩個示例和讀者分享了在opensips的呼叫流程中的一些細(xì)節(jié)處理。通過以上兩個示例可以看出，用戶在某些環(huán)境中如果為了滿足一個需求簡單修改cfg文件可以實(shí)現(xiàn)某個功能，但是失去了其他功能和業(yè)務(wù)流程的支持。opensips切換為無狀態(tài)模式，響應(yīng)處理沒有辦法做進(jìn)一步處理，包括其他的掛機(jī)狀態(tài)的處理。如果關(guān)閉record_routing，呼叫路徑上的終端就不會通過opensips或者其他代理進(jìn)行呼叫，當(dāng)然其他相關(guān)dialog，事務(wù)就發(fā)生了改變，CDR，BYE請求都都會失去完整的記錄。因此，讀者在實(shí)現(xiàn)某個功能時一定要首先滿足SIP協(xié)議規(guī)范的處理流程，然后考慮通過靈活的方式實(shí)現(xiàn)不同場景的要求。
參考資料：
https://opensips.org/html/docs/modules/1.8.x/tm.html
www.freesbc.cn
www.asterisk.org.cn
