1.SIP這玩意是怎么走來和如何構(gòu)建的？

通俗的說，SIP就是一個(gè)輕量級(jí)信令協(xié)議，它可以作為音頻、視頻、及時(shí)信息的信令。

說到SIP是怎么出來的就要提H.323，而提到這個(gè)標(biāo)準(zhǔn)由不得不提到ITU-T，我們就先說說指定SIP的IETF（Internet Engineering Task Force）和制定H.323的ITU-T（International Telecommunications Union–Telecommunications Standard Sector）之間一些小趣事吧。ITU-T和IETF想事兒總是不一樣的，它們倆往往從兩個(gè)不同的角度來進(jìn)行。ITU-T作為一個(gè)隸屬于美國(guó)的國(guó)際標(biāo)準(zhǔn)化組織，傳承了美國(guó)政策的一致性和試圖完成維護(hù)世界和平的角色，所以它制定出來的標(biāo)準(zhǔn)一定是經(jīng)過無數(shù)輪的反復(fù)和草案，花了N年制定出一個(gè)最終的，廣為接受的結(jié)果。而恰恰相反，IETF則更趨近于實(shí)用主義，信奉“rough consensus and running code”，也就是說能用進(jìn)行，邊用邊補(bǔ)充唄。因此在大多數(shù)時(shí)候，IETF標(biāo)準(zhǔn)制定的周期要比ITU-T短一些，這可能也歸因于IETF每年舉辦三次開放性論壇。這些春季、夏季、秋季會(huì)議會(huì)安排在世界各地，并且向各個(gè)對(duì)此感性趣的組織開放（去瞅一瞅吧：http://www.ietf.org/meetings/meetings.html）多個(gè)IETF工作組在這些會(huì)議上相聚，針對(duì)他們現(xiàn)在的系統(tǒng)開發(fā)敲定一些技術(shù)細(xì)節(jié)，對(duì)于要是到了會(huì)議結(jié)束時(shí)還是沒有解決的問題那就幾個(gè)月后的下次開會(huì)繼續(xù)研究唄。簡(jiǎn)而言之，IETF以一種實(shí)際實(shí)用的角度去完善體系架構(gòu)和協(xié)議設(shè)計(jì)。

說了這么多可能你還沒有意識(shí)到我在扯這些是為了什么，但是請(qǐng)記住這些正是SIP（Session Initiation Protocol）架構(gòu)所體現(xiàn)的核心思想——先用著，再擴(kuò)展。SIP的結(jié)構(gòu)是建立于兩個(gè)常用協(xié)議之上的：在RFC 2821中的SMTP 協(xié)議(Simple Mail Transfer Protocol )——它定義了電子郵件的消息格式，以及定義在RFC 2616的HTTP協(xié)議 (Hypertext Transfer Protocol )——它定義了基于Web的多媒體通信消息。另外，SIP又使用了定義在RFC 3550中的RTP/RTCP協(xié)議(Real Time Transport Protocol/Real Time Control Protocol )——它定義了在IP網(wǎng)上的多媒體包格式，還使用了定義在RFC 2327的SDP協(xié)議(Session Description Protocol )——它定義了一個(gè)多媒體會(huì)話的參數(shù)和特征。因此，SIP是建立在其他IETF提出的協(xié)議之上的，這有點(diǎn)像H.323建立在諸如H.225.0和H.245等ITU-T制定的協(xié)議之上，它的兩個(gè)比較基礎(chǔ)的RFC分別是版本1.0 RFC2543和版本2.0 RFC3261。當(dāng)然，SIP還運(yùn)行于其他IETF定義的傳輸協(xié)議之上，比如TCP(Transport Control Protocol ), UDP(User Datagram Protocol ) 和IP (Internet Protocol )等。這樣，這么多著名的，并且被廣泛應(yīng)用的協(xié)議為SIP提供了超于H.323的簡(jiǎn)單明了的特性。

在網(wǎng)上看到了這樣三個(gè)MindMap，覺得很能表達(dá)SIP的基本核心思想：

關(guān)于SIP的架構(gòu)，我們一定要知道這玩意不是什么新鮮玩意，你看看它基于什么就知道了，這么個(gè)拼出來的東東架構(gòu)能嶄新到什么地步呢？我的粗淺理解是SIP的主要架構(gòu)其實(shí)就是一個(gè)典型的C-S架構(gòu)：一個(gè)Client客戶端在RFC3261中定義為一個(gè)發(fā)送SIP請(qǐng)求并接收SIP回應(yīng)的網(wǎng)絡(luò)元素，這個(gè)Client可能與也可能不與人進(jìn)行交互。對(duì)應(yīng)的，一個(gè)Server服務(wù)器是接受SIP請(qǐng)求并且給予其回應(yīng)的網(wǎng)絡(luò)元素。比如最典型的是一個(gè)SIP請(qǐng)求INVITE，邀請(qǐng)一個(gè)用戶或者服務(wù)器參與會(huì)話，若得到的是肯定的響應(yīng)的話，那么則會(huì)返回響應(yīng)SUCCESS。要是再深入一點(diǎn)，我們可以將這樣一個(gè)簡(jiǎn)單的分類進(jìn)行細(xì)分：

???? Client分為兩類：

用戶代理客戶端User Agent Client?：它是一個(gè)邏輯功能，它創(chuàng)建請(qǐng)求、并且使用這個(gè)功能實(shí)體的一些具體功能發(fā)送出請(qǐng)求。

代理Proxy?：中文翻譯過來還是代理，但是這個(gè)與上邊的Agent不一樣，它是一個(gè)中間設(shè)備，既作為Client，也作為Server?，可以解釋、翻譯、改寫一個(gè)請(qǐng)求，并將請(qǐng)求轉(zhuǎn)發(fā)給其他的服務(wù)器，完成路由功能。有時(shí)候有狀態(tài)和無狀態(tài)Proxy，所謂有狀態(tài)就是Proxy根據(jù)不同的情形作出不同的處理，這些處理具有前后的相關(guān)性，比如三個(gè)人傳數(shù)字，A要通過B給C傳一個(gè)數(shù)字，一種情況是不管A說什么，B都說同一數(shù)字給C，這叫做無狀態(tài)Proxy；另一種狀態(tài)是A說1的話，B就傳給C數(shù)字2，要是A說2的話，B就傳給C數(shù)字3，這樣就是一個(gè)有狀態(tài)的Proxy。有些資料上有所為B2BUA，實(shí)質(zhì)與Proxy很相似，只不過更加靈活。

??? Server分類三類：

用戶代理服務(wù)器User Agent Server:?它是一個(gè)邏輯功能，它對(duì)一個(gè)請(qǐng)求產(chǎn)生應(yīng)答。

重定向服務(wù)器Redirect Server:?一個(gè)將客戶端的請(qǐng)求重定向去聯(lián)系另一個(gè)服務(wù)器以完成請(qǐng)求的服務(wù)器。

注冊(cè)服務(wù)器Registrar?：一個(gè)接受REGISTER 注冊(cè)請(qǐng)求，并將信息放置于位置服務(wù)器的服務(wù)器。

注意：我們?cè)跁铣３？吹降腢A是一個(gè)概括的說法，之所以區(qū)分UAS和UAC只是從邏輯上區(qū)分，實(shí)質(zhì)上不一定是獨(dú)立物理實(shí)體。

2.SIP該在哪，能干啥？

我們學(xué)習(xí)SIP就要知道它的地位，有個(gè)宏觀的了解才能知道N多協(xié)議之間的關(guān)系：

既然根據(jù)RFC 3261，SIP是基于STMP和HTTP的，并且底層使用了IP、UDP和TCP，那么它就是一個(gè)應(yīng)用層協(xié)議，也就是說，它能為End User提供服務(wù)，你能看得見摸得著。描述SIP應(yīng)用服務(wù)的單位是會(huì)話，也就是英文中Session一詞，意為在兩個(gè)或多個(gè)參與者之間有順序的交換信息，更深入一點(diǎn)，SIP必須先去扮演建立會(huì)話的角色，然后再在通信中管理會(huì)話。大家更關(guān)注的有三點(diǎn)：

a.多于兩個(gè)的參與者就意味著呼叫可能是多點(diǎn)的，而不僅僅是點(diǎn)對(duì)點(diǎn)的那樣子。

b.End User可能總不是從相同的地點(diǎn)發(fā)起呼叫的，我們需要添加追蹤這些End User的功能。

c.End User可能會(huì)使用文字、音頻、視頻等的混合媒體類型，這些在網(wǎng)路中對(duì)網(wǎng)絡(luò)的帶寬、最大傳輸延時(shí)等都有不同的要求和限制。SIP還需要對(duì)此進(jìn)行有效處理。

針對(duì)以上的Concerns，RFC 3261主要定義了五個(gè)方面的SIP多媒體會(huì)話管理能力：

· 用戶位置管理：決定哪一個(gè)端系統(tǒng)用于這次通信。

· 用戶可用性：決定被叫端是不是愿意參與這次通信。

· 用戶容量：決定用于這次通信的媒體以及其參數(shù)。

· 會(huì)話建立：在被叫和主叫兩端建立會(huì)話參數(shù)。

· 會(huì)話管理: 包含轉(zhuǎn)接和終止會(huì)話、修改會(huì)話參數(shù)、調(diào)用會(huì)話業(yè)務(wù)。

3. SIP依靠怎么運(yùn)作？

既然SIP是建立在SMTP和HTTP上的，那么其消息格式也有巨大的相似度，但是注意到一個(gè)SIP會(huì)話的資源是通信資源，而不是頁面或者網(wǎng)頁資源，這是與HTTP不同的地方。一個(gè)身份或者叫做一個(gè)尋址體制必須在請(qǐng)求/響應(yīng)集有效建立之前建立。身份標(biāo)識(shí)就是所謂的SIP URI（SIP Uniform Resource Indicator），其中包含了充足的信息來初始化一個(gè)會(huì)話。使用這個(gè)標(biāo)識(shí)的資源的例子（RFC 3261中提供的）有：有在線業(yè)務(wù)的用戶、在一個(gè)消息系統(tǒng)中的一個(gè)郵箱，在一個(gè)組織中的一組邏輯用戶（例如銷售部門），一個(gè)PSTN電話號(hào)碼等等。SIP URI與電子郵件地址類似，這也是借用了SMTP協(xié)議中的規(guī)定：典型的包含兩部分，第一部分為用戶名，第二部分為主機(jī)名，sip:huangpc@bupt.cn，?這是RFC 2543所介紹的最通常的格式。?當(dāng)然SIP URI還有其他的一些格式，比如在RFC 3261中引入的安全SIP URI：sips:huangpc@bupt.cn，?這個(gè)是在TCP上的TLS作為安全傳輸層的一種方式。

定義了用戶標(biāo)識(shí)后，我們就可以定義請(qǐng)求的標(biāo)識(shí)了——SIP中稱為方法（Method）。其他的擴(kuò)展方法在后續(xù)的RFC中都有定義。

· REGISTER: 用于與SIP服務(wù)器進(jìn)行注冊(cè)。

· INVITE: 用于表明用戶或者服務(wù)器被邀請(qǐng)參與這個(gè)會(huì)話。這個(gè)消息體中將包含一個(gè)對(duì)被叫端的會(huì)話描述。

· ACK: 僅用了INVITE請(qǐng)求，表明收到請(qǐng)求。

· CANCEL: 用于取消一個(gè)pending 的請(qǐng)求。

· BYE: User Agent Client用戶代理客戶端發(fā)送，來告訴服務(wù)器它希望結(jié)束通話。

· OPTIONS: 向服務(wù)器查詢它的能力。

定義完請(qǐng)求，很自然我們需要回應(yīng)的語言規(guī)范：包含狀態(tài)碼和描述性短語。分為六類：

· 1xx: 暫時(shí)性回應(yīng)，表明已經(jīng)接收到，正在處理之中。

· 2xx: 成功回應(yīng)，表明動(dòng)作已經(jīng)被接收，理解并且接受了。

· 3xx: 重定向回應(yīng)，需要進(jìn)一步的動(dòng)作來處理處理這個(gè)請(qǐng)求。

· 4xx: 客戶端錯(cuò)誤回應(yīng)，請(qǐng)求中語法不對(duì)，不能被服務(wù)器接受。

· 5xx: 服務(wù)器錯(cuò)誤回應(yīng)，服務(wù)器不能處理這個(gè)有效的請(qǐng)求。

· 6xx: 全局錯(cuò)誤回應(yīng)，這個(gè)請(qǐng)求不能被任何服務(wù)器接受。

你現(xiàn)在可能比較納悶，這都是些關(guān)于SIP會(huì)話建立和拆除的部分，但關(guān)于這個(gè)會(huì)話中要傳的文字、音視頻等的格式等雙方是怎么知道的呢？在INVITE中，就帶有了這些信息，這個(gè)信息的格式則又引出了另一個(gè)RFC，RFC 2327，會(huì)話描述協(xié)議（Session Description Protocol (SDP)）。

SIP和其他協(xié)議一樣都有這樣的一個(gè)要求：在會(huì)話開頭時(shí)兩端要有充分的信息交流。使用的兩個(gè)協(xié)議就是定義在RFC 2974中的SAP(Session Announcement Protocol )和定義在RFC 2327的SDP (Session Description Protocol)。簡(jiǎn)單來說，SAP提供了一種定期宣傳多媒體會(huì)話，向有意參與會(huì)話者傳遞相關(guān)會(huì)話信息的機(jī)制。使用它來支持Mbone（Internet Multicast Backbone），因此關(guān)興趣的各方都會(huì)清楚的指導(dǎo)目前正在進(jìn)行的一些會(huì)話。而SDP則定義了描述一個(gè)通信會(huì)話的格式，同樣的，它也可以用于不同的傳輸協(xié)議，比如SAP、SIP、HTTP或其他等傳輸協(xié)議。學(xué)習(xí)時(shí)要注意SDP的載體是SIP。RFC 2327專門注明了一些SDP能提供的比較關(guān)鍵的信息：

會(huì)話名和目的。

會(huì)話激活的時(shí)間。

構(gòu)成會(huì)話的媒體。

怎么樣接收這些媒體（地址、端口號(hào)、格式等）

而另一些信息則是可選附帶的，例如會(huì)議使用的帶寬，負(fù)責(zé)這個(gè)會(huì)話的那個(gè)人的聯(lián)系方式等等。

說到這些你可能覺得很抽象，我們趕緊那個(gè)例子RFC 2327中的例子來看看：

???? v=0?
???? o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4?
???? s=SDP Seminar?
???? i=A Seminar on the session description protocol?
???? u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps?
???? e=mjh@isi.edu (Mark Handley)?
???? c=IN IP4 224.2.17.12/127?
???? t=2873397496 2873404696?
???? a=recvonly?
???? m=audio 49170 RTP/AVP 0?
???? m=video 51372 RTP/AVP 31?
???? m=application 32416 udp wb?
???? a=orient:portrait

我們看到SDP格式包含多行文本，都是以 = 的格式書寫的，RFC中的星號(hào)*指的是選擇項(xiàng)。我們主要有三類的會(huì)話描述：會(huì)話描述、時(shí)間描述、媒體描述，具體你可以參看RFC 2327。注意這個(gè)例子中，兩個(gè)m開頭的行，定義了音視頻的概要，這些概要是在RFC 3550 Real Time Protocol (RTP)中的第13節(jié)和RFC 3551?RTP Profile for Audio and Video Conferences with Minimal Control?中的第6節(jié)，在編碼最后的那個(gè)0和31，這是在后續(xù)RTP幀中要使用的負(fù)載類型值，用來確定媒體和編碼類型。49170和51372都是接收者的端口，發(fā)送者端口分別加1，也就是說在這個(gè)例子中49171和51373是發(fā)送者的端口。

4.SIP到底怎么運(yùn)作？

一個(gè)最簡(jiǎn)單的例子是在SIP呼叫建立兩個(gè)直接相連的端對(duì)端的通話過程。發(fā)起者會(huì)發(fā)起一個(gè)INVITE消息給對(duì)端來發(fā)起會(huì)話，接著會(huì)收到Ringing和OK消息。被叫端返回ACK表明連接完成，可以進(jìn)行信息交流了。當(dāng)不需要這個(gè)連接時(shí)，任何一端發(fā)送BYE消息給對(duì)端，對(duì)端返回OK來終止呼叫。

注意，SIP消息和具體的媒體流并不是在一個(gè)層面運(yùn)作的。例如，一個(gè)VoIP電話是先通過SIP信令完成交互后再開始具體媒體流的傳輸?shù)?#xff0c;如下圖，SIP的根本作用的完成點(diǎn)對(duì)點(diǎn)（或多點(diǎn)）的媒體流傳輸?shù)那靶蚬ぷ鳌?/strong>