SIP協議是VoIP中最重要的信令控制協議。SIP中第一件事情就是主叫發送INVITE給被叫，被叫響鈴。本文從多角度詳細描述INVITE消息發送的全過程。

---

一、閱讀RFC權威描述

關于INVITE消息發送，先查看RFC 3261中權威描述：

INVITE client transaction: https://tools.ietf.org/html/rfc3261#page-128

• 從TU收到發送INVITE的要求，通過transport層發出去，進入Calling狀態
• 啟動Timer A，Timer A觸發時發送INVITE
• 啟動Timer B，Timer B觸發時通知TU
• 網絡錯誤或收到1xx，2xx，300-699響應時處理邏輯各不相同

Figure 5: INVITE client transaction

INVITE server transaction: https://tools.ietf.org/html/rfc3261#page-136

• 收到INVITE時，將INVITE傳給TU，并進入Proceeding狀態
• 從TU收到100-199響應，通過transport層發出去
• 在Proceeding狀態收到INVITE，發送response

Figure 7- INVITE server transaction

很容易產生幾個疑問：

• Q1: TU是什么意思？實際中TU具體是什么？
• Q2: 為什么要啟動Timer A和Timer B？
• Q3: 被叫收到INVITE是從哪里收到的？
• Q4: “send 100 if TU won't in 200ms” 是什么意思？實際中是怎樣的？

---

二、理解基礎細節

Q1: TU是什么意思？實際中TU具體是什么？

TU是Transaction User的縮寫，表示的是使用Transaction層服務的上層模塊。從RFC 3261的 5 Structure of the Protocol 小節可以知道：SIP協議是分層闡述的，總結如下圖：

從上圖可知，Transaction層上面是Core層，所以TU就是Core層。對于主叫端是UAC Core，對于被叫端是UAS Core，對于代理服務器就是Proxy Core。如下面兩圖所示：

Q3: 被叫收到INVITE是從哪里收到的？

從上面的分層描述總很容易看出：被叫收到INVITE是從Transport Sublayer收到的，而Transport Sublayer是從具體使用系統網絡傳輸層如UDP或TCP層收到的。

小結：

將上面兩個狀態機和相關SIP消息綜合在一起，可以得到下圖：

INVITE client and server transaction

---

三、理解關鍵設計

第一節閱讀RFC時產生的疑問Q2和Q4都涉及到timer，為什么要引入這些timer呢？

這就涉及到SIP協議設計上對底層網絡的假設。RFC 3261中明確表示：

SIP works with both IPv4 and IPv6.

即SIP是設計運行在IP網絡協議之上的（SIP最初設計就是為VoIP服務的）。

SIP協議對網絡傳輸層沒有可靠性的要求，在不可靠的傳輸層如UDP上可以良好地工作。

所以SIP就要自己保證信令消息的可靠性傳輸，這也是SIP Transaction層的主要職責：消息丟失重傳、消息去重。自然地，SIP Transaction層的狀態機就要通過timer來實現重傳，通過狀態遷移實現去重。具體解釋如下：

Q2: 為什么要啟動Timer A和Timer B？

Timer A的工作邏輯：發出第一次INVITE請求，在超時時間(第一次是0.5秒)內未收到任何響應，則Timer A觸發，此時發出第二次INVITE請求，將超時時間加倍后(0.5x2=1秒)重新計時，超時未收到任何響應，則Timer A再次觸發INVITE的發送，依此類推，每次Timer A超時時間加倍。

這樣Timer A就實現了以經典的指數型延遲重試策略來確保INVITE的發送和響應接收

• 如果INVITE發送失敗，如下圖F01，則Timer A會觸發INVITE請求重發
• 如果INVITE發送成功，但響應返回途中丟失，如下圖F05，則Timer A也會觸發INVITE請求重發，UAS收到重復的INVITE請求后，保持狀態為Proceeding不變，重新發送響應給UAC

INVITE client and server transaction with timers

上面解釋了Timer A的作用：確保INVITE成功送達且成功收到響應。

那么Timer B呢，很簡單，在無網或者網絡很差的情況下，INVITE不應無限重發，這就是Timer B的作用，當Timer B超時(RFC建議為32秒)觸發時，則停止發送，給TU報告發送失敗。

Q4: “send 100 if TU won't in 200ms” 是什么意思？實際中是怎樣的？

在RFC 17.2.1 INVITE Server Transaction 中有明確說明：

When a server transaction is constructed for a request, it enters the
"Proceeding" state. The server transaction MUST generate a 100
(Trying) response unless it knows that the TU will generate a
provisional or final response within 200 ms, in which case it MAY
generate a 100 (Trying) response. This provisional response is
needed to quench request retransmissions rapidly in order to avoid
network congestion.

簡單來說，如果transaction知道TU不會在200毫秒內發送一個響應，那么transaction應立刻回一個100 Trying響應，以便告知發送方自己已經接收到INVITE請求了，請不要重傳INVITE了。這樣可以降低網絡擁堵。

要回答實際中UAS是否會發100 Trying響應，要看端到端的消息發送過程了。我們看常見的 “客戶端 - 服務端 - 客戶端” 的網絡拓撲下的情況：

從上圖可以看到：從主叫客戶端UAC到服務端，服務端要轉發給被叫客戶端，服務端無法確定多久能轉發完成，于是在F02步驟立刻回復主叫客戶端UAC一個100 Trying響應，告訴主叫：

我收到你的INVITE了，我在努力發送給被叫，請不要重發INVITE了

然后我們看被叫客戶端UAS在F04步驟收到INVITE請求，被叫的transaction知道其TU即UAS Core會立即響應一個180 Ringing，所以被叫客戶端UAS不會回復服務端100 Trying響應。

---

總結一下整個INVITE發送到響鈴的過程如下圖：

要點如下：

• 通過Timer A和B來保障消息可靠送達
• 通過狀態機來實現消息去重

總結

以上是生活随笔為你收集整理的sip协议详解_SIP协议详解-INVITE消息发送过程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。