我們處在一個每天或者每小時，甚至於每分鐘都在變化的時代。大資料，人工智慧，5G，以至於XG都是推動變化的發動機。新的IP企業通訊環境中，和傳統的或者以前的企業通訊相比，一個比較重要的變化是SIP端的變化。SIP終端從單一固定物理形態改變為可移動的多形態終端。這個變化是革命性的變化，透過這個變化，才使得IP企業通訊的使用者可以實現移動辦公，遠端辦公，包括現在的物聯網IOT終端等應用場景，也實現了立體的雲端IPPBX和使用者終端的連線。但是，如果實現SIP移動支援的話，SIP呼叫的信令互動就因為多終端處理，它們相關的dialog，tag和事務可能會發生相應的變化。今天，筆者就SIP的移動性和SIP移動性引發的Dialog，Call-ID等方面的變化做一些討論說明。
此圖片以及以下部分圖片均來自於網際網路資源
自從2005年起, 著名的基於開源的Asterisk被Linksys WRT54G series應用到低端的企業和中小型企業的路由器中以後，緊接著在2006年，SIP協議棧被諾基亞遷移到了基於塞班作業系統的E系列諾基亞終端以後，SIP的移動性才真正開始獲得認可。隨著業務場景和需求的變化，網路系統的變化，現在的IPPBX或者電話系統中，SIP終端可以支援很多不同的型別，包括智慧手機端APP，物理SIP話機和PC端的SIP軟電話等幾種不同的形態，但是，無論SIP終端以何種形態或者存在方式，同一SIP賬號下的多種形態都需要註冊到SIP代理伺服器，透過SIP代理伺服器結合定位服務來實現不同形態SIP終端的呼叫控制。
1
SIP移動性背景說明
關於SIP移動性討論的分享，筆者在以前的文章中有過比較詳細的描述，讀者也可以參考歷史文件來獲得這方面的討論：SIP系列講座-SIP移動性的場景介紹。此文件是針對歷史文章的進一步補充，主要特別針對SIP移動場景中針對Dialog，Call-ID進行進一步闡述。
透過以上圖例，我們可以看到，SIP移動性主要針對SIP終端的移動性進行物理上的移動處理支援，SIP移動性支援了使用者終端自由移動，透過SIP代理伺服器實現對移動地址的靈活支援，使用者可以使用已註冊的任意一種移動終端接聽電話，因此SIP移動性必須具備以下四個方面的特徵：
- SIP透過SIP代理和轉發請求方式支援使用者的移動性，查詢地址後轉發到新的線上狀態地址。
- SIP使用者端形態可以是PC端的軟電話，物理SIP話機，手機APP，IOT終端或者其他無線SIP話機。
- 使用者必須註冊其當前的地址到SIP代理伺服器。
- 代理伺服器根據其定位地址來決定最終呼叫目的地。
2
SIP分叉呼叫中的併發呼叫和按序呼叫討論
在以上關於移動性的討論中，我們注意到一個比較重要的問題。當呼叫方呼叫被呼叫方時，如果SIP代理伺服器配置了不同方式的呼叫的話，被呼叫方就會因為移動端支援的不同，可能出現不同被呼叫方具體的結果。在SIP代理伺服器可以支援SIP分叉並行呼叫和SIP按序呼叫兩種方式。關於SIP fork的細節，讀者可以參考：分叉呼叫（Fork） 具體處理流程分析，筆者這裡僅重新回顧這些細節以便讀者方便了解後續的討論。這兩種方式會按照SIP呼叫流程的協商形式的不同而產生不同的呼叫流程和呼叫結果，最終會影響被呼叫方呼叫狀態。
在以上的並行呼叫處理中，SIP代理伺服器會同時呼叫兩個SIP終端使用者。如果其中一個首先應答的話（SIP物理話機-鼎信SIP話機（B-1）），代理伺服器然後執行呼叫方和之間的呼叫流程（180 ring），然後代理伺服器會取消另外一個呼叫（B-2的PC端軟電話），最後確認ACK握手，對另外一臺終端執行最終ACK處理。然後再執行應答終端之間的RTP建立，並且開始雙方RTP流的傳輸。
SIP分叉呼叫中的按序處理方式則和並行呼叫的處理方式有所不同，按序方式中，SIP代理伺服器會根據呼叫順序依次進行呼叫。讀者參考以下SIP分叉處理的按序呼叫流程示意圖，如果其中一臺SIP終端因為其他原因（Busy或者其他狀態）不能接聽了SIP的話，則返回302，然後確認302以後。代理伺服器依次進行下一個SIP終端呼叫，直到其中一個SIP使用者應答了呼叫，然後進行RTP流建立，雙方開始語音傳輸。
在分叉呼叫中，如果同一賬號支援了不同SIP終端例項註冊的話，在分叉呼叫中就會出現不同的連線狀態。當出現問題使用者，對其進行跟蹤排查是一個比較困難的事情。因此，如何對這些終端進行跟蹤就顯得比較重要。比較幸運的是，所有的SIP終端在不同事務中都根據不同的SIP頭和其他終端進行了區別。
我們現在討論一個在分叉呼叫中比較極端的場景，如果呼叫方A呼叫了被呼叫方B，被呼叫方B的兩個終端同時應答了呼叫的話，然後一段時間後，其中一個被呼叫方終端結束通話了呼叫，那麼，接下來的SIP呼叫流程會如何處理呢？在進行詳細說明之前，筆者首先對呼叫的兩個重要概念做一點提前說明。這兩個基本概念是call leg和dialog。在早期的SIP協議規範RFC2543中，call leg是定義兩個UA之間的SIP信令之間的關係，在RFC3261中使用dialog替代了call leg的定義。
Call Leg: Another name for a dialog [31]; no longer used in this
specification. (RFC3261 section 8)因此，在後續介紹中為了避免使用者的困惑，我們這裡首先說明。目前，很多使用者為了表達的方便，或者也有部分讀者對dialog比較迷惑，容易對這些功能誤用，希望讀者能夠引起注意。如果需要詳細瞭解dialog的規範說明，建議讀者參考RFC3261和RFC2543的規範。在以下的特殊呼叫場景中，我們可以看到，呼叫方A收到了請求的200 OK響應，一個呼叫產生了兩個call legs或者dialogs。
3
SIP分叉呼叫中dialog建立
根據以下這個特殊的流程，如果我們取消了移動端的呼叫的話，我們看一下如何處理不同的dialog以及其後續流程的變化。
在進一步討論之前，我們首先說明一下關於SIP dialog的定義。一個SIP dialog 是透過Call-ID，From中的local/本地tag和To遠端的tag組合定義的。現在讓我們一步步結合這個特殊示例進行呼叫分析，說明Call-ID，本地tag，遠端tag以及2以及CSeq的變化。在呼叫方發起第一個呼叫時，在以下的示例中，已經生成了Call-ID，本地的tag，但是沒有生成遠端的tag值。
SIP代理拒絕了第一個呼叫以後，同一呼叫方另外應該呼叫發起以後，SIP INVITE中出現了稍微不同的訊息內容。Call-ID相同，但是CSeq 出現了遞增（遞增1），並且因為這是應該新的事務，而且branch也出現了不同。
現在，被呼叫方回覆了200 OK以後，dialog建立就已經完成，針對此Call-ID和From tag=86aee210添加了本地的tag。
到此為止，一個完整的dialog就生成了。如果是另外一個終端應答了呼叫，其處理流程基本一致，Call-ID，From tag 始終是一樣的，To tag會有所不同。因此，分叉呼叫會導致多個dialog，每個dialog是完全唯一，它本身具有其獨特的。dialog建立以後，SIP代理負責綁定了雙方終端具體的呼叫業務關係，呼叫方和被呼叫方之間可以繼續進行其他的業務操作，例如呼叫保持，呼叫保持重啟，訂閱等等業務控制。這些業務都會生成不同的事務，但是，這些事務都屬於此dialog中。
如果讀者想了解更多關於dialog 和事務的詳解，讀者可以參考歷史文章：
再論SIP呼叫中的Call，Dialog和Transaction。透過以上流程詳解，我們可以看到SIP代理是如何一步步針對SIP的移動性功能支援流程進行處理的。
4
總結
SIP的移動性支援是來自於網路發展的必然，也是現代企業融合通訊的要求。越來越多的員工使用了移動裝置，多點辦公也逐漸成為常態。透過SIP移動性的支援，各種移動終端可以實現無縫呼叫連線。
筆者首先介紹了關於SIP移動端的起源，然後介紹了SIP移動性所引起的呼叫不同型別。在SIP代理伺服器端，代理伺服器可能根據配置的不同，支援了併發呼叫或者按序呼叫兩種形態。SIP代理伺服器根據不同型別的呼叫產生了不同的dialog以及其他tag的變化。在特殊場景中，SIP的dialog根據呼叫狀態也發生了變化。最後，筆者根據示例介紹了具體的tag，dialog等相關概念在SIP移動性方面的支援和變化情況，這些變化可能導致SIP移動支援中產生多個dialog。雖然，SIP移動性透過代理伺服器以後，產生了多種SIP訊息變化，只要讀者在排查過程中重點找到相關的dialog以及繫結的tag標籤，可以比較輕鬆獲得呼叫的完整路徑。
雖然筆者在以上的討論中列舉了應該比較特殊的示例，但是足以說明SIP移動性支援中關於SIP信令的處理。讀者可以根據SIPdialog做更深入學習。
參考資料：
https://en.wikipedia.org/wiki/Session_Initiation_Protocol
www.dinstar.cn
www.asterisk.org.cn
https://datatracker.ietf.org/doc/html/rfc3261#section-8
