一個簡單的SIP呼叫創建流程

本文譯自Alan B. Johnston的《SIP: understanding the Session Initiation Protocol》的第二版18頁。

 

A simple Session Establishment Example

 

原書地址：

http://bks3.books.google.com/books?id=VMP6gCBazzIC&printsec=frontcover

 

翻譯筆記：很久沒有翻譯東西了，寫起來仍是有些困難。本身直接看原文的時候沒有以爲什麼阻礙，可是當你要用中文寫出來的時候，就沒有那麼流暢了。還好通過幾個小時的坷坷絆絆，也算是把它翻譯出來了。一看時間，哇塞，都快臨晨2點了。真是一投入就忘記了時間。

我的能力有限，歡迎你們挑錯，同時把該文送過喜歡VoIP技術的朋友。

 

 

上圖顯示了兩個啓用了SIP的設備之間的 SIP 消息交互。 這兩個設備能夠是 SIP 電話、 手持設備、 掌上電腦或手機。 它假定兩個設備已經鏈接到 IP 網絡好比互聯網，而且已經知道彼此的 IP 地址。

主叫方Tesla經過發送的一條SIP INVITE給被叫方Marconi來啓動信息交互。 在 這條INVITE請求消息中包含了關於主叫方請求的會話或呼叫類型方面的細節。 它能夠是一個簡單的語音 （音頻） 會話、相似於視頻會議的多媒體會話或者它多是一個遊戲會話。

這條INVITE 消息包含如下內容：

INVITE sip:marconi@radio.org SIP/2.0

Via: SIP/2.0/UDP lab.high-voltage.org:5060;branch=z9hG4bKfw19b

Max-Forwards: 70

To: G. Marconi <sip:Marconi@radio.org>

From: Nikola Tesla <sip:n.tesla@high-voltage.org>;tag=76341

Call-ID: 123456789@lab.high-voltage.org

CSeq: 1 INVITE

Subject: About That Power Outage...

Contact: <sip:n.tesla@lab.high-voltage.org>

Content-Type: application/sdp

Content-Length: 158

v=0

o=Tesla 2890844526 2890844526 IN IP4 lab.high-voltage.org

s=Phone Call

c=IN IP4 100.101.102.103

t=0 0

m=audio 49170 RTP/AVP 0

a=rtpmap:0 PCMU/8000

 

由於SIP消息是基於文本編碼的協議，因此這使得SIP消息看起來像UDP數據報在以太網上傳輸那樣的在線傳輸。

INVITE消息中列出來的區域被稱爲頭部區域。它們都有着這樣的形式：頭標記：值 CRLF。第一行被稱爲開始行，該行標記了一種稱爲INVITE的方法，後面跟着的是請求的URI（Request-URI），最後是SIP版本號碼2，它們之間使用空格來加以區分。SIP消息的每一行都用過CRLF來終結。請求的URI是SIP URI的一種特殊形式，它指明瞭請求要被髮送到的資源，它也被稱做請求目標。SIP URI將會在後面部分進行更多更細討論。

緊隨其後的第二行的第一個字段是VIA，每個SIP設備產生或者轉發一條SIP消息的時候都會在Via字段裏面加上本身的地址，通常都是能夠經過DNS解析的IP地址。Via字段包含了SIP版本 2.0，緊跟一個「/」，以後的UDP表示經過UDP進行傳輸，而後接着一個空格，接着是主機名或者IP地址，接着分號，最後是端口值。在上面的這個例子中是通用的SIP端口號5060。SIP的傳輸採用TCP、UDP、TLS和SCTP。端口號將在章節後面些的內容進行描述。Branch參數是一個傳輸標記符。針對這條SIP信息的後續響應能夠被相互關聯上就是由於它們包含同樣的傳輸標記。

下一行的頭標記是Max-Forwards，它被初始化爲一個整數值，每一個SIP服務器在接受和轉發這個請求的過程當中都會增長這個值，這個將簡化環回檢測。

下一行就是To和From行了，它們標識了SIP請求的發起者和目標。如同本例同樣，在名字標籤被使用的狀況下，SIP URI就被放在了括弧內，它將被使用來路由請求。在提醒過程當中，名字標籤將會被使用，可是卻不會被協議自己所使用。

Call-ID行是用來保持對特定SIP會話進行記錄的標識符。SIP請求的發起者建立了本地惟一的字符串，而後一般會添加@和它的IP地址以便讓該標識全球惟一。針對Call-ID，會話中的每一方都會貢獻一個隨機的標識符。這些標識符在每一次呼叫中都不同。這些標識符被稱爲tag-（標籤），在每個會話創建以後，這些標籤會被包含在To和From字段。最初的INVITE中包含了一個From 標籤，可是在To中沒有標籤。

用戶代理（User Agent）產生一條INVITE來創建會話，同時也產生了惟一的Call-ID和From標籤。迴應這個INVITE的用戶代理也將產生一個標籤求。最終本地標籤（包含在From）、遠程標籤（包含在To）以及Call-ID三個合在一塊兒來惟一地標識創建起的會話，也被稱做「對話」，對話的標識符被參與會話的雙方用來識別特定會話，由於在同一時間，在它們之間可能會創建不少的會話。在該創建好的會話以後的後續請求也將使用這個會話標示符。它們將會在下面的實例中展現。

下一行的頭標記是CSeq，或者是command sequence（命令隊列），它包含有一個數字，以及一個方法。在本例中是INVITE。在每個新的請求被髮送的時候，這個數字就會被增長。在本例中，它被初始化爲1，可是也有可能從一個其它整數開始。

Via、Max-Forwards、To、From、Call-ID和CSeq構成了任何一條SIP請求語句裏面的最小組成部分。其它的部分就能夠做爲可選附加信息或者針對於特別請求的必要信息。在這條INVITE消息裏面，頭標記Contact也是須要的，由於它包含了Tesla的通信設備的SIP URI，也稱做UA（用戶代理），這個URI能夠被使用來直接路由信息到Tesla。可選的頭標記Subject（主題）也出如今這個例子裏，它沒有被協議所使用，可是卻能夠在振鈴被叫方的時候顯示出來以幫助被叫方決定是否接受這個呼叫。這點有點相似於電子郵件裏面的From（發件人）和Subject（主題）。其它出如今這條INVITE消息內的頭標記則包含了創建呼叫所必須的媒體信息。

Content-Type 和Content-Length頭標記字段標識了消息體是SDP，而且包含了158個字節的數據。 關於158個字節的基本知識包含在了表2.1中。每行結尾的CRLF顯示爲??。每一行的字節數據值顯示在右邊。在消息主體和消息頭部之間有一行空行把兩者隔開。而消息頭是以Content-Length結尾的。在本例中，有7行SDP數據描述了呼叫者Tesla但願創建呼叫的媒體屬性。這些媒體信息是必須的，由於SIP不知道將要創建的媒體會話的類型，因此呼叫者必須指明它想創建會話的類型（音頻、視頻、遊戲），SDP字段的名字在表2.2中，而且在7.1章節會討論，可是咱們將快速的預覽一下必要的基本信息。

表2.1: Content-Length Calculation 例子
LINE	TOTAL
v=0??	05
o=Tesla 2890844526 2890844526 IN IP4 lab.high-voltage.org??	59
s=Phone Call??	14
c=IN IP4 100.101.102.103??	26
t=0 0??	07
m=audio 49170 RTP/AVP 0??	25
a=rtpmap:0 PCMU/8000??	22
	158

Table 2.2: SDP 實例數據
SDP 參數	參數名稱
v=0	Version number 版本號碼
o=Tesla 2890844526 2890844526 IN IP4 lab.high-voltage.org	Origin containing name 原始包含名字
s=Phone Call	Subject 主題
c=IN IP4 100.101.102.103	Connection 鏈接
t=0 0	Time 時間
m=audio 49170 RTP/AVP 0	Media 媒體
a=rtpmap:0 PCMU/8000	Attributes 屬性

表2.2包含了

鏈接的IP地址：100.101.102.103

媒體格式：音頻

端口號：49170

媒體支持的協議：RTP

媒體編碼：PCM μ Law

採樣率：8000Hz

INVITE 只是SIP請求消息的一個例子，在RFC 3261和其它一些擴展RFC裏共定義了5種方法或者其它的SIP請求。圖2.1中的另一條消息是迴應INVITE 的180 Ringing消息。這條消息說明了被叫方已經收到了INVITE而且提醒正在進行。提醒多是振鈴、在屏幕上顯示一條消息，或者其它吸引被叫方Marconi注意的方法。

180 Ringing是SIP迴應消息的一個例子。迴應是數字化的而且由數字的第一個數字來分類。一條180迴應是消息類的，經過第一個位數字爲1來標識。消息類的迴應被用來傳遞呼叫過程當中的一些非關鍵的信息。不少SIP迴應代碼是基於HTTP 版本1.1的迴應代碼，可是作了一些擴展和增長。任何一位瀏覽過網頁的用戶在他們想要瀏覽的網頁不存在的時候應該都接到過來自於WEB服務器的「404 Not Found」迴應。404 NOT FOUND也是一個有效的SIP「客戶端錯誤類」的迴應，若是請求的是一位未知的用戶，那麼也會返回404。其它類的SIP迴應將在第五章節中描述。

在SIP中，單一的決定了迴應方式的迴應代碼是由服務器或者用戶來解釋的。在本例中的迴應，Ringing，就是標準的建議。可是可使用任何文原本提示更多信息，好比說 180 ，稍等，我將試圖叫醒他，就既是一個很是合理的SIP迴應，而且它有着和180 Ringing迴應相同的意思。

180 Ringing迴應有着以下的結構：

SIP/2.0 180 Ringing

Via: SIP/2.0/UDP lab.high-voltage.org:5060;branch=z9hG4bKfw19b

;received=100.101.102.103

To: G. Marconi <sip:marconi@radio.org>;tag=a53e42

From: Nikola Tesla <sip:n.tesla@high-voltage.org>&gt;;tag=76341

Call-ID: 123456789@lab.high-voltage.org

CSeq: 1 INVITE

Contact: <sip:marconi@tower.radio.org>

Content-Length: 0

該消息是大部分經過複製INVITE消息裏面的內容來的，包含了Via、To、From、Call-ID和CSeq行，而後添加了一行包含有SIP版本號、迴應代碼、緣由短語的迴應行。這種方法簡化了對迴應的消息處理。

Via行包含了原始的branch參數，可是增長了額外的received參數。這個參數包含了IP地址代表了請求是由100.101.102.103所接受的。這個IP地址也是Via行裏面的URI (lab.high-voltage.org)經過DNS所解析來的。

注意在迴應消息裏面你們認爲可能會被修改的To和From字段其實沒有被修改。從消息裏面看出，消息是從Tesla發送給Marconi，頭部區域讀取將讀取相反的信息。這是由於SIP裏面的To和From字段是用來顯示請求的方向，而不是消息的方向。由於Tesla發起了這個請求，全部的迴應將讀取To爲Marconi，From爲Tesla。

To行如今包含了一個由Marconi產生的標籤，在此次會話或者對話的全部後續請求和迴應都將包含由Tesla產生的標籤和Marconi產生的標籤。

這個迴應包含了一個Contact行，裏面包含了一個地址。一旦會話創建起來以後，經過裏面這個地址，Marconi就能夠被直接聯繫到。

當被呼叫的Marconi決定接受這個呼叫（好比接聽呼叫），那麼一條包含200 OK的迴應將會被髮送。這條迴應同時也代表了呼叫發起者所提出的媒體會話類型是能夠接受的。這條200 OK是成功類的迴應的一個例子。 200 OK的消息體包含有Marconi的媒體信息：

SIP/2.0 200 OK

Via: SIP/2.0/UDP lab.high-voltage.org:5060;branch=z9hG4bKfw19b

;received=100.101.102.103

To: G. Marconi <sip:marconi@radio.org>;tag=a53e42

From: Nikola Tesla <sip:n.tesla@high-voltage.org>;tag=76341

Call-ID: 123456789@lab.high-voltage.org

CSeq: 1 INVITE

Contact: <sip:marconi@tower.radio.org>

Content-Type: application/sdp

Content-Length: 155

v=0

o=Marconi 2890844528 2890844528 IN IP4 tower.radio.org

s=Phone Call

c=IN IP4 200.201.202.203

t=0 0

m=audio 60000 RTP/AVP 0

a=rtpmap:0 PCMU/8000

這條迴應採用和180 Ringing迴應同樣的方式構建的，它也包含一樣的To標籤和Contact URI。可是媒體支持能力卻必定要經過附加在SDP進行告知。和表2.2同樣的SDP字段，該SDP包含：

端點IP地址： (200.201.202.203);

媒體格式 (audio);

端口 (60000);

媒體傳輸協議： (RTP);

媒體編碼：(PCM μ-Law);

採樣率 (8,000 Hz).

最後一步就是經過一個「確認」消息來確認媒體會話。確認意思就是Tesla成功的接到了Marconi的迴應。媒體信息的交換可讓媒體會話使用其它協議來創建會話，在本例中是RTP。

ACK sip:marconi@tower.radio.org SIP/2.0

Via: SIP/2.0/UDP lab.high-voltage.org:5060;branch=z9hG4bK321g

Max-Forwards: 70

To: G. Marconi <sip:marconi@radio.org>;tag=a53e42

From: Nikola Tesla <sip:n.tesla@high-voltage.org>;tag=76341

Call-ID: 123456789@lab.high-voltage.org

CSeq: 1 ACK

Content-Length: 0

命令順序-CSeq有着和INVITE同樣的號碼，可是方法卻被設置成了ACK。到了這一點，媒體會話就將使用SIP消息上攜帶的媒體信息了。 媒體會話使用其它的協議開始了，典型的是RTP。Via行的branch參數包含一些不一樣於INVITE的新傳輸識別標識，由於確認的200 OK的ACK被認爲是一個獨立的傳輸。

這個信息交互展現了SIP是一個端到端的行令協議。一個SIP網絡，或者SIP服務器是不要求被使用的協議的。兩個運行SIP協議族的端點若是知道對方的IP地址的話就可使用SIP來創建會話。雖然不是很直觀，可是這個例子也展現了SIP協議的客戶端-服務器的特性。當Tesla產生INVITE請求，它就是一個SIP客戶端，當Marconi迴應這個請求，它就是一個SIP服務器。當媒體會話創建好了以後，Marconi產生一個BYE請求，這個過程它又是一個SIP客戶端，而Tesla迴應這個請求的時候，它則成了爲SIP服務器。這也就是爲何SIP服務器和SIP客戶端必須同時都包含SIP服務器和SIP客戶端軟件，由於在一個典型的會話過程當中，兩者都是不可獲取的。這個特色不一樣於其它客戶端-服務器端的HTTP或者FTP之類的Internet協議。WEB瀏覽器永遠都是HTTP客戶端，而WEB服務器永遠都是HTTP服務端，FTP也是同樣的道理。在SIP內，在會話過程當中，一個端點將在客戶端和服務器端進行來回切換。

在圖2.1種Marconi發送了一個BYE請求來結束會話：

BYE sip:n.tesla@lab.high-voltage.org SIP/2.0

Via: SIP/2.0/UDP tower.radio.org:5060;branch=z9hG4bK392kf

Max-Forwards: 70

To: Nikola Tesla <sip:n.tesla@high-voltage.org>;tag=76341

From: G. Marconi <sip:marconi@radio.org>;tag=a53e42

Call-ID: 123456789@lab.high-voltage.org

CSeq: 1 BYE

Content-Length: 0

本例中的Via行包含有Marconi的主機地址而且也包含了一個新的傳輸標示符，由於BYE被認爲是不一樣於上面的INVITE和ACK傳輸的單獨的傳輸。 To和From行反應了這個請求時產生於Marconi。他們已經將上面的傳輸信息顛倒了過來。可是Tesla可以經過和INVITE中同樣的本地標籤、遠程標籤和CALL-ID識別出該會話，而後結束相應的媒體會話。注意例子中全部的branch ID都使用z9hG4bK字符串開始，這是一個特殊的字符串，它說明了branch ID是使用了RFC 3261中嚴格定義的規則計算而來，也說明做爲一個傳輸識別標記，是可用的結果的[1]。

針對BYE請求的是一個200 OK的迴應：

SIP/2.0 200 OK

Via: SIP/2.0/UDP tower.radio.org:5060;branch=z9hG4bK392kf

;received=200.201.202.203

To: Nikola Tesla <sip:n.tesla@high-voltage.org>;tag=76341

From: G. Marconi <sip:marconi@radio.org>;tag=a53e42

Call-ID: 123456789@lab.high-voltage.org

CSeq: 1 BYE

Content-Length: 0

這個迴應應答了原始請求的CSeq ：1 BYE

[1]這個字符串是必須的，由於用戶代理經過RFC 3261 所產生的branch ID有可能不適合來作傳輸標示符。在本例中，客戶端必須使用To標標籤、From標籤、Call-ID和CSeq來建立本身的傳輸標識符