When stateful, a proxy is purely a SIP transaction processing engine.
Stateful 模式下，opensips會(huì )保持所有transaction 事務(wù)狀態(tài)的消息內容，所有消息會(huì )存儲在內存中。因此，當然，有狀態(tài)模式會(huì )消耗大量的系統資源。
RFC3261-16.2定義了關(guān)于Stateless Proxy的細節：讀者可以參考：SIP協(xié)議規范RFC3261中文分享-12
1state是什么意思？
根據前面的介紹，我們知道，其實(shí)這個(gè)state是針對transaction 來(lái)定義的。那么，transaction又是什么意思呢？關(guān)于transaction 建議讀者參考：
Kamailio/OpenSIPS學(xué)習筆記-SIP相關(guān)基礎
SIP講座系列-各種SIP服務(wù)器介紹
實(shí)際上，我們在前面的文章中已經(jīng)使用了opensips的transaction 模塊，包括
Kamailio/OpenSIPS學(xué)習筆記-如何測試SIP 408響應超時(shí)，調用了$T_fr_timeout等變量。opensips中的tm 模塊是一個(gè)非常重要的模塊，支持的配置功能也非常靈活，相對比較復雜。因為篇幅關(guān)系，這里不再做太多介紹。
實(shí)話(huà)說(shuō)，stateless 目前生產(chǎn)環(huán)境中沒(méi)有看到太多的應用場(chǎng)景。在某些環(huán)境可能被使用，例如，作為一個(gè)SBC，SIP發(fā)起方可能對SIP服務(wù)器端不斷發(fā)送option消息驗證其是否是存活狀態(tài)，OpenSIPS可以設置為一個(gè)stateless狀態(tài)，檢測到是option以后，然后丟棄。很多時(shí)候，如果用戶(hù)ping 運營(yíng)商的SBC的話(huà)，為了防止系統過(guò)載，SBC可能沒(méi)有返回任何消息。
Stateful 模式是SIP UAS或者proxy主要的應用場(chǎng)景。它可以支持SIP呼叫場(chǎng)景基本上所有必要的相關(guān)應用， 例如，處理重傳，失敗路由處理，定時(shí)器調整，NAT轉換處理，CDR/計費，CANCELs和ACKs消息的路由管理等。我們花費一點(diǎn)時(shí)間重點(diǎn)介紹在有狀態(tài)模式下的處理流程。
2OpenSIPS中stateless和stateful的兩種狀態(tài)
首先讀者一定要明確，默認環(huán)境下，opensips是以stateless 狀態(tài)啟動(dòng)的。在stateless模式下，opensips通過(guò)core 模塊提供SIP的信令功能，具體的函數包括forward（）和sl_send_reply（）。stateful模式的函數功能由transaction module提供，包括t_relay（）和t_reply（）。絕大部分的應用環(huán)境中，opensips是在有狀態(tài)的模式下工作的，但是，默認opensips啟動(dòng)時(shí)又是一個(gè)無(wú)狀態(tài)的模式，如果opensips需要從stateless切換到stateful 狀態(tài)的話(huà)，opensips需要通過(guò)調用事務(wù)模塊的函數從無(wú)狀態(tài)模式切換到有狀態(tài)模式。接下來(lái)，筆者介紹一下從無(wú)狀態(tài)模式切換到有狀態(tài)模式的兩種方式。
3啟動(dòng)stateful狀態(tài)的兩種方式
啟動(dòng)opensips的有狀態(tài)模式可以通過(guò)以下兩種方式。一種是手動(dòng)通過(guò)明確的外部調用函數-t_newtrans（）的方式來(lái)啟動(dòng)opensips的有狀態(tài)模式； 另外一種是自動(dòng)啟動(dòng)的方式，通過(guò)t_relay（）和t_reply（）函數來(lái)自動(dòng)啟動(dòng)有狀態(tài)模式。
這里，讀者需要注意，前一種方式是對請求創(chuàng )建了一個(gè)事務(wù)狀態(tài)，但是它執行的是無(wú)SIP信令處理；后一種方式是如果沒(méi)有創(chuàng )建有狀態(tài)模式事務(wù)的話(huà)，它們會(huì )自動(dòng)創(chuàng )建一個(gè)事務(wù)，并且執行SIP 信令操作。
4retransmissions測試示例
retransmissions是SIP網(wǎng)絡(luò )環(huán)境中經(jīng)常遇到的一個(gè)問(wèn)題。如果opensips要處理retransmissions的話(huà)，opensips需要在有狀態(tài)模式中進(jìn)行處理。retransmissions支持兩種retransmissions，一種是incoming 請求的檢測和重新傳輸； 入局的請求通過(guò)檢測可以再進(jìn)行處理，否則的話(huà)，重傳流程可能進(jìn)入到其他的cfg腳本中，或者查詢(xún)數據庫等流程，這樣就會(huì )耗費更多的系統資源。因此，opensips進(jìn)行重傳檢測是非常必要的，如果發(fā)現是一個(gè)重傳遞請求，則系統可能直接回復相關(guān)的響應即可。另外一種retransmissions基本上是針對被呼叫方來(lái)進(jìn)行的，opensips獲得被呼叫方的回復以后再進(jìn)行其他的業(yè)務(wù)流程處理。
為了演示如何使用t_new_tran（），這里，我們提供重傳的示例演示，呼叫入局時(shí)，如果檢測到一個(gè)不存在的地址以后，如何進(jìn)行重傳處理。具體的配置步驟如下：
首先，需要在cfg文件中加載-loadmodule "cfgutils.so" 模塊。
添加cfg腳本處理流程：
## requests for my domain
if （is_method（"PUBLISH|SUBSCRIBE"）） {
send_reply（503, "Service Unavailable"）;
exit;
}
if （$rU==NULL） {
# request with no Username in RURI
send_reply（484,"Address Incomplete"）;
exit;
}
#發(fā)送呼叫1002到地址 地址1.1.1.1
if （$rU=="1002"） {
#設置request uri是 1.1.1.1
$rd="1.1.1.1";
t_relay（）;
exit;
}
// 創(chuàng )建一個(gè)新的事務(wù)，切換到有狀態(tài)模式。
t_newtran（）;
#進(jìn)行呼叫，休眠2秒鐘。
if（is_method（"INVITE"）） {
sleep（2）;
}
以上腳本中，我們偽造了一個(gè)不存在的地址是1.1.1.1。使用一個(gè)SIP 終端呼叫另外一個(gè)終端1002的話(huà)，這里的目的地地址是一個(gè)不存在的地址，用戶(hù)可能感覺(jué)到呼叫流程相對比較慢，因為在呼叫中添加了一個(gè)休眠時(shí)間。
5總結
在本文章中，筆者討論了關(guān)于opensips中關(guān)于UAS的兩種狀態(tài)的具體使用方式和函數調用，以及價(jià)格應該注意到示例語(yǔ)法。首先，筆者介紹了stateless和stateful的基本區別，以及各自的應用場(chǎng)景，包括函數調用方式。接下來(lái)，筆者主要重點(diǎn)介紹了在無(wú)狀態(tài)啟動(dòng)的情況下，opensips如何切換為有狀態(tài)模式環(huán)境，以及兩種切換方式和各自的不同。最后，筆者通過(guò)retransmissions的應用場(chǎng)景介紹了如何使用 t_newtran（）實(shí)現opensips從無(wú)狀態(tài)模式切換到有狀態(tài)模式的示例，通過(guò)一個(gè)示例說(shuō)明opensips如何在有狀態(tài)環(huán)境中對入局呼叫進(jìn)行處理。
參考資料：
https://opensips.org/html/docs/modules/1.8.x/tm.html
www.freesbc.cn
www.asterisk.org.cn
