1

1. 序論 ..................................................................................................2

2. 相關研究 ..........................................................................................2

2.1 SIP (Session Initiation Protocol) 簡介 .................................................2 2.2 SIP命名方式 .........................................................................................3 2.3 SIP 元件介紹 ........................................................................................4 2.4 SIP message ...........................................................................................5 2.5 SDP........................................................................................................7 2.6 SIP運作模式 .........................................................................................8

3. 系統設計 ........................................................................................ 11

3.1 系統設計考量 ......................................................................................11 3.2 系統架構 ..............................................................................................12 3.3 系統運作流程 ......................................................................................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 軟體架構 ..............................................................................................17 4.2 軟體架構 ..............................................................................................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

2

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 開放標準的精神延伸至通訊領域，實現了不同

3

電腦、電話、及軟體的通訊。SIP的訊息類似於 HTTP (RFC 2068[8])，

其定址方式，則是重用了 SMTP 的定址方式，SIP address (如：

sip:inaba@ssl.es.ncku.edu.tw)與 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:inaba@ssl.es.ncku.edu.tw 或 是

sip:25643588@140.92.61.55

4

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或其他資料庫當中的資訊。

5

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 類

6

別，Final則包括了 2xx，3xx，4xx，5xx，6xx等類別，表 2.2表示各

個不同類別的 Response。

方法 說明 1xx Informational

2xx Successful 3xx Redirection

4xx Client-Error 5xx Server-Error 6xx 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

7

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的資訊包含了

8

ü media的種類，

ü port number、

ü 傳輸協定以及 media的格式。

圖 2.1為 SDP的結構。

圖 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便可

Session Description Session Level

Protocol Version Originator and

Session ID Session Name Session Time

Media Description

Media Name and Transport

Connection Information

9

以結束目前進行會議。

圖 2.2 SIP call flow

2.5.1 SIP proxy 模式

以圖 2.3為例，caller (inaba@work.com) 先送出一個 INVITE訊

息呼叫 callee (yucho@work.com)，proxy server收到之後便會去做查

詢 ， 查 詢 完 成 之 後 便 得 知 目 前 callee 實 際 的 位 址 在

yucho@home.com，於是 proxy server便會以 yucho@home.com為對象

發出 INVITE 訊息。callee 在回覆 200 OK的時候，會將 200 OK的

response回應給 proxy server，再由 proxy server轉送給 caller。

INVITE

200: OK

ACK

Client (Caller) Server (Callee)

180: Ringing

100: Trying

RTP

BYE

200: OK

10

圖 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。

圖 2.4 SIP redirect mode

Redirect Server

3. INVITE yucho@home.com

yucho@home.com

inaba@work.com 1. INVITE yucho@work.com

4. Response

2. Move temporally contact : yucho@home.com

SIP Proxy

3. Response

yucho@home.com

inaba@work.com

1. INVITE yucho@home.com

2. INVITE yucho@work.com

4. Response

11

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 的服務，並且在使用者漫遊的時候，系統會自動建立連線並且

繼續之前的通話。

圖 3.1 System Architecture

SIP Proxy 1 Internet

WLAN

SIP UA SIP UA

SIP UA

Ethernet

SIP Proxy 2

Ethernet

WLAN

SIP UA

Location Server

12

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註冊

圖 3.2 Registration Sequence

UA Proxy Location server

Register Update

OK 200 OK

Beacon

13

圖 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所示

14

圖 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。

UA Proxy Location server

Register Update

OK 200 OK

Beacon

UA

Moving

15

圖 3.4 call setup sequence

CN 會根據 INIVTE 訊息當中所夾帶的 SDP，判斷是否接受 UA

的呼叫，如果接受的話，便會依照原路徑回傳 200 OK給 UA，UA最

後在回應 ACK，此時便可以建立資料路徑(Data Path)。

3.3.4 結束通話

通訊的雙方都可以發送 BYE 的訊息，用以告知對方結束通

話。如圖 3.5所示，對方收到之後回覆 200 OK便可以終止通話。

UA Proxy 1 Location server

INVITE

Update

OK

200 OK

302 Redirect

ACK

CN Proxy 2

INVITE

200 OK

INVITE

INVITE

Voice Data

16

圖 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，便可以建立語音的通訊。

UA Proxy 1 Location server

200 OK

CN Proxy 2

BYE

17

圖 3.6 Roaming 4. 系統實做

4.1 軟體架構

圖 4.1 為我們所設計的軟體架構，分成了數個模組。由於要完成

SIP所有的 Protocol Stack並不是件簡單的事情，所以我們在網路上尋

找 Open Source來幫助我們開發系統。

其中藍色部分是我們主要開發的部分，綠色部分透過 oSIP

Library[]、粉紅色部分則是透過WinRTP Library[]來完成。

UA Proxy 1 Location server

Register

INVITE

CN

200 OK

Roaming

200 OK

UA

Register

200 OK

Proxy 2

Voice Data

Voice Data

ACK

18

圖 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來幫助我們開發系統。

System layer Transport layer

Reactor

SIP Transaction

Message

Parser

SIP UA Logic

Line Manger

Application (GUI)

RTP/ RTCP

Media manger

Codec

Audio /Video driver

19

其中藍色部分是我們主要開發的部分，綠色部分透過 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所示：

20

圖： 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轉換成資料結構中的資料，

並檢查資料型態的正確性

SIP Message SIP Message

Request - Line

Request - Line

Status - Line

Status - Line

From Header From

Header To

Header To

Header Via

Header Via

Header SDP SDP ……

Media Info.

Media Info.

Time Info.

Time Info.

Session Info.

Session Info. SIP - URL SIP - URL SIP - URL SIP - URL SIP - URL SIP - URL

21

Copy：拷貝兩個資料結構中的資料

Compare：比較兩個資料結構中的資料

Get：取得子模組中每個項目的資料內容

Set：設定子模組中每個項目的資料內容

4.2.2 Transaction模組

SIP是以 transaction為基礎的協定，任何 SIP元件的溝通都會有

一系列的訊息交換。SIP的 transaction由一個請求訊息和任意數量的

回應訊息（零個或多個暫時回應和一個最終回應）組成。oSIP Library

提供相當簡單的介面給 transaction 的使用者（TU）。使其能利用

transaction來架構出各種 SIP application。transaction所提供的介面大

致有（如圖所示）：

圖 4.3 SIP transaction module

Transport Layer

SIP Transaction

SIP Transaction APITransaction init and stop

Transaction receive message

Transaction timeout

Transaction ErrorCreate transaction

Send message to transaction

Get transaction info

22

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 與其他模組間的互相合作關係如圖所示。

圖 4.4 SIP UA Logic合作關係

Call Model Dispatcher Call Model FSM

Transaction layer

User agent logic

Application user

Timer Call back from

transaction layer

Command from

application user

Send message

Call back

23

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)的語音串流。

24

QoS 支援: WINRTP支援 DiffServ。

RTP Implementation：編碼及解碼 RTP訊息。

Jitter的緩衝大小: 提供動態設定。

5. 結論

傳統架構在有線網路上的 VOIP 並沒有支援行動能力，不過這樣

帶來的好處是高傳輸速率，低錯誤率，繞送封包的延遲較短，相對的

語音的品質也比較好；而在行動環境下的電話系統，傳輸資料的錯誤

率較高、頻寬比較小且受繞送封包的影響，就會比傳統 VOIP多了一

段轉送及交接上的延遲，所以語音品質比不上在有線網路上傳送的情

況，不過由於在行動性上佔有絕對的優勢，MVOIP 得以有較好的服

務延伸性，所以MVOIP一定是未來發展的趨勢。

未來還有一些地方可以再做改善的地方，包括

一、 效能的改善

Mobile Host 在做漫遊的時候，通訊必須中斷而後再透過

Re-Invite的方式建立連線，對於 Real-Time的 Application而言，

是一段相當漫長的時間。所以讓MH在漫遊的時候，可以及早建

立連線是將是往後努力的方向，例如：透過Media Relay的方式

是不錯的選擇。

二、 語音與資料同時處理。

目前系統的應用是以傳遞語音資料為主，將來可以在再加入

傳遞檔案資料的功能，使得功能更加完備。

25

三、 加解密功能

在網路上傳遞語音訊息時，封包容易被擷取，造成安全性的

一大漏洞，所以系統可以再加入加解密的功能，提高系統的安全

性。

四、 功能的改善

未來可以再整合 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

26

[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