SIP協議詳解(中文)-1

1、SIP協議介紹
Internet的許多應用都需要建立和管理一個會話，會話在這裏的含義是在參與者之間的數據的交換。由於考慮到參與者的實際情況，這些應用的實現往往是很複雜的：參與者可能是在代理間移動，他們可能可以有多個名字，他們中間的通訊可能是基於不同的媒介（比如文本，多媒體，視頻，音頻等）－有時候是多種媒介一起交互。人們創造了無數種通訊協議應用於實時的多媒體會話數據比如聲音，影像，或者文本。本SIP（會話初始協議）和這些協議一樣，同樣允許使用Internet端點（用戶代理）來尋找參與者並且允許建立一個可共享的會話描述。爲了能夠定位精確的會話參與者，並且也爲了其他的目的，SIP允許創建基礎的network hosts（叫做代理服務器），並且允許終端用戶註冊上去，發出會話邀請，或者發出其他請求。SIP是一個輕形的，多用途的工具，可以用來創建，修改和終止會話，它獨立運作於通訊協議之下，並且不依賴建立的會話類型。

2、SIP協議功能概況
SIP是一個應用層的控制協議，可以用來建立、修改、和終止多媒體會話（或者會議）例如Internet 電話。SIP也可以邀請參與者參加已經存在的會話，比如多方會議。媒體可以在一個已經存在的會話中方便的增加（或者刪除）。SIP顯示的支持名字映射和重定向服務，這個用於支持個人移動業務－用戶可以使用一個唯一的外部標誌而不用關係他們的實際網絡地點。SIP在建立和維持終止多媒體會話協議上，支持5個方面：
用戶定位： 檢查終端用戶的位置，用於通訊。
用戶有效性：檢查用戶參與會話的意願程度。
用戶能力：檢查媒體和媒體的參數。
建立會話：”ringing”,建立會話參數在呼叫方和被叫方。
會話管理：包括髮送和終止會話，修改會話參數，激活服務等等。
   SIP不是一個垂直集成的通訊系統。SIP可能叫做是一個部件更合適，它可以用作其他IETF協議的一個部分，用來構造完整的多媒體架構。比如，這些架構將會包含實時數據傳輸協議（RTP）（RFC 1889）用來傳輸實時的數據並且提供QoS反饋，實時流協議（RSTP）(RFC 2326)用於控制流媒體的的傳輸，媒體網關控制協議（MEGACO）(RFC 3015)用來控制到公共電話交換網（PSTN）的網關，還有會話描述協議（SDP）（RFC 2327）用於描述多媒體會話。因此，SIP應該和其他的協議一起工作，才能提供完整的對終端用戶的服務。雖然基本的SIP協議的功能組件並不依賴於這些協議。

SIP本身並不提供服務。但是，SIP提供了一個基礎，可以用來實現不同的服務。比如，SIP可以定位用戶和傳輸一個封裝好的對象到對方的當前位置。並且如果我們利用這點來通過SDP傳輸會話的描述，立刻，對方的用戶代理可以得到這個會話的參數。如果我們用這個像傳輸會話描述（SESSION DESCRIPTION SD）一樣呼叫方的照片，一個”呼叫ID”服務很容易就建立了。這個簡單的例子說明了，SIP作爲一個基礎，可以在其上提供很多不同的服務。

SIP並不提供會議控制服務（比如議席控制或者投票系統），並且並沒有建議會議應該則那樣管理。可以通過在SIP上建立其他的會議控制協議來發起一個會議。由於SIP可以管理參與會議的各方的會話，所以會議可以跨異構的網絡，SIP 並不能，也不打算提供任何形式的網絡資源預留管理。


安全對於提供的服務來說特別重要。要達到理想的安全程度，SIP提供了一套安全服務，包括防止拒絕服務，認證服務（用戶到用戶，代理到用戶），完整性保證，加密和隱私服務。

SIP可以基於IPV4也可以基於IPV6

3、術語
在這個文檔中，關鍵詞”必須”,”不允許”,”要求”,”可以”,”不可以”,”應該”,”不應該”,”建議”,”不建議”,”可能”,”可選” 是根據BCP14,RFC 2119[2]的規範描述SIP實現需要的不同層次

4、實施概覽
這節通過簡單的示例介紹了SIP的基本實現。本節是通過自然的而非正則的示例來介紹的。

   第一個例子說明了SIP的基本功能：定位一個斷點，發出通訊請求，通過協商會話參數建立會話，拆卸剛纔建立的會話。
   圖一表示一個典型的Alice和Bob兩個用戶間的SIP消息交易交換例子.（每一個消息採用字母”F”和一個用來指向正文的一個數字做標記）在這個例子裏，Alice在她的PC上使用一個SIP的應用程序（比如說一個軟的電話），呼叫Bob在Internet上的一個SIP電話。這個例子也掩飾了兩個SIP代理之間，怎樣爲Alice和Bob建立會話連接。This typical arrangement is often referred to as the "SIP trapezoid" as shown by the geometric shape of the dotted lines in Figure 1.

Alice 通過Bob的SIP標誌 “呼叫” Bob，這個SIP標誌是統一分配的資源（Uniform Resource Identifier URI）稱作SIP URI。SIP URI在19.1節中定義。它很像一個email地址，典型的SIP URI包括一個用戶名和一個主機名。在這個範例中，SIP URI是sip:[email protected],biloxi.com是Bob的SIP服務提供商。Alice有一個SIP URI: sip:[email protected]。 Alice可以輸入Bob的URI，也可以直接在地址本的一個超級鏈接上點擊一下Bob的URI。SIP也提供保密URI，稱作SIPS URI。例如：sips: [email protected]。 一個基於SIPS URI的通話保證這個通話是安全的，並且對呼叫者和被叫的所有的SIP消息是加密傳輸的（叫做TLS）。在TLS中，請求是通過加密方式傳輸給被叫方，但是這個加密機制是基於被叫方宿主服務器的實現的。

SIP是基於一個類似HTTP協議的請求應答的通訊模式。每一個通訊都包含對某個功能的請求，並且起碼需要一個應答。在這個應答中，Alice的軟電話發送一個含有Bbo的SIP URI抵制的INVITE通訊請求。INVITE是一個SIP請求的例子，表示請求方（Alice）希望服務方（Bob）應答。INVTE請求包含一系列的包頭域（Header fields）。包頭中包含很多屬性並且包含了傳輸消息的附加信息。在INVITE中有如下的字段：呼叫的唯一標誌，目的抵制，Alice的地址，Alice和Bob建立會話的類型。INVITE請求（圖1中的F1）可能看起來像這樣的：

INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:[email protected]>
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: [email protected]
CSeq: 314159 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 142
(Alice’s SDP not shown)


atlanta.com . . . biloxi.com
.    proxy                 proxy        .
.                                         .
Alice’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . Bob’s
softphone                                             SIP Phone
|                    |                    |                    |
| INVITE F1            |                    |                    |
|--------------->            | INVITE F2            |                    |
| 100 Trying F3        |--------------->            | INVITE F4            |
|<---------------            | 100 Trying F5        |--------------->            |
|                    |<--------------            | 180 Ringing F6        |
|                    | 180 Ringing F7        |<---------------            |
| 180 Ringing F8        |<---------------            | 200 OK F9            |
|<---------------            | 200 OK F10        |<---------------            |
| 200 OK F11        |<---------------            |                    |
|<---------------            |                    |                    |
|                            ACK F12                        |
|                    ------------------------------------------------->        |
|                        Media Session                        |
|<================================================>    |
|                            BYE F13                        |
|                    <-------------------------------------------------        |
|                        200 OK F14                            |
|                    ------------------------------------------------->        |
|                                                            |
圖一：SIP矩形表達的SIP會話建立例子。

在文本消息的第一行，包含了請求的類型（INVITE）。在這行之後的是這個請求的頭域。這個例子中包含了最少需要的頭域集合。簡單介紹一下：

VIA域包含了Alice接收發送請求的服務器地址（pc33.atlanta.com）。同樣這個包含了一個分支參數來標誌Alice和這個服務器的會話事務。

TO域包含了顯示姓名（Bob）和一個SIP或者SIPS URI（sip：[email protected]）請求將首先傳輸到這個URI中。顯示姓名（Display names）在RFC 2822中描述。
From域也同樣包含一個顯示姓名（Alice）和一個SIP或者SIPS URI（sip:[email protected]）這個URI用來標誌請求的原始發起者。
這個域也包含了一個TAG參數，這個TAG參數是一個隨機字串（1928301774），是軟電話（softphone）在URI上增加的一個隨機串。用來做標誌用途的。
Call_ID包含一個全局的唯一標誌，用來唯一標誌這個呼叫，通過隨機字串和softphone的自己名字或者IP抵制混和產生的。通過TO TAG, FROM TAG和CALL-ID完整定義了Alice和Bob之間的端到端的SIP關係，並且表示這個是一個對話性質的關係。
CSEQ或者Command Sequence包含了一個整數和一個請求名字。這個Cseq數字是順序遞增的。每當對話中發起一個新的請求都會引起這個數字的順序遞增。
Contact域包含一個SIP或者SIPS URI用來表示訪問Alice的直接方式，通常由用戶名和一個主機的全名（Fully Qualified Domain Name FQDN）組成。當FQDN作爲首選的時候，許多終端用戶由於不會由名字登記（而導致不能訪問Alice的主機），所以IP地址是可選的。
VIA域告訴大家本請求發送到哪裏並且應答到哪裏，Contract域告訴大家將來的請求將發送到哪裏（奇怪…不是Alice發起的麼，將來的請求應該是Bob纔對啊）。
Max-Forwards:最大轉發數量限制了通訊中轉發的數量。它是由一個整數組成，每轉發一次，整數減一。
Content－type包含了消息正文的描述（消息正文在本範例中沒有列出）
Content-length:包含消息正文的長度（字節數）
完整的SIP包頭域的定義在20節。會話的細節，比如媒體的類型，codec，或者採樣速率，沒有通過SIP來描述。這個可以通過SIP的消息正文來描述，可以通過其他定義的協議在正文中進行描述。有一種是會話描述協議（Session Descripotion Protocol SDP）（RFC2327[1]）。這個SDP消息（沒有在例子中列出）通過SIP的消息中傳送，就像通過附件發送EMAIL一樣，或者說通過HTTP傳輸的網頁一樣。

由於softphone並不知道bob或者bob的sip服務器biloxi.com在哪裏，所以softphone發送INVITE請求到Alice的sip服務器,atlanta.com。這個atlanta.com SIP服務器應該已經在Alice的softphone中配置了，或者可以通過DHCP獲得。atlanta.com SIP服務器是一臺代理服務器。代理服務器接收SIP請求並且根據請求轉發。在這個例子中，代理服務器接收到INVITE請求，並且回送一個100（Trying）應答給Alice的softphone。100（Trying）應答表示INVITE請求已經收到，並且代理服務器正在轉發INVITE請求。SIP的應答是通過一個三位數的數字表示的。SIP應答同樣包含TO、FROM、Call-ID，CSEQ和在VIA中的分支參數，這個參數使得Alice的softphone可以把請求和應答關聯起來。atlanta.com代理服務器收到INVITE請求之後，就去找biloxi.com可能通過DNS服務來找提供這個biloxi.com的SIP服務器。這在[4]中有描述。最後，轉發INVITE請求到biloxi.com或者能到達biloxi.com的代理服務器。在轉發請求之前，atlanta.com代理服務器會在via頭上增加一個一段包含自己抵制的值（INVITE已經包含了Alice的的地址VIA域）。biloxi.com代理服務器收到這個INVITE請求並且返回一個100（Trying）應答給atlanta.com代理服務器標誌這它已經收到這個請求並且正在處理這個請求。這個代理服務器通過查詢數據庫，通常叫做地址服務，這個服務中包含了bob的當前ip地址。（我們在下一節可以看到這個數據庫是怎麼回事）biloxi.com代理服務增加另一段包含自己地址的VIA頭域並且發送它到bob的sip 電話。

Bob的SIP電話接收到INVITE請求並且提醒bob有一個從Alice的呼入，這樣bob可以決定是否響應這個呼入。這個意思就是：bob的電話響了。bob的sip電話發送一個180（Ringing）迴應，這個迴應將通過兩個代理服務器原路返回給Alice。每一個代理服務器通過via頭域決定該把這個應答發送給哪裏，並且在發送之前把自己的地址從頭上拿走。雖然DNS和定位服務在路由最初的INVITE請求，180（ringing）響應可以簡單返回給發起者而不需要查找發起者在哪裏，並且不需要在代理服務器保留狀態，同時，每一個轉發INVITE的代理也可以得到INVITE的每一個應答，這樣的特性也非常有用。

當Alice的softphone收到180（Ringing）應答的時候，它提示Alice,可能是通過一個回鈴音，或者屏幕上的一個消息提示。

在這個例子中，Bob決定響應這個呼叫。當他拿起電話，他的SIP電話發送200（OK）迴應給發送者，表示這個電話已經接起來了。這個200（OK）包含了一個消息體，這個消息體包含SDP媒體描述，這個媒體描述包含Bob希望和Alice建立何種媒體連接。同樣，SDP消息也是兩段交換：Alice發送一個給Bob，Bob發送一個回給Alice。這個兩段的交換提供基本的兼容性協商，並且基於簡單的SDP提出/應答交換模型。如果Bob不想響應這個呼叫或者正在響應別的呼叫，一個錯誤的響應會代替正常的200（OK）回送出去，這樣，就不會有連接建立。SIP完整的返回代碼在21節有介紹。Bob發出的200（OK）（圖一的F9消息）可能長得像這樣的：

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 <sip:[email protected]>;tag=a6c85cf
From: Alice <sip:[email protected]>;tag=1928301774
Call-ID: [email protected]
CSeq: 314159 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 131
(Bob’s SDP not shown)

應答的第一行包含了應答代碼（200）和原因（ok）。剩下的行包含了包頭域。VIA,TO,FROM,CALL-ID,Cseq包頭域是從INVITE請求包中直接拷貝過來的。（有三個VIA域值－一個是Alice SIP電話增加的，一個是atlanta.com代理加的，一個是biloxi.com代理加的）。Bob的SIP電話增加了一個TAG參數。這個TAG參數會被參與對話的各方所使用，並且在以後的對話中被使用。Contract域包含了一個能直接聯繫到Bob的URI。Content－type和Content_Length域包含了消息體（沒有在例子中體現），這個消息體裏邊是Bob的SDP媒體信息。

除了DNS和位置服務之外，代理服務器可以自主決定路由，也就是說自己決定應該向哪裏轉發請求。比如，如果Bob的SIP電話返回一個486（電話正忙）信號，biloxi.com這個代理服務器可以轉發這個INVITE請求到Bob的語音郵箱服務器。一個代理服務器可以同時向N個地方發送INVITE請求。這種併發尋找就是傳說中的分流（forking）。


在這個例子中，200（OK）應答通過兩個代理並且發送到Alice的softphone上，Alice的softphone收到這個應答，停止振鈴，並且標誌電話Bob已經接聽。最後，Alice的電話發送一個確認消息，ACK，到Bob的SIP電話來確認接收到了這個最後的200（o’k）應答。在這個例子中，ACK信號是直接由Alice的softphone發送到Bob的SIP phone上，跨過了兩個代理服務器。這是因爲兩個端點（Alice和Bob）通過INVITE/200(OK)的請求應答包中的Contact包頭域都知道互相之間的地址了，這個地址是最開始發起INVITE請求的時候所不知道的。所以，不需要兩個代理服務器再查找對方的地址了，所以代理服務器不參與接下來的通話流了。這就完成了一個完整的使用INVITE/200/ACK 三方握手來建立SIP會話的過程。會話建立過程中的細節描述再13節由描述。

現在，Alice和Bob的媒體會話開始了，他們通過發送剛纔建立會話所交換的SDP包中約定的互相明白的媒體包來進行會話。一般情況下，端到端的媒體包和SIP信號控制包通過不同的通訊路徑來發送。

在會話中，Alice或者Bob都可以改變他們自己的媒體會話屬性。這個可以通過發送一個包含新媒體屬性描述的re-INVITE請求來完成。這個re-INVITE是捆綁在一個現有的會話的，這樣參與會話的對方可以明白這是要改變現有的會話屬性而不是新建立一個會話。對方收到這個re-INVITE請求後，會發送一個200（OK）應答表示接受這個改變。請求方通過一個ACK來表示接受了對方的這個200(OK)應答。如果對方不同意這個媒體屬性變化，他會發送一個錯誤的應答比如488（暫時不能進行），這個也會收到發起者的一個ACK響應。不管怎樣，就是是re-INVITE的失敗也不會影響到現有的會話－原有的會話還可以用上次的媒體會話屬性繼續。可以在14節找到會話屬性更改的細節說明。

在通話結束的時候，Bob首先斷開（掛機hangs up），並且發送一個BYE的消息。這個BYE的消息將直接送到Alice的softphone，同樣是跳過代理的。Alice通過發送200（OK）應答來確認收到了這個BYE消息，這個消息終止了會話並且應答了BYE的請求。ACK在這裏不需要發送－一個ACK信號只在響應一個INVITE的響應的時候被髮送。我們稍晚一點會討論這個INVITE的特別處理，但是基於SIP的可靠性的機制，一個通話的時間可以認爲包含電話振鈴和掛機的時間（but relate to the reliability mechanisms in SIP, the length of time it can take for a ringing phone to be answered, and forking.）基於這樣的原因，SIP請求的處理通常根據是否INVITE請求進行分類，INVITE類和非INVITE類請求分開處理。結束會話的細節可以在15節查到。

24.2節描述了圖1中使用的全部消息詳細解釋。在某些情況下，所有會話中的包都繼續通過代理轉發會很有用。比如，如果biloxi.com代理服務器希望在INVITE之後繼續保持SIP消息流，他會在INVITE中增加一個頭域（Record-Route）包含一個URI指向這個代理服務器的hostname或者IP地址。這個消息會被Bob的SIP電話和Alice的softphone所接到（因爲Record-Route頭域將在200(OK)應答中被送回），並且在會話中一直保存。那麼biloxi.com代理服務器就可以繼續接收和轉發ACK,BYE,給BYE的200（OK）應答。每一個代理都可以單獨決定是否接收INVITE以後的後續消息，並且這些後續消息都可以被髮送到那些決定接收後續消息的代理服務器。這種情況通常發生在提供mid-call業務的代理服務器上。

登記服務是另一個常用的SIP操作。登記服務是biloxi.com代理服務器知道Bob當前地址的一個方法。在初始化的時候，或者每隔一段時間，Bob的SIP 電話發送REGISTER消息給biloxi.com的一個註冊服務器。REGISTER消息包含了Bob當前登陸服務器的SIP或者SIPS的URI（sip:[email protected]）（轉換成爲Contact域中的SIP或者SIPS URI）。登記服務器登記這個映射，這個叫做綁定（binding），寫到一個數據庫裏邊，叫做定位服務（location service），這個數據庫可以被biloxi.com的代理服務器使用。通常登記服務器和代理服務器是做在一起的。一個很重要的概念就是SIP服務器的差別在邏輯上，並非在物理上的差別。

Bob並沒有限定非得在一個單個設備上發起註冊。比如，他家裏的SIP電話和公司的SIP電話都可以註冊。這些消息在定位服務（location service）中保存，並且允許代理服務器通過不同的手段查找Bob。同樣的，不同的用戶也可以在同一個設備上同時註冊。

定位服務（location service）是一個邏輯概念。他是讓代理服務通過輸入一個URI來查詢到底應該向哪裏轉發請求。可以簡單通過用戶註冊來建立這個定位服務所需要的資料，也可以通過其他方法。可以通過其他任意的地址映射方式來實現定位服務。

最後在SIP中需要注意的是，註冊服務只是用來提供路由收到的SIP請求的，它並不做請求的身份認證的判定。在SIP中授權和認證可以通過建立在基於請求/應答的模式上的上下文相關的請求來實現，也可以使用更底層的方式來實現（具體在26節有描述）。

完整的註冊SIP消息描述例子在24.1節。

其他SIP的操作，比如檢查SIP服務器的負載，或者使用客戶端使用可選項（OPTIONS），或者用CANCEL取消一個未決的請求，在後續的章節中會介紹。

5、協議的結構
SIP是一個分層的協議，意思是說SIP協議由一組相當無關的處理層次組成，這些層次之間只有鬆散的關係。協議分成不同層次來描述是爲了能夠更清晰的表達，在同一個小節裏有功能的公共要素的交叉描述。本協議並沒有規定一個具體的實現。當我們說一個要素”包含”某一個層，我們的意思是這個要素複覈這個層定義的規則。

不是SIP每一個要素都一定包含每一個層。此外，SIP定義的要素是邏輯上的要素，不是物理要素。一個物理的實現可以實現不同的邏輯要素，或許甚至是基於串行事務處理原理。SIP最底層的是它的語法和編碼層。編碼方式是採用擴展的Backus-Naur Form grammar(BNF範式)。完整的BNF描述在25節；第7節有簡要的SIP消息結構描述。

第二層是傳輸層。它定義了一個客戶端如何發送請求和接收應答，以及一個服務器如何接收請求和發送應答。所有的SIP要素都包含一個通訊層。第18節有通訊層的描述。

第三層是事務層。事務是SIP的基本組成部分。一個事務是客戶發送的一個請求事務（通過通訊層）發送到一個服務器事務，連同服務器事務的所有的該請求的應答發送回客戶端事務。事務層處理應用服務層的重發，匹配請求的應答，以及應用服務層的超時。任何一個用戶代理客戶端（user agent client UAC）完成的事情都是由一組事務構成的。有關事務的討論在第17節有描述。用戶代理包含一個事務層，來實現有狀態的代理服務器。無狀態的代理服務器並不包含事務層。事務層包含一個客戶元素（可以認爲是一個客戶事務）和一個服務器元素（可以認爲是一個服務器事務），他們都可以用一個有限狀態機來處理特定的請求。

在事務層之上是事務用戶（TU）。每一個SIP實體，除了無狀態代理，都是一個事務用戶。當一個TU發出一個請求，它首先創建一個客戶事務實例（client transaction instance）並且和請求一起發送，這包括了目標IP地址、端口號、以及發送請求的設備。TU可以創建客戶事務，也可以取消客戶事務。當客戶取消一個事務，它請求服務器終止正在處理的事務，並且回滾狀態到該事務開始前的狀態，並且產生指定的該事務的錯誤報告。這是由CANCEL請求完成的，這個請求有自己的事務，並且包含一個被取消的事務（第9節）。

SIP要素，包含，用戶代理客戶端和服務器，無狀態和有狀態代理服務器和註冊服務器，包含一個可以互相區別的核心（Cores）。Cores，除了無狀態代理服務器，都是事務用戶。UAC(用戶代理客戶端)和UAS(用戶代理服務端)的cores的行爲依賴於實現，對所有的實現來說，有幾個公共的原則（第8節）。對UAC來說，這些規則約束請求的建立；對UAS來說，這些規則約束請求的處理和應答。由於註冊服務在SIP中是一個重要的角色，所以UAS處理REGISTER請求有一個特別的名字：登記員（registrar，登記服務器）。第10節描述了UAC和UAS的對REGISTER實現的core（核心）行爲。第11節描述了OPTIONS的UAC和UAS的core實現，這個OPTIONS用來檢測UA的處理能力的（UA-user agent）。