Mobile-voip Based On Sip

1. 序論 ..................................................................................................2 2. 相關研究 ..........................................................................................2 2.1 2.2 2.3

SIP (Session Initiation Protocol) 簡介 .................................................2 SIP 命名方式.........................................................................................3 SIP 元件介紹 ........................................................................................4

2.4 2.5 2.6

SIP message ...........................................................................................5 SDP ........................................................................................................7 SIP 運作模式.........................................................................................8

3. 系統設計 ........................................................................................ 11 3.1 3.2 3.3

系統設計考量 ...................................................................................... 11 系統架構..............................................................................................12 系統運作流程 ......................................................................................12 3.3.1 註冊 ................................................12 3.3.2 交接 (handoff) .......................................13 3.3.3 呼叫建立 (call setup) .................................14 3.3.4 結束通話 ............................................15 3.3.5 漫遊 (Roaming) .....................................16

4. 系統實做 ........................................................................................17 4.1 4.2

軟體架構..............................................................................................17 軟體架構..............................................................................................18 4.2.1 Message Parser 模組 ..................................19 4.2.2 Transaction 模組......................................21 4.2.3 SIP UA Logic 模組 ....................................22 4.2.4 Line Manager 模組 ...................................23

5. 結論 ................................................................................................24

1

1. 序論 以 網 際 網 路 為 媒 介 傳 送 聲 音 的 技 術 稱 為 VOIP(Voice Over Internet Protocol)[1]，傳統的 VOIP 是以有線網路為架設的基礎，在這 種環境下，使用者在使用行動電腦時，若是在執行 VOIP 的應用程式 顯然不具有行動力，使用者雖然使用著行動電腦，但並不是在行動環 境中，這樣一旦使用者離開位置，勢必會造成斷訊的問題。如果可以 將 VOIP 應用在行動環境中，則可以讓使用者在同一棟建築物或是一 個類似校園大小般區域性的空間漫遊，將原有的 VOIP 推展至行動環 境中正是本篇研究報告的動機。本篇研究報告，將以 SIP 為通訊平 台，發展一套 MVoIP 的系統。

2. 相關研究 2.1 SIP (Session Initiation Protocol) 簡介 最先由美國哥倫比亞大學的 Henning Schulzrinne 教授在 1998 年 初開始發展，1999 年 3 月由 IETF 的 MMUSIC(Multipart Multimedia Session Control)工作小組制定正式標準成為 RFC 2543[2]， 1999 年 9 月 IETF 成立新的工作小組 ,負責 SIP 新版本 2.0 的制定 , 並於 2000 年 7 月釋出初版 RFC 2543bis，於 2001 年發佈了 RFC 3261 [3]。 RFC 3261 的發佈，標示著 SIP 的基礎已經確立，隨後又發佈了 幾個 RFC 增定版本，充實了安全性及身份認證等幾個領域的內容， 例如 RFC 3262[4]對臨時回應做了可靠性的規範。RFC 3263[5]確立了 SIP proxy 的定位規則。RFC 3264[6]提供了 Offer/Answer Model，RFC 3265[7]則是確立了具體的事件通知。 如同 Internet 一樣，SIP 易於理解、擴充、及實做，作為 IETF 的 規範，SIP 將 Internet 開放標準的精神延伸至通訊領域，實現了不同 2

電腦、電話、及軟體的通訊。SIP 的訊息類似於 HTTP (RFC 2068[8])， 其定址方式，則是重用了 SMTP 的定址方式，SIP address (如： sip:[email protected])與 E-mail address 的結構相同，SIP 甚至 利用 Web 的體系結構，如 DNS，而使得 SIP 的使用者之間的通訊， 有更高的擴充性。

SIP 有下列幾點特性 Ø 利用文字(Text-based)的方式來編碼，類似 HTTP/1.1 Ø Client-Server 的架構 ü Clients 端初始一個呼叫(caller) ü Servers 端回應呼叫 (callee)

Ø 訊號與資料獨立，SIP 負責訊號部分，資料傳送部分 可以使用 RTP，TCP，UDP… Ø 可 與 其 他 IETF 所 制 訂 的 協 定 配 合 ， 例 如 ： RFC2327(SDP)[12], RFC2616 (HTTP/1.1) [11], RFC2396(URL)[13]…

2.2 SIP 命名方式 SIP 的位址稱做 SIP URLs，其格式為 user@host ，使用者利用 REGISTER 的 SIP request 來結合自己的 SIP URLs user 代表使用者名 稱或是電話號碼 host 代表 domain name 或是數字型態的 IP address 舉

例

來

說

sip:[email protected]

sip:[email protected]

3

或

是

2.3 SIP 元件介紹 在 SIP 是一個 Client and Server 的架構，在此環境當中，有三個 主要的元件分別為: User Agents, Servers 還有 Location Servers。

Ø User Agents 在 SIP 環境中是終端設備，主要負責產生 SIP requests，用來建 立多媒體會議(media session)，並且傳送及接收多媒體資料。User Agents 又分成了 User Agent Client (UAC) 及 User Agent Server 兩種 模式。UAC 負責產生一個 Request 及處理一個 Response，UAS 怎是 接受一個 Request 並且產生 response。在 Session 建立過程中，UA 通 常需要接替著扮演這兩個角色。這點並不像其他 Client and Server 架 構，例如 HTTP，PC 一直扮演著 HTTP client 的角色，而 Web Server 也一直扮演著 HTTP Server 的角色。

Ø Servers 根據 RFC 2543 中定義，Server 主要分成了 Proxy, Redirect, 以及 Registrar server。

ü SIP proxy： 負責接受 UA 或 其他 proxy 所 發 送 的 SIP Request，並且轉送 Request 到其他地方。

ü Redirect Server：負責接受 UA 或其他 proxy 所發送的 SIP Request，並且傳回 redirection response (3xx)，指出這個 Request 應該送往何方。

ü Registrar Server：負責接受 SIP registration requests，並且 更新 SIP UA 在 Location Server 或其他資料庫當中的資訊。

4

SIP proxy, Redirect 還有 Registrar servers 只有做單純的 signaling 轉送，他們沒有傳送多媒體資料及產生 SIP Request 的能力。

Location Servers 在 RFC 2543 中，通常當作一個資料庫來使用。資料庫當中可以 存放使用者的資訊，例如 URLs, IP address, 或是其他資料等等。SIP UA 不能直接來存取 Location server，而是透過 proxy, redirect,或是 registrar server。 2.4 SIP message SIP message 的語意及表頭與 HTTP/1.1(RFC 2616)相同。可以分 成兩類，一類是 Request ，另外一類是 Response。 在 RFC 2543 當中，定義了六個基本的 SIP request 種類，如表 2.1 所示。 方法

說明

INVITE

建立會議(Session)

ACK

對 INVITE 做最後的確認

BYE

結束一個已經存在的會議

CANCEL

取消尚未建立連線的會議

REGISTER

註冊使用者的 URL

OPTIONS

查詢 Server 及其功能 表 2.1、SIP methods

Response 用 status-codes 來 表 示 回 應 的 內 容 ， 符 合 且 延 伸 HTTP/1.1 response code。 分成 Provisional(暫時)及 Final(決定)兩類，Provisional 為 1xx 類

5

別，Final 則包括了 2xx，3xx，4xx，5xx，6xx 等類別，表 2.2 表示各 個不同類別的 Response。 方法 1xx

說明 Informational

2xx 3xx

Successful Redirection

4xx

Client-Error

5xx 6xx

Server-Error Global-Failure 表 2.2、SIP Response

1xx Informational responses 指的是 server 或是 proxy 正在執行一 些未來的動作，並還沒有一個定義好的 response。2xx 代表這個 request 是成功的，並且必須結束一個搜尋的動作。3xx Redirection 會回覆欲 通訊的使用者目前的位置資訊。4xx response 是 Server 對於 UAC 所 提出的 request 回覆一個失敗的 response。5xx response 是代表 Server 本身發生了錯誤。Global Failures 6xx 指的是 server 有一個關於特定的 使用者最終的資訊，不僅僅是這個特定的 Request-URI，所有未來的 對這個使用者的搜尋都應該被終止。表 2.3 為幾個常用的 Response code 範例 Response code

Reason Phrase

100

Trying

200

OK

302

Moved temporarily

403

Forbidden

503

Service Unavailable

600

Busy 表 2.3、SIP Response code 6

2.5 SDP SIP message body 當中，可以攜帶任何的資料，但通常是給通訊雙 方用來協商 session 相關的資訊。SIP 本身並沒有提供多媒體協商的能 力，多媒體協商必須仰賴 Session Description Protocol (SDP)，SDP 本 身並不是一個通訊協定，它的描述語言是基於文字的。 SIP 利用 answer/offer 的模式來使用 SDP。呼叫者送出一個 INVITE 訊息並攜帶著 SDP，其中 SDP 包含了呼叫者想使用的多媒體 的格式、位址、Port，被呼叫方在回應的時候，便可以針對呼叫者所 提出的 SDP，做出接受或拒絕的回應，這種雙方協商的結果，就可以 得知多媒體資料格式及通訊的位址為何。 SDP 定義在 RFC 2327[9]當中，後來經過修訂及匯集 draft 之後， 發表了 RFC 3264 “An Offer/Answer Model with SDP”，RFC 3264 明確 的描述應該如何將 SIP 與 SDP 一起使用。 SDP 簡單地提供一個描述 session 資訊的格式。基本而言，一個 session 是由數個 media stream 所組成，因此，要描述一個 session 必 須要有數個相關的參數。SDP 當中有 session-level 與 media-level 的參 數， Ø session-level 的參數包含了 ü session 的名稱、 ü session 的發起者、 ü session 的期限等等。 Ø Media-level 的資訊包含了 7

ü media 的種類， ü port number、 ü 傳輸協定以及 media 的格式。

圖 2.1 為 SDP 的結構。 Session Description Session Level Protocol Version Originator and Session ID Session Name Session Time

Media Name and Transport Connection Information Media Description

圖 2.1 SDP session Description Structure 2.6 SIP 運作模式 SIP 的呼叫建立如圖 3.2 所示，開始的時候 caller 會送出 SIP INVITE 的訊息給 callee，callee 收到之後，會馬上回應一個 100 Ringing 的訊息通知 caller，說明目前 callee 已經收到 INVITE 訊息且正在處理 中，如果 callee 願意與 caller 通話，便會送出 200 OK 的 response，最 後 caller 再送出 ACK，此時便可以開始進行會議。當其中一方想結束 通訊時，便會送出 BYE 的訊息來通知對方，對方回應 200 OK 便可 8

以結束目前進行會議。

Client (Caller)

Server (Callee) INVITE 100: Trying 180: Ringing 200: OK ACK RTP BYE 200: OK

圖 2.2 SIP call flow

2.5.1 SIP proxy 模式 以圖 2.3 為例，caller ([email protected]) 先送出一個 INVITE 訊 息呼叫 callee ([email protected])，proxy server 收到之後便會去做查 詢 ， 查 詢 完 成 之 後 便 得 知 目 前 callee 實 際 的 位 址 在 [email protected]，於是 proxy server 便會以 [email protected] 為對象 發出 INVITE 訊息。callee 在回覆 200 OK 的時候，會將 200 OK 的 response 回應給 proxy server，再由 proxy server 轉送給 caller。

9

[email protected]

2. INVITE

SIP Proxy

[email protected]

4. Response

1. INVITE [email protected]

3. Response

[email protected]

圖 2.3 SIP proxy mode

2.5.2 SIP redirect 模式 如圖 2.4 所示，與 proxy server 不同的地方，在於 redirect server 查詢得知 callee 實際的位址的時候，並不像 proxy server 會直接代為 處理之後 session 的建立，而是將 callee 的實際位址告知 caller，讓 caller 自行送出新的 INVITE。使用 redirect 的模式，可以減低 server 的負擔， 但 caller 必須有能力將 request 的訊息傳送到 callee。 [email protected]

1. INVITE [email protected] Redirect Server

2. Move temporally contact : [email protected] 3. INVITE [email protected]

[email protected]

4. Response

圖 2.4 SIP redirect mode

10

3. 系統設計 3.1 系統設計考量 SIP 為應用層(Application-Layer)的協定，所以不需要改變作業系 統便可以支援，以 SIP 來支援行動通訊，對於 real-time 的服務可以提 升其效能。相較於 Mobile IP，SIP 較易於與其他 IETF 的協定整合， 對於行動電信也提供更廣泛的應用。 在 未 來 的 發 展 性 ， SIP 已 經 獲 得 3GPP (Third Generation Partnership Project) 、 3GPP2 (Third Generation Partnership Project Number 2)等機構認證，成為未來第三代行動通訊 (3G) 的標準。 系統設計的目標就是要讓使用者可以在 SIP base 的環境中，使用 VoIP 的服務，並且在使用者漫遊的時候，系統會自動建立連線並且 繼續之前的通話。 Location Server

Internet

SIP Proxy 1 Ethernet

Ethernet

SIP UA

SIP Proxy 2

WLAN SIP UA

WLAN

SIP UA SIP UA

圖 3.1 System Architecture

11

3.2 系統架構 圖 3.1 為系統架構，在 Internet 底下分成數個子網路，每個子網 路會有一個 Proxy Server 來管轄，UA 可以經由 Ethernet 的 Tier 或者 WLAN 的 Tier 與其他 UA 進行通訊。整個 SIP 環境，由一個 Location Server 來負責紀錄 UA 目前所在的 Proxy Server，Proxy Server 則記錄 UA 實際的 IP address。 Proxy 位於 Ethernet，會以廣播的方式主動的發送 Beacon 給 UA， 其中 Beacon 的內容為 Proxy 的 IP address，UA 可以根據 Proxy 的 IP 判斷目前所處的網域，如果漫遊到新的網域底下的話，會向 Proxy 提 出註冊，Proxy 紀錄 UA 的 SIP URL 與 IP address，之後將 Proxy 的 IP address 以及 UA 的 SIP URL 向 Location Server 進行更新。利用這樣 子的方式，Proxy 可以掌握目前 UA 位於何處。 3.3 系統運作流程 3.3.1 註冊

UA

Proxy

Location server

Beacon Register Update OK

200 OK

圖 3.2 Registration Sequence

12

圖 3.2 表示一個註冊的流程，其中實線部分為 SIP 訊息，虛 線部分則非 SIP 訊息。 首先 UA 會根據 Proxy 所發送的 Beacon，向 Proxy 發送註冊訊息， Proxy 收到之後，會根據註冊訊息的內容，紀錄 UA 目前的 IP address， 並且將 UA 的 SIP URL 以及 Proxy 本身的 IP 向 Location Server 傳給 Location Server 做紀錄。成功之後 Location Server 會回傳 Ok 的訊息， Proxy 再回傳 200 Ok 的訊息給 UA，如此就完成註冊的流程。 3.3.2 交接 (handoff) 當 UA 在通訊中移動時，可能漫遊到另一個 Proxy 所管轄的 Domain，或者漫遊到的地方不支援之前所使用的網路設備，Ethernet 網路線；此時，UA 需要尋找新的 Proxy 要求服務，持續保持 online 的狀態，並持續之前的通訊。 Handoff 可分為兩種模式：Horizontal handoff & Vertical Handoff； 當 UA 移動到新環境時，不需變換網路接取介面而能繼續連上網路， 此種狀況的 Handoff 便稱為 Horizontal Handoff；若需變換另一種網路 接介面連接上網，此種狀況的 Handoff 便稱為 Vertical Handoff。 由於 SIP 是 Application Layer 的 Protocol，所以不需考慮底層是利 用何種設備上網，，在系統內的運作皆是一致的，系統只須依據 UA 在 Handoff 時所帶上來的位置資訊去重建資料封包的傳送路徑，而 UA 本身也不須知道自己為 Horizontal handoff or Vertical Handoff，只 須把自己目前所在的 IP Address 送上系統，系統所提供的功能會處理 移 動 後 的 路 由 問 題 ， 系 統 可 藉 由 此 功 能 給 予 UA 移 動 時 的 Transparency。 Handoff 的流程如圖 3.3 所示

13

UA

UA

Proxy

Location server

Moving Beacon Register Update OK 200 OK

圖 3.3 Handoff Sequence 當 UA 漫遊到新的位置的時候，會收不到原先 Proxy 發送來 的 beacon，這時候代表它漫遊到另外一個網域底下，所以會先執行 ipconfig /release 的指令，放棄原本所使用的 IP address，再利用 ipconfig /renew 的指令，重新取的 IP address，此時便可以收到新的 Proxy Server 送來的 Beacon，再利用新取的 IP address 向 Proxy Server 做註冊。之 後的流程跟之前討論過的註冊一樣，這裡不再贅述。 3.3.3 呼叫建立 (call setup) 當 UA 想與他人通訊的時候，會發送 Invite 的訊息給 Proxy，要求 Proxy 1 幫忙找到 CN (Correspond Node)，如圖 3.4 所示。 之後 Proxy 1 會向 Location Server 做查詢，Location Server 查到 CN 位於哪一個 Proxy 之後，會回傳 302 Move Temporarily 給 Proxy 1，Proxy 1 在根據回應的訊息找到 CN 目前所在的 Proxy Server，也 就是 Proxy 2，再將 INVITE 訊息轉送給 Proxy 2，最後 Proxy 2 再將 INVITE 訊息轉送給 CN。

14

UA

Proxy 1

Location server

Proxy 2

CN

INVITE INVITE 302 Redirect

Update

INVITE OK 200 OK

INVITE 200 OK

ACK

Voice Data

圖 3.4 call setup sequence CN 會根據 INIVTE 訊息當中所夾帶的 SDP，判斷是否接受 UA 的呼叫，如果接受的話，便會依照原路徑回傳 200 OK 給 UA，UA 最 後在回應 ACK，此時便可以建立資料路徑(Data Path)。 3.3.4 結束通話 通訊的雙方都可以發送 BYE 的訊息，用以告知對方結束通 話。如圖 3.5 所示，對方收到之後回覆 200 OK 便可以終止通話。

15

UA

Proxy 1

Location server

Proxy 2

CN

BYE 200 OK

圖 3.5 call tear down 3.3.5 漫遊 (Roaming) 當 UA 發生漫遊的時候，便需要系統提供 Handoff 機制，除 了更新位置之外，並且讓 UA 重新建立連線。 如圖 3.6 所示，UA 發生漫遊之後，首先會先向目前所處網域中 的 Proxy Server 做註冊，以 3.6 而言的話，UA 便向 Proxy 1 做註冊， 完成之後再向原本通訊的對象發 INVITE 的訊息，CN 收到 INVITE 訊息之後，根據 INVITE 訊息當中的 Call-ID 的欄位，可以判斷是不 是之前所建立的 Session。CN 回應 200 OK 確認 UA 所發送過來的 INVITE，最後 UA 在回覆 ACK，便可以建立語音的通訊。

16

UA

UA

Location server

Proxy 1

Proxy 2

CN

Roaming

Voice Data Register

200 OK

Register 200 OK

INVITE 200 OK ACK

Voice Data

圖 3.6 Roaming

4. 系統實做 4.1 軟體架構 圖 4.1 為我們所設計的軟體架構，分成了數個模組。由於要完成 SIP 所有的 Protocol Stack 並不是件簡單的事情，所以我們在網路上尋 找 Open Source 來幫助我們開發系統。 其 中 藍 色 部 分 是 我 們 主 要 開 發 的 部 分， 綠 色 部 分 透 過 oSIP Library[]、粉紅色部分則是透過 WinRTP Library[]來完成。

17

Application (GUI) Line Manger

Message Parser

SIP UA Logic

Media manger

RTP/ RTCP

SIP Transaction

Codec Audio /Video

Reactor

driver

Transport layer System layer 圖 4.1 軟體架構 各模組的說明如下： Message Parser :此模組是 SIP 的訊息處理模組，負責 Encode 及 Decode SIP 的訊息，把 SIP 訊息分解成一個個有意義的 token。 SIP Transaction : 此 模 組 維 護 著 RFC 3261 中 記 載 之 SIP Transaction 的 State Machine，並藉此 State Machine 控制著整個 Session 建立的流程。 4.2 軟體架構 圖 4.1 為我們所設計的軟體架構，分成了數個模組。由於要完成 SIP 所有的 Protocol Stack 並不是件簡單的事情，所以我們在網路上尋 找 Open Source 來幫助我們開發系統。

18

其 中 藍 色 部 分 是 我 們 主 要 開 發 的 部 分， 綠 色 部 分 透 過 oSIP Library[10]、粉紅色部分則是透過 WinRTP Library[11]來完成。 Line Manage : 此模組主要統合 SIP UA Logic 和 Media Manager 的部分。 Media Manager：此模組主要處理 Session 建立之後，多媒體資料 的傳送、維護、及結束。 Application：此模組提供一個介面讓使用者可以方便的開發程 式。 軟體組件說明 SIP 通訊協定程式庫主要是由 Message Parser、SIP Transaction、 SIP UA Logic 及 Line Manager 四大模組所組成。其中 Message Parser、 SIP Transaction 藉由 oSIP Library 來完成。 4.2.1 Message Parser 模組 SIP Message Parser 主要的功能是提供給 SIP 通訊協定中各個模 組使用，處理 SIP message 的編碼與解碼。在解碼(decode)方面，此模 組負責將文字模式的 SIP message 轉換成系統自定的資料結構。在編 碼(encode)方面，SIP 屬於文字模式(text-based)的通訊協定，使用 UTF-8 的編碼方式，oSIP Library 會負責將系統自定的資料結構組合 成 SIP message。模組的架構如圖 4.2 所示：

19

SIP SIPMessage Message

Request -Request Line Line

SIP -URL SIP -URL

Status -Status Line Line

From From Header Header

To To Header Header

Via Via …… Header Header

SIP -URL SIP -URL

SIP -URL SIP -URL

Session Session Time Time Info. Info. Info. Info.

SDP SDP

Media Media Info. Info.

圖： 4.2 SIP Message Parser module 此架構分為三層，第二層為 SIP message 包含的 start-line、 header 與 SDP 子模組，第三層為第二層子模組中更細部劃分的子模 組，包含 SIP header 使用的 SIP-URL 與 SDP 包含的 Session Info., Time Info., Media Info.，三階層中每個子模組皆包含下列幾項功能： Initial：將子模組資料結構中的資料初始化，包含配置記憶體等。 Free：釋放資料結構中資料的記憶體。 Clear：清除資料結構中資料的值。 Encode：依照 message 的訊息傳送模式，將資料結構中的資料組 合為有意義的 SIP message。 Decode：將文字模式的 SIP message 轉換成資料結構中的資料， 並檢查資料型態的正確性 20

Copy：拷貝兩個資料結構中的資料 Compare：比較兩個資料結構中的資料 Get：取得子模組中每個項目的資料內容 Set：設定子模組中每個項目的資料內容 4.2.2 Transaction 模組 SIP 是以 transaction 為基礎的協定，任何 SIP 元件的溝通都會有 一系列的訊息交換。SIP 的 transaction 由一個請求訊息和任意數量的 回應訊息（零個或多個暫時回應和一個最終回應）組成。oSIP Library 提供相當簡單的介面給 transaction 的使用者（TU）。使其能利用 transaction 來架構出各種 SIP application。transaction 所提供的介面大 致有（如圖所示）： SIP Transaction A P I T ransaction init and stop

T ransaction tim eo ut

Transaction Error

Create transaction Sen d m essage to transaction

Transaction receive m essag e G et transaction info

SIP Transaction Transport Layer

圖 4.3 SIP transaction module

21

Call function: Transaction init and stop、Create transaction、Send message to transaction、Get transaction info。 Call back function: Transaction timeout 、 Transaction error 、 Transaction receive message。 4.2.3 SIP UA Logic 模組 一個所謂的 SIP user agent 是一個用來創造一個新的 SIP Request 並且使用 Client Transaction State Machine 來傳送的邏輯上的元件。另 一方面 SIP user agent 也是用來對 SIP Request 產生回應並使用 Server Transaction State Machine 來傳送的邏輯元件。而 SIP user agent 可分 為：SIP User Agent Client，SIP User Agent Server，SIP Registration Client 其中 SIP UA Logic 與其他模組間的互相合作關係如圖所示。

Call back

Command from

Application user

application user

Call Model Dispatcher

Call Model FSM User agent logic

Transaction layer Timer

Call back from transaction layer

圖 4.4 SIP UA Logic 合作關係

22

Send message

4.2.4 Line Manager 模組 Line Manager 是一個模擬電話行為的 API 集合，程式設計師可以 利用這樣的 API 來寫出 softphone 等應用程式。Line Manage 主要是用 來統合 SIP UA Logic 以及 Media Manager 的部分，而其中主要的功 能分為 Call back functions、Hook off/on 功能、Dial SIP call 功能、 Register/Unregister SIP UA 功能、Proxy 設定、以及 Registrar 設定。 4.3.5 Media Manager 模組 Media Manager 模組，主要是管理 WinRTP Library 所提供的 Function，藉此提供 VoIP 的服務。 WinRTP 是 Cisco IP SoftPhone 產品的一部份，利用 C++來編寫， 並且是一個 COM 的元件，程式設計師可以輕易的使用任何語言來撰 寫。 它有一下幾項特點： 支援多樣性的語音設備: 使用者可以使用在機器上的任何一種 語音設備，甚至是 USB 的麥克風等等。 Codec 支援: G.711 64kbps (both ALaw and ULaw)，至於 G.723 and G.729 礙於版權的關係，使用者必須自行開發。 支援語音混音: 可以將收進來的聲音跟 Wave 檔案作混音。 音量控制: WINRTP 支援音量設定，包括麥克風及喇叭的音量。 Silence Suppression: WINRTP 支援 silence suppression (Voice Activity Detection - VAD)的語音串流。 23

QoS 支援: WINRTP 支援 DiffServ。 RTP Implementation：編碼及解碼 RTP 訊息。 Jitter 的緩衝大小: 提供動態設定。

5. 結論 傳統架構在有線網路上的 VOIP 並沒有支援行動能力，不過這樣 帶來的好處是高傳輸速率，低錯誤率，繞送封包的延遲較短，相對的 語音的品質也比較好；而在行動環境下的電話系統，傳輸資料的錯誤 率較高、頻寬比較小且受繞送封包的影響，就會比傳統 VOIP 多了一 段轉送及交接上的延遲，所以語音品質比不上在有線網路上傳送的情 況，不過由於在行動性上佔有絕對的優勢，MVOIP 得以有較好的服 務延伸性，所以 MVOIP 一定是未來發展的趨勢。 未來還有一些地方可以再做改善的地方，包括 一、 效能的改善 Mobile Host 在做漫遊的時候，通訊必須中斷而後再透過 Re-Invite 的方式建立連線，對於 Real-Time 的 Application 而言， 是一段相當漫長的時間。所以讓 MH 在漫遊的時候，可以及早建 立連線是將是往後努力的方向，例如：透過 Media Relay 的方式 是不錯的選擇。 二、 語音與資料同時處理。 目前系統的應用是以傳遞語音資料為主，將來可以在再加入 傳遞檔案資料的功能，使得功能更加完備。 24

三、 加解密功能 在網路上傳遞語音訊息時，封包容易被擷取，造成安全性的 一大漏洞，所以系統可以再加入加解密的功能，提高系統的安全 性。 四、 功能的改善 未來可以再整合 PSTN 以及 GSM 的網路，讓使用者可以在各 個通訊網路上進行 MVoIP 的服務。此外還可以提供語音信箱、 多方通話等等的功能。 五、 Voice Codec 增加 目前系統只有 G.711 alaw 及 ulaw 可供選擇，在 WLAN 頻寬 較小的情況下，如果可以將語音資料壓縮的更小的話，那通話品 質將可以提升，例如利用 G.729 來進行語音編碼等等。

相關研究 [1]

Princy

Mehta

and

Sanjay

Udani;”Voice

over

IP”,IEEE

POTENTIALS,October/November 2001 [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, “SIP: session initiation protocol,” Request for Comments (Proposed Standard) 2543, Internet Engineering Task Force, Mar. 1999. [3] J. Rosenberg, H. Schulzrinne, G. Camarillo “SIP: Session Initiation Protocol,” Request for Comments: 3261, Internet Engineering Task Force, June 2002

25

[4] J. Rosenberg, H. Schulzrinne “Reliability of Provisional Responses in the Session Initiation Protocol (SIP)” Request for Comments: 3262, Internet Engineering Task Force, June 2002 [5] J. Rosenberg, H. Schulzrinne “Session Initiation Protocol (SIP): Locating SIP Servers” Request for Comments: 3263, Internet Engineering Task Force, June 2002 [6] J. Rosenberg, H. Schulzrinne “An Offer/Answer Model with the Session Description Protocol (SDP)” Request for Comments: 3264, Internet Engineering Task Force, June 2002 [7]

J.

Rosenberg,

H.

Schulzrinne

“Session

Initiation

Protocol

(SIP)-Specific Event Notification” Request for Comments: 3265, Internet Engineering Task Force, June 2002 [8] R. Fielding, J. Gettys, J. Mogul “Hypertext Transfer Protocol -HTTP/1.1” Request for Comments: 2068, Internet Engineering Task Force, 1999 [9] M. Handley, V. Jacobson, “SDP: Session Description Protocol” Request for Comments: 2327, Internet Engineering Task Force, April 1998 [10] http://www.gnu.org/software/osip/ [11] http://www.vovida.org/applications/index.html

26