1.SIP這玩意是怎么走來和如何構建的？

通俗的說，SIP就是一個輕量級信令協議，它可以作為音頻、視頻、及時信息的信令。

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

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

在網上看到了這樣三個MindMap，覺得很能表達SIP的基本核心思想：

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

???? Client分為兩類：

用戶代理客戶端User Agent Client?：它是一個邏輯功能，它創建請求、并且使用這個功能實體的一些具體功能發送出請求。

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

??? Server分類三類：

用戶代理服務器User Agent Server:?它是一個邏輯功能，它對一個請求產生應答。

重定向服務器Redirect Server:?一個將客戶端的請求重定向去聯系另一個服務器以完成請求的服務器。

注冊服務器Registrar?：一個接受REGISTER 注冊請求，并將信息放置于位置服務器的服務器。

注意：我們在書上常常看到的UA是一個概括的說法，之所以區分UAS和UAC只是從邏輯上區分，實質上不一定是獨立物理實體。

2.SIP該在哪，能干啥？

我們學習SIP就要知道它的地位，有個宏觀的了解才能知道N多協議之間的關系：

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

a.多于兩個的參與者就意味著呼叫可能是多點的，而不僅僅是點對點的那樣子。

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

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

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

· 用戶位置管理：決定哪一個端系統用于這次通信。

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

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

· 會話建立：在被叫和主叫兩端建立會話參數。

· 會話管理: 包含轉接和終止會話、修改會話參數、調用會話業務。

3. SIP依靠怎么運作？

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

定義了用戶標識后，我們就可以定義請求的標識了——SIP中稱為方法（Method）。其他的擴展方法在后續的RFC中都有定義。

· REGISTER: 用于與SIP服務器進行注冊。

· INVITE: 用于表明用戶或者服務器被邀請參與這個會話。這個消息體中將包含一個對被叫端的會話描述。

· ACK: 僅用了INVITE請求，表明收到請求。

· CANCEL: 用于取消一個pending 的請求。

· BYE: User Agent Client用戶代理客戶端發送，來告訴服務器它希望結束通話。

· OPTIONS: 向服務器查詢它的能力。

定義完請求，很自然我們需要回應的語言規范：包含狀態碼和描述性短語。分為六類：

· 1xx: 暫時性回應，表明已經接收到，正在處理之中。

· 2xx: 成功回應，表明動作已經被接收，理解并且接受了。

· 3xx: 重定向回應，需要進一步的動作來處理處理這個請求。

· 4xx: 客戶端錯誤回應，請求中語法不對，不能被服務器接受。

· 5xx: 服務器錯誤回應，服務器不能處理這個有效的請求。

· 6xx: 全局錯誤回應，這個請求不能被任何服務器接受。

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

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

會話名和目的。

會話激活的時間。

構成會話的媒體。

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

而另一些信息則是可選附帶的，例如會議使用的帶寬，負責這個會話的那個人的聯系方式等等。

說到這些你可能覺得很抽象，我們趕緊那個例子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中的星號*指的是選擇項。我們主要有三類的會話描述：會話描述、時間描述、媒體描述，具體你可以參看RFC 2327。注意這個例子中，兩個m開頭的行，定義了音視頻的概要，這些概要是在RFC 3550 Real Time Protocol (RTP)中的第13節和RFC 3551?RTP Profile for Audio and Video Conferences with Minimal Control?中的第6節，在編碼最后的那個0和31，這是在后續RTP幀中要使用的負載類型值，用來確定媒體和編碼類型。49170和51372都是接收者的端口，發送者端口分別加1，也就是說在這個例子中49171和51373是發送者的端口。

4.SIP到底怎么運作？

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

注意，SIP消息和具體的媒體流并不是在一個層面運作的。例如，一個VoIP電話是先通過SIP信令完成交互后再開始具體媒體流的傳輸的，如下圖，SIP的根本作用的完成點對點（或多點）的媒體流傳輸的前序工作。

在RFC 3261中描述了一個比較復雜的例子：使用了代理服務器作為通信通路。SIP代理服務器代表其他的Client發起請求，并且在許多時候作為路由模式，將SIP請求轉發給另一個距離最終目的地（也就是被叫端）較近的設備。因此，SIP代理服務器扮演著兩個角色——在接收請求時是server角色，在發送請求時是client角色。注意，代理服務器必須可以解釋一個SIP消息，并且需要的時候轉發這條消息前對其進行重寫，大的網絡中可能有多個代理服務器。在RFC3261中的第四節中有個比較有趣的例子，描述了兩個SIP終端通過兩個代理服務器建立呼叫的過程。在這個例子中，兩個終端位于兩個不同的城市：Atlanta and Biloxi，因此是在兩個相互隔離的網絡中。每個網絡有它自己的代理服務器，分別稱為atlanta.com?和?biloxi.com。?若在Atlanta的Alice想呼叫在Biloxi的Bob，那么Alice的電話就會發送以下的INVITE消息給它的代理服務器atlanta.com：

Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds?
Max-Forwards: 70?
To: Bob?
From: Alice ;tag=1928301774?
Call-ID: a84b4c76e66710@pc33.atlanta.com?
CSeq: 314159 INVITE?
Contact:?
Content-Type: application/sdp?
Content-Length: 142

當這個消息通過網絡轉到Bob后Bob要是愿意接受這個呼叫那么它就會返回一個OK，這個消息會先到biloxi.com?代理：

SIP/2.0 200 OK?
Via: SIP/2.0/UDP server10.biloxi.com?
??? ;branch=z9hG4bKnashds8;received=192.0.2.3?
Via: SIP/2.0/UDP bigbox3.site3.atlanta.com?
??? ;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2?
Via: SIP/2.0/UDP pc33.atlanta.com?
??? ;branch=z9hG4bK776asdhds ;received=192.0.2.1?
To: Bob ;tag=a6c85cf?
From: Alice ;tag=1928301774?
Call-ID: a84b4c76e66710@pc33.atlanta.com?
CSeq: 314159 INVITE?
Contact:?
Content-Type: application/sdp?
Content-Length: 131

我們注意到有相同的Call-ID來保證這個會話的單一性。更多的細節參看RFC 3261里的這個例子的具體解釋。

5.SIP中的信令和媒體之間的關系：

SIP等于為媒體的建立進行實現的溝通，打個比喻，只有你知道你要說話的那個人在那，并且兩個人都要找到彼此暢通的語言，這樣才能更有效的溝通。

而真正開始兩人滔滔不絕的傾心交談了，就與前邊這些對話前的相互了解和基本溝通沒有關系了。

6.幾個重要的概念：

呼叫（call）：?呼叫是一個非正式的術語，用來表示一個多媒體會話，用Call-ID來標識；不論兩方通話還是在多方通話中，在每個UA中是使用同一個Call-ID；

?

事務(transaction)：?請求（UAC）+最終響應（相鄰的UAS），SIP基于事務。所謂相鄰就是說transaction存在于相鄰的SIP實體，而不是存在于兩個UA之間。CSeq標識。一個事務中包含一個請求消息、0個或多個臨時響應消息、1個或多個最終響應消息（2xx~6xx）。SIP是事務性的協議。事務的區分通過Via字段棧頂的Branch的值來確定，這是由于對于請求消息每經過一個有事務狀態的Proxy的時候，該Proxy需要為這個事務創建一個服務器端事務和一個客戶端事務，并且將自己的URI添加到Via的棧頂，并生成一個Global ID做為Branch的值，以此值來表示一個與之相對應的事務。SIP在事務層面定義了狀態機和定時器來實現重傳。

下圖是一個回復200 OK的成功的INVITE事務：是不是INVITE事務區別在于?UAC需要為每個INVITE最終請求（2xx～6xx）生成ACK響應，而其他的請求消息（INFO,OPTION,etc）則不必如此。因為INVITE的地位比較重要， 所以需要這樣一個三次握手的機制來保證會話的雙方都能夠確保事務的完整性，這一點和TCP連接建立的三次握手比較像。

注意在上圖這兩個UA中，每一個代理服務器都將自己的地址加入返回的ACK的Via頭域中，而非成功的transaction則不會加入，見RFC 3261 (p.24)。CSeq頭域的值必須與INVITE相同，并且CSeq的方法必須是ACK。中間響應消息 1xx 的使用則是為了節省網絡開銷設計的，一旦 UC 收到任何一個中間響應消息，則 UC 必須停止消息重發定時器，不再從發這個請求消息，反之則直到收到最終響應消息或重發定時器超時。一旦客戶端UAC的事務在Calling狀態收到任何中間響應消息1xx，事務則自動切換到Processing狀態，停止請求消息的重發。并且需要將中間響應消息傳送給TU事務用戶。在呼叫業務中，TU以及上層應用可以根據中間響應消息在用戶界面上提示用戶。一旦事務切換到Processing狀態，任何其他中間響應消息也都要傳送給TU。

而非INVITE事務則如下：

當UAC發出非INVITE請求時，它就會在事務管理子層上開啟定時器F（TCP）或者是E（UDP），確保超時的時候進行重傳。這適用于除了 ACK請求外的其他非INVITE請求。每次超時重傳時E的時間都被翻倍，直到最大的4秒。而F超時時，UAC就會認為是Timeout，這個事務將被刪除。

對話(dialog/leg）：?代表著兩個SIP UA之間持續一段時間的端到端的聯系（如：一段通話）。也就說僅僅存在于端到端的信令關系。當一個UAS發出對于INVITE（或者REFER）的非失敗最終響應<=>200OK（BYE），則Dialog建立，同時這也是session的開始。UA和SIP代理服務器之間不會有對話。在SIP中呼叫中包含一個或多個Dialog（這僅僅存在于多方通話中）。Dialog終結于任意一端發出 BYE。Early Dialog可以通過UAC發出的CANCEL進行終結，更確切的說，所有早期對話在接收到非2XX最終響應時就被終結了。 Call-ID-value、To、From進行標識。Forking時體現明顯。

在這個Forking的例子中，這個用戶注冊了三個設備，在用戶被呼叫時，INVITE的Contact頭域就被轉換為三個INVITE發往三個設備。后邊的q指的是優先級，q越小，優先級越高。其中的SIP注冊服務器相當于一個Forking代理，盡管這個實體接收到兩個ACK，但是除了這些ACK外，它與主叫方的信令交互都是屬于一個transaction的，而與被叫方則分別建立了Transaction。另外，被叫方收到的兩個ACK由分別建立了Transaction。注意Device3返回了488這樣的非成功響應，SIP注冊服務器（Forking代理服務器）沒有將該響應發回主叫方，這是SIP代理一個重要的特征，SIP代理還能自行發出Request:CANCEL消息。

UAS對話層接收到一個新的對話請求INVITE消息后，在建立會話的響應消息2xx中，將請求消息里面的所有Route-Record字段拷貝到2xx消息中，并且UAS的對話層必須添加一個Contact字段使得對話中后續的響應（INVITE在2xx響應的情況下也包括ACK消息）、請求消息可以直接和本UA聯系。當UAC收到UAS的INVITE的2xx響應消息后，如果2xx中不包含任何Route-Record字段的，則UAC可以選擇直接發送ACK到Contact中地址&端口。

?

會話(session)：?多方用戶的媒體關系，在對話的控制下建立。

下圖是Early dialog、Session、Dialog、Transaction等的在一個UA-UA的呼叫中的體現：

在這個例子中，通過INVITE事務而成功建立起來的dialog必須有一個ACK進行回應，這是第二個transaction的開始，盡管ACK并沒有回復，但是由于新的 branch-value被填入，所以這個ACK代表了一個新的Transaction的開始。注意，此時?transaction number (CSeq)?并沒有根據INVITE而增加--也就是說若收到的最終響應不是2XX（是3XX--6XX），則該transaction中包含ACK，若最終響應是2XX，則ACK屬于一個新的transaction(此處存疑，國外有資料將其視為一個新的transaction，但是RFC3261中的意思卻是ACK不屬于INVITE Transaction，也不創建新的Transaction，但會重新計算Transaction參數--branchID)。早期對話是UAS以一個1XX響應作為回應時建立的。這樣做的好處是在UAC可能在早期對話中發出諸如UPDATE這樣的SIP請求。

7.在線狀態（Presence）

有人譯為“呈現”，個人覺得譯為在線狀態比較貼切，這是一種激動人心的SIP應用，它使您能夠確定用戶位置，并判斷是否能夠通過電話、電子郵件/文本或視頻與其進行通信。人員和應用都可以利用狀態信息，從而使企業有機會將通信整合到業務流程之中。IETF指定了許許多多的SIP擴展來支持在線狀態這個功能，我們列舉如下：

· RFC 2778: A Model for Presence and Instant Messaging

· RFC 2779: Instant Messaging/Presence Protocol Requirements

· RFC 3261 SIP: Session Initiation Protocol

· RFC 3856: A Presence Event Package for the Session Initiation Protocol

· RFC 3859: Common Profile for Presence

主要的組成有：

Presence Agent（PA）：PA為SIP使用者的代理人，能夠接收和處理Presence的消息。它也能夠回應和重新整理其它的消息（如公開的消息或SIP以外的任何消息）。當一個用戶改變其狀態時，它還能給訂閱者發送通知。其可以與 SIP proxy server放在一起實現，也可以作為一個獨立實體存在。

Presence User Agent (PUA) ：查詢更新PA。

8.全網看SIP

在非IMS網絡中，拓撲結構如下:

在這個結構中，有三個主要的部分：

公網與業務定制者節點：這是PSTN網絡以及在用戶層面的設備。

DMZ區域：對接外網的一些網絡元素，用于安全方面。

核心網：網絡消息處理的核心區域。

需要的注意是：

1.在核心網部分的媒體服務器有時候也可以扮演UA的角色，比如你定制語音留言這個業務，那么這個媒體服務器就負責播放提示音和錄音。網關在某個層面上也是扮演了UA的角色。

2.IP PBX是一種B2BUA，另外，SBC也是一種B2BUA，負責隱藏內網拓撲結構。應用服務器也是一種B2BUA，供修改業務參數等操作使用。

9.NAT問題

下圖所示SIP可能會出現的NAT問題：

目前商用的方法是使用Session Border Controller (SBC)，也就是說在應用層提供NAT服務，SBC監聽SIP請求，當得到一個請求時，它不僅檢查IP頭以便路由這個包，它也查看SIP消息內部的contract地址，并且在將其路由到下一跳之前將該地址改為一個可路由的地址，這個可路由的地址不一定是公網地址，只要下一個節點可以路由即可，如下圖所示：

轉自：http://www.cnblogs.com/gnuhpc/archive/2012/01/16/2323637.html

?

轉載于:https://www.cnblogs.com/liushui-sky/p/6709583.html

總結

以上是生活随笔為你收集整理的【SIP协议】学习初学笔记的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。