注：內容為其他材料整理而來，內容可能有錯誤。若您發現錯誤，望留言指正，非常感謝！
1. 什么是 SIP 會話初始協議 session initiation protocol？
由互聯網工程任務組制定的, 用於多方多媒體通信的框架協議。
它是一個基於文本的應用層控制協議, 獨立於底層傳輸協議, 用於建立、修改和終止IP網絡上的雙方或多方多媒體會話。
2. 什么是信令？
信令是控制電路的信號，是終端和終端、終端和網絡之間傳遞的一種消息，專門用來控制電路，建立、管理、刪除連接，以使用戶能夠正常通過這些連接進行通信。
允許程控交換、網絡數據庫、網絡中其它“智能”節點交換下列有關信息：
呼叫建立、監控（Supervision）、拆除（Teardown）、分布式應用進程所需的信息（進程之間的詢問/響應或用戶到用戶的數據）、網絡管理信息。
信令通常需要在通信網絡的不同環節(基站、移動台和移動控制交換中心等)之間傳輸，各環節進行分析處理並通過交互作用而形成一系列的操作和控制，其作用是保證用戶信息的有效且可靠的傳輸。
信令網關就是兩個不同的網之間信令互通設備。
3. SIP 相關術語
3.1 呼叫
一個呼叫是由一個公共源端所邀請的在一個會議中的所有參加者組成，由一個全球唯一的Call-ID 進行標識。
3.2 事務
SIP是一個客戶 /服務器協議。
客戶和服務器之間的操作從第 1 個請求至最終響應為止的所有消息構成一個SIP事務 。
一個正常的呼叫一般包含三個事務。
其中，呼叫啟動包含兩個操作請求：邀請（ Invite）和證實（ ACK），前者需要回送響應，后者只是證實已收到最終響應，不需要回送響應。
呼叫終結包含一個操作請求：再見（ Bye）。
3.3 SIP URL (Uniform Resource Locators)
為了能正確傳送協議消息，SIP還需解決兩個重要的問題。
- 尋址，即采用什么樣的地址形式標識終端用戶；
- 用戶定位。
SIP沿用 WWW 技術解決這兩個問題。
- SIP URL的一般結構為：
SIP: 用戶名：口令 @ 主機：端口；傳送參數：用戶參數；方法參數；生存期參數；服務器地址參數？頭部名=頭部值
SIP：需采用SIP協議和所指示的端系統通信
用戶名：由任意字符組成，一般可取類似於E-mail用戶名形式，也可以是電話號碼
口令：可置於SIP URL中，但一般不建議，因為其安全性是有問題的
主機：主機域名或IPv4地址
端口：請求消息送往的端口號，其缺省值為5060，即公開的SIP端口號
傳送參數：采用TCP還是UDP傳送，缺省值為UDP
用戶參數：SIP URL的一個特定功能是允許主機類型為IP電話網關，此時，用戶名可以為一般的電話號碼。因此，在域名后，增加了“用戶參數”字段。該字段有兩個可選值：IP和電話，其設定為“電話”時，標識用戶名為電話號碼，對應的端系統為IP電話網關。
方法參數：所用的方法（操作）
生存期參數：UDP多播數據包的壽命，僅當纏訟參數為UDP、服務器地址參數為多播地址時才能使用。
服務器地址參數：和該用戶通信的服務器的地址，覆蓋“主機”字段中的地址，通常為多播地址。
傳送參數、生存期參數、服務器地址參數和方法參數均屬於URL參數，只能在重定向地址，及Contact字段中才能使用。
- SIP URL (Uniform Resource Locators)
用戶定位：
基於等級，SIP用戶終端上電后即向等級服務器等級，SIP專門為此定義了一個“登記”(REGISTER)請求消息，並規定了登記操作過程。
3.4 定位服務
SIP重定位服務器或代理服務器用來獲得被叫位置的一種服務， 可由定位服務器提供， 但 SIP協議不規定 SIP服務器如何請求定位服務。
3.5 代理服務器
一個邏輯網絡實體代表客戶端轉發請求或者響應，可以同時作為客戶端和服務器端。
代理服務器有三種形態： Stateless、 Stateful 和 CallStateful，其可以采用分支、循環等方式向多個地址嘗試轉發請求。
代理服務器的主要功能： 路由、 認證鑒權、 計費監控、 呼叫控制、 業務提供等。
3.6 重定向服務器
重定向服務器將請求中的目的地址映射為零個或多個新的地址，然后返回給客戶端，客戶端直接再次向這些新的地址發起請求。重定向服務器並不接收或者拒絕呼叫，主要完成路由功能，與注冊過程配合可以支持 SIP終端的移動性。
3.7 注冊員
注冊員為接收注冊請求的服務器，通常與 Proxy 或者 Redirect Server 共存。注冊員需要將注冊請求中的地址映射關系保存到數據庫中，供后續的相關呼叫過程使用， 同時可以提供定位服務。
3.8 用戶助理
用來發起或者接收請求的邏輯實體稱為User Agent。
4. SIP會話事務
5. SIP協議棧
SIP是應用層的控制協議，用來建立、修改和終止多媒體會話。
SIP本身不提供服務，只是作為一個部件與其他協議一起組成完成的多媒體構架。
SIP 協議是 IETF 多媒體數據和控制體系結構的一部分，與其它協議相互合作。
例如：
RSVP（ Resource ReServation Protocol ）用於預約網絡資源，
RTP（ Real-time Transmit Protocol ）用於傳輸實時數據並提供服務質量（ QoS ）反饋，
RTSP （ Real-Time Stream Protocol ）用於控制實時媒體流的傳輸，
SAP（ Session Announcement Protocol ）用於通過組播發布多媒體會話，
SDP（ Session Description Protocol ）用於描述多媒體會話。
但是 SIP 協議的功能和實施並不依賴這些協議。[1]
6. SIP消息
SIP消息采用文本方式編碼。
\( SIP消息=\left\{ \begin{aligned} \textbf{請求消息} &— 用於客戶端為了激活按特定操作而發給服務器的SIP消息，\\ &\;\;\;\;包括 INVITE，ACK，OPTIONS，BYE，CANCEL和 REGISTER消息等。 \\ \textbf{響應消息} &— 用於對請求消息進行響應，指示呼叫的成功或失敗狀態。不同類的響應消息由狀態碼來區分。\\ &\;\;\;\;狀態碼包含三位整數，狀態碼的第一位用於定義響應類型，另外兩位用於進一步對響應進行更加詳細的說明。 \end{aligned} \right. \)
6.1 請求消息
| 請求消息 | 消息含義 |
|---|---|
| INVITE | 發起會話請求，邀請用戶加入一個會話，會話描述含於消息體中。對於兩方呼叫來說，主叫方在會話描述中指示其能夠接受的媒體類型及其參數。 被叫方必需在成功響應消息的消息體中指明其希望接受哪些媒體，還可以指示其行將發送的媒體。如果收到的是關於參加會議的邀請，被叫方可以根據 Call-ID或者會話描述中的標識確定用戶已經加入該會議，並返回成功響應消息。 |
| ACK | 證實已收到對於 INVITE 請求的最終響應。該消息僅和 INVITE 消息配套使用。 |
| BYE | 釋放已建立的呼叫 |
| CANCEL | 取消尚未完成的呼叫請求，對於已完成的請求（即已收到最終響應的請求）則沒有影響。 |
| REGISTER | 向SIP網絡服務器登記用戶位置信息 → 即注冊認證 |
| OPTIONS | 查詢服務器的能力 |
6.2 響應消息
請求消息和響應消息都包括SIP頭字段和SIP消息字段。
在SIP消息中加入SDP消息正文部分。
| 序號 | 狀態碼 | 消息功能 |
|---|---|---|
| 1xx | 信息響應(呼叫進展響應)0 | 表示已經接受到請求消息，正在對其進行處理 |
| 100 | 試呼叫 | |
| 180 | 振鈴 | |
| 181 | 呼叫正在前轉 | |
| 182 | 排隊 | |
| 2xx | 成功響應 | 表示請求已經被成功接收、處理並被成功接受 |
| 200 | OK | |
| 3xx | 重定向響應 | 表示需要采取進一步動作，以完成該請求消息 |
| 300 | 多重選擇 | |
| 301 | 永久遷移 | |
| 302 | 臨時遷移 | |
| 303 | 見其他 | |
| 305 | 使用代理 | |
| 380 | 代換服務 | |
| 4xx | 客戶出錯 | 表示請求消息中包含語法錯誤或者SIP服務器不能完成對該請求消息的處理 |
| 400 | 錯誤請求 | |
| 401 | 無權 | |
| 402 | 要求付款 | |
| 403 | 禁止 | |
| 404 | 沒有發現 | |
| 405 | 不允許的方法 | |
| 406 | 不接受 | |
| 407 | 要求代理權 | |
| 408 | 請求超時 | |
| 410 | 消失 | |
| 413 | 請求實體太大 | |
| 414 | 請求URI太大 | |
| 415 | 不支持的媒體類型 | |
| 416 | 不支持的URI方案 | |
| 420 | 分機無人接聽 | |
| 421 | 要求轉機 | |
| 423 | 間隔太短 | |
| 480 | 暫時無人接聽 | |
| 481 | 呼叫腿/事務不存在 | |
| 482 | 相環探測 | |
| 483 | 調頻太高 | |
| 484 | 地址不完整 | |
| 485 | 不清楚 | |
| 486 | 線路忙 | |
| 487 | 中止請求 | |
| 488 | 此處不接受 | |
| 491 | 待處理請求 | |
| 493 | 難以辨認 | |
| 5xx | 服務器出錯 | 表示SIP服務器故障不能完成對正確消息的處理 |
| 500 | 內部服務器錯誤 | |
| 501 | 沒實現的 | |
| 502 | 無效網關 | |
| 503 | 不提供此服務 | |
| 504 | 服務器超時 | |
| 505 | SIP版本不支持 | |
| 513 | 消息太長 | |
| 6xx | 全局故障 | 表示請求不能在任何SIP服務器上實現 |
| 600 | 全忙 | |
| 603 | 拒絕 | |
| 604 | 都不存在 | |
| 606 | 不接受 |
6.3 消息結構
請求消息和響應消息的格式，一般由起始行、若干個消息頭和消息體構成。
SIP一般消息 = 起始行
*消息頭
CELF（空行）
[消息體]
- 起始行 = 請求行、狀態行（SIP請求消息起始行是請求行（Request-Line），響應消息起始行是狀態行（Status-Line））
- 請求消息頭至少包括 From, To, CSeq, Call-ID, Max-Forwards, Via六個頭字段，它們是構建SIP消息基本單元
- 消息體一般采用SDP（Session Description Protocol）協議，會話描述協議
6.3.1 請求消息
SIP 請求命令的格式，由起始行、消息頭和消息體組成。通過換行符區分消息頭中的每一條參數行。對於不同的請求消息，有些參數可選。
請求消息結構[2]
| 起始行 | 命令名稱 | 對端UPI | 版本 |
|---|---|---|---|
| 消息頭 | Call-ID: 本地標識@主機 | Call-ID: call-973636852-4@191.169.150.101 | 用以唯一標識一個特定的邀請或標識某一客戶的所有登記，每個會議呼叫都有自己的Call-ID |
| From：顯示名
|
From: <sip :1000@191.169.200.61> ;tag=1c17691 | 指示請求的發起者 | |
| To: 顯示名
|
To: < Sip :1000@191.169.200.61> To: < sip :1001@191.169.200.61> ;tag=62beb3ca |
指明請求的接收者 | |
| Cseq | Cseq: 1 INVITE | 命令序號，指明請求的接收者 | |
| Via: 發送協議 發送方;隱藏參數;生存期參數;多播地址參數;接收方標記,分支參數 | Via: SIP /2.0/UDP softx3000.bell-telephone.com:5060 Via: SIP /2.0/UDP 10.0.0.1:5060;received=191.169.12.30 字段：Via: SIP /2.0/UDP191.169.1.116:5061;ttl=16; maddr=191.169.10.20;branch=z9hG4bkbc427dad6 |
指示路由。可以防止請求消息傳送產生環路，並確保響應和請求消息選擇同樣的路徑，以保證通過防火牆或滿足其它特定的選路要求。 | |
| Contact:地址;q參數;動作參數;時效參數;擴展屬性 | Contact: < Sip :66500002@191.169.1.110:5061> ;q=0.7;expires=3600 | 用於 INVITE 、ACK 和 REGISTER 請求以及成功響應、呼叫進展響應和重定向響應消息，其作用是給出其后和用戶直接通信的地址。 | |
| Max-Forwards: 十進制整數 | Max-Forwards: 70 | 定義一個請求到達其目的地址所允許經過的中轉站的最大值。主要是為了出現環路時不會一直消耗代理服務器的資源。該字段的初始值為 70。 | |
| Allow: 十進制整數 | Allow: INVITE, ACK, OPTIONS, CANCEL, BYE | 給出代理服務器支持的所有請求消息類型列表。 | |
| Content-Length: 十進制整數 | Content-Length: 349 | 表示消息體的大小，為十進制值。 | |
| Content-Type: 十進制整數 | Content-Type: application/sdp | 表示發送的消息體的媒體類型。 | |
| Supported | Supported: 100rel | SIP 協議中定義的 100 類臨時響應消息的傳輸是不可靠的，100rel 擴展為 100 類響應消息的可靠傳輸提供了相應的機制。 | |
| User-Agent | User-Agent: Softphone Beta1.5 | 包含有發起請求的用戶終端的信息。 | |
| Expires | Expires: 5 | 指定了消息（或消息內容）多長時間之后超時。 | |
| Accept-Language | Accept-Language: en | 表示原因短語、會話描述或應答消息中攜帶的狀態應答內容的首選語言類型。 | |
| Authorization | Authorization：認證方式 USERNAME， REALM， NONCE， RESPONSE，URI， CNONCE， ALGORITHM | 包含某個終端的鑒權證書。 | |
| …… | |||
| 消息體 | SDP | 會話描述協議 |
Call-ID：主機應為全局定義域名和全局可選路IP地址，此時，本地標識由在“主機”范圍內唯一的URI字符組成。
From：顯示名為用戶界面上顯示的字符，若系統不予顯示，應置為“匿名(Anonymous)”。tag是全局唯一的16進制數字串標記，中間可帶連字符“-”。當兩個共享同一個SIP地址的用戶實例通相同的Call-ID發起呼叫邀請時，就需用此標記予以區分。
To：需要用標記來區分來自不同實例的響應。To字段匯總的標記是由每個實例至於響應消息中的。
Cesq：客戶在請求中應加入此字段，由命名名稱和一個十進制序號組成，由請求客戶選定，在Call-ID范圍內唯一確定。重發請求的序號保持不變。服務器將請求中的 Cseq 值復制到響應消息中，用於將請求和其觸發的響應相關聯。ACK 和 CANCEL 請求的 Cseq 值（十進制序號）和對應的 INVITE 請求相同，BYE 請求的 Cseq 序號應大於 INVITE 請求。服務器必須記憶相同 Call-ID 的INVITE 請求的最高序號，收到序號低於此值的 INVITE 請求應在給出響應后予以丟棄。
Via：發起請求的客戶必須將其自身的主機名或網絡地址插入請求的 Via 字段，如果未采用缺省端口號，還需插入此端口號。在請求前傳過程中，每個代理服務器必須將其自身地址作為一個新的 Via 字段加在已有的 Via 字段之前。如果代理服務器收到一個請求，發現其自身地址位於 Via 頭部中，則必須回送響應“檢測到環路”。
當請求消息通過網絡地址翻譯點（如防火牆）時，請求的源地址和端口號可能被改變，此時 Via 字段就不能成為響應消息選路的依據。為了防止這一點，代理服務器應校驗頂端 Via 字段，如果發現其值和代理服務器檢測到的前站地址不符，則應在該 Via 字段中加入“ receive ”參數，如此修改后的字段稱為“接收方標記 Via 頭部字段”。
Via字段格式介紹：發送協議的格式為： 協議名 /協議版本 /傳送層，協議名和傳送層的缺省值分別為 SIP 和 UDP。· 發送方為通常的發送方主機和端口號。 ·隱藏參數就是關鍵詞 hidden，如有此參數，表示該字段已由上游代理予以加密，以提供隱私服務。 ·多播地址參數和接收方標記的意義如前所述。 ·生存期參數與多播地址參數配用。 ·分支參數用於代理服務器並行分發請求時標記各個分支，當響應到達時，代理可判定是哪一分支的響應。
Contact：INVITE 和 ACK 請求中的 Contact 字段指示該請求發出的位置。它使被叫可以直接將請求（如 BYE 請求）發往該地址，而不必借助 Via 字段經由一系列代理服務器返回。
對 INVITE 請求的成功響應消息可包含 Contact 字段，它使其后 SIP 請求（如ACK 請求）可直接發往該字段給定的地址。該地址一般是被叫主機的地址，如果該主機位於防火牆之后，則為代理服務器地址。
對應於 INVITE 請求的呼叫進展響應消息中包含的 Contact 字段的含義和成功響應消息相同。但是， CANCEL 請求不能直接發往該地址，必須沿原請求發送的路徑前傳。
REGISTER 請求中的 Contact 字段指明用戶可達位置。該請求還定義了通配Contact 字段“ *”，它只能和值為 0 的“失效”字段配用，表示去除某用戶的所有登記。 Contact 字段也可設定“失效”參數（任選），給定登記的失效時間。如果沒有設定該參數，則用“失效”字段值作為其缺省值。如果兩者均無，則認為 SIP URI 的失效時間為 1 小時。
REGISTER 請求的成功響應消息中的 Contact 字段返回該用戶當前可達的所有位置。
重定向響應消息，如用戶臨時遷移、永久遷移、地址模糊等消息中的 Contact字段給出供重試的其它可選地址，可用於對 BYE INVITE 和 OPTIONS 請求的響應消息。
Contact字段格式介紹：地址的表示形式和 To ，From 字段相同。q 參數，其取值范圍為 [0，1]，指示給定位置的相對優先級。數值越大，優先級越高。 ·動作參數僅用於REGISTER 請求。它表明希望服務器對其后至該客戶的請求進行代理服務還是重定向服務。如果未含此參數，則執行動作取決於服務器的配置。 ·失效參數指明 URI 的有效時間，可用秒表示，也可用 SIP 日期表示。 ·擴展屬性就是擴展名。
Max-Forward：請求每經過一個中轉站，該值減 1。如果該值為 0 時該請求還沒有到達其目的地址，服務器將回送“ 483” (Too Many Hops) 響應並終止這個請求。
Content-Length：應用程序使用該字段表示要發送的消息體的大小，而不考慮實體的媒體類型。如果使用基於流的協議（如 TCP 協議）作為傳輸協議，則必須使用此消息頭字段。消息體的長度不包括用於分離消息頭部和消息體的空白行。Content-Length值必須大於等於 0。如果消息中沒有消息體，則 Content-Length 頭字段值必須設為 0。
Content-Type：如果消息體不為空，則必須存在 Content-Type 頭字段。 如果消息體為空且 Content-Type 頭字段存在，則表示此類型的消息體長度為 0（如一個空的聲音文件）。
Support：如果 UAC 支持該擴展， 則在發送的消息中增加Supported:100rel 頭域和字段。
如果 UAS 支持該擴展，則在發送 100 類響應時增加 Require:100rel 頭域和字段。 UAC 收到該響應消息后需要向 UAS 發送 PRACK 請求通知 UAS 已收到該臨時響應。 UAS 向 UAC 發送對 PRACK 的 2XX 響應消息結束對該臨時響應的確認過程。
如果某一 UA 想要在發送的臨時響應消息中攜帶 SDP 消息體，那么 UAC 和 UAS都必須支持和使用 100rel 擴展以保證該消息的可靠傳輸。
Accept-Language：如果消息中沒有 Accept-Language頭字段，則服務器端認為客戶端支持所有語言。
Authorization：終端收到認證請求消息后根據服務器端返回的信息和用戶配置等信息采用特定的算法生成加密的 RESPONSE ，並且通過新的請求消息發送給服務器端。
服務器端在收到帶有認證響應的新的請求消息后首先檢查 NONCE 的正確性。如果 NONCE不是本地產生，則直接返回失敗。否則如果 NONCE是本地產生，但是認證過程已經超時，則服務器端會重新產生 NONCE 並重新發起對用戶的認證過程。其中老的 NONCE 會通過CNONCE參數返回。
NONCE驗證通過后服務器端會根據 NONCE、用戶名、密碼（服務器端可以根據本地用戶信息獲取用戶的密碼） 、URI 等采用和終端相同的算法生成 RESPONSE ，並且對此 RESPONSE和請求消息中的 RESPONSE進行比較，如果二者一致則用戶認證成功，否則認證失敗。
Authorization字段格式： ·HTTP-DIGEST認證方式。 ·USERNAME：被認證的用戶的用戶名。 ·REALM：用於標識發起認證過程的域。 ·NONCE：由發起認證過程的實體產生的加密因子。
RESPONSE ：終端在收到服務器的認證請求后根據服務器端產生的 NONCE、用戶名、密碼、URI 等信息經過一定的算法生成的一個字符串。該字符串中包含了經過加密后的用戶密碼。（在認證過程中處理用戶密碼之外其他信息都會通過 SIP消息以明文的方式在終端和服務器端進行傳遞。）
URI：發起的呼叫請求消息的 Request-URI。由於終端在收到認證請求后需要重新向服務器端發起請求 （其中帶有認證響應信息） 。 該請求消息在經過網絡服務器時某些字段包括 Request－ URI 都有可能被修改。認證頭域的 URI 參數用於傳遞終端發起請求時原始消息的Request-URI用於對認證信息進行認證，這樣才能保證認證過程的正確性。
CNONCE：如果在服務器端超時后終端才向服務器返回了帶有認證響應的新的請求消息，則服務器端需要重新產生 NONCE重新對用戶進行認證。其中 NONCE中帶有新的 NONCE，老的 NONCE會通過 CNONCE參數返回給終端。
ALGORITHM：用於傳遞生成 RESPONSE的算法。
6.3.2 響應消息
SIP 響應消息的格式，由起始行、消息頭和消息體組成。通過換行符區分消息頭中的每一行參數。對於不同的響應消息，有些參數可選。
響應消息結構
| 起始行 | SIP/協議版本 | 狀態碼 | 描述性短語 |
|---|---|---|---|
| 消息頭 | Call-ID: 值 | ||
| Form: 值 | |||
| To: 值 | |||
| Cseq: 值 | |||
| Via: 值 | |||
| Contact: 值 | |||
| Max-Forwards: 值 | |||
| Allow: 值 | |||
| Content-Length: 值 | |||
| Supported: 值 | |||
| User-Agent: 值 | |||
| Content-Type: 值 | |||
| …… | |||
| 消息體 | SDP | ||
7. SIP監控域互聯結構
控制協議網關在SIP監控域和非SIP監控域的設備之間進行網絡傳輸協議、控制協議、設備地址的轉換；
媒體網關是進行媒體傳輸協議、媒體數據編碼格式的轉換。
8. 聯網結構
8.1 級聯結構
8.1.1 信令級聯結構
信令流逐級轉發
8.1.2 媒體級聯結構
8.2 互聯結構
互聯的系統平台及設備不應向對方的SIP端口發送應用無關消息，避免應用無關消息占用系統平台及設備的SIP消息處理資源。
8.2.1 信令互聯結構
處於平級關系，共享對方SIP監控域的監控資源
8.2.2 媒體互聯結構
