Design and Implementation of Early Media Mechanism based on Session Initiation Protocol

全文

(1)Design and Implementation of Early Media Mechanism based on Session Initiation Protocol Chun-Yuan Huang, Heng-Te Chu, Wen-Shiung Chen, Yi-Hung Huang1 and Lili Hsieh2 1. VIP-CCLab., Dept. of Electrical Engineering, National Chi Nan University Dept. of Information Networking Technology, Hsiuping Institute of Technology 2 Dept. of Information Management, Hsiuping Institute of Technology Correspondence: [email protected]. 摘要網路電話除了應該提供良好的通話品質外，還必須擁有多元化的應用服務才能吸引更多的客戶群。本論文所提出的 Vivid Ring Service 就是一種可以隨使用者的喜好指定特殊之圖片、聲音或影像替代原本呆板的回鈴聲（Ring-back Tone）之個性化應用服務。為了實現 Vivid Ring Service，本論文設計了五種架構於 SIP 協定之預前媒體（Early Media）傳送機制。在論文中不僅針對 RFC 3959 所提出的 Early Session 機制作優缺點之比較，最後還使用 Early Media 機制實作 Vivid Ring Service，藉此證實此機制之可行性，並且利用此機制達成語音出席（Voice Presence）之功效。關鍵詞：會議初始協定、會議描述協定、網際網路電話、預前媒體、個性化應用服務、語音出席。. Abstract In addition to providing good communication quality, Internet telephony service must possess a variety of add-on application services in order to attract more and more users. In this paper, we propose a new personalized service, called “Vivid Ring Service,” which can allow users to customize and replace the conventional and dull ring-back tone with personal favorite pictures, audios, or videos. To realize the “Vivid Ring Service,” we design five mechanisms, based on the early media scheme of SIP protocol. In addition to comparing the pros and cons of the early session schemes proposed by RFC 3959, we eventually utilize the early media schemes to implement the Vivid Ring Service, to demonstrate the feasibility of early media, and to accomplish the effects of “Voice Presence.” Keywords: VoIP, SIP, Vivid Ring Service, Early Media, Ring-back Tone, Voice Presence.. 1. 前言無論在傳統的公眾交換電話網路（ Public Switched Telephone Network，PSTN）或是在行動電. 話系統網路（例如：GSM、GPRS、3G…）之中，當使用者拿起話筒撥出電話號碼之後，在對方應答之前，使用者皆可在話筒中聽到由 Dual-Tone Multi-Frequency（DTMF）兩種頻率（一般為 440Hz 與 480Hz）所組成單一音調的音訊（例如：”嘟 … 嘟 …”），就是所謂的回鈴聲（Ring-back Tone）。但是隨著時代的變遷，單調的 Ring-back Tone 卻無法滿足新世代使用者多元化的需求，他們更希望可以依個人喜好的音樂去變更自己的回鈴聲。在 VoIP [1]的網路中，由於所傳輸的資訊不再侷限於只是單純的聲音，而是各式各樣的多媒體資訊。於是本論文針對 VoIP 的特性提出一套符合於網路電話的新服務，並命名為『Vivid Ring』。 Vivid Ring Service 是一種可以隨使用者喜好去變更 Ring-back Tone 的服務。Vivid Ring 不僅可以將 Ring-back Tone 變成了美妙的音樂，只要對方的 SIP 話機有支援螢幕顯示，還可以自錄一段影片或自己的照片來代替 Ring-back Tone。除此之外，使用者也可以利用 SIP UA 所內建之電話簿來針對不同的發話者啟動不同的 Ring-back Tone 設定。使用者甚至可以在 SIP 話機上設定話機的狀態模式，例如：使用者正好準備去開會，在開會前使用者可以將話機設定為開會模式，此後只要有朋友撥打電話進來，他們所聽到的 Ring-back Tone 將轉變為，『我現在正在開會中，如有要事請稍後再 Call 我！』，如此一來將可以利用 Vivid Ring 輕易達成語音出席（Voice Presence）的功效。為了實現 Vivid Ring Service，本論文設計了五種架構於 SIP [1][6][12]之 Early Media [4]傳輸機制，並且針對此五種傳輸機制與 RFC 3959 [4]所提出的 Early Media 架構的差異性與優缺點做比較。最後使用 Java 程式語言搭配 Early Media 傳輸機制來實作軟體 SIP 網路電話，藉由本實驗所實作之軟體 SIP 網路電話與 SIP Express Router （SER）[11][15] 的實際互相運作，並且透過 Ethereal [2] 擷取封包，證明 Vivid Ring Service 的可行性。. 2. Early Media 機制之設計與實現 2.1 Early Media.

(2) 在 SIP 的網路下，一個 Session 的建立需要經由發話方（Caller）發送一個附帶有 SDP [13]訊息的 INVITE Request 給受話方（Callee），當受話方的使用者拿起電話時，受話方的話機才會回傳一個附帶有 SDP 訊息的 200 OK Response 給發話方，接著發話方收到 200 OK Response 後馬上送出一個 ACK Request 給受話方，於是一個 Session 的建立就此大功告成。像這樣一個經由 Three-way handshake 的動作並且在受話方回應後所建立而成的 Session 被稱為『Regular Session』。而在發話方送出 INVITE 之後直到受話方拿起話筒的這段時間內，如圖 1 所示，雙方所交換的聲音（audio）或影像（video）全都稱之為 Early Media，而這些聲音與影像所組成之 RTP Stream 則被稱為『Early Session』。. 圖 2 Scheme 1 for Vivid Ring Service.. 2.2.2 Scheme 2 如圖 3，架構二的方法相當類似架構一，不同的是，這次在 180 Ringing Response 的 Message body 並不需要附帶任何檔案，可以空白或者是直接攜帶回應 SDP offer [8]的 SDP answer，只需要在 Header 裡面增加一行 Alert-Info header，並且在欄位裡面填上一段 HTTP 網址，等到發話端接收到 180 Ringing Response 之後，它就可以自己去網址所指定的位址以 HTTP 的 GET 方法取得作為 Ring-back Tone 的檔案來播放，之後恢復通話的流程與架構一相同。. 圖 1 Early Media.. 2.2 Early Media for Vivid Ring Service 本論文為了在 SIP UA 上實現 Vivid Ring Service，設計了五種 Early Media 傳輸機制，以下幾個小節將分別針對此五種傳輸機制做一個詳細的說明。. 圖 3 Scheme 2 for Vivid Ring Service.. 2.2.1 Scheme 1. 2.2.3 Scheme 3. 圖 2 表示兩台話機在架構一模式的訊號流程圖。首先發話方會傳送一個 INVITE Request 給受話方要求建立通話，此時如果受話方的話機有開啟 Vivid Ring Service 功能，受話方的話機會回送一個在 Message body 裡夾帶有檔案的 180 Ringing Response 給發話方。這個夾帶的檔案可以是圖片檔、音樂檔或者是影片檔。除此之外，這個 Response 還利用 Content-Type header 告之發話方 Message body 所附帶之檔案的格式，並且以 Content-Disposition header 註明此檔案是為了作為 Alert 而使用，如此一來發話方將可聽到或看到不同形式的 Ring-back Tone。當受話方的使用者拿起話筒的時候，受話方的話機才會送出附帶有 SDP answer [8]的 200 OK Response，發話方收到 200 OK Response 並發出 ACK 之後即可恢復正常通話。. 如圖 4，架構三是一種非常類似 Third Party Call Control （ 3PCC ） [10] 的作法，當受話端收到了 INVITE Request 與 SDP offer1 之後，受話方的主機會複製一份 SDP offer1，並且將 Origin 欄位從 o = caller 123456 123456 IN IP4 caller.ua 修改為 o = callee 567890 567890 IN IP4 callee.ua，最候將修改完畢的 SDP 當成 SDP offer1`夾帶在 INVITE Request 裡面傳送給 Media Server，當 Media Server 從 SDP offer1`挑選完可接受的多媒體形式、RTP 傳輸編碼格式與傳輸協定，接著新增一行 a = sendonly 表示不接受接收方向的 RTP Stream 之後，Media Server 立即使用 200 OK Response 回傳 SDP answer1`給受話方。收到 SDP answer1`的受話方如同剛剛處理 SDP offer1 一般，拷貝了 SDP answer1`的內容並且修改 Origin 欄位的內容之後，就將複製的 SDP answer1 夾帶在 183 Session Progress Response 裡面.

(3) 回傳給發話端。到此為止，無論是發話方、受話方或是 Media Server，三方皆已經完成了完整的 SDP 交換，Early Session 的建立也算是大功告成，只是發話方並不曉得 Session 的建立是藉由兩段 Dialog 的關係所組成，並且是直接存在於自己與 Media Server 之間，完全不經過受話方。等到受話方的使用者拿起話筒，受話方的話機會送出一個 BYE Request 給 Media Server 要求停止 RTP Stream 的傳送，同時也傳送 200 OK Response 給發話方。等到受話方收到發話方所送出的 ACK Request 之後，受話方緊接著馬上傳送一個附帶有 SDP offer2 的 INVITE Request 給受話方要求更新 Session 的內容，當雙方完成全新的 Three-way handshake 後，發話方與受話方即可恢復正常通話。圖 5 Scheme 4 for Vivid Ring Service.. 2.2.5 Scheme 5. 圖 4 Scheme 3 for Vivid Ring Service.. 2.2.4 Scheme 4. 如圖 6，架構五在發話方與受話方交換完 SDP 的 offer1 與 answer1 之後，受話方會收到 PRACK Request 並且用 200 OK Response 回應此訊息，緊接著受話方的話機會主動送出一個攜帶有 SDP offer2 的 UPDATE Request [3][9]給發話方，而這一份 SDP offer2 所攜帶的參數是為了建立 Early Session 而使用的。如果被發話方所接受，從受話方接收到對應 UPDATE Request 的 200 OK Response 那一刻開始， Early Session 也算是正式建立成功。等到受話方的使用者拿起話筒時，受話方話機傳送出 200 OK Response 並且收到 ACK Request 之後，受話方的話機只要接著傳送 INVITE Request 去跟發話方交換通話用的 SDP 內容，等完成 Three-way handshake 的動作之後，雙方即可開始通話。. 如圖 5，在架構四中，使用了一個新的 Option tag，也就是『early-session』[4]。當受話方收到 INVITE 之後，它會馬上以 183 Session Progress Response 回應發話端，並且以帶有 early-session 的 Supported header 告知發話端，受話端支援 Early Session 的機制。如果發話端認得這個 Option tag，並且支援 Early Session 機制，發話端的話機將會在 PRACK Request [7]的 Message body 裡面攜帶一份全新的 SDP，額外還加入一個帶有 early-session 的 Require header 要求與受話端建立 Early Session，於是雙方就可以此方式，藉由 PRACK Request 以及回應 PRACK 的 200 OK Response 來交換 Early Session 專用的 SDP。最後以 Re-INVITE 的方式來恢復通話。. 圖 6 Scheme 5 for Vivid Ring Service..

(4) 2.3 Early Session in RFC 3959 RFC 3959 是一份發表於 2004 年 12 月專門為 SIP Early Session 所制定的協定標準，從圖 7 可以觀察到 RFC 3959 的架構也是需要使用到 early-session 這個 Option tag 來幫忙運作，所以一開始，發話方的 INVITE Request 就攜帶一份 SDP offer，並且利用 Content-Disposition header 指明這份 SDP 的用途是為了建立 Regular Session 而使用的。除此之外，發話方也利用 Supported header 告知受話方，它支援 Early Session 這個機制，由受話方自己決定要不要啟動這項功能。於是受話方的話機利用 MIME [14] 格式將兩份 SDP 一起放進 183 Session Progress Response 的 Message body 中，並且分別加入了 Content-Disposition header 註明此段 SDP 的作用。所以當發話方收到這個 Response 之後，它就能藉由 Content-Disposition header 所附帶的資訊，將 Message body 裡面的 SDP 分別取出，並且另外使用 PRACK Request 傳送一份 SDP 做為 early-answer 給受話方。等到受話方回送對應 PRACK Request 的 200 OK Response 給發話方時，雙方之間的 Early Session 便成功的建立完成。而受話方的使用者拿起話筒時，受話方的主機便會停止傳送 Early Session 的 RTP Stream，並且在受話方收到發話方的 ACK 訊息後，雙方會依照先前所交換的另一份 SDP 自動建立起通話用的 Regular Session。. 圖 7 RFC 3959 Early Session 架構圖. 3. Early Media 於 Vivid Ring Service 實作之優缺點比較架構ㄧ中之訊息流程相當簡單，它並不需要為了 Vivid Ring Service 額外送出 Request 或 Response，只要發話方的話機能辨識 Content-Type header 裡面的 audio/wav 字串，發話方就能在撥號後聽到不同於 DTMF 的 Ring-back Tone。然而此種架構並不是完美的，因為如果受話方將含有病毒或惡意程式的檔案夾帶在 180 Ringing Response 中，發話方的話機就會有安全上的風險。除此之外，如果夾帶在 180 Ringing Response 中的檔案過於龐大，導致封包傳輸上的延遲過久，發話端的話機將. 會以為它所送出的 INVITE Request 並未被受話端所接收到，於是啟動重送機制。如果延遲超過 32 秒，則發話方的主機會認定通話建立失敗。而架構二與架構一同樣具有信令流程簡單的優點，但是為了達成 Vivid Ring Service，在架構二中需要額外有一台 Media Server 來支援這項功能。除此之外，如果 Media Server 不為具有安全認證公信力的主機，受話端也會有安全性的危機。對架構三而言，除了跟架構二一樣需要一台 Media Server 作為輔助之外，此處的 Media Server 還必須具有 SIP UA 的功能才能正常運作。另外還有另一項缺點，假如 SDP offer1 中所提供的 RTP Payload 格式全不符合 Media Server 可接受的格式，SDP answer1`裡面的媒體傳輸埠號將全為 0，此時 Vivid Ring Service 將會無法運作，而發話方也會因為無法從話筒中聽到任何聲音而誤以為通話建立失敗。但是只要受話方的主機在察覺 SDP answer1`的媒體傳輸埠號全為 0 的狀況時，改以 180 Ringing Response 代替 183 Session Progress 傳送給發話方，雙方的通話將可以如一般程序模式繼續順利進行。由架構四開始，我們不需要額外的 Media Server 來幫忙實現 Vivid Ring Service，只要雙方的話機都認得 early-session 這個新的 Option tag 就可以正常運作。但是在這個新的 Option tag 在西元 2004 年 12 月被公佈出來之前，市面上已經充斥著許多舊式的話機，雙方都支援此功能的機率實在不高，對於買了新式話機使用者而言，這並不是他們所願意見到的現象，他們只希望當自己的話機開啟 Vivid Ring Service 功能，無論對方使用何種設備皆能聽見使用者所指定音樂。除此之外，Vivid Ring 的 RTP Stream 應該是由受話方傳向發話方，但是建立 Early Session 的 SDP offer2 卻是由發話方所提供，邏輯上此點是不太合理的，畢竟發話方是無法曉得受話方將提供的 Early Media 是聲音還是影像，如果在 SDP offer2 的傳輸編碼格式全不被受話方所接受，Vivid Ring Service 將會因此而失效，於是受話方的話機在必須傳送完 415 Unsupported Media Type 去對應 PRACK Request，之後還需再傳送一個 180 Ringing Response 去啟動發話端話機的 Local Ring-back Tone，不然發話端的使用者也將會如同架構三一般因為聽不到任何聲音而誤以為通話建立失敗。架構五除了不再需要 Media Server 的支援，也不像架構四需要使用新的 Option tag 才能運作，因此，只要發話方的話機有支援西元 2002 年 9 月所公佈的 RFC 3311 的 UPDATE Method，Vivid Ring Service 就可以正常的運作，畢竟 UPDATE 這個 Method 原本就是為了修改在正式通話前的 Session 參數而產生的，所以無論新舊話機，對於這個重要的 Method 支援度相當高。相對的，early-session 這個 Option tag 對於一般話機的正常運作並不是非常.

(5) 的必要，所以建立 Early Session 的成功機率相對減低許多。即使發話方的話機真的不支援 UPDATE 這個 Method 而回送 405 Method Not Allowed Response 給受話方，此時受話方的話機只要再傳送 180 Ringing Response 給發話方，即可避免發話方因為聽不到 Ring-back Tone 誤以為通話建立失敗。也由於架構五中建立 Early Session 的 SDP offer 是由受話方主動提供，就 Vivid Ring Service 而言，它可以避免架構四中所提到的失敗狀況，大大的提升了 Vivid Ring Service 的成功率。由於 RFC 3959 對於 Early Session 機制需由發話方利用帶有 early-session 的 Supported header 所觸發，若發話方沒有將此標頭加入 INVITE Request 之中，則 Early Session 機制將永遠無法啟動。由此點看來，RFC 3959 並不符合 Vivid Ring Service 的特性，因為受話方的使用者希望功能的啟動與否是由自己決定，而且在任何情況皆不受發話方牽制。除此之外，RFC 3959 與本論文的架構四有著一樣的缺點，原因是由於 early-session 這個 Option tag 太新所造成的，也許 early-session 這個 Option tag 在不久的將來會廣被接受，但是在現今的過渡時期，話機支援 UPDATE Method 的數量高於 early-session 卻是個不爭的事實。綜合以上觀點，比起 RFC 3959 的架構，本論文的架構五將是實作 Vivid Ring Service 更合適的選擇。. 圖 8 Vivid Ring Service 實驗架構圖此時如果 fish 的 Vivid Ring 設定是開啟的，則 fish 會在回送 183 Response （圖 10 上方第 4 個封包）之後，接著送出 UPDATE Request（圖 10 上方第 5 個封包）給 Proxy Server，再藉由 Proxy Server 轉交給 elvis，當 fish 收到對應於 UPDATE 的 200 OK（圖 10 上方第 6 個封包），elvis 就可以經由 Early Media 的機制聽到 fish 所指定的音樂聲。. 4. Early Media 於 Vivid Ring Service 之實作與結果本論文 Early Media 機制架構五所實作 SIP UA，Vivid Phone 1.0。當使用者開始啟動程式時，螢幕上將會出現一個 Vivid Phone 的主體視窗。由於在整個實驗的架構中，如圖 8，希望能藉由與 SIP Express Router 的 Proxy Server 與 Registrar Server 互相運作來證實本架構的可行性，因此本實驗分別在兩台電腦上開啟 Vivid Phone 程式，並且以 fish （163.22.24.156）以及 elvis（10.10.35.170）兩個不同的帳號向本實驗的 Registrar Server （163.22.24.155）註冊。當 elvis 想要與 fish 通話時，如圖 9 中之橢圓形部份所示，elvis 必須在自己的 Vivid Phone 主視窗的下方欄位填入 fish 完整的 SIP 帳號，然後按下綠色的撥號鍵，Vivid Phone 就會根據 fish 的 SIP 帳號的 Domain Name 將 INVITE Request（圖 10 下方第 3 個封包）傳送到本實驗所架設的 SIP Proxy Server （163.22.24.155），然後 SIP Proxy Server 接著會根據 fish 所註冊的聯絡位址將 INVITE 轉送給 fish 所使用的 Vivid Phone 主機（圖 10 上方第 3 個封包）。. 圖 9 Fish(左)與 elvis(右)雙方鈴響時的畫面接著當 fish 按下綠色的接聽鍵後，fish 的 Vivid Phone 主機除了回送一個對應於 INVITE 的 200 OK Response（圖 10 上方第 7 個封包）外，還會在 fish 收到 elvis 的 ACK Request 完成 Three-way handshake 之後主動發送另一個帶有 SDP 的 INVITE Request （圖 10 上方第 9 個封包），當雙方完成第三次的 SDP Offer/Answer（圖 10 上方第 9 個與第 11 個封包）交換之後，fish 與 elvis 就可以開始通話。在整個實驗的過程中除了向 Registrar Server 註冊的 REGISTER Request 以外，無論是 Request 或 Response，皆是從其中一個 UA 發送後經由 Proxy Server 轉送到另一方，但是卻絲毫不影響本論文所推測之結果，因此架構五之可行性可以由此得證。.

(6) 參考文獻. 圖 10 Ethereal 擷取到的封包(上為 fish，下為 elvis). 5. 結論本論文針對 Vivid Ring Service 所設計的五種 Early Media 機制各有不同的特性與優缺點，以架構一而言，它的訊號流程相當簡潔，雖然不適合傳送較大的 Early Media 檔案，但是卻非常適合用來傳遞檔案較小的圖片型 Early Media。而需要 Media Server 輔助的架構二與架構三，十分合適讓 Internet Services Provider（ISP）業者來營運，只要直接將 Media Server 與 Proxy Server 結合在一起，不僅可以節省硬體的擴充費用，更可以藉由 Proxy Server 的認證機制與病毒掃描機制保障發話方不受 Early Media 中的病毒與惡意程式的侵擾。架構四與架構五則是點對點的 Early Media 類型，其中不需要使用額外 Option tag 之架構五更是優於架構四。除此之外，就實作 Vivid Ring Service 而言，架構五更是話機全面接受 RFC 3959 前的最佳過渡時期替代方案。. 6. 未來研究本論文雖然已經成功得以 Early Media 機制實作出支援 Vivid Ring Service 的 SIP UA，但是由於架構三、架構四與架構五的 Vivid Ring Service 皆是以 Early Session 的方式運作，所以如果一個 SIP 帳號同時註冊了兩個不同 IP 位址，發話端將會因為不知該接受哪一個 Early Session 而發生 RFC 3960 [5] 中所提及的在 Forking 時衍生如何選擇哪一個 Early Media 等等的問題[12]。除此之外，當 Early Session 正式轉換至 Regular Session 時，使用者誤以為 Media Session 已經建立起來，實際上還沒有完成，就開始講話了而發生開始的前幾個片段音節遺失，即所謂的 Media Clipping 現象[5]。而如何避免這些問題的發生，也是未來重要的研究方向之一。. [1] D. Collins, “CARRIER GRADE VOICE OVER IP,” McGraw-Hill Companies, Inc., 2003. [2] “Ethereal – Network Protocol Analyzer,” Network Integration Service, Inc. http://www.ethereal.com [3] G. Camarillo, W. Marshall and J. Rosenberg, “Integration of Resource Management and Session Initiation Protocol (SIP),” IETF RFC 3312, October 2002. [4] G. Camarillo, Ericsson, “The Early Session Disposition Type for the Session Initiation Protocol (SIP),” IETF RFC 3959, December 2004. [5] G. Camarillo and H. Schulzrinne, “Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP),” IETF RFC 3960, December 2004. [6] H. Schulzrinne and A. B. Johnston, “Internet Communications using SIP”, John Wiley & Sons, Inc., 2001. [7] J. Rosenberg and H. Schulzrinne, “Reliability of Provisional Responses in Session Initiation Protocol (SIP),” IETF RFC 3262, June 2002. [8] J. Rosenberg and H. Schulzrinne, “An Offer/Answer Model with Session Description Protocol (SDP),” IETF RFC 3264, June 2002. [9] J. Rosenberg, dynamicsoft, “The Session Initiation Protocol (SIP) UPDATE Method,” IETF RFC 3311, September 2002. [10] J. Rosenberg, J. Peterson, H. Schulzrinne and G. Camarillo, “Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP),” IETF RFC 3725, April 2004. [11] J. Kuthan, J. Janak and Y. Rebahi, “iptel.org SIP Express Router v0.11.0 -- Admin's Guide,” FhG Fokus, 2002. [12] M. Handley et al., “SIP: session initiation protocol,” IETF RFC 3261, June 2002. [13] M. Handley and V. Jacobson, “SDP: session description protocol,” IETF RFC 2327, April 1998. [14] N. Freed and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” IETF RFC 2046, November 1996. [15] S. Kingham and Q. Wu, “Tutorial: Build and understand a SIP Proxy Server,” AARNet, January 2005..

(7)