關(guān)于兩大平臺(tái)的傳說很多。一些讀者也可能覺得奇怪，為什么要同時(shí)介紹兩個(gè)不同的平臺(tái)。事實(shí)上，從一開始，這兩個(gè)項(xiàng)目都是從這個(gè)歷史脈絡(luò)發(fā)展而來：SER->OpenSER->Kamailio/OpenSIPS�？梢赃@樣說，SER是可能很多通信技術(shù)人員開始學(xué)習(xí)SIP軟交換的第一個(gè)公開學(xué)習(xí)的平臺(tái)。從2001年，德國(guó)人Andrei 基于研究的目的寫了第一行SER（SIP Express Router）代碼開始，基本上奠定了德國(guó)人在開源SIP軟交換領(lǐng)域的老大地位，而且現(xiàn)在的Kamailio/OpenSIPS和OpenIMSCore 都和SER以前的開發(fā)人員有著非常緊密的關(guān)系。后來，一個(gè)如此強(qiáng)悍的團(tuán)隊(duì)因?yàn)榉N種原因分家，最后發(fā)展成目前的kamailio和OpenSIPS，還包括一個(gè)不冷不熱的OpenIMSCore。至于分家的各種小道消息，筆者也不會(huì)做過多討論，我們也不是人家團(tuán)隊(duì)的人員，不清楚真正的分家的原因，很多人的轉(zhuǎn)發(fā)可能都是誤讀。不過，從媒體公開的網(wǎng)絡(luò)媒體的解釋中，Kamailio 的創(chuàng)始人倒是解釋了很多，關(guān)于這方面的內(nèi)容讀者可以自己查找。我們不會(huì)關(guān)注太多八卦的東西，也不想蹭熱點(diǎn)。
1、在一般的SIP應(yīng)用場(chǎng)景中，我們可以看到很多關(guān)于SIP協(xié)議的功能支持描述，洋洋灑灑幾千字可能都說不清楚。其實(shí)，這些功能都可以通過一個(gè)抽象的介紹，簡(jiǎn)單概括為：
- 用戶定位：決定終端的地址，使用此地址進(jìn)行通信。關(guān)于定位服務(wù)器的規(guī)定，讀者可以參考RFC 3262。
- 用戶參數(shù)協(xié)商：決定媒體使用參數(shù)和參數(shù)使用方式
- 用戶的有效性：決定用戶的有效性和是否建立會(huì)話
- 呼叫創(chuàng)建：對(duì)呼叫方和被呼叫方創(chuàng)建呼叫參數(shù)，并且對(duì)雙方報(bào)告呼叫狀態(tài)。
- 呼叫管理：管理呼叫會(huì)話轉(zhuǎn)接等功能
2、SIP協(xié)議包括幾個(gè)核心的模塊，根據(jù)OpenSIPS或kamailio的介紹中，主要包括注冊(cè)服務(wù)器，Proxy服務(wù)器和定位服務(wù)器。例如圖例所示：
Kamailio的官方文檔對(duì)整個(gè)SIP服務(wù)器和相關(guān)應(yīng)用也給出了一個(gè)比較詳細(xì)的架構(gòu)圖：
為了配合我們的筆記重點(diǎn)，我們重點(diǎn)討論以上拓?fù)鋱D的紅色的標(biāo)注部分，可能有時(shí)會(huì)涉及CDR，RTP等一些技術(shù)討論。
由此，結(jié)合兩張圖例我們可以看出，關(guān)于開源軟交換的討論中，我們更多的討論仍然基于注冊(cè)服務(wù)器，代理和定位服務(wù)器，應(yīng)用服務(wù)器和重定位服務(wù)器的討論。關(guān)于以上幾種服務(wù)器的技術(shù)討論我們?cè)谝郧暗闹v座中有具體的介紹，讀者可以查閱歷史文檔來進(jìn)一步了解這些服務(wù)器的各自特點(diǎn)和具體的功能。
3、當(dāng)我們討論SIP的軟交換時(shí)，在具體的SIP注冊(cè)或其他的流程中，大家比較常見的名詞就是transactions和dialogs，它們不能用一個(gè)定義或一句話來準(zhǔn)確定義，而且有時(shí)場(chǎng)景發(fā)生變化也會(huì)變化。因此，這兩個(gè)名詞也是我們自己經(jīng)常會(huì)產(chǎn)生誤解或者比較模糊的地方，筆者自己也經(jīng)常會(huì)犯這方面的錯(cuò)誤。所以，我們認(rèn)為有必要和大家一起分享。transactions和dialogs這兩個(gè)名詞會(huì)一直在OpenSIPS或Kamailio服務(wù)器的配置語法中使用，所以我們必須首先了解它們二者之間的不同，才能恰當(dāng)?shù)厥褂靡恍┫嚓P(guān)的語法來處理SIP流程。
transactions和dialogs他們各自有很多不同的參數(shù)變量，如果錯(cuò)誤使用，可能導(dǎo)致我們無法對(duì)其進(jìn)行成功配置。
transactions是有用戶代理發(fā)起，在用戶端和服務(wù)器端之間進(jìn)行的多個(gè)流程所組成。從用戶端發(fā)起Request一直到final response（可能包括一些中間的響應(yīng)消息）。在響應(yīng)的消息中， 可以是以provisional 的響應(yīng)消息，例如180ring，或者final 響應(yīng)消息，200 OK。
如果transaction是由INVITE發(fā)起，回復(fù)的200 OK，中間沒有ACK那也是一個(gè)transaction。ACK本身有自己的transaction。以上圖例中就是兩個(gè)transaction發(fā)生。
所有UA transaction都具有自己的transaction, 客戶端有自己的transaction，服務(wù)器端則有自己的transaction。以下圖例說明了UAC到UAS中間結(jié)果2個(gè)proxy發(fā)生的transaction。注意，這里的Proxy是stateful proxy。如果是stateless proxy 則transaction僅僅發(fā)生于UA之間。
如果用戶正在處理一個(gè)INVITE transaction時(shí)，ACK不包含在起始transaction中。
經(jīng)過Stateless proxy時(shí)的transactions, 中間沒有任何transaction發(fā)生。
Dialog則表示在一定時(shí)間內(nèi)兩個(gè)UA的點(diǎn)對(duì)點(diǎn)關(guān)系。簡(jiǎn)單來說，Dialog也是transactions的總和。它的主要作用是處理兩個(gè)UA之間的消息，并且負(fù)責(zé)處理兩個(gè)UA之間的路由請(qǐng)求。SIP dailog 可以分為兩種類型：RTC dialog和Presence Dialog。RTC dialog是由一個(gè)INVITE transaction 發(fā)起，由BYE transaction結(jié)束。Presence dialog 則是有SUBSCRIBER transaction 帶一個(gè)超時(shí)頭值來設(shè)置。
每個(gè)Dialog都是由一個(gè)Dialog ID來定義。Dialog ID 則有一個(gè)CallID 頭域值，本地tag和遠(yuǎn)端tag來表示。
這里要注意，Dialog ID在每個(gè)UA都是不一樣的，大家要切記以下幾點(diǎn)：
- 對(duì)于UAC來說，Dialog ID中的Call-ID通過Call-ID 頭域值來設(shè)置，遠(yuǎn)端tag是設(shè)置在“To” 值域中，當(dāng)然，本地local tag則設(shè)置在“From” 中，這個(gè)規(guī)則適用于請(qǐng)求和響應(yīng)中。
- 對(duì)于UAS來說，Call-ID是保持一致，但是遠(yuǎn)端tag在“To” 值域中設(shè)置，local tag則在“To”中設(shè)置。
- 只有非失敗響應(yīng)才能創(chuàng)建dialog。簡(jiǎn)單來說，2xx 和101-199 的響應(yīng)帶一個(gè)tag，而且這個(gè)tag的請(qǐng)求是INVITE的時(shí)才能創(chuàng)建dialog。換句話說，只有當(dāng)所有成功的INVITE 發(fā)生以后，才能創(chuàng)建dialog。
- 一旦dialog創(chuàng)建以后，任何UA都可以在此dialog中創(chuàng)建一個(gè)新的transaction。如果UAC在已存在的dialog中發(fā)起了一個(gè)新的INVITE transaction，我們稱之為RE-INVITE。
- 在kamailio支持transaction和dialog模塊來實(shí)現(xiàn)對(duì)transaction和dialog的管理設(shè)置，它們分別是“TM”和“dialog” 模塊。在未來的筆記學(xué)習(xí)中我們會(huì)涉及相關(guān)的參數(shù)說明。注意，TM顧名思義就是Transaction management模塊只能支持stateful 模式，不能支持stateless模式。
4、大家知道，SIP協(xié)議本身就是一個(gè)雙方響應(yīng)，然后互相發(fā)送消息的協(xié)議。雙方通過不同級(jí)別的收發(fā)信息獲悉對(duì)方狀態(tài)。我們使用了很多關(guān)于request的內(nèi)容，這些request 消息對(duì)應(yīng)相應(yīng)的RFC標(biāo)準(zhǔn)，讀者可以查閱：
在上面和以前的講座中，我們都一般會(huì)用到final response 或者provisional 響應(yīng)消息等。在SIP協(xié)議中，定義了六個(gè)分類級(jí)別，它們都各自代表不同的含義。
- 1xx are provisional responses。
- 2xx responses are positive final responses。
- 3xx responses are used to redirect a caller。
- 4xx are negative final responses。
- 5xx means that the problem is on server's side。
- 6xx reply code means that the request cannot be fulfilled at any server。
以上六種分類可以分為：provisional responses 和final responses。101-199為provisonal responses, 200-699 則都?xì)w為final responses. final responses 則繼續(xù)分為positive response（200-299） 和negative response（300-699）。
以上六類響應(yīng)碼SIP相關(guān)組織有很多明確的解釋，讀者可以查閱，RFC6228和RFC3261， RFC8197等規(guī)定。
5、總結(jié)，我們主要介紹了kamailio和OpenSIPS的背景介紹，還介紹了主要的核心模塊和架構(gòu)，同時(shí)重點(diǎn)介紹了transaction和dialog的一些容易引起歧義的內(nèi)容，最后推薦讀者需要了解的一些請(qǐng)求響應(yīng)的代碼，這些代碼在后期學(xué)習(xí)中會(huì)經(jīng)常遇到，所以建議讀者花一點(diǎn)時(shí)間多了解這些代碼。在接下來的筆記中，我們會(huì)具體介紹幾個(gè)核心的模塊和主要功能，包括使用的安裝命令和參數(shù)。
參考資料：
https://tools.ietf.org/html/rfc6228#section-Abstract
https://tools.ietf.org/html/rfc8197#section-5.1
關(guān)注微信公眾號(hào)：asterisk-cn，獲得有價(jià)值的行業(yè)分享。訪問5060社區(qū)-開源IPPBX論壇獲得技術(shù)幫助：www.ippbx.org.cn/www.hiastar.com
