VoIPv6通話品質測試工具之研製

國立交通大學

網路工程研究所

碩

碩

碩 士

士

士 論

論

論 文

文

文

VoIPv6

通話品質測試工具之研製

Design and Implementation of Voice Quality Testing Tool for

VoIPv6 Environments

研 究 生：宋岳鑫

指導教授：林一平 博士

VoIPv6

通話品質測試工具之研製

Design and Implementation of Voice Quality Testing Tool for VoIPv6

Environments

研 究 生：宋岳鑫 Student：Yueh-Hsin Sung 指導教授：林一平 Advisor：Yi-Bing Lin

國 立 交 通 大 學

網 路 工 程 研 究 所

碩 士 論 文

A Thesis

Submitted to Institute of Network Engineering College of Computer Science

National Chiao Tung University in partial Fulfillment of the Requirements

for the Degree of Master

in

Computer Science July 2007

Hsinchu, Taiwan, Republic of China

VoIPv6

通話品質測試工具之研製

學生：宋岳鑫

指導教授：林一平 博士

國立交通大學網路工程研究所碩士班

摘

要

VoIP (Voice over IP) 為第三代行動通訊 IMS (IP Multimedia Subsystem) 中最重 要的服務之一。在 IMS 中， VoIP 分別以 SIP (Session Initiation Protocol) 與 RTP (Real-time Transport Protocol)協定來傳輸信令和多媒體資訊，並採用 IPv6 (IP version 6) 來提供大量的位址空間。在建置 IMS 應用服務時，需要分析器與測試工具研究相 關通訊協定，並對所佈建的系統進行效能測試。本論文針對 IMS 的多媒體應用服務 設計並實作 SIPv6 Analyzer ，在分析功能上提供各種通訊協定標頭的解析，並針對 SIP 對話產生 SIP 信令流程圖、播放 RTP 語音或影像串流，以及提供封包統計功能。 搭配 SmartBits 硬體平台提供測試功能，具有 IPv6 通道 (Tunnel) 建立的能力，可以 測試各種 IPv6 使用環境、可以發送 SIP 訊息以進行 SIP 通話建立流程，以及利用 SmartLibrary 控制 SmartBits 硬體產生多個封包串流，測試所佈建的系統在不同負載 時的效能與其通話品質。

Design and Implementation of Voice Quality Testing Tool for

VoIPv6 Environments

Student: Yueh-Hsin Sung

Advisor: Dr. Yi-Bing Lin

Institute of Network Engineering

National Chiao Tung University

Abstract

VoIP (Voice over IP) is one of the most important services among the IMS (IP Multimedia Subsystem) services. IMS utilizes SIP (Session Initiation Protocol) and RTP (Real-time Transport Protocol) to transfer the VoIP signaling and multimedia contents. IPv6 (IP version 6) is employed in the IMS to provide large address space. This paper proposes an analysis tool referred to as SIPv6 Analyzer to investigate the IMS-related protocols during IMS service deployment and to evaluate the deployed systms. SIPv6 Analyzer dissects the protocol headers and provides SIP message flow generation and RTP audio/video stream replay. The SIPv6 Analyzer also works as a testing tool and provides IPv6 tunnel setup capbility, SIP call setup capability and multiple testing streams generated by SmartBits hardwares. Through these functions, the user can evaluate the performance and service quality of the deployed system.

誌誌誌 謝謝謝 首先誠摯地感謝指導教授林一平博士與陳懷恩博士，沒有老師的專業建議與細心 指導，我無法完成此篇碩士論文。在林一平博士嚴格的指導中，我學習到了研究的方 法，並從中獲得極大的助益。在陳懷恩博士的指導中，讓我獲得論文研究方向與許多 專業知識。另外感謝楊偉儒博士、逄愛君博士擔任我的口試委員，並在口試中給與指 正與建議，使得論文能更加完整。 感謝實驗室的同伴們，特別是：雅琳、依寰以及曉涵，謝謝你們的陪伴，讓我的 研究生活更加的充實。 最後我也要感謝我的家人與我的朋友們在我研究生活中給予的鼓勵及支持。

目

目

目 錄

錄

錄

中文摘要... i Abstract... ii 誌謝 ... iii 目錄 ... iv 圖目錄 ... vi 表目錄 ... viii 第一章 簡介... 1 第二章 SIPv6 Analyzer ... 3 2.1 SIPv6 Analyzer 系統架構... 3

2.1.1 The Packet Processing Module ... 4

2.1.2 The User Interface Module ... 5

2.2 SIP/RTP Processor ... 6

2.3 SIPv6 Analyzer 展示... 11

第三章 SIPv6 Analyzer MOS 評估模組系統架構... 14

3.1 SIPv6 Analyzer MOS 評估模組系統架構... 14

3.1.1 控制器... 15 3.1.2 媒體前置處理器與媒體資料庫... 16 3.1.3 IPv6 通道代理人... 17 3.1.4 SIP 代理人... 17 3.1.5 RTP 代理人 ... 18 3.1.6 PESQ ... 20 3.2 驗證語音品質評估模組正確性 ... 20

第四章 實驗環境與實驗結果 ... 25

4.1 實驗 1 – Pure IPv6/ Public IPv4 使用環境之效能評估 ... 26

4.1.1 實驗 1 實驗流程 ... 28 4.1.2 實驗 1 實驗結果 ... 31 4.2 實驗 2 – SBC 使用環境之效能評估 ... 33 4.2.1 RTP Proxy 效能測試... 33 4.2.2 NAT 效能測試 ... 37 4.2.3 NAT 與 SBC 整合效能測試... 40 4.3 實驗 3 – IPv6-in-IPv4 通道使用環境之效能評估... 44 4.3.1 實驗 3 實驗流程 ... 44 4.3.2 實驗 3 實驗結果 ... 47 4.4 實驗 4 – IPv6-in-IPv4 UDP 通道使用環境之效能評估... 48

4.4.1 IPv6-in-IPv4 UDP Tunnel Server 效能測試 ... 48

4.4.2 NAT 與 IPv6-in-IPv4 UDP Tunnel Server 整合效能測試 ... 52

4.5 各元件之效能比較... 55

第五章 結論與未來工作 ... 57

圖

圖

圖 目

目

目 錄

錄

錄

2.1 SIPv6 Analyzer 系統架構圖 . . . 3

2.2 SIP/RTP Processor . . . 6

2.3 SIP Session List 範例 . . . 6

2.4 RTP Connection List 範例 . . . 7

2.5 IMS 環境下的 VoIP 通話範例 . . . 11

2.6 SIP Viewer 、 SIP 訊息流程以及 RTP Viewer 之螢幕快照 . . . 13

3.1 SIPv6 Analyzer 系統架構圖 . . . 14

3.2 驗證語音品質評估模組正確性之實驗環境 . . . 21

3.3 平均 MOS 值與測試次數關係圖 . . . 23

4.1 VoIP 使用環境示意圖 . . . 26

4.2 Pure IPv6/Public IPv4 效能測試環境 . . . 27

4.3 Pure IPv6/Public IPv4 效能測試結果 – 同時通話個數對平均延遲之關係圖 31 4.4 RTP Proxy 效能測試環境 . . . 33 4.5 Portaone RTP Proxy 系統架構 . . . 34 4.6 RTP Proxy 效能測試結果 . . . 36 4.7 NAT 效能測試環境 . . . 38 4.8 NAT 效能測試結果 – 同時通話個數對平均延遲及封包遺失率之關係 . . . 39 4.9 NAT 與 SBC 整合效能測試環境 . . . 40 4.10 NAT 與 SBC 整合效能測試結果 . . . 41 4.11 NAT 與 SBC 整合效能測試結果 – 同時通話個數對 MOS 之關係圖 . . . . 43 4.12 IPv6-in-IPv4 通道效能測試環境 . . . 44

4.14 IPv6-in-IPv4 通道環境效能測試結果 – 同時通話個數對平均延遲之關係圖 47

4.15 IPv6-in-IPv4 UDP Tunnel Server 效能測試環境 . . . 48

4.16 Miredo Teredo Relay系統架構圖 . . . 49

4.17 Miredo Teredo Relay效能測試 . . . 51

4.18 NAT 與 IPv6-in-IPv4 UDP Tunnel Server 整合效能測試環境 . . . 52

4.19 NAT 與 IPv6-in-IPv4 UDP 通道整合效能測試結果 . . . 53

4.20 IPv6-in-IPv4 UDP 通道環境效能測試結果 – 同時通話個數對 MOS 之關 係圖 . . . 54

表

表

表 目

目

目 錄

錄

錄

3.1 語音編解碼器之 MOS 值 (G.729) . . . 23 3.2 語音編解碼器之 MOS 值 (iLBC) . . . 24 3.3 語音編解碼器之 MOS 值 (G.711u) . . . 24 4.1 封包傳輸延遲差異值之理論值與實測值之比較表 . . . 32 4.2 RTP Forwarding Table 範例 . . . 35

4.3 IPv6-in-IPv4 Tunnel Server IPv6 路由表範例 . . . 46

第

第

第一

一

一章

章

章 簡

簡

簡介

介

介

VoIP (Voice over IP) 為第三代行動通訊 IMS (IP Multimedia Subsystem) 中最重 要的服務之一。在 IMS 中，VoIP 分別以 SIP (Session Initiation Protocol) 與 RTP (Real-time Transport Protocol) 協定來傳輸信令和多媒體資訊。此外， IMS 也採用 IPv6 (IP version 6) 來提供大量的位址空間、 QoS (Quality of Service)，以及隨插即用 的功能。因此在建置 IMS 應用服務時，非常需要使用分析器來研究相關通訊協定。常 見的 Ethereal 是一個開放原始碼的協定分析器，且能夠解析七百多種通訊協定標頭， 但 Ethereal 並沒提供針對 IMS 分析的專屬功能。因此本論文針對 IMS 的應用服務， 設計並實作出 SIPv6 Analyzer 。 SIPv6 Analyzer 不但能夠解析通訊協定標頭，也能用 來分析 SIP 對話、產生 SIP 信令流程圖、播放 RTP 語音或影像串流，並呈現封包統 計功能，分析封包延遲的變異量。

本論文針對測試VoIP 通話品質的功能需求，搭配 SmartBits 硬體，研發 SIPv6 Analyzer 的語音品質評估模組，發送測試封包到待測系統，以評估待測系統的效能與 通話品質。 SIPv6 Analyzer 的語音品質評估模組提供以下功能，使其成為適合測試各 種 VoIPv6 (Voice over IPv6) 環境之效能與通話品質之工具。 SIPv6 Analyzer 具有以下 功能：

• 具有建立 IPv6 通道 (Tunnel) 之能力。 • 具有 SIP 通話建立之能力。

目前已有的語音品質評估方式可分為主觀 (Subjective) 與客觀 (Objective) 兩種。 主觀的語音評估方式，目前所使用的標準為 P.800 [1] 。藉由一個受控制的環境下， 讓受測者聽取系統所播放的聲音，或是透過系統進行對話。受測者於結束後對於測 試結果進行評分，將語音品質區分為五個等級， Excellent (5) 、 Good (4) 、 Fair (3) 、 Poor (2) ，以及 Bad (1) 。藉由統計受測者所評估之分數，求得待測系統的語音品 質；客觀的語音評估方式，又可分為兩種方式，一種是分析過去主觀測試結果，經由 迴歸分析，將影響語音品質的因素量化，計算各種因素的結果後得到語音品質，目前 的標準為 G.107 (E-Model) [2] ；第二種是直接對經過系統的語音之聲波進行分析，了 解原本的聲波經過系統後的受損程度，評估系統之語音品質，目前的標準為 P.862 (即 PESQ ， Perceptual Evaluation of Speech Quality) [3] 。

主觀的語音品質評估的優點，是可以直接了解使用者對於系統的語音品質滿意程 度，但是進行此方式的評估，需要遵從標準所規範的測試環境，測試的過程可能相當 昂貴而耗時；客觀的語音品質評估則可以迅速評估系統的語音品質。 E-Model 的評估方式中，雖然包含網路的延遲的因素，但是 E-Model 中許多影 響語音品質的參數在一般 VoIP 應用中不易量測，需使用預設值設定這些參數，而且 E-Model沒有支援所有的語音編解碼器 (CODEC) ，待測系統所使用的語音編解碼器若 不在支援的清單中，便無法直接使用 E-Model 評估其語音品質；而 PESQ 是基於評估 聲音訊號的受損程度計算語音品質，可以同時考量封包遺失與語音編解碼器的影響， 雖然 PESQ 無法了解延遲所造成的語音品質下降，但是可以支援各種不同的語音編解 碼器。因此本論文選擇 PESQ 來計算待測系統的通話品質，並提供延遲與封包遺失率 做為參考。 本論文後續的章節組織描述如下。第二章說明 SIPv6 Analyzer 的系統架構與運作 範例。第三章說明 SIPv6 Analyzer 語音品質評估模組的系統架構。第四章利用 SIPv6 Analyzer 比較目前 IPv4 位址不足的解決方案之效能。第五章為總結並提出未來方向。

第

第

第二

二

二章

章

章 SIPv6 Analyzer

2.1 SIPv6 Analyzer

系

系

系統

統

統架

架

架構

構

構

Audio Player Video Player m i n o p Packet Viewer Session Viewer j g k l h Input Output Action Processor Ethereal Packet Processor d Packet Buffer a SIP/RTP Processor Statistic Processor e f

Packet Preprocessor c _{Rule Table}Filtering b Command Interpreter WinPcap Module Packet Processing Module User Interface Module (1) (2) (3) Flow Generator Statistic Generator 圖 2.1: SIPv6 Analyzer 系統架構圖

圖 2.1 為 SIPv6 Analyzer 的系統架構，包含三個主要模組 (Module) 。WinPcap Module (圖 2.1 (1)) 使用開放原始碼的 WinPcap (Windows Packet Capture) 函式庫 [4] 擷取封包。 Packet Processing Module (圖 2.1 (2)) 從 WinPcap Module 取得封包、將 封包分類，並且提供上層的應用程式分析系統所擷取到的封包。User Interface (UI) Module (圖 2.1 (3)) 藉由對話 (Dialog)/會議 (Session) 列表、訊息流程 (Message Flow)

、語音及影像，來展示系統所擷取到的封包之資訊。

2.1.1 The Packet Processing Module

Packet Processing Module 包含五個元件。當 Packet Processing Module 從 Win-Pcap Module 收到封包時，Packet Preprocessor (圖 2.1 b ) 由封包的標頭取得 IP 位 址與 通訊埠號資訊，並且將該資訊以及所收到的封包儲存進 Packet Buffer (圖 2.1

a

)。Packet Preprocessor 負責維護 Filtering Rule Table (圖 2.1 c )並且呼叫 WinPcap Module 根據指定的過濾規則 (Filtering Rules) 過濾特定的封包。 Packet Preprocessor 將所擷取下來的封包內容，以指標 (pointer) 的方式傳遞給 Ethereal Packet Processor (圖 2.1 d )與 SIP/RTP Processor (圖 2.1 e )。 Ethereal Packet Processor 是使用 Ethe-real 的函式庫 [5] ，來實作封包標頭資訊的解析功能。 SIP/RTP Processor 從擷取到 的 IP 封包中擷取 SIP 與 RTP 的封包，並將 SIP 與 RTP 封包安排到對應的會議中。 Statistic Processor (圖 2.1 g ) 紀錄收到封包的個數、 inter-arrival distribution 與 jitter 統計資料。

多數的封包分析器 (如 Ethereal 與 Sniffer) 設定過濾規則 “udp port 5060” 與 “udp port 9000” 來擷取 SIP 與 RTP 封包。然而 SIP UA (User Agent ， IMS 使用者裝備) 可能使用 TCP 傳輸 SIP 訊息。 SIP UA 也可能使用任意的通訊埠號來傳輸 SIP 訊息。 因此，使用固定通訊埠的過濾規則擷取 SIP 訊息， 利用 TCP 或是彈性使用任何通訊 埠號碼傳送的 SIP 訊息，將被系統忽略，而且 “錯誤的封包” 可能會被擷取下來，進行 IMS 的服務分析。

前述的問題的解決方法說明如下， SIP 訊息的第一行是 request-line 或是 status-line ，而 request-line 的最後一個字串，與 status-line 的第一個字串是使用 ASCII 字 串 “SIP/2.0” 這個字串用來辨識 SIP 的版本。為了避免誤判任何 SIP 訊息， SIP/RTP Processor 檢查 TCP 或 UDP 的承載 (Payload) ，檢查是否包含該字串。如果有的話， 則可以辨識出 SIP 訊息。

同理，設定固定的過濾規則可能擷取到使用 UDP 通訊埠 9000 非 RTP 的封包， 或是忽略不是使用通訊埠 9000 的 RTP 封包。此問題解決方法說明如下，因為 RTP 的傳輸位址 (Transport Address) 藉由 SIP 訊息傳送， SIP/RTP Processor 由 SIP 訊息 中 SDP [6] 所攜帶的 c 與 m 欄位，獲取正確的傳輸位址。接下來 SIP/RTP Processor 可以藉由此資訊，正確的辨認出 RTP 封包。在 RTP 封包被辨認出來後，SIP/RTP Processor 藉由 SDP 中取出的傳輸位址與 RTP 標頭資訊的 SSRC (Synchronization Source) [7]，將其安排到相對應的 RTP 連線。

2.1.2 The User Interface Module

UI Module 包含三個元件， Input Component (圖 2.1 h ) 接收使用者的指令並 請求 Action Processor (圖 2.1 g ) 執行該指令。在 Action Processor 中， Command Interpreter (圖 2.1 l ) 呼叫 Ethereal Packet Processor 、 SIP/RTP Processor 、 Statistic Processor 或是 Packet Preprocessor 執行 Input Component 下達的指令。在指令執行 後， Action Processor 可由 Packet Viewer (圖 2.1 j ) ，或是 Session Viewer (圖 2.1 k ) ，取得封包與會議的資訊。接下來 Action Processor 呼叫 Output Component (圖 2.1

i

)將結果藉由視窗介面的多媒體工具呈現出來。例如，使用 Audio Player (圖 2.1 m ) ，與 Video Player (圖 2.1 n ) 播放 RTP 所攜帶的語音及影像。 Flow Generator (圖 2.1

o

) 藉由封包的 IP 位址或是 SIP 訊息的標頭欄位，畫出 SIP 訊息流程 (SIP Message Flow) 。 Statistic Generator (圖 2.1 p ) 使用表格、樹狀圖 (Tree-View) 或是長條圖 (Bar Chart) 呈現與封包相關的統計資料。

藉由以上的元件， UI Module 提供了以下幾個方便的功能。

• 因為不同會議中的 SIP 訊息會互相交錯， UI Module 從 SIP/RTP Processor 獲取 SIP 對話，並將 SIP 對話列成表格 (如圖 2.6 a )。藉由此功能，使用者很容易地 觀察這些在 SIP dialods 中，經過排列的 SIP 訊息。而不是從互相交錯的訊息中 進行閱讀。

• UI Module可藉由 IP 位址或是 SIP 標頭欄位，為每個 SIP dialog ，產生一個 SIP 訊息流程 (如圖 2.6 b ) 。藉由此功能，使用者可以辨識出 SIP 信令傳輸路徑上所

經過的所有節點。

• UI Module 支援 H.263 的影像編解碼器，以及 G.711u 、 G.711a 與 GSM 三種語 音編解碼器。因此使用者可以利用此功能，播放使用者所選擇 RTP 連線 (圖 2.6

c

) 所攜帶的語音或影像。

2.2 SIP/RTP Processor

本節說明 SIPv6 Analyzer 中最主要的元件， SIP/RTP Processor 。

RTP

Connection List

Dispatcher

SIP Parser

SIP/RTP Processor

UI Module

3 2 4

Packet Preprocessor

1 b c d 5

SIP Session List

a

圖 2.2: SIP/RTP Processor

如圖 2.2 所示， SIP/RTP Processor 包含 SIP Session List (圖 2.2 a )、 SIP Parser (圖 2.2 b ) 、 RTP Connection List (圖 2.2 c )與 Dispatcher (圖 2.2 d ) 。

200 OK INVITE Session Identifier 3 100 Trying 180 Ringing 6 2 1 From wechen@cs.nctu.edu.tw To liny@cs.nctu.edu.tw Call-ID 46F8Eb78621 4 5 7 ACK

SIP Session List 利用鏈結串列 (Linked-List) 的結構儲存 SIP 會議資訊 (參考圖 2.3 ) 。SIP Session List 中每筆資料包含 Session Identifier (圖 2.3 1 ) ，用來標示 SIP 會 議，並且使用一個鏈結串列，儲存所有與此會議關聯的封包指標。 一個 SIP 會議的 Session Identifier包含 SIP 標頭的 From 、 To 與 Call-ID 欄位。

SIP 通話建立的交易 (Transaction) 包含一個 INVITE 訊息 (圖 2.3 3 ) ，可能有 零個以上的暫時 (Provisional) 訊息 (如 100 Trying 訊息，與 180 Ringing 訊息，參考 圖 2.3 4 與 5 ) 、一個 200 OK 訊息 (圖 2.3 6 ) ，與一個 ACK 訊息 (圖 2.3 7 ) 。在 此交易中，INVITE 與 200 OK 訊息的 SDP ，其 c 與 m 欄位都攜帶了目的傳輸位址。 當通話建立的交易完成後，通話雙方間的 RTP 連線即被建立。 SSRC 3ffe:3600:1::1 3ffe:3600:1::2 9002 9000 3ffe:3600:1::2 3ffe:3600:1::1 9002 9000 3ffe:3600:1::3 3ffe:3600:1::4 9002 9000 3ffe:3600:1::4 3ffe:3600:1::3 9000 9002 29696 22607 25002 23141 SRC IP DST IP SRC Port DST Port RTP 6 1 2 3 4 RTP 5 RTP RTP

(a) 接收 RTP 封包後 RTP Connection List 的內容

3ffe:3600:1::1 3ffe:3600:1::2 * * 3ffe:3600:1::2 3ffe:3600:1::1 * * SSRC 9000 9000 SRC IP DST IP SRC Port DST Port 1 2

(b) 處理 SIP 200 OK 訊息候 RTP Connection List 的內容 圖 2.4: RTP Connection List 範例

一個 RTP 會議包含兩個單向的連線， RTP Connection List (圖 2.4 (a)) 將 RTP 封包對映到其所屬的 RTP 連線。 RTP Connection List 中每個連線資料包含來源 IP 位 址 (SRC IP) 、 目的 IP 位址 (DST IP) 、 來源通訊埠 (SRC Port) 、 目的通訊埠 (DST Port)、 SSRC 欄位，與一個儲存該 RTP 連線的封包之指標的鏈結串鏈。 來源 IP 位 址 、 目的 IP 位址，與目的通訊埠用來檢查一個封包是否為 RTP 封包。利用 RTP Session List 中的全部五個欄位，可以用來將 RTP 封包分類至其所屬的連線。 在 Internet-Drafts [8] 中， RTP 的傳輸方式定義有兩種，非對稱式 (Asymmetric) 與對稱式 (Symmetric) 。圖 2.4 (a) 的第一筆與第二筆資料代表一對非對稱式的 RTP 會議，而第三筆與第四筆資料代表一對對稱式的 RTP 會議。在非對稱連線的情形

下， SIP UA 使用一個通訊埠 (如 9000) 來接受 RTP 封包，而另外使用一個通訊埠 (如 9002) 來傳送 RTP 封包。對稱式的連線的情形下， SIP UA 使用相同的通訊埠 (如 9000)來傳送與接收 RTP 封包。

SIP Parser (圖 2.2 b ) 只憑 SIP 訊息，無法判定一個 RTP 連線是否為非對稱式或 是對稱式。 因此在 RTP 連線的第一個封包被系統擷取下來之前， SIP Parser 將 RTP Connection List 的 SRC Port 欄位，標示為 ‘*’ 在 SRC Port 的欄位中 ( 參考圖 2.4 (b) 第一筆與第二筆資料 ) ，代表來源通訊埠號未明，並且應該從該 RTP 連線第一筆收到 的 RTP 封包中取出。 同理， SIP 訊息不包含 SSRC 值， SSRC 欄位也標示為 ‘*’ 。 在收到 RTP 連線中第一筆封包時， Dispatcher 將這些值填入 RTP Connection List 的 SRC Port與 SSRC 欄位。

考慮以下的 SIP/RTP 封包的處理流程範例。假設發話方 (wechen@cs.nctu.edu.tw) 的 IP 位址為 3ffe:3600:1::1 ，而受話方 (liny@csie.nctu.edu.tw) 的 IP 位址為 3ffe:3600:1::2 。 通話雙方皆使用通訊埠 5060 收送 SIP 訊息，利用通訊埠 9000 接收 RTP 封包，通 訊埠 9002 傳送 RTP 封包。在 SIP/RTP Processor 初始化後， SIP Session List (圖 2.2

a

)與 RTP Connection List (圖 2.2 b ) 為空的。 INVITE 訊息的處理方式說明如下：

步 步

步驟驟驟 1.1 (圖 2.2 1 ) 在收到 INVITE 訊息時， Packet Preprocessor 將封包指標傳給 Dispatcher 。

步 步

步驟驟驟 1.2 (圖 2.2 2 ) Dispatcher從封包的 IP 與 UDP 標頭獲得來源 IP 位址 (3ffe:3600:1::1) 、 目的 IP 位址 (3ffe:3600:1::2) 、 來源通訊埠號 (5060) ，與目的通訊埠號 (5060) 。 此資訊用來搜尋 RTP Connection List 。 Dispatcher 若未發現相符的資料，則 認為此封包並非 RTP 封包。

步 步

步驟驟驟 1.3 (圖 2.2 3 ) Dispatcher 將封包指標傳給 SIP Parser ， SIP Parser 檢驗發 現 此 封 包 攜 帶 SIP 訊 息 (如 INVITE 訊 息) 。 SIP Parser 接 下 來 產 生 Ses-sion Identifier 藉由 合併 SIP 訊息的 From (即 wechen@cs.nctu.edu.tw) 、 To (即 liny@cs.nctu.edu.tw) 與 Call-ID 標頭欄位。 為了獲得發話端的 RTP 傳輸位址，

SIP Parser 由 SDP 的 c 欄位獲得 IP 位址 3ffe:3600:1::1 ，由 m 欄位獲得通訊埠 號 9000 。此時，通話建立的交易並未完成。 SIP Parser 暫時紀錄傳輸位址，並 於步驟 2.4 存入 RTP Connection List 。

步 步

步驟驟驟 1.4 (圖 2.2 3 ) SIP Parser 回傳 Session Identifier 的資訊，包含 From 、 To 與 Call-ID欄位 (即 {wechen@cs.nctu.edu.tw} {liny@cs.nctu.edu.tw} {46F8Eb78621}) 給 Dispatcher 。

步 步

步驟驟驟 1.5 (圖 2.2 6 ) Dispatcher 使用此標識符 (Identifier) 搜尋 SIP Session List 。 因 為此封包屬於一個新的 SIP 會議，不會找到相符的會議。因此，一筆新的 SIP 會 議資料被建立，結果如圖 2.3 2 ，而 INVITE 訊息的指標被連接至此 SIP Session 的鏈結串列 (圖 2.3 3 )。

此時，新的 SIP Session 已經被建立，而 SIP/RTP Processor 繼續處理下一個封 包指標。接下來的 SIP 暫時訊息 (即 100 Trying 訊息，與 180 Ringing 訊息) ，依照 步驟 1.1 到 1.5 處理後，將被連接在 SIP Session List (圖 2.3 4 與 5 ) 。 假設回應該 INVITE訊息的 200 OK 訊息被 Packet Preprocessor 擷取下來， SIP/RTP Processor 進 行以下動作。 步 步 步驟驟驟 2.1 與 2.2 同步驟 1.1 與 步驟 1.2 。 步 步

步驟驟驟 2.3 (圖 2.2 3 ) SIP Parser偵測到此封包帶有 SIP 訊息 。 SIP Parser接著從 SDP 中的 c 欄位取得 IP 位址 3ffe:3600:1::2 ，由 m 欄位取得通訊埠號 9000 ，組成受 話方的傳輸位址。 此 時 ， SIP Parser 已 經 取 得 RTP 連 線 之 傳 輸 位 址 。 發 話 方 的 傳 輸 位 址 [3ffe:3600:1::1]:9000 在 步 驟 1.3 獲 得 。 受 話 方 的 傳 輸 位 址 [3ffe:3600:1::2]:9000 在 步 驟 2.3 獲得。 步 步

步驟驟驟 2.4 (圖 2.2 4 ) SIP Parser 將 IP 位址與通訊埠號碼填入 RTP Connection List (如 圖 2.4 (b) 第一筆與第二筆資料) ， IP 位址 3ffe:3600:1::1 被填入第一筆資料的

SRC IP 欄位與第二筆資料的 DST IP 欄位。 IP 位址 3ffe:3600:1::2 被填入第二筆 資料的 SRC IP 欄位與第一筆資料的 DSP IP 欄位。通訊埠 9000 與 ‘*’ 標記，分 別被填入第一筆資料與第二筆資料的 DST Port 與 SRC Port 欄位。 ‘*’ 標記被填 入第一筆與第二筆資料的 SSRC 欄位 。 步 步

步驟驟驟 2.5 (圖 2.2 3 ) SIP Parser 回傳 Session Identifier 給 Dispatcher 。 步

步

步驟驟驟 2.6 (圖 2.2 5 ) Dispatcher 使用 Session Identifier 搜尋 SIP Session List 。此時發 現一個相符的會議 (於步驟 1.5 時建立) 。 Dispatcher 接著把 200 OK 訊息的指標 連接到相符的 SIP 會議 (圖 2.3 6 )的鏈結串列。

此時， SIP 200 OK 訊息的處理已經完成。對映此 SIP 200 OK 訊息的 SIP ACK 訊息，依照步驟 1.1 到 1.5 ，被連接到 SIP Session List (圖 2.3 7 )。假設發話方開始發 送 RTP 封包到受話方。第一個 RTP 封包被收到後，SIP/RTP Processor 進行下列步 驟。 步 步 步驟驟驟 3.1 與步驟 1.1 相同。 步 步

步驟驟驟 3.2 (圖 2.2 2 ) Dispatcher 搜尋 RTP Connection List 並且找尋相符的資料 (即 圖 2.4 (b) 的第一筆資料，於步驟 2.4 產生) 。這筆資料中來源通訊埠為 ‘*’ ，同時 SSRC 的值也是 ‘*’ 。 Dispatcher 由 RTP 封包的標頭中取出 SSRC 值 (即 22340) ，接著將 RTP Connection List 的 Src Port 與 SSRC 欄位之值，分別以 ‘9002’ 與 ‘22340’ 取代。被修改後的 RTP Connection List 如圖 2.4 (a) 1 。 Dispatcher 接 著將封包指標連接到相符資料 (圖 2.4 (a) 5 )的鏈結串列。

步 步

步驟驟驟 3.3 (圖 2.2 2 ) 在 Dispatcher 成功儲存封包指標於 RTP Connection List 後， Dispatcher 繼續處理下一個封包指標。

在收到受話方送出的 RTP 封包後，SIP/RTP Processor 執行步驟 3.1 到 3.3 。在 RTP 封包被處理後，可以得到圖 2.4 (b) 2 的來源通訊埠號與 SSRC 值欄位，如圖2.4 (b) 2 所示。 RTP 封包便可連接在 RTP Connection List (圖 2.4 (a) 6 )。

在處理封包指標的過程中，如果 Dispatcher 無法在 RTP Connection List 找到相符 的資料，並且SIP Parser 指出此封包並未攜帶 SIP 訊息，則SIP/RTP Processor 丟棄此 封包指標，並且繼續處理下一個封包。

2.3 SIPv6 Analyzer

展

展

展示

示

示

CSCF cs.nctu.edu.tw 3ffe:3600:1::5 MGW SIPv6 Analyzer UA1 wechen@cs.nctu.edu.tw 3ffe:3600:1::1 UA2 liny@cs.nctu.edu.tw 3ffe:3600:1::2 Hub IMS a b c d e f g i h UMTS PDN

IMS: IP Multimedia Sub-system MGW: Media Gateway PDN: Packet Data Network

圖 2.5: IMS 環境下的 VoIP 通話範例

圖 2.5 為展示 SIPv6 Analyzer 功能的 IMS 環境， UA1 (圖 2.5 a ) 為發話方， UA2 (圖 2.5 i ) 為受話方， IP 位址分別為 3ffe:3600:1::1 與 3ffe:3600:1::2 。兩個 UA 使用 UMTS (Universal Mobile Telecommunications System ，圖 2.5 b ) 、 IMS (圖 2.5

c

) 與 PDN (Packet Data Network ，圖 2.5 f ) 互相溝通。 UA1 與 UA2 分別註冊帳 號 wechen@cs.nctu.edu.tw 與 liny@cs.nctu.edu.tw 於 IMS 網路中的 CSCF (Call Session Control Function ，圖 2.5 d ) 在通話建立完成後， RTP 封包藉由 MGW (Media Gate-way，圖 2.5 e )傳輸。 SIPv6 Analyzer (圖 2.5 h ) 可以連接於 IMS 或是 PDN ，以分 析 SIP 與 RTP 封包。在此展示中， SIPv6 Analyzer 與 UA2 藉由一個集線器 (Hub ， 如圖 2.5 g )連接於 PDN 。

SIPv6 Analyzer 透過集線器擷取所有送往 UA2 或由 UA2 送出的封包，依據步驟 1.1 到 1.5 與步驟 2.1 到 2.5 處理 SIP 訊息，並根據步驟 3.1 到 3.5 分類 RTP 封包到其 所屬的會議。在擷取完成後，使用者可以分析 SIP 訊息流程與播放多媒體內容。

Head-ers” ，要求 SIPv6 Analyzer 畫出 SIP 訊息流程。若選擇使用第一個選項 (即 Draw Message Flow) ， SIPv6 Analyzer 利用來源與目的 IP 位址畫出 SIP 訊息流程。如果 選擇第二個選項 (即 Draw Message Flow from Headers) ， SIPv6 Analyzer 利用 SIP 訊 息的標頭欄位 (即 SIP 的 Via 或 Route 標頭欄位) 畫出 SIP 訊息流程。圖 2.6 b 展 示出使用 SIP Via 標頭欄位所畫出的 SIP 訊息流程。此訊息流程中，虛線代表 SIP 訊息傳遞路徑，虛線使用 SIP Via 標頭欄位產生。例如 SIPv6 Analyzer 所擷取的 SIP INVITE訊息中的 Via 欄位， Via 欄位中包含兩個 URI (Uniform Resource Identifier [6]) – 3ffe:3600:1::1 與 3ffe:3600:1::5 。SIPv6 Analyzer 利用前述資訊，從 3ffe:3600:1::1 (即 UA1) 畫一個虛線到 3ffe:3600:1::5 (即 CSCF) 。藉由此功能，SIPv6 Analyzer 可以顯 示 UA1 與 CSCF 之間的訊息交換，即使 SIPv6 Analyzer 並未與此兩個節點直接相連。

為了分析擷取到的 RTP 封包，使用者可以選擇 “RTP Viewer” 子頁面 (圖 2.6 3 ) ，啟用 Statistic Generator (圖 2.1 p ) 以用來顯示 RTP Session List (圖 2.6 4 ) 。如要 播放語音或影像，使用者將該筆資料(圖 2.6 4 ) 加入 Media Instance (圖 2.6 7 )。接下 來使用者可以點選控制按鈕 (即 Play/Hold/Stop 按鈕，如圖 2.6 8 ) ，播放 RTP 封包 所攜帶的內容。圖 2.6 5 顯示 Video Player (圖 2.1 n ) 所播放的影像。藉由此功能， 使用者可以評估 RTP 封包所攜帶的語音/影像的品質。

如要評估在不同 Jitter Buffer 設定下的語音/影像品質，使用者可以點選 Configu-ration 按鈕 (圖 2.6 2 ) ，設定 Jitter Buffer 的長度 (如圖 2.6 6 ) 。 RTP Viewer 的狀 態列 (圖 2.6 9 ) 顯示目前的 Jitter Buffer 長度 (即 100 ms) 、被丟棄的封包個數 (即 0 個) ，以及所選擇的 RTP 連線之平均 Jitter 值 (即 60.09 ms)。增長 Jitter Buffer 的長 度可以減少被丟棄的封包，但會增加通訊的延遲。使用者可以使用此功能，觀察不同 Jitter Buffer長度的影響。

第

第

第三

三

三章

章

章 SIPv6 Analyzer MOS 評

評

評估

估

估模

模

模組

組

組

系

系

系統

統

統架

架

架構

構

構

3.1 SIPv6 Analyzer MOS

評

評

評估

估

估模

模

模組

組

組系

系

系統

統

統架

架

架構

構

構

Controller

UI Module

Network Under Test PESQ M ed ia P re p ro ce ss o r IPv6 Tunnel Agent Degraded Files Reference Files Encoded Data MOS Evaluation Module S p ee ch E n co d er Speech Decoder SmartLib RTP Processor SIP Agent RTP Agent Media Database h 1 k l m f g d a b c 4 j e 2 i _n 3 SmartBits (1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) (15) (16) (17)

S

IP

v

6

A

n

a

ly

z

e

r

圖 3.1: SIPv6 Analyzer 系統架構圖

圖 3.1 為 SIPv6 Analyzer 的 MOS 評估模組 (MOS Evaluation Module) 之架構圖， 同時表示 SIPv6 Analzer 與待測網路 (Network Under Test ，圖 3.1 4 )的關係。 使用 者介面 (User Interface Module ，圖 3.1 1 )，為 SIPv6 Analyzer 的使用者介面。 MOS 評估模組 (圖 3.1 2 ) 為本論文所要實作的系統，搭配 SmartBits (圖 3.1 3 ) 對待測網 路進行測試。

MOS 評估模組主要包含七個元件： 控制器 (Controller ，圖 3.1 a ) 、 IPv6 通道 代理人 (IPv6 Tunnel Agent ，圖 3.1 b )、 SIP 代理人 (SIP Agent，圖 3.1 c )、 PESQ (圖 3.1 d )、 RTP 代理人 (RTP Agent，圖 3.1 e )、 媒體資料庫 (Media Database ， 圖 3.1 f ) ，以及媒體前置處理器 (Media Preprocessor ，圖 3.1 g ) 。接下來將介紹各 個元件。

3.1.1

控

控

控制

制

制器

器

器

控制器 (圖 3.1 a ) 負責控制 MOS 評估模組中的 IPv6 通道代理人(圖 3.1 b ) 、 SIP代理人(圖 3.1 c )、 PESQ (圖 3.1 d )與 RTP 代理人(圖 3.1 e )，控制器接受 UI 所下達的指令，並將指令轉換為控制各種元件的指令與參數。 介 介 介面面面 (1) (圖 3.1 (1)) 為控制器與 UI Module 之間的介面，從 UI Module 傳遞的參數， 共有 5 個 依序為， UAC 與 UAS 所使用的連線型態(Pure IPv6/IPv6-in-IPv4 通 道/IPv6-in-IPv4 UDP 通道/IPv4) 、 UAC 與 UAS 使用的 IP 位址、測試時所使 用的語音編解碼器 (G.729/iLBC/G.711u) 、 UAC 與 UAS 的 SIP URIs ，以及 SIP Server 的位址。控制器經由此介面回傳最後的結果給 UI Module 。

介 介

介面面面 (2) (圖 3.1 (2)) 為控制器與 IPv6 通道代理人之間的介面，若 UAC 或 UAS 使 用 IPv6 通道，控制器將傳遞呼叫 IPv6 通道代理人，來建立 IPv6 通道。參數包 含使用何種方式建立 IPv6 通道，例如 TSP(Tunnel Setup Protocol) [9] 或 Teredo [10] ，以及 UAC 與 UAS 的 IPv4 位址。

介 介

介面面面 (4) (圖 3.1 (4)) 為控制器與 SIP 代理人之間的介面，由控制器所傳遞的參數為 UAC與 UAS 的 SIP URIs 、 SIP Server 的位址，以及 UAC 與 UAS 所使用的 IP 位址。

介 介

介面面面 (6) (圖 3.1 (6)) 為控制器與 RTP 代理人之間的介面，由控制器所傳遞的參數 包含本次測試封包所使用的語音編解碼器 (G.711u) ， UAC 與 UAS 的傳輸位 址， UAC 與 UAS 所使用的連線型態 (Pure IPv6/IPv6-in-IPv4 通道/IPv6-in-IPv4

UDP 通道/IPv4) ，使用 IPv6-in-IPv4 與 IPv6-in-IPv4 UDP 通道時，控制器在 UAS 的連線型態的附加參數指定 Tunnel Server 的 IPv4 位址以及 UAS 的 IPv4 位址。 介 介 介面面面 (12) (圖 3.1 (12)) ，控制器利用介面 (12) 依序將語音參考檔案與劣化品質檔案之 檔案名稱輸入 PESQ ，並獲得回傳的 MOS 值。最後控制器將這次測試中得到的 所有 MOS 值取平均，作為最後輸出的 MOS 值。

3.1.2

媒

媒

媒體

體

體前

前

前置

置

置處

處

處理

理

理器

器

器與

與

與媒

媒

媒體

體

體資

資

資料

料

料庫

庫

庫

媒體前置處理器 (圖 3.1 g ) 與媒體資料庫 (圖 3.1 f ) ，為兩個緊密合作的元件。 媒體資料庫擁有三個資料表。 Reference Files (圖 3.1 k ) 用來儲存語音參考檔，本系 統所使用的語音參考檔案為 ITU-T Recommendation P.862 [3] 所附的語音參考檔案。 Degraded Files (圖 3.1 l ) 儲存每次測試後產生的劣化品質檔，與 Encoded Data (圖 3.1 m

)儲存編碼後之語音參考資料。 Reference Files 資料表會記錄每個語音參考檔案的摘 要資料，摘要資料包含每個語音參考檔案的格式、取樣頻率、取樣資料大小，以及資 料表更新旗標。語音參考檔的格式可以是 raw 或是 wav 檔。 raw 檔為不含檔案標頭之 語音參考檔案，使用者於輸入時必須指定其取樣頻率，與取樣資料之大小。 wav 檔為 包含檔案標頭之語音參考檔案，標頭內含有取樣頻率及取樣資料大小的資訊。資料更 新旗標代表一個語音參考檔是否為新加入的語音參考檔，當使用者從 UI Module 新增 語音參考檔時， Reference Files 資料表摘要資料中會標示此語音參考檔的資料更新旗 標為 “dirty” ，代表需要進行編碼。 Speech Encoder (圖 3.1 n ) 會根據此其標對語音參 考檔案進行編碼，所支援的語音編解碼器有 G.729 、 iLBC 與 G.711u ， G.711u 的程 式碼取自於 [11] ， iLBC 的程式碼取自於 [12] ， G.729 的程式碼取自於 [13] 。 由於每次測試時如果都要對語音參考檔案進行編碼，會比較沒有效率，因此媒體 前置處理器在系統啟動時，經由以下步驟，避免每次測試都要對語音參考檔案進行編 碼： 步 步 步驟驟驟 1.1 (圖 3.1 (16)) 媒體前置處理器查詢媒體資料庫的 Reference Files 資料表，檢

查語音參考檔的摘要資料中的更新旗標。若旗標為 “dirty” ，則媒體前置處理器 將從 Reference Files 資料表，取得語音參考檔， Speech Encoder 根據摘要資料中 的檔案格式、取樣頻率，以及取樣資料大小，對語音參考檔進行編碼。

步 步

步驟驟驟 1.2 (圖 3.1 (17)) Speech Encoder 將編碼後資料存入 Encoded Data 中 。 步 步 步驟驟驟 1.3 (圖 3.1 (16)) 媒體前置處理器更新語音參考檔的摘要資料，將更新旗標標示 為 “clean” ，代表該語音參考檔已經過編碼。

3.1.3 IPv6

通

通

通道

道

道代

代

代理

理

理人

人

人

在測試 IPv6 使用環境時，使用者可能是經由各種 IPv4/IPv6 轉移機制得到 IPv6 連線，為了測試這些轉移機制的效能， SIPv6 Analyzer 需要有能力進行通道 建立的流程，並藉由獲得的通道資訊設定 SmartBits 以進行測試。IPv6 通道代理 人 (圖 3.1 b ) 為系統建立 IPv6 通道，使 SIPv6 Analyzer 可以透過 IPv6 通道發送 SIP 信令，進行 SIP 通話建立流程。 IPv6 通道代理人經由介面 (2) (圖 3.1 (2)) 接 受控制器所傳的參數，依據參數中指定的通道建立方式 (TSP/Teredo) 以及 IPv4 位址，利用 IPv6 通道代理人整合的 Gateway6 Client [14] 或是 Miredo Teredo Client [15]， IPv6 通道代理人經由介面 (3) (圖 3.1 (3))使用 TSP 或是 Teredo 取得 IPv6 通道。

3.1.4 SIP

代

代

代理

理

理人

人

人

由於測試環境中，使用者可能需要進行註冊認證後才能進行通話建立流程，或是 待測系統中使用 SBC ， SBC 會修改 SIP 信令內容，決定 RTP 封包的路徑。因此本 論文需要產生 SIP 信令，讓測試能順利進行。 SIP 代理人 (圖 3.1 c ) 使用 SIPp [16] ， SIPp 根據輸入的 XML 檔案，決定其操作的模式為 UAC (User Agent Client) 或是 UAS (User Agent Server) 。 XML 檔案中定義其執行的程式實體 (Instance) 執行的步 驟，以及送出的 SIP 訊息內容。控制器由介面 (4) (圖 3.1 (5)) 傳送本論文所定義的兩 個 XML 檔案之名稱 – 分別為 UAC 與 UAS 所使用，以及 SIP URI 到 SIP 代理人，作 為 SIP 代理人的程式啟動參數。 SIP 代理人透過介面 (5) (圖 3.1 (5)) ，以 SIP 作為信 令交換之通訊協定。

3.1.5 RTP

代

代

代理

理

理人

人

人

RTP 代理人 (圖 3.1 e )主要包含三個子元件 RTP 處理器 (RTP Processor ，圖 3.1 h

)、 Speech Decoder (圖 3.1 i ) ，與 SmartLibrary (圖 3.1 j ) 。 RTP 處理器接收控 制器傳送的參數，透過 SmartLib 控制 SmartBits 發送 RTP 測試封包，測試結束時利 用 SmartLibrary 取得測試結果，透過 Speech Decoder ，依據取得的測試結果，將預先 編碼的資料 (圖 3.1 m 取出後進行解編碼，獲得劣化品質檔案。 控制器利用介面 (6) (圖 3.1 (6)) 傳遞指令與參數給 RTP 處理器，此部份同控制 器的介面說明 (3.1.1) 。 此時 RTP 處理器已經得知 UAC 與 UAS 的傳輸位址，以及 如何產生封包樣板 (Template) 。封包樣板為一個位元陣列，內容為預先設定好的網 路封包標頭資訊。 RTP 處理器將 UAC 的傳輸位址，設定至封包樣板的目的傳輸位 址，將 UAS 的傳輸位址設定至封包樣板的來源傳輸位址。最後將封包樣板的酬載 (Payload) 設定為預先設定好的 RTP 封包樣板。產生完封包樣板之後， RTP 處理器 透過 SmartLibrary (圖 3.1 (7)) ，設定 SmartBits 以封包樣板產生封包串流，並控制 SmartBits發送 N 個封包。所有的語音參考檔案共 F 個，由於系統預設使用 P.862 所 附的語音參考檔案，因此 F 預設為 20 。所有的語音參考檔案經過編碼後，共會產生 N 個編碼後的資料，所以送出 N 個封包，預設為 7883 個，為 P.862 所附的所有語音 參考檔案經過編碼後產生的資料個數。在發送封包的時候，指定 SmartBits 為每個封 包加上簽章。 SmartBits 的封包簽章是 SmartBits 用來在接收埠辨認 SmartBits 所發送 的封包的方式。簽章資訊包含四個欄位，封包串流編號 (Stream ID) 、該封包的序號 (Sequence) 、送出的時間郵戳，以及接收時的時間郵戳。 RTP 處理器透過 SmartLibrary 得知測試進度，在測試結束時從 SmartBits 取出 SmartBits所接收到封包攜帶的的簽章資訊。此時 RTP 處理器藉由步步步驟驟驟 5.1 到 5.3 獲 得封包遺失樣式 (P ) ，封包遺失樣式為一個紀錄封包有被接收或是未被接收的陣列， 其元素值為 1 代表有被接收， 0 代表封包遺失。

步 步 步驟驟驟 5.1 RTP 處理器透過 SmartLibrary 詢問 SmartBits ，得知此次測試中接收到 R 個封包具有簽章資訊。令 i 為 1 ，並產生封包遺失樣式 P ，其長度為 N 位元 (bit) ，將其所有元素初始化為 0 。 步 步 步驟驟驟 5.2 取得第 i 個簽章資訊，根據其序號 s 將陣列 P 的第 s 個元素標示為 1 ，表示 有收到序號 s 的封包。 步 步 步驟驟驟 5.3 檢查 i 是否等於 R 。若不相等，則遞增 i ，回到步步步驟驟驟 5.2 ；若相等，則完成 封包遺失樣式的產生。 RTP 處理器透過介面 (9) (圖 3.1 (9)) 取出所有使用語音編解碼器 (G.711u) 預先編 碼的檔案，共 F 個。此時 RTP 處理器將透過步步步驟驟驟 5.4 到 5.5 將取出的檔案分別存放 在資料陣列 Ef 中。 步 步 步驟驟驟 5.4 令 f 為 1 ， nf 代表第 f 個預先編碼檔案內含的資料筆數，每筆資料長度為 160 Bytes 。 步 步 步驟驟驟 5.5 將第 f 個預先編碼檔案的資料複製到資料陣列 Ef ，遞增 f 。檢查 f 是否等 於 F ，若否，則重複步步步驟驟驟 5.5；若是，則結束此步驟。 此時 RTP 處理器獲得 F 個資料陣列 (Ef) ，紀錄每個預先編碼檔案的資料。接下 來藉由步步步驟驟驟 5.6 到 5.9 ，將封包遺失樣式 P 套用在編碼資料 Ef 上，用來模擬封包遺 失的情形： 步 步 步驟驟驟 5.6 令 f 為 1 ，代表正在產生第 f 個語音參考檔案的劣化品質檔。 nf 為陣列 Ef 的長度。

步 步 步驟驟驟 5.7 令 i 為 1 ，將 Ef 陣列的內容複製 b_nN_fc次，得到資料陣列 ef ，含有 b_nN_fc ∗ nf 筆資料，為套用過封包遺失樣式的編碼資料。 步 步 步驟驟驟 5.8 檢查封包遺失樣式 P 的第 i 個元素，若為 0 則將陣列 ef 的第 i 筆資料設定 為 0 ；若為 1 則保留陣列 ef 的第 i 筆資料。接下來遞增 i ，並重覆此步驟直到i 為 bN nfc ∗ nf 。 步 步 步驟驟驟 5.9 檢查 f 是否為 F ，若不相等，則遞增 f ，回到步步步驟驟驟 5.7 ；若相等則結束此 步驟。 此時 RTP 處理器獲得 F 個資料陣列 (ef) ，透過 (圖 3.1 (10)) ， RTP 處理器將 所有的 ef ，依序傳給 Speech Decoder 進行解編碼的動作，解編碼後產生劣化品質檔 案。 Speech Decoder 經由 (圖 3.1 (11)) 將解編碼後的劣化品質檔案存入媒體資料庫中 的 Degraded Files 資料表。最後 RTP 處理器由 (圖 3.1 (6)) 回報測試的結果，將產生 的劣化品質檔案清單交給控制器。

3.1.6 PESQ

PESQ (Perceptual Evaluation of Speech Quality) 使 用 P.862 [3] 所 附 的 標 準 程 式，控制器藉由介面 (12) (圖 3.1 (12)) ，輸入語音參考檔案與劣化品質檔案的名 稱。 PESQ 根據輸入的語音參考檔案與劣化品質檔案的名稱，分別由介面 (13) (圖 3.1 (13))與介面 (14) (圖 3.1 (14)) 取得語音參考檔案與劣化品質檔案，並計算其 MOS 值。

3.2

驗

驗

驗證

證

證語

語

語音

音

音品

品

品質

質

質評

評

評估

估

估模

模

模組

組

組正

正

正確

確

確性

性

性

本論文所使用的 RTP 代理人、媒體前置處理器以及媒體資料庫，是由實驗室 的詹依寰同學與作者所共同開發，主要的不同是在於本論文中所修改的 RTP 代理人，

利用 SmartLibrary 作為控制 SmartBits 硬體平台的介面，利用 SmarBits 硬體發送測 試封包，測試封包的傳送與接收的時間可以被精確的紀錄下來，並且能夠對待測系統 進行壓力測試。為了驗證語音品質評估模組的正確性，本論文設計一個實驗環境 (如 圖 3.2) ，觀察語音品質評估模組所支援的三種語音編解碼器在不同封包遺失率環境 下，計算其 MOS 值。並將結果與過去研究結果比較，以驗證本論文整合語音編解碼器 與 RTP 代理人，及所實作的語音品質評估模組所計算的 MOS 值之正確性。 Network Impairment Emulator SmartBits SIPv6 Analyzer Port 1 Port 2 f d i Port 3 NIC 3 g h IP: 192.168.0.2 IP: 10.0.0.2 e NIC 1 NIC 2 IP: 10.0.0.1 IP: 192.168.0.1 a b c 圖 3.2: 驗證語音品質評估模組正確性之實驗環境

實驗環境 (圖 3.2) 主要包含三個元件，網路模擬器 (Network Impairment Emula-tor，圖 3.2 c ) 、 SmartBits (圖 3.2 d ) ，以及 SIPv6 Analyzer (圖 3.2 i ) 。 SIPv6 Analyzer透過 NIC 3 (圖 3.2 h )控制 SmartBits 由 Port 2 (圖 3.2 f ) 發送 RTP 測試封 包，由 Port 1 (圖 3.2 e ) 接收封包。網路模擬器所使用的系統為 IP Wave V.3 Network Impairment Emulator ，模擬實際網路中的封包遺失，可設定其封包遺失率，以及遺 失的模式 (如：“隨機” (Random) 或 “週期式” (Periodic)) 。網路模擬器具有兩張網路 卡，分別為 NIC 1 (圖 3.2 a )與 NIC 2 (圖 3.2 b ) ， 用來轉送來自 SmartBits 的 Port 2的 RTP 封包到 SmartBits 的 Port 1 ，網路模擬器會根據使用者在網路模擬器上設定 的封包遺失率，將 NIC 2 收到的封包標示為 “丟棄” (Dropped) 或是 “通過” (Pass) ， 將標示為通過的封包經由 NIC 1 送出，將標示為丟棄的封包丟棄，並且使標示為丟棄 的封包佔 NIC 2 所收到的封包的比例，為使用者所設定的封包遺失率。各元件組態與 實驗流程說明如下：

網路模擬器的 NIC 1 與 NIC 2 具有 IP 位址分別為 10.0.0.1 與 192.168.0.1 ，設定 為不同網域。SmartBits 的 Port 1 與 Port 2 的 IP 位址分別為 10.0.0.2 與 192.168.0.2 。 SIPv6 Analyzer 設定 SmartBits 產生一個 IPv4 的 RTP 串流，其來源傳輸位址為 192.168.0.2:9000 目的傳輸位址為 10.0.0.2:9000 。依據語音品質評估模組所支援的三種 語音編解碼器 (G.729 、 iLBC 與 G.711u) 設定傳送的封包大小，分別為 74 Bytes 、 92 Bytes 與 214 Bytes 。由於大部分的 SIP UA 實作中， 為 20 ms 發送一次 RTP 封 包，因此 RTP 串流的封包設定為每 20 ms 發送一次。共進行四次實驗，分別設定網路 模擬器的封包遺失率為 5% 、 10% 、 15% 以及 20 % ，並且根據 [17] 設定網路模擬器 的封包遺失模式為隨機。 由於網路模擬器於模擬封包遺失時，使用隨機的方式標示哪些封包為丟棄，在短 時間的實驗內 SmartBits 的 Port 1 計算的封包遺失率，並不會與實驗所設定的封包遺 失率完全相同。而且因為 PESQ 根據輸入的語音參考檔案，以語音訊號所含的能量大 小，判斷語音資料為通話部份 (Speech Bursts) 或是靜音部分 (Silent Periods) ，並對通 話部分的語音訊號，與劣化品質檔案中相對應的語音訊號進行計算。所以 PESQ 輸出 的 MOS 值會受到封包遺失是否位於通話部分影響，如果遺失的封包攜帶的語音資料是 通話部分，則對輸出的 MOS 值影響較大；反之，遺失的封包所攜帶的語音資料是靜音 部分，則對輸出的 MOS 值影響較小。實驗時間若不夠長，可能因為隨機產生的封包遺 失集中在通話部分或是靜音部分，使得計算所得的 MOS 質偏低或偏高。因此實驗時間 需要達一定時間以上，才能使得實驗環境中，實測的封包遺失率接近所設定的封包遺 失率。而且使封包遺失可以平均出現在通話部分與靜音部分，讓這段時間內的系統計 算的平均 MOS 值趨於穩定。 每個語音編解碼器所輸出的實驗結果如圖 3.3 ，隨著測試次數增加，平均 MOS 值 逐漸趨向穩定值，直到測試次數達 45 次之後，每次得到的平均 MOS 值差異已經小於 10−3 。而且網路模擬器所產生的封包遺失率，與設定的封包遺失率差異值，在測試 45 次之後維持在 1% 以下。因此本論文將使用測試 45 次得到的 MOS 值，與其他研究結 果進行比較。

2 2.5 3 3.5 4 4.5 0 5 10 15 20 25 30 35 40 45 Average MOS Number of Tests Average MOS at 5% packet loss rate Average MOS at 10% packet loss rate Average MOS at 15% packet loss rate Average MOS at 20% packet loss rate

2 2.5 3 3.5 4 4.5 0 5 10 15 20 25 30 35 40 45 Average MOS Number of Tests Average MOS at 5% packet loss rate Average MOS at 10% packet loss rate Average MOS at 15% packet loss rate Average MOS at 20% packet loss rate

(a) 語音編解碼器為 G.729 (b) 語音編解碼器為 iLBC 2 2.5 3 3.5 4 4.5 0 5 10 15 20 25 30 35 40 45 Average MOS Number of Tests Average MOS at 5% packet loss rate Average MOS at 10% packet loss rate Average MOS at 15% packet loss rate Average MOS at 20% packet loss rate

(c) 語音編解碼器為 G.711u 圖 3.3: 平均 MOS 值與測試次數關係圖

本論文將三種語音編解碼器，在四種不同封包遺失率環境下的平均 MOS 值，與前 人的研究結果 [18] [19] [20] 進行比較，得到表 3.1 – 3.3 。由於 [19] 的結果中， G.711 在封包遺失率為 5 % 與 10 % 得到的 MOS 值，比 iLBC 在相同情形下得到的 MOS 值 高，與本實驗與 [18] 所做的實驗結果有很大的差異。因此本論文將排除 [19] 所做的 G.711之實驗結果。

表 3.1: 語音編解碼器之 MOS 值 (G.729)

Loss Rate Mean MOS (Our Work) MOS (Relative Work) Differences 5% 3.352 3.39 1.12 % 10% 3.045 3.09 1.46 % 15% 2.789 2.82 1.10 % 20% 2.561 2.63 2.62 % 本論文所測量的三個語音編解碼器在 5% 、 10% 、 15% ，以及 20% 的環境下的 MOS值，與 [20] 、 [19] 及 [18] 的差異值大多在 5% 以下。由於網路模擬器產生的封包

表 3.2: 語音編解碼器之 MOS 值 (iLBC)

Loss Rate Mean MOS (Our Work) MOS (Relative Work) Differences 5% 3.601 3.47 3.75 % 10% 3.366 3.25 3.38 % 15% 3.185 3.05 4.50 % 20% 2.997 2.88 4.06 %

表 3.3: 語音編解碼器之 MOS 值 (G.711u)

Loss Rate Mean MOS (Our Work) MOS (Relative Work) Differences 5% 3.446 3.300 4.42 % 10% 3.080 2.930 5.12 % 遺失率與設定值約有 1% 的誤差，且上述三篇論文的結果，並未說明所使用的語音參考 檔案，也未說明其 MOS 值的計算進行幾次實驗，因此本論文認為 5% 的差異在可以接 受的範圍。 另外，為了驗證封包遺失樣式的套用是否正確，本論文取得 [21] 所提供的 iLBC 參考實作，該參考實作包含 iLBC 的語音編解碼器、語音參考檔案、封包遺失樣式，以 及套用封包遺失樣式後的劣化品質檔案。將該參考實作的語音參考檔案與劣化品質檔 案輸入 PESQ 後得到的 MOS 值，與相同語音參考檔案及相同的封包遺失樣式的情形 下，本系統所計算得到的 MOS 值做比較。於沒有封包遺失的情形下，兩者完全相同 (3.75) 。套用參考實作所附的封包遺失樣式時，兩者亦得到相同的 MOS 值 (3.384) 。 由上述的實驗結果，可以驗證語音品質評估模組正確無誤。

第

第

第四

四

四章

章

章 實

實

實驗

驗

驗環

環

環境

境

境與

與

與實

實

實驗

驗

驗結

結

結果

果

果

在 VoIP (Voice over Internet Protocol) 應用中 IPv4 位址不足的問題，目前有 IPv6 (Internet Protocol Version 6) [22] 及 NAT (Network Address Translator) [23] 兩種解決 方案。 IPv6 在使用上可分為兩種 Pure IPv6 及 IPv6 通道，前者是網路節點全面使 用 IPv6 ；後者是在 IPv6/IPv4 轉換的過程中提供 IPv6 的連線能力給 IPv4 網路的使 用者。 IPv6 通道可再分為， IPv6-in-IPv4 通道與 IPv6-in-IPv4 UDP (User Datagram Protocol) 通道，前者將 IPv6 封包封裝在 IPv4 封包內，需要 Public IPv4 位址才能建 立 IPv6-in-IPv4 通道；後者將 IPv6 封包封裝在 IPv4 UDP 封包內，讓 NAT 內的使用 者使用 IPv6-in-IPv4 UDP 通道，獲得 IPv6 的連線能力。

NAT 雖然解決了 IPv4 位址不足的問題，但是在 VoIP 應用中，在 NAT 下的使用 者還需要 SIP/RTP 穿越 NAT 的機制。目前 VoIP 服務提供者大多使用 SBC (Session Border Controller) [24] 解決 SIP/RTP 穿越 NAT 的問題。本論文將測試 Pure IPv6 、 IPv6-in-IPv4通道、 IPv6-in-IPv4 UDP 通道，以及 SBC 四種解決方案，進行網路元件 的效能分析與比較。

本論文將選出的 IPv4 位址不足解決方案，簡化其使用環境如圖 4.1 。第一種： UAC (User Agent Client ，圖 4.1 (1)) 與 UAS (User Agent Server ，圖 4.1 (2)) 都使用 Pure IPv6解決 IPv4 位址不足的問題，通話時不需要其他元件轉送 RTP 封包， UAC 與 UAS 直接互相傳送 RTP 封包。第二種： UAC 使用 Public IPv4 ， 而 UAS 為 NAT 下之使用者，以 SBC 解決穿越 NAT 的問題， RTP 封包經過 RTP Proxy (圖 4.1 (4)) 與 NAT 1 (圖 4.1 (7)) 。 第三種： UAC 使用 Pure IPv6 ， UAS 使用 IPv6-in-IPv4 通 道， RTP 封包經過 Tunnel Server 1 (圖 4.1 (5)) 。 第四種： UAC 使用 Pure IPv6 ，

UAS使用 IPv6-in-IPv4 UDP 通道， RTP 封包經過 Tunnel Server 2 (圖 4.1 (6)) 與 NAT 2 (圖 4.1 (8)) 。所有環境中 UAC 與 UAS 皆透過 SIP Server (圖 4.1 (3)) 繞送 SIP 信令。

IPv4/IPv6 IPv4 /IPv6 /IPv6 Tun nel IPv_4/IP v6/I_Pv6 Tu_nne l IPv4 Privat_{e IPv} 4

IPv6 _{IPv6 Tun}nel

(1) UAC (2)UAS (3) SIP Server (4) RTP Proxy (6) Tunnel Server 2 IPv4 (7)NAT 1 IPv6 Tunn el (Public IPv4 ) (8)NAT 2 (5) Tunnel Server 1 IPv₆ Public _IPv4 IPv6 T unnel (Priva te IPv 4) 1 2 3 4 圖 4.1: VoIP 使用環境示意圖 本論文在受控制的網路環境下，設計四個實驗模擬圖 4.1 所示的四種使用環境， 探討各種 IPv4 位址不足的解決方案的網路元件對通話品質的影響，最後以端到端 (end-to-end)平均延遲、封包遺失率及 MOS 來評估其效能。

4.1

實

實

實驗

驗

驗 1 – Pure IPv6/ Public IPv4 使

使

使用

用

用環

環

環境

境

境之

之

之效

效

效能

能

能評

評

評估

估

估

為了評估 Pure IPv6 使用環境下，在 RTP 封包不經過任何元件， UAC 與 UAS 藉 由 Layer-2 Switch 連接所有設備，並直接傳送時的通話品質為何，並以此結果作為其 他環境的比較標準，本論文設計實驗 1 的實驗環境。藉由此實驗，了解此依環境中不 同語音編解碼器 (CODEC) 對於通話品質的影響，並以同時通話個數對平均延遲、封 包遺失率，以及 MOS 的評估其效能。

Layer-2 Switch SmartBits SIPv6 Analyzer IPv4/IPv6 100Mbps SIP Server IPv4/IPv6 100Mbps IPv4/IPv6 100Mbps IPv4/IPv6 100Mbps IPv4/IPv6 100Mbps IPv6: 2001:f18:113::10 IPv6: 2001:f18:113::11 Switch Port 1 NIC Switch Port 2 Switch Port 3 Switch Port 4 Switch Port 5 Port 1 Port 2 NIC 1 NIC 2 a b d f k i c e j Port 3 NIC 3 g h

圖 4.2: Pure IPv6/Public IPv4 效能測試環境

Switch (圖 4.2 c )將所有元建連接起來。 SmartBits (圖 4.2 e ) 負責產生 RTP 的測試 封包。 SIPv6 Analyzer (圖 4.2 j ) 負責發送 SIP 信令以進行 SIP 通話建立流程、產生 SDP所需攜帶的傳輸位址 (Transport Address ，參考 RFC 3550 [7]) ，並且根據收到的 SIP訊息 SDP 攜帶的傳輸位址，設定 SmartBits 。最後由 SIPv6 Analyzer 產生實驗結 果報表。本實驗以 Pure IPv6 的設定為例，各元件的組態如下：

SIP Server 所使用的系統為 Linux 2.6.21.3 並執行 SER [25] 0.9.6 ，而 NIC (圖 4.2 b

)具有 IPv6 位址，連接到 Layer-2 Switch (圖 4.2 c ) 。SmartBits 型號為 SMB-600B ，搭配 TeraMetrics LAN-3321A 卡板，卡板具有兩個 10/100/1000 MBps 網路埠即 Port 1 (圖 4.2 d )與 Port 2 (圖 4.2 f ) 。分別模擬為圖 4.1 中的 UAC 與 UAS 並負責收 送 RTP 封包， IPv6 位址分別為 2001:f18:113::10 與 2001:f18:113::11 。 Port 3 (圖 4.2

g

) 與 SIPv6 Analyzer 的 NIC 3 (圖 4.2 h ) 皆具有 IPv4 位址， SIPv6 Analyzer 透過 此連線控制 SmartBits。SIPv6 Analyzer 之 NIC 1 (圖 4.2 i ) 與 NIC 2 連接到 Layer-2 Switch (圖 4.2 k )負責收送 SIP 信令以建立通話，具有 IPv6 位址。所有的網路連線皆 是 100MBps Ethernet 。Public IPv4 之實驗環境與 Pure IPv6 環境相同，只有 IP 位址 組態改變為 IPv4 ，因此本節不重複描述其組態。

4.1.1

實

實

實驗

驗

驗 1 實

實

實驗

驗

驗流

流

流程

程

程

SIPv6 Analyzer 根據同時通話個數決定進行 SIP 通話建立流程的次數， 以 NIC 1 當作 UAC 送出 SIP INVITE 訊息， 訊息中 SDP 所攜帶的傳輸位址 ，由 SmartBits 的 Port 1 的 IPv6 位址與 UDP 通訊埠 9000 組成 (i.e., [2001:f18:113::10]:9000) 。 SIP INVITE 訊息經由 SIP Server 將 SIP 訊息繞送至 SIPv6 Analyzer 的 NIC 2 ， SIPv6 Analyzer 接著以 SmartBits 上 Port 2 的 IPv6 位址與 UDP 通訊埠 9000 產生傳輸位 址 (i.e., [2001:f18:113::11]:9000) ，攜帶於 SIP 200 OK 訊息，並以 NIC 2 送出。 SIPv6 Analyzer NIC 1 收到 SIP 200 OK 訊息後回應 ACK ，完成通話建立。在每次通話建立 完成後遞增 UDP 通訊埠，產生新的傳輸位址以供應下次 SIP 通話建立流程使用直到 完成同時通話個數所需的次數。

成功完成 SIP 通話建立流程之後， SIPv6 Analyzer 根據 SDP 所攜帶的傳輸位址， 透過 NIC 3 設定 SmartBits 的 Port 1 與 Port 2 的傳輸位址，並依據所使用語音編解碼 器決定送出 RTP 封包的間隔時間。本論文所使用的三種語音編解碼器(G.729 、 iLBC 與 G.711u) ，在大部分的實作中是間隔 20 ms 送出一個 RTP 封包，因此設定送出 RTP 封包的間隔為 20 ms ，最後以 Port 2 送出 RTP 封包 。由於 P.862 所附的 20 個語音參 考檔案，編碼後共產生 7883 筆資料，因此測試時每個封包串流送出 7883 個封包，即 每次測試進行時間約 157 秒。 接下來則對此系統進行 (1) 封包遺失率之測量 、 (2) 平均延遲之測量，以及 (3) MOS之測量。由於 SmartBits 可以同時紀錄封包遺失率與封包的延遲，因此 (1) (2) 的 測試可同時進行。 封 封 封包包包遺遺遺失失失率率率之之之測測測量量量 在此說明封包遺失率計算方式，每次實驗結果的封包遺失率計算如公式 4.1 ， SmartBits的 Port 2 送出封包總數 N ，由 SmartBits 的 Port 1 收到封包總數 R 。

Packet Loss Rate = R

N ∗ 100% (4.1) 尋找最大吞吐量值的方式是利用二分逼近，在給定的上限與下限之間進行搜尋， 並觀察每次測試結果的封包遺失率，直到找到最大吞吐量為止。測試前需要計算出線 路可負載的通話個數上限 (MC) ，並與 SmartBits 可以產生封包串流 (Packet Stream)

上限數目 (2048) 比較，並選取其最小值，作為測試的上限值 (U) 。 U 值決定了搜尋 最大吞吐量測試的搜尋上限之初始值，以及封包遺失率測試、平均延遲測試，與 MOS 測試中， SmartBits 所要模擬的同時通話個數上限。 MC 由線路的頻寬，與使用語音

編解碼器 C 的封包串流所需的頻寬 (BC) 決定。 BC 計算方式為每個封包所需傳輸的

時間，乘上每秒鐘傳送封包數。 BC 於 100Mbps Ethernet 的計算方式為 (Inter-frame

Gap + Preamble + Length of Ethernet Frame + CRC) * 50 。以 G.729 的測試為例， 其 BC 值為 47200 。 MC 值由公式 4.2 計算為 2118 。 MC = b 100MBps BC c (4.2) 2118 > 2048因此選 2048 為 U ，進行搜尋最大吞吐量的步驟如下： 步 步

步驟驟驟 1 設定上限 (u) 為 2048 ，下限 (l) 為 0 ，最大吞吐量(T ) 為 0 ， SIPv6 Analyzer 將在上下限範圍中改變同時通話個數 (S) ，測試待測系統以求得其最大吞吐量。 步 步 步驟驟驟 2 設定同時通話個數 S 為 du+l 2 e 。 步 步 步驟驟驟 3 進行通話建立流程，並進行測試。 步 步 步驟驟驟 4 測試結果可知是否有封包遺失，若有封包遺失則設定 u 為 S ；若無封包遺失則 將 l 設定為 S 。 步 步 步驟驟驟 5 檢查 T 是否與 S 相同，若不同則設定 T 為 S 並重複 步步步驟驟驟 2 到 步步步驟驟驟 5 ；若相 同則表示測試已達終止狀態。此時，最大吞吐量值應在 T ± 1 的範圍內。 平 平 平均均均延延延遲遲遲之之之測測測量量量 每個封包的端到端延遲 (D) 如公式 4.3 ，計算平均延遲的方式，是所有收到的封 包之端到端延遲平均值。

D = Propagation Delay + Transmission Delay + Processing Delay (4.3) SmartBits 在進行測試的時候，可以設定傳送埠在每個送出的封包末端 (CRC 資訊 之前)，覆蓋 18 Bytes 的簽章資料。 內含有四個欄位：封包所屬的串流編號 (Stream ID)、 該封包的序號 (Sequence) 、該封包離開傳送埠的時間郵戳 (Timestamp) 、該封 包被接收埠接收的時間郵戳。 SmartBits 接收埠在收到封包時填上其中的接收時間郵 戳，其他欄位則是在送出時填上。藉由此簽章資訊， SmartBits 可以獲得每個封包的 端到端延遲，統計每個串流中封包延遲時間，並產生紀錄。 SIPv6 Analyzer 在測試結 束時，將 SmartBits 所產生的紀錄取出，計算每個封包串流的平均延遲如公式 4.4 。 Li 、 di 與 pi 分別代表第 i 個封包串流之平均延遲、 SmartBits 所收到第 i 個封包串流 之封包的端到端延遲總和，與 SmartBits 所收到第 i 個封包串流之封包的總數。 Li = di pi (4.4) 最後系統輸出所有封包串流的平均延遲之平均值 (L) ，作為測試輸出之結果，如 公式 4.5 ， n 為 SmartBits 測試時產生的封包串流數目。 L = n X i=1 Li n (4.5) 封包遺失與平均延遲的測試，由 1 個同時通話開始，接下來是 100 個同時通話， 之後每次遞增 100 個同時通話，即 200 、 300 、 直到上限 (U) ，並且紀錄每次得到的 平均延遲與封包遺失率。 MOS 值值值之之之測測測量量量

為了解 UAC 與 UAS 間的通話品質，每次測試時有 n 個同時通話， SIPv6 Ana-lyzer將設定 SmartBits 產生 1 個有標定簽章的封包串流，其餘 n − 1 封包串流做為背

景資料流 (Background Traffic) 。藉由追蹤此一有標定簽章的封包串流中的封包，得知 其每個封包接收狀態 (“已接收” 或 “未接收”) ，產生每個參考檔案所對應的劣化品質檔 案 (Degraded File) ，並將每一個參考檔案，與其劣化品質檔案輸入 PESQ 評估後得到 MOS值。最後將所有得到的 MOS 取平均後得到最後輸出的 MOS 值，此 MOS 代表實 驗中所觀察的 UAC 與 UAS ，藉此了解在各種不同的背景資料流情形下， VoIP 通話 的品質變化情形。 測試過程較前兩者不同，同時通話個數是由最大吞吐量 (T ) 開始測試，可以獲得 沒有封包遺失的情形下的 MOS 值，接下來測試同時通話個數超過最大吞吐量的情形， 由 d T 100e ∗ 100 個同時通話開始，每次測試遞增 100 個同時通話。如此測試便可了解在 不同的同時通話個數下，封包遺失率與 MOS 值的關聯性。 至此完成一種語音編解碼器的測試。接下來重複上述流程，將所有語音編解碼器 測試完畢即完成 Pure IPv6 之測試。接下來根據 4.1 的設定修改各元件的 IPv4 設定， 依照相同實驗流程完成 Public IPv4 之測試。

4.1.2

實

實

實驗

驗

驗 1 實

實

實驗

驗

驗結

結

結果

果

果

14 16 18 20 22 24 26 28 0 200 400 600 800 1000 1200 1400 1600 1800 2000 Average Latency ( µ s)

Number of Concurrent Calls

G.729 - IPv4 iLBC - IPv4 G.711u - IPv4 G.729 - IPv6 iLBC - IPv6 G.711u - IPv6

圖 4.3: Pure IPv6/Public IPv4 效能測試結果 – 同時通話個數對平均延遲之關係圖 預期此環境並不會有明顯的效能損失，同時通話個數與平均延遲的關係實驗結果 如圖 4.3 ，與預測結果相符。經實驗中所使用三種編解碼器 (G.729 、 iLBC 與 G.711u)

編碼後之封包，長度分別為 94 、 112 與 234 Bytes ，其平均延遲約為 16 µs 、 17.5 µs 與 27.5 µs ，較長的封包，其平均延遲較長。不同的語音編解碼器的實驗結果，其平均 延遲的差異值，推測主要來自於封包的傳輸延遲 (Transmission Delay) 。傳輸延遲依據 100MBps Ethernet的理論值計算，如公式 4.6 。

Inter-frame Gap + Preamble + Length of Ethernet Frame + CRC

100MBps (4.6) 假設處理延遲 (Processing Delay) 約略為定值，所有封包傳遞於相同媒體，因此傳遞延 遲 (Propagation Delay) 也相同。以 G.729 的封包端到端延遲為基準，由公式 4.3 與公 式 4.6 計算，得到使用 iLBC 與 G.711u 的封包的端到端延遲的理論值之差異，分別為 1.44 µs 與 11.2 µs 。將 iLBC 與 G.711u 的 RTP 封包的平均延遲，減去使用 G.729 的 RTP 封包平均延遲，得到端到端延遲的實測值差異。比較實測值與理論值，最大的誤 差列於表 4.1 。 表 4.1: 封包傳輸延遲差異值之理論值與實測值之比較表 Pure IPv6 Public IPv4 語音編解碼器 iLBC G.711u iLBC G.711u 傳輸延遲理論差異值 1.44 11.2 1.44 11.2 傳輸延遲實測最大差異值 1.579 11.325 1.539 11.295 實測與理論值之最大誤差 0.139 0.125 0.099 0.095 由表 4.1 可知，實測結果，之最大誤差不超過 SmartLibrary 所說明的測試精準度 誤差範圍 ± 0.2 µs ，可驗證實驗結果中，使用不同語音編解碼器的 RTP 封包，其平均 延遲的差異值主要來自於傳輸延遲。並可得知在實驗 1 實驗環境中， Layer-2 Switch 並不會造成顯著的效能損失，不論是平均延遲或是封包遺失。使用 G.729 、 iLBC 與 G.711u 三種語音編解碼器的通話品質，經由 PESQ 評估，分別為 3.848 、 3.956 與 4.44 ，為其他實驗中所能得到最佳的 MOS 值。

4.2

實

實

實驗

驗

驗 2 – SBC 使

使

使用

用

用環

環

環境

境

境之

之

之效

效

效能

能

能評

評

評估

估

估

VoIP 服務中，目前服務提供者大多使用 SBC (Session Border Controller) [24] 解 決 SIP/RTP 穿越 NAT 的問題。 SBC 包含兩個元件，分別為圖 4.1 中的 SIP Server (圖 4.1 (3)) 與 RTP Proxy (圖 4.1 (4)) 。以 SBC 解決 SIP/RTP 穿越 NAT 問題的 VoIP 使用環境中， RTP 封包會經過 NAT 與 RTP Proxy ，為了釐清影響整理環境效能的因 素，本論文分別測試 NAT 與 RTP Proxy ，最後再以整合環境測試，評估 SBC 使用環 境的通話品質。

4.2.1 RTP Proxy

效

效

效能

能

能測

測

測試

試

試

Layer-2 Switch SmartBits SIPv6 Analyzer IPv4 100Mbps RTP Proxy IPv4 100Mbps IPv4 100Mbps IPv4 100Mbps IPv4 100Mbps IPv4: 140.113.1.10 IPv4: 140.113.1.11 Switch Port 1 NIC Switch Port 2 Switch Port 3 Switch Port 4 Switch Port 5 Port 1 Port 2 NIC 1 NIC 2 c d f h m k e g l Port 3 NIC 3 i j IPv4: 140.113.1.1 SIP Server IPv4 100Mbps Switch Port 1 NIC a b 圖 4.4: RTP Proxy 效能測試環境

RTP Proxy 效能測試的環境如圖 4.4 ，由於 RTP Proxy 需要與 SIP Server 進行互 動，才能設定 RTP Proxy 轉送 RTP 封包的傳輸位址，因此與實驗 1 (圖 4.2) 的環境相 比，新增 RTP Proxy (圖 4.4 c )。RTP Proxy 所使用的程式為 Portaone RTP Proxy ， 為開放原始碼之軟體， Portaone RTP Proxy 使用 IPv4 位址 140.113.1.1 。SIP Server 具有 IPv4 位址， SIP Server 透過網路控制 RTP Proxy 。SmartBits 的 Port 1 與 Port 2的 IPv4 位址分別為 140.113.1.10 與 140.113.1.11 ，其餘設定同實驗 1 (圖 4.2) 。

Proxy 的系統架構如圖 4.5 ， Portaone RTP Proxy (圖 4.5 a ) 是利用 UDP Socket (圖 4.5 e )，進行轉送 RTP 封包的動作。 Portaone RTP Proxy 主要由 RTP For-warding Table (圖 4.5 b )與 Polling Event Handler (圖 4.5 c ) 所構成。 Polling Event Handler定期呼叫系統的 Poll System Call (圖 4.5 d )，檢查 RTP Forwarding Table 所 維護的所有 UDP Socket 之狀態，了解其緩衝區是否已經有資料可供讀取，並回傳所有 UDP Socket 的狀態。 Physical Interface Module Physical Interface IPv4 Network UDP Socket Kernel Level RTP Proxy Polling Event Handler

Poll System Call RTP Forwarding Table User Level e d c b a g h IPv4 Forwarding f 圖 4.5: Portaone RTP Proxy 系統架構

Portaone RTP Proxy核心的運作機制為 Polling Event Handler ，其運作流程如下：

步 步 步驟驟驟 1 初始化時間郵戳 ts = 0 。 步 步 步驟驟驟 2 取得目前系統時間，並存於時間郵戳 tc 。若 (tc− ts) < 10ms，則表示距離上

次取得系統時間已經過了 tc− tsms。讓 Portaone RTP Proxy 的程序 (Process) 進

入睡眠狀態 10 − (tc − ts) ms ，等待作業系統將程序喚醒，讓 Poll Event Handler

大約保持在 10 ms 才呼叫一次 Poll System Call 。喚醒後取得目前系統時間，存 於時間郵戳 ts ；若 (tc− ts) ≥ 10ms ，將 tc 值存入 ts 。

步 步