resiprocate及sdp協(xié)議詳細(xì)分析

1、1Resiprocate Resiprocate 介紹 介紹1. 1.前言 前言本文主要內(nèi)容來自互聯(lián)網(wǎng)，特此感謝 Steven 的辛苦撰寫和 resiprocate 開源組織的無私奉獻(xiàn)以及 sip 協(xié)議的創(chuàng)造者 Schulzrinne 教授和 Rosenberg 大師的辛勤工作。2．從 ．從 SIP SIP 談起 談起說明 說明:不期待一次就把 RFC3261 或者其他的協(xié)議文檔內(nèi)容及其細(xì)節(jié)全部記住或者完全理解;把原理性的東西及其脈絡(luò)厘

2、清也許更重要;在調(diào)試程序和看協(xié)議棧源碼的過程中我的做法是一直把 RFC3261(經(jīng)常的是那份中文文檔?的文檔打開;遇到忘記或者不是太明白的概念和內(nèi)容就在文檔中再搜索相關(guān)主題及內(nèi)容來看看;經(jīng)常會(huì)碰到這樣的問題,我發(fā)個(gè)內(nèi)容給 SIP Proxy 或者 SIP Server,可是并沒得到我希望的回復(fù)或者與期待的回復(fù)內(nèi)容有出入,這時(shí),我的經(jīng)常做法是再去研讀協(xié)議的相關(guān)定義,看看是不是我哪個(gè)細(xì)節(jié)并沒理解深入或者引起注意,導(dǎo)致我發(fā)出去的內(nèi)容與協(xié)議標(biāo)準(zhǔn)

3、有出入或者我的流程與協(xié)議定義不吻合。接下來的內(nèi)容是前人的文檔整理,只是個(gè)大概,如果沒興趣,完全可以跳過不看;協(xié)議棧部分基本上是分成 DUM 與 Stack 兩部份可以先后看，也可以先看 Stack 部分。補(bǔ)充說明：文檔中的大部分圖片都來自網(wǎng)上公開的資料，只有少數(shù)幾幅是自繪，因此出現(xiàn)內(nèi)容不清和誤導(dǎo)，概不負(fù)責(zé)? 特此感謝借鑒資料和圖片的原創(chuàng)者們，雖然他們并不知道又誤導(dǎo)了一個(gè)菜鳥。2.1 2.1 SIP SIP (Session (Sessi

4、on Initiation Initiation Protocol) Protocol) 簡介 簡介最先由美國哥倫比亞大學(xué)的 Henning Schulzrinne 教授在 1998 年初開始發(fā)起，1999 年 3 月由 IETF 的 MMUSIC(Multipart MultimediaSession Control)工作小組制定正式標(biāo)準(zhǔn)成為 RFC 2543， 1999 年 9 月 IETF 成立新的工作小組 ,負(fù)責(zé) SI

5、P 新版本 2.0 的制定 , 并于 2000 年 7 月釋出初版 RFC 2543bis，于 2001 年發(fā)布了 RFC 3261 。RFC 3261 的發(fā)布，標(biāo)示著 SIP 的基礎(chǔ)已經(jīng)確立，隨后又發(fā)布了幾個(gè) RFC 增定版本，充實(shí)了安全性及身份認(rèn)證等幾個(gè)領(lǐng)域的內(nèi)容，例如 RFC 3262 對(duì)臨時(shí)響應(yīng)做了可靠性的規(guī)范。RFC 3263 確立了 SIP proxy 的定位規(guī)則。RFC 3264 提供了 Offer/

6、Answer Model，RFC3265 則是確立了具體的事件通知。如同 Internet 一樣，SIP 易于理解、擴(kuò)充、及實(shí)做，作為IETF 的規(guī)范，SIP 將 Internet 開放標(biāo)準(zhǔn)的精神延伸至通訊領(lǐng)域，實(shí)現(xiàn)了不同計(jì)算機(jī)、電話、及軟件的通訊。SIP 的訊息類似于 HTTP (RFC 2068)，其尋址方式，則是重用了SMTP 的尋址方式，SIP address (如： sip:inaba@ssl.es.ncku.edu.

7、tw)與 E-mail address 的結(jié)構(gòu)相同，SIP 甚至利用 Web 的體系結(jié)構(gòu)，如 DNS，而使得 SIP 的使用者之3送 Request 到其它地方。? Redirect Server：負(fù)責(zé)接受 UA 或其它 proxy 所發(fā)送的 SIPRequest，并且傳回 redirection response (3xx)，指出這個(gè) Request 應(yīng)該送往何方。? Registrar Server：負(fù)責(zé)接受 SIP registr

8、ation requests，并且更新 SIP UA在 Location Server 或其它數(shù)據(jù)庫當(dāng)中的信息。SIP proxy, Redirect 還有 Registrar servers 只有做單純的 signal 轉(zhuǎn)送，他們沒有傳送 media 及產(chǎn)生 SIP Request 的能力。Proxy, Redirect,以及 Registrar server 只是邏輯概念定義的不同而物理實(shí)現(xiàn)上完全可以在同一物理位置實(shí)現(xiàn)。?

9、 Location Servers Servers：在 RFC 3261 中，通常當(dāng)作一個(gè)數(shù)據(jù)庫來使用。數(shù)據(jù)庫當(dāng)中可以存放使用者的信息，例如 URLs, IP address, 或是其它資料等等。SIPUA 不能直接來存取 Location server，而是透過 proxy, redirect,或是registrar server。2.4 2.4 SIP SIP message messageSIP message 的語意及表頭與 H

10、TTP/1.1(RFC 2616)相同?？梢苑殖蓛深?，一類是Request ，另外一類是 Response。在 RFC 3261 當(dāng)中，定義了六個(gè)基本的 SIP request 種類，如表 2.1 所示。方法 說明INVITE 建立會(huì)話 SessionACK 對(duì) INVITE 做最后的確認(rèn)BYE 結(jié)束一個(gè)已經(jīng)存在的會(huì)話CANCEL 取消尚未建立聯(lián)機(jī)的會(huì)話REGISTER 注冊(cè)使用者的 URLOPTIONS 查詢 Server 及其功能表

11、 2.1、SIP methodsResponse 用 status-codes 來表示響應(yīng)的內(nèi)容，符合且擴(kuò)展了 HTTP/1.1 response code。分成 Provisional(暫時(shí))及 Final(最終)兩類，Provisional 為 1xx 系列，F(xiàn)inal 則包括了 2xx，3xx，4xx，5xx，6xx 等系列，表 2.2 表示各個(gè)不同類別的 Response。方法 說明1xx Informational2xx S