3.SIP協(xié)議

SIP（Session initialization Protocol， 會(huì)話初始協(xié)議 ）是由IETF（Internet Engineering Task Force，因特網(wǎng)工程任務(wù)組）制定的多媒體通信協(xié)議。

它是一個(gè)基于文本的應(yīng)用層控制協(xié)議，用于創(chuàng)建、修改和釋放一個(gè)或多個(gè)參與者的會(huì)話。SIP 是一種源于互聯(lián)網(wǎng)的IP 語(yǔ)音會(huì)話控制協(xié)議，具有靈活、易于實(shí)現(xiàn)、便于擴(kuò)展等特點(diǎn)。SIP（Session Initiation Protocol）是一種類似于http協(xié)議的純文本應(yīng)用層協(xié)議。SIP可以用來(lái)控制會(huì)話的建立、取消、關(guān)閉等操作。主要可以實(shí)現(xiàn)以下功能：

• 用戶定位： 檢查終端用戶的位置，用于通信；
• 用戶有效性： 檢查用戶參與會(huì)話的意愿程度；
• 用戶能力： 檢查媒體和媒體參數(shù)；
• 建立會(huì)話： “振鈴”，在呼叫和被叫方同時(shí)建立會(huì)話的參數(shù)；
• 會(huì)話管理： 包括會(huì)話的傳輸和終止，修改會(huì)話參數(shù)以及請(qǐng)求服務(wù)

目前相關(guān)設(shè)備供應(yīng)商和業(yè)務(wù)供應(yīng)商聯(lián)合成立了一個(gè)關(guān)于SIP的論壇：http://www.sipforum.org，為SIP的發(fā)展提供一個(gè)自由討論、展現(xiàn)新思維的發(fā)展平臺(tái)

3.1 概念講述

3.1.1 SIP request

請(qǐng)求是SIP中一個(gè)最基本的概念之一，每一次關(guān)于SIP的操作都需要發(fā)送請(qǐng)求。

3.1.2 SIP response

回復(fù)和請(qǐng)求在SIP中一般都是成對(duì)出現(xiàn)，回復(fù)中的內(nèi)容是對(duì)端關(guān)于請(qǐng)求的處理結(jié)果。

3.1.3 Transaction

SIP協(xié)議是一種事務(wù)型協(xié)議。transaction的概念建立在請(qǐng)求和回復(fù)之上，一個(gè)請(qǐng)求和相關(guān)的最終回復(fù)就組成了一個(gè)transaction。（不包括關(guān)于ACK的處理）由于在一次通話建立到結(jié)束的過(guò)程中，會(huì)有多個(gè)Transaction，所以需要對(duì)Transaction進(jìn)行唯一性標(biāo)記，在SIP中對(duì)Transaction進(jìn)行唯一標(biāo)記的是branch參數(shù)

3.1.4 TU

在具備Transaction的概念之后，就出現(xiàn)了Transaction user的概念，Transaction架構(gòu)在Transaction 上，能夠?qū)ransaction進(jìn)行管理。

3.1.5 Client Transaction 和Server Transaction

有了Transaction的概念之后，針對(duì)請(qǐng)求和回復(fù)的不同就出現(xiàn)了client Transaction和server Transaction。CT指的是請(qǐng)求發(fā)起者所具有的Transaction的部分，ST是請(qǐng)求的接受者所具有的部分。

3.1.6 用戶代理 UA（User Agent）

UA指的是一個(gè)用戶實(shí)體。

3.1.7 UAC和UAS用戶代理服務(wù)器端（User Agent Server）

實(shí)際發(fā)起請(qǐng)求的用戶實(shí)體就是UAC，實(shí)際接收請(qǐng)求進(jìn)行處理的用戶實(shí)體就是UAS。

3.1.8 INVITE

特殊請(qǐng)求。SIP協(xié)議中最關(guān)鍵的請(qǐng)求。用于發(fā)起會(huì)話。

3.1.9 session

session，在收到對(duì)應(yīng)的INVITE請(qǐng)求的2xx回復(fù)之后，完成建立。在下一次INVITE請(qǐng)求的2xx回復(fù)發(fā)送或者收到后進(jìn)行修改，唯一一種結(jié)束方式為發(fā)送或者收到bye請(qǐng)求。

3.2.0 dialog

dialog的概念和session的概念類似，不同的是dialog是針對(duì)信令交互的一種概念，而session是對(duì)實(shí)際媒體發(fā)送和接收流程的描述。dialog的建立時(shí)間也是在接收到信令的200 OK回復(fù)之后，結(jié)束也是在發(fā)送或者接收到bye請(qǐng)求之后。

3.2 SIP的結(jié)構(gòu)

在SIP協(xié)議中主要包含以下幾種邏輯上的角色：UA、Proxy Server、 Register/Location Server、Redirect Server。

• UA： 用戶代理（User Agent）類似于http協(xié)議中瀏覽器的角色，是用戶操作的終端界面，用戶代理需要符合SIP協(xié)議的要求，但是結(jié)合其他的協(xié)議根據(jù)不同的應(yīng)用場(chǎng)景，會(huì)有不同的實(shí)現(xiàn)邏輯。比如，SIP協(xié)議結(jié)合H.323VoIP協(xié)議可以實(shí)現(xiàn)軟件電話功能。用戶代理分為UAC（UA Client）和UAS（UA Server）兩種邏輯實(shí)體，UAC發(fā)送SIP Request并接受Response，UAS接收SIP Request并返回Response，一個(gè)物理設(shè)備既可以是UAC同時(shí)也可以是UAS。
• Proxy Server： 代理服務(wù)器的作用主要是轉(zhuǎn)發(fā)Request和Response給其他的Proxy Server或者UA，Proxy Server分為有狀態(tài)代理服務(wù)器（Stateful Proxy）和無(wú)狀態(tài)代理服務(wù)器（Stateless Proxy），前者會(huì)保留一次通信事務(wù)的狀態(tài)，通過(guò)一個(gè)有限狀態(tài)機(jī)來(lái)控制轉(zhuǎn)發(fā)操作，而后者不保存狀態(tài)，只是實(shí)現(xiàn)透明的轉(zhuǎn)發(fā)操作。
• Registration/Location Server： 注冊(cè)和定位服務(wù)器用于登記和定位UA，在線的UA會(huì)定時(shí)的向Registration服務(wù)器發(fā)送SIP消息來(lái)表明UA當(dāng)前的位置（如IP地址、端口號(hào)等），Registration服務(wù)器會(huì)將該信息存入數(shù)據(jù)庫(kù)（或者散列表）中，當(dāng)其他UA向該UA發(fā)送request時(shí)就能獲得該UA的位置。
• Redirect Server： 用于重定向，在邏輯上相當(dāng)于一個(gè)特殊功能的UA。

3.3 SIP方法

在SIP的REQUEST中，核心的方法（method）定義了6種：INVITE、ACK、BYE、CANCEL、OPTIONS和REGISTER。

• INVITE消息用于發(fā)起一個(gè)新的會(huì)話；
• ACK消息用于完成會(huì)話的建立；
• BYE消息用于結(jié)束一個(gè)會(huì)話；
• CANCEL消息用于取消一個(gè)請(qǐng)求（一般是針對(duì)INVITE）；
• OPTIONS消息用于查詢服務(wù)器的能力；
• REGISTER消息用于發(fā)送注冊(cè)請(qǐng)求消息。

SIP請(qǐng)求的類型，也稱作SIP方法。RFC3261 中定義了六種方法。另外八種方法有獨(dú)立的RFC擴(kuò)展描述。如INFO、NOTIFY等等。

各方法含義可參考：SIP請(qǐng)求方法

也可移步SIP開(kāi)發(fā)手冊(cè)：鏈接: https://pan.baidu.com/s/1GFCHYqumPrd5ORhyCfJAew?pwd=yxj1 提取碼: yxj1

3.4 SIP協(xié)議格式

SIP消息采用[ISO 10646]文本方式編碼，分為兩類：請(qǐng)求消息和響應(yīng)消息。

請(qǐng)求消息：客戶端為了激活按特定操作而發(fā)給服務(wù)器的SIP消息。

響應(yīng)消息：用于對(duì)請(qǐng)求消息進(jìn)行響應(yīng)，指示呼叫的成功或失敗狀態(tài)。

每條SIP消息由以下三部分組成：起始行（ Start Line）/ 狀態(tài)行（Status-Line），SIP頭，消息體；請(qǐng)求消息和響應(yīng)消息都包括SIP頭字段和SIP消息字段。

起始行（ Start Line）/ 狀態(tài)行（Status-Line）

每個(gè)SIP消息由起始行開(kāi)始。起始行傳達(dá)消息類型（在請(qǐng)求中是方法類型，在響應(yīng)中是響應(yīng)代碼）與協(xié)議版本。起始行可以是一請(qǐng)求行（請(qǐng)求）或狀態(tài)行（響應(yīng)） 。

請(qǐng)求消息

請(qǐng)求消息整體格式如圖：

其中：起始行格式：命令名稱+目標(biāo)URI+sip協(xié)議版本

請(qǐng)求消息包括以下幾種請(qǐng)求命令：

響應(yīng)消息

響應(yīng)消息的起始行為狀態(tài)行（Status-Line），狀態(tài)行由協(xié)議版本、狀態(tài)碼和狀態(tài)原因短語(yǔ)組成，各個(gè)部分之間用一個(gè)空格字符進(jìn)行分隔。下面介紹其中的狀態(tài)碼。

SIP協(xié)議中共定義了6類狀態(tài)碼，其中狀態(tài)碼的第1位數(shù)字用于指示響應(yīng)類型，后兩位數(shù)字表示具體響應(yīng)。下面用“1xx”標(biāo)識(shí)狀態(tài)碼為“100-199”之間的響應(yīng)。

• 1xx：臨時(shí)響應(yīng)，表示請(qǐng)求消息正在被處理；
• 2xx：成功響應(yīng)，表示請(qǐng)求已被成功接收，完全理解并被接受；
• 3xx：重定向響應(yīng)，表示需采取進(jìn)一步以完成該請(qǐng)求；
• 4xx：客戶機(jī)錯(cuò)誤，表示請(qǐng)求消息中包含語(yǔ)法錯(cuò)誤信息或服務(wù)器無(wú)法完成客戶機(jī)請(qǐng)求；
• 5xx：服務(wù)器錯(cuò)誤，表示服務(wù)器無(wú)法完成合法請(qǐng)求；
• 6xx：全局故障，表示任何服務(wù)器無(wú)法完成該請(qǐng)求；

響應(yīng)消息整體格式如圖：

其中：起始行格式：sip協(xié)議版本+響應(yīng)返回碼+描述性短句

響應(yīng)消息是從100 - 699的返回碼，分別表示不同的意義。

消息返回碼可查看：SIP協(xié)議格式

SIP 頭

SIP頭域詳情可查閱：https://blog.csdn.net/qui910/article/details/122683453

用來(lái)傳遞消息屬性和修改消息意義。它們?cè)谡Z(yǔ)法和語(yǔ)義上與 HTTP 頭域相同（實(shí)際上有些頭就是借自 HTTP ），并且總是保持格式：<名字 >:<值>。

樣例：

下表是描述的是SIP頭格式中的各種Key值，可以大略分為4類：General通用頭域，Request請(qǐng)求頭域，Response響應(yīng)頭域，Entity實(shí)體域。

具體詳細(xì)可參考：SIP協(xié)議-04 SIP頭域

消息體

用于描述被初始的會(huì)話（例如，在多媒體會(huì)話中包括音頻和視頻編碼類型，采樣率等）。消息體能夠顯示在請(qǐng)求與響應(yīng)中。

SIP 清晰區(qū)別了在 SIP 起始行和頭中傳遞的信令信息與在 SIP范圍之外的會(huì)話描述信息。可能的消息體類型就包括本文將要描述的SDP會(huì)話描述協(xié)議、還有基于xml的消息體。

4.SDP協(xié)議

SDP全稱是Session Description Protocol，翻譯過(guò)來(lái)就是 描述會(huì)話的協(xié)議 。主要用于兩個(gè)會(huì)話實(shí)體之間的媒體協(xié)商。

SDP描述由許多文本行組成，文本行的格式為<類型>=<值>，表示為key=value;

SIP負(fù)責(zé)建立和釋放會(huì)話，一般來(lái)說(shuō)，會(huì)話中包含相關(guān)的媒體，比如視頻和音頻。媒體數(shù)據(jù)是由SDP描述的。SDP一般不單獨(dú)使用，它與SIP配合使用時(shí)會(huì)放到SIP協(xié)議的body中。會(huì)話建立時(shí)，需要媒體協(xié)商，雙方才能確定對(duì)方的媒體能力以及交換媒體的數(shù)據(jù)(這就是sdp的工作)。

那為什么要去發(fā)這個(gè)描述文本呢，主要是為了解決參與會(huì)話的各成員之間能力不對(duì)等的問(wèn)題，如果參加本次通話的成員都支持高質(zhì)量的通話，但是我們沒(méi)有去進(jìn)行協(xié)議，為了兼容性，使用的都是普通質(zhì)量的通話格式，這樣就很浪費(fèi)資源了。所以SDP的作用還是很有必要的。

在SIP協(xié)議的包含的內(nèi)容是SDP時(shí)，應(yīng)該把Content-Type設(shè)置成application/sdp。SDP協(xié)議于RFC4566中發(fā)布。

樣例：

4.1 SDP簡(jiǎn)介

SDP是會(huì)話描述協(xié)議的縮寫(xiě)，是描述流媒體初始化參數(shù)的格式，由IETF作為RFC 4566頒布。流媒體是指在傳輸過(guò)程中看到或聽(tīng)到的內(nèi)容，SDP包通常包括以下信息：

會(huì)話信息

• 會(huì)話名和目的。
• 會(huì)話活動(dòng)時(shí)間。

由于參與會(huì)話的資源是受限制的，因此包括以下附加信息是非常有用的。

• 會(huì)話使用的帶寬信息。
• 會(huì)話負(fù)責(zé)人的聯(lián)系信息。

媒體信息

• 媒體類型，例如視頻和音頻。
• 傳輸協(xié)議，例如RTP/UDP/IP和H.320。
• 媒體格式，例如H.261視頻和MPEG視頻。
• 多播地址和媒體傳輸端口（IP多播會(huì)話）。
• 用于聯(lián)系地址的媒體和傳輸端口的遠(yuǎn)端地址（IP單播會(huì)話）。

SDP描述由許多文本行組成，文本行的格式為<類型>=<值>，<類型>是一個(gè)字母，<值>是結(jié)構(gòu)化的文本串，其格式依<類型>而定?！?”兩側(cè)不允許有空格，一個(gè)值中的多個(gè)參數(shù)用空格分隔。

4.2 SDP協(xié)議格式

SDP會(huì)話描述由一個(gè)會(huì)話級(jí)描述（session_level description）和多個(gè)媒體級(jí)描述（media_level description）組成。會(huì)話級(jí)（session_level）的作用域是整個(gè)會(huì)話。其位置是從’v=’行開(kāi)始到第一個(gè)媒體描述為止。媒體級(jí)（media_level）描述是對(duì)單個(gè)的媒體流進(jìn)行描述（例如傳送單個(gè)音頻或者視頻的vlc sdp文件只有短短的幾句話，從m=開(kāi)始，這其實(shí)就是個(gè)媒體機(jī)描述），其位置是從’m=’行開(kāi)始到下一個(gè)媒體描述為止?？傊?，除非媒體部分重載，會(huì)話級(jí)的值是各個(gè)媒體的缺省默認(rèn)值（就是說(shuō)媒體級(jí)描述其實(shí)也是一個(gè)會(huì)話級(jí)描述，只不過(guò)沒(méi)寫(xiě)出來(lái)的會(huì)話級(jí)描述參數(shù)都用的缺省值）。

詳細(xì)可參考：SDP格式詳解

v= （協(xié)議版本）
o= （所有者/創(chuàng)建者和會(huì)話標(biāo)識(shí)符）
s= （會(huì)話名稱）
i=* （會(huì)話信息）
u=* （URI 描述）
e=* （Email 地址）
p=* （電話號(hào)碼）
c=* （連接信息 ― 如果包含在所有媒體中，則不需要該字段）
b=* （帶寬信息）
一個(gè)或更多時(shí)間描述（如下所示）：z=* （時(shí)間區(qū)域調(diào)整）
k=* （加密密鑰）
a=* （0個(gè)或多個(gè)會(huì)話屬性線路）
0個(gè)或多個(gè)媒體描述（如下所示）
時(shí)間描述

t= （會(huì)話活動(dòng)時(shí)間）
r=* （0或多次重復(fù)次數(shù)）
媒體描述

m= （媒體名稱和傳輸?shù)刂罚?/span>
i=* （媒體標(biāo)題）
c=* （連接信息 — 如果包含在會(huì)話層則該字段可選）
b=* （帶寬信息）
k=* （加密密鑰）
a=* （0個(gè)或多個(gè)會(huì)話屬性線路）

4.3 SDP實(shí)例

# 請(qǐng)求視頻流
INVITE sip:00000000001310018021@192.168.40.66:7100 SIP/2.0
Via: SIP/2.0/UDP 192.168.40.55:7100;rport;branch=z9hG4bK2480933505
From: