此圖片以及以下部分圖片均來自于互聯(lián)網(wǎng)資源
自從2005年起, 著名的基于開源的Asterisk被Linksys WRT54G series應用到低端的企業(yè)和中小型企業(yè)的路由器中以后，緊接著在2006年，SIP協(xié)議棧被諾基亞遷移到了基于塞班操作系統(tǒng)的E系列諾基亞終端以后，SIP的移動性才真正開始獲得認可。隨著業(yè)務場景和需求的變化，網(wǎng)絡系統(tǒng)的變化，現(xiàn)在的IPPBX或者電話系統(tǒng)中，SIP終端可以支持很多不同的類型，包括智能手機端APP，物理SIP話機和PC端的SIP軟電話等幾種不同的形態(tài)，但是，無論SIP終端以何種形態(tài)或者存在方式，同一SIP賬號下的多種形態(tài)都需要注冊到SIP代理服務器，通過SIP代理服務器結(jié)合定位服務來實現(xiàn)不同形態(tài)SIP終端的呼叫控制。
1.SIP移動性背景說明
關(guān)于SIP移動性討論的分享，筆者在以前的文章中有過比較詳細的描述，讀者也可以參考歷史文檔來獲得這方面的討論：SIP系列講座-SIP移動性的場景介紹 。此文檔是針對歷史文章的進一步補充，主要特別針對SIP移動場景中針對Dialog，Call-ID進行進一步闡述。
通過以上圖例，我們可以看到，SIP移動性主要針對SIP終端的移動性進行物理上的移動處理支持，SIP移動性支持了用戶終端自由移動，通過SIP代理服務器實現(xiàn)對移動地址的靈活支持，用戶可以使用已注冊的任意一種移動終端接聽電話，因此SIP移動性必須具備以下四個方面的特征：
- SIP通過SIP代理和轉(zhuǎn)發(fā)請求方式支持用戶的移動性，查詢地址后轉(zhuǎn)發(fā)到新的在線狀態(tài)地址。
- SIP用戶端形態(tài)可以是PC端的軟電話，物理SIP話機，手機APP，IOT終端或者其他無線SIP話機。
- 用戶必須注冊其當前的地址到SIP代理服務器。
- 代理服務器根據(jù)其定位地址來決定最終呼叫目的地。
2.SIP分叉呼叫中的并發(fā)呼叫和按序呼叫討論
在以上關(guān)于移動性的討論中，我們注意到一個比較重要的問題。當呼叫方呼叫被呼叫方時，如果SIP代理服務器配置了不同方式的呼叫的話，被呼叫方就會因為移動端支持的不同，可能出現(xiàn)不同被呼叫方具體的結(jié)果。在SIP代理服務器可以支持SIP分叉并行呼叫和SIP按序呼叫兩種方式。關(guān)于SIP fork的細節(jié)，讀者可以參考：分叉呼叫（Fork） 具體處理流程分析，筆者這里僅重新回顧這些細節(jié)以便讀者方便了解后續(xù)的討論。這兩種方式會按照SIP呼叫流程的協(xié)商形式的不同而產(chǎn)生不同的呼叫流程和呼叫結(jié)果，最終會影響被呼叫方呼叫狀態(tài)。
在以上的并行呼叫處理中，SIP代理服務器會同時呼叫兩個SIP終端用戶。如果其中一個首先應答的話（SIP物理話機-鼎信SIP話機（B-1）），代理服務器然后執(zhí)行呼叫方和之間的呼叫流程（180 ring），然后代理服務器會取消另外一個呼叫（B-2的PC端軟電話），最后確認ACK握手，對另外一臺終端執(zhí)行最終ACK處理。然后再執(zhí)行應答終端之間的RTP創(chuàng)建，并且開始雙方RTP流的傳輸。
SIP分叉呼叫中的按序處理方式則和并行呼叫的處理方式有所不同，按序方式中，SIP代理服務器會根據(jù)呼叫順序依次進行呼叫。讀者參考以下SIP分叉處理的按序呼叫流程示意圖，如果其中一臺SIP終端因為其他原因（Busy或者其他狀態(tài)）不能接聽了SIP的話，則返回302，然后確認302以后。代理服務器依次進行下一個SIP終端呼叫，直到其中一個SIP用戶應答了呼叫，然后進行RTP流創(chuàng)建，雙方開始語音傳輸。
在分叉呼叫中，如果同一賬號支持了不同SIP終端實例注冊的話，在分叉呼叫中就會出現(xiàn)不同的連接狀態(tài)。當出現(xiàn)問題用戶，對其進行跟蹤排查是一個比較困難的事情。因此，如何對這些終端進行跟蹤就顯得比較重要。比較幸運的是，所有的SIP終端在不同事務中都根據(jù)不同的SIP頭和其他終端進行了區(qū)別。
我們現(xiàn)在討論一個在分叉呼叫中比較極端的場景，如果呼叫方A呼叫了被呼叫方B，被呼叫方B的兩個終端同時應答了呼叫的話，然后一段時間后，其中一個被呼叫方終端掛斷了呼叫，那么，接下來的SIP呼叫流程會如何處理呢？在進行詳細說明之前，筆者首先對呼叫的兩個重要概念做一點提前說明。這兩個基本概念是call leg和dialog。在早期的SIP協(xié)議規(guī)范RFC2543中，call leg是定義兩個UA之間的SIP信令之間的關(guān)系，在RFC3261中使用dialog替代了call leg的定義。
- Call Leg: Another name for a dialog [31]; no longer used in this
- specification. (RFC3261 section 8)
因此，在后續(xù)介紹中為了避免用戶的困惑，我們這里首先說明。目前，很多用戶為了表達的方便，或者也有部分讀者對dialog比較迷惑，容易對這些功能誤用，希望讀者能夠引起注意。如果需要詳細了解dialog的規(guī)范說明，建議讀者參考RFC3261和RFC2543的規(guī)范。在以下的特殊呼叫場景中，我們可以看到，呼叫方A收到了請求的200 OK響應，一個呼叫產(chǎn)生了兩個call legs或者dialogs。
3.SIP分叉呼叫中dialog創(chuàng)建
根據(jù)以下這個特殊的流程，如果我們?nèi)∠艘苿佣说暮艚械脑�，我們看一下如何處理不同的dialog以及其后續(xù)流程的變化。
在進一步討論之前，我們首先說明一下關(guān)于SIP dialog的定義。一個SIP dialog 是通過Call-ID，F(xiàn)rom中的local/本地tag和To遠端的tag組合定義的�，F(xiàn)在讓我們一步步結(jié)合這個特殊示例進行呼叫分析，說明Call-ID，本地tag，遠端tag以及2以及CSeq的變化。在呼叫方發(fā)起第一個呼叫時，在以下的示例中，已經(jīng)生成了Call-ID，本地的tag，但是沒有生成遠端的tag值。
SIP代理拒絕了第一個呼叫以后，同一呼叫方另外應該呼叫發(fā)起以后，SIP INVITE中出現(xiàn)了稍微不同的消息內(nèi)容。Call-ID相同，但是CSeq 出現(xiàn)了遞增（遞增1），并且因為這是應該新的事務，而且branch也出現(xiàn)了不同。
現(xiàn)在，被呼叫方回復了200 OK以后，dialog創(chuàng)建就已經(jīng)完成，針對此Call-ID和From tag=86aee210添加了本地的tag。
到此為止，一個完整的dialog就生成了。如果是另外一個終端應答了呼叫，其處理流程基本一致，Call-ID，F(xiàn)rom tag 始終是一樣的，To tag會有所不同。因此，分叉呼叫會導致多個dialog，每個dialog是完全唯一，它本身具有其獨特的。dialog創(chuàng)建以后，SIP代理負責綁定了雙方終端具體的呼叫業(yè)務關(guān)系，呼叫方和被呼叫方之間可以繼續(xù)進行其他的業(yè)務操作，例如呼叫保持，呼叫保持重啟，訂閱等等業(yè)務控制。這些業(yè)務都會生成不同的事務，但是，這些事務都屬于此dialog中。
如果讀者想了解更多關(guān)于dialog 和事務的詳解，讀者可以參考歷史文章：
再論SIP呼叫中的Call，Dialog和Transaction。通過以上流程詳解，我們可以看到SIP代理是如何一步步針對SIP的移動性功能支持流程進行處理的。
4.總結(jié)
SIP的移動性支持是來自于網(wǎng)絡發(fā)展的必然，也是現(xiàn)代企業(yè)融合通信的要求。越來越多的員工使用了移動設(shè)備，多點辦公也逐漸成為常態(tài)。通過SIP移動性的支持，各種移動終端可以實現(xiàn)無縫呼叫連接。
筆者首先介紹了關(guān)于SIP移動端的起源，然后介紹了SIP移動性所引起的呼叫不同類型。在SIP代理服務器端，代理服務器可能根據(jù)配置的不同，支持了并發(fā)呼叫或者按序呼叫兩種形態(tài)。SIP代理服務器根據(jù)不同類型的呼叫產(chǎn)生了不同的dialog以及其他tag的變化。在特殊場景中，SIP的dialog根據(jù)呼叫狀態(tài)也發(fā)生了變化。最后，筆者根據(jù)示例介紹了具體的tag，dialog等相關(guān)概念在SIP移動性方面的支持和變化情況，這些變化可能導致SIP移動支持中產(chǎn)生多個dialog。雖然，SIP移動性通過代理服務器以后，產(chǎn)生了多種SIP消息變化，只要讀者在排查過程中重點找到相關(guān)的dialog以及綁定的tag標簽，可以比較輕松獲得呼叫的完整路徑。
雖然筆者在以上的討論中列舉了應該比較特殊的示例，但是足以說明SIP移動性支持中關(guān)于SIP信令的處理。讀者可以根據(jù)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
