3.SIP協議

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

它是一個基于文本的應用層控制協議，用于創建、修改和釋放一個或多個參與者的會話。SIP 是一種源于互聯網的IP 語音會話控制協議，具有靈活、易于實現、便于擴展等特點。SIP（Session Initiation Protocol）是一種類似于http協議的純文本應用層協議。SIP可以用來控制會話的建立、取消、關閉等操作。主要可以實現以下功能：

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

目前相關設備供應商和業務供應商聯合成立了一個關于SIP的論壇：http://www.sipforum.org，為SIP的發展提供一個自由討論、展現新思維的發展平臺

3.1 概念講述

3.1.1 SIP request

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

3.1.2 SIP response

回復和請求在SIP中一般都是成對出現，回復中的內容是對端關于請求的處理結果。

3.1.3 Transaction

SIP協議是一種事務型協議。transaction的概念建立在請求和回復之上，一個請求和相關的最終回復就組成了一個transaction。（不包括關于ACK的處理）由于在一次通話建立到結束的過程中，會有多個Transaction，所以需要對Transaction進行唯一性標記，在SIP中對Transaction進行唯一標記的是branch參數

3.1.4 TU

在具備Transaction的概念之后，就出現了Transaction user的概念，Transaction架構在Transaction 上，能夠對Transaction進行管理。

3.1.5 Client Transaction 和Server Transaction

有了Transaction的概念之后，針對請求和回復的不同就出現了client Transaction和server Transaction。CT指的是請求發起者所具有的Transaction的部分，ST是請求的接受者所具有的部分。

3.1.6 用戶代理 UA（User Agent）

UA指的是一個用戶實體。

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

實際發起請求的用戶實體就是UAC，實際接收請求進行處理的用戶實體就是UAS。

3.1.8 INVITE

特殊請求。SIP協議中最關鍵的請求。用于發起會話。

3.1.9 session

session，在收到對應的INVITE請求的2xx回復之后，完成建立。在下一次INVITE請求的2xx回復發送或者收到后進行修改，唯一一種結束方式為發送或者收到bye請求。

3.2.0 dialog

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

3.2 SIP的結構

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

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

3.3 SIP方法

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

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

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

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

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

3.4 SIP協議格式

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

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

響應消息：用于對請求消息進行響應，指示呼叫的成功或失敗狀態。

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

起始行（ Start Line）/ 狀態行（Status-Line）

每個SIP消息由起始行開始。起始行傳達消息類型（在請求中是方法類型，在響應中是響應代碼）與協議版本。起始行可以是一請求行（請求）或狀態行（響應） 。

請求消息

請求消息整體格式如圖：

其中：起始行格式：命令名稱+目標URI+sip協議版本

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

響應消息

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

SIP協議中共定義了6類狀態碼，其中狀態碼的第1位數字用于指示響應類型，后兩位數字表示具體響應。下面用“1xx”標識狀態碼為“100-199”之間的響應。

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

響應消息整體格式如圖：

其中：起始行格式：sip協議版本+響應返回碼+描述性短句

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

消息返回碼可查看：SIP協議格式

SIP 頭

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

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

樣例：

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

具體詳細可參考：SIP協議-04 SIP頭域

消息體

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

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

4.SDP協議

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

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

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

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

在SIP協議的包含的內容是SDP時，應該把Content-Type設置成application/sdp。SDP協議于RFC4566中發布。

樣例：

4.1 SDP簡介

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

會話信息

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

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

• 會話使用的帶寬信息。
• 會話負責人的聯系信息。

媒體信息

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

SDP描述由許多文本行組成，文本行的格式為<類型>=<值>，<類型>是一個字母，<值>是結構化的文本串，其格式依<類型>而定。“=”兩側不允許有空格，一個值中的多個參數用空格分隔。

4.2 SDP協議格式

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

詳細可參考：SDP格式詳解

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

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

m= （媒體名稱和傳輸地址）
i=* （媒體標題）
c=* （連接信息 — 如果包含在會話層則該字段可選）
b=* （帶寬信息）
k=* （加密密鑰）
a=* （0個或多個會話屬性線路）

4.3 SDP實例

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