第三章 SIPv6 Translator系統實作原理
3.3 SIP-ALG實作方法一與二之比較
表 3-1 對 SIP-ALG 實作方法一與二作比較。圖 3-1（a）顯示 SIP-ALG 實作方法一 在程式開始以 SIPMessage 資料結構來儲存 SIP 訊息。因此，在除錯與程式的正確性 上，可以隨時針對 SIP 訊息內容作新增、修改與刪除，並可以很輕易地更動圖 3-1 之程 式架構。但產生 SIPMessage 資料結構將導致記憶體配置與釋放的動作大量增加，非 常浪費運算時間。在圖 3-1○2 搜尋特定的 SIP 標頭欄位時，因為是採用串列資料結構儲 存每筆 SIP 標頭欄位，因此每次搜尋 SIP 標頭名稱都必須要從頭開始搜尋，此一程序會 增加運算時間。
為了提升 SIP-ALG 的運算速度，SIP-ALG 實作方法二針對 SIP 訊息的結構，採取 讀入輸入緩衝區後直接轉換標頭，然後再寫入輸出緩衝區。因此，實作方法二對所有 SIP 與 SDP 欄位僅需要讀取一次，即可將所有特定欄位轉換完畢。而在實作方法一，
由於一開始就已經將 SIP 訊息存在 SIPMessage 資料結構中，每當要對 SIP 與 SDP 特 定 標 頭 作 轉 換 之 前 ， 就 必 須 先 分 別 對
SIPMessageHeader
與SIPMessageBodyContent 資料結構內所有 FieldName 作搜尋。假設有 n 個特定欄
位（包含 SIP 與 SDP 標頭）需要作轉換，就必須對 SIPMessage 資料結構做 n 次搜尋。實作方法二的優點是效能比實作方法一好很多，詳細數據可以參考第四章效能測量實 驗，但缺點則是程式架構比較不易更動。
表 3-1 SIP-ALG 實作方法一與二之比較表
O (1) O (n)
Search SIP Headers
No
Structure SIP Message
YesMethod 2 Method 1
O (1) O (n)
Search SIP Headers
No
Structure SIP Message
YesMethod 2
Method 1
第四章
SIPv6 Translator 之互通性測試與效能評 估
本章節介紹本論文對 SIPv6 Translator 所作的測試實驗。測試實驗總分為兩部份：
（1）SIPv6 Translator 系統之互通性測試實驗與（2）SIPv6 Translator 系統之效能測試 實驗。
4.1 SIPv6 Translator 系統之互通性測試實驗
為了驗證 IPv6 SIP UA 是否可以透過 SIPv6 Translator 與 IPv4 SIP UA 通訊，本實驗 針對電信國家型計畫（National Telecommunication Program；簡稱 NTP） VoIP 平台之 SIPv4 軟硬體設備做了互通性（Interoperability）測試實驗。
互通性測試實驗環境架構圖如圖 4-1 所示。在 IPv6 網路環境中，IPv6 SIP UA（本 節中簡稱 UA1）擔任撥話者（Calling Party），測試設備採用本實驗室所開發的 SIPv6 UA。在 IPv4 網路環境中，IPv4 SIP UA（本節中簡稱 UA2）擔任受話者（Called Party），
測試設備採用 NTP VoIP 平台之 SIPv4 軟硬體設備，包括軟體電話設備（包括 Windows Messenger 4.7 與 CCL Vontel Skin UA）、硬體電話設備（包括 PinTel 2.1.10、snom 200
除錯與分析，我們同時在 IPv6 網路與 IPv4 網路上安裝封包分析器（SIPv6 Analyzer），
來觀察轉換前的 SIP 訊息以及轉換後的 SIP 訊息。
SIPv6 Analyzer-1
CCL Vontel Skin UA IPv6 SIP UA (UA1)
IPtel SER NCTU SIP Server SIPv6 Translator
Cisco 2621 Gateway IPv4 SIP UA (UA2)
SIPv6 Analyzer-1
CCL Vontel Skin UA IPv6 SIP UA (UA1)
IPtel SER NCTU SIP Server SIPv6 Translator
Cisco 2621 Gateway IPv4 SIP UA (UA2)
圖 4-1 SIPv6 Translator 系統之互通性測試環境架構圖
我們在實驗過程之中，先讓 SIP-ALG 模組轉換 SIP 標頭中有關路由的 Request-URI 與 Contact、Via 標頭欄位以及 SDP 標頭中 c 欄位，再觀察 NTP VoIP 平台中的軟硬體 設備是否能正常運作，若不能運作，我們會觀察錯誤原因並逐漸加入其他欄位含有 IP 位址的必要轉換。實驗結果顯示，UA1 與 Windows Messenger 4.7 網路電話軟體建立通 話時，Windows Messenger 4.7 會因為在分析 SIP 標頭欄位時檢查到 IPv6 位址，而在視 窗中顯示錯誤訊息，並直接切斷這個連線且不回應任何的 SIP 訊息給 UA1（如圖 4-2 所示）。此時當其他的 SIP UA 想要與 Windows Messenger 4.7 建立通話時，Windows Messenger 4.7 一律會回 ”486 Busy Here”，我們推論可能是因為 Windows Messenger 4.7 讀到 IPv6 位址顯示錯誤時，SIP 撥話者狀態機（State Machine）未回到最後狀態而造成
由圖 4-2 的錯誤訊息與圖 4-3 封包分析器交叉比對，得知此 IPv6 位址為 From 欄位 內的值，因此當 SIPv6 Translator 在增加了 From 欄位的轉換之後，UA1 與 Windows Messenger 4.7 即可正常通訊，因此可知除了上述的 Request-URI、Contact、Via 標頭欄 位以及 c 欄位之外，Windows Messenger 4.7 還會檢查 From 標頭欄位。
圖 4-2 Windows Messenger 4.7 無法判讀 IPv6 位址
圖 4-3 Windows Messenger 4.7 無法判讀 IPv6 位址之封包擷取畫面
Cisco 所製造的 IP Phone 7940 Series 與 Cisco 2621XM 設備，檢查的欄位更多。如 圖 4-4 所示，當 SIPv6 Translator 加入了 From 標頭欄位轉換之後，Cisco 設備仍然會回 覆”400 Bad Request”給 UA1，由結果判斷 SIP 訊息中仍然有標頭欄位需要轉換。如圖 4-5 所示，接著當 SIPv6 Translator 同時加入了 From 與 To 標頭欄位轉換之後，Cisco 設 備仍然會發出”400 Bad Request , Warning: 399 Invalid SDP Message”，由此結果判斷 SDP 中仍然有欄位需要轉換。最後，當 SIPv6 Translator 同時加入了 SIP From、To 標頭欄位 以及 SDP 標頭中 o 欄位的轉換之後，UA1 與 Cisco 設備即可建立通訊。因此，我們由 實驗結果推測，這 Cisco 的網路電話設備會將所有與 IP 位址相關的欄位全部都做檢查。
圖 4-4 未修改 SIP 標頭中的 From 或 To 標頭欄位
圖 4-5 未修改 SDP 標頭中的 o 欄位
最後將實驗結果整理如下表 4-1 所示，我們將各 SIP UA 設備需檢查 IP 資訊的 SIP 與 SDP 欄位列出，必定會檢查欄位的欄位以打勾表示。由表 4-1 可知 CCL Skin UA、
Vontel PSTN Gateway、美國廠商所製造的 PingTel 2.1.10 以及德國廠商所製造的 snom 200，僅檢查 SIP 訊息的 Request-URI、Contact、Via 標頭欄位與 SDP 中的 c 欄位，即
與 UA1 建立通訊。由實驗結果得知，加入了 SIP 的 From 與 To 標頭欄位以及 SDP 標 IP Hard Phone IP Soft Phone
SDP Fields SIP Header Fields
v Cisco IP Phone
7940 Series Windows Messenger
4.7.2009 CCL Skin UA
c IP Hard Phone IP Soft Phone
SDP Fields SIP Header Fields
v Cisco IP Phone
7940 Series Windows Messenger
4.7.2009 CCL Skin UA
c
v: The Field must be translated.
-: The Field may not be translated.
在本實驗的互通性測試之中，SIPv6 Translator 可以讓 SIPv6 UA 與電信國家型計畫 所佈建的 SIPv4 軟硬體以及 PSTN 閘道器相互通訊，證明 SIPv6 Translator 可以支援大 多數的 SIPv4 電話網路設備。此一成果也可以支援 NICI IPv6 基礎建設分組，讓 IPv6 SIP 網路建置成果與現有 IPv4 電話網路相互通訊。
4.2 SIPv6 Translator 系統之效能量測實驗
為了分析本系統 SIPv6 Translator 的效能，我們觀察 SIP 撥話者通話建立時所增加 的延遲時間，來作為 SIPv6 Translator 系統之效能量測實驗的評估依據。
為了快速地開發出 SIP 通話建立訊息測試程式，本論文採用開放原始碼的 osip 以 及 eXosip 函式庫套件作為底層開發模組[23,24]。撥話者發出 SIP INVITE 要求到發出 SIP ACK 要求這段時間為通話建立時間，我們定義為通話建立時間（Call Setup Time；
簡稱 CST）。如圖 4-6 所示，本實驗中以測量 CST 所增加的延遲時間來評估 SIPv6 Translator 的效能。
Ti m e
UAC UAS
CST
INVITE
180 Ringing 200 OK
ACK 100 Trying
UAC: User Agent Client UAS: User Agent Server CST: Call Setup Time UAC: User Agent Client UAS: User Agent Server CST: Call Setup Time
圖 4-6 SIP 通話建立之訊息流程圖
IPv4 Network IPv4 Network
(NTU) (NTU)
SIPv6 Translator
IPv4 SIP UA (UA1)
IPv6 SIP UA (UA2)
NTU SIP Server
NCTU SIP Server IPv4 SIP UA
(UA3)
圖 4-7 SIPv6 Translator 系統之效能量測實驗環境架構圖
效能測試實驗環境架構圖如圖 4-7 所示。UA1 與 UA3 為 IPv4 SIP UAs，UA2 為 IPv6 SIP UA。UA1 與 UA2 擔任為撥話者，UA3 則擔任受話者。接下來我們以三個實驗來 測試 SIPv6 Translator 所增加的額外負擔，每個實驗分成實驗組 a 與對照組 b。實驗組 表示此實驗環境不包含 SIPv6 Translator，對照組表示此實驗環境包含 SIPv6 Translator。
藉由實驗組與對照組的比較，就可以得到 SIPv6 Translator 所增加的延遲時間。底下描 述各分項實驗之環境架構。
如圖 4-8 所示，在最簡單的環境（實驗 1）下，兩個 UAs 不需要透過 SIP 伺服器直 接互相連線。實驗 1 的目的是在最簡單的環境下測量 SIPv6 Translator 所增加的 CST。
在實驗 1a，UA1 與 UA3 之間直接透過網路線連接。在實驗 1b，UA2 與 UA3 透過 SIPv6 Translator 連接。
SIPv6 Translator 透過 NCTU SIP 伺服器與 UA3 建立通話。在實驗 2b，UA2 會先經過 SIPv6 Translator 的轉換，再透過 NCTU SIP 伺服器與 UA3 建立通話。比較實驗 1 與 2，我們可以得到 SIPv6 Translator 與 SIP 伺服器之 CST。
SIPv6 Translator
給 NCTU SIP 伺服器，然後再透過 NTU SIP 伺服器傳給 UA3 來建立通話。實驗 3 增加 了從 NCTU 到 NTU 網路之間經過了兩次 TANet（Taiwan Academic Network）骨幹網路 傳輸，因此比較實驗 2 與 3 可得網路傳輸之 CST。
CST 大約增加 11.3 ms；而經過 SIPv6 Translator，CST 大約增加不到 1 ms。由此可知，
SIP 伺服器、網路以及 SIPv6 Translator 都會增加 CST 的負擔，在這些因素之中，SIPv6 Translator 的影響最小。
表 4-2 SIPv6 Translator 在各分項實驗中所增加負擔之比較
實驗2b (Method 1)
932 (4.93%) 967 (24.15%) 0
Extra Overhead19823.7192 實驗3b (Method 1)
4970.3859 實驗1b (Method 1)
4003.3634
實驗2b (Method 1)
932 (4.93%) 967 (24.15%) 0
Extra Overhead19823.7192 實驗3b (Method 1)
4970.3859 實驗1b (Method 1)
4003.3634 實驗1a
Mean CST (us)
表 4-3 比較 SIP-ALG 實作方式一與二的效能。SIPv6 Translator 採用方法二來實作 SIP-ALG，對 CST 所增加的負擔大約 0.2 ms，效能大約比方法一提升近 5 倍。從實驗 1 來看，SIPv6 Translator 所增加的負擔降到了 5.07%，在實驗 2 更是降到了 2.76%。
表 4-3 SIP-ALG 實作方法一與二之效能比較
989 (13.02%)
8584.6394實驗2b (Method 1)
210 (2.76%)
7805.0647
實驗2b (Method 2)
203 (5.07%)
4206.1100
實驗1b (Method 2)
967 (24.15%)
Extra Overhead
4970.3859
實驗1b (Method 1)
Mean CST (us)
989 (13.02%)
8584.6394實驗2b (Method 1)
210 (2.76%)
7805.0647
實驗2b (Method 2)
203 (5.07%)
4206.1100
實驗1b (Method 2)
967 (24.15%)
Extra Overhead
4970.3859
實驗1b (Method 1)
Mean CST (us)
實驗結果顯示，SIP-ALG 實作方法二的效能比方法一提升接近 5 倍。一個 SIP Proxy 所增加的時間延遲大約為 3.6 ms，經過了網路之後，所增加的時間延遲大約為 11.3 ms，
而本論文的 SIPv6 Translator 系統僅僅增加了大約 0.2 ms 的負擔，幾乎可以被忽略不計。
第五章 結論
由於越來越多人使用 SIP 網路電話，每個網路電話裝置都至少需要一個 IP 位址。
隨著網路電話的普及，IPv4 將不足以分配給每一台網路電話。IPv6 提供大量的 IP 位址 來解決 IPv4 位址不足的問題，但在 IPv6 佈建初期，大多數的 SIP 網路電話仍只支援 IPv4。本論文提出 SIPv6 Translator 系統之設計與實作，提供一個 SIP 協定的轉換機制，
讓 IPv6 網路電話使用者與 IPv4 網路電話使用者可以互相通訊。SIPv6 Translator 系統以 NAT-PT 機制為基礎，加入了 SIP-ALG 轉換機制，針對 SIP 訊息內的 IP 資訊作轉換，
讓 SIP 訊息可以在 IPv6 與 IPv4 網路 SIP 設備之間正確的傳遞。SIP 伺服器、網路路由 以及 SIPv6 Translator 都會對 SIP 通話建立的時間造成影響，然而在這些影響 SIP 通話 建立時間的因素之中，以 SIPv6 Translator 系統所增加的負擔最小，其中 SIP-ALG 實作 方法二之延遲幾乎可以被忽略。
未來期望以 SIPv6 Translator 的開發成果，協助 NICI IPv6 基礎建設分組之 IPv6 SIP 網路之建置，藉 SIP 網路電話之應用來推動國內 IPv6 之使用，並促進 SIP 設備廠商進 一步研發 IPv6 SIP 網路電話設備。此成果對於 IPv6 與 VoIP 的推廣均有相當大的助益。
參考文獻
[1] Tsirtsis, G., and Srisuresh, P., “DNetwork Address Translation - Protocol Translation (NAT-PT)”, RFC 2766, February 2000.
[2] Nordmark., E., “Stateless IP/ICMP Translation Algorithm (SIIT)”, RFC 2765, February 2000.
[3] Postel, J. (ed.), "Internet Protocol - DARPA Internet Program Protocol Specification”, STD 5, RFC 791,USC/Information Sciences Institute, September 1981.
[4] J. Postel, "Transmission Control Protocol", STD 7, RFC 793, USC/Information Sciences Institute, September 1981.
[5] J. Postel, "User Datagram Protocol", STD7 , RFC 768, USC/Information Sciences Institute, August 1980.
[6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC
2460, December 1998.
[7] Hinden, R. and S. Deering, "Internet Protocol Version 6 ( IPv6 ) Addressing Architecture", RFC 3513, April 2003.
[8] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[9] Conta, A. and S. Deering, "ICMP for the Internet Protocol Version 6 (IPv6)", RFC 2463, December 1998.
[10] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[11] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[12] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC
1035, November 1987.
[13] Thomson, S. , Huitema, C., Ksinant, V. and M. Souissi, "DNS Extensions to support IP version 6", RFC 3596, October 2003.
[14] Bush, R., "Delegation of IP6.ARPA", BCP 49, RFC 3152, August 2001.
[15] Srisuresh, P., Tsirtsis, G., Akkiraju, P., and Heffernan, A., “DNS extensions to Network Address Translators (DNS_ALG)”, RFC 2694, September 1999.
[15] Srisuresh, P., Tsirtsis, G., Akkiraju, P., and Heffernan, A., “DNS extensions to Network Address Translators (DNS_ALG)”, RFC 2694, September 1999.