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

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

　

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

　

　　在UA發(fā)起注冊時，除了需要知道終端的具體IP地址以外，UA注冊的另外一個目的是獲得其功能支持能力類型。UA注冊時也會通知注冊服務(wù)其終端支持的功能類型，例如是否僅支持語音不支持視頻，是否支持必要的methods，語言等。具體的功能支持完整列表，建議讀者參考RFC3840 規(guī)范。一般讀者關(guān)注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è)內(nèi)網(wǎng)環(huán)境中，其地址不會經(jīng)常發(fā)生變化。但是，如果同一SIP賬號支持了多賬號注冊或者物理話機停用以后，SIP賬號IP地址也可能發(fā)生遷移。用戶使用軟電話或者APP 軟電話登錄了SIP賬號。在很多SIP運營場景中，如果用戶在筆記本電腦或者是手機端的APP發(fā)送了地址變化，此SIP賬號需要重新注冊，通過查詢定位服務(wù)器，重新注冊找到自己新的IP地址。因此，SIP賬號重新注冊也是一個非常普遍的SIP注冊場景。

　　

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

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

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

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

　　OpenSIPS學(xué)習(xí)筆記-ACC模塊/事務(wù)-CDR記錄以及BYE消息丟失-呼叫會話關(guān)閉時延影響計費和配置示例

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

　

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

　　我們在前面的關(guān)于SIP代理服務(wù)器的技術(shù)架提到了SIP代理之間的關(guān)聯(lián)關(guān)系。網(wǎng)絡(luò)上有很多關(guān)于SIP代理服務(wù)器拓?fù)涫纠�，為了方便說明，我們這里再次說明關(guān)于SIP代理服務(wù)器呼叫的流程：

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

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

　　

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

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

　

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

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

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

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

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

　　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