會話初始協議(Session Initiation Protocal, SIP)。SIP是一個應用層的信令控制協議，主要目的是在 IP 網絡中建立、修改和釋放多媒體會話的應用層協議。其主要的應用包括但不侷限於語音、消息、視頻、呼叫控制等。會話的參與者可以通過組播（multicast）、網狀單播（unicast）或兩者的混合體進行通信。
SIP的業務模式是一個點對點協議，其中有兩個要素——SIP用戶代理（User Agent, UA）和SIP網絡服務器。
SIP支持建立和終止多媒體通信的五個方面
- 用戶位置：確定用於通信的終端系統
- 用戶可用性：確定被叫方參與通信的意願
- 用戶能力：確定要使用的媒體和媒體參數
- 會話建立：“振鈴”在被叫和主叫方建立會話參數
- 會話管理：包括會話的傳輸和終止，修改會話參數的調用和服務。
SIP協議主要消息
SIP消息分類
SIP協議是以層協議的形式組成的，就是說它的行爲是以一套相對獨立的處理階段來描述的，每個階段之間的關係不是很密切。SIP協議將Server和User Agent之間的通訊的消息分爲兩類：請求消息和響應消息
請求常用方法 [請求消息]
請求在兩個SIP實體之間發起SIP事務，以建立，控制和終止會話。常用的SIP請求消息如下：
- INVITE：用於與用戶代理之間的媒體交換建立對話。
- ACK：客戶端向服務器端證實它已經收到了對INVITE請求的最終響應。
- PRACK：表示對1xx響應消息的確認請求消息。
- BYE：表示終止一個已經建立的呼叫。
- CANCEL：表示在收到對請求的最終響應之前取消該請求，對於已完成的請求則無影響。
- REGISTER：該方法爲用戶代理實施位置服務，該位置服務向服務器指示其地址信息。
- OPTIONS：表示查詢被叫的相關信息和功能。
- NOTIFY：通知用戶有關新事件的通知。
請求常用響應代碼 [響應消息]
- SIP協議中的響應消息用於對請求消息進行響應，指示呼叫的成功或失敗狀態。
臨時應答(1XX) ：對請求的臨時響應表明請求有效且正在處理中。
會話成功(2XX) ：200級響應表明成功完成請求。作爲對INVITE的響應，它表示呼叫已建立。
重定向(3XX) ：該組指示完成請求需要重定向。該請求必須在新的目的地完成。
請求失敗(4XX) ：請求包含錯誤的語法或無法在服務器上完成。
服務器失敗(5XX) ：服務器無法完成一個明顯有效的請求。
全局性錯誤(6XX) ：這是全球性的故障，因爲請求無法在任何服務器上完成。
-
類型 狀態碼 狀態說明
100試呼叫（Trying）
180振鈴（Ringing）
181呼叫正在前轉（Call is Being Forwarded）
200成功響應（OK）
302臨時遷移（Moved Temporarily）
400錯誤請求（Bad Request）
401未授權（Unauthorized）
403禁止（Forbidden）
404用戶不存在（Not Found）
408請求超時（Request Timeout）
480暫時無人接聽（Temporarily Unavailable）
486線路忙（Busy Here）
504服務器超時（Server Time-out）
600全忙（Busy Everywhere） -
概念
最終響應（Final response）：用於結束 SIP 事務的響應，與臨時響應相對。
所有的 2XX，3XX，4XX，5XX 和 6XX 響應都是最終響應。
臨時響應（Provisional response）：服務器用來表示工作進展，並不結束 SIP
事務的一種響應。編碼爲 1XX 的響應是臨時響應，其他響應都是最終響應。
SIP消息結構
SIP請求由三部分組成：請求行、請求頭和請求體。SIP 是一個基於文本的協議，在這一點上與 HTTP 和 SMTP 相似，這裏對比一個簡單的SIP請求和HTTP請求：
GET /index.html HTTP/1.1
INVITE sip:[email protected] SIP/2.0
在 HTTP 中， GET 指明一個獲取資源（文件）的動作，而 /index.html 則是資源的地址，最後是協議版本號。而在 SIP 中，INVITE 表示發起一次請求，[email protected] 爲請求的地址，稱爲 SIP URI，最後也是版本號。其中，SIP URI很類似一個電子郵件，其格式爲“協議:名稱@主機”。與 HTTP 和 HTTPS 相對應，有 SIP 和 SIPS，後者是加密的；名稱可以是一串數字的電話號碼，也可以是字母表示的名稱；而主機可以是一個域名，也可以是一個IP地址。
SIP 是一個對等的協議，類似 P2P。不像傳統電話那樣必須有一箇中心的交換機，它可以在不需要服務器的情況下進行通信，只要通信雙方都彼此知道對方地址（或者，只有一方知道另一方地 址），在不知道的情況下就需要服務器來中轉。
INVITE 示例 ！！！
1、Request-Line：請求行
請求行包括三個部分：方法名、請求URL、協議版本
請求的方法，定義了請求的性質（INVATE、NOTIFY、BYE等），以及一個Request-URI，指出請求應該發送的位置。典型的SIP URI的格式爲sip：username @ domainname或sip：username @ hostport。如下圖示例：
SIP請求頭示例
2、Message Header：請求頭
-
![]()
Message Header.png
via：SIP版本號（2.0）、傳輸類型（UDP）、呼叫地址 、branch。branch爲分支，是一隨機碼，它被看作傳輸標識，標誌會話事務。
<＝Via字段中地址是消息發送方或代理轉發方設備地址，一般由主機地址和端口號組成
<＝傳輸類型可以爲UDP、TCP、TLS、SCTP
From：表示請求消息的發送方和目標方
<＝如果裏面有用戶名標籤，地址要求用尖括號包起來
<＝對於INVITE消息，可以在From字段中包含tag，它也是個隨機碼
To：請求消息的目標方
Contact：是INVITE消息所必須的，用來告訴對方，回消息給誰。**
<＝（注意區別：在180RINGING的時候，這裏是目標方地址）**
Call-ID：用於標識一個特定邀請以及與這個邀請相關的所有後續事務（即標識一個會話）
CSeq：字段是用來給同一個會話中的事務進行排序的，每發送一個新的請求，該值加1，當排序到65535（也就是216的最大數），會開始新一輪的排序。
Allow：允許的請求消息類型
Supported：
Session-Expires：存活時間，用戶的響應必須在這個時間範圍內
Min-SE：最小長度。
X-UCM-AudioRecord：自定義字段
X-UCM-CallPark：自定義字段
Max-Forwards：最大轉發數量限制了通訊中轉發的數量。它是由一個整數組成，每轉發一次，整數減一。如果在請求消息到達目的地之前該值變爲零，那麼請求將被拒絕並返回一個483（跳數過多）錯誤響應消息。
User-Agent：指明UA的用戶類型
Content-Type：消息實體類型
Content-Length：消息實體長度，單位爲字節
本地將生成From tag和Call-ID全局唯一碼，被叫方代理則生成To tag全局唯一碼。這三個隨機碼做爲整個對話中對話標識（dialog indentifier）在通話雙方使用。
3、Message Body：請求體
請求體主要包含的就是SDP相關的東西，詳細解釋可以參考這裏
-
![]()
Message Body
SIP主要概念模型
實體模型概述
SIP 協議模型定義了 User Agent 和 Server 等兩類主要實體。
SIP 協議把 User Agent（即 UA）分爲兩個部分：User Agent Client 和 User
Agent Server。呼叫方（稱 User Agent Client）發出邀請 （或呼叫），被叫
方（稱 User Agent Server）接受或拒絕邀請 （或呼叫）。
SIP Server
Proxy Server 代理服務器
Proxy Server 作爲 UAC和 UAS 間的中間媒體，它轉發 UAC 發來的的邀請，在轉發之前，根據被叫標識請求位置服務器獲得被叫的可能位置，然後分別向它們發出邀請；
Redirect Server 重定向服務器
Redirect Server 接受UAC來的邀請，根據被叫標識請求位置服務器獲得被叫的可能位置，把這些信息返回給邀請的發起者（UAC），和 Proxy Server 的不同之處就在於它不轉發邀請，邀請由主叫終端自己完成。
設 想 bob 和 alice 是經人介紹認識的，而他們還不熟悉，bob 想請 alice 吃飯就需要一箇中間人（M）傳話，而這個中間人就叫代理服務器（Proxy Server）。還有另一種中間人叫做重定向服務器（Redirect Server），它類似於這樣的方式工作──中間人 M 告訴 bob，我也不知道 alice 在哪裏，但我老婆知道，要不然我告訴你我老婆的電話，你直接問她吧，我老婆叫 W。這樣，M 就成了一個重定向服務器，而他老婆 W 則是真正的代理服務器。這兩種服務器都是 UAS，它們主要是提供一對欲通話的 UA 之間的路由選擇功能。具有這種功能的設備通常稱爲邊界會話控制器（SBC，Service Border Controller）。
Register Server 註冊服務器
主要用於登記分組終端的當前位置和位置服務的原始數據；
試想這樣一種情況，alice 還是個學生，沒有自己的手機，但它又希望 bob 能隨時找到她，於是當她在學校時就告訴中間人 M 說她在學校，如果有事打她可以打宿舍的電話；而當她回家時也通知 M 說有事打家裏電話。只要 alice 換一個新的位置，它就要向 M 重新“註冊”新位置的電話，以讓 M 能隨時找到她，這時候 M 就是一個註冊服務器。
Back to Back 背靠背用戶代理
RFC 3261 並沒有定義 B2BUA的功能，它只是一對 UAS 和 UAC的串聯。FreeSWITCH 就是一個典型的 B2BUA。
我們來看上述故 事的另一個版本：M 和 W 是一對恩愛夫妻。M 認識 bob 而 W 認識 alice。M 和 W 有意搓合兩個年輕人，但見面時由於兩人太靦腆而互相沒留電話號碼。事後 bob 相知道 alice 對他感覺如何，於是打電話問 M，M 不認識 alice，就轉身問老婆 W （注意這次 M 沒有直接把 W 電話給 bob），W 接着打電話給 alice，alice 說印象還不錯，W 就把這句話告訴 M， M 又轉過身告訴 bob。 M 和 W 一個面向 bob，一個對着 alice，他們兩個合在一起，稱作 B2BUA。在這裏，bob 是 UAC，因爲他發起請求；M 是 UAS，因爲他接受 bob 的請求併爲他服務；我們把 M 和 W 看做一個整體，他們背靠着背（站着坐着躺着都行），W 是 UAC，因爲她又向 alice 發起了請求，最後 alice 是 UAS。其實這裏UAC 和 UAS 的概念也不是那麼重要，重要的是要理解這個背靠背的用戶代理。因爲事情還沒有完，bob 一聽說 alice 對他印象還不錯，心花怒放，便想請 alice 吃飯，他告訴 M， M 告訴 W， W 又告訴 alice，alice 問去哪吃，W 又只好問 M， M 再問 bob…… 在這對年輕人掛斷電話這前， M 和 W 只能“背對背”的工作。
這幾種代理服務器的描述文字比較多，但是說的很形象。
作者：O_禾火_O
鏈接：https://www.jianshu.com/p/bb21032b3bb2
來源：簡書