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

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

　

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

　

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

　　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網絡中起著非常重要的重要，因此，這里筆者認為有必要再次對其概念做一次梳理。

　　根據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呼叫。另外，根據RFC3261-16-1的說明，因為有狀態(tài)SIP代理服務器可以一直在保存其SIP請求狀態(tài)消息，如有必要，在處理SIP請求的過程中，任何時間，它可以從有狀態(tài)代理模式切換到無狀態(tài)代理SIP服務器狀態(tài)。與其相反的切換流程，在RFC3261并沒有說明，讀者一定要注意。在具體應用場景中，代理服務器可能會從無狀態(tài)代理切換為有狀態(tài)代理，例如在opensips的實現中。更多關于有狀態(tài)SIP代理服務器的深入討論，讀者可以閱讀：

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

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

　

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

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

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

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

　　

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

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

　

　　通過以上基于SIP轉發(fā)服務器的處理流程，讀者可以看出，在獲得用戶contact以后，轉發(fā)服務器不再介入任何的呼叫流程，兩個UA之間進行協(xié)商處理，并且最終實現媒體流通信。因此，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