國立臺中教育大學數學教育學系碩士論文
指導教授：甯自強博士
王讚彬博士
依發話者喜好為基礎之網路電話
技術與應用
研究生：曾伯岑 撰
中華民國九十六年七月
摘要 網路電話系統中，多重註冊為其一項優點，使用者可為自己擁有的多 項通訊裝置註冊帳號，且都對映到同一使用者，因此，須聯絡對方時，只 需撥打該使用者的專屬號碼即可，不需一一連繫各個使用者的裝置，而本 文便是在此基礎上，介紹如何依發話者的喜好選擇受話端的裝置，即是能 夠依照在發話時的附加條件，自動對於受話者的各項通訊裝置作一喜好排 序，以期能與最適合的受話端通話。 對於依照發話者喜好選擇受話端的裝置，雖然已在 IETF 的 RFC 3841 中有規範相關的方法，但在位址比對上的演算法，其採一次對全部的受話 者位址作比較，得出順序後再進行連線，是較為浪費時間的，本文即針對 此一缺點，提出討論，並進而提出改良的循序位址比對法，以及管線式比 對法，其中循序式比對法是以最有可能接聽的位址依序進入比對，每比對 一次，得出結果即進行連線程序，較原本的 RFC3841 比對法，可以減少不 必要的系統效能，也能夠縮短所需時間；而管線式比對法，則是循序式比 對法的改進，將原本在等待連線的同一時間，繼續作下一組位址的比對工 作，如此更降低了整體的所需時間，這兩種方法皆能更快速的依發話者需 求找到受話端。 本研究也將發話者喜好選擇受話端的網路電話應用在數學課程教育 上，建置一網頁介面的數學學習線上諮詢系統，使得學生或老師能夠更快 速、方便的連絡彼此，系統採用概念關聯架構的觀念，讓學生在發現課業 問題時，能夠按照問題程度的發話條件，找尋到負責該課程章節問題的助 教，線上即時詢問，以期能夠增進學習效率。 關鍵字：網路電話，發話者喜好，位置比對，概念關聯
ABSTRACT
Multiple registration is an important feature in Voice over IP (VoIP) systems. With this feature, users can register several devices/locations with one logical number. In this environment, caller preferences provide a manner to define the priority for each device/location. Based on the priority, callers may select callee’s location according to their preferences.
For example, IETF has defined a method of selecting callee’s location according to caller preferences in RFC 3841. However, the matching algorithm of RFC3841 is time-consuming because it will process all contact addresses at once. Our research introduces a novel location matching algorithm for fast selecting callee’s location based on caller preferences.
In this thesis, we also develop a VoIP prototype system of caller preferences using the concept relation architecture for mathematics education. The system can automatic select appropriate teaching assistants to answer questions according to the concept relation of questions.
目錄
中文摘要...I 英文摘要...II 目錄...III 表目錄...IV 圖目錄...V 第一章 緒論...1 1.1 動機與目的...1 1.2 論文架構...2 第二章 背景知識與相關文獻...3 2.1 通話處理規則...32.2 RFC 3841 Caller Preferences for the Session Initiation Protocol...4
2.2.1 Reject-Contact header fields 與 Accept-Contact header fields...5
2.2.2 Request-Disposition...5 2.3 RFC 3841 的位址比對方法...6 2.3.1 位址比對範例...8 第三章 循序比對法與管線式比對法...11 3.1 循序比對法(Sequential Matching)...11 3.2 管線式比對法(Pipelined Matching)...14 第四章 效能評估...17 4.1 位址比對方法分析...19 4.2 位址比對數量分析...19 4.3 位址比對時間分析...20 4.3.1 循序比對法的位址比對時間分析...20 4.3.2 管線式比對法的位址比對時間分析...26 4.4 小結...28 第五章 發話者喜好之網路電話系統在數學教育課程上的應用...29 5.1 數學學習線上諮詢系統介紹…...29 5.2 概念關聯與 click-to-dial 技術...29 5.2.1 概念關聯架構...29 5.2.2 click-to-dial 技術...30 5.3 數學學習線上諮詢系統組成與操作...31 5.4 問題與討論...36 第六章 結論...38 參考文獻...39
表目錄
表 2.1 CPL 與 Caller preferences 的比較...4 表 2.2 比對過程統計表...9 表 4.1 三種方法的特性比較...19 表 4.2 RFC3841 與循序比對法處理位址的數量比較...20 表 4.3 RFC3841 與循序比對法處理有 q 值重複位址的時間比較...24圖目錄 圖 2.1 計算分數流程圖...7 圖 3.1 循序比對法流程圖...12 圖 3.2 管線式比對法流程圖...15 圖 4.1 三種方法所需時間的比較...17 圖 4.2 二個位址數的 q 值重複情形...21 圖 4.3 三個位址數的 q 值重複情形...22 圖 4.4 四個位址數的 q 值重複情形...22 圖 4.5 第一次比對即完成連線的位址分佈圖...23 圖 4.6 RFC3841 與循序比對法在 r=0.9 時的位址平均比對時間...25 圖 4.7 RFC3841 與循序比對法在 r=1 時的位址平均比對時間...25 圖 4.8 RFC3841 與循序比對法在 r=1.5 時的位址平均比對時間...26 圖 4.9 管線式比對法與循序比對法的整體所需時間比較...27 圖 5.1 概念關聯圖...30
圖 5.2 Call flow of click-to-dial...31
圖 5.3 數學學習線上諮詢系統架構圖...32 圖 5.4 學生於線上諮詢系統操作流程圖...33 圖 5.5 數學學習線上諮詢系統登入畫面...34 圖 5.6 學生修課科目...35 圖 5.7 課程修課名單...35 圖 5.8 依問題程度選擇助教...36
第一章 緒論 在傳統電話系統中，一個號碼代表一個裝置，若要找到某位使用者， 那麼必須撥打在他可能出現地點的電話，例如要找某位教師，在他的週遭 可能出現的環境，辦公室、教室、實驗室、手機等都需要依其號碼一一撥 打，才能找到該位教師，而在網路電話技術出現後，這樣的問題便獲得解 決。
網路電話技術中，Session Initiation Protocol(SIP)[2][6]為一主要通訊協 定，而多重註冊是其一項優點，即是一個使用者可以替自己的多個裝置註 冊 不 同 的 位 址 (contacts) ， 但 卻 是 對 映 到 同 一 使 用 者 的 Address of Record(AOR)，只需撥打使用者的專屬號碼，系統會依其所註冊的所有裝 置發出連線請求，直到與某個裝置達成連線，即是找到該使用者，這樣便 能解決傳統電話中可能要撥打多次電話才可以找到使用者的問題。 在網路電話的世界中，還多了一項傳統電話所沒有的功能，那便是使 用者的狀態顯示(presence)[1][3][4][5]，在過去，想要知道對方現在是否在 該地點，或著是正在做什麼，只有打電話過去才能了解，但在網路電話上， 不須再打電話過去才能了解，直接可以在對方顯示的狀態上得知現況，這 在目前的即時通訊軟體上皆以相當普遍地使用著，在帳號旁即會顯示出該 使用者目前的狀態，例如是在線、不在線、忙碌中、電話中等即時的情況， 甚至是以狀態顯示的文字引起並增加與對方的互動。 顯示狀態的服務(presence service)，是使用者的被動反應，由使用者自 行控制選擇目前的狀態，而使用者不只可以有被動的反應，也是可以發出 主動的要求，便是以發話者的喜好條件選擇受話端。 1.1 動機與目的 在網路電話系統中，解決了在傳統電話上需要撥打多次號碼才有可能 找到受話者的問題，過去，在傳統電話裡，語音服務是絕大部份的選擇， 少有裝置提供其他功能，但是，現今各種的通訊裝置皆附帶多樣功能，各
有異同，如何讓裝置的功能發揮效用，讓受話方擁有相同功能的裝置能優 先受話，於是又產生了新的問題，例如我的通訊裝置有視訊功能，想要與 也有視訊功能的受話方通話，是否可以呢？也就是能否依照我的喜好選擇 受話者的裝置？可以的，只要遵循著通話處理規則。 通話處理規則是指依循規則來處理不同的通話，例如發話者想要與受 話端有視訊設備的裝置通話，就能在發話時附加規則，限定要找有視訊裝 置的受話端，caller preferences 是上述在發話時附加規則的方式，相關的標 準文件有 RFC 3840 Indicating User Agent Capabilities in the SIP[7]、RFC 3841 Caller Preferences for SIP[8][15]與 RFC 4596 Guidelines for Usage of the Session Initiation Protocol (SIP) Caller Preferences Extension[9]。
在 RFC 3841 中即是規範發話者喜好選擇受話端的相關方法，在向受 話者發出連線時，附加想要的功能需求，系統就依其規則將受話者的裝置 作一排序，最符合發話者的要求就可以優先受話，甚至是不具有哪些功能 的要排除受話，這樣就可以依發話者喜好選擇受話裝置。 不過，通話的目的是為了找到受話者，受話端雖然有多項裝置，而受 話者始終只有一位，雖然已經存在著相關的方法-RFC 3841 在作通話處 理，但其在規則處理上的位址比對演算法還有改良的空間，因此，如何能 夠較快速的找到使用者且依發話端的喜好來選擇受話端裝置，便是本論文 的主要目的。 1.2 論文架構 在後續章節上，第二章將介紹相關的背景知識與文獻討論，且包含 RFC 3841 中按發話者喜好選擇受話端裝置的演算法，在第三章則是提出兩 個改善的方法-循序式比對法與管線式比對法，第四章為各種位址比對方法 的效能評估與成本比較，第五章是將以發話者喜好為基礎之網路電話應用 於數學課程教育上的實作系統雛形，最後第六章是本論文的結論。
第二章 背景知識與相關文獻
本章節將會介紹以發話者喜好為基礎之網路電話相關的背景知識，在 2.1 節是通話處理規則的種類，2.2 節是在介紹 RFC 3841 中定義的 Reject-Contact、Accept-Contact 與 Request-Disposition header fields，2.3 節則是 RFC3841 中有關運算位址比對的演算法。 2.1 通話處理規則 通話處理規則中，前述提到的 RFC 3840、RFC 3841 及 RFC 4596 都是 與發話者喜好選擇受話端相關的標準文件，其中 RFC 3840 是在描述有哪些 功能可以讓 User agent 註冊及該以哪些格式文字註冊，RFC 3841 是在定義 發話者喜好的通話處理該如何運作的方法，而 RFC 4596 則是包含了 caller preferences 的延伸應用及描述按發話者喜好選擇受話端的益處，並以例子 展示其運作步驟，及在章節最後按 RFC 3841 中 7.2 節的 matching algorithm 實作一個方法應用於發話者的喜好與受話者能力的比對，RFC 4596 的主要 目的是讓人更加了解 RFC 3840 與 RFC 3841。 在 SIP 的世界中，除了 RFC 3841 外，還有一種語言在描述通話處理 的規則，那就是 CPL(call processing language)[4][10]，它的功用相似於 caller preferences，用於指定接聽電話的規則，例如在上班時間早上九點到下午 五點，凡是有電話進來一律接到辦公室的話機號碼，除非是家裡打來的電 話才是接到自己的手機上，如表 2.1，CPL 的缺點是使用者需自行編寫上 傳一份關於自己想要的規則，而 caller preferences 是在發話時附加想要的 規則，因此可以因應即時的變動來更改規則，例如要直接撥打至語音留言 系統，即可在發話時附加限制，而傳統的電話系統都無法直接撥至留言系 統，除非它有一個專屬號碼，但這樣就需要再多記憶一組號碼，不夠直接 快速。
RFC 4596 大部份的篇幅都在展示 caller preferences 的例子，發話者的 哪些喜好要求，sip proxy 會如何因應處理，展示多種不同的情形，最後， 依 RFC 3841 中 7.2 節的演算法，提出一個實作的方法，以下是方法的步驟：
STEP 1. Extracting a Feature Set from a Header STEP 2. Extracting Values from a Feature Parameter STEP 3. Comparing Two Value-Ranges
STEP 4. Feature Set to Feature Set Matching
STEP 5. Selecting and Ordering Contacts Based on Caller Preferences
表 2.1 CPL 與 Caller preferences 的比較
The method of
call processing CPL Caller preferences
Feature 規則需要上傳至主機且需經 常維謢才能達到所求 規則是附加在每次向受話者 發出通話請求時 Advantage 規則格式採用 XML 標準 能因應即時的變動為每次通 話附加不同的規則 Disadvantage 無法立刻為每次通話更改規 則，較無彈性 著重在發話者的喜好規則
2.2 RFC 3841 Caller Preferences for the Session Initiation Protocol
RFC 3841[8]是在描述如何依發話者的喜好選擇受話端，且制定三個 SIP message 的 header field ， 分 別 是 Reject-Contact header field 、 Accept-Contact header fields 與 Request-Disposition，前兩者是用於發話時附 加 所 想 要 的 規 則 喜 好 ， Reject-Contact 是 記 錄 想 要 拒 絕 的 功 能 特 性 ， Accept-Contact 則 是 希 望 對 方 受 話 端 裝 置 能 夠 擁 有 的 功 能 特 性 ， 而 Request-Disposition 則是記載發話者將發出 SIP message 的請求時，其路徑 路由希望在伺服器上被處理的方式，RFC 3841 並且提出了一個比對位址的 演算法以決定如何按發話者的喜好選擇受話端，以下兩小節介紹新定義的
三個 header field。
2.2.1 Reject-Contact header fields 與 Accept-Contact header fields
Reject-Contact 與 Accept-Contact 是記載著許多的發話者所偏好的特性 數值，用於選擇其所喜好的受話端裝置，以下為其例子： Accept-Contact: *;audio;require Reject-Contact: *;actor="msg-taker";video 其格式皆為以“*＂為起始，接著是各種的特性參數，以分號作區隔，特性 參數的種類有四種，分別是 numeric、token、string、boolean，種類的不同 影響的是比對的方式，numeric 為數值類型的參數，比對方式即是一般數 值的比較，即數值是否有達到其所要求的界限，而 string 與 token 兩類是 字串型的參數，差別在於 token 是在固定的參數集中的一項，而 string 則 可以是任意的字串，非固定參數集中的一個，最後一項 boolean 是指參數 為 true 或 false，若未指定，預設為 true，如上述例子中，在 Accept-Contact 中有一項 boolean 參數為 audio，其未指定 true 或 false，即為“audio=true＂ 之意。 在特性參數的四項種類之外，還有重要的兩個標籤：explicit、require， 是附加在參數後，如上述例子，對於發話者的喜好選擇有重要的作用，詳 細的說明與應用將在 2.3 節 RFC 3841 的位址比對方法中作介紹。 2.2.2 Request-Disposition Request-Disposition 的格式相對於 Reject&Accept-Contact 則是較為簡 單，皆為 token 種類，例子如下：
Request-Disposition: proxy, recurse, parallel
其參數為固定以下數值：proxy/redirect、cancel/no-cancel、fork/no-fork、 recurse/no-recurse、parallel/sequential、queue/no-queue，每一組參數只能出 現一個，如已有 proxy 參數，就不可以再加入 redirect 參數。
2.3 RFC 3841 的位址比對方法
依RFC 3841 Caller Preferences for Session Initiation Protocol (SIP)上所 說明的位址比對方法，是為了讓發話者裝置能夠選擇適當的受話裝置，以 便傳送影像或聲音等功能，也就是希望受話者裝置與發話者有相同的能 力，因此在請求連線時，可以附加兩種header field：Reject-Contact header field及Accept-Contact header field，其中便會提到該發話端拒絕裝置有哪些 功能的位址或是同意裝置有哪些功能的位址，而比對方法是首先處理 Reject-Contact header field ，排除掉不想要的位址，餘下的位址便稱為target set ，接著處理 Accept-Contact header field，依其想要的功能將餘下的位址 做一排序。 在 target set 中，若無位址存在，代表所有受話者位址皆被排除在外， 為了避免 call miss 的問題，則連線順序會依各位址的 q 值為依據，若有位 址存在 target set，接者是要在這其中排出順序，順序的參照數值稱為 Qa 值，計算方式是依照 Accept-Contact，Qa 值是在當位址的 q 值相同時，才 拿來當作第二決定優先順序之值；另外有種情形是受話者某位址並不帶有 任何能力參數可供比對時，將會被暫時排除在 target set 之外，待計算 Qa 值時才加回在 target set 中，且其 Qa 值為 1。 每個位址的 Qa 值計算方式，是先依 accept-contact 的項目計算分數 (score)，然後視 accept-contact 有幾項，算出其平均值，即為 Qa 值，計算 方式如下所述，若該位址所具備的能力完全符合 accept-contact 中的所需要 項目，則拿到 1 分，若只符合二項中的一項則拿到1 2分，也就是 0.5 分， 依此類推，接著再按其附加標籤調整分數，如圖 2.1，標籤的種類有 explicit 與 require，調整分數的方式為當分數為 1 分時，不作調整；小於 1 分時才 進入調整步驟程序，因為分數小於 1，代表該位址的受話裝置有部份功能 沒有完全符合該 accept-contact 的要求，因此，若沒有附加任何標籤，則分 數不作改變；若有 explicit 標籤，則分數調整為 0；若有 require 標籤，表 示這項功能是必須的，則將該位址排除在 target set 外，最後依有幾項
accept-contact，算出該位址分數的算術平均值，即為 Qa 值，誰獲得的 Qa 最高即是 target set 中的第一優先位址，排出順序後，再依 target set 中各位 址的 q 值大小，由大至小，若相同時再參照剛剛計算出的 Qa 值，決定受 話端的順序，依序發出連線請求，其步驟順序整理如下：
STEP 1.處理 Reject-Contact header field STEP 2.處理 Accept-Contact header field
STEP 3.計算 target set 中各位址的分數(score)，其平均值為 Qa STEP 4.先依 q-value，若有相同再依 Qa 值大小決定優先順序
2.3.1 位址比對範例
範例如RFC 3841 Caller Preferences for SIP[8]中所述，假設一位已註冊
的使用者其位址為sip:[email protected]，且他有五個連絡位址，分別是：
1. Contact:sip:[email protected];audio;video;methods="INVITE,BYE
";q=0.2
2. Contact:sip:[email protected];audio="FALSE";methods="INVITE" ;actor="msg-taker";q=0.2
3. Contact: sip:[email protected];audio;actor="msg-taker"; methods="INVITE";video;q=0.3
4. Contact:sip:[email protected];audio;methods="INVITE,OPTIONS"
;q=0.2
5. Contact: sip:[email protected];q=0.5
u1 到u5，位址後面接著的即是該裝置所具備的功能，如第一個連絡 位址u1，即是指位址為[email protected]的，其具備的能力有audio、 video，且可以使用SIP的methods為INVITE與BYE，及其q值為 0.2，當有一
發話者向sip:[email protected]發出INVITE時，且附帶的caller preferences
header fields如下所示： – Reject-Contact: *;actor="msg-taker";video – Accept-Contact: *;audio;require – Accept-Contact: *;video;explicit – Accept-Contact: *;methods="BYE";class="business";q=1.0 如表 2.2 所示，按照 2.3 節提到的位址比對方法步驟，一開始，首先移除 u5，因為他並不帶有任何能力可供比較，所以先排除在外，接著處理 Reject-Contact，u3 是唯一完全符合的項目，因此將 u3 排除，餘下的繼續
步驟程序，u1、u2、u4 成為 target set，按 accept-contact header field 開始計 算 分 數 ， u1 符 合 第 一 項 accept-contact ， 拿 到 1 分 ， 亦 符 合 第 二 項 accept-contact，對於第二項也拿到 1 分，在第三項 accept-contact，只符合 兩項要求中的一項，因此拿到 0.5 分，又該項並無附加任何標籤，所以分 數不作調整，而 u2，對於第一項 accept-contact 並不符合，又該項有附加 標籤 require，所以 u2 被排除，接著處理 u4，符合第一項 accept-contact， 拿到 1 分，對於第二項 accept-contact 的要求，不符合 video，得 0.0 分， 但有 explicit 標籤，因此將分數調整為 0(本來就已經是 0.0 分)，對於第三 項 accept-contact 則是完全不符合，因此不計分。接著是計算 Qa 值，u1 分 別拿到 1、1、0.5 分，因此它的 Qa 值是((1+1+0.5)/3)=0.83，u4 拿到 1、0.0 分，所以 u4 的 Qa 值為 0.5，此時將 u5 加回 target set，且其 Qa 值為 1.0， 最後就是要決定順序，按照餘下各位址的 q 值與 Qa 值，u5 的 q 值為 0.5， Qa 值為 1.0；u1 的 q 值為 0.2，Qa 值為 0.83；u4 的 q 值為 0.2，Qa 值為 0.5，所以第一優先順序是 u5，因為它的 q 值最大，而 u1 與 u4 的 q 值皆 為 0.2，因此再比較 Qa 值，u1 的 Qa 值大於 u4，所以 u1 優先，最後的連 線順序即為 u5，接著是 u1，最後是 u4。
Reject-Contact Accept-Contact Accept-Contact Accept-Contact Reject & Accept
Contact Callee contacts *;actor="msg-taker "; video *;audio; require *;video; explicit *; methods="BYE"; class="business"; q=1.0 Qa audio; video; methods="INVITE,BYE; u1 q=0.2
Get 1 point Get 1 point Get 0.5 point (1+1+0.5)/ 3=0.83 audio="FALSE"; methods="INVITE"; actor="msg-taker"; u2 q=0.2 Audio=＂FALSE ＂, but it is require, so u2 gets discarded audio; actor="msg-taker"; methods="INVITE"; video; u3 q=0.3 Completely correspondence, so u3 gets discarded audio; methods="INVITE, OPTIONS"; u4 q=0.2
Get 1 point Get 0 point (1+0)/2= 0.5
u5 q=0.5 immune 1
在 RFC3841 Caller Preferences for SIP 的位址比對法中，可以發現是把 受話者的所有裝置位址一次處理完，決定出剩餘位址(target set)的順序後再 依其 q 值的大小決定真正的連線順序，其真正第一優先考量的參考值是各 位址的 q 值，是經過比對過程後，餘下受話者位址的 q 值，而非在處理過 程中依 Accept-Contact 計算分數而得的 Qa 值，Qa 值是在 q 值相同時，才 提供一個比較的依據，是連線請求的第二參考值。
第三章 循序比對法與管線式比對法 由上述例子可以發現到，在 RFC 3841 中的位址比對法，對於受話方 位址是採用一次處理的方式，但是其位址比對演算法得出的 Qa 值卻又不 是連線依循的第一參考值，而是各比對成功位址的 q 值，針對這些缺點， 因此，我們在本章節提出改良的方法。 發出通話請求的目的是在找到受話者，只要對一個受話者的位址完成 連線通話即可，因為已經找到受話者，就不須再對其餘位址發出連線請 求，對於 RFC 3841 中，一次處理完所有的受話者位址這項缺點，我們將 它改善為一次處理一個位址，且是所有位址中，q 值最大的位址，也就是 先將全部的受話者位址按 q 值大小為序作排列，再按此順序對各位址作比 對處理，q 值相同時，則一起作處理，照原法計算分數及 Qa 值，當然，連 線的時機也須被改善，因為這決定到是否需要繼續進行剩餘的工作，因此 每當有比對位址的結果出來時，若比對成功，即發出連線請求，連線成功 即可停止剩餘的比對處理或是發出連線請求的工作，否則就接著程序繼續 進行，直到連線成功或是所有位址皆處理過，這樣的優點便在於只要是 q 值愈大的位址比對成功且完成連線，便會節省越多的時間與系統處理比對 所需的效能。我們分別提出兩種方式-4.1 節的循序比對法與 4.2 節管線式 比對法，以改良 RFC 3841 中的位址比對法，方法描述如下： 3.1 循序比對法(Sequential Matching) 循序比對法，是在一開始先依受話者各位址 q 值的大小，將最大 q 值 的位址送入處理，也就是進行 RFC 3841 Caller Preferences for SIP 的比對方 法，若位址沒被排除掉，完成比對程序，即進行連線，成功即結束，因為 已經找到受話者，不必再處理其餘的位址，若在比對過程中遭到排除或是 連線未成功，則接著 q 值順序處理其餘的位址，而遇到無帶有任何能力參 數可供比對的位址時，則直接發出連線請求，完整的步驟如下(如圖 3.1)：
STEP 1.選擇受話者位址中 q 值最大者(相同時則一起處理) STEP 2.按 RFC3841 中比對的方法處理篩選位址
STEP 3.若比對成功且完成連線即結束，否則重複步驟 1 至 3，選 擇 q-value 次大者，直至處理完所有位址
圖 3.1 循序比對法流程圖
因為在 RFC 3841 Caller Preferences for SIP 中的比對方法是一定要將 所有受話者的連絡位址一次處理完，才能決定連線的順序，而循序比對法 中，不須一次處理完全部的位址，一次只處理一個位址，且是依連線順序 第一優先參考的 q 值為依據，依次按各位址的 q 值作選擇，當一次比對完 一個位址，且比對成功，未被排除，即可發出連線請求，若成功連線，就 不須再進行其餘位址的比對處理，所以，只要受話者所在的位址是在 q 值 較大的位址，則循序比對法所須比對的位址數將會少於 RFC 3841 所比對 的位址數，如此，在處理所需的時間上，因為比對的位址數減少了，所以 整體的處理位址的時間將會縮短；而系統處理比對位址所花費的效能也會
因比對位址的減少而減少，因此，若受話者只要不是沒在其所有位址旁， 或是在最小 q 值位址，則循序比對法相對於 RFC 3841 Caller Preferences for SIP 的比對法所須的處理時間及系統處理效能都花費的較少。
若以循序比對法應用在第 2.3.1 節所提到的範例上，首先排序出受話 者連絡位址的 q 值順序：
1. q=0.5;Contact: sip:[email protected]
2. q=0.3;Contact: sip:[email protected];audio;actor="msg-taker"; methods="INVITE";video
3. q=0.2;Contact:sip:[email protected];audio;video;methods="INVITE ,BYE"
4. q=0.2;Contact:sip:[email protected];audio="FALSE";methods="IN VITE";actor="msg-taker"
5. q=0.2;Contact:sip:[email protected];audio;methods="INVITE,OPTI ONS" 因此將 q 值最大的位址 u5 優先送入處理比對程序，發現該位址無提供能力 參數可供比對，所以直接發出連線請求，若受話者接聽則完成連線，無須 進行其餘程序，若無接聽，則繼續按排序出 q 值順序的位址作比對處理， 因此接著是將 u3 作比對處理，發現與 Reject-Contact 的項目相符合，所以 u3 被排除，無須發出連線請求，剩餘的三個位址-u1、u2、u4 因為其 q 值 皆相同，將會一起作比對處理，其中 u2 會因不具備 audio 的特性而被排除， 剩下 u1、u4 計算得分及 Qa 值，得到 Qa 分別是 u1:0.83、u4:0.5，所以將會 先對 u1 發出連線請求，若無接聽才繼續對 u4 發出連線請求。從以上的作 法 可 以 發 現 得 出 位 址 順 序 的 結 果 與 RFC 3841 比 對 法 是 相 同 的 ， u5->u1->u4，不同的是，循序比對法在每得出一個成功比對的結果時，便 會發出連線請求，若成功便不須進行餘下 q 值較小位址的比對及連線程 序，可以節省時間與系統處理的效能。
3.2 管線式比對法(Pipelined Matching)
循序比對法雖然能夠節省時間與系統效能，但必須不是在最差情形 時，最差情形就是在最小 q 值的位址才完成連線，所需要的時間與處理的 位址數就會與 RFC 3841 Caller Preferences for SIP 相當，因此，我們提出第
二種方法，稱為「管線式比對法」，由循序比對法改進而來，加入 pipeline 的觀念，也就是在等待連線的時間同步處理位址的比對，一開始在送出最 大 q 值的位址進入處理後，若比對成功，那麼在等待連線請求的時間，同 步處理按 q 值順序排列的位址，當前一個連線請求未成功時，就繼續對剛 剛在等待連線時成功比對的位址發出連線請求，直到完成連線為止，或是 全部的位址都已處理完，且發出連線請求過，同樣地，若遇到無帶有任何 能力參數可供比對的位址，在無 q 值與該位址重複時，是認定為比對成功； 若是有重複 q 值位址時，則其 Qa 值為 1。整體步驟如下(如圖 3.2)： STEP 1.選擇 contacts 中 q 值最大者(相同時則一起處理) STEP 2.按 RFC3841 中 matching 的方法處理篩選 contacts
STEP 3.若成功 match，在等待連線的時間，同步處理按 q 值順序 排列的位址 STEP 4.若成功連線即結束，否則續連按 q 值大小成功比對的位址 管線式比對法相較於循序比對法，便是在等待連線的時間，會同步處理位 址的比對，其優點就是能夠節省整體的時間，而且即使是在最差的情形， 也就是在 q 值最小的位址才完成連線，還是比循序比對法或 RFC 3841 Caller Preferences for SIP 的比對法所需的時間來的少，原因就在於利用連 線等待的時間處理位址的比對，而也因為如此，在於系統的處理效能上便 無法節省許多，因為不像是循序比對法，處理比對一個位址成功才請求連 線一次，而是會預先作好比對的程序，排好順序等待連線，所以若是相同 的受話者，整體所需的時間會較 RFC 3841 Caller Preferences for SIP 比對法 及循序比對法來的少，但對於系統處理所需效能上則可能無法減少。
圖 3.2 管線式比對法流程圖
若以管線式比對法應用在第二章的例子上，首先將受話者的所有連絡 位址按照 q 值大小順序排列好，如下所示：
1.q=0.5;Contact: sip:[email protected]
2.q=0.3;Contact: sip:[email protected];audio;actor="msg-taker"; methods="INVITE";video
3.q=0.2;Contact:sip:[email protected];audio;video;methods="INVITE,BYE" 4.q=0.2;Contact:sip:[email protected];audio="FALSE";methods="INVITE";a
ctor="msg-taker"
接著就將 q 值最大的 u5 送入比對程序，但 u5 位址並無帶有任何能力參數 可進行比對，又是無其他位址 q 值與其相同，因此比對成功，進行連線請 求，在等待連線的時間，同步處理比對程序，接著是 u3 進入比對處理， 發現與 Reject-contact 的所有項目相符合，於是 u3 遭到排除，若 u5 的連線 請求此時成功，則無須再進行剩餘工作，若還是在等待連線中，就處理比 對位址的程序，接著是剩餘的三個相同 q 值的位址，處理情形同循序比對 法，u2 將遭到排除，而 u1 得到 Qa 值為 0.83，u4 得到 Qa 值為 0.5，若此 時 u5 的連線請求成功，則無須進行剩餘工作，若連線未成功，則接著按 得出的連線順序，對 u1 發出連線請求，成功即完成連線，否則接著對 u4 出連線請求。綜觀上述管線式比對法的應用，可以發現與 RFC 3841 及循 序比對法得到結果的順序是一樣的，u5->u1->u4，但其差別在於會用等待 連線時間處理比對位址，因此相較於之前的兩種方法，整體所花費的時間 會較少。
第四章 效能評估 在 RFC 3841 的比對法中，需要對受話者的所有連絡位址都要作處理， 即假設受話者有 n 個連絡位址，就要將 n 個位址一起送進處理，而在循序 比對法中，一次只處理一個，因此最好的情況是第一個即完成比對，並完 成連線，如此將能節省最多的時間與系統處理效能，因為第一個 q 值最大 的位址即完成連線，則剩餘的位址就不必作比對處理，也不須再發出連線 請求，而最差情形則是到最後一個受話者的位址才完成連線或是皆無 match 時，按各位址原 q 值大小排順序發出連線請求，這樣子所花的時間 應與原 RFC 3841 的方法相當，因為比對的方法相同，差別在於一次作一 個或是全部的位址；在管線式比對法，最佳的情形也是第一個位址即完成 比對，且連線成功，如此也是會節省最多的時間與系統處理效能，而最差 情況亦是最後一個位址才完成連線或皆無 matching 時，但即使是最差情形 所花費的時間都會比原方法所來的少，原因就在於會利用在完成比對，請 求連線的等待時間，同步作其餘的位址比對工作，故即使是出現最差的情 況，所需的時間依舊會比 RFC 3841 的比對法及循序比對法較少。 圖 4.1 三種方法所需時間的比較
三種方法的所需時間表呈現在圖 4.1，其中在 RFC 3841 上，tn 表示所 有的受話者的連結位址送入作比對的時間，T 則是請求連線時的等待時 間；在循序比對法上， 表示為一個位址送進處理作比對所需的時間，T 則也是請求連線時的等待時間；另外在管線式比對法上， 亦是處理一個 位址的時間，T 為等待連線的時間，可以看到假設 q 值為最大的受話者位 址經過比對後，成功通過，且完成連線，在圖中即是第一個 T 的連線完成 工作，可以明顯看到循序比對法與管線式比對法皆明顯優於原本的作法， 原因就在於原先作法需要先處理完所有的受話端位址，花的時間為 tn，而 改良的兩種方法，對於第一次發出連線請求時，只需先花費處理一個位址 的時間 ，當然會優於 RFC3841 的作法；而要是在排定順序後的最後一個 連線，也就是第三次連線請求才成功的話，可以看出 RFC3841 與單一位址 處理法應該是一樣的時間，而管線式位址比對法因為會利用前兩次發出連 線請求等待的時間處理位址的比對，因此所花費的時間會少於前兩個方 法。 1 t 1 t 1 t
4.1 位址比對方法分析
如表 4.1，針對三種方法在比對位址的處理方法上，比較各步驟的不 同處，以及各方法的優缺點。
表 4.1 三種位址比對方法的特性比較 處理方法
性質 RFC3841 Sequential Matching Pipelined Matching
處理位址方式 一次處理全部 的受話者位址 一次處理一個位址 一次處理一個位址，但在發出連 線請求的等待時間時，同步處理 剩餘位址 對於各位址的 q 值 處理位址時並 不考慮 依序選擇較大 q 值的位址 進入比對處理 依序選擇較大 q 值的位址進入 比對處理 決定連線順序 以 target set 中 位址的 q 值為 優先參考值，相 同時才比較 Qa 值 無連線順序參考值，因在 處理比對程序時已先篩 選，但若 q 值相同，則以 Qa 值為依據 無連線順序參考值，因在處理比 對程序時已先篩選，但若 q 值相 同，則以 Qa 值為依據 等待連線時 idle idle 同步作比對位址的程序 優點 只要是在最後一個位址(q 值最小的位址)前完成連 線，必能降低系統處理與 減少連線等待時間 在最好(q 值最大的位址即完成 連線)與最差的情形(q 值最小的 位址完成連線)所花費的時間皆 少於原方法 缺點 一次處理完所 有位址較耗費 時間，且耗費系 統處理效能 無運用發出連線請求的等 待時間作其他事項 若不在最大 q 值的位址即完成 連線，則所需的系統處理時間與 RFC3841 相同 4.2 位址比對數量分析 假設受話者有 n 個連絡位址，且受話者在 n 個位址的機率皆相同，即 1 n，且各位址的 q 值亦無重複，在以處理比對位址的數目為觀點上來看，
RFC 3841 Caller Preferences for SIP 的比對法不論是在哪種情形下，最差、 平均或最佳情形下，所須作的比對位址數皆為 n 個，而在循序比對法中， 最差情形所須處理比對的位址數亦為 n 個；平均的情形下，需要處理比對 的位址數目假設為 N，則 N= 1 n i i n =
∑
= 1 2 n+ ，相較於 n，n- 1 2 n+ = 1 2 n− ，也就 是約節省所須處理比對位址數的一半；如果是在最佳情形的話，則只須處理比對一個位址即可，如此則節省(n-1)個比對的位址數。 表 4.2 RFC3841 與循序比對法處理位址的數量比較 Matching method RFC 3841 Sequential matching Improvement Case Worst case n n 0 n 1 2 n+ 1 2 n− Average case Best case n 1 n-1 在假設條件中，若 q 值有重複時，循序比對法並不會因位址有 q 值的重複， 而影響比對位址的數量，因為當有位址的 q 值重複時，其步驟是將同 q 值 的位址一起送進比對處理程序，會影響到的是一次處理幾個位址的數量， 對於整體的位址處理數量則不會有改變。 4.3 位址比對時間分析 假設一次處理一個位址的時間為 t，則一次處理兩個以上位址時，考 慮需要多增加運算 Qa 值，以及因為在相同 q 值下，需要作 Qa 值的比較以 決定連線位址的順序，因此將其假設為 rt ，即一次處理兩個以上的位址 時，一個位址的處理時間為 rt，以下分別從 Worst-Case、Average-Case、 Best-Case 三種情形下，分析比較在 RFC3841 比對法與循序比對法及管線式 比對法的位址比對時間。 4.3.1 循序比對法的位址比對時間分析 受話者各位址的 q 值是否有重複，只有影響到循序比對法，RFC 3841 的比對法則不會因 q 值是否有重複而影響到一次須處理的位址數，當 q 值 重複時，即至少有兩個位址的 q 值為相同，RFC 3841 的位址比對法在各種 情形下，所需的比對時間皆為 nrt，而循序比對法在 Worst-Case 的比對時 間亦為 nrt，即所有位址的 q 值皆相同，而 Best-Case 則是 t 時間，剛好在
第一個最大 q 值的位址且無重複情形下比對成功，且完成連線，而 Average-Case 則要考慮受話者的位址數與 q 值的重複個數，若在受話者端 為二個位址時，如下圖 5.2 所示，q 值重複的情形只有兩個位址皆相同或 著是互不同，q 值不同時，平均比對時間為 1 1 2t 2t ⎛ + ⎞ ⎜ ⎝ ⎠⎟，q 值皆相同時，平 均 比 對 時 間 為 2 2rt ， 因 此 在 兩 個 位 址 時 的 平 均 比 對 時 間 即 為 1 1 1 2 2 2t 2t 2rt ⎡⎛ + ⎞+ ⎤ ⎜ ⎟ ⎢⎝ ⎠ ⎥ ⎣ ⎦，可化簡為 1 1 2t+2rt，而在第一個位址即完成連線的平均 比對時間為1
(
2)
2 t+ rt 。 圖 4.2 二個位址數的 q 值重複情形 三個位址時，如下圖 5.3 所示，q 值的重複情形有四種不同，顏色相 同的裝置代表有相同的 q 值，在第一種情形為 q 值皆不相同時，其平均比 對時間為1 1 1 3t+3t+ t3 ，第二、三種是位址內皆為二個 q 值相同，另一個不 同，平均比對時間即為2 1 3rt+3t，第四種情形為三個位址的 q 值皆相同時， 平均比對時間即是3 3rt，因此在受話者位址數為三個時，其平均比對時間 為1 1 1 1 2 2 1 3 4 3t 3t 3t 3rt 3t 3rt ⎧⎛ + + ⎞+ ×⎡ + ⎤+ ⎫ ⎨⎜ ⎟ ⎢ ⎥ ⎬ ⎝ ⎠ ⎣ ⎦ ⎩ ⎭，可化簡為 5 7 12t+12rt，而在第一個 位址即完成連線的平均比對時間為1(
2 3)
4 t+ rt+ +t rt ，可化簡為(
)
1 2 5 4 t+ rt 。圖 4.3 三個位址數的 q 值重複情形 當位址數為四個時，如下圖 4.4，會因為 q 值的重複情形而有八種不 同組合，其平均 比對時間為： 1 1 1 1 1 2 1 1 2 2 3 1 4 3 2 8 4t 4t 4t 4t 4rt 4t 4t 4rt 4rt 4rt 4t 4rt ⎧⎛ + + + ⎞+ ×⎡ + + ⎤ ⎡+ + ⎤+ ×⎡ + + ⎫ ⎨⎜⎝ ⎟⎠ ⎢⎣ ⎥ ⎢⎦ ⎣ ⎥⎦ ⎢⎣ ⎥ ⎬ ⎩ ⎭ ⎤ ⎦ ， 可化減為 6 10 16t+16rt，而在第一個位址即完成連線的平均比對時間為
(
)
1 2 2 3 8 t+ rt+ + +t t rt+ rt+ + 4t rt ，可化簡為(
)
1 4 11 8 t+ rt 。 圖 4.4 四個位址數的 q 值重複情形 位址數為五個時，q 值的重複情形會有 16 種，六個位址數時，會有 32 種情形，以至 n 個位址時，會有2n−1種情形，計算在第一次比對後即完 成連線的平均比對時間如下： 假 設 n 個 位 址 的 q 值 重 複 情 形 為 H 種 ，n H =Hn−1+Hn−2 + +… H2+H1+1= 1 2n− ，而第一次比對後即完成連線的情形為 第一次進入比對的位址數為 1 個至最多 n 個，如圖 4.5，即是在第一筆進入 比對的資料數為 1 個、2 個至 n 個，當為 1 個位址時，其所需的比對時間 為 t，2 個位址以上為 2rt 至 nrt，因此第一次比對後即完成連線的平均比對 時 間 為
(
1 2 3(
)
1)
1 2 3 1 n n n n t H rt H rt H n rt H nrt H × − + × − + × − + +… − × + ， 即 ( ) ( ) ( )(
)
( ( ))(
1 1 2 1 3 1 1 1)
1 1 2 2 2 3 2 1 2 2 n n n n n n t rt rt n rt nrt − − − − − − − − − − × + × + × + +… − × + ， 可 化 簡 為 2(
3)
1 1 2 6 2 1 2 n n n t r − − − ⎡⎣ + × − t⎤⎦。 而 若 需 處 理 完 全 部 n 個 位 址 ， 其 單 一 位 址 平 均 比 對 時 間 則 為 圖 4.5 第一次比對即完成連線的位址分佈圖 2 3 2 4 4 n n t rt n n + + − ，因此在有重複 q 值的情形下，循序比對法處理完 n 個位址 的平均比對時間即為 2 3 2 4 4 n n t rt + + − 。 綜合上述，RFC 3841 比對法與循序比對法在各種情形下的位址比對時 間比較如下表 4.3，可以發現在 Worst-Case 時，RFC 3841 比對法與循序比 對法所需要的比對時間是相同的，在 Average-Case 與 Best-Case 中，則是 循序比對法優於 RFC 3841 比對法，且若是在平均情況下的循序比對法之 最短所需時間，其時間複雜度為 O(big O)(1)的常數時間，而原先的 RFC3841 演算法其時間複雜度則為 O(n)的線性時間，在圖 4.6，黑色線表示 RFC 3841 的位址比對法，紅色線表示循序比對法，兩者分別在 Average-Case 下，假設當 r=0.9 時，即是在有重複 q 值時，計算一個位址的時間為 0.9t， 兩種方法比對時間的比較，而藍色線表示循序比對法在第一次比對位址時 即完成連線的比對時間，圖 4.7 是在 r=1 時的比較，圖 4.8 是 r=1.5 時的比 較。 從這三張圖中可以發現在平均情形下，且有重複 q 值位址的狀況，若 循序比對法需要處理完全部 n 個位址，在 r 值大於 1 的情況下，即是處理 一個有 q 值重複的位址時間大於處理一個無 q 值重複的位址(1t)，循序比對 法皆會優於 RFC 3841 的位址比對法；而若是在第一次比對後就完成連線， 即其最少所需的比對時間是在任何情形下皆會優於 RFC 3841 的位址比對 法。 Matching
method RFC 3841 Sequential matching Improvement
Case Worst case nrt nrt 0 Process all contacts 2 3 2 4 4 n n t rt + + − 2 ( ) 1 4 n t r + + Average case nrt
(
)
2 2 1 1 2 3 2 1 2 n n n t r − − − ⎡⎣ + × − t⎤⎦ ( ) 2 1 2 3 2 1 1 2 2 n n n t r − − − + + Shortest time t Best case nrt t (nr-1)t 表 4.3 RFC3841 與循序比對法處理有 q 值重複位址的時間比較1 2 3 4 5 6 7 8 9 10 11 1 2 3 4 5 6 7 8 9 10 11 Mat c hing Time( un it t) Numbers of Contact n RFC 3841
Sequential matching on processing all contacts(average case) The shortest time of average case on Sequential matching r=0.9 圖 4.6 RFC3841 與循序比對法在 r=0.9 時的位址平均比對時間 1 2 3 4 5 6 7 8 9 10 11 1 2 3 4 5 6 7 8 9 10 11 Ma tc hi n g Tim e (u ni t t ) Numbers of Contact n RFC3841
Sequential matching on processing all contacts(average case) The shortest time of average case on Sequential matching r=1
1 2 3 4 5 6 7 8 9 10 11 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Mat c hi ng T ime(unit t ) Number of Contacts n RFC 3841
Sequential matching on processing all contacts(average case) The shortest time of average case on Sequential matching r=1.5 圖 4.8 RFC3841 與循序比對法在 r=1.5 時的位址平均比對時間 4.3.2 管線式比對法的位址比對時間分析 檢視管線式比對法的步驟，發現其與循序比對法的差別在於會利用等 待連線的時間作位址比對的工作，而其在對位址比對的方法是相同於循序 比對法的，因此管線式比對法的位址比對時間是與循序比對法相同的，其 Best-Case 亦是發生在最大 q 值的位址為一個的情形下，且連線成功，因此 只需花費一個 t 的時間，而 Worst-Case 則是發生在需處理完 n 個相同 q 值 的位址，需花費 nrt 的時間，至於平均情形亦是最少需要 2
(
2)
1 1 2 3 2 1 2 n n n t r − − − ⎡⎣ + × − t⎤⎦的 時間，而若需處理完 n 個位址，則所需的平均比對時間為 2 3 2 4 4 n n t r + + − t。 管線式比對法相較於循序比對法的優點並非在於位址比對時間上，而 是在於其會利用等待連線的時間做位址的比對工作，因此會縮短從起始至 完成連線的整體所需時間，例如在受話者有五個位址的情形下，按 q 值大 小排列如下：(u1,u2),(u3,u4),(u5)，其中相同 q 值的為同一組，且假設組別 中只有在前者為比對成功，而連線成功會在 u5 發生，按各別的比對方法 步驟，首先是第一組(u1,u2)進入比對，u1 勝出，兩種方法同時發出連線請求，同一時間，管線式比對法會繼續做第二組的比對，在 u1 無回應下就 接著與 u3 連線，於此同一時間，管線式比對法便會作第三組的比對，但 循序比對法只會等待至無回應時才接著做第二組的比對，再發出連線，無 回應，再接著比對最後一組，至完成與 u5 的連線，兩種方法的所需時間 表示如下圖 4.9，可以發現管線式比對法在第一條虛線處即可結束，而循 序比對法則要在第二條虛線處才能結束，相較之下，管線式比對法所需時 間較少，當然，這兩者的時間差異，在個人使用者的感受差別不大，但若 是在量大時，即使用者眾多時，對於系統整體所減少的時間是可觀的。 圖 4.9 管線式比對法與循序比對法的整體所需時間比較 但管線式比對法的優點也相對是它的缺點，因為會在等待連線的同一 時間作下一次的比對工作，若此次連線成功，那麼在這次連線等待時間預 先作的下個位址比對工作就是多耗費了電腦的效能，反觀循序式比對法則 無此問題，因此，在所需時間上，管線式比對法是三種方法中所費最少的， 但管線式比對法則會因為在成功連線的等待時間多作下次的位址比對工 作，所以會多耗費一些不必要的系統效能。
4.4 小結 本章提出了兩個新的位址比對演算法，分別是循序比對法及管線式比 對法，其中循序比對法改進 RFC 3841 中一次將所有受話方位址進行比對 的程序，改採以各位址的 q 值為序，一次比對一個位址，比對成功且連線 完成即不須再比對剩餘位址，較 RFC 3841 的比對法可以縮短時間及系統 效能；而管線式比對法，與循序比對法的差別在於會利用連線等待的時間 作下一個位址的比對工作，更加能節省時間，但是在該此連線為成功時， 會多作一次下個位址的比對工作，但相對於 RFC3841 與循序比對法，更能 縮短所需時間。
第五章 發話者喜好之網路電話系統在數學教育課程上的應用 除了前述理論分析外，我們建置了一套依發話者喜好為基礎之網路電 話的應用系統雛形，藉以說明在數學教育課程上面的應用，5.1 節將會對 此課程系統作個簡介，5.2 節是介紹會運用到的相關技術與概念-Click to Dial 技術與概念關聯架構[17]，5.3 節則是介紹此數學課程系統的組成、架 構與操作，5.4 節則是建置此課程系統的問題與討論。 5.1 數學學習線上諮詢系統簡介 這套系統主要是應用在課後輔導上，提供一個網路平台讓修課的學生 可以即時線上討論，或是學生可以詢問線上助教，甚至是直接與老師對 談，老師、助教也可以透過直接對話問答以掌握學生的學習狀況，此外， 還將概念關聯應用於發話者喜好的條件上，藉由附帶條件在詢問的問題 上，系統再選擇至適當的助教受話端。 此課程系統雛形是將概念關聯結合發話者的喜好條件，以網路電話應 用在課程系統上，主要是讓修習課程的學生能夠各方便的與助教、老師及 共同修課的學生聯繫，只需使用網頁瀏覽器及客戶端的即時通訊軟體，即 可隨時隨地連上此課程系統，以簡易滑鼠點選的方式達到與對方連絡，不 論是與同學討論作業報告，或是與助教、老師商討問題，只要點選該門課 列出的名單即可達成網路電話的通訊，此外，在詢問助教問題方面，便是 將概念關聯應用在問題的難度等級上，讓問題之間有相關性，藉以讓系統 決定哪些問題該被優先回答，再接著其餘較深入的問題，讓學生能夠更加 的清楚了解此課程。 而為了達到在網頁上容易的以滑鼠點選完成通話目的，因此我們將在 下一節介紹 click-to-dial 技術，並且描述概念關聯的觀念以應用於發話者喜 好的條件上。
5.2 概念關聯架構與 Click-to-Dial 技術 5.2.1 概念關聯架構 在國小數學中，各章節的數學概念是有相關聯的，概念與概念之間的 關聯，稱為概念關聯[17]，而國小數學各章節概念間的關係可以使用樹狀 結構作呈現，如圖 5.1，標示十二個節點，分別代表國小數學十二冊，其 間的關係為在上層的母節點表示為較複雜的數學概念，而其子節點即為母 節點所須具備的基本數學概念，因此他們的關係便是能夠認知該節點之子 節點的數學概念，才有可能完成認知其母節點的數學概念，例如在圖 5.1 中，若要能成功認知 C9 的數學概念，便要先成功知 C11 與 C12 的數學概 念，但並非具備了 C11 與 C12 的數學概念，就能成功認知 C9。 圖 5.1 概念關聯圖[17] 我們將此概念應用於以發話者喜好為基礎的網路電話系統上，藉由關聯的 先後順序概念，將學生的問題也按此例分序，當偵測到關鍵字 C1 至 C12 後，再按照助教的分群，選出負責需先認知了解問題集的助教，再列出負 責較複雜問題的助教，供學生詢問，由淺入深，增進學習效率。
5.2.2 Click-to-Dial 技術
為了要讓架構在網頁上的系統達到方便、直覺操作為主，我們採用 Click-to-Dial 的技術，這是一項重要的功能，Click-to-Dial 的作用是在網頁 上點選想對話的使用者，即可連線通話，而 Click-to-Dial 的功能則可以運 用 SIP 下的 REFER[12]方法達成的，如下圖 5.2，
圖 5.2 Call flow of click-to-dial
舉例說明，當 John 在電腦上瀏覽網頁時，按下連結想與 Mary 進行通話時， 一般實作上，瀏覽器是以 javascript 程式模擬 REFER 方法將 Mary 的 SIP 位址送給在該電腦上 John 的 SIP UAC，待同意之後，便會由 John 的 UAS 發出 INVITE 給 Mary，請求通話，這便是 click to dial 的一個完整流程， 如此一來，此課程系統便可結合伺服器端語言與資料庫等在網頁上即可完 成通話過程，便不需要想到要與修課學生進行語音通話時，再鍵入其通話 位址，嘗試連線通話。
5.3 數學學習線上諮詢系統組成與操作
這個系統是採用 iptel.org 所開發的 SER(SIP Express Router)[14]與 SERWeb 軟體，再配合 client 端的 X-lite 即時通訊軟體以及後端的 MySQL
資料庫組成，SER 是一套符合 RFC 3261 的 SIP server，包含 registrar，proxy server 與 redirect server，支援多種作業系統平台，如 Linux、BSD、Solaris 等，且是開放原始碼，模組化設計介面，相當地有彈性打造成各自需要的 使用面向，此外，是使用 C 語言撰寫而成，因此在各個平台上皆擁有良好 的執行效率；而 SERWeb 則是 SER 的一個網頁管理介面程式，用 PHP 語 言撰寫，因此相容於各種標準的網頁瀏覽器，且其設計為模組化，我們可 以很容易的修改或增刪各項功能，以符合我們的需求。 圖 5.3 線上諮詢系統架構圖 整個課程系統的架構如圖 5.3 所示，在網路電話主機 SER 的運作環境 下，使用者可藉由 SERweb 的網頁介面操縱管理在 SER 資料庫上的帳號基 本資訊、電話簿、發送文字訊息…等，還可以由 SERweb 上點擊撥號透過 X-lite 等 client 端通訊軟體直接連絡受話者，而我們主要的改變在 SERweb 上，將其修改成適合課程名單與修課學生的架構，依每個登入帳號的不 同，便會按身份而顯示不同的資訊，例如是以學生的身份登入，如圖 5.6， 便會先顯示該位學生是修哪些課程，再點入該課程時，才會顯現出修習此 課的學生與課程助教，在最左邊顯示姓名，接著是他們的 SIP address，再 來是顯示他們的狀態、課程名稱，若狀態是顯示在線的話，便可點選他的 SIP address 進行通話，而若是老師身份的話，一登入，是顯示該老師教授 哪幾門課，再點入時才是該課程的學生與助教名單，助教身份也是相同， 此外，在顯示的名單上，還會標明每個人是否在線上，若顯示 online，便
可直接點選嘗試通話，以作課程相關討論。 此外，在欲點選受話者時，還可以結合一些喜好條件以作選擇，操作 流程如圖 5.4，例如修課學生想要詢問課程上的問題時，但不知該詢問哪 位助教，可以在問題列上輸入欲問的題目，系統在分析比對後，即可按照 概念關聯架構，如圖 5.8，依問題的程度分別列出負責的助教，以供點選 進行通話，達成依發話者喜好選擇受話端。 圖 5.4 學生於線上諮詢系統操作流程圖 以下介紹 SERWeb 的實作部份，SERWeb 是由 PHP 程式撰寫而成的使 用者網頁介面軟體，需配合 SER 網路電話伺服器使用，提供 SER 的管理 者及使用者一個方便的操作環境，其採模組化設計，在一般使用者方面， 計有十項功能，例如帳號資訊、電話簿、傳送文字訊息等，且其程式架構 上，將各項功能的主程式、顯示畫面、各文字訊息、抓取資料庫等皆為分
開撰寫。
而我們所作的數學學習線上諮詢系統，主要是修改其電話簿的功能 (phonebook.php)，增加三個新的模組：course_list.php、course_students.php 與 test_question.php，首先是在 ser 的資料庫中新增一資料表 course_list， 記載各使用者修習哪些課程，因此在使用者點選課程功能進入頁面時，便 是一個新的模組，由程式讀取該使用者在 course_list 資料表內的修課資 訊；在點選課程名稱進入修課名單時，又是一個新模組，根據原本的電話 簿資料表修改而成，新增加三個欄位，分別為 course_name、course_id 與 question，其中 course_name 記載課程的名稱，course_id 記錄課程的編號， 而 question 欄位則是記載概念關聯問題的分類；最後一個新增的模組則是 運用在學生詢問問題時，分析比對問題的關鍵字，之後到資料庫中，比對 助教的 question 欄位，符合的助教便輸出到瀏覽器畫面上供使用者點選通 話，在其程式邏輯判斷上，是在 test_question 模組的主程式裡加上所需的 關鍵字比對程式碼，這裡是只針對 C1 至 C12 的關鍵字作判斷，將 C1 至 C6 分為一群, C7 至 C12 為另一群，當偵測到問題中有符合的關鍵字，便 到資料表中將符合的助教人選輸出。 圖 5.5 數學學習線上諮詢系統登入畫面
圖 5.6 學生修課科目
5.4 問題與討論
在建置此課程系統上，因為是由多個系統組合而成的，包括 SER 網路 電話系統、SERweb 網頁介面管理程式、供 SER 使用的 MySQL 資料庫以 及所需要的網頁伺服器、PHP 運作環境、資料庫管理介面程式等，因此在 過程上，遭遇許多問題，例如各程式間的相容性，不只是程式間的相容， 還有各程式與作業系統的相容，此外，最主要是在修改 SERweb 的程式， 以符合課程系統的呈現方式，包含對應的資料庫表格該如何設計及增刪， 以及如何將概念關聯應用於發話者條件上，經由系統整合與程式的撰寫、 修改後，我們完成此一雛形課程系統，使得學生能夠隨時透過瀏覽器在網 頁介面上即可與同學語音討論，並能在線上發問問題，即時獲得負責的助 教解答。 當然，此課程系統尚有不足處，例如現在是以網頁點選式發出通話， 在與首位助教聯繫後，需自行點選下一位助教，非常地不方便，如果可以 在發問問題後直接連至負責的助教處，並在此問題解決後，自動轉接至下 一位負責關聯問題的助教，將提昇系統使用的便利性；此外在概念關聯上 的應用，目前只是以此觀念套用在各課程上，尚未詳細將各課程內容的問 題作出相對應的概念關聯架構，因此未來的工作便是能精確的將各課程的 概念關聯應用於發話者條件，藉以分析問題，選擇至適當助教，甚至是以 各課程的相關內容關鍵詞去作對應不同的負責助教等；而在選擇助教上， 若能將助教以組別區分將有利於學生尋找負責該問題之助教，組別是指單 一助教帳號對映到多位不同助教，這樣一來，只需有組別其中的助教在 線，即可讓學生詢問，也可以在因應發話者喜好選擇受話端時，不會有多 位助教同時負責同一概念的問題，只需顯示由該組的助教帳號負責即可。
第六章 結論
RFC 3841 Caller Preferences for the SIP 中的比對法，因為其一次需要 比對完所有受話者的位址，是需要花費較多的時間與系統處理效能，所以 我們提出循序比對法以及管線式比對法加以改進，循序比對法的最佳情形 所需的時間及系統處理效能一定比 RFC3841 的方法少，因為在最佳情形 下，只需處理一個位址的比對後，即完成與受話方通話，而在平均情形下， 其最短所需時間，即是在第一次比對位址後即完成通話，必少於原比對 法，若需處理完全部 n 個位址數，其在 r 值大於 1 的情況下，即是處理一 個有 q 值重複的位址時間大於處理一個無 q 值重複的位址(1t)，循序比對法 皆會優於 RFC 3841 的位址比對法，此外，在最差狀況下，也與 RFC 3841 的比對方法所需的時間相當，而管線式比對法，不論是最佳情形或最差情 形所需的時間皆比原本方法以及循序比對法較少，因為管線式比對法會利 用連線等待時間做比對位址的處理，雖然在位址比對上的時間與循序式相 同，但卻可以縮短整體所需的時間，由上述分析比對下，在依發話者的喜 好選擇受話端，循序比對法及管線式比對法是較優於 RFC 3841 的位址比 對演算法。 而在依發話者喜好為基礎之網路電話的數學學學習線上諮詢系統，可藉由 此一網頁介面的平台，使得老師、助教、學生能夠更加便利的討論課程相 關問題，也能藉著應用概念關聯的架構於附帶發話者的喜好條件，使得學 生發問問題時，選擇適當的助教即時通話，循序解答問題，加強學習效果， 而系統建構在此尚為雛形，未來將研究能夠結合更加多樣化的顯示狀態， 讓各使用者在課程名單上能即時的顯示多種現況，不再只是單純的在線或 是不在線，以便引發各使用者間的更多互動；此外，在未來的發話者附加 之喜好條件上，能夠再更加精確，對應各課程的概念關聯架構圖，甚至可 以根據使用者的狀態等多種條件選擇加諸於學習諮詢系統的應用。
參考文獻
[1] Dongmei Jiang, Tet Hin Yeap, Liscano R. and Logrippo, L., “Two Approaches for Advanced Presence Services in SIP Communications,” 13th IEEE International Conference on Networks, 2005. Jointly held with the 2005 IEEE 7th Malaysia International Conference on Communication, Vol.1, No.52.
[2] Dorgham Sisalem and Jiri Kuthan, SIP Tutorial at http://www.iptel.org/files/sip_tutorial.pdf
[3] Dersingh, A., Liscano R. and Jost, A., “Managing Access Control for Presence-based Services,” Proceedings of the 3rd Annual of Communication Networks and Services Research Conference, pp.105-111, 2005.
[4] Dongmei Jiang, Tet Hin Yeap, Logrippo, L. and Liscano, R., “Personalization for SIP Multimedia Communications with Presence,” Proceedings of ICSSSM '05, Vol.2, pp.1365-1368, June 2005.
[5] Henning Schulzrinne, “The SIMPLE Presence and Event Architecture,” First International Conference on Communication System Software and Middleware, pp.1-9, Jan 2006.
[6] J. Rosenberg et al., “SIP: Session Initiation Protocol,” RFC 3261, IETF, June 2002
[7] J. Rosenberg, H. Schulzrinne and P. Kyzivat, “Indicating User Agent Capabilities in the Session Initiation Protocol (SIP),” RFC 3840, IETF, August 2004.
[8] J. Rosenberg, H. Schulzrinne and P. Kyzivat, “Caller Preferences for the Session Initiation Protocol (SIP),” RFC 3841, IETF, August 2004.
[9] J. Rosenberg, P. Kyzivat, “Guidelines for Usage of the Session Initiation Protocol (SIP) Caller Preferences Extension,” RFC 4596, IETF, July 2006.
[10] J. Lennox, X. Wu, H. Schulzrinne, “Call Processing Language (CPL):A language for User Control of Internet Telephony Services”, RFC3880, IETF, October 2004.
[11] Marcin Dzieweczynski , “Implementation of Caller Preferences in Session Initiation Protocol (SIP),” Master Thesis, Information Networks Division at Linköping Institute of Technology, March 2004.
[12] R. Sparks, “The Session Initiation Protocol (SIP) Refer Method,” RFC 3515, IETF, April 2003.
[13] Samir Chatterjee, T. Abhichandrini, Haiqing Li, Bengisu Tulu and Jongbok Byun, “Instant Messaging and Presence Technologies for College Campuses,” IEEE Network, Vol.19, No.3, pp.4-13, July-August 2005.
[15] Wolfgang Kellerer, Matthias Wagner, Wolf-Tilo Balke and Henning Schulzrinne,
“Special Issue on Mobile Multimedia Communications Preference-based session management for IP-based mobile multimedia signaling,” European Transactions on Telecommunications, Vol.15, pp.415-427, 2004.
[16] Østhus, E.C, “Presence and call screening in VoIP,” Project Assignment, NTNU, Norwegian , December 2004.
[17] 郭冠廷，2006，電腦適性化測驗雛型系統之研究，中興大學資訊科學
