- 會話發起協議教程
- SIP - 首頁
- SIP - 簡介
- SIP - 網路元素
- SIP - 基本呼叫流程
- SIP - 訊息傳遞
- SIP - 響應程式碼
- SIP - 頭部
- SIP - 會話描述協議
- SIP - 提供/應答模型
- SIP - 移動性
- SIP - 分支
- SIP - 代理和路由
- SIP 到 PSTN
- SIP - 編解碼器
- SIP - B2BUA
- SIP 有用資源
- SIP 快速指南
- SIP - 有用資源
- SIP - 討論
SIP 快速指南
會話發起協議 - 簡介
會話發起協議 (SIP) 是 VoIP 技術中最常用的協議之一。它是一種應用層協議，與其他應用層協議協同工作，以控制網際網路上的多媒體通訊會話。
VoIP 技術
在進一步討論之前，讓我們先了解一下關於 VoIP 的一些要點。
VoIP 是一種允許您透過網際網路傳遞語音和多媒體（影片、圖片）內容的技術。它是利用網際網路隨時隨地進行通訊最便宜的方式之一。
VoIP 的一些優勢包括：
低成本
可移植性
無需額外電纜
靈活性
視訊會議
對於 VoIP 通話，您只需要一臺具有網際網路連線功能的計算機/筆記型電腦/移動裝置。下圖描述了 VoIP 通話是如何進行的。
有了這些基礎知識，讓我們回到 SIP 上來。
SIP – 概述
以下列出了一些關於 SIP 的要點：
SIP 是一種信令協議，用於在網際網路協議上建立、修改和終止多媒體會話。會話只不過是兩個端點之間的一個簡單呼叫。端點可以是智慧手機、筆記型電腦或任何可以透過網際網路接收和傳送多媒體內容的裝置。
SIP 是一種由 IETF（網際網路工程任務組）標準定義的應用層協議。它在 **RFC 3261** 中定義。
SIP 體現了客戶端-伺服器架構以及從 **HTTP** 中使用 URL 和 URI，以及從 **SMTP** 中使用文字編碼方案和頭部樣式。
SIP 利用 SDP（會話描述協議）來描述會話，並利用 RTP（即時傳輸協議）在 IP 網路上傳輸語音和影片。
SIP 可用於雙方（單播）或多方（多播）會話。
其他 SIP 應用包括檔案傳輸、即時訊息、視訊會議、線上遊戲和流媒體多媒體分發。
SIP 在哪裡適用？
基本上，SIP 是一種應用層協議。它是一種簡單的網路信令協議，用於與一個或多個參與者建立和終止會話。SIP 協議設計為獨立於底層傳輸協議，因此 SIP 應用程式可以在 TCP、UDP 或其他低層網路協議上執行。
下圖描述了 SIP 在總體方案中的位置：
通常，SIP 協議用於兩個或多個端點之間的網際網路電話和多媒體分發。例如，一個人可以使用 SIP 發起對另一個人的電話呼叫，或者有人可以與許多參與者建立電話會議。
SIP 協議的設計非常簡單，命令集有限。它也是基於文字的，因此任何人都可以閱讀 SIP 會話中端點之間傳遞的 SIP 訊息。
SIP - 網路元素
有一些實體幫助 SIP 建立其網路。在 SIP 中，每個網路元素都由一個 **SIP URI**（統一資源識別符號）標識，就像一個地址一樣。以下是網路元素：
- 使用者代理
- 代理伺服器
- 註冊伺服器
- 重定向伺服器
- 位置伺服器
使用者代理
它是端點，也是 SIP 網路中最重要的網路元素之一。端點可以發起、修改或終止會話。使用者代理是 SIP 網路中最智慧的裝置或網路元素。它可以是軟電話、行動電話或筆記型電腦。
使用者代理在邏輯上分為兩部分：
**使用者代理客戶端 (UAC)** - 傳送請求並接收響應的實體。
**使用者代理伺服器 (UAS)** - 接收請求併發送響應的實體。
SIP 基於客戶端-伺服器架構，其中主叫方的電話充當客戶端，發起呼叫，被叫方的電話充當伺服器，響應呼叫。
代理伺服器
它是接收來自使用者代理的請求並將其轉發到另一個使用者的網路元素。
基本上，代理伺服器的作用很像路由器。
它具有一定的智慧，可以理解 SIP 請求並藉助 URI 將其傳送出去。
代理伺服器位於兩個使用者代理之間。
在源和目標之間最多可以有 70 個代理伺服器。
代理伺服器有兩種型別：
**無狀態代理伺服器** - 它只是簡單地轉發接收到的訊息。此類伺服器不儲存任何呼叫或事務資訊。
**有狀態代理伺服器** - 此類代理伺服器會跟蹤收到的每個請求和響應，並在將來需要時可以使用它們。如果在規定時間內沒有收到另一方的響應，它可以重新發送請求。
註冊伺服器
註冊伺服器接受來自使用者代理的註冊請求。它幫助使用者在網路中進行身份驗證。它將使用者的 URI 和位置儲存在資料庫中，以幫助同一域內的其他 SIP 伺服器。
請檢視以下示例，該示例顯示了 SIP 註冊的過程。
這裡，主叫方想要在 TMC 域中註冊。因此，它向 TMC 的註冊伺服器傳送 REGISTER 請求，伺服器返回 200 OK 響應，因為它授權了客戶端。
重定向伺服器
重定向伺服器接收請求並在註冊伺服器建立的位置資料庫中查詢請求的預期接收者。
重定向伺服器使用資料庫獲取位置資訊，並向用戶返回 3xx（重定向響應）。我們將在本教程的後面討論響應程式碼。
位置伺服器
位置伺服器向重定向伺服器和代理伺服器提供有關呼叫者可能位置的資訊。
只有代理伺服器或重定向伺服器才能聯絡位置伺服器。
下圖描述了每個網路元素在建立會話中扮演的角色。
SIP – 系統架構
SIP 被構建為分層協議，這意味著它的行為是根據一系列相當獨立的處理階段來描述的，每個階段之間的耦合度很鬆散。
SIP 的最低層是其 **語法和編碼**。其編碼使用增強的 **巴克斯-諾爾正規化語法** (BNF) 指定。
第二層是 **傳輸層**。它定義了客戶端如何傳送請求和接收響應，以及伺服器如何接收請求和傳送響應。所有 SIP 元素都包含傳輸層。
接下來是 **事務層**。事務是由客戶端事務（使用傳輸層）傳送到伺服器事務的請求，以及從伺服器事務返回到客戶端的所有對該請求的響應。使用者代理客戶端 (UAC) 完成的任何任務都是使用一系列事務進行的。**無狀態代理**不包含事務層。
事務層之上的層稱為事務使用者。除了 **無狀態代理** 之外，每個 SIP 實體都是事務使用者。
SIP - 基本呼叫流程
下圖顯示了 SIP 會話的基本呼叫流程。
以下是上述呼叫流程的分步說明：
傳送到代理伺服器的 INVITE 請求負責發起會話。
代理伺服器立即向呼叫方（Alice）傳送 **100 Trying** 響應，以停止 INVITE 請求的重新傳輸。
代理伺服器在位置伺服器中搜索 Bob 的地址。獲取地址後，它將 INVITE 請求進一步轉發。
此後，Bob 生成的 **180 Ringing**（臨時響應）返回給 Alice。
Bob 接起電話後，很快就會生成 **200 OK** 響應。
Bob 在收到 **200 OK** 後，會收到來自 Alice 的 **ACK**。
同時，會話建立，RTP 資料包（對話）開始從兩端流動。
對話結束後，任何參與者（Alice 或 Bob）都可以傳送 **BYE** 請求以終止會話。
**BYE** 直接從 Alice 到 Bob，繞過代理伺服器。
最後，Bob 傳送 **200 OK** 響應以確認 BYE，會話終止。
在上述基本呼叫流程中，有三個 **事務**（標記為 1、2、3）。
完整的呼叫（從 INVITE 到 200 OK）稱為 **對話**。
SIP 梯形
代理如何幫助一個使用者連線到另一個使用者？讓我們藉助下圖找出答案。
圖中所示的拓撲稱為 SIP 梯形。該過程如下：
當主叫方發起呼叫時，會向代理伺服器傳送 INVITE 訊息。收到 INVITE 後，代理伺服器嘗試藉助 DNS 伺服器解析被叫方的地址。
獲取下一條路由後，主叫方的代理伺服器（Proxy 1，也稱為出站代理伺服器）將 INVITE 請求轉發到被叫方的代理伺服器，該伺服器充當被叫方的入站代理伺服器（Proxy 2）。
入站代理伺服器聯絡位置伺服器以獲取有關被叫方註冊使用者地址的資訊。
從位置伺服器獲取資訊後，它將呼叫轉發到其目的地。
一旦使用者代理瞭解其地址，它們就可以繞過呼叫，即對話直接傳遞。
SIP - 訊息傳遞
SIP 訊息有兩種型別：**請求**和**響應**。
請求的開頭行包含一個定義請求的方法和一個定義請求傳送位置的 Request-URI。
類似地，響應的開頭行包含一個響應程式碼。
請求方法
**SIP 請求**是用於建立通訊的程式碼。為了補充它們，有一些 **SIP 響應** 通常指示請求成功還是失敗。
這些被稱為方法的 SIP 請求使 SIP 訊息能夠工作。
方法可以被視為 SIP 請求，因為它們請求另一個使用者代理或伺服器採取特定操作。
方法分為兩種型別：
核心方法
擴充套件方法
核心方法
如下所述，共有六種核心方法。
INVITE
INVITE 用於與使用者代理發起會話。換句話說，INVITE 方法用於在使用者代理之間建立媒體會話。
INVITE 可以包含呼叫者在訊息體中的媒體資訊。
如果 INVITE 收到成功響應 (2xx) 或已傳送 ACK，則認為會話已建立。
成功的 INVITE 請求會在兩個使用者代理之間建立一個**對話**，該對話將持續到傳送 BYE 以終止會話。
在已建立的對話中傳送的 INVITE 稱為**重邀 (Re-INVITE)**。
重邀用於更改會話特性或重新整理對話狀態。
INVITE 示例
以下程式碼顯示瞭如何使用 INVITE。
INVITE sips:Bob@TMC.com SIP/2.0 Via: SIP/2.0/TLS client.ANC.com:5061;branch = z9hG4bK74bf9 Max-Forwards: 70 From: Alice<sips:Alice@TTP.com>;tag = 1234567 To: Bob<sips:Bob@TMC.com> Call-ID: 12345601@192.168.2.1 CSeq: 1 INVITE Contact: <sips:Alice@client.ANC.com> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY Supported: replaces Content-Type: application/sdp Content-Length: ... v = 0 o = Alice 2890844526 2890844526 IN IP4 client.ANC.com s = Session SDP c = IN IP4 client.ANC.com t = 3034423619 0 m = audio 49170 RTP/AVP 0 a = rtpmap:0 PCMU/8000
BYE
BYE 是用於終止已建立會話的方法。這是一個 SIP 請求，可以由呼叫者或被叫方傳送以結束會話。
它不能由代理伺服器傳送。
BYE 請求通常端到端路由，繞過代理伺服器。
BYE 無法傳送到正在等待的 INVITE 或未建立的會話。
REGISTER
REGISTER 請求執行使用者代理的註冊。此請求由使用者代理傳送到註冊伺服器。
REGISTER 請求可能會轉發或代理，直到到達指定域的權威註冊伺服器。
它在正在註冊的使用者**To**頭中攜帶 AOR（記錄地址）。
REGISTER 請求包含時間段（3600 秒）。
一個使用者代理可以代表另一個使用者代理傳送 REGISTER 請求。這稱為**第三方註冊**。在這裡，**From**標記包含代表**To**頭中標識的方提交註冊的方的 URI。
CANCEL
CANCEL 用於終止未建立的會話。使用者代理使用此請求取消之前發起的掛起呼叫嘗試。
它可以由使用者代理或代理伺服器傳送。
CANCEL 是一個**逐跳**請求，即它透過使用者代理之間的元素，並接收下一個有狀態元素生成的響應。
ACK
ACK 用於確認對 INVITE 方法的最終響應。ACK 始終沿 INVITE 的方向傳送。如果 INVITE 中沒有 SDP 主體（媒體特性），則 ACK 可能包含 SDP 主體。
ACK 不能用於修改已在初始 INVITE 中傳送的媒體描述。
接收 ACK 的有狀態代理必須確定是否應將 ACK 下游轉發到另一個代理或使用者代理。
對於 2xx 響應，ACK 是端到端的，但對於所有其他最終響應，當涉及有狀態代理時，它以逐跳方式工作。
OPTIONS
OPTIONS 方法用於查詢使用者代理或代理伺服器的功能並發現其當前可用性。對請求的響應列出了使用者代理或伺服器的功能。代理永遠不會生成 OPTIONS 請求。
擴充套件方法
訂閱 (Subscribe)
SUBSCRIBE 用於使用者代理建立訂閱，以便獲取有關特定事件的通知。
它包含一個**Expires**頭欄位，指示訂閱的持續時間。
時間段結束後，訂閱將自動終止。
訂閱在使用者代理之間建立對話。
您可以在過期時間之前，透過在對話中傳送另一個 SUBSCRIBE 來再次重新訂閱。
使用者將收到來自使用者的訂閱的 200 OK。
使用者可以透過傳送另一個 Expires 值為 0（零）的 SUBSCRIBE 方法來取消訂閱。
NOTIFY
NOTIFY 用於使用者代理獲取特定事件的發生情況。通常，當訂閱者和通知者之間存在訂閱時，NOTIFY 會在對話中觸發。
如果通知者接收到每個 NOTIFY，則會收到 200 OK 響應。
NOTIFY 包含一個**Event**頭欄位，指示事件，以及一個**subscriptionstate**頭欄位，指示訂閱的當前狀態。
NOTIFY 始終在訂閱開始和結束時傳送。
PUBLISH
PUBLISH 用於使用者代理將事件狀態資訊傳送到伺服器。
當有多個事件資訊來源時，PUBLISH 最有用。
PUBLISH 請求類似於 NOTIFY，但它不是在對話中傳送的。
PUBLISH 請求必須包含**Expires**頭欄位和**Min-Expires**頭欄位。
REFER
REFER 用於使用者代理將另一個使用者代理推薦給訪問對話的 URI。
REFER 必須包含**Refer-To**頭。這是 REFER 的必填頭。
REFER 可以在對話內或對話外發送。
**202 Accepted** 將觸發 REFER 請求，指示其他使用者代理已接受引用。
INFO
INFO 用於使用者代理向與其建立了媒體會話的另一個使用者代理傳送呼叫信令資訊。
這是一個端到端請求。
代理將始終轉發 INFO 請求。
UPDATE
如果會話未建立，則 UPDATE 用於修改會話的狀態。使用者可以使用 UPDATE 更改編解碼器。
如果會話已建立，則使用重邀來更改/更新會話。
PRACK
PRACK 用於確認已收到臨時響應 (1XX) 的可靠傳輸。
通常，當客戶端收到包含**RSeq**可靠序列號和**supported:100rel**頭的臨時響應時，客戶端會生成 PRACK。
PRACK 在**rack**頭中包含 (RSeq + CSeq) 值。
PRACK 方法適用於所有臨時響應，但 100 Trying 響應除外，100 Trying 響應永遠不會可靠地傳輸。
PRACK 可以包含訊息體；它可以用於提供/回答交換。
MESSAGE
它用於使用 SIP 傳送即時訊息。IM 通常由參與文字對話的參與者即時交換的簡短訊息組成。
MESSAGE 可以在對話內或對話外發送。
MESSAGE 的內容作為**MIME**附件包含在訊息體中。
通常會收到**200 OK**響應以指示訊息已傳遞到其目的地。
SIP - 響應程式碼
SIP 響應是由使用者代理伺服器 (UAS) 或 SIP 伺服器生成的訊息，用於回覆客戶端生成的請求。它可能是正式確認，以防止 UAC 重新傳輸請求。
響應可能包含 UAC 需要的一些其他資訊頭欄位。
SIP 有六種響應。
1xx 到 5xx 是從 HTTP 借用的，而 6xx 是在 SIP 中引入的。
1xx 被認為是**臨時**響應，其餘的是**最終**響應。
| 序號 | 功能和描述 |
|---|---|
| 1 | 1xx：臨時/資訊響應
資訊響應用於指示**呼叫進度**。通常，響應是端到端的（100 Trying 除外）。 |
| 2 | 2xx：成功響應
此類響應旨在指示請求已被接受。 |
| 3 | 3xx：重定向響應
通常，這些類響應由重定向伺服器對 INVITE 的響應傳送。它們也稱為重定向類響應。 |
| 4 | 4xx：客戶端故障響應
客戶端錯誤響應指示請求無法滿足，因為從 UAC 端識別出了一些錯誤。 |
| 5 | 5xx：伺服器故障響應
此類響應用於指示請求由於伺服器錯誤而無法處理。 |
| 6 | 6xx：全域性故障響應
此響應類指示伺服器知道請求在任何位置嘗試都會失敗。因此，不應將請求傳送到其他位置。 |
SIP - 頭部
頭是 SIP 訊息的一個組成部分，用於傳達有關訊息的資訊。它被構造為一系列頭欄位。
在大多數情況下，SIP 頭欄位遵循與 HTTP 頭欄位相同的規則。頭欄位定義為**Header: field**，其中 Header 用於表示頭欄位名稱，field 是包含資訊的標記集。每個欄位由一個欄位名後跟一個冒號 (":") 和欄位值組成（即**field-name: field-value**）。
SIP 頭 - 簡潔形式
許多常見的 SIP 頭欄位都有一個簡潔形式，其中頭欄位名稱用單個小寫字元表示。以下是一些示例：
| 頭 | 簡潔形式 |
|---|---|
| To | T |
| Via | V |
| Call-ID | I |
| Contact | M |
| From | F |
| Subject | S |
| Content-Length | I |
SIP 頭格式
下圖顯示了典型 SIP 頭的結構。
根據頭在 SIP 中的使用方式，將其分類如下：
SIP - 會話描述協議
SDP 代表會話描述協議。它用於以網路上參與者理解的格式描述多媒體會話。根據此描述，一方決定是否加入會議或何時或如何加入會議。
會議所有者透過傳送包含會話描述的多播訊息（例如所有者的名稱、會話的名稱、編碼、時間等）在網路上釋出它。根據這些資訊，廣告的接收者做出關於參與會話的決定。
SDP 通常包含在會話發起協議（通常稱為 SIP）的主體部分中。
SDP 在 RFC 2327 中定義。SDP 訊息由一系列稱為欄位的行組成，其名稱由單個小寫字母縮寫，並且為了簡化解析，這些欄位的順序是必需的。
SDP 的目的
SDP 的目的是傳達多媒體會話中媒體流的資訊，以幫助參與者加入或收集特定會話的資訊。
SDP 是一個簡短的結構化文字描述。
它傳達會話的名稱和目的、媒體、協議、編解碼器格式、時間和傳輸資訊。
嘗試加入的參與者會檢查這些資訊，並決定是否加入會話，以及如果決定加入，則如何以及何時加入會話。
該格式的條目形式為 <type> = <value>，其中 <type> 定義唯一的會話引數，<value> 為該引數提供特定值。
SDP 訊息的一般形式為 -
x = parameter1 parameter2 ... parameterN
該行以單個小寫字母開頭，例如 x。字母和 = 之間永遠沒有空格，每個引數之間正好有一個空格。每個欄位都有定義數量的引數。
會話描述引數
會話描述（* 表示可選）
- v = (協議版本)
- o = (所有者/建立者和會話識別符號)
- s = (會話名稱)
- i =* (會話資訊)
- u =* (描述的 URI)
- e =* (電子郵件地址)
- p =* (電話號碼)
- c =* (連線資訊 - 如果包含在所有媒體中則不需要)
- b =* (頻寬資訊)
- z =* (時區調整)
- k =* (加密金鑰)
- a =* (零個或多個會話屬性行)
協議版本
v= 欄位包含 SDP 版本號。由於 SDP 的當前版本為 0，因此有效的 SDP 訊息始終以 v = 0 開頭。
來源
o= 欄位包含有關會話發起者和會話識別符號的資訊。此欄位用於唯一標識會話。
該欄位包含 -
o=<username><session-id><version><network-type><address-type>
username 引數包含發起者的登入名或主機。
session-id 引數是網路時間協議 (NTP) 時間戳或用於確保唯一性的隨機數。
version 是一個數值欄位，每次會話更改時都會增加，也建議為 NTP 時間戳。
network-type 對於 Internet 始終為 IN。address-type 引數對於 IPv4 或 IPv6 地址，可以是 IP4 或 IP6，以點分十進位制形式或完全限定的主機名錶示。
會話名稱和資訊
s= 欄位包含會話的名稱。它可以包含任意數量的非零字元。可選的 i= 欄位包含有關會話的資訊。它可以包含任意數量的字元。
URI
可選的 u= 欄位包含一個統一資源指示符 (URI)，其中包含有關會話的更多資訊
電子郵件地址和電話號碼
可選的 e= 欄位包含會話主機的電子郵件地址。可選的 p= 欄位包含電話號碼。
連線資料
c= 欄位包含有關媒體連線的資訊。
該欄位包含 -
c =<network-type><address-type><connection-address>
network-type 引數定義為 Internet 的 IN。
address-type 定義為 IPv4 地址的 IP4 和 IPv6 地址的 IP6。
connection-address 是將傳送媒體資料包的 IP 地址或主機，可以是多播或單播。
如果是多播，則 connection-address 欄位包含 -
connection-address=base-multicast-address/ttl/number-of-addresses
其中 ttl 是生存時間值，number-of-addresses 指示從基本多播地址開始包含多少個連續的多播地址。
頻寬
可選的 b= 欄位包含有關所需頻寬的資訊。其形式為 -
b=modifier:bandwidth − value
時間、重複次數和時區
t= 欄位包含會話的開始時間和結束時間。
t=start-time stop-time
可選的 r= 欄位包含有關重複次數的資訊，可以以 NTP 或天數 (d)、小時 (h) 或分鐘 (m) 表示。
可選的 z= 欄位包含有關時區偏移的資訊。如果會話跨越從夏令時到標準時間或反之亦然的更改，則使用此欄位。
媒體公告
可選的 m= 欄位包含有關媒體會話型別的資訊。該欄位包含 -
m= media port transport format-list
media 引數可以是音訊、影片、文字、應用程式、訊息、影像或控制。port 引數包含埠號。
transport 引數包含使用的傳輸協議或 RTP 配置檔案。
format-list 包含有關媒體的更多資訊。通常，它包含在 RTP 音訊影片配置檔案中定義的媒體有效負載型別。
Example: m = audio 49430 RTP/AVP 0 6 8 99
這三種編解碼器之一可用於音訊媒體會話。如果打算建立三個音訊通道，則將使用三個單獨的媒體欄位。
屬性
可選的 a= 欄位包含前面媒體會話的屬性。此欄位可用於擴充套件 SDP 以提供有關媒體的更多資訊。如果 SDP 使用者無法完全理解，則可以忽略屬性欄位。對於媒體欄位中列出的每個媒體有效負載型別，可以有一個或多個屬性欄位。
SDP 中的屬性可以是
- 會話級，或
- 媒體級。
會話級意味著屬性列在 SDP 中第一個媒體行之前。如果是這種情況，則該屬性適用於其下面的所有媒體行。
媒體級意味著它列在媒體行之後。在這種情況下，該屬性僅適用於此特定媒體流。
SDP 可以包含會話級和媒體級屬性。如果同一屬性同時出現，則媒體級屬性會覆蓋該特定媒體流的會話級屬性。請注意，連線資料欄位也可以是會話級或媒體級。
SDP 示例
下面給出了一個會話描述示例，摘自 RFC 2327 -
v = 0 o = mhandley2890844526 2890842807 IN IP4 126.16.64.4 s = SDP Seminar i = A Seminar on the session description protocol u = http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps e = mjh@isi.edu(Mark Handley) c = IN IP4 224.2.17.12/127 t = 2873397496 2873404696 a = recvonly m = audio 49170 RTP/AVP 0 m = video 51372 RTP/AVP 31 m = application 32416udp wb a = orient:portrait
SIP - 提供/應答模型
SDP 與 SIP 的使用在 SDP 提供/應答 RFC 3264 中給出。SIP 中的預設訊息正文型別為application/sdp。
呼叫方在 SDP 中列出他們願意接收的媒體功能，通常在 INVITE 或 ACK 中。
被叫方在其對 INVITE 的 200 OK 響應中列出其媒體功能。
SDP 的典型 SIP 使用包括以下欄位：版本、來源、主題、時間、連線和一個或多個媒體和屬性。
SIP 不使用主題和時間欄位，但為了相容性而包含。
在 SDP 標準中，主題欄位是必需欄位，必須包含至少一個字元，建議如果沒有任何主題則為 s=-。
時間欄位通常設定為 t = 00。SIP 使用連線、媒體和屬性欄位在 UA 之間建立會話。
來源欄位在 SIP 中的使用有限。
會話 ID 通常在整個 SIP 會話中保持不變。
每次更改 SDP 時，版本都會遞增。如果傳送的 SDP 與之前傳送的 SDP 相同，則版本保持不變。
由於要使用的媒體會話和編解碼器型別是連線協商的一部分，因此 SIP 可以使用 SDP 指定多種替代媒體型別並選擇性地接受或拒絕這些媒體型別。
提供/應答規範 RFC 3264 建議為每個媒體欄位使用包含 a = rtpmap: 的屬性。透過將 SDP 響應中相應媒體欄位的埠號設定為零來拒絕媒體流。
示例
在以下示例中，呼叫方 Tesla 希望使用初始 INVITE 中攜帶的 SDP 與 Marry 建立音訊和視訊通話，其中包含兩個可能的音訊編解碼器和一個影片編解碼器 -
v = 0 o = John 0844526 2890844526 IN IP4 172.22.1.102 s = - c = IN IP4 172.22.1.102 t = 0 0 m = audio 6000 RTP/AVP 97 98 a = rtpmap:97 AMR/16000/1 a = rtpmap:98 AMR-WB/8000/1 m = video 49172 RTP/AVP 32 a = rtpmap:32 MPV/90000
編解碼器由 RTP/AVP 配置檔案編號 97、98 引用。
被叫方 Marry 接聽電話，為第一個媒體欄位選擇第二個編解碼器，並拒絕第二個媒體欄位，只希望 AMR 會話。
v = 0 o = Marry 2890844526 2890844526 IN IP4 172.22.1.110 s = - c = IN IP4 200.201.202.203 t = 0 0 m = audio 60000 RTP/AVP 8 a = rtpmap:97 AMR/16000 m = video 0 RTP/AVP 32
如果此音訊通話不可接受，則 Tom 將傳送 ACK 然後傳送 BYE 以取消通話。否則，將建立音訊會話並交換 RTP 資料包。
如本示例所示，除非保持媒體欄位的數量和順序，否則呼叫方無法確定被叫方接受和拒絕了哪些媒體會話。
以下各節總結了提供/應答規則。
生成提供規則
SDP 提供必須包含所有必需的 SDP 欄位（包括 v=、o=、s=、c= 和 t=）。這些是 SDP 中的必填欄位。
它通常包含一個媒體欄位 (m=)，但並非必須包含。媒體行包含按優先順序順序列出的所有編解碼器。唯一的例外是，如果端點支援大量編解碼器，則應列出最有可能被接受或最優選的編解碼器。不同的媒體型別包括音訊、影片、文字、MSRP、BFCP 等。
生成應答規則
對提供的 SDP 應答必須根據以下規則構建 -
應答必須具有與應答相同數量的 m= 行，並且順序相同。
可以透過將埠號設定為 0 來拒絕單個媒體流。
透過傳送非零埠號來接受流。
每個媒體型別列出的有效負載必須是提供中列出的有效負載的子集。
對於動態有效負載，每個方向不需要使用相同的動態有效負載編號。通常，只選擇一個有效負載。
修改會話規則
任何一方都可以發起另一個提供/應答交換來修改會話。修改會話時，必須遵循以下規則 -
來源 (o=) 行版本號必須與上次傳送的版本號相同，這表示此 SDP 與之前的交換相同，或者可以遞增 1，這表示必須解析的新 SDP。
提供必須包含所有現有的媒體行，並且必須按相同的順序傳送。
可以將其他媒體流新增到 m= 行列表的末尾。
可以透過將埠號設定為 0 來刪除現有媒體流。此媒體行必須保留在 SDP 中，以及此會話的所有未來提供/應答交換中。
呼叫保持
通話中的一方可以暫時將另一方置於保持狀態。這可以透過傳送一個與原始 INVITE 的 SDP 相同的 INVITE 來完成，但其中包含a = sendonly屬性。
透過傳送另一個包含a = sendrecv屬性的 INVITE 使通話再次處於活動狀態。下圖顯示了呼叫保持的呼叫流程。
SIP - 移動性
個人移動性是指能夠在多個裝置上擁有一個恆定識別符號的能力。SIP 使用 REGISTER 方法支援基本的個人移動性，該方法允許移動裝置更改其 IP 地址和連線到 Internet 的連線點，並且仍然能夠接收來電。
SIP 還可以支援服務移動性 - 使用者在移動時保持相同服務的能力
移交期間的 SIP 移動性（呼叫前）
裝置透過簡單的SIP註冊將其聯絡URI與記錄地址繫結。根據裝置IP地址，註冊會自動授權此資訊在SIP網路中更新。
在切換過程中，使用者代理在不同的運營商之間路由，它必須再次使用Contact作為AOR向另一個服務提供商註冊。
例如，讓我們以以下呼叫流程為例。UA臨時收到了一個新的SIP URI和一個新的服務提供商。然後，UA執行雙重註冊 -
第一次註冊是向新的服務運營商進行的，它將裝置的Contact URI與新服務提供商的AOR URI繫結。
第二個REGISTER請求路由回原始服務提供商，並將新服務提供商的AOR作為Contact URI提供。
如呼叫流程後面所示，當請求進入原始服務提供商的網路時，INVITE將重定向到新服務提供商，然後該提供商將呼叫路由到使用者。
對於第一次註冊，包含裝置URI的訊息將是 -
REGISTER sip:visited.registrar1.com SIP/2.0 Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bK97a7ea349ce0fca Max-Forwards: 70 To: Tom <sip:UA1@registrar1.in> From: Tom <sip:UA1@registrar1.in>;tag = 72d65a24 Call-ID: 4e719d1c1fc9000803630373300@172.22.1.102 CSeq: 1 REGISTER Contact: <sip:Tom@172.22.1.102:5060> Expires: 600000 Content-Length: 0
第二次註冊訊息（帶有漫遊URI）將是 -
REGISTER sip:home.registrar2.in SIP/2.0 Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bKah4vn2u Max-Forwards: 70 To: Tom <sip:UA1@registrar2.in> From: Tom <sip:UA1@registrar2.in>;tag = 45375 Call-ID:87nr43i@172.22.1.102 CSeq: 6421 REGISTER Contact: <sip:UA1@registrar2.in> Content-Length: 0
上圖中顯示的第一個INVITE將傳送到sip:registrar2.in；第二個INVITE將傳送到sip: sip:Tom@registrar2.in，它將轉發到sip:Tom@172.22.1.102。它到達Tom並允許建立會話。定期需要重新整理這兩個註冊。
通話期間的移動性（重新邀請）
使用者代理可能會在會話期間更改其IP地址，因為它從一個網路切換到另一個網路。基本SIP支援此場景，因為對話中的重新邀請可用於更新Contact URI和更改SDP中的媒體資訊。
請檢視下圖中提到的呼叫流程。
這裡，Tom檢測到一個新網路，
使用DHCP獲取新的IP地址，以及
執行重新邀請以允許訊號和媒體流到新的IP地址。
如果UA可以從兩個網路接收媒體，則中斷可以忽略不計。如果不是這種情況，則可能會丟失一些媒體資料包，導致通話略微中斷。
重新邀請將顯示如下 -
INVITE sip:Jerry@TTP.com SIP/2.0 Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bK918f5a84fe6bf7a Max-Forwards: 70 To: <sip:Harry@TTP.com> From: sip:Tom@PPT.com;tag = 70133df4 Call-ID: 76d4861c19c CSeq: 1 INVITE Accept: application/sdp Accept-Language: en Allow: INVITE,ACK,CANCEL,BYE,INFO,OPTIONS,REFER,NOTIFY,SUBSCRIBE Contact: <sip:172.22.1.102:5060>; Content-Type: application/sdp Content-Length: 168 v = 0 o = PPT 40467 40468 IN IP4 192.168.2.1 s = - c = IN IP4 192.168.2.1 b = AS:49 t = 0 0 b = RR:0 b = RS:0 a = rtpmap:97 AMR/8000/1 m = audio 6000 RTP/AVP 96 a = fmtp:102 0-15 a = ptime:20 a = maxptime:240
重新邀請包含Bowditch的新IP地址（在Via和Contact頭欄位中）和SDP媒體資訊。
通話中移動性（帶替換頭）
在通話中移動性中，必須更改實際路由集（SIP訊息必須遍歷的SIP代理集）。我們不能在通話中移動性中使用重新邀請
例如，如果代理對於NAT遍歷是必需的，則必須更改Contact URI - 必須建立一個新的對話。因此，它必須傳送一個帶有Replaces頭的新的INVITE，該頭標識現有的會話。
注意 - 假設A和B都在通話中，如果A收到另一個INVITE（例如來自C）並帶有替換頭（應與現有對話匹配），則A必須接受INVITE並終止與B的會話並將所有資源轉移到新形成的對話。
呼叫流程如下圖所示。它類似於之前使用重新邀請的呼叫流程，除了當接受帶有Replaces的INVITE時，會自動生成BYE以終止現有對話。
以下是此場景中需要注意的要點 -
Tom和Jerry之間現有的對話包括舊的已訪問代理伺服器。
使用新無線網路的新對話需要包含新的已訪問代理伺服器。
因此，Tom傳送了一個帶有Replaces的INVITE，它建立了一個新的對話，該對話包括新的已訪問代理伺服器，但不包括舊的已訪問代理伺服器。
當Jerry接受INVITE時，會自動傳送BYE以終止透過舊的已訪問代理伺服器（現在不再參與會話）路由的舊對話。
生成的媒體會話是使用INVITE中SDP中的Tom的新IP地址建立的。
服務移動性
SIP中的服務可以在代理或UA中提供。除非使用者的裝置配置相同且具有相同的服務，否則提供服務移動性和個人移動性可能具有挑戰性。
SIP可以輕鬆支援網際網路上的服務移動性。當連線到網際網路時，配置為使用印度一組代理的UA仍然可以在歐洲漫遊時使用這些代理。它不會對媒體會話的質量產生任何影響，因為媒體始終在兩個UA之間直接流動，並且不會遍歷SIP代理伺服器。
端點駐留服務僅在端點連線到網際網路時可用。如果端點暫時丟失了其網際網路連線，則在端點中實現的呼叫轉發等終止服務將失敗。因此，某些服務是在網路中使用SIP代理伺服器實現的。
SIP - 分支
有時代理伺服器將單個SIP呼叫轉發到多個SIP端點。此過程稱為分叉。這裡，單個呼叫可以同時響鈴多個端點。
使用SIP分叉，您可以同時讓您的辦公電話和您的軟電話或手機上的SIP電話響鈴，讓您可以輕鬆地從任何裝置接聽電話。
通常，在辦公室裡，假設老闆無法接聽電話或不在，SIP分叉允許秘書接聽他分機的電話。
如果存在有狀態代理，則分叉將成為可能，因為它需要執行並響應它收到的許多響應。
我們有兩種型別的分叉 -
- 並行分叉
- 順序分叉
並行分叉
在這種情況下，代理伺服器將同時將INVITE分叉到兩個裝置（UA2、UA3）。這兩個裝置都將生成180響鈴，並且接收呼叫的裝置將生成200 OK。首先到達發起者的響應（假設UA2）將與UA2建立會話。對於另一個響應，將觸發CANCEL。
如果發起者同時收到兩個響應，則根據q值，它將轉發響應。
順序分叉
在這種情況下，代理伺服器將將INVITE分叉到一個裝置（UA2）。如果UA2此時不可用或繁忙，則代理伺服器將將其分叉到另一個裝置（UA3）。
分支 ID 和標籤
分支ID幫助代理將響應與分叉請求匹配。如果沒有分支ID，代理伺服器將無法理解分叉響應。分支ID將在Via頭中可用。
標籤由UAC用於區分來自不同UAS的多個最終響應。UAS無法解決請求是否已被分叉。因此，它需要新增一個標籤。
如果代理生成最終響應，則代理也可以新增標籤，它們永遠不會將其插入到它們轉發的請求或響應中。
可能單個請求也會被多個代理伺服器分叉。因此，將進行分叉的代理應將其自己的唯一ID新增到它建立的分支中。
呼叫段和呼叫ID
呼叫段是指兩個使用者代理之間的一對一信令關係。呼叫ID是SIP訊息中攜帶的唯一識別符號，用於指代呼叫。呼叫是呼叫段的集合。
UAC透過傳送INVITE開始。由於分叉，它可能會從不同的UA收到多個200 OK。每個對應於同一呼叫內的不同呼叫段。
因此，呼叫是一組呼叫段。呼叫段指的是UA之間的端到端連線。
呼叫段兩個方向的CSeq空間是獨立的。在一個方向內，每個事務的序列號都會遞增。
語音郵件
語音郵件現在對於企業使用者來說非常普遍。這是一個電話應用程式。當被叫方不可用或無法接聽電話時，它就會出現，PBX將通知呼叫方留下語音留言。
如果被叫方的號碼無法接通，使用者代理將獲得3xx響應或重定向到語音郵件伺服器。但是，需要某種SIP擴充套件來指示語音郵件系統使用哪個郵箱——也就是說，播放哪個問候語以及將錄製的訊息儲存在哪裡。有兩種方法可以實現這一點 -
使用SIP頭欄位擴充套件
使用Request-URI來表示此資訊
假設使用者sip:Tom@tutorialspoint.com在sip:voicemail.tutorialspoint.com處有一個提供語音郵件的語音郵件系統，當它轉發到語音郵件伺服器時，INVITE的Request-URI可能如下所示 -
sip:voicemail.tutorialspoint.com;target = sip:Tom@tutorialspoint.com;cause = 486
下圖顯示了Request-URI如何攜帶郵箱識別符號和原因（此處為486）。
SIP - 代理和路由
眾所周知，代理伺服器可以是無狀態的或有狀態的。在這裡，在本章中，我們將更多地討論代理伺服器和SIP路由。
無狀態代理伺服器
無狀態代理伺服器只是轉發它接收到的訊息。這種伺服器不儲存任何呼叫或事務資訊。
- 無狀態代理在轉發SIP請求後會忘記該請求。
- 透過無狀態代理，事務將很快。
有狀態代理伺服器
有狀態代理伺服器會跟蹤它接收到的每個請求和響應。如果需要，它可以在將來使用儲存的資訊。如果它沒有從另一端收到響應，它可以重新傳輸請求。
有狀態代理在轉發請求後會記住該請求，因此它們可以將其用於高階路由。有狀態代理維護事務狀態。事務意味著事務狀態，而不是呼叫狀態。
與無狀態代理相比，有狀態代理的事務速度並不快。
有狀態代理可以在需要時分叉和重新傳輸。（例如：呼叫轉發忙，例如）。
Via 和 Record-route
Record-Route
Record-Route頭由希望位於同一呼叫ID後續請求路徑中的代理插入請求中。然後，使用者代理使用它來路由後續請求。
Via
Via頭由伺服器插入請求中，以檢測迴圈並幫助響應找到返回客戶端的路徑。這僅有助於響應到達其目的地。
UA本身在傳送請求時生成並將其自己的地址新增到Via頭欄位中。
轉發請求的代理會在Via頭欄位列表的頂部新增一個包含其自身地址的Via頭欄位。
生成對請求的響應的代理或UA會按順序將請求中的所有Via頭欄位複製到響應中，然後將響應傳送到頂部Via頭欄位中指定的地址。
接收響應的代理會檢查頂部Via頭欄位並匹配其自身地址。如果不匹配，則會丟棄該響應。
然後刪除頂部Via頭欄位，並將響應轉發到下一個Via頭欄位中指定的地址。
Via頭欄位包含協議名稱、版本號和傳輸（SIP/2.0/UDP、SIP/2.0/TCP等），幷包含埠號和引數，如接收、rport、分支。
如果UA或代理從與頂部Via頭欄位中指定的地址不同的地址接收請求，則會將接收標籤新增到Via頭欄位中。
UA和代理會向Via頭欄位新增分支引數，該引數計算為Request-URI、To、From、Call-ID和CSeq編號的雜湊函式。
SIP 到 PSTN
SIP（軟電話）和PSTN（舊電話）都是不同的網路，使用不同的語言。因此，我們需要一個翻譯器（此處為閘道器）在這兩個網路之間進行通訊。
讓我們舉一個例子來說明SIP電話如何透過PSTN閘道器撥打PSTN電話。
在這個例子中，Tom (sip:tom@tutorialspoint.com)是SIP電話，Jerry使用全球電話號碼+91401234567。
透過閘道器從SIP到PSTN
下圖顯示了從SIP到PSTN透過閘道器的呼叫流程。
以下是從SIP電話撥打PSTN電話時發生的所有過程的分步說明。
首先，(Tom)SIP電話撥打全球號碼+91401234567以聯絡Jerry。SIP使用者代理將其識別為全球號碼，並使用DNS將其轉換為請求URI並觸發請求。
SIP電話直接向閘道器傳送INVITE請求。
閘道器透過選擇PSTN中下一個電話交換機的SS7 ISUP中繼來發起PSTN呼叫。
來自INVITE的撥號數字被對映到ISUP IAM中。ISUP地址完成訊息(ACM)由PSTN傳送回來，指示中繼已建立。
電話產生鈴聲並將其傳送到電話交換機。閘道器將ACM對映到包含SDP的183會話進度響應，該SDP指示閘道器將用於橋接來自PSTN的音訊的RTP埠。
在收到183後，主叫方的UAC開始接收來自閘道器傳送的RTP資料包，並將音訊呈現給主叫方，以便他們知道被叫方正在PSTN中進行呼叫。
當被叫方接聽電話時，呼叫完成，這會導致電話交換機向閘道器傳送應答訊息(ANM)。
然後，閘道器雙向切斷PSTN音訊連線，並向主叫方傳送200 OK響應。由於RTP媒體路徑已建立，閘道器在183中回覆SDP，但不會對RTP連線造成任何更改。
UAC傳送ACK以完成SIP信令交換。由於ISUP中沒有等效的訊息，閘道器會吸收ACK。
主叫方向閘道器傳送BYE以終止呼叫。閘道器將BYE對映到ISUP釋放訊息(REL)。
閘道器向BYE傳送200OK並從PSTN接收RLC。
SIP - 編解碼器
編解碼器（codec），是編碼器-解碼器的簡稱，執行兩個基本操作：
首先，它將模擬語音訊號轉換為等效的數字形式，以便於傳輸。
然後，它將壓縮後的數字訊號轉換回其原始的模擬形式，以便於播放。
市場上有很多編解碼器可用——有些是免費的，而另一些則需要許可。編解碼器的音質和頻寬會有所不同。
諸如電話和閘道器之類的硬體裝置支援幾種不同的編解碼器。在相互通訊時，它們會協商將使用哪個編解碼器。
在本章中，我們將討論一些廣泛使用的流行的SIP音訊編解碼器。
G.711
G.711是由ITU於1972年為數字電話應用而引入的編解碼器。該編解碼器有兩個變體：A-Law用於歐洲和國際電話線路，uLaw用於美國和日本。
G.711使用對數壓縮。它將每個16位樣本壓縮為8位，因此實現了1:2的壓縮比。
一個方向的位元率為64 kbit/s，因此一個呼叫消耗128 kbit/s。
G.711是PSTN網路使用的相同編解碼器，因此它提供了最佳的語音質量。但是，它比其他編解碼器消耗更多的頻寬。
它最適合於我們擁有大量可用頻寬的區域網。
G.729
G.729是一種頻寬要求低的編解碼器，它提供了良好的音訊質量。
該編解碼器以10毫秒長的幀對音訊進行編碼。給定8 kHz的取樣頻率，一個10毫秒的幀包含80個音訊樣本。
編解碼器演算法將每個幀編碼為10個位元組，因此結果位元率為一個方向的8 kbit/s。
G.729是一種許可編解碼器。想要使用此編解碼器的終端使用者應該購買實現它的硬體（無論是VoIP電話還是閘道器）。
G.729的一個常用變體是G.729a。它與原始編解碼器相容，但CPU要求更低。
G.723.1
G.723.1是ITU宣佈的一場競賽的結果，其目的是設計一種能夠透過28.8和33 kbit/s調變解調器鏈路進行呼叫的編解碼器。
我們有兩個G.723.1變體。它們都對30毫秒的音訊幀（即240個樣本）進行操作，但演算法有所不同。
第一個變體的位元率為6.4 kbit/s，而第二個變體的位元率為5.3 kbit/s。
這兩個變體的編碼幀分別為24位元組和20位元組長。
GSM 06.10
GSM 06.10是為GSM行動網路設計的編解碼器。它也稱為GSM全速率。
此GSM編解碼器變體可以免費使用，因此您經常會在開源VoIP應用程式中找到它。
該編解碼器對20毫秒長的音訊幀（即160個樣本）進行操作，並將每個幀壓縮為33個位元組，因此產生的位元率為13 kbit/s。
SIP - B2BUA
回傳使用者代理（B2BUA）是SIP應用程式中的一個邏輯網路元素。它是一種SIP UA，接收SIP請求，然後重新制定請求，並將其傳送出去作為新的請求。
與代理伺服器不同，它維護對話狀態，並且必須參與在其建立的對話上傳送的所有請求。B2BUA破壞了SIP的端到端特性。
B2BUA – 工作原理？
B2BUA代理在電話呼叫的兩個端點之間執行，並將通訊通道劃分為兩個呼叫支路。B2BUA是UAC和UAS的串聯。它參與呼叫雙方之間所有已建立的SIP信令。作為對話服務提供商提供的B2BUA可能會實現一些增值功能。
在發起呼叫的支路上，B2BUA充當使用者代理伺服器（UAS），並將請求作為使用者代理客戶端（UAC）處理到目標端，處理端點之間的背靠背信令。
B2BUA維護其處理的呼叫的完整狀態。B2BUA的每一側都作為RFC 3261中指定的標準SIP網路元素執行。
B2BUA的功能
B2BUA提供以下功能：
呼叫管理（計費、自動呼叫斷開、來電轉接等）
網路互通（可能需要協議適配）
隱藏網路內部結構（私有地址、網路拓撲等）
通常，B2BUA也實現在媒體閘道器中，以橋接媒體流，從而完全控制會話。
B2BUA示例
許多私有分支交換機（PBX）企業電話系統都集成了B2BUA邏輯。
一些防火牆內建了ALG（應用層閘道器）功能，允許防火牆授權SIP和媒體流量，同時仍保持高安全級別。
另一種常見的B2BUA型別稱為會話邊界控制器（SBC）。