根據(jù)上一個章節(jié)中關于SIP技術架構的討論中，我們可以發(fā)現(xiàn)，SIP注冊需要通過定位服務器來發(fā)現(xiàn)其具體的地址信息。終端注冊需要通過注冊服務和定位查詢服務來找到其終端地址。具體的注冊流程如下圖所示，當SIP終端開始注冊時，它會對注冊服務器發(fā)送當前的地址和定位消息，注冊服務器然后通過定位服務器更新其定位信息。定位服務器來類似于LADP服務或微軟的目錄服務（如 Active Directory）。一旦終端消息更新以后，其他用戶可以通過其“廣播”地址以及綁定的通過解析的IP地址聯(lián)系此終端用戶。這里的IP地址就是具體的物理終端地址或者軟電話地址。當然，大部分情況下，注冊服務還可以要求UA進行認證處理，需要發(fā)送用戶名稱和密碼進行驗證。在后續(xù)章節(jié)我們將重點討論其驗證流程。需要提醒讀者的是，一般讀者經常使用B2BUA的服務器或者開源的媒體服務器，在用戶遇到的SIP注冊中，我們僅看到的是一臺服務器實現(xiàn)注冊，事實上，注冊服務和定位服務是可以互相獨立的，注冊服務器和定位服務器也可以是同一臺服務器。關于注冊綁定和呼叫的一些具體流程，用戶也可以參考歷史文檔：

　　在RFC3261的8.1.1.8和10-1中，官方對contact有非常具體的定義，定位是對其具體IP地址的定位，contact最終是具體通信的地址（specific instance of the UA）。

　

　　除了注冊以外，在呼叫中也同樣需要進行類似的處理。其具體的注冊和定位綁定關系需要數(shù)據(jù)庫進行不斷更新來保證，關于其URL替換處理流程，讀者可以參考：關于SIP Proxy處理中的八大疑問討論

　

　　在UA發(fā)起注冊時，除了需要知道終端的具體IP地址以外，UA注冊的另外一個目的是獲得其功能支持能力類型。UA注冊時也會通知注冊服務其終端支持的功能類型，例如是否僅支持語音不支持視頻，是否支持必要的methods，語言等。具體的功能支持完整列表，建議讀者參考RFC3840 規(guī)范。一般讀者關注contact 部分參數(shù)即可，具體實例如下：

　　REGISTER sip:example.com SIP/2.0

　　From: sip:user@example.com;tag=asd98

　　To: sip:user@example.com

　　Call-ID: hh89as0d-asd88jkk@host.example.com

　　CSeq: 9987 REGISTER

　　Max-Forwards: 70

　　Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds8

　　Contact: <sip:user@host.example.com>;audio;video

　　;actor="msg-taker";automata;mobility="fixed"

　　;methods="INVITE,BYE,OPTIONS,ACK,CANCEL"

　　Content-Length: 0

　　一般物理SIP電話的移動的可能性不大，在一個企業(yè)內網環(huán)境中，其地址不會經常發(fā)生變化。但是，如果同一SIP賬號支持了多賬號注冊或者物理話機停用以后，SIP賬號IP地址也可能發(fā)生遷移。用戶使用軟電話或者APP 軟電話登錄了SIP賬號。在很多SIP運營場景中，如果用戶在筆記本電腦或者是手機端的APP發(fā)送了地址變化，此SIP賬號需要重新注冊，通過查詢定位服務器，重新注冊找到自己新的IP地址。因此，SIP賬號重新注冊也是一個非常普遍的SIP注冊場景。

　　

　　在一般的企業(yè)通信環(huán)境中，用戶都會經常使用B2BUA代理服務器，例如IPPBX/UC這類產品。這些產品可以支持用戶可以實際操作的典型的業(yè)務場景，比如，IVR，隊列，錄音等需求。SIP代理服務器對于一般用戶來說，他本身不支持呼叫的媒體業(yè)務功能，用戶也對SIP代理服務器相對比較陌生。但是，SIP代理服務器在整個SIP網絡中起著非常重要的重要，因此，這里筆者認為有必要再次對其概念做一次梳理。

　　根據(jù)RFC3261-16對代理的定義，我們可以知道，SIP代理服務器其主要工作就是找到SIP請求需要通信的SIP服務器地址，并且前轉請求或者轉發(fā)SIP請求到下一個SIP服務器。它將會解析SIP請求消息，如有必要在轉發(fā)SIP請求之前對SIP請求進行重寫。它可以觸發(fā)請求和響應消息，影響SIP客戶端和服務器端工作流程。從以上概念我們知道，SIP代理服務器其工作方式其實是非常抽象的，越抽象的概念往往在部署使用時越靈活。為了對SIP請求進行各種必要的處理，SIP代理服務器必須按照請求要求做SIP狀態(tài)處理。SIP代理服務器可以設置支持有狀態(tài)代理服務器和無狀態(tài)代理服務器，并且SIP代理服務器可以對呼入SIP請求分叉處理，對SIP的多注冊定位地址進行呼叫。因此，為了完整了解代理服務器的功能，讀者需要掌握四個SIP代理服務器（只有前兩種是RFC3261的定義）基本的概念：

無狀態(tài)代理	Dialog Stateful 代理	Transaction Stateful 代理
均衡負載, 轉發(fā)代理, SIP頭管理,	呼叫計費， CDR 生成， 呼叫時代用戶狀態(tài) 支持所有transaction stateful代理的場景	調度呼叫 呼叫遇忙前轉/無應答前轉 SIP 注冊 Call 分叉處理

　　通過以上定義，我們可以知道，有狀態(tài)代理通過保存的消息可以做更多業(yè)務處理，包括計費，重新發(fā)起呼叫，呼叫二次路由等功能。因為無狀態(tài)代理在生成SIP呼出請求以后，它會丟棄SIP消息，因此，其業(yè)務功能支持非常有限，在目前市場上幾乎看不到SIP無狀態(tài)代理應用。基于以上說明，因為它本身在轉發(fā)以后不會留存任何SIP請求，在性能支持方面，當然無狀態(tài)代理會支持更多SIP呼叫。另外，根據(jù)RFC3261-16-1的說明，因為有狀態(tài)SIP代理服務器可以一直在保存其SIP請求狀態(tài)消息，如有必要，在處理SIP請求的過程中，任何時間，它可以從有狀態(tài)代理模式切換到無狀態(tài)代理SIP服務器狀態(tài)。與其相反的切換流程，在RFC3261并沒有說明，讀者一定要注意。在具體應用場景中，代理服務器可能會從無狀態(tài)代理切換為有狀態(tài)代理，例如在opensips的實現(xiàn)中。更多關于有狀態(tài)SIP代理服務器的深入討論，讀者可以閱讀：

　　OpenSIPS學習筆記-ACC模塊/事務-CDR記錄以及BYE消息丟失-呼叫會話關閉時延影響計費和配置示例

　　在上一個章節(jié)的討論中，我們已經提到，兩個UA是可以直接通過IP直接呼叫而無需經過SIP代理服務器。但是，那樣的操作在實際業(yè)務場景中沒有太多的意義，特別是在比較大的應用場景中，用戶部署大量的SIP終端時，需要各種管理機制來控制其終端以及幫助實現(xiàn)部署和高可靠性的功能。因此，SIP代理服務器是非常必要的。以下圖例說明了SIP代理服務器借助DHCP服務器端來處理一些流程，設置自動部署或者代理出現(xiàn)故障以后，DHCP通過Option實現(xiàn)的其他服務器注冊的流程示例。DHCP服務器可以通過DNS方式或者IP地址格式對終端發(fā)送其可選SIP代理服務器地址。

　

　　如果讀者不了解關于SIP和DHCP的配置細節(jié)的話，基于讀者查閱RFC3361學習關于SIP Option code 120的詳解說明。如果用戶使用IPv6的話，建議用戶參考RFC3319。

　　我們在前面的關于SIP代理服務器的技術架提到了SIP代理之間的關聯(lián)關系。網絡上有很多關于SIP代理服務器拓撲示例，為了方便說明，我們這里再次說明關于SIP代理服務器呼叫的流程：

　　如果讀者想模擬整個完整SIP代理服務器呼叫的流程的話，可以參考筆者的視頻配置說明，安裝兩個OpenSIPS代理服務器，通過UA呼叫來實現(xiàn)模擬場景和SIP流程抓包過程，通過OpenSIPS實現(xiàn)兩個SIP-Proxy完整呼叫測試

　　SIP代理服務器根據(jù)呼叫要求不同，可以實現(xiàn)不同的工作模式。不同工作模式下其SIP消息處理方式也有非常大的不同，并且也影響著SIP服務器的負載和性能。具體來說，SIP代理服務器可以支持兩種工作模式，一種是默認的代理工作模式，另外一種是轉發(fā)代理工作模式。

　　

　　在以上默認SIP代理模式下，正常UA雙方呼叫大概需要經過九個步驟。其具體步驟已在圖例中標識清楚，筆者在這里不再做更多文字說明。在默認的SIP代理模式環(huán)境中，所有的SIP消息都需要通過代理進行處理。

　　在代理轉發(fā)模式的場景中，SIP代理服務器經過查詢定位以后，對呼叫方返回一個contact 地址，呼叫方重新根據(jù)contact地址對呼叫目的地終端重新發(fā)起INVITE請求，通過雙方UA終端之間的交互，然后雙方發(fā)送媒體流數(shù)據(jù)。事實上，這種模式也是一種無狀態(tài)代理的模式。顯然，在高并發(fā)環(huán)境中，代理轉發(fā)模式下的SIP代理服務器承擔了相對比較少的處理流程，其負載也降低很多。通過SIP轉發(fā)代理模式，可以實現(xiàn)高并發(fā)呼叫中SIP的均衡負載的處理。

　

　　通過以上基于SIP轉發(fā)服務器的處理流程，讀者可以看出，在獲得用戶contact以后，轉發(fā)服務器不再介入任何的呼叫流程，兩個UA之間進行協(xié)商處理，并且最終實現(xiàn)媒體流通信。因此，SIP 轉發(fā)服務器不會承擔太多的處理流程，也無需太多的系統(tǒng)資源。如果讀者對SIP 轉發(fā)服務器有興趣的話，可以參考RFC3261-8.3章節(jié)做進一步了解，這里不再做太多細節(jié)說明。

　　當然，筆者介紹的兩種代理模式流程是基于一般正常呼叫設置環(huán)境，如果有其他配置不成功設置，或者終端之間協(xié)商有問題的話，例如，編碼不支持，不支持轉發(fā)設置等，呼叫仍然需要更多流程來協(xié)助處理。

　　在本章節(jié)的介紹中，筆者主要介紹了SIP代理的基本構成，使用SIP代理服務器的原因，默認SIP代理服務器的九大步驟，SIP轉發(fā)代理服務器的九大步驟的工作模式以及狀態(tài)代理的各種模式和應用場景。在這些內容中，筆者同時引用了歷史文檔中一些非常細節(jié)具體的配置示例來協(xié)助讀者了解SIP代理的操作流程，例如兩個OpenSIPS代理的互相呼叫的示例。

　　在下一個章節(jié)，筆者將繼續(xù)介紹關于SIP定位服務器的知識，SIP定位服務器的查詢流程以及SIP定位服務器資源支持等內容，還有SIP UA終端配置方面的細節(jié)。

　　雖然筆者介紹了幾個關于SIP代理服務器的具體細節(jié)，但是，因為SIP代理服務器應用場景非常靈活，為了讀者能夠完全掌握其工作場景，筆者仍然建議讀者自己不斷上手實踐，反復練習，同時結合RFC3261的細節(jié)說明做更深入了解。有了這些基礎知識，讀者才能在后續(xù)的介紹中更好消化SIP技術體系的更多內容。

　　https://datatracker.ietf.org/doc/html/rfc3840

　　www.asterisk.org.cn

　　www.dinstar.cn

　　https://www.rfc-editor.org/rfc/rfc3361.txt

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