這種使用場景是最簡單的場景，不會使用在實際的復雜業(yè)務場景中。因為，在實際的業(yè)務場景中，可能多種SIP終端部署在完全不同的場景，其位置和其他屬性支持能力也可能不同。因此，如何實現(xiàn)雙方的呼叫看似是一個非常簡單的問題，但是如果讀者想真正了解其相關的概念和背后處理機制的話，可能需要比較深入的研究學習。這些涉及的領域和概念包括SIP服務器的必要性，AOR和Contact的概念和相互關系，SIP的注冊服務處理流程，SIP的定位服務的處理流程，注冊超時處理機制，SIP注冊請求中的主要參數(shù)使用方式，關于SIP第三方注冊，AOR和Contacts的添加方式，多個Contacts呼叫對SIP定位服務的影響�，F(xiàn)在，我們針對這些內(nèi)容逐一加以討論。

　　在討論下面的所有內(nèi)容之前，筆者首先說明一個和哲學相關的話題。筆者一直非常感嘆這個原理的博大精深。事實上，在我們討論的SIP協(xié)議和各種控制機制中，我們都有意無意地在應用這個哲學原理，那就是奧卡姆剃刀原理（和老子的某些思想非常相似，熟悉老子的朋友可以閱讀老子這方面的經(jīng)典）。今天，我們在后續(xù)的討論中，讀者可能可以感受到的每個流程設計的必要性和極簡原則。否則，處理機制就會給其他的流程帶來負載和成本開銷，例如，我們后續(xù)可能涉及到ACK發(fā)送和100 Trying的討論。

　　這個原理稱為“如無必要，勿增實體”，即“簡單有效原理”。正如他在《箴言書注》2卷15題說“切勿浪費較多東西去做，用較少的東西，同樣可以做好的事情。”

　　在前面的介紹中，筆者介紹了SIP的簡單的點對點呼叫流程，點對點呼叫必須獲悉雙方的IP地址和必須具有相同的表面。用戶需要手動輸入對端的IP地址來執(zhí)行呼叫。因此，點對點的呼叫方式不可能應用在復雜的IP通信領域中。另外，IP通信和傳統(tǒng)的PSTN的呼叫業(yè)務相比，PSTN交換機更多是以呼叫業(yè)務本身為中心的處理能力，而SIP服務器則側重于IP網(wǎng)絡的應用和服務能力支撐。所以為了滿足復雜環(huán)境的要求，實現(xiàn)多種融合通信/IP業(yè)務的需求，必須有一個SIP服務器來幫助處理終端的要求，監(jiān)控終端的狀態(tài)，實現(xiàn)SIP會話管理，并且SIP服務器端需要支持多種復雜的功能需求。根據(jù)RFC3261的規(guī)范和其拓展協(xié)議支持來看，SIP服務器需要支持示例中的說描述的所有功能。

　　這里說明一下，比較規(guī)范的說法，我們通常所說的SIP服務器，應該包括了以上所有功能。一般情況下，我們說的SIP服務器可能包括注冊，定位，IPPBX等應用服務。幾個服務可能完全封裝成了一臺服務器也可能是通過幾臺服務器獨立實現(xiàn)。很多廠家的SIP服務器是否支持以上所有功能，完全取決于廠家產(chǎn)品本身的支持能力。在實際的應用環(huán)境中，我們可能通常說的也僅是一個IPPBX或者簡單的應用服務。如果我們從一個非常龐大的網(wǎng)絡應用環(huán)境中看的話，整個IP網(wǎng)絡支持了多種不同的SIP服務器應用，并且分布在不同的地方。網(wǎng)絡拓撲實現(xiàn)方式包括了，最底層模擬終端部署，SIP 電話分別通過電路交換和SIP中繼對接到SBC的訪問控制層，然后和SIP 服務器對接，實現(xiàn)SIP 會話的管理。SIP服務器然后再和具體的SIP應用服務器對接互通，最后通過SIP服務器路由到最終終端。當然，以上說明是說明一個垂直執(zhí)行的流程，很多情況下，終端之間也可能直接通過本地其他的SIP服務器直接橫向互通。這完全取決于業(yè)務處理層面的需求邏輯。

　　以上是一個完整的連接圖例。在企業(yè)通信網(wǎng)絡中，一般的終端都部署在內(nèi)網(wǎng)呼叫中。

　　在會話管理中，SIP服務器就起到了非常重要的作用，例如，我們接下來要介紹的SIP注冊服務和定位服務。現(xiàn)在，我們介紹和終端關系最緊密的概念AOR和Contact。

　　在我們討論注冊服務和定位服務之前，我們首先介紹一下讀者和SIP用戶經(jīng)常迷惑的兩個概念-AOR和Contact。我們通常所說的SIP地址中包括了AOR和Contact兩種類型的地址。AOR的全稱是Address-of-Record。在RFC3261中，AOR是這樣定義的：

　　簡單來說，兩種地址的格式也是完全不同的。AOR地址格式為SIP:user@domain（例如，SIP：james@hiastar.com）， 而Contact地址格式為Contact: james 。大家可能注意到了，這個Contact是一個具體的IP地址，一些情況下也可能是一個FQDN地址。

　　下面，讓我們詳細說明一下兩種地址的不同。首先，如果討論AOR地址的話，我們可以使用我們互聯(lián)網(wǎng)的域名和IP地址的關系來說明。大家知道，一般用戶訪問網(wǎng)站使用的是公司的域名，而不是公司網(wǎng)站的IP地址。域名需要通過解析以后，才能獲得相應的IP地址。因此，AOR簡單來說，就是一個帶域名的用戶帳戶，相當于一個用戶的公網(wǎng)地址，它具有唯一性，而Contact的具體的聯(lián)系方式是這個終端的IP地址。但是，讀者，一定要明白，SIP終端的IP地址可能是臨時性的，終端也可能是完全移動的，而且支持了不同的物理形式，這里就需要SIP服務器做定位處理，和其AOR記錄地址匹配。實際上，用戶需要首先呼叫AOR地址，而不是Contact地址。讀者需要記住AOR和Contact的區(qū)別：

　　一個AOR地址可以對應多個Contact地址（一個SIP終端可以支持多種形式的物理終端）。

　　當然，為了讓用戶自己獲悉地方的地址和呼叫，首先，雙方SIP終端必須注冊到SIP服務器，SIP終端呼叫對方之前，需要先通過SIP注冊服務器進行狀態(tài)檢查，然后才能進行呼叫，路由管理和會話處理。接下來，我們介紹如何實現(xiàn)SIP注冊服務。

　　按照上面的介紹，為了實現(xiàn)雙方的呼叫，雙方的SIP終端首先需要注冊到一個SIP注冊服務器來完成注冊服務（Registrar）。注冊服務本身是一個流程中的角色，動作和功能，其概念比較抽象。在實際的工作流程中，它需要借助注冊（Registry, 具體的數(shù)據(jù)庫等存儲服務對象）服務器來完成。關于英文中對注冊的定義，讀者需要自己掌握，筆者這里不再累述。

　　在Registry的模塊中，通過數(shù)據(jù)庫來存儲AOR地址，Contact地址，Q 值和超時設置。關于Q值的作用和超時設置的機制，我們會在下面的章節(jié)中做詳細介紹。這里，筆者僅說明AOR和Contact地址。

　　以上示例介紹了一個簡單的注冊服務的流程�，F(xiàn)在，讓我們看看注冊服務是如何實現(xiàn)的。SIP終端用戶首先對SIP進行注冊服務，同時對注冊服務器發(fā)送AOR地址和Contact地址。注冊服務器判斷其域名是否是本SIP服務器支持的域名，如果是支持的域名，則會存儲其AOR地址和Contact的具體的物理地址，并且此地址在一定超時設置內(nèi)有效。這樣，SIP注冊服務器就獲悉了SIP終端的AOR地址和Contact地址，它就會知道，如果其他SIP 終端呼叫時，SIP注冊服務器知道如何路由這個呼叫，而且可以根據(jù)AOR地址解析到具體的SIP物理地址。

　　如果多臺SIP終端對注冊服務器注冊的話，注冊服務器會存儲所有的AOR地址和其相應的Contact地址到注冊數(shù)據(jù)庫中保存。

　　我們上面提到了注冊流程，事實上，如果用戶雙方需要執(zhí)行呼叫流程的話，呼叫流程還需要另外一半服務來協(xié)助完成呼叫。另外一半流程就是SIP服務中的定位服務（Location）。SIP中的定位服務和注冊服務一樣，它的功能概念仍然具有一定的抽象性。簡單來說，它扮演一個服務角色，執(zhí)行具體的流程，還執(zhí)行某些功能。定位服務器可以獨立存在，也可以和注冊服務一起工作，存在于SIP服務器中。在一般比較小型的企業(yè)應用環(huán)境中，一般的定位服務和注冊服務都部署在同一服務器。以下是一個簡單的定位服務的示例圖：

　　現(xiàn)在，讓我們看看SIP服務中的定位服務是如何工作的。如果雙方進行呼叫的話，為了實現(xiàn)呼叫，呼叫方首先是執(zhí)行一個定位服務，然后，定位服務器對被呼叫方進行查詢，查詢被呼叫方是否注冊等狀態(tài)，AOR地址等過程，最后才能實現(xiàn)真正的呼叫。這里，為了簡單說明定位服務的功能流程，筆者這里介紹的僅是一個簡單的定位服務的處理流程，沒有涉及其他的服務支持，比如重轉發(fā)服務等。

　　根據(jù)以上圖例介紹，這里的定位服務處理流程中，我們的定位服務，代理服務器和注冊服務器都部署在同一服務器中。具體的定位服務大概經(jīng)過以下幾個步驟：

　　經(jīng)過以上五個步驟，一個完整的定位服務就完成了。當然，筆者沒有涉及具體的定位服務，注冊服務和代理之間的服務協(xié)商機制。每個廠家和業(yè)務需求的處理方式可能有所不同，如果用戶需要做進一步的分析，可以查詢廠家的技術文檔。接下來，問題來了，如果查詢時，發(fā)現(xiàn)沒有可用的Contacts怎么辦？這就需要借助超時設置來監(jiān)控終端注冊狀態(tài)。

　　大家可能在剛才的的注冊服務中發(fā)現(xiàn)，注冊服務器需要對Contact的狀態(tài)進行查詢，確認其狀態(tài)可用，表示其是在正常的注冊狀態(tài)。注冊狀態(tài)控制的主要參數(shù)就是Expires。這個參數(shù)控制著終端注冊的狀態(tài)情況。這里，我們對超時設置的幾個要素和大家做一個介紹。

　　大家知道，一般默認的注冊超時設置是3600秒。用戶終端注冊時攜帶了這個設置，這表示此用戶在3600秒鐘內(nèi)的狀態(tài)是存活的。但是，這里讀者一定要注意，即使用戶設置的是3600秒，如果終端不能在超時范圍內(nèi)不停對注冊服務器發(fā)送超時刷新的消息，注冊服務器可能會認為此終端已經(jīng)不再注冊狀態(tài)。因為，在某個時間段，可能其他SIP終端需要對此終端進行呼叫，如果不能不停刷新定時器超時設置，注冊服務器可能不能得到準確的狀態(tài)信息，這樣可能導致呼叫失敗。因此，終端會不斷對注冊服務器進行消息發(fā)送，保持這個存活狀態(tài)。例如，現(xiàn)在，SIP終端開始對注冊服務器進行注冊，一個小時后，超時后，注冊信息從注冊服務器移除。注冊時，默認超時設置為3600秒：

　　一小時超時后，注冊服務器刪除注冊記錄：

　　在開始時，筆者已經(jīng)提到，在正常情況下，任意分機，任意時間段電話之間的互相呼叫是非常正常的需求。如果在某一時間段內(nèi)，某些分機沒有處于正常的注冊狀態(tài)，雙方發(fā)起的呼叫就會失敗。終端如何讓注冊服務器端能夠準確獲悉SIP終端的目前的注冊狀態(tài)呢？系統(tǒng)只能讓SIP終端自己在默認傳輸時間內(nèi)不斷對注冊服務器發(fā)起重新注冊的消息。這也是我們通常所說的注冊周期的概念。終端需要在一個特定的周期內(nèi)不斷按照設定的間隔周期重新注冊，以便對注冊服務器保持一個存活狀態(tài)。當然，這個周期的設置取決于終端設置，以及服務器端的設置，因為，周期長短會影響服務器端的執(zhí)行性能，會直接影響服務器的執(zhí)行狀態(tài)。另外，讀者需要注意，每重新注冊一次，QSeg值會增加一次。

　　如果終端想退出注冊和關機的話，那么，終端退出注冊是怎么處理的？一些讀者可能簡單認為，退出注冊是不是直接對注冊服務器發(fā)送了一個BYE消息？這是一種錯誤的想當然的想法。實際上，當SIP終端退出注冊時，它仍然對SIP服務器發(fā)送一個注冊請求，只是這次的請求攜帶了一個超時設置為零的設置，而不是3600。 以下是一個注冊和退出注冊的消息示例：

　　用戶可能點擊終端界面的退出注冊或者關機，終端會直接對注冊服務器發(fā)送一個注冊消息，但是攜帶Expires=0， 通知注冊服務器刪除注冊記錄信息。注冊服務器收到的定時器超時設置的參數(shù)設置后，刪除所有相關記錄。

　　到本章節(jié)為止，估計很多讀者可能對注冊請求頭的一些字段非常迷惑。很多技術文檔也是完全根據(jù)標準的技術術語來解釋這些注冊請求中頭的用法，所以很多用戶對某些參數(shù)的理解始終沒有完全領會。我們嘗試使用英文書信的格式來解釋請求的各種消息參數(shù)和使用說明，這種方式應該是比較貼切的表達方式，用戶可以非常清楚地理解SIP注冊時主要的幾個頭的概念和其相應的關系。

　　如果我們把SIP注冊邀請信對應到SIP注冊請求中的參數(shù)中，筆者就會完全理解每個參數(shù)的真正含義和概念。再次提醒，這里的注冊中的To 和From很多情況下是同一用戶，但是也可能是其他用戶。

　　以上圖例可以完整解釋為這樣一個流程。首先，終端用戶提供帶域名的賬號發(fā)起注冊請求。注冊服務需要通過注冊服務器進行注冊，然后通知注冊服務器，這里有一個用戶（To tag的），如果有和這個用戶相關的呼入，請注冊服務器路由映射到具體的Contact 地址。這里，一般來說，這個Contact地址是具體的一個物理終端或軟電話終端帶了5060端口。終端同時提醒注冊服務，保持超時設置為3600秒。最后，落款是來自于From tag 地址的注冊請求。另外，終端通知注冊服務器，如果有返回確認消息的話（例如 200 OK），請返回到這個上面的Via地址。

　　前面我們介紹的場景是注冊方自己注冊自己所屬的參數(shù)和相關信息（一般稱之為first-party registration）。但是，在某些情況下，可能用戶SIP終端可以通過其他第三方用戶（third-party registration）對其進行注冊。注冊時，一些頭標簽參數(shù)發(fā)生變化。為了回答這個問題，大家可以看看以下這個圖例：

　　比較復雜的第三方注冊中帶了GRUU來做地址查詢：

　　上面的示例中，大家是否注意到 To header和From header的用戶名稱是不一樣的。實際上，這種情況也是允許的，這就是通常所說的第三方注冊方式（rfc3261）。

　　這里，用戶必須了解To tag的作用和From的作用。To tag是表示的真正的用戶注冊的地址，而from tag則表示是正在請求注冊的地址。簡單來說，to tag表示的是第一用戶的地址，而from tag表示的是正在要求注冊的第三方用戶的地址，可能和To tag用戶是完全不同的另外一個用戶。因此，讀者一定要對第三方注冊有一個正確的理解。以下是筆者對SIP第三方注冊關于To和From tag使用的幾個區(qū)別要點：

　　To和Contact 頭是已經(jīng)注冊的用戶的消息內(nèi)容，其地址來自于已注冊的用戶。

　　From和Via頭是正在要求注冊的第三方的消息地址，來自于第三方用戶，不是已注冊用戶本身的地址。

　　很多情況下，企業(yè)辦公環(huán)境中，員工可能使用多個分機來接聽公司內(nèi)部電話，以便更好地適應企業(yè)通信移動性的要求。一個分機電話可能支持桌面軟電話，可能是一個SIP物理座機電話，也可能是一個手機app。所以，其分機的網(wǎng)絡也可能隨著用戶的移動也經(jīng)常發(fā)生變化。有時，員工可能在辦公室，有時可能在咖啡館見客戶，有時可能在其他的地方。因此，員工分機的幾個IP地址需要和其AOR地址進行綁定。一個AOR地址可以支持多個不同的IP地址。

　　從上面的圖例中，我們可以看到，如果外部呼叫呼入到這個AOR地址后，注冊服務器配合代理服務器就呼叫所有的Contact地址。讀者需要注意，這里沒有配置Q值，實際上，呼入以后，服務器端會通過不同的Q值的優(yōu)先級進行呼叫處理。這里，我們忽略了Q值，在后續(xù)的講座中，我們會介紹呼入以后，根據(jù)Q值優(yōu)先級進行多個Contact地址查詢的處理機制。用戶也可以參考筆者以前的文章了解整個機制的處理流程。

　　可能讀者已經(jīng)注意到了，既然一個AOR可以支持多個Contact地址，那這些Contact地址是如何加入到Contact列表中的呢？ 事實上，在SIP協(xié)議中，關于Contact地址的添加，SIP協(xié)議支持了三種添加Contacts的方式：

　　用戶手動自己添加，用戶可以輸入多個Contact地址來綁定AOR。用戶自己手動注冊每個終端設備到注冊服務器。當然，手動添加的方式當然需要耗費人工資源。

　　這里提醒讀者，在以上的示例中，我們僅說明一個簡單的添加場景。但是，如果涉及了一些IPPBX的時候，特別是面對大型IPPBX的解決方案時，完全靠IPPBX本身的注冊定位機制來處理注冊和定位服務可能顯得有一點吃力。用戶可能涉及了定位服務器和DNS的問題。關于這方面的內(nèi)容，讀者可以查閱RFC3263和RFC5947來做進一步了解。

　　大家已經(jīng)注意到了，一個AOR 地址可以支持多個Contacts地址，但是支持了多個Contacts地址的話，定位處理的機制會直接影響到呼叫的流程。我們可以想象一下，其他用戶如果呼叫這個用戶時，有幾個疑問需要大家考慮：

　　事實上，以上疑問都是通過注冊和定位服務來處理的。其實，在處理多個Contacts呼叫時，定位服務通過兩種不同的模式來處理呼叫：并行呼叫處理（parallel forking）和按序依次呼叫處理模式（Sequential forking）。筆者在以前的討論中討論過關于呼叫查詢的問題，并且介紹了每個請求處理的具體流程，讀者可以查閱具體流程。今天，我們從另外一個角度再次對定位服務的處理機制進行討論。

　　首先，我們介紹一下什么是按序依次呼叫處理模式（Sequential forking）。按序呼叫處理的流程是，呼叫方對另外一方進行呼叫，因為被呼叫方帶有多個Contacts地址，因此，首先，呼叫方需要對定位服務進行查詢，定位服務器按照Q值優(yōu)先級順序進行查詢，Q（0.1-1.0之間）值高的具有高優(yōu)先級。定位服務器首先對其contact地址進行呼叫。如果Q值最高的沒有接聽，則繼續(xù)對次級的Q值進行查詢呼叫，依此類推。直到找到一個接聽呼叫的終端SIP。以下示例是一個帶Q值的Contact格式：

　　這個Q值在用戶注冊時就已經(jīng)設定，再次說明，Q值最高的具有最高的被呼叫優(yōu)先級，另外，讀者一定要注意，Q值總是小數(shù)。

　　根據(jù)Q值的說明，以下示例是一個按續(xù)呼叫的處理流程。定位服務器根據(jù)Q值依次呼叫和處理拆線。

　　這里，筆者需要具體說明，如果通過Q值查詢以后，對其Contact進行了呼叫，呼叫因為各種原因導致呼叫失�。ɡ�如，486 忙狀態(tài)），則定位服務器進行對其終端返回其他響應消息，直到ACK處理完成。然后，接下來，繼續(xù)根據(jù)Q值再次進行查詢，找到對應的Contact地址，然后對其Contact地址進行INVITE呼叫請求。如果找到一個接聽呼叫的終端，則此終端對定位服務器返回200 OK，然后定位服務器對呼叫方返回200 OK。最后，呼叫方和被呼叫方通過保存的route set 獲悉Contact地址后，雙方直接互相發(fā)送ACK消息（不經(jīng)過定位服務器）。

　　另外一種呼叫模式是并行呼叫處理（parallel forking）呼叫處理的機制，它的處理機制則相對比較簡單。如果呼叫方對定位服務器發(fā)起一個INVITE呼叫以后，定位服務器會對所有Contacts地址同時發(fā)起INVITE呼叫。

　　最快接聽的終端對定位服務器返回200 OK，然后，定位服務器對呼叫方返回200 OK和雙方直接發(fā)送ACK，而不經(jīng)過定位服務器，雙方呼叫正式確認。接下來，定位服務器則同時對其他沒有接聽呼叫的終端發(fā)送Cancel消息。這里需要特別注意，根據(jù)Cancel的消息處理流程，定位服務器會同時對其他終端發(fā)送Cancel消息，200 OK，487，和ACK。

　　根據(jù)Cancel的流程處理機制（對應了奧卡姆剃刀原理-如無必要，勿增實體），每個沒有接聽的終端會繼續(xù)對定位服務器返回200 OK，緊接著，每個沒有接聽呼叫的終端繼續(xù)對定位服務器發(fā)送487 請求結束的消息，最后，定位服務器收到這些終端發(fā)送到487 以后，再次同時對這些Contacts分別發(fā)送最終ACK消息。至此，定位服務器對整個失敗呼叫的拆線流程結束。

　　在實際生產(chǎn)環(huán)境中，很多終端可能沒有設置Q值或者終端設置為等值，所以，最終的按序處理呼叫可能出現(xiàn)其他的接聽錯誤，這里需要配合定位服務器的設置進行檢查。因此，筆者提醒讀者，如果遇到類似問題時，檢查終端設置和Q值設置。另外，并行呼叫接聽的終端具有隨意性，很多因素影響接聽順序，例如網(wǎng)絡原因或基于APP的軟電話的推送服務遲延。

　　在本討論中，我們主要討論的環(huán)境是基于SIP服務器支持的環(huán)境，而不是前面討論過的點對點呼叫環(huán)境。因此，在討論中，我們需要借助SIP服務器來實現(xiàn)終端管理，終端呼叫協(xié)商，會話處理和呼叫流程模式的處理等比較復雜的概念。首先，筆者介紹了SIP服務器的必要性和其定義規(guī)范。根據(jù)終端的概念，我們介紹了非常重要的兩個概念AOR和Contact的區(qū)別。然后，筆者介紹了SIP注冊的流程，配合SIP注冊服務，筆者也介紹了SIP定位服務的處理。

　　另外，筆者針對注冊超時的問題，也幫助讀者分析了超時設置的必要性和處理方式。在呼叫中，因為需要處理多個Contact地址，所以也花費一定的時間介紹了SIP注冊時所攜帶的Q值。這個Q值決定了對Contact呼叫的優(yōu)先級。針對很多讀者比較迷惑的SIP頭字段，筆者以信件的方式把這些主要的概念做了充分介紹。最后，筆者討論了定位服務對SIP多Contacts呼叫機制-并行呼叫和按序依次呼叫。

　　因為篇幅的關系，筆者這里沒有花費更多時間去討論其他的關于SIP注冊和定位的相關的問題，例如Branch ID來確認who是who的問題，代理服務器的處理所涉及的問題和經(jīng)過多Via路由以后的Via添加和刪除的流程。我們將會在后續(xù)的文章中繼續(xù)討論。

　　https://voipmagazine.wordpress.com/2014/09/19/sip-registration-process/

　　https://www.ietf.org/rfc/rfc3261.txt

　　https://www.test-king.com/guide-642-437-sip.htm

　　http://www.openmobilealliance.org/release/LOCSIP/V1_0-20081223-C/OMA-AD-LOCSIP-V1_0-20081223-C.pdf

　　http://www.voipdictionary.com/IPTelephonyDictionary-Location-Server-LS-Definition.html

　　https://tools.ietf.org/html/rfc3263

　　https://tools.ietf.org/html/rfc5947