在前面的章節(jié)中，我們一直在介紹呼叫的同時，也會提到SIP定位服務。沒有SIP定位服務，SIP呼叫不可能完成。但是，SIP定位服務或者服務器通常沒有出現(xiàn)在我們一般的用戶配置的物理邏輯實體中，其存在形態(tài)相對比較抽象。在RFC3261的規(guī)范中，SIP的功能之一就是用戶定位，通過用戶定位來決定通信的系統(tǒng)終端。另外，在RFC3261中定義了支持用戶定位的定位服務，在規(guī)范中定義了定位服務是SIP轉發(fā)服務或者SIP代理用來獲取被呼叫方可能的定位信息的服務。它包含一個各種AOR和Contact綁定關系信息列表，其綁定更新也可能經(jīng)常更新，添加或者刪除。具體關于定位服務的完整處理流程，讀者可以參考筆者歷史文檔：深入理解SIP服務器的注冊和定位服務流程

　　筆者特別強調，在一般的企業(yè)網(wǎng)絡中，我們也不會看到單獨的定位服務器來提供定位服務，它和其他的SIP代理，例如注冊服務構成一個一體的處理單元來提高定位服務。前面我們的很多圖例已經(jīng)說明，讀者可以參考。在具體的定位服務處理中，定位服務器通過定位數(shù)據(jù)庫結合注冊服務來實現(xiàn)定位信息更新或者管理。

　　在以下示例中，SIP定位服務和注冊服務部署在一體環(huán)境中，用戶從發(fā)起呼叫到查詢定位大概經(jīng)過六個核心的步驟。定位服務器本身部署了一個數(shù)據(jù)庫，此數(shù)據(jù)庫用來存儲SIP UA的位置信息，SIP registrar(注冊服務)負責處理來自于SIP UA的register和re-register 消息，并且不斷更新其位置信息。SIP代理服務器將通過UA發(fā)起的SIP INVITE消息中的目的地SIP URL，找到當前目的地的位置信息。一旦，其呼叫目的地地址應答了這個呼叫，SIP代理將前轉這個INVITE請求到目的地地址，然后通知呼叫方其呼叫處于“trying” 狀態(tài)。

　　

　　SIP定位服務的資源可以來自于不同的用戶存儲資源。一些用戶可能使用自己的本地服務器來存儲定位服務，一些比較大的客戶可能通過LDAP協(xié)議使用微軟的AD（Active Directory），或者通過A記錄，SRV，NAPTR使用DNS服務器來獲取SIP定位服務的用戶數(shù)據(jù)。關于SIP定位服務，RFC3263規(guī)范有非常詳細的說明，讀者可以查閱參考資料鏈接做進一步了解。

　　

　　當然，針對以上幾種關于定位服務器部署，目前很多用戶根據(jù)自己的實際業(yè)務需求做相應調整。隨著用戶數(shù)量不斷增加，用戶場景不斷遷移，終端不斷切換，對其注冊資源和定位服務有更大的挑戰(zhàn)。注冊查詢時間延長，意味著呼叫時間就會延長，最終直接影響其他的定時器時間等問題。讀者如果需要了解SIP網(wǎng)絡性能指標的話，可以參考筆者歷史文檔：

　　完整RFC6076-端對端SIP網(wǎng)絡九大性能評價指標（KPI）概論和時延產(chǎn)生其他因素的相關性討論

　　在本地安裝的數(shù)據(jù)庫服務中，用戶也需要考慮各種數(shù)據(jù)庫訪問和支持包之間的優(yōu)化關系。例如，很多用戶經(jīng)常使用的OpenSIPS，MYSQL，和GCC等。以下示例是

　　C. P. Wright和其他研究人員在2010年在IBM發(fā)布的一篇關于SIP服務器性能的研究論文-SIP server performance on multicore systems

　　在這篇論文中，研究人員針對系統(tǒng)底層基礎應用服務器的性能進行了對比測試，也包括了多核CPU，MYSQL數(shù)據(jù)庫，OPENSER，GC等安裝支持。雖然，我們目前使用的平臺和部署方式發(fā)生了很大變化，但是，其性能瓶頸和以前有非常多的相似之處，我們仍然需要考慮數(shù)據(jù)庫連接的性能，OpenSIPS的性能，支持包的優(yōu)化等問題。另外，在具體的OpenSIPS環(huán)境中，opensips官方使用了 usrloc 模塊對User location test，隨著用戶增加，使用不同的mysql Prepared Statements命令取得了非常不同的性能。

　　

　　目前看，用戶本地安裝的服務器和DNS服務器相對符合現(xiàn)在用戶的需求以及未來的擴展，微軟的AD則相對比較封閉，不利于用戶充分擴展其服務。特別是近幾年，SIP網(wǎng)絡部署都已經(jīng)在全球部署，通過DNS定位的需求相對比較大，本地部署則維持正常需求水平。

　　在本章節(jié)中，筆者通過以下示例結合前面的章節(jié)來更加細致地介紹一下如何通過DNS查詢以后實現(xiàn)的呼叫流程。

　

　　在以上圖例中，首先eric通過SIP終端呼叫方對自己的代理服務器發(fā)送一個呼叫INVITE請求，在SIP服務器進行不同需求處理，注意，這里的SIP服務器（包括了注冊服務，定位服務和轉發(fā)服務代理）。SIP代理服務器查詢DNS找到其呼叫目的地地址，域名是freepbx.cn。DNS會對不同的DNS服務器發(fā)送DNS查詢請求。DNS服務器通過DNS查詢以后，結合SRV，NAPTR地址，DNS服務器發(fā)現(xiàn) _sip._udp.freepbx.cn綁定的是一個具體的IP地址（IP address=11.10.9.8，這里是假設地址）。然后，DNS返回地址11.10.9.8，然后SIP服務器中的SIP代理轉發(fā)這個目的地地址到另外一個SIP代理服務器地址，然后SIP代理服務器呼叫其UA終端。這里，我們假設SIP的DNS查詢服務僅使用了一次查詢就獲得了地址。在實際DNS查詢中可能還要查詢更多的DNS服務以及下一跳服務器地址等比較復雜的查詢。當然，在DNS查詢處理中，查詢服務還要涉及ENUM，具體的規(guī)范和協(xié)議包括RFC6116等規(guī)范，我們將在后續(xù)的系列講座中會對ENUM進行比較詳細說明，這里不再做過多說明。

　　在本章節(jié)中，筆者介紹了關于定位服務的基本流程和六大步驟，然后介紹了關于定位服務的資源存儲問題以及資源池的部署。針對SIP配合DNS查詢服務做了比較深入的討論。在各種SIP定位部署環(huán)境中，因為業(yè)務場景不同，一些用戶使用的資源服務也不同。筆者重點介紹了比較常用的DNS查詢方式。但是，為了實現(xiàn)DNS查詢的穩(wěn)定性，用戶同樣需要考慮很多方面的問題，例如DNS服務器的穩(wěn)定性，終端的兼容性等。

　　在下一個章節(jié)中，筆者將進一步介紹關于SIP 客戶端和SIP消息方面的內容。