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