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