中 華 大 學

~ 1 ~ 

中 華 大 學 碩 士 論 文

題目：連線服務自由移轉、分流與整合機制 設計

系 所 別：資訊工程學系碩士班 學號姓名：M09402046 王阜毓 指導教授：陳旻秀 博士

中華民國九十六年八月

~ 2 ~ 

論文摘要

Session Initiation Protocol(SIP)被廣泛地被應用於網際網路電信領域中，同時 也被採用為 VoIP 與 3GPP 的信號通訊協定，因此 SIP 的發展成為網際網路電信 領域中備受矚目的研究議題。SIP 的研究可分為四大方向，分別是 terminal mobility、personal mobility、service mobility 與 session mobility。本論文將針對 session mobility 這個議題提出如何利用 SIP 讓使用者能在進行通話的過程中，自 由的變換通話設備或將視訊串流隨意分流或取回的使用機制。我們將 SIP 所定義 的 User Agent(UA)擴充為 Session Manager、Session User 與 Free Node 三種不同 的角色。依據這些角色所提供的能力，提出一套完整的機制，以解決收回整合的 問題。最後我們採用具有開放原始碼的軟體電話來進行實做，並驗證這套機制的 可行性。

~ 3 ~ 

誌謝

感謝實驗室的同學英鼎、學弟則勤，在我撰寫這篇論文的時候提供我許多援 助；感謝女友蓓琳在我積弱不振的時候適時的鼓勵我；感謝父母的關愛讓我能無 後顧之憂的全心投入論文的撰寫；感謝陳旻秀老師的諄諄教誨，在我遇上研究瓶 頸時提供我許多意見，並不厭其煩的再三協助我校稿，使得這篇論文能夠順利問 世。另外誠摯的感謝兩位口試委員劉懷仁教授與嚴力行在百忙中撥空蒞臨指導，

並給予論文的指正與建議，使這篇論文能更完善。

有你們的協助讓我在研究所期間成長茁壯，謝謝你們。

王阜毓 謹致 中華民國九十六年八月與新竹

~ 4 ~ 

目錄

第 1 章 序論... 8 

1.1  動機 ... 8 

1.2  論文架構 ... 10 

第 2 章 SESSION INITIATION PROTOCOL ... 11 

2.1  SESSION INITIATION PROTOCOL ... 11 

2.2  SIP MOBILITY ISSUE ... 14 

2.3  SESSION MOBILITY ... 15 

2.4  Nested REFER ... 18 

第 3 章 系統架構... 20 

3.1  連線服務收回與整合 ... 20 

3.2  Session Manager, Session User and Free Node ... 20 

3.3  安全性考量 ... 25 

第 4 章 系統實作與實驗... 27 

4.1  系統實作 ... 27 

4.2  實驗 ... 29 

第 5 章 結論與未來工作... 38 

參考文獻... 39 

~ 5 ~ 

圖片目錄

圖 2-1 SIP 訊息語法 ... 12 

圖 2-2 跨網域的 SIP 訊息傳送方式 ... 14 

圖 2-3 利用 REFER 方式進行連線服務移轉 ... 16 

圖 2-4 利用 3PCC 方式進行連線服務移轉 ... 16 

圖 2-5 Shacham 所提出的分流機制 ... 18 

圖 2-6 Nested REFER 執行流程 ... 19 

圖 3-1 使用 Nested REFER 回收連線服務 ... 21 

圖 3-2 部份連線服務示意圖 ... 21 

圖 3-3 (SMR) 要求 session manager 權限 ... 24 

圖 3-4 (SMR)Session manager 處理行為 ... 24 

圖 3-5 (SMT)Session manager handling behavior ... 24 

圖 3-6 (SMT)Session user/free node handling behavior ... 24 

圖 3-7 User agent 身份轉換 ... 25 

圖 4-1 SIP-Communicator 的軟體組成 ... 28 

圖 4-2 client 送出 Nested REFER 流程 ... 28 

圖 4-3 Server 處理 Nested REFER 流程 ... 29 

圖 4-4 User anger 身分轉換時 sip-communicator 變動 ... 29 

圖 4-5 SIP-Communicator 軟體畫面 ... 30 

圖 4-6 情境一：移轉並取回全部連線服務 ... 31 

圖 4-7 移轉全部連線服務再回收的封包流量 ... 31 

圖 4-8 情境二：移轉並取回視訊連線服務 ... 32 

圖 4-9 移轉視訊連線服務再回收的封包流量 ... 32 

圖 4-10 情境三：對方進行分流後再分流並取回連線服務 ... 33 

~ 6 ~ 

圖 4-11 對方進行分流後再分流並取回連線服務的封包流量 ... 34 

圖 4-12 透過 SMR 與 SMT 取回連線服務... 35 

圖 4-13 情境 4 電腦 A1 上所錄得的封包流量圖 ... 36 

圖 4-14 情境 4 電腦 B1 上所錄得的封包流量圖... 37 

~ 7 ~ 

表格目錄

表 2-1 SIP 相關 RFC 文件 ... 12  表 2-2 RFC 3261 規範的六種基本 method ... 12  表 2-3 RFC 3261 規範的六類 status code ... 13 

~ 8 ~ 

第1章  序論

1.1

動機

隨著網路頻寬的快速增加，許多網路應用服務也漸漸被開發出來，從早期網 頁瀏覽的 WWW 與 HTTP、資料交換的 FTP，到現在正熱門的即時通訊(IM)如 MSN、QQ、AOL 等，我們可以發現網路與日常生活早已緊密結合在一起。以即 時通訊為例，過去即時通訊服務必須透過電信網路來進行，人們透過手機或有線 電話撥打朋友的電話號碼來聯絡感情，並按照通話的時間長短繳交費用給電信供 應商，而通話時間與距離越長所需繳交的費用也越多。

有鑑於跨國通信費用的昂貴與網際網路的普及應用，研究人員便開始研究如 何透過價格較低網際網路進行遠距離對話的方法。其研究成果就是我們今天所看 到的 Voice over Internet Protocol(VoIP)，原理是將語音轉換成資料串流(stream) 後，透過網路送至收話端，收話端收到語音資料串流後，再轉換成語音撥放出來，

利用這樣的方式，使得收話端可以聽到發話端所說的話。資料串流的應用還不僅 如此，舉凡目前網路上的網路電視，線上音樂，都是利用資料串流的原理發展出 來。然而，隨著資料串流服務的普及使用，如何讓使用者更方便的控制資料串流 服務，成了重要的課題，Session Initiation Protocol(SIP)因此而誕生。

SIP 是一種用於連線服務管理的通訊協定，可以建立、終止、修改連線服務。

透過 SIP 的協助，使用者可以選擇連線的對象，然後發出控制訊息要求與對方建 立連線服務，或在已經不需要使用到該連線的時候發出控制訊息與對方中斷連線 服務。根據 SIP 的應用範圍可以分為四大方向，分別是 terminal mobility、personal mobility、service mobility 與 session mobility。

terminal mobility 利用 SIP 基礎架構使終端機可任意切換網路，目的與功能 相似於 Mobile IP，並解決了 Mobile IP 的 triangle routing 的問題。service mobility

~ 9 ~ 

讓使用者的服務設定與 SIP 帳號結合，只要登入 SIP 帳號即可取得服務的設定，

免除設定的繁瑣程序。Personal mobility 則架構出一個 SIP URI 間對應的環境，

讓 SIP 使用者可以將不同的 SIP URI 提供給不同的對象族群，將每個 SIP URI 的 用途作明確的區分。session mobility 討則論如何讓連線服務在兩個 user agent 任 意移轉的問題。

在這四大方向中又以 session mobility 最引人注目，其原因在於單純的建立與 終止連線早已經不符合使用者的需求，使用者需要能對連線服務做更進一步的控 制，如連線服務自由移轉。比方說，一般行動裝置受限與體積較小的限制，必須 縮小螢幕及降低攝影機的解析度，當使用者在戶外時，沒有其他選擇只能利用行 動裝置與其他人溝通。然而當使用者回到家中，有高階的視訊及音訊產品可用 時，使用者可能會想改用這些設備來獲得更好的通訊品質。以前的作法必須中斷 原本在行動裝置上通訊的連線服務，再利用家中裝置重新與對方建立連線服務進 行通訊，這樣的過程不僅麻煩且相當的不方便。因此有人提出了連線服務移轉的 想法，將連線服務直接移轉到另一個裝置上，省去了瑣碎的連線服務重新建立程 序。

然而，連線服務移轉機制的出現，只滿足了部分使用者的需求。因為這樣的 機制只提供將連線服務全部的移轉。倘若使用者同時使用視訊與音訊裝置進行通 訊，則同一個連線服務中會包含視訊及音訊的兩個連線存在，若家中只有視訊裝 置時，連線移轉機制會在音訊的連線上出現問題。為解決連線設備支援功能無法 滿足連線服務移轉的問題，分流機制被提出了，分流機制可以將連線服務分流到 各個不同的裝置上，也可以只將一部份的連線服務分流出去，解決了移轉機制的 不足。只是這套的機制在連線服務收回並整合上有著相當複雜的問題，使得使用 者仍然無法方便且自由的在各個裝置間移轉連線服務。因此本論文的主要貢獻，

即是提出一套完善的機制來支援連線服務的自由移轉、分流與整合的需求。

~ 10 ~  1.2

論文架構

本篇論文將在第二章對 SIP 通訊協定及四種 SIP 移動管理議題作更進一步的 介紹。並在第三章說明我們如何利用 session manager，session user 與 free node 三種角色建構出自由移轉、分流與整合連線服務的環境。並在第四章展示我們採 用具有開放原始碼的軟體電話來進行實做的成果，驗證這套機制的可行性。最後 以第五章作總結並討論未來目標。

~ 11 ~ 

第2章  SESSION INITIATION PROTOCOL 

2.1 SESSION INITIATION PROTOCOL

Session initiation protocol(SIP)是一種使用於連線服務管理的通訊協定，由哥 倫比亞大學計算機系 Henning Schulzrinne 教授及其研究小組於西元 1996 年向 IETF 提交草案，並於西元 2001 年正式發佈 SIP 規範 RFC 32610，其後更為了加 強安全性與身份驗證等領域的內容而發佈了數份 RFC 如表 2-1。

SIP 利用 SIP URI 賦予每個 SIP 帳號獨一無二的位址來達到終端連線的目 的，SIP URI 的格式類似 E-mail address，其格式為 sip:user account@host，例如 sip：Bob@sip.csie.chu.edu.tw。在 0 的定義中網路用於 SIP 服務的設備依其功能 分類可分為四種角色，分別是 Proxy server、Redirect server、Registrar server 及 User agent 透過這些設備可以傳達 SIP message 來達到連線服務管理的目的。每一 個 User agent 擁有一個 SIP URI，並負責使用者端的 SIP message 發送與接收。

Registrar server 負責管理並維護 SIP URI 資料，User agent 必須隨時向 Registrar server 更新 SIP URI 所對應的 IP 位址資訊，讓其他 User agent 可以透過 SIP URI 來找到受話方。Proxy server 負責轉送 SIP 訊息，當不知道受話方 IP 位址時，User agent 會先將 SIP 訊息傳送給 Proxy server，再由 Proxy server 向 Registrar server 查詢受話方 IP 位址後轉送給受話方。Redirect server 紀錄各地 Proxy server 的資 訊，使得 SIP 可以進行跨網域的訊息交換。

SIP 訊息包含三大部份，分別是 start-line、message-header 與 message-body。

Start-line 根據訊息是 request 或 response 而有所不同，當訊息為 request 時，start-line 會包含 method 用以說明這個 request 的目的，0 規範了六種 method 如表 2-2。而 訊息為 response 時 start-line 則包含 status code，以回報 request 的執行狀況，Status code 也分為六大類如表 2-3。

message header 類似 http1.1 的 header，提供更多資訊描述 start-line 的內容，

~ 12 ~ 

共分為 general header、request header、response header 與 entity header 四類。

message body 則為訊息內容，通常會將建立連線服務所需的資源內容採用[2]所定 之格式 message body 中。

表 2-1 SIP 相關 RFC 文件

RFC 文件編號 說明

RFC3261

SIP 的基礎

RFC3262

管理應答關係

RFC3263

建立 SIP Proxy 的規則

RFC3264

提供具體的 offer/answer 模型

RFC3265

具體的事件表示

圖 2-1 SIP 訊息語法

當使用者想利用 SIP 建立連線服務時，user agent 會產生一個的訊息，訊息 中包含了要建立連線服務對象的 SIP URI，以及建立連線服務所需的各種資訊，

並將訊息交給 proxy server 來轉送。proxy server 根據 user agent 所提供的目的端 SIP URI 位址來進行轉送，因為 proxy server 上並沒有 SIP URI 與 IP 位址的對應 資訊，所以在轉送之前，proxy server 必須先向 registrar server 查詢 SIP URI 的對 應 IP 位址。

表 2-2 RFC 3261 規範的六種基本 method

~ 13 ~ 

Method 說明

REGISTER

向 SIP server 註冊使用者資訊

INVITE

建立連線服務

ACK

CANCEL

BYE

中斷連線服務

OPTIONS

查詢 SIP Server 相關資訊

表 2-3 RFC 3261 規範的六類 status code Status code 說明

1XX

訊息 (100 Trying, 180 Ringing )

2XX

成功 (200 OK, 202 Accepted)

3XX

重新導向 (302 Moved Temporarily)

4XX

Request 錯誤 (404 Not Found, 482 Loop Detected)

5XX

Server 錯誤 (501 Not Implemented)

6XX

全域錯誤 (603 Decline)

當轉送的目的端在同一網域內時，向網域內的 Registrar server 查詢目的端 SIP URI 對應的 IP 位址後直接轉送給目的端的 user agent。反之因目的端不在同 一網域內，向 Redirect server 查詢對應於目的端網域的 proxy server 位址，並將訊 息傳送給該台 proxy server。而目的端網域的 proxy server 收到訊息後再向 registrar server 查詢目的端的 IP 位址後傳送。圖 2-2 為兩個 User agent 傳送訊息的過程。

~ 14 ~ 

Domain A SIP Proxy Server Domain A SIP Registrar Server

Domain B SIP Proxy Server Domain B SIP Registrar Server

User Agent Client User Agent Server

SIP Redirect Server

2 3

4 9 10

1 8 7

6 5

RTP

Domain A Domain B

Request Response

圖 2-2 跨網域的 SIP 訊息傳送方式

2.2 SIP MOBILITY ISSUE

移動管理是網路研究的一大熱門議題，目前在 IP 移動管理上已有相當豐碩 的研究成果(Mobile IP)。在 0 也中指出 SIP 可以支援四類的移動管理，分別是 terminal mobility、session mobility、service mobility 與 personal mobility。

Terminal mobility 是利用先前所提到的 SIP 基礎架構使終端機可任意切換網 路，目的與功能相似於 Mobile IP，Mobile IP 在 home domain 架設一台 home agent，若移動裝置在 home domain 內，封包由移動裝置自己接收，當移動裝置 離開 home domain 移動到其他 domain 時，便由 home agent 代為接收移動裝置的 封包並 tunnel 到移動裝置所在的位址，這樣的好處移動裝置可以在各個不同的 subnet 利用相同的 IP 上網，但是因為要透過 home agent 轉送，所以造成了 triangle route 的問題。而 terminal mobility 則是採用 SIP URI 來表示使用者所在位置，當 使用者的移動裝置具備上網能力時，SIP user agent 會向 registrar server 進行註 冊，使得使用者所用的 IP 位址資訊能與 SIP URI 產生關聯，當其他人要找尋該

~ 15 ~ 

名使用者就能透過這個 SIP URI 位址向 registrar server 查尋目前該名使用者所使 用的 IP 位址，並直接與其建立連線，避免 triangle route 問題的發生。

Service mobility 討論如何讓使用者的服務設定與 SIP 帳號結合，大部分的使 用者在使用網路服務時，都會設定個人的偏好設定，然而這些偏好設定只能保存 在使用者所設定的那台電腦上。如果要讓偏好設定能夠在其他裝置上使用，必須 將設定儲存在隨身碟中四處攜帶，並在達到新環境時將偏好設定複製到所使用的 新電腦上。這樣的方法不僅步驟麻煩，若不慎遺失了隨身碟更有可能造成所有設 定全部遺失的可能。為此 SIP 提供較好的解決方案，將使用者的偏好設定與 SIP URI 儲存在一起。讓使用者不管到了哪台電腦只要登入 SIP 帳號即可取得偏好設 定，免除設定的繁瑣程序。

Personal mobility 則架構出一個帳號間對應的環境，在人際關係複雜的現代 生活中，使用者可能會想將不同的 SIP URI 提供給不同的對象族群，將每個 SIP URI 的用途作明確的區分。只是在區隔 SIP URI 用途的同時，也造成自己管理 SIP URI 的不便，因此 SIP 提供了 personal mobility 使得 SIP URI 可以產生一對多 或多對一的關係，提高使用與管理的便利性。

2.3 SESSION MOBILITY

Session mobility 討論如何讓連線服務在兩個 user agent 任意移轉的問題，在 RFC 3515[3]與 RFC 3725[4]中定義了兩種連線服務移轉的方式分別稱為 REFER 與 Third-party call control(3PCC)，其連線服務移轉方式分別如圖 2-3 與圖 2-4。

REFER 利用[3]所制定的 REFER method 來進行連線服務移轉。當中的 MN1 想要 將連線服務移轉至 MN2 時，MN1 會對 MN2 發送一個 REFER 訊息，請 MN2 發 送一個 INVITE 給 CN，在 CN 接收到 INVITE 後，便將原本與 MN1 進行的連線 服務終止，轉而與 MN2 建立連線服務。透過這樣的方式，來達到連線服務的移 轉。

若使用 3PCC 的連線服務移轉方式，MN1 則必須扮演 control 的角色。一開

~ 16 ~ 

始由 MN1 向 MN2 發出 INVITE，MN2 接受後回傳 SDP，MN1 再將 MN2 的 SDP 填入 INVITE 訊息發送給 CN，CN 也在接受後回傳 SDP 給 MN1，MN1 以 OK 的形式回送給 MN2，使得 CN 與 MN2 都有對方的 SDP 資訊，透過這樣的方式 來建立 CN 與 MN2 的連線服務以取代 CN 與 MN1 的連線服務。

1 3

2

Old RTP Session

New RTP Session REFER

INVITE

BYE

圖 2-3 利用 REFER 方式進行連線服務移轉

New RTP Session

Old RTP

Session

1 ^INVITE 2 ₂₀₀ ^{OK SD}

P

3 4

5

6

INVITE 200 O

K SDP

ACK SDP from 4 ACK

圖 2-4 利用 3PCC 方式進行連線服務移轉

REFER 與 3PCC 的連線服務移轉方式提供了使用者更便利的操作，但是若 要將連線服務分流到多個 user agent，RFC 規範中還沒有相關的解決方案。因此

~ 17 ~ 

國立中正大學的黃仁竑教授針對這個問題進行研究，並提出完善的 Session 分流 機制[5]。其主要貢獻在於原始的 REFER 機制在進行移轉連線服務時，並沒有相 關資訊指出要將連線服務分流，使得連線服務只能全部移轉，而[5]所提出的分 流機制將原始的 REFER 機制加上了一個 Mobility header 指出要移轉的是連線服 務中的哪部分，進而達到分流的目的。Mobility header 的定義如下：

Syntax:

Mobility = “Mobility” HCOLON callid * (SEMI mobility-param)

mobility-param = mobility-media / generic-param

mobility-media = “media” EQUAL token

使用這套機制可以使連線服務自由的被分流，但是卻存在分流出去的連線服 務卻無法收回的問題，造成使用者必須到每一個被分流的裝置上去終止連線服務 的不便。

R. Shacham 等學者也針對連線服務的分流與整合作過相關的研究[6][7]。將 REFER 與 3PCC 的方式合併使用，把所有接受分流的裝置組成一個虛擬裝置，

並選出一個裝置作為虛擬裝置的代表裝置，以圖 2-5 為例，audio_dev 與 video_dev 組成了虛擬裝置，並選擇 audio_dev 作為代表裝置。

當 MN 想要將連線服務分流到 audio_dev 與 video_dev 上，會送出一個 REFER 訊息給 audio_dev，audio_dev 在收到 REFER 訊息後會發出 INVITE 向 video_dev 索取視訊 SDP，取得視訊 SDP 後，audio_dev 將視訊與音訊 SDP 填入 INVITE 傳 給 CN，要求取代原本 MN 的連線服務。在這套的機制中，不需要對 REFER 作 任何的更動，但是分流過程中所需的訊息數量龐大，造成網路與主機負荷提高，

更因為所有接受分流的裝置都要預先組成虛擬裝置而在實用性上更會大打折 扣，因此我們將提出一個全新的機制，來解決這樣的缺陷。

~ 18 ~ 

圖 2-5 Shacham 所提出的分流機制

2.4 Nested REFER

Nested REFER 為 RFC 3892[8]所規範，當兩台裝置無法直接進行溝通時，可 以使用 Nested REFER 透過中間的裝置來轉達 REFER 訊息，完成連線服務移轉 的功能。原始 REFER 訊息的 Refer-To 欄位應該填入要 REFER 的對象的 SIP URI，

而 Nested REFER 將 Refer-To 欄位的內容作修正，以下為 Refer-To 內容的例子：

Refer-To:<sip:C.example;method=REFER?Refer-To="<sip:D>.example">

上面的 Refer-To 欄位說明了要向 C 發送一個 REFER 訊息，REFER 對象為 D，執行流程如圖 2-6。A 發送一個 Nested REFER 給 B，B 收到 Nested REFER 後會從 Refer-To 欄位得知 A 要求 B 發送一個 REFER 訊息給 C，並將要發送給 C 的 REFER 訊息中 Refer-To 欄位填寫為 D 的 SIP URI。當 C 收到這由 B 發出的 REFER 訊息後，便開始一般的 REFER 流程，將 A 與 D 正在進行的連線服務移 轉。

~ 19 ~ 

圖 2-6 Nested REFER 執行流程

~ 20 ~ 

第3章  系統架構 

3.1

連線服務收回與整合

比較[5]與[6]所提出的連線服務移轉分流機制，雖然[6]的機制較為完善，但 是需要浪費比較多的訊息數量才能達到分流的目的，且接受分流的裝置必須要事 先組成虛擬裝置，這使得自由移轉的美意蒙上了一層陰影。反之[5]所提出的機 制雖然無法收回與控制被分流出去的連線服務，卻擁有較高的分流自由度與較低 的網路負載的優勢。因此我們利用 Nested REFER 與 session manger 的概念將[5]

所提出的設計加以延伸，更進一步的建構出可將連線服務自由移轉、分流與整合 的環境。

原本的 Nested REFER 是希望 A 即使在無法直接與 D 傳送訊息的情況下，也 能進行 REFER，但是我們稍加應用將 Refer-To 內的 SIP URI 填寫本機端的 SIP URI，Refer-To 填寫遠端 SIP URI，會產生收回連線服務的效果如圖 3-1。在知道 連線服務被移轉到哪部裝置的情況下，使用者可以發出 Nested REFER 來要求取 回連線服務來進行連線服務，若配合[5]所提出的 Mobility header，指定回收的連 線服務類型，更能達到將被分流連線服務回收並整合的目的。

3.2 Session Manager, Session User and Free Node

雖然將 Nested REFER 加以變化可以應用於回收連線服務，但是因為使用 Nested REFER 收回連線服務必須先知道連線服務目前在哪台裝置上進行，所以 單憑 Nested REFER 還不能做到在任意裝置上進行連線服務分流與整合。因此我 們更進一步的將 SIP 所定義的 user agent 擴充為 session manager、session user 與 free node 三種邏輯成員。利用這三種邏輯成員的身份調整，將可建構自由移轉、

分流與整合連線服務機制。在介紹這些成員功能前，我們先引入一個部份連線服 務的概念。圖 3-2 中原本 A 與 C 兩個裝置視訊與音訊連線服務正在進行，當 A 將音訊連線服務移轉到 B 後，我們稱 A 與 B 都擁有部份連線服務。換句話說，

~ 21 ~ 

所謂的部份連線服務為連線服務經過分流機制處理後，依據被分流對象的數量分 成多個分流，這些分流就是部份連線服務。

圖 3-1 使用 Nested REFER 回收連線服務

A Video RTP C

Audio RTP Split

B

圖 3-2 部份連線服務示意圖

扮演 session manager 的 user agent 擁有所有部份連線服務的資訊，並可以利 用這些資訊對部份連線服務進行任意移轉、分流、取回及終止。而擁有部份連線 服務的 user agent 我們稱之為 session user。session user 可以主動控制其所擁有的 部份連線服務，或者被動接受 session manager 控制來決定是否對自己擁有部份連

~ 22 ~ 

線服務進行移轉。session user 在移轉成功後須告知 session manager 目前部份連 線服務的資訊，使得 session manager 可以掌握所有部份連線服務目前的資訊。而 其他非 session manager 或 session user 身份的 user agent 我們稱為 free node。

因為 session manager 對於連線服務有完整的控制權，基於便利性與安全性的 衡量，我們規劃出集中與分散兩種操作模式。這兩種操作模式的差異在於扮演的 session manager 的 user agent 數量。使用集中操作模式，只會存在一個 session manager，也就是僅有一個 user agent 可以對這個連線服務進行完整的控制。當通 訊內容有安全性上的考量，採用集中操作模式可以降低連線服務遭到有心人士惡 意竊取的風險，避免重要的談話內容外流。然而使用者若想要在非 session manager 身份的 user agent 上進行連線服務控制時就必須先進行 session manger 身份取得機制，向擁有 session manager 身份的 user agent 取得 session manager 身 份後，才能對連線服務進行控制。

使用者可以在 session user 或 free node 上進行 session manger 身份取得機制，

流程如圖 3-3 所示。想取得 session manager 權限的 user agent 會向 session manager 送出一個含有身份資訊的訊息用來向 session manager 要求權限取得。若 session manager 同意授權，會回傳一個包含所有部份連線服務資訊的訊息，收到這些資 訊的 user agent 將成為新的 session manager。session manager 在處理 session manger 身份取得機制的流程如圖 3-4。

最初 session manager 會處於等待的狀態，等待其他裝置來要求 session manager 身份移轉。當收到來自其他裝置要求 session manager 權限的訊息後，必 須先檢查自己的身分是否為 session manager，確定自己身份為 session manager 才開始驗證附帶於訊息中的身份資訊並關閉處理 SMR 以確保不會出現多個 session manager，否則直接回傳拒絕訊息。若要求 session manager 權限的使用者 身份不合法，回傳一個拒絕授權的訊息。反之，則回傳一個包含所有部份連線服 務資訊的訊息給該 user agent，告知他可以成為新的 session manager。同時將發

~ 23 ~ 

送訊息通知所有屬於這個連線服務的 session user，session manager 已經由新的 user agent 來擔任，而舊的 user agent 則依據是否擁有部份連線服務轉換成 session user 或是 free node 身份。

除了在 session user 或 free node 透過 session manger 身份取得機制來取得 session manager 權限的方式外，也可以由 session manager 主動將權限授與給其他 非 Session manager 身份的 user agent 來達到 session manager 身份轉換的目的。這 個機制稱為 Session Manager Transformation ( SMT )，過程如圖 3-5。由 session manager 選定一個要賦予 session manager 身份的 user agent，然後發送一個包含連 線服務資訊的訊息給選定的 user agent，接著等待選定的 user agent 回應。若收到 接受的訊息，表示授權已經成功，將告知所有屬於這個連線服務的 session user 新的 session manager 已經產生。若沒收到回應或被拒絕，則不做任何動作。因為 視訊與音訊裝置有限，session user 或 free node 在收到 SMT 訊息時，必須先檢 查自己身份是否已經是另外一個連線服務的 session manager，一個 user agent 只 能成為一個連線服務的 session manager 避免造成回收無法顯示影像。透過 SMR 與 SMT 兩項機制，free node 與 session user 可以自由的變換成為 session manager 身份，而 session manager 也會因為這兩項機制而成為 free node 或 session user 身 份，圖 3-7 為 user agent 身份轉換的示意圖。

~ 24 ~ 

圖 3-3 (SMR) 要求 session manager 權限

圖 3-4 (SMR)Session manager 處理行為

圖 3-5 (SMT)Session manager handling behavior

圖 3-6 (SMT)Session user/free node handling behavior

~ 25 ~ 

圖 3-7 User agent 身份轉換

在分散操作模式中，user agent 的身份只會有 session manager 或 free node 其 中一種，也就是說每一個 session user 即是 session manager。此操作模式首要考 量為操作的便利性，因此擁有 session manager 身份的 user agent 對所屬的連線服 務進行移轉或分流成功後，也會對連線服務移轉或分流的對象進行 SMT 機制。

與集中操作模式不同的是進行到 Informing 階段時，所通知的訊息並不是 session manager 已經由新的 user agent 擔任，而是加入新的 session manager，使得連線服 務移轉或分流的對象也成為 session manager。當再次進行 session 移轉或分流時，

session manager 數量也會隨著增加，任何擁有部份連線服務的 user agent 都是 session manager，方便在任何 user agent 上對連線服務進行控制。在此操作模式 下 free node 也可以 SMR 機制來向任一個 session manager 取得權限，但是 free node 在取得 session manager 身分之後一定的時間內，必須對連線服務進行控制，

一旦超過時間沒有對連線服務進行任何的控制，將會恢復成為 free node 身份。

3.3

安全性考量

在進行 SMT 與 SMR 時或進行連線服務移轉時，若負責轉送的主機對封包 進行測錄，有可能造成連線服務資訊外洩的疑慮。而且竊取到連線服務資訊的主 機，將可以利用這些資訊把連線服務移轉過來，使得使用者的隱私權受到侵犯。

~ 26 ~ 

在 0 提出了 S/MIME 機制來將進行加密，然而 SIP 訊息並不是所有資訊都需 要加密。因此[16]提出了部份加密的機制。在本論文所提出的架構中，可以很方 便的將[16]所提出的機制引入使用。

~ 27 ~ 

第4章  系統實作與實驗

4.1

系統實作

近年來因為 SIP 相關技術越來越熱門，許多 SIP 堆疊與 user agent 被開發出 來，我們選擇 JAIN-SIP、NIST-SIP 與 SIP communicator 來進行實作，架構如圖 4-1，以下我們簡單的介紹這三種工具：

I. JAIN-SIP

JAIN(Java APIs for Integrated Networks)-SIP [13]定義了許多 SIP API 介面讓 使用者在 JAVA 平台上得以快速的開發電話通信平台，使用 JAIN-SIP 更能降低 開發電話通信平台在開發、測試與整合所花的成本。

II. NIST-SIP

NIST-SIP[14]是 National Institute of Standards and Technology(NIST)進行的一 個專案，目前版本為 1.2。為了提供更快速與方便的 SIP 開發環境 NIST-SIP 實作 了許多函式庫與工具，包含了通訊協定堆疊與函式庫，NIST-SIP 可以用來協助 使用者開發並測試 SIP 應用程式與伺服器。

III. SIP communicator

SIP communicator[15]是一套建構在 JAIN-SIP 與 Java Media Framework(JMF) JAVA 的 SIP user agent，由 Emil Ivov 所帶領的團隊負責開發與維護。SIP communicator 可以在 IPv4 或 IPv6 的環境下利用 SIP 建立視訊及音訊的連線服 務。

在我們實作的系統中，為了利用[8]所提出的 Nested REFER 來進行連線服務 的回收，我們在 javax.sip.header 套件中加入了 ReferredByHeader 介面，並在 gov.nist.javax.sip.header 套件中實作 ReferredBy，接著在 SipManager 中，插入產 生與接收 Nested REFER 的函式，使得 sip-communicator 在收到 Nested REFER 時 能夠順利的完成連線服務回收，clinet 端與 server 端行為如圖 4-2 與圖 4-3。

~ 28 ~ 

圖 4-1 SIP-Communicator 的軟體組成

圖 4-2 client 送出 Nested REFER 流程

另外為了順利的透過 SMR 與 SMT 傳遞 session manager 資訊，我們也改寫 了 CallProcessing 中處理 INVITE 的函式，使得 session manager 資訊可以攜帶在 message body 中，sip-communicator 當收到 session manager 資訊後，會在 rule table 上 顯 示 目 前 user agner 的 身 分 如 圖 4-4 。

~ 29 ~ 

圖 4-3 Server 處理 Nested REFER 流程

圖 4-4 User anger 身分轉換時 sip-communicator 變動

4.2

實驗

經過改寫過的 SIP communicator 軟體如圖 4-5，為了驗證我們所提出的機制 是否可行，我們使用四台 user agent 設計了四種情境模式，分別是 1.移轉並取回

~ 30 ~ 

全部連線服務、2.分流並取回部份連線服務、3.在對方主機也進行分流連線服務 的情況下分流並取回連線服務、4.透過 SMR 與 SMT 取回連線服務 。

圖 4-5 SIP-Communicator 軟體畫面

在情境 1 中，我們使用三台 user agent，分別稱為 A、B 與 C。先讓 A 與 B 建立連線，接著從 A 向 C 發出移轉全部連線服務的命令，使 C 取代 A 與 B 進行 連線服務，然後再由 A 向發出收回全部連線服務的命令，恢復 A 與 B 之間的連 線服務，過程如圖 4-6。我們實際操作了情境 1 並在電腦 B 上觀察封包繪製出圖 4-8。

我們可以看出，在大約 7 秒的時候 A 進行了連線服務移轉，使得原本 A 與 B 之間傳送的封包數變為零，而 B 與 C 之間有封包開始傳送，直到 15 秒時，A 作了連線服務回收，才使得 A 與 B 之間又有封包開始傳送。

情境 2 同樣使用到 3 台電腦，不同於情境 1 的地方在於 A 不是將連線服務 全部移轉，而是將視訊連線服務分流給 C，如圖 4-8。同樣的我們也在 B 上觀察 封包傳輸狀況繪製成圖 4-9。A 在 7 秒時將視訊連線服務分留給 C，使得 A 與 B 之間只剩下音訊連線服務在進行，因為音訊所需的資料量遠小於視訊，所以我們 可以看到大部分的封包都由 A 轉向 C，直到 15 秒，A 下了收回視訊連線服務後

~ 31 ~ 

B 與 C 之間的封包數量才歸零。

圖 4-6 情境一：移轉並取回全部連線服務

圖 4-7 移轉全部連線服務再回收的封包流量

~ 32 ~ 

圖 4-8 情境二：移轉並取回視訊連線服務

圖 4-9 移轉視訊連線服務再回收的封包流量

~ 33 ~ 

情境 3 則在對方也進行分流的情況下，進行將音訊連線服務分流出去再回 收。圖 4-10 中的 B 與 C 先建立連線服務，C 把音訊連線服務分流給 D，接著 B 在將音訊服務分流給 A，使音訊連線服務從原本的 B 與 C 移轉到 A 與 D 之間，

最後 B 再將音訊連線服務取回。

圖 4-11 為在 B 上觀察的封包流量圖，在 13 秒時 C 將音訊連線服務分流給 D，使得 B 與 D 之間產生封包流量。接著在 23 秒時，B 也將音訊連線服務分流 給 A，所以 B 與 D 之間傳輸的封包量歸零。最後在 32 秒時，B 向 A 收回音訊連 線服務，於是 B 與 D 之間又開始有封包產生。

情境模式 4 使用了四台電腦，如圖 4-12 所示 A1 與 B1 依序將音訊連線服務 移轉至 A2 與 B2，在 A1 收回音訊連線服務後，由 A2 向 A1 進行 SMR 要求 session manager 權限，取得權限後，A2 收回 A1 上的所有連線服務，接者 B1 透過 SMT 機制將 session manager 權限授權給 B2，在 B2 接受以後，收回 B1 上的視訊連線 服務。

圖 4-10 情境三：對方進行分流後再分流並取回連線服務

~ 34 ~ 

圖 4-11 對方進行分流後再分流並取回連線服務的封包流量

圖 4-13 為情境 4 電腦 A1 所錄得的封包流量圖，一開始 A1 與 B1 建立了視 訊與音訊連線服務，在約九秒的時候，A1 將音訊連線服務移轉給 A2，所以音訊 連線服務的流量消失，接著在約 18 秒時 A1 將音訊連線服務回收，但是此時 B1 也將音訊連線服務移轉給 B2，所以 A1 取回的音訊連線服務變成由 B2 提供。

~ 35 ~  A1

A2 B1 B2

Audio Video

Split Audio

Audio

Split Audio Audio

Session Manager

Free Node Session Free Node

Manager

Session Manager

Session

Manager Free Node

Session Manager

Session

Manager Session User

Retrieve Audio

Audio

Session Manager

Session

Manager Session User

Free Node

SMR Session User

Session Manager

Session Manager

Session User Session User

Retrieve All

Video

Video

Video

Audio Video

Session Manager

Session Manager Session User

Free Node

Retrieve Video Audio

Video

Session Manager

Session Manager

Free Node Free Node

Session User

Session Manager Session

Manager Session User Session User

SMT

圖 4-12 透過 SMR 與 SMT 取回連線服務

~ 36 ~ 

圖 4-13 情境 4 電腦 A1 上所錄得的封包流量圖

圖 4-14 為情境 4 電腦 B1 上所錄得的封包流量圖，在五秒左右因為 A1 將音 訊連線服務移轉給 A2，使得音訊連線服務的來源變成了 A2，在 15 秒時 B1 也 將音訊連線服務移轉出去給 B2，因此音訊連線服務的流量消失，而 30 秒時，

A2 完成 SMR 並進行視訊與音訊連線服務的取回，使得 B1 的視訊流量由 A1 改 導向 A2，接著在 40 秒左右 B1 也完成了 SMT，使得 B2 可以進連線服務的取回，

導致全部流量歸零。

~ 37 ~ 

圖 4-14 情境 4 電腦 B1 上所錄得的封包流量圖

~ 38 ~ 

第5章  結論與未來工作

未來分流與整合連線服務將會成為一種重要的應用，而在本論文中提出了一 套連線服務自由移轉、分流與整合機制，讓使用者可以任意進行連線服務的分流 與整合。透過 session manager、session user 與 free node 三種角色的轉換，使用 者可以在任意一台裝置上進行連線服務的再移轉或回收整合。相較於[6]所提出 的分流機制，我們所提出的機制不受虛擬裝置的限制任意，在分流過程中所需的 訊息量也較低，減輕網路與裝置處理訊息的額外負擔。在前一章節中，我們也透 過實驗證明，這樣的機制即使對方也進行分流仍然可以正常的運作。

目前這套機制只在 J2SE 實做出雛型系統，未來我們希望能夠將環境繼續的 在 J2ME 上進行開發並整合至 OSGi[17]家用閘道，期望能夠藉此讓這套機制確實 的在行動環境中發揮其任意自由移轉的精神，以賦予使用者更精彩的數位生活。

~ 39 ~ 

參考文獻 

[1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley and E. Schooler, “SIP: Session Initiation Protocol”, RFC 3261, IETF, June 2002

[2] M. Handley and V. Jacobson, “SDP: Session Description Protocol”, RFC 2327, IETF, April 1998

[3] R. Sparks, “The Session Initiation Protocol (SIP) Refer Method”, RFC 3515, IETF, April 2003

[4] J. Rosenberg, J. Peterson, H. Schulzrinne and G. Camarillo, “Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)”, RFC 3725, IETF, April 2004

[5] Chen-Jui Peng, Min-Xiou Chen and Ren-Hung Hwang , “SSIP: Split a SIP Session over Multiple Devices＂, Technical Co-Chair, ANW2005 Technical Program Committee

[6] R. Shacham , H. Schulzrinne , S. Thakolsri and W. Kellerer , “Session

Initiation Protocol(SIP) Session Mobility draft-shacham-sipping-session-mobility-04”, IETF , July 2007

[7] R. Shacham, H. Schulzrinne, S. Thakolsri and W. Kellerer, “The virtual device:expanding wireless communication services through service discovery and session mobility,” IEEE international conference on wireless and mobile computing, networking and communications, 2005. (WiMob'2005), Volume 4, Aug. 22-24, 2005, Page(s):73 – 81

[8] R. Sparks, “The Session Initiation Protocol (SIP) Referred-By Mechanism”,RFC 3892 ,IETF, Sep 2004

[9] J. Rosenberg and H. Schulzrinne, “Reliability of Provisional Responses in the Session Initiation Protocol (SIP)”, RFC 3262, IETF, June 2002

[10] J. Rosenberg and H. Schulzrinne, “Session Initiation Protocol (SIP): Locating SIP Servers”,RFC 3263, June 2002

[11] J. Rosenberg and H. Schulzrinne, “An Offer/Answer Model with the Session Description Protocol (SDP)”, RFC 3264, June 2002

~ 40 ~ 

[12] A. B. Roach, “Session Initiation Protocol (SIP)-Specific Event Notification”, RFC 3265, IETF, June 2002

[13] JCP, “JSR-32: JAIN SIP Specification,” http://www.jcp.org/en/jsr/detail?id=32 [14] NIST, “NIST-SIP 1.2 – SIP Libraries and Tools for the People,”

http://www-x.antd.nist.gov/proj/iptel/

[15] Network Research Team, “SIP-Communicator A Java Softphone based on JAIN SIP with audio/video and instant,” https://sip-communicator.dev.java.net/

[16] J. Peterson, “Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format,” RFC 3893, IETF, Sep 2004

[17] Open Service Gateway Initiative, http://www.osgi.org/