建構於NAT/防火牆環境下網路電話系統設計之研究
56
0
0
全文
(2)
(3) 建構於 NAT/防火牆環境下網路電話系統設計之研究. 指導教授：梁明正 博士 吳國棟 博士 國立高雄大學電機工程學系研究所 學生：李宗哲 國立高雄大學電機工程所. 摘要 以 SIP 為基礎的網路電話(VoIP)系統，對於封包語音傳輸已成為最受歡迎的 應用之ㄧ。在許多應用環境下，公司為了整合特殊服務，將伺服器放置於 NAT 或防火牆下可使伺服器受到保護，然而伺服器放置在 NAT 或防火牆後時，將發 生許多額外的問題，尤其當用戶處於 NAT 或防火牆外時，用戶與伺服器之間的 通訊將變的難以實行，對於活動於外部網路的使用者而言，伺服器將難以查覺使 用者資訊的變更。目前用於解決 NAT 或防火牆解決方案如 ALG，STUN，TURN 及 SBC，然而這些方式必須配合其他額外伺服器、對於使用者端增加額外協定 甚至修改 NAT/防火牆才能達到穿越之目的。有鑑於此本研究主要針對伺服器位 於 NAT/防火牆衍生之問題，提出簡易傳輸存取(Simple Transmission Access，STA) 系統架構，透過 STA 架構使用者不需增加其他額外協定且無需更改現有 NAT/ 防火牆設定下建立 SIP 會議。 關鍵詞：VoIP、會議初始協定、NAT、防火牆. i.
(4) A VoIP System with Server behind a NAT/Firewall. Advisor(s): Dr. Ming-Cheng Liang Dr. Kou-Tan Wu Institute of Electronic Engineering National University of Kaohsiung. Student: Chun-Zer Lee Institute of Electronic Engineering National University of Kaohsiung. Abstract. The SIP based VoIP system has become one of the most popular system for packet voice transmission. In many applications, it is desirable that the server can be protected behind the NAT/Firewall in order to integrate with company specific services. However, when a server is behind the NAT/Firewall, several problems will occur. Especially, when a user is outside the NAT/Firewall, it will be hard for the user to communicate with the server, especially to notify the server of the activation of that user. To deal with the problem of NAT/Firewall, solutions such as ALG, STUN, TURN and SBC have been used. However, these solutions will either require that the NAT/Firewall to be implemented in certain way or require the client be modified. In this paper, the problems related to a server behind a NAT/Firewall are addressed. A Simple Transmission Access (STA) system architecture has been proposed so that the NAT/Firewall and the client will remain unchanged and no additional non-SIP related messages will need to be dealt with. Simulated results and implementation of the system will also be presented.. Keywords：VoIP, SIP, NAT, Firewall. ii.
(5) 致謝 經過兩年的努力，此篇論文終於可以順利完成。二年求學過程中很感激梁明 正、吳國棟二位老師的支持與指導，給予學生灌輸相當多有關基礎理論與實作方 面的知識，以及教導做人與處事應持有的態度，再次感謝兩位老師的栽培。 另外還要特別感謝黃立璁同學的指導與教誨，從入學到畢業期間幾乎都是由 他在帶領，給予提供網路基礎概念、系統實作方面相關知識，以及李敬文同學幫 忙提供其他額外相關周邊資訊，陳劉明、蔡穗山同學在課業方面與予相當大的幫 助，最後還要多謝徐毓鄉助理的日常生活的照顧以及學弟們的蒐集資料，你們的 幫助，我會銘記在心裡。 最後，更要感謝我的家人對我的關心，提供給我一個良好的生活環境，讓我 專注於課業，使我能順利完成碩士學位，願以此論文獻給我最摯愛的家人。. iii.
(6) 目錄 目錄...............................................................................................................................iv 圖目錄............................................................................................................................v 表目錄..........................................................................................................................vii 第一章、 緒論........................................................................................................1 1.1. 研究背景與動機........................................................................................1 1.2. 問題............................................................................................................1 1.3. 目的............................................................................................................2 第二章、 相關研究................................................................................................4 2.1. 議程起始協定(Session Initiation Protocol，SIP).....................................4 2.1.1. SIP基本網路元件..........................................................................5 2.1.2. SIP訊息結構..................................................................................8 會談描述協議(SDP，Session Description Protocol) .............................10 SIP與NAT ................................................................................................11 2.3.1. NAT類型......................................................................................12 2.3.2. SIP穿越Firewall/NAT問題..........................................................15 2.3.3. SIP穿透防火牆/NAT技術介紹...................................................16 2.4. 建置SIP伺服器位於Firewall/NAT的解決方法......................................19 第三章、 系統設計..............................................................................................22 3.1. 設計考量..................................................................................................22 3.2. 系統架構..................................................................................................23 3.3. 系統運作模式..........................................................................................25 2.2. 2.3.. 3.3.1. Registration ..................................................................................25 3.3.2. Call Set Up...................................................................................26 第四章、 系統實作..............................................................................................36 4.1. 測試環境..................................................................................................36 4.2. 安全性......................................................................................................37 4.3. 限制性......................................................................................................40 4.4. 減輕Server負載量 ...................................................................................43 第五章、 結論與未來工作..................................................................................46 5.1. 結論..........................................................................................................46 5.2. 未來工作..................................................................................................46 參考文獻......................................................................................................................46. iv.
(7) 圖目錄 圖 圖 圖 圖 圖 圖 圖 圖 圖 圖 圖. 1 2 3 4 5 6 7 8 9 10 11. SIP網路環境架構..............................................................................................5 UAC and UAS ...................................................................................................6 SIP Proxy ...........................................................................................................7 SIP Redirection ..................................................................................................7 SIP Registrar Server...........................................................................................8 SDP格式訊息 ..................................................................................................11 NAT的運作流程..............................................................................................12 Full Cone NAT運作方式.................................................................................13 Restricted Cone NAT運作方式 .......................................................................14 Port Restricted Cone NAT運作方式 .............................................................14 Symmetric NAT運作方式 .............................................................................15. 圖 圖 圖 圖 圖 圖 圖 圖 圖 圖 圖 圖 圖 圖 圖 圖 圖 圖 圖 圖 圖 圖 圖 圖. 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35. STUN運作模式 .............................................................................................17 TURN運作模式.............................................................................................18 RTP Relay Server運作模式...........................................................................18 SBC系統架構 ................................................................................................19 SipDual-Start系統架構環境圖......................................................................20 Signaling訊息傳送流程 ................................................................................20 RTP多媒體資訊流程 ....................................................................................21 STA網路環境架構圖 ....................................................................................23 SIP Server註冊流程 ......................................................................................25 位元於不同Firewall/NAT用戶註冊流程 .....................................................26 雙方使用者位於visiting location zone .........................................................27 雙方使用者位於不同Firewall/NAT .............................................................27 雙方使用者位於不同的區域........................................................................27 SIP Proxy處理請求方法規則 .......................................................................27 分佈visiting location zone使用者情況 .........................................................28 Visiting Location送出邀請訊息....................................................................28 Visiting Location接收邀請訊息....................................................................29 Home Location送出reINVITE ......................................................................30 Home與Visiting Location環境圖–由Home UA傳送邀請訊息 .................31 Home與Visiting Location流程圖–Home UA傳送邀請訊息 .....................32 Home與Visiting Location環境圖–由Visiting UA傳送邀請訊息 ..............33 Home與Visiting Location流程圖–由Visiting UA傳送邀請訊息 ..............33 Home location用戶通訊環境圖....................................................................34 Home location用戶通訊流程圖....................................................................34 v.
(8) 圖 圖 圖 圖 圖 圖 圖 圖 圖. 36 37 38 39 40 41 42 43 44. SipDual-Start模擬環境架構..........................................................................37 STA模擬環境架構 ........................................................................................37 RTP audio port number ..................................................................................38 RTP audio/video port number ........................................................................38 SipDual-Start模擬環境圖..............................................................................40 STA模擬環境圖 ............................................................................................41 STA模擬環境圖 ............................................................................................41 SipDual-Start模擬環境圖..............................................................................43 STA模擬環境圖 ............................................................................................44. vi.
(9) 表目錄 表 表 表 表 表 表 表. 1 H.323 與SIP協定之比較...................................................................4 2 SIP請求方法表..................................................................................9 3 SIP回應訊息表................................................................................10 4 SDP參數描述 ..................................................................................11 5 SIP伺服器軟硬體環境....................................................................36 6 SIP Proxy軟硬體環境 .....................................................................36 7 Media Controller軟硬體環境..........................................................36. vii.
(10) 第一章、 緒論 1.1. 研究背景與動機 從 1995 年由 VocalTec 公司推出網路電話軟體至今，VoIP 的發展也屆滿 12 年，早期 VoIP 軟體雖能提供基本語音通話，但當時仍以撥接式 ADSL 上網為主， 受限於連線頻寬不足、網路壅塞等因素而產生語音不清與延遲加上軟硬體成本、 使用習性不便等其他非技術方面的因素，使得 VoIP 應用並不普遍而墮入沈潛期。 隨著寬頻普及，以 Skype 為代表的分佈式 VoIP 開始快速興起躍升於檯面， 成為火線話題，未來網路電話取代傳統電話儼然成為一趨勢，其原因包括可提供 較多的通訊服務、節省電話成本、傳輸頻寬可有效率運用、以及加值服務的延伸 彈性較高，相對地有品質問題、相容性問題有待解決。而 VoIP 主要使用的通訊 協定包括：H.323、SIP、MGCP，其中 SIP (Session Initiation Protocol)[1]是針對 VoIP 特別設計的一個更新、更簡單的協定，具有低複雜度、容易維護與建置、 延伸性佳、擴充性高、開發簡單、建置花費低等優勢已成為目前 VoIP 的主流協 定，更多設備廠商都開始將下一代網路電話的協定標準指向 SIP，因此本論文中 對基於 SIP 協定的 VoIP 系統中關鍵技術進行了研究。 近年來，VoIP 憑藉極其低廉的通信費用、內部免費通話、系統建置維護門 檻低、應用服務多樣化等優點，明顯有助於提高工作效率及大幅降低營運成本等 特點，迅速吸引了大量中小企業主的青睞。 一般中小企業導入 VoIP 除可有效降低企業內部通訊費用外，透過 VoIP，寬 頻連線可同時結合語音、數據、影像傳輸等服務，使頻寬的使用效益達到最佳化。 而在企業 VoIP 也有革命性的突破，已可以從單純的企業內部至各分公司之間垂 直通訊應用，讓企業本體公司與分公司間通訊可以免費。 目前企業網路一般都是內部網路，所使用的 IP 皆為私有 IP，和外界的通信， 都是通過一 NAT 來實現位址轉換的。這是因為 IP 位址缺乏，企業網路很難和 ISP 申請到全局 IP 位址，同時考慮到企業網路的內部安全性，企業是不希望外界都 可以直接訪問到企業網路上的所有設備。因此採用內部網路位址可以使企業自主 維護網路，和 INTERNET 的通信透過 NAT 就可以實現。如同一般企業網路會將 某些伺服器設置在 Firewall 的 DMZ 或 NAT 中，未來企業 VoIP 伺服器設置在 Firewall 的 DMZ 或 NAT 也將成為主流趨勢，但接著所面臨 SIP 穿越 NAT 又是 一大挑戰。. 1.2. 問題 目前 VoIP 系統環境建置主要以公開網路(public network)為主，雖然 SIP 通 訊協定的設計無法直接通過防火牆（Firewall）和網路位置轉換（NAT）設備， 1.
(11) 這使得 SIP 通訊協定在企業或家庭等使用私有網路位置的環境下的應用受到限 制。. z. 當 VoIP 系統位於 NAT 或防火牆下時，在 NAT 穿越時分為二個問題： SIP 信號穿越於 NAT 從公開網路傳入之 SIP 信號：NAT 在預設情況下無法直接將外部網路 傳送之封包導入內部網路，必需先由內部網路主機傳送封包到外部網路 主機後，外部網路主機才可根據 NAT 映射出來的傳輸路徑與內部網路 傳送封包，因此在預設環境下外部網路使用者使用目的端 5060 連接埠 傳送到 NAT 時，NAT 並無法得知 SIP 封包需送往內部網路的主機位置， 使得 SIP 會議建立失敗。 Binding timeout：SIP 並無提供 NAT 在連接埠方面保存之機制，當一段 時間連接埠沒有使用時，NAT 會將該連接埠資源回收，使得外部網路 主機無法透過先前所開啟的連接埠溝通。 . IP 位址變動：在 PPPoE 網路環境下，如果不是使用固定 IP 位址，根據 ISP 所使用的 DHCP 伺服器，每個使用者取得到 IP 位址會有所能使用 的最大期限，當期限到達時所使用的 IP 位址將無效，因此其他主機無 法透過先前的 IP 位址找尋到自己。通常 ISP 所給定的期限為 24 小時。. z. RTP 多媒體資訊穿越於 NAT 由於使用者聲音與影像是藉由 RTP 傳送，在 SIP 訊息裡 SDP 負責描述 RTP 傳輸時的連接埠與 IP 位址等資訊，然而在一般的情況下位於公開網路之使用者 無法使用預設之 RTP 連接埠與內部網路伺服器傳送 RTP 訊息，原因在於公開網 路下使用者傳傳送之目的端連接埠將會被 NAT 或防火牆擋掉。. 1.3. 目的 為瞭解決網路安全問題和 IP 位址資源匱乏等問題，許多企業公司採用了私 有位址，並通過防火牆/NAT 來控制與網際網路的通信。眼前 VoIP 是現代企業 追求最甚的技術之一，其中導入 VoIP 除可有效降低企業內部通訊費用外，透過 VoIP，寬頻連線可同時結合語音、數據、影像傳輸等服務，使頻寬的使用效益達 到最佳化，相關的企業應用如語音、互動式多媒體、多方線上會議、錄音/錄影 服務等加值功能與技術也不斷推陳出新。一般企業網路為了提高系統安全性，會 將某些伺服器設置在 Firewall 的 DMZ 或 NAT 中，相信未來企業間會將相關 VoIP 系統設置在局域內部網路中，甚至個人家庭、學校也有相關的問題，但所面臨穿 越 NAT 又是一大挑戰。 因此本論文提出一個系統架構，可將 VoIP 系統設置於 DMZ 或 NAT 內，順 利解決 SIP 穿越 NAT 的問題，只需要針對伺服器端做設定，並不會加諸於任何 2.
(12) 負擔於使用者身上，以及任何 Firewall/NAT 的變動，同時使用者可適用於任何 NAT 種類。. 3.
(13) 第二章、 相關研究 本章主要介紹與本論文相關的其他研究：SIP、NAT type、解決 SIP 穿越 NAT 的方法和已提出建置 SIP 伺服器位於 Firewall/NAT 的解決方法。. 2.1. 議程起始協定(Session Initiation Protocol，SIP) SIP (Session Initiation Protocol)[1]協定為 VoIP 通信的主要協定之一，是基於 IETF 多 媒 體 會 話 控 制 協 議 工 作 小 組 (Multipart Multimedia Session Control, MMUSIC)討論後，於 1999 年制訂 RFC 2543 標準，是針對 VoIP 特別設計的一個 更新、更簡單的協定，主要用於網際網路會議或網路電話彼此之間的通訊。早期 所制定 SIP 的規範相當簡單，但對於目前一般電話許多附加服務的功能，如保留 （Call Hold）､轉接（Call Transfer）等功能並無定義其可用的支援方式，因此在 SIP2.0 版本中將考慮納入 RFC 2848，補強 SIP 協定功能薄弱的問題，於 2000 年 7 月提出初版 RFC 2543bis，接著在 2001 年則發佈了 RFC3261 版本。 SIP 是在諸如 SMTP 和 HTTP 基礎之上建立起來的，基於 IP 的一個應用層 控制協定其主要功能用來建立，改變和終止基於 IP 網路的用戶間呼叫，目前已 廣泛應用在網路電話、視訊會議、即時訊息等更多網路應用服務上。 以 OSI 定義的網路七層分類，SIP 應該是屬於會談層（Session Layer） 。由於 SIP 是架構在應用層中，因此開發 SIP 的應用程式時，可不管底層的傳輸協定或 網路架構，這讓 SIP 具有容易開發、內容簡潔以及擴充性高的優點，也讓 SIP 除 了可在 TCP 或 UDP 的傳輸層上進行互動運作外，還能架構在其他任何型態的傳 輸網路，讓開發者更容易進行系統的整合。 表 1 H.323 與 SIP 協定之比較. 協定比較 相容性 複雜度. H.323 高. SIP 低. 成本. 高. 低. 編碼格式 擴充性. ASN.1 差. text 佳. 成熟度. 好. 差. 定義範圍. 完全. 有限. 作業互通性. 好. 一般. 由表 1所示，其中SIP傳輸協定具有以下幾個特點： (1) 複雜度低：由於 H.323 本身制定的標準裡，同時涵蓋了許多其他的標準，使 4.
(14) (2). (3) (4) (5). 得整體的機制變得複雜而沒有彈性。對 SIP 而言，標準本身主要探討 signaling 的機制，整體的複雜度較低。 文字編碼：SIP 的編碼精神類似 HTTP1.1，直接使用文字來當作編碼，有別 於 H.323 的二進位元編碼方式，文字編碼的方式相對而言可以明確表示訊息 內容。 資料與訊號分別傳送：多媒體資料是由 SDP 負責描述，資料傳送則是由 RTP、 TCP 與 UDP 等通訊協定規範。 可搭配 IETF 的相關協定使用：利用 SDP 來作多媒體資料描述，也可以利用 HTTP1.1 來擴充服務的內容。 擴充性佳：SIP 在整體的擴充性，只定義基本的連線建立機制，保留了許多 擴充空間，故表現也較為良好。. SIP 是 IETF 體系的一部份，因此與 IETF 的許多其他協議都有聯繫，例如 即時傳輸協議（RTP）[2]、會談公告協議（SAP）、會談描述協議（SDP）。而一 個完整的 SIP 服務系統，還需要 DNS、DHCP、RSVP 等 IETF 協定的配合才能 正常運作。其中 SDP 可視為 SIP 的一部分，專門負責處理媒體格式的協商，SIP 沒有它也不可能單獨運作。 2.1.1. SIP 基本網路元件 如圖 1所示，在RFC 2543[2]中定義了SIP體系結構所組成的SIP邏輯元件。 其中SIP系統基本組件可以分為兩大類：SIP用戶代理 (SIP User Agent)和SIP服務 器 (SIP Server)，也就是所謂用戶端(Client Side)和伺服器端(Server Side)，伺服器 端則包括有代理伺服器(Proxy Server)、重定向伺服器(Redirect Server)、註冊伺服 器(Registrar Server)三種複合的功能。SIP協議將在這兩大類元件間進行，而每一 元件皆具有特定的功能角色，接下來將逐一對每個元件做介紹。. 圖 1. SIP 網路環境架構. 5.
(15) 1.. 用戶代理 (User Agent). User Agents通常簡稱為UA，是SIP網路環境中的用戶終端設備。它可以是SIP 電話機或者在個人電腦端的SIP客戶端軟體，主要功能為發出請求、回應初始、 終止會話。如圖 2所示，用戶代理在邏輯上它包含有User Agent Client (UAC) 以 及 User Agent Server (UAS) 兩種角色，其中UAC負責產生請求(Request)以及接 收由UAS產生的回應(Response)，而UAS負責接收UAC產生的請求(Request)以及 依照請求產生回應(Response)。 每個SIP UA都同時扮演者UAC和UAS的角色， 如果SIP UA目前扮演的是呼叫者(Caller)的角色，這時該UA就是扮演UAC的角 色，反之SIP UA所扮演的是接聽者(Callee)的角色，這時該UA則扮演UAS的角色。. 圖 2 UAC and UAS. 2.. 代理伺服器 (Proxy Server). Proxy Server是SIP協議運作的中心，並且同時具有伺服器端和客戶端雙重角 色的仲介元件，主要負責將SIP UA或者其他的Proxy Server產生的請求或將收到 的請求代為轉送到另一個目標SIP元件去。如圖 3所示，當Joe送出連線請求時並 不一定知道請求連線的對象其IP位址究竟位於何處，此時便需要將請求傳送給 Proxy Server，Proxy Server再透過查詢Location Server得知Lee相關位址資訊，以 轉送到正確的Lee位置去。從Joe發出請求連線時，有可能經由Proxy Server層層轉 送後才將請求訊息傳送到目的端的Lee，每個SIP Proxy都會有預設的方法決定下 一個路由，並且對請求訊息做適當的修改處理以利訊息的傳遞。目的端的Lee回 應結果的時候也是一樣會經由相反的路由路徑將回應結果給請求端的Joe。. 6.
(16) 圖 3. 3.. SIP Proxy. 重定向伺服器 (Redirect Server). 重定向伺服器(如圖 4)有點像Proxy Server的角色，與Proxy Server不同的 是，Redirect Server只負責為呼叫者查尋最新接聽者的位置，並把查尋結果回傳 給呼叫者，讓呼叫者知道需要將連線請求重新導向接聽者新的位置，而不會轉遞 任何請求到其他伺服器。Redirect Server就好像是SIP環境中的DNS伺服器，專門 負責查尋SIP的目標位址。. 圖 4. 4.. SIP Redirection. 註冊伺服器 (Register Server). 註冊伺服器(如圖 5)主要是接受REGISTER請求的伺服器，其目的是根據用 戶在請求中的SIP URI和IP等聯繫資訊，紀錄儲存或更新位置伺服器中的位址資 料庫。在SIP系統中所有的使用者，一開機都要向Register Server進行註冊、登錄 完畢，因此Registrar Server還兼具有使用者身份認證的功能，登錄完畢後該用戶 資訊才得以被查詢及被呼叫。 7.
(17) 圖 5. 5.. SIP Registrar Server. 位置伺服器 (Location Server). 位置伺服器可視為 SIP 資料庫，負責儲存跟 Register Server 註冊的 UA 資 訊，例如：URI、IP 位址、身份、特性等等。接受註冊伺服器的用戶資料，並提 供給代理伺服器和轉向伺服器使用。通常位置伺服器、註冊伺服器都是代理伺服 器的一部分，少數大規模的電信等級服務設施，才會因效能考量區分開。 2.1.2. SIP 訊息結構 SIP 元件透過 SIP 訊息(Message)機制用於會話連接的建立及修改，而 SIP 的 訊息內容完全是遵循擴散巴科斯(ABNF；Augmented Backus-Naur Form)形式語法 的規則，並且採用 UTF-8 的文本編碼格式。SIP 訊息有請求(Request)和回應 (Response)兩種類型的訊息，以 ABNF 語法表示如下： SIP-message = Request | Response 其中二者具有相同的訊息格式，我們可以用 generic-message structure 來描述 這二種訊息型態，其定義如下： generic-message = start-line *message-header CRLF (carriage-return line-feed) [ message-body ] 根據 RFC 2543[3]對 SIP 訊息描述，每個訊息格式包含三個元素：一、起始 行 (Strar-Line)，包括在發送訊息請求時的請求列 (Request-Line)及發送回應訊息 的狀態列 (Status-Line)。二、訊息標頭 (Message Header)以及訊息主體 (Message Body)，即為 SDP 訊息。前二者一定要包含不可，而訊息主體則是自由選擇是否 要附帶的。 有關起始行及訊息標頭則要滿足下列的格式： start-line = Request-Line | Status-Line 8.
(18) message-header = (general-header|request-header|response-header | entity-header ) 其中 SIP 的訊息標頭欄位與 SIP 協定的訊息定義與 HTTP 在語法規則和定義 上很相似。每個標頭欄位都遵循以下格式；首先是欄位名(Field Name)，欄位名 不分大小寫，後面是冒號，然後是欄位值，其中欄位值與冒號間可有多個空格。 message-header = field-name ":" [ field-value ] CRLF 根據 SIP 的定義，請求訊息要滿足下列的格式： Request = Request-Line *( general-header | request-header | entity-header ) CRLF [message-body] Request-Line = Method SP Request-URI SP SIP-Version CRLF Method = "INVITE" | "ACK" | "OPTIONS" | "BYE" | "CANCEL" | "REGISTER" (*：至少重複一次以上；CRLF：是將指標移回行頭並且進到下一列最開頭；SP：空一格). 回應訊息與請求訊息有點類似，格式如下： Response = Status-Line *( general-header | response-header | entity-header ) CRLF [ message-body ] Status-Line = SIP-version SP Status-Code SP Reason-Phrase CRLF Status-Code = Informational | Success | Redirection | Client-Error |Server-Error |Global-Failure | extension-code SIP 在建立呼叫連線時所用的六個基本請求方法(Methods)如表 2，分別是邀 請(INVITE)、確認(ACK)、再見(BYE)、取消(CANCEL)、註冊(REGISTER)和選 項(OPTIONS)。後來 SIP 為了能提供緊急的服務功能，又增加通知(INFO)、告知 (SUBSCRIBE)、及公佈(NOTIFY)方法。而在回應訊息部分又可分為六類如表 3， 每個回應代碼均有特殊的涵義或反應的行為。 表 2. SIP 請求方法表. 請求方法 INVITE ACK. 說明 用來發起一個 Session 的邀請 用來確認 INVITE 的最終應答。 9.
(19) BYE. 結束一個已連結的呼叫. CANCEL. 用於取消一個已發出但尚未建立完成通話程式的呼叫。. OPTIONS. 用於查詢 Server 的相關訊息及支援能力。. REGISTER. 用於向註冊伺服器註冊客戶端的相關訊息。. INFO SUBSCRIBE NOTIFY. 發送會話中資訊而不改變會話狀態，可以用來傳送通話 中隨機產生的各種信號，也可以在會話雙方間傳遞即時 訊息。 該方法用來向遠端端點預訂其狀態變化的通知。 該方法發送訊息以通知預訂者它所預定的狀態的變化。 表 3. SIP 回應訊息表. 狀態碼. 說明. 1xx (Informational). 用來告知發出要求訊息的一方，請求已經收到正在 處理中，處理狀況為何等。. 2xx (Success). 包含接收封包成功，已瞭解封包內容以及接收請求 等。. 3xx (Redirection). 包含將請求封包重新指向到其他位址的資訊，發話 端會據此將呼叫重新向指定的位址發起，被指向的 新位置可能是通話的目的地。. 4xx (Client Error). 有關用戶端送來的請求封包有錯誤或是一些有關用 戶端無法建立交談的訊息資訊。. 5xx (Server Error). 有關一些伺服器端有錯誤的訊息。. 6xx (Global Failure). 有關一些目前網路環境有錯誤的訊息，或目前無人 或無法處理 Client 端的要求等。. 2.2. 會談描述協議(SDP，Session Description Protocol) SDP[4]主要目的是用來讓通話雙方可以藉由 SDP 封包知道建立交談時所需 的資訊。其中 SDP 包含了 IP 位址、通訊埠號碼以及語音資料要用哪種協定傳送 等的資訊。SDP 目前被廣泛使用在 SIP、SAP、MGCP[5]、RTSP 等應用層協議。 SIP 是屬於一種信令傳輸方式，所以當使用者要開始建立交談時，雙方一定 要知道對方想要的通訊方式。而 SIP 的封包並不會帶出這些資訊，所以 SIP 封包 中除了有 SIP 的資訊外，還會額外包含 SDP 的封包以便讓對方知道我方想要的 通訊方式。 其中SDP是採用文字模式，如圖 6顯示幾個比較重要的參數，而SDP的格式 主要是由許多文本行所組成的，而文本行的格式為<類型>=<值>。假若使用者瞭 解參數所代表的意思，則可以很容易瞭解Control Message中所包含的資訊。 10.
(20) 圖 6. SDP 格式訊息. 根據所定義，如表 4顯示其參數所代表意義，其中SDP至少攜帶以下資訊： (1) Session 的名稱。 (2) 相關連線訊息的資訊：比如在哪個 IP 位址、Port 監聽接收封包。 (3) 多媒體的型態，為 Audio 或 Video，甚至二者包括。 (4) 傳輸協定，如使用 RTP、UDP 等。 (5) 多媒體 Codec 編碼格式，如 GSM、ulaw、alaw、h.263 等。 表 4. SDP 參數描述. 參數. 意義. 說明. v. Protocol Version Number. o. Owner/Creator and Session Identifier. s. Session Name. c. Connection Information. 定義本地端的連線參數. b. Bandwidth Information. 描述頻寬狀況. t. Time Session Starts and Stops. a. Media Attributes. m. Media Information. SDP 的版本，目前皆使用 0 描述連線的來源端訊息 呼叫端用來描述 Session 名稱的，通 常由 UAS/UAC 設定提供. Session 活動時間，宣告 Session 在多 久時間後失效 描述多媒體編碼型式和相關支援能 力參數 描述多媒體通道建立的訊息. 2.3. SIP 與 NAT NAT (Network Address Translation) [6]是一個 IETF (Internet Engineering Task Force, IETF) 標準，用於允許網路上的多台電腦 (使用私有 IP 位址，例如：. 11.
(21) 10.0.X.X、192.168.X.X、172.X.X.X)共用單個、全局路由的 IPv4 位址。簡單地敘 述，NAT 就是在局域內部網路中使用私有 IP 位址，而當內部節點要與外部網路 進行會透過一個合法的 IP 位址與外界連線。 依據[7]IETF RFC 1918 -『Address Allocation for Private Internets』 ，定義有三 個區段作為私有 IP 位址使用： 位址類別 主機 IP 範圍 -------------------------------------------------------------------------類別 A 10.0.0.1~10.255.255.254 類別 B 172.16.0.1~172.31.255.254 類別 C 192.168.0.1~192.168.255.254 NAT 裝置作用隱藏了內部網路 IP 位址，所有內部網路節點對於外部網路 (Internet)是不可見的，因此可保護內部網路主機不受外界攻擊，而內部網路用戶 通常不會意識而 NAT 裝置的存在。如圖 2.2 所示提到的內部網路位址，是指在 內部網路中分配給節點的私有 IP 位址，只適合於內部網路中使用，則私有 IP 位 址的路由資訊不能對外散播。當內部用戶欲存取外部網路服務時，所傳送的封包 經由 NAT 裝置在轉傳到外部網路的目的端，而在 NAT 裝置接收到內部用戶端傳 送的封包來源 IP:Port 為 192.168.0.200:1234 時，會使用本裝置的一個連接埠 (也 稱為 NAT 連接埠)來對應用戶端的 IP 位址與來源連接埠並將來源資訊儲存在 NAT translation table 內，然後根據這個連接埠，產生新的封包來源 IP:Port 為 210.32.166.58:7000 送到目的地 IP:Port 為 140.127.206.10:80；而當 NAT 裝置收到 傳回的訊息會比對 NAT translation table，比對過後發現目的地連接埠 7000 所對 應的內部 IP:Port，並把封包正確傳回到 NAT 用戶端。. 圖 7 NAT 的運作流程. 2.3.1. NAT 類型 依據 RFC 中的定義，有四種比較常見的 NAT 類型：全克隆(Full Cone NAT)、 12.
(22) 限制性克隆(Restricted Cone NAT)、埠限制性克隆(Port Restricted Cone NAT)、對 稱式 NAT(Symmetric NAT)。 1.. 全克隆 (Full Cone NAT). 首先要透過內部用戶網路IP位址和埠的請求映射到NAT裝置的外部網路IP 位址和連接埠。其次，任何一個外部主機通過把一個IP封包發送給已得到映射的 外部網路IP的方式，都能夠把封包發送給該內部主機。如圖 8所示，位於NAT內 IP:Port為 192.168.0.100:80 的用戶，所傳送封包訊息經NAT轉址後來源IP:Port變 為 140.127.206.10:12345，修改過後的封包再傳送到外部網路(Internet)，最後到達 目的端A用戶，而A用戶也可經由相同的路徑回傳封包給內部用戶，同時A用戶 只要告知B用戶得知的修改過後的來源IP:Port，同樣B用戶也可以傳送封包給內 部用戶。. 圖 8. 2.. Full Cone NAT 運作方式. 限制性克隆 (Restricted Cone NAT). 有點類似Full Cone NAT，首先也是透過內部用戶網路IP位址和埠的請求映射 到NAT裝置的外部網路IP位址和連接埠。但不同的是只有當內部主機曾經給IP位 址為X的外部主機發送過封包時，IP位址為X的外部主機才能夠把封包傳送給內 部主機。如圖 9所示，內部用戶只傳送封包給外部用戶A、C，當用戶A、C接收 到所傳送的封包時，可透過接收的封包來源IP:Port再回傳給內部用戶，如果用戶 A將來源IP:Port告知給用戶B知道，而用戶B依照來源IP:Port傳送資料封包給內部 用戶，則NAT會封鎖來自用戶B的封包，主要原因是當內部用戶傳送封包給用戶 A時，此時NAT會記錄封包目的端的IP，所以當用戶B傳送封包到NAT時，NAT 查尋不到曾傳送過封包到目的端為用戶B的IP位址，因此將封包給封鎖。. 13.
(23) 圖 9. 3.. Restricted Cone NAT 運作方式. 埠限制性克隆 (Port Restricted Cone). Port Restricted Cone與Restricted Cone NAT有點類似，與Restricted Cone NAT 不同的是：它同時記錄了外部主機的IP位址和Port。當NAT接收到封包時，會記 錄 內 部 網 路 用 戶 所 發 送 過 封 包 的 目 的 端 IP 位 元 址 和 Port ， 唯 有 被 紀 錄 的 Destination table集合中IP位元址和Port才允許進入內部網路，否則將被封鎖。如圖 10所示，內部用戶僅傳送封包給外部用戶A，則接下來NAT僅會允許來自IP:Port 為 222.111.90.2 的封包通過；若由相同的IP位址，但Port卻變為 2385， NAT將會 封鎖住；反之，相同的Port，但IP位址卻不同，還是會被NAT封鎖住。. 圖 10 Port Restricted Cone NAT 運作方式 14.
(24) 4.. 對稱式 NAT (Symmetric NAT). Symmetric NAT是所有NAT種類中最嚴謹的一個，除了擁有Port Restricted Cone的性質外，基於傳送封包目的地的不同會映射不同的連接埠。其中只允許 先由私有網域內的用戶發送封包到網際網路中的用戶可以回傳封包。如圖 11所 示，內部用戶各傳送封包給外部用戶A、B，並且得到二組不同映射的結果，用 戶A的是 140.127.206.10:6000，而用戶B的是 140.127.206.10:7000，二者用戶只能 透過各自映射的IP:Port與內部用戶傳送訊息。假如用戶B想經由用戶A所映射的 IP:Port傳送訊息給內部用戶，則會被NAT所封鎖；反之，也會得到相同的結果。. 圖 11. Symmetric NAT 運作方式. 2.3.2. SIP 穿越 Firewall/NAT 問題 雖然 Firewall/NAT 穿透技術解決了 IP 位址匱乏與安全性問題，但由於穿越 Firewall/NAT 時只修改封包中網路層和傳輸層的資訊，並未處理 SIP 訊息的內 容，因此若公眾網路上的主機使用 SIP 訊息中攜帶的私有 IP 位址和通訊埠作為 封包的目的地，將導致此封包無法在公眾網路上路由，以致於私有網路內的主機 收不到公眾網路上主機所傳送的封包[8][9]。如下列範例為用戶 200 邀請用戶 100 的 INVITE 的訊息，在 SIP 訊息中主要有兩個標頭內容的 IP 位址和通訊埠與路 由有關，分別為 “Contact” 和”Via”。其中 Contact 標頭是用來告知對方此後的請 求訊息傳送的位置，因此若此標頭內容為私有 IP 位址及通訊埠，公眾網路上的 SIP 設備便無法將請求訊息正確傳送到內部網路的 SIP 設備。當送出請求訊息 時，SIP 設備會加入一個 Via 標頭，其內容包含自己的 IP 位址，並將此 Via 放在 原有的 Via 最上方，而當目的地 SIP 設備傳送回應訊息時，會將請求訊息中的所 有 Via 原封不動的複製到回應訊息中，層層的 SIP 設備將依序檢查 Via 欄位所帶 的位址資訊，以便將封包依照原路徑反向送回。若 Via 帶有私有 IP 位址及通訊 埠，則回應訊息無法回到內部網路的 SIP 設備。 15.
(25) INVITE sip:100@140.127.205.143 SIP/2.0 Call-ID: 80676d0-1eb6c-c0a801bc@140.127.205.143 From: 200<sip:200@140.127.205.143>;tag=402fdc4-1eb6f To: <sip:100@140.127.205.143> CSeq: 100 INVITE Via: SIP/2.0/UDP 192.168.1.188 Contact: 200<sip:200@192.168.1.188> Max-Forwards: 70 User-Agent: SIP Phone Allow: REFER,UPDATE,INFO,NOTIFY Content-Type: application/sdp Content-Length: 267 v=0 o=200 0 0 IN IP4 192.168.1.188 s=c=IN IP4 192.168.1.188 t=0 0 m=audio 8194 RTP/AVP 4 0 8 a=ptime:30 m=video 8196 RTP/AVP 34 31 如上述除了標頭部份的問題外，在 SIP 訊息本體的 SDP 中，c 欄位和 m 欄 位分別帶有欲接收 RTP 封包的 IP 位址與通訊埠。若欄位中內容為私有 IP 位址和 通訊埠，則通話建立後的 RTP 影音封包將無法送到正確使用者位置。 因此 Firewall/NAT 穿透時不僅需要對 TCP/UDP 層的埠號訊息以及 IP 層的來 源位址和目的地位址進行轉換，還需對 IP 封包 Playload 的相關位址訊息進行轉 換，因此 NAT 穿透問題是目前發展 VoIP 應用最大的障礙，迫切需要解決。 2.3.3. SIP 穿透防火牆/NAT 技術介紹 目前，已提出了多種解決方案。根據處理部份所在位置不同，可以分為三種： 用戶端解決方案、路由邊界解決方案以及伺服器端解決方案，其各方案包括技術 方法如下： (1) 用戶端解決方案 用 戶 端 解 決 方 案 主 要 包 括 ： STUN (Simple Traversal of UDP through NAT)[10]、TURN (Traversal Using Relay NAT)[11]、ICE (Interactive Connectivity Establishment)。 (2) 路由邊界解決方案 ALG (Application Layer Gateway)[12]、UPnP (Universal Plug and Play)、 16.
(26) MIDCOM (Middlebox Communications)。 (3) 伺服器端解決方案 B2BUA (Back-to-Back User Agent)、RTP Relay Server、SBC (Session Border Controller)[13] 接下來只針對所提出的系統架構中相關作法的解決方案做說明。 1.. STUN. STUN 是由 IETF 所制定的一種由 UDP 對 NAT 的簡單穿越方式協定。透過 STUN 可提供客戶端察知是否位於 NAT 內，並且可得知 NAT 是屬於何種類型與 對外公有 IP 位址及所映射的連接埠，其 STUN 協定最大的優點是無需現有 NAT 裝置做任何變動，但是因為 STUN 還不是 100%有效的(不支援 Symmetric NAT) 方法，所以還需要配合 TURN 或是 ALG 這種透過第三方轉送 RTP 封包的穿越方 式。. 圖 12 STUN 運作模式. 如圖 12所示，位於內部網路的STUN Client透過UDP發送請求STUN訊息給 外部網路的STUN Server，STUN Server收到請求訊息會產生回應訊息，其中回應 訊息中攜帶NAT的公有IP位址以及所映射的連接埠，當回應訊息通過NAT轉送給 內部的STUN Client，此時STUN Client經由這些資訊修改SIP協定中Via、Contact HF與SDP裡c、m參數資訊，最後將修改過後的封包送至SIP Proxy，因此能讓信 令訊息及媒體串流訊息能在不更改任何NAT的情況下就可以正常運作。 2.. TURN. TURN 與 STUN 相似，也是基於內部網路用戶通過某種機制預先得到 STUN Server 上的 IP 位址和埠，然後在修改 SIP 封包內的標頭位址資訊以解決穿越問 題，其優點是提供了對 Symmetric NAT 的穿越。雖然 TURN 技術支援所有類型 的 NAT 穿越，但是在通信中需要負責轉傳雙方的多媒體串流，以致於多媒體串 流在傳輸過程中增加了不少 TURN 伺服器的負擔，不可避免地增加了封包的延 17.
(27) 遲和遺失封包的可能性，透過 TURN 技術需要大量的 TURN 伺服器，當用戶增 多時，TURN 伺服器會成為系統瓶頸。因此，TURN 的使用越來越少。. 圖 13 TURN 運作模式. 如圖 13所示，內部網路用戶發出的封包都要經由TURN Server進行轉傳到目 的端，相對所回應的封包也是要透過TURN Server在轉傳到內部網路用戶，進而 解決Symmetric NAT穿越的問題。 3.. RTP Relay Server. 亦可稱為 RTP 代理伺服器(RTP Proxy Server)，其功能是中繼轉傳通信中雙 方的媒體串流封包。當一方的 RTP 封包到達 RTP 代理伺服器時，RTP 代理伺服 器會記錄此封包的來源 IP 位址；而當接收到另一方的 RTP 封包時，RTP 代理伺 服器才知該往何處傳送。這是非常重要的，因為 SIP UA 媒體串流只有真正穿越 NAT 之後，NAT 位址映射關係才會建立，相對的映射位址才可得知的。值得注 意的是，只有當 RTP 代理伺服器接收到雙方的第一個 RTP 封包，才能建立起中 繼路徑，並轉傳通信中雙方的 RTP 媒體封包。. 圖 14 RTP Relay Server 運作模式. 如圖 14所示，當內部網路用戶所傳送的信令訊息到達Proxy Server時，Proxy 18.
(28) Server將對信令訊息中攜帶的SDP資訊進行解析與處理，修改媒體串流埠為RTP 代理伺服器上分配的外部埠號以及RTP代理伺服器本身對外的外部IP位址，使得 通信中的媒體串流均經由指定的RTP代理伺服器中繼，進而完成信令和媒體串流 穿越NAT。 4.. SBC. SBC是迄今為止，對穿越Firewall/NAT問題解決最完善的方案，主要是安裝 在網路核心交換端，以確保整個網路範圍內IP即時傳輸的安全性與可靠性，不僅 不用對原來網路中的Firewall/NAT設備做任何改變，而且對原有網路也沒有任何 特殊要求。如圖 15所示，SBC採用了二種不同的架構：B2BUA、ALG，並且同 時包含media proxy與服務控制功能，所有經過SBC的信令和媒體串流透過SBC的 協調和修改，可以在系統與用戶間正確傳送。用戶端的Firewall/NAT可以接受這 種修改後的信令和媒體串流訊息並把他們傳送到內部網路用戶。. 圖 15 SBC 系統架構. 2.4. 建置 SIP 伺服器位於 Firewall/NAT 的解決方法 在 [14] 系統環境主要構想是將SIP伺服器建置於家庭個人工作室中，而遠 端使用者為位於學校宿舍房間內，透過NAT和防火牆設定、增設STUN Server、 以及用戶端支援機制(如：STUN)來解決所造成的問題。根據Wiki描述將此系統 取名為SipDual-Start系統架構。圖 16為SipDual-Start架構環境，在家庭個人工作 室環境部份，從ISP所申請的寬頻網路接到ADSL Modem Router，其中SIP伺服器 是由一台Linux系統電腦組成(內建包含asterisk、NAT、Firewall、DHCP、apache…) 建置在DMZ或NAT/防火牆區域內，而家中網路電話則接於Linux系統電腦NAT 後。學校環境部份：學生宿舍房間則是透過學生宿舍閘道器的DHCP Server分配 私有IP。. 19.
(29) 圖 16 SipDual-Start 系統架構環境圖. 其中在 NAT 穿越時分為二個問題來討論[15]： z SIP 信號穿越於 NAT z RTP 多媒體資訊穿越於 NAT 1、 SIP Signaling 問題 (1) 從公開網路傳入之 SIP 信號 當遠端使用者傳送封包給家庭個人工作室的 SIP 伺服器時，傳送的封包會經 由 ADSL Modem Router，再轉送到工作室的 Asterisk 伺服器，但是當 ADSL Modem Router 接收到封包時，因為不知道封包是要轉送到內部 Asterisk 伺服器 而遭到丟棄，以致於無法正常運作，此問題可透過通訊埠轉送(port forwarding)、 防火牆規則(firewall rule)設定來解決此問題。其中通訊埠轉送功能(port forwardin g)設定為 external port 5060 Æ internal ip Asterisk 伺服器 port 5060，同時要搭配 防火牆規則允許外部 5060 埠進入到內部網路。. 圖 17 Signaling 訊息傳送流程. 如圖 17所示，假設Asterisk伺服器在 5060 埠號碼監聽接收封包，當ADSL Modem Router接收到目的地 5060 埠號碼訊息時，會根據通訊埠轉送規則路由到 內部Asterisk伺服器 5060 埠號碼位置，而Asterisk伺服器會照原路徑傳送給遠端 使用者。 (2) 浮動 IP 問題 20.
(30) 在家庭 ADSL Modem Router 部份，如果 ISP 所提供的為浮動 IP，因為浮動 IP 每隔一段時間 IP 位址會變動，此問題會導致遠端使用者所傳送的封包位址不 對，而造成使用者連線失敗或註冊失敗。浮動 IP 所造成問題只要 ADSL Modem Router 有支援動態網功能變數名稱稱服務(DDNS)即可解決。 2、SIP Media 問題 當逺端使用者與另一使用者建立通話時，由於 SIP 訊息本體的 SDP 中，c 欄位內容為私有 IP 位址和通訊埠，導致遠端之使用者無法使用預設之 RTP 連接 埠與內部網路伺服器傳送 RTP 訊息，有關傳送 RTP 多媒體訊息所產生問題，可 分二部份來說明。首先是由 Asterisk Server 傳送 RTP 多媒體給遠端使用者問題： 主要透過 STUN 來解決。. 圖 18 RTP 多媒體資訊流程. 如圖 18所示，除了需要增設STUN Server外，遠端使用者也要支援STUN機 制。雖然STUN已制定標準，有關網路電話支援STUN Client機制卻是隨著程式開 發者需求程度，導致遠端使用者使用支援STUN機制不全的網路電話傳送RTP 時，還是會發生錯誤，如SJphone。因此考量了其軟、硬體網路電話支援STUN 機制因素，在宿舍房間內加裝了一台寬頻分享器，使得網路電話分配到固定私有 IP位址，其中網路電話設定限制必須可自行設定傳送時的RTP埠號碼，再配合寬 頻分享器設定通訊埠轉送(port forwarding)、防火牆規則(firewall rule)得已解決。 其次，遠端使用者傳送到Asterisk伺服器問題：有關Asterisk伺服器部份可設定傳 送RTP埠範圍，再配合ADSL Modem Router設定通訊埠轉送(port forwarding)、防 火牆規則(firewall rule)功能即可解決。 雖然利用 STUN 機制配合通訊埠轉送(port forwarding)、防火牆規則(firewall rule)可解決傳送 RTP 多媒體問題，但學校環境部份任何一 NAT/防火牆屬於對稱 式 NAT 的話，則無法正常運作。. 21.
(31) 第三章、 系統設計 論文所設計的 STA (Simple Transmitter Access)環境架構中，重點著重於修改 伺服端，在不需額外增加其他非 SIP(如：STUN)協定及防火牆支援任何機制(如： ALG、UPnP 等)下，可順利解決建置 SIP Server 位於 Firewall/NAT 所帶來的問題， 以下將對這些問題提出我們的設計觀點，並說明我們的設計考量。. 3.1. 設計考量 論文所設計 STA 環境架構動機主要來自[8]，基於不想增加用戶端任何負擔 以及適用於任何 Firewall/NAT 情況下，提出幾項說明我們系統主要的設計考量： (1) 標準化 標準化為主要的重點，唯有標準化的系統才能與其他支援特定通訊協定的系 統互相通訊及應用，以致於系統具有未來性，讓我們所建立的環境更具有價值以 及被別人採納，因此標準化就成為我們主要設計考量 (2) 方便性 本系統解決建置 SIP Server 位於 Firewall/NAT 所造成的問題，主要是透過修 改伺服端，對使用者來講不會增加任何負擔、設定也較簡單。 (3) 限制性 根據以往 SIP 穿越 Firewall/NAT 的解決方案中，往往會侷限用戶端以及 Firewall/NAT 要支援某些機制，因此在系統設計上希望能夠適用於任何的設備 上。 (4) 需要支援的設備 將 SIP Server 建置位於 Firewall/NAT 內的解決方法，首先面臨的是 NAT 的 種類對系統架構所造成的影響，並非所有的解決方案(如：STUN 機制)都適用於 任何 NAT 種類，目前在企業公司間最常使用的 Symmetric NAT 為最嚴謹的，也 是穿越問題最多的一種，因此適合於任何 NAT 種類也是設計考量之一。 (5) 減少系統網路部署時所需的花費 希望透過本系統架構，讓建置位於不同區域 Firewall/NAT 的 SIP Server 可以 輕易擴充，在部份尚未部署或未涵蓋在服務範圍內的區域只要透過本系統，便可 讓該區域的使用者連結上系統，以減少部份區域部署系統時的花費。 (6) 互通性 22.
(32) 考量所設計的系統與其他的 SIP 網路系統達到互通的能力，提供系統運作中 所必備資訊供其他 SIP 網路系統參考，以致於可利用本系統架構讓不同的 SIP 網 路系統用戶通聯。. 3.2. 系統架構 本 論 文 中 運 用 GSM 行 動 網 路 錯 誤 ! 找 不 到 參 照 來 源 。 中 HLR(Home Location Register) 與 VLR(Visiting Location Register) 概 念 於 系 統 中 將 內 部 SIP Server當作Home location，外部SIP Proxy當作Visiting Location，圖 19為本研究之 Simple Transmission Access (STA)系統架構圖，主要區域分為二部份，第一為home location zone，當使用者位於本身區域時，所有的SIP初始化訊息將由SIP Server 進行處理；第二為visiting location zone，當使用者移動至其他外部網路時歸屬於 漫遊狀態，此時SIP的訊息將由公眾的SIP Proxy代為處理轉送到內部SIP Server， 然而home location的伺服器必須先註冊到SIP Proxy下，提供visiting location zone 的使用者依據註冊訊息路徑由SIP Proxy與home location SIP Server互通。. 圖 19 STA 網路環境架構圖. 本系統中包含四個主要的網路元件： (1) SIP Server： SIP Server 的服務範圍主要為內部網路網域(Domain)使用者，其中 SIP Server 包含三種 SIP Components 角色功能，分別為 Registrar Server、Location Server、 User Agent： A. Registrar Server 主要負責所有 UA 的註冊訊息，並且根據用戶在請求中 的 SIP URI 和 IP 等聯繫資訊，紀錄儲存或更新至 Location Server 中的 資料庫。同時 Registrar Server 還兼具有使用者身份認證的功能，登錄完 畢後該用戶資訊才得以被查詢及被呼叫 B. Location Server 功能主要是維護更新或提供註冊的 UA 資訊供系統使 用，UA 若移動位置或登出時，都需要通知 SIP Server 網域下的 Location Server 去更新 UA 最新資訊，例如：URI、IP 位址和埠等等。 23.
(33) C.. User Agent 功能主要將 SIP Server 以某一帳號、密碼註冊到外部 SIP Proxy，SIP Proxy 將儲存註冊中所穿越的訊號通道(Signal Tunnel)位置資 訊，此後 SIP Proxy 與 SIP Server 之間的訊息將由此通道進行傳送。. (2) SIP Proxy： 所有 Visiting Location Zone 的使用者，透過位於公眾網路中的 SIP Proxy 將 訊息轉傳到內部網路 SIP Server。當 SIP Proxy 接收到 SIP Server 或 UA 註冊訊息 時，會將某些資訊儲存到 Location Server 以供往後規則條件判斷使用，其中 Media Controller 的使用權也是由 SIP Proxy 所掌控，在 SIP Proxy 也包含三種 SIP Components 角色功能，分別為 Registrar Server、Location Server、Outbound Proxy： A. Registrar Server 主要負責位於內部網路的 SIP Server 註冊訊息，並且將 註冊請求訊息的 SIP URI 和 IP 等聯繫資訊，紀錄儲存或更新至 Location Server 中的資料庫。同時 Registrar Server 還兼具 SIP Server 身份認證的 功能，登錄完畢後外部使用者所傳送的訊息才得已透過 SIP Proxy 轉送 到內部網路 SIP Server。 B.. C.. Location Server 功能主要是維護更新或提供註冊的 SIP Server 資訊供系 統做規則條件判斷使用，以及儲存經由 SIP Proxy 轉傳到內部網路 SIP Server 註冊的外部使用者某些資訊，比如：帳號、SIP Server 擁有者等。 當外部使用者登出時，需要通知 SIP Proxy 網域下的 Location Server 去 刪除所儲存有關外部使用者的資訊，以致在規則條件判斷時增加查詢資 料庫時的效率。 Outbound Proxy 功能主要在接收到封包時，根據 SIP 訊息的內容，決策 規則條件判斷後在進行封包修改，最後在決定轉傳到內部網路的 SIP Server 或者外部使用者。. (3) Media Controller： Media Controller 用來擔任多媒體訊息的傳送，所有經由外部網路的使用者 將透過 Media Controller 代為轉送，當雙方使用者同樣位於外部網路時，初始化 訊息會由內部 SIP Server 作為認證，但多媒體訊息將直接由 Media Controller 負 責傳送，而不會在經過內部 SIP Server。 (4) User Agent (UA)： 使用者通訊設備及執行 SIP UA 應用程式的平臺。可根據使用者位於區域， 決定是否透過 SIP Proxy 與內部網路 SIP Server 進行 SIP 訊息傳送，其中包括 Request 和 Response 訊息，以及建立通話後多媒體訊息的傳送路徑。. 24.
(34) 3.3. 系統運作模式 系統內使用者可直接或透過 SIP 代理伺服器傳送訊息給 home location SIP 伺服器，不論透過哪種方式傳送給 SIP 伺服器，主要決定權在於使用者位於區 域，至於傳送多媒體訊息的路徑也會依使用者區域而有所不同，以下將從註冊到 建立通話最後傳送多媒體訊息整個運作模式做個說明。 3.3.1. Registration 註冊部份可分為 SIP Server 以及 User Agent 二部份。 (1) SIP Server 註冊 首先SIP Server系統中有支援註冊程式，使得SIP Server將一UA身份註冊到 SIP Proxy，其中SIP Proxy會紀錄儲存註冊請求訊息的SIP URI和IP等聯繫資訊至 Location Server的資料庫內。如圖 20所示，詳細步驟如下：. 圖 20 SIP Server 註冊流程. 1、當 SIP Proxy 接收到 SIP Server 註冊訊息後，會回應 100 Trying 給 SIP Server， 告知 SIP Server 所傳送的註冊訊息已收到正在處理當中，避免 SIP Server 以為 沒收到而重傳註冊訊息。 2、接著 SIP Proxy 會將訊息中有關 SIP Server 註冊資料，如：帳號(username)、 密碼(password)、位於區域(domain)、以及封包穿越 Firewall/NAT 所映射的 NAT 公有 IP 位址、連接埠等等，儲存至 Location Server 資料庫內。其中得知 的 NAT 公有 IP 位址、連接埠為信號通道(Signal Tunnel)位置資訊，此後 visiting location zone 使用者傳送給 SIP Server 的訊息，SIP Proxy 將利用此信號通道 與 SIP Server 進行溝通。 3、最後 SIP Proxy 會傳送 200 OK 註冊成功訊息給 SIP Server。 (2) User Agent 註冊 User Agent註冊部份，位於home location zone和visiting location zone的用戶在 註冊流程有所差異。其中位於home location zone的使用者，如圖 3.3.2 所示與一 般註冊的流程一樣，所以在這不加以說明，至於visiting location zone使用者可位 於公眾網路或Firewall/NAT，二者註冊流程皆相同，所以只針對位於Firewall/NAT 25.
(35) 使用者做說明，如圖 21所示詳細步驟如下：. 圖 21 位元於不同 Firewall/NAT 用戶註冊流程. 1、首先，與 SIP Server 不同 Firewall/NAT 的 UA 會將註冊請求訊息傳送到 SIP Proxy。 2、當 SIP Proxy 接收到註冊請求訊息後，根據 SIP 訊息內容中 Request URI 的 domain，去查詢 Location Server 資料庫中註冊此 domain 值的 SIP Server 帳號， 然後得知 SIP Server 信號通道(Signal Tunnel)位置資訊，最後將 destination uri 修改為此資訊內容。其中在 SIP Proxy 處理請求方法(Request Method)訊息部 份，有自定一個規則而執行不同的動作，規則中會檢查 UA 是否位於 visiting location zone，因此只要註冊訊息透過 SIP Proxy 轉傳的 UA 帳號，都會儲存 到資料庫中。 3、接著 SIP Proxy 將修改完後的封包，經由信號通道傳送到內部 SIP Server。 4、SIP Server 接收註冊訊息後，會回應 100 Trying 訊息經由原路傳送給 UA，告 知 UA 已接收到註冊訊息正在處理中，不要在重送訊息。 5、接著將註冊請求訊息的 SIP URI 和 IP 等聯繫資訊，紀錄儲存或更新至 Location Server 中的資料庫。 6、最後 SIP Server 會傳送 200 OK 註冊成功訊息給 SIP Proxy，在由 SIP Proxy 轉 傳給 UA。 3.3.2. Call Set Up 在談論到使用者建立通聯連線前，如上述所提本系統中自定一個規則來判斷 SIP Proxy接收到請求訊息時所執行動作，圖 22、圖 23、圖 24為實際位於不同 區域的用戶傳送請求訊息的流程，經研究、討論定義出如圖 25規則，其中SIP Proxy在接收請求訊息依據所定規則會執行transmit active、forward active。transmit action代表此SIP 封包根據Requset uri (ruri)傳送到使用者目的地位址；forward active 會 修 改 封 包 destination uri 資 訊 為 先 前 SIP Server 註 冊 到 SIP Proxy 穿 越 Firewall/NAT通道的IP address、port，透過此訊號通道傳送訊息到SIP Server，其 中User-Agent Header Field值主要識別此封包是由SIP Server傳送到SIP Proxy。. 26.
(36) 圖 22 雙方使用者位於 visiting location zone. 圖 23 雙方使用者位於不同 Firewall/NAT. 圖 24 雙方使用者位於不同的區域. 圖 25 SIP Proxy 處理請求方法規則. 1.. Caller 和 Callee 位於 visiting location zone. 圖 26為雙方使用者皆位於visiting location網路環境下，由使用者分佈可分為三 種，第一種為一方在公開網路環境下，另一方位於NAT或防火牆環境下，第二種 為雙方皆位於公眾網路環境下，第三種為雙方皆位於NAT/防火牆環境下。當使 用者位於NAT/防火牆網路環境下時，SIP代理伺服器會修改所接收到的SIP訊 息，並透過與先前SIP伺服器建立的傳輸通道將SIP訊息傳入SIP伺服器中，因此 SIP代理伺服器主要任務在於將visiting location下，依使用者所在之網路環境適時 修改SIP訊息，將SIP訊息轉送到正確目的地位置。. 27.
(37) 圖 26 分佈 visiting location zone 使用者情況. 圖 27為外部使用者位於公開網路環境下傳送邀請(INVITE)訊息時的運作流 程，由於使用者位於公開網路環境下，因此需藉由visiting location下SIP代理伺服 器代為找尋本身home location位置，詳細流程如下：. 圖 27 Visiting Location 送出邀請訊息. 1、INVITE： 當 UA A 需要邀請另一位元使用者時會傳送邀請(INVITE)訊息，然而使用者 28.
(38) 位於公開網路環境下沒辦法直接傳送給 home location SIP 伺服器，因此邀請訊息 會藉由 visiting location 中的 SIP 代理伺服器代為轉傳給 SIP 伺服器來尋找受邀者 之位置。 2、check username form message： SIP 代理伺服器根據邀請者 UA A 所傳送的邀請訊息查詢 From 與 To 使用者 位置，當受邀者同樣位於公開網路時，表示 SIP 代理伺服器在暫存資料庫中搜尋 到 To 使用者資訊，根據 SIP 代理伺服器處理請求方法規則，此時 SIP 代理伺服 器會透過信號通道將邀請訊息送往與 UA A 同樣網域下位於 NAT/防火牆後的 SIP 伺服器。 3、200 OK： 當 SIP 伺服器接通時傳送 200 OK 傳送回 SIP 代理伺服器，由 200 OK 中的 SDP 可得知傳送 RTP 時相關的資訊，當 UA A 接收到 200 OK 訊息時，藉由連接 埠與 IP 位址傳送 RTP 資訊。 4、ACK： UA A 接收到 200 OK 時會回覆 ACK 訊息告知 SIP 伺服器訊息已成功接收， 同樣的每個 SIP 訊息會經由 SIP 代理伺服器處理請求方法規則決定下一步動作。 圖 28為SIP伺服器接收到由公開網路環境使用者傳送邀請訊息時的運作流程， 詳細流程如下：. 圖 28 Visiting Location 接收邀請訊息. 29.
(39) 1、INVITE： 當 SIP 伺服器接收到邀請訊息時會透過本身 location 資料庫查詢受邀者傳輸 路徑，並且藉由 SIP 訊息中 Via 欄位得知訊息是由 SIP 代理伺服器所傳送，因此 將邀請訊息傳送到 SIP 代理伺服器下。 2、check username form message： 根據 SIP 代理伺服器處理請求方法規則，由於經由 SIP 伺服器傳送的邀請訊 息，在 SIP 訊息中 User Agent 欄位會是＂SIP Server＂，因此 SIP 代理伺服器會 執行 transmit action 並直接由 RURI 資訊傳送 SIP 訊息給 UA B。 3、200 OK： UA B 接收到邀請訊息時會傳送 200 OK 並將本身 RTP 相關訊息藉由 SDP 傳 送到 SIP 伺服器上。 4、ACK： 當 SIP 伺服器接收到 200 OK 時表示受邀者準備就緒，此時會傳送 ACK 訊 息給 UA B。 圖 29為雙方使用者建立SIP會議後SIP伺服器重新傳送邀請訊息讓外部使用者藉 由visiting location下的Media Controller傳送多媒體訊息，藉此減輕SIP伺服器所需 負擔，詳細流程如下：. 圖 29 Home Location 送出 reINVITE. 30.
(40) 1、reINVITE： 當雙方使用者建立完 SIP 會議後，SIP 伺服器會重新傳送邀請訊息給 UA A 與 UA B 使用者，而在 reINVITE 訊息中將會修改 SDP 的「c (Connect)」與 「m (Media)」欄位資訊為 Media Controller 的 IP 位址與 RTP 連接埠。 2、check username from message： 根據 SIP 代理伺服器處理請求方法規則，由於經由 SIP 伺服器傳送的邀請訊 息，在 SIP 訊息中 User Agent 欄位會是＂SIP Server＂，因此 SIP 代理伺服器會 執行 transmit action 並直接由 RURI 資訊將 reINVITE 傳送到 UA A 與 UA B。 3、200 OK： 當 UA A 與 UA B 接收到 reINVITE 訊息時回覆 200 OK 給 SIP 伺服器，表示 訊息已接收。 4、RTP： 接收到 reINVITE 訊息後，雙方使用者在 RTP 傳輸路徑上由原本需傳送到內 部 SIP 伺服器的路徑變更為傳送到 Media Controller 伺服器上，透過 reINVITE 減 輕 SIP 伺服器網路負擔，而在外部網路的使用者無需將 RTP 資訊傳送回內部網 路伺服器，由 visiting location 提供的 Media Controller 可縮短 RTP 傳輸路徑。 2.. UA 位於 Home Location 與 Visiting Location 環境：. A. 由 Home UA 傳送邀請訊息： 當任何一方UA位於Visiting Location網路環境下時，需要藉由SIP代理伺服器 代為找尋內部SIP伺服器，圖 30為Home Location使用者送出邀請訊息到Visiting Location使用者網路環境圖，SIP伺服器透過預先與Visiting Location建立之傳輸通 道與SIP代理伺服器交換訊息，經由SIP代理伺服器找尋使用者B實際通訊位址， 提供Home Location完成SIP會議的建立。. 圖 30 Home 與 Visiting Location 環境圖–由 Home UA 傳送邀請訊息. 31.
(41) 圖 31 Home 與 Visiting Location 流程圖–Home UA 傳送邀請訊息. 1.INVITE： 由使用者 B 傳送邀請訊息到 SIP 伺服器，此時 SIP 伺服器會建立 SIP 會議並 傳送 200 OK 訊息回覆給 B 使用者。 2.Server INVITE： 由於使用者 A 在註冊時的傳輸路徑是經由 SIP 代理伺服器負責轉送，因此 當 SIP 伺服器透過 Location 資料庫查詢使用者 A 資訊時，得知邀請訊息必須送 往 SIP 代理伺服器，因此 SIP 伺服器會將邀請訊息轉送到 SIP 代理伺服器，代理 伺服器根據 SIP 訊息中 RURI 位址負責傳送到使用者 A。 3.Check message： SIP 代理伺服器會將所有透過 Visiting Location 使用者資訊暫存至代理伺服 器所屬的 Location 資料庫，因此透過資料庫的查詢代理伺服器得知使用者 A 實 際通訊位置，並將邀請訊息加入 SIP 代理伺服器之 Via 欄位資訊並傳送到使用者 A。 4.200 OK 與 ACK 經由 SIP 訊息中的 Via 與 RURI 資訊可得知訊息的目的端位置，使得 SIP 伺 服器與 SIP 代理伺服器可透過先前建立的傳輸通道順利的建立 SIP 會議。 5.RTP： SIP 會議建立完成後使用者 B 會經由 SIP 伺服器負責傳送 RTP 訊息到 Visiting Location 環境下的 Media Controller 伺服器，負責外部網路使用者傳送 RTP 訊息 32.
(42) 的主要伺服器。 B. 由 Visiting UA 傳送邀請訊息： 圖 32為使用者由Visiting Location傳送邀請訊息到SIP伺服器環境圖，當SIP代理 伺服器接收由外部網路使用者所傳送的邀請訊息時，SIP代理伺服器必須藉由 Location資料庫查詢該使用所處的Home Location位置，並將邀請訊息藉由先前所 建立的傳輸通道與Home Location溝通。. 圖 32 Home 與 Visiting Location 環境圖–由 Visiting UA 傳送邀請訊息. 圖 33 Home 與 Visiting Location 流程圖–由 Visiting UA 傳送邀請訊息. 1.INVITE： 當使用者位於 Visiting Location 環境下的 NAT 或防火牆時 SIP 代理伺服器會 修改由使用者 A 傳送出來的邀請訊息，藉由接收到 NAT 或防火牆的 SIP 訊息， SIP 代理伺服器將修改 Via、Contact，並加入 receiver、rport 等欄位資訊，確保後 續訊息皆可正確的傳送到 NAT/防火牆內使用者。 2.Check message： SIP 代理伺服器接收到邀請訊息時會透過 Location 資料庫查詢使用者名稱， 當受邀者使用名稱不在 Location 資料庫時表示受邀者位於 Home Location 網路 下，此時代理伺服器檢查 SIP 訊息中 RURI 位置決定傳送於那一個 Home Location 33.
(43) 網路。 3.RTP： 由 INVITE 與 200 OK 訊息可得知使用者雙方通訊位置，由於使用者 B 位於 Home Location，因此 B 所送出的 RTP 訊息將由 SIP 伺服器代為轉送，而使用者 A 位於 Visiting Location，因此 A 位於 NAT 或防火牆內所送出的 RTP 將由 Media Controller 伺服器負責轉送。 3.. UA 位於 Home Location 環境：. 圖 34為雙方使用者皆位於Home location環境圖，如一般SIP會議建立方式，使用 者直接與SIP伺服器傳送SIP信號與RTP訊息，由於使用者皆位於Home location， 因此SIP伺服器不需將SIP信號傳送到Visiting location。. 圖 34 Home location 用戶通訊環境圖. 圖 35 Home location 用戶通訊流程圖 34.
(44) 1.INVITE： 當 A 使用者傳送邀請訊息時，SIP 伺服器會透過 Location 伺服器查詢 B 使 用者通訊路徑，由於 SIP 伺服器預設使用主從式架構傳輸 RTP 訊息，因此伺服 器回覆 200 OK 時，訊息中的 SDP 資訊為 SIP 伺服器的 IP 位址與 RTP 通訊埠， 當 SIP 會議建立完成後 A 使用者會將 RTP 資訊傳送到 SIP 伺服器。 2.Server INVITE： SIP 伺服器藉由 Location 伺服器查詢到 B 使用者通訊位置時，會經由該通訊 位置傳送邀請訊息到 B 使用者，當使用者 B 回覆 200 OK 後，SIP 伺服器會傳送 ACK 訊息表示 SIP 會議建立完成。 3.RTP： 位於 Home location 使用者在傳送 RTP 訊息時會經由 SIP 伺服器代為轉送， 因此 SIP 伺服器保有對於 Home location 下使用者之控制權。. 35.
(45) 第四章、 系統實作 4.1. 測試環境 依網路環境可分為三種測試項目：安全性、限制性、減輕 SIP Server 負載量， 每個測試項目分別由數個使用者負責產生 SIP 與 RTP 資訊，每個使用者分別產 生 10 至 20 通電話，因此伺服器將負擔不同的同時通話數量並進行比較。在測量 的過程中將監測點設為 UAC 方，測量 UAC 從建立到終結 SIP 會議所需時間， 與 UAS 經由伺服器與網路傳送到 UAC 的 RTP 封包資訊，藉此觀察封包延遲時 間(Delay)與抖動率(Jitter)。 由延遲時間可得知 UAC 聽取 UAS 多媒體資訊時，每個封包所產生的延遲 時間，當延遲時間增加時 UAC 所聽取的語音或影像將會斷斷續續，因此延遲時 間可直接說明使用者在使用不同系統時的通話品質。 抖動為延遲時間之變化量，因此抖動與延遲時間息息相關，當抖動時間分佈 的愈平均時，表示伺服器的用戶量還在可承受的負載範圍內，由於每個測量項目 網路環境皆相同，因此只有伺服器會影響延遲時間與抖動時間，當抖動時間分佈 的愈不平均時，表示系統開始出現負載現象。 如 表 5、 表 6與 表 7為實際測試環境中SIP Server、SIP Proxy與Media Controller軟硬體環境，由Asterisk扮演SIP Server作為接收與傳送SIP訊息，使用 OpenSER作為SIP代理伺服器，而RTP Proxy當作Media Controller轉送使用者之間 的RTP多媒體資訊。 表 5. SIP 伺服器軟硬體環境. CPU. Intel Celeron D CPU 3.20GHz. RAM. 512 MB. OS. Linux debian 2.6.18-4. SIP IP PBX Asterisk-1.2.17 表 6. SIP Proxy 軟硬體環境. CPU. Intel Celeron D CPU 3.20GHz. RAM. 512 MB. OS. Linux debian 2.6.18-4. SIP Proxy. OpenSER 1.1.1-notls. 表 7. Media Controller 軟硬體環境. CPU. Intel Pentium 4 CPU 3.40GHz. RAM. 1GB. OS. Linux debian 2.6.18-4. RTP Server. rtpproxy-0.3. 36.
(46) 4.2. 安全性 A. SipDual-Start 環境模擬 在 SipDual-Start 架構中由 NAT/防火牆內的 SIP 伺服器作為主要伺服器，透 過更改 NAT/防火牆提供外部用戶與內部網路伺服器通訊，NAT/防火牆必須設置 通訊埠轉送(port forward)選項並且增加 SIP 伺服器所開啟的 RTP 連接埠範圍。藉 由增加通訊埠轉送的方式測量使用者位元於內部網路與外部網路環境下 SIP 建 立到終結的時間、RTP 延遲時間與抖動時間。. 圖 36 SipDual-Start 模擬環境架構. B. STA (Simple Transmitter Access)環境模擬 在 STA 架構中由 SIP Server 所組成的 home location zone 與外部 SIP Proxy 所 組成的 visiting zone 之間保有一條傳輸通道，此傳輸通道由 location zone 伺服器 建立，藉此提供 visiting zone 用戶可與 location zone 使用者溝通，在不需更動 NAT 或防火牆的情況下測量由 home location 與 visiting zone 溝通時 SIP 建立到終結的 時間、RTP 延遲時間與抖動時間。. 圖 37 STA 模擬環境架構. 37.
(47) 數據分析 圖 38與 圖 39為二種架構環境下在NAT/防火牆所開啟的連接埠比較圖，在 SipDual-Start架構環境下必須增加SIP伺服器所使用的RTP連接埠範圍到NAT/防 火牆的通訊埠轉送列表，而一個只傳送語音的RTP會議對於伺服器需要使用 4 個 連接埠，因此當SIP伺服器欲提供外部 50 個使用者時必須在NAT/防火牆上開啟 200 連接埠，當一個RTP會議需提供語音與影像時需開啟 8 個連接埠，因此需在 NAT/防火牆上開啟 400 連接埠，然而在STA架構依外部使用者人數的多寡開啟適 當的連接埠數量。 250 200. 200. 200. port number. 200 150. 200200. 120. STA sipdual-start. 80. 100 50. 200 160. 40. 0 10. 20. 30. 40. 50. call number. port number. 圖 38 RTP audio port number. 450 400 350 300 250 200 150 100 50 0. 400. 400. 400. 400. 400400. 320 240. STA. 160. sipdual-start. 80. 10. 20. 30. 40. 50. call number. 圖 39 RTP audio/video port number. STA 和 SipDual-Start 會話建立時間比較 在 STA 架構中為瞭解決開啟過多的連接埠而增加了 visiting zone 的 SIP Proxy 伺服器，提供外部使用者與內部伺服器溝通的角色，如下圖所示在 20 與 30 通同時通話數情況下 SipDual-Start 與 STA 在 SIP 會議建立與終結時間並無太 大的差別，因此藉由 visiting zone 轉送 SIP 會議到內部 SIP 伺服器除了可解決開 啟過多連接埠問題外，並不會對於 SIP 會議建立與終結時間有太大的影響。. 38.
(48) STA 和 SipDual-Start 延遲時間比較 下圖為 STA 架構與 SipDual-Start 架構在 20 到 30 通同時通話數環境下 RTP 延遲時間比較，由於 STA 架構中需經由 Home location SIP 伺服器與 visiting Media Controller 伺服器轉送使用者 RTP 訊息，因此在延遲時間表現上比 SipDual-Start 在 NAT/防火牆上開啟通訊埠轉送來的差。. 小結： 在 SipDual-Start 架構中需要先設想最多使用者人數，然後預先在 NAT/防火 牆開啟多少埠以及埠的範圍。假如所傳送 RTP 資料只有語音部份，Asterisk 至少 要開啟四個埠，如果是語音/影像至少要開啟八個埠，其 NAT/防火牆也要開啟相 同埠數以及 Asterisk 預設開啟傳送 RTP 埠的範圍以做通訊埠轉送動作。 假設現在二個架構預設使用者最多上限人數為 30 人，在 STA 架構中，如果 有 30 個用戶要求通聯(純語音)連線時，在 NAT/防火牆會自動開啟 120 埠，但是 通聯結束後所開啟的埠馬上關閉，但在 SipDual-Start 架構中 NAT/防火牆所開啟 的埠還是 120 個，但是通聯結束後他的埠還是一樣開啟；而如果只有 10 用戶要 求通聯(純語音)時，STA 架構在 Firewall/NAT 只要開啟 40 埠即可，但在 SipDual-Start 架構中還是開啟 120 埠，而只要使用到 40 埠。 比較二者架構後，STA 架構其安全性會比 SipDual-Start 來的好，但缺點受限 於 RTP Proxy 效能，RTP 延遲時間會比較。 39.
(49) 4.3. 限制性 非對稱式 NAT (1) SipDual-Start 環境模擬 圖 40為SipDual-Start系統環境圖由於SIP伺服器位於NAT/防火牆下，因此對於伺 服器所屬的NAT/防火牆(Zyxel35)必須手動設定通訊息轉送的功能，提供外部位 於公開網路環境下用戶傳送到Zyxel35 的SIP協定與RTP訊息轉送到內部SIP伺服 器下。然而位於另外一方NAT/防火牆(Zyxel5)下的使用者在傳越Zyxel5 時需搭配 STUN伺服器，提供Zyxel5 位於公開網路環境下的IP與連接埠資訊，使用者藉由 STUN所提供的資訊修改SIP訊息傳送到Zyxel35 並轉送到SIP伺服器達到SIP會議 的建立與RTP訊息傳送能力。 A.. 圖 40 SipDual-Start 模擬環境圖. (2) STA (Simple Transmitter Access)環境模擬 在 STA 網路環境下，內部網路 SIP 伺服器會先與 Visiting Location 下的 SIP 代理伺服器建立通訊連接路徑，而 Visiting Location 下的 SIP 代理伺服器功能只 在於暫存外部使用者資訊息，並且負責將 SIP 訊息轉送到使用者所屬的 Home Location 網路下。在 SIP 會議建立的過程中 SIP 代理伺服器會將 SIP 訊息轉送到 Home Location 的 SIP 伺服器下，由 SIP 伺服器保有對使用者之控制權，而 SIP 代理伺服器只提供轉送的服務，當使用者位於 Visiting Location 網路環境下時， RTP 訊息會透過 Media Controller 進行轉送的服務，因此位於 Visiting Location 網 路環境 NAT/防火牆的使用者可透過 Media Controller 轉送 RTP 訊息。. 40.
數據
+7
![圖 16 SipDual-Start 系統架構環境圖 其中在 NAT 穿越時分為二個問題來討論[15]： z SIP 信號穿越於 NAT z RTP 多媒體資訊穿越於 NAT 1、 SIP Signaling 問題 (1) 從公開網路傳入之 SIP 信號 當遠端使用者傳送封包給家庭個人工作室的 SIP 伺服器時，傳送的封包會經 由 ADSL Modem Router，再轉送到工作室的 Asterisk 伺服器，但是當 ADSL Modem Router 接收到封包時，因為不知道封包是要](https://thumb-ap.123doks.com/thumbv2/9libinfo/8791096.220280/29.892.132.774.116.283/系統架其中在SIP問題從公開網路傳入之信號當遠傳送工作室的伺服.webp)
Outline
相關文件
However, NTP SIPv6 UA cannot communicate with CISCO PSTN gateway, and CCL PCA (IPv6 SIP UA) cannot communicate with CISCO PSTN gateway and Pingtel hardware-based SIP phone.
A host connecting to the outside network is allocated an external IP address from the address pool managed by NAT... Flavors of
Binding Warning message Binding Update message AAAO: the AAA server of the old foreign network to which the OFA belongs. AAAF: the AAA server of the new foreign network to which the
n The information contained in the Record-Route: header is used in the subsequent requests related to the same call. n The Route: header is used to record the path that the request
n Another important usage is when reserving network resources as part of a SIP session establishment... Integration of SIP Signaling and Resource
"Distributed Management Architecture for Multimedia Conferencing Using SIP" ,Moon-Sang Jeong, Jong-Tae Park, and Wee-Hyuk Lee, International Conference on DFMA ,2005..
當 Bundle 啟動後會將自身所提供的服務註冊到 Service Registry 中，如圖 2-12，Service Registry 會對部署在 OSGi Framework 的 Bundles 發送新加入 Bundle 的 Service
Registry Server 是建構於第三方具有公信力的一個組織，而 Registry Server 在 Web Service 的架構中，主要的功能類似於提供服務查詢(Yellow
