GB28181/SIP/SDP 協(xié)議簡介（下）

3.SIP協(xié)議

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

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

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

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

3.1 概念講述

3.1.1 SIP request

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

3.1.2 SIP response

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

3.1.3 Transaction

SIP協(xié)議是一種事務(wù)型協(xié)議。transaction的概念建立在請求和回復(fù)之上，一個請求和相關(guān)的最終回復(fù)就組成了一個transaction。（不包括關(guān)于ACK的處理）由于在一次通話建立到結(jié)束的過程中，會有多個Transaction，所以需要對Transaction進(jìn)行唯一性標(biāo)記，在SIP中對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的概念之后，針對請求和回復(fù)的不同就出現(xiàn)了client Transaction和server Transaction。CT指的是請求發(fā)起者所具有的Transaction的部分，ST是請求的接受者所具有的部分。

3.1.6 用戶代理 UA（User Agent）

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

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

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

3.1.8 INVITE

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

3.1.9 session

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

3.2.0 dialog

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

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)用場景，會有不同的實(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，一個物理設(shè)備既可以是UAC同時也可以是UAS。
• Proxy Server： 代理服務(wù)器的作用主要是轉(zhuǎn)發(fā)Request和Response給其他的Proxy Server或者UA，Proxy Server分為有狀態(tài)代理服務(wù)器（Stateful Proxy）和無狀態(tài)代理服務(wù)器（Stateless Proxy），前者會保留一次通信事務(wù)的狀態(tài)，通過一個有限狀態(tài)機(jī)來控制轉(zhuǎn)發(fā)操作，而后者不保存狀態(tài)，只是實(shí)現(xiàn)透明的轉(zhuǎn)發(fā)操作。
• Registration/Location Server： 注冊和定位服務(wù)器用于登記和定位UA，在線的UA會定時的向Registration服務(wù)器發(fā)送SIP消息來表明UA當(dāng)前的位置（如IP地址、端口號等），Registration服務(wù)器會將該信息存入數(shù)據(jù)庫（或者散列表）中，當(dāng)其他UA向該UA發(fā)送request時就能獲得該UA的位置。
• Redirect Server： 用于重定向，在邏輯上相當(dāng)于一個特殊功能的UA。

3.3 SIP方法

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

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

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

各方法含義可參考：SIP請求方法

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

3.4 SIP協(xié)議格式

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

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

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

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

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

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

請求消息

請求消息整體格式如圖：

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

請求消息包括以下幾種請求命令：

響應(yīng)消息

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

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

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

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

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

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

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

SIP 頭

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

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

樣例：

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

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

消息體

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

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

4.SDP協(xié)議

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

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

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

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

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

樣例：

4.1 SDP簡介

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

會話信息

• 會話名和目的。
• 會話活動時間。

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

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

媒體信息

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

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

4.2 SDP協(xié)議格式

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

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

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

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

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

4.3 SDP實(shí)例

# 請求視頻流
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: