Tuesday, September 05, 2006

漫談IP新世代電信服務(5)IP電信的安全議題—我的電話被入侵了!?


文/iThome (記者) 2006-09-05

目前企業用戶發生網路電話安全事件並不多,但未來使用人數增加後,涉及隱私權、電話盜打和惡意攻擊等問題勢必加劇,所有的網路電話用戶都將無可倖免。


網路電話既然是在IP網路上運行,甚至是在Internet上傳遞,和網路安全之間的關連性不言可喻,網路電話的安全性議題非常廣泛,除了避免無聊的駭客,透過癱瘓攻擊致使SIP網路電話無法正常運作之外,還要小心高明的駭客破解SIP網路電話系統,藉此盜打電話。

試想,如果SIP電話已像Email一般普及時,該如何認證發話端以防堵垃圾網路電話?網路電話交談過程是否有可能被非法竊聽?如何防止?VoIP使用者 防止被竊聽,而治安單位卻千方百計想辦法監聽VoIP,到底是道高一尺?還是魔高一丈?以上都是網路電話安全的熱門話題。

偽造身份以欺騙登錄(Identity Theft)
「欺騙」是在網路上隱藏某人真正的識別身份,要建立假的識別身份,攻擊者必須在封包中使用偽造來源來取代真實位址。「欺騙」可用來隱藏攻擊的原始來源或愚弄網路存取控制清單 (ACL),而且無法追蹤到欺騙封包的原始傳送者。

雖然SIP話機無法以搭線的方式盜打電話,但經由IP網路管理的漏洞或是透過Sniffer等軟體,仍可竊取SIP語系統管理的密碼、SIP話機的登錄密碼,非法用戶仍可取得相應的語音功能和許可權。

圖(一)是兩種典型的偽造身份以欺騙登錄,或偽造身份通知代理伺服器轉移呼叫的方法,駭客會不斷的發送REGISTER註冊訊息,除了嘗試登錄系統以遂其盜撥電話的陰謀外,也能癱瘓一定程度的代理伺服器處理效能。

圖(一) 欺騙登錄(Identity Theft)與呼叫攔截(Call Hijacking)

服務竊取問題在類比話機中同樣存在,我們在一根普通模擬話機線並接了多個電話時,也會出現電話盜打的問題。在SIP話機首次登錄時,會要求提示輸 入分機碼和密碼;如密碼外洩,任何人登錄到別人的分機號碼;如果獲得可自由撥打國內甚至國際長途號碼的許可權,將會給企業帶來巨大的損失,且很難追查。

另一種欺騙的方法,是圖(一)下半部中以302 Moved Temporarily 訊息的攻擊方法,攻擊者會先發送一個偽造來自UAC_1的302 Moved Temporarily訊息給代理伺服器。如果代理伺服器設計不夠嚴謹,就會誤認UAC-1已經主動要求暫時移轉呼叫到攻擊者UAC去。這同時也是呼叫攔 截的一種手法。

防止SIP電話被盜打是IP電信時代的新問題,要避免IP電話被盜打,就要保護好用戶名和密碼。這個要求是和用戶保護好自己其他的帳戶是一樣的, 最主要的作法是在用戶端需要防止木馬,以及其他盜號病毒的入侵。對於企業來說,最好是能綁定帳號(也就是虛擬電話號碼)和IP位址甚至MAC位址,就算帳 號被竊,也不能在其他地方撥出電話。但是這又讓網路電話失去移動性(Mobility)的效益。

呼叫攔截
呼叫攔截(Call Hijacking)也稱為連線劫持,亦稱為「中間人(Man in the middle)」攻擊。連線劫持會欺騙伺服器或用戶端,把操控網路的攻擊者主機當成實際合法的上游主機,讓攻擊者的主機看起來像是所要的目的地。 SIP的典型連線劫持方式如圖(一)下半部中所示。

這種手法也有人叫它重定向攻擊,劫持者透過發送偽造來自UAC的302 Moved Temporarily訊息給代理伺服器,使代理伺服器誤以為UAC要求暫時移轉所有的呼叫到UAC 攻擊者去,此時一旦有SIP UAC_1發送邀請UAC對話的連線,就會被代理伺服器轉至到假的UAC,變成由SIP UAC攻擊者接聽電話,而真正的UAC不會有任何感覺,頂多覺得今天電話特別少而已。

預防連線劫持的因應對策包括有使用加密的SIP協定和Secure RTP通訊管道等。由於呼叫攔截者往往來自於企業內部,將SIP UA裝置重新註冊的時間縮短多少可以增加進行呼叫攔截的難度。

竊聽
「竊聽(Sniffing)」或「截聽(Eavesdropping)」是監視網路資料傳輸 (例如純文字密碼或組態資訊)的行為。使用簡單的封包竊聽程式,攻擊者就可以輕易的讀取所有純文字的資料傳輸。同樣的,攻擊者可以使用精簡的雜湊演算法破 解封包加密,以及解密您認為安全的內容。竊聽封包需要在伺服器/用戶端通訊的路徑上設有封包竊聽程式。最後是RTP媒體串流的偵聽問題。

在VoIP環境下這個問題依然存在。一個典型的VoIP呼叫需要信令和媒體流兩個建立的步驟,RTP/RTCP是在基於封包的網路上傳輸即時語音 資訊的協定。由於協議本身是開放的,即使是一小段的媒體串流都可以被重放出來而不需要前後資訊的關聯。如果有人能在資料網路上通過Sniffer的方式記 錄所有資訊並通過軟體加以重新播放,那麼所有用戶間的私密談話內容就都不保了。

現今大多數SIP設備製造商都不對語音資料進行加密,這是基於實用性的考慮,因為加密要佔用CPU資源。終端用戶的SIP設備和軟交換機必須對資訊進行幾乎是即時的加密和解密,並且不能影響呼叫品質。這個問題需要增加硬體和基礎設施的投資才能解決。

要位於呼叫通過的路徑上,才能截獲呼叫設置或SIP呼叫過程中的語音資料,由於呼叫的路徑可能會改變,因此想截獲SIP呼叫只有幾個可實施點,即在SIP用戶端、代理伺服器前端或者在兩個終端所使用的ISP上。

想防止攻擊者破解竊聽來的封包,可以完整地加密通訊,並且驗證相關憑證。SSL和IPSec是加密的兩種方式,一樣可以和SIP應用配合運作,能 有效增加竊聽者的「竊聽成本」,或延長竊聽者的解讀時間,以避免外洩具有時效性的通話內容,但目前並沒有廠商敢保證能夠100%不會被竊聽。

竊聽行為也有合法的,那就叫做監聽了,為有效進行犯罪偵防,立法單位希望將網路電話也納入電信監聽法的管制,此舉勢必凸顯出如何有效執行監聽的問題。

目前的網路監聽產品或技術,多鎖定在企業內部等小規模的監聽行為,針對以監聽VOIP內容為目地而設計的更少;監聽系統在設計上首要考量的就是處 理效能,在效能上是否能夠做到完全不漏失任何呼叫,需要多大的儲存空間,如何部署實現,都需要精確計算與實作;下一階段的重要問題,就是如何建構出一套有 效的虛擬空間和實體位置的定位管理架構,也就是要能得知收發話端的實際地理位置,如果能掌握即時定位出收發話雙方接入網實際地點的技術,和構建出跨國合作 的機制,監聽網路電話的動作,在犯罪偵防上也將更具意義。

法律的健全和科技的進步似乎難以構成消滅犯罪的要件,監聽是一把雙面刃,獲得這項授權的治安機關,能夠在與犯罪者的鬥爭中取得了得力的武器;但是使用不當,傷害的是未來整個資訊社會的發展方向。這些議題,都有待後續研究者加入探討的行列。

拒絕服務癱瘓攻擊(DoS)
「拒絕服務(Denial of Service,DoS)」攻擊會阻止合法使用者存取伺服器或服務,從攻擊方法和破壞效果來看,DoS是一種既簡單又有效的攻擊方式。攻擊者向伺服器發送相當多帶有虛假位址的服務請求,伺服器會等不到回傳的消息,就會耗盡所有資源。

TCP SYN氾濫攻擊是常見的網路層級「拒絕服務」攻擊,很容易發動卻又難以追蹤。攻擊會利用 TCP/IP 連線建立機制中的潛在弱點,並且塞爆伺服器的等待連線佇列,網路電話協定都是TCP或UDP,網路電話的伺服器或終端裝置都有可能遭受到TCP SYN的攻擊。

再者網路電話技術已經有很多知名的服務埠,像H.323的1719、1720、SIP的5060等,還有一些埠是產品本身需要,用於遠端管理或是私有資訊傳遞的用途。只要是攻擊者的PC和這些應用存在於同一網段,就可以通過簡單的掃描工具來獲得更詳細的資訊。

市場上很多採用H.323協定的VoIP系統,在建立H.245通訊過程中都存在漏洞,容易在1720埠上受到DoS的攻擊,導致系統的不穩定甚 至癱瘓。除了上述傳統網路層級的DoS攻擊方式外,在SIP環境中,還可以運用再見攻擊(BYE Attack)和取消攻擊(CANCEL Attack)兩種手法,以惡意癱瘓正常的SIP服務,如圖(二)上半部所示。

圖(二) 再見(BYE)攻擊與取消(CANCEL)攻擊

劫持者偵測到SIP UAC和SIP UAS正在通話中,就發送一個偽造來自SIP UAC的BYE訊息給代理伺服器,使代理伺服器誤以為SIP UAC要結束通話了,或是如案例中直接發給一個偽造來自代理伺服器的BYE訊息給SIP UAC,讓SIP UAC誤以為SIP UAS要求結束通話,這就是再見攻擊,通常會讓SIP用戶感覺很困惑,為什麼常常電話一接通、或是講沒幾句話,怎麼莫名其妙掛斷了呢?

取消攻擊的原理和再見攻擊相差不大,如圖(二)下半部所示。劫持者偵測到UAC正試圖和UAS進行通話,就透過發送一個偽造來自代理伺服器的 CANCEL訊息給UAC或UAS,或者反過來偽造一個來自UAC或UAS的CANCEL訊息給代理伺服器,目的是讓代理伺服器誤以為UAC或UAS要取 消剛剛的通話要求,這就是取消攻擊,其效果是讓SIP話機永遠都接不到來電,或是往往電話鈴響一聲就隨即斷了線。

無論再見攻擊或是取消攻擊,都是源自於不嚴謹的程式碼撰寫,大多問題都能用更新軟體或軔體的方式解決。
垃圾網路電話
您很可能還沒聽過SPIT(Spam for Internet Telephony)-「垃圾網路電話」,也有人稱之為Spam Call,一些科技觀察家表示,這個字眼很快地就會橫掃全球。

SPIT的議題是Yahoo的通訊產品副總裁Brad Garlinghouse在加州聖荷西舉行的InBox IT 2005電子郵件會議中首度提出的,他認為IP通訊匯流中的VoIP正促使一種新型態的垃圾郵件產生。他並提到在2004的美國總統大選期間,他的IP電 話開始收到了幾通來自有名的競選機構如Karl Rove所傳送的自動語音回覆電話。數以百計的自動外撥電話開始在網路中氾濫,兩年之內SPIT將成為一個嚴重的問題。

將來SPIT的威脅比電子郵件信箱的垃圾嚴重許多,畢竟收到垃圾電子郵件,直接刪除就好,可是垃圾網路電話卻會中斷您目前的工作來接聽它,您能想 像一天收到100封垃圾郵件的景況,但是您如果一天接到100通垃圾電話,內容不外是市調、推銷、騷擾,甚至於詐騙等,可能所有的網路電話使用者都會瘋掉 吧?或是寧可選擇關機?

雖然SPIT議題還是在討論初期,網路電話市場在一兩年內暫時還沒有熱到會出現太嚴重的Spam Call情況,但是具有「前瞻性」的生意人已經為了爭奪SPIT的「市場」而摩拳擦掌。除了一些認為網路電話是新興行銷工具的廣告公司外,在防禦的一方, 不少從事網路安全產品的公司已展開初步的合作,一起研發一套偵測與避免垃圾網路電話的架構。

防止來路不明的SIP呼叫,最簡單有效的方法就是發話端識別(Caller-ID Verify),居心不良的發話者,通常不願意在對方的話機顯示來電號碼(Caller-ID),以避免身份的曝光或是讓被叫端得知主叫端的聯絡方式,如 此他們就可能會被人找到。接不接受匿名撥出(Anonymous Call)是建置網路電話服務時第一個要考慮到的政策,是否拒絕匿名來電(Anonymous Call Reject)則和前面的問題一體兩面,是同時也必須思考到的問題。

最通常的作法是利用強制顯示來電號碼方法,做為最基本的發話端身份識別功能,代理伺服器可由UA註冊的帳號資訊,比對其發出INVITE訊息中的 發話端識別資訊(From欄位)是否一致,若否則拒絕其呼叫,回應403 Forbidden的訊息,唯有正確填入發話端識別資訊的呼叫得以被系統接受,也才能在被叫端的話機上正確顯示來電訊息。範例中顯示的是由代理伺服器管理 的程序,若不透過代理伺服器,話機本身亦可做到相同的功能,或當鈴響時由人工觀察是否顯示來電,以決定是否接聽,是最直接的做法。

至於利用來電號碼的顯示做為發話端身份的識別,其實還有一些問題存在,原因是SIP對相關欄位的定義並不嚴謹,一般實作上也並不會強烈要求,甚至有的話機軟體上也允許用戶隨意填入發話端資訊。

其本身的判斷上也有不明之處,通常的判斷方法是利用From或Contact欄位內的訊息,比對與IP Header中的Source IP Address是否一致,但問題是,廠商通常會在Contact欄位填入IP,但SIP並沒有規定一定要如此,因此有的廠商會在Contact欄位填入 SIP URI,也就是代理伺服器的Domain Name,甚至於填入MAC Address以做為自己產品間的識別。

若透過From欄位內的訊息來判斷也有問題,From欄位跟Email的From概念類似,只是一個暱稱,SIP一樣沒有規定一定要填入甚麼資 訊,雖然很多廠商慣例上會填入發話端的SIP URI。換言之,如果嚴謹的要求,很多應該能通的電話也會被擋下了。這些都是目前發話端身份識別上的問題。

反騷擾電話在SIP UA終端裝置中可以很容易的實現,系統收到來電時可以自動比對這通電話是否在拒絕接聽的表列之內,若是則自動拒絕該來電。

但是這個方法也有一些盲點,一是更換SIP UA終端裝置後設定的移轉過程會很麻煩。二是這種方法只能拒絕同一個發話源的第二次騷擾呼叫,除了使用者設定上的時間浪費外,一定會接到第一通騷擾電話也 是問題,發話源不斷變化發話端的身份,使用者還是會不斷收到騷擾電話,更不論新的騷擾電話發話源會不斷出現。

對用戶而言,只要騷擾電話能成功的送出振鈴,就已經達到騷擾的目的了。 在ITSP業者的營運層面,也可以設置一套反騷擾服務(Anti-SPAM Call System)系統。系統的核心概念是由前台的IVR系統和後台的SPIT資料庫整合,使用者則負責提供回報機制,由用戶檢舉Spam Call並列入SPIT黑名單中,業者具有很大的處理彈性;消極部分可以列入Presence功能中,標注為「不受歡迎者」,也可以在來話顯示中標示 「SPAM」字眼,讓接聽者自己決定是否接聽該通來電。積極的處理方式可以乾脆通知該發話端的ITSP直接將其停權,或直接阻斷來自該特定發話端的所有 INVITE要求等。

至於用戶檢舉SPAM Call的機制設計,可以設計一個網頁接受用戶的申告。以客服人員接聽用戶的申告電話,並手動鍵入系統。最經濟有效的是是設置一個IVR系統,每當用戶接 聽到一通騷擾電話,在掛掉後可立即回撥一個「騷擾電話申告專線」如「1XX」的免付費公眾服務號碼,接通後系統會提示「您的騷擾電話申告已經被處理」的語 音訊息,用戶不必輸入任何資訊即可掛掉。因為系統將自動調閱出你的前一通被呼叫記錄,把發話端的記錄到騷擾電的表列之內,這套系統為避免誤報,可以採用投 票制。譬如說當一個發話源在一段時間內被超過10個不同的用戶舉報,才會真正被列入騷擾電話的黑名單之列,而且還要有能讓用戶提出申訴的管道,以避免可能 的爭議。

正視網路電話安全問題
雖然現階段還很少聽到企業用戶遭受網路電話發生安全事件,可能是普及率和整合程度都還沒有達到「對網路電話進行攻擊,即產生足夠經濟效益」的地 步,一旦未來使用人數增加之後,有心人士「研發」網路電話攻擊技巧的動機就會增加,涉及隱私權、電話盜打和惡意攻擊等問題勢必加劇,所有的網路電話用戶都 將無可倖免。

目前廠商所提的網路電話安全技術都還是基於網路安全的層次,「網路安全,則網路電話安全」;但是網路電話設備特有的使用行為和將產生特有的功擊模式,未來如何整合安全方案仍有待廠商通盤考量,而企業在導入VoIP之際更必須格外謹慎做好防護工作。

作者/賈文康
第一線技術顧問、台北市電腦商業同業公會顧問、NICI全國IPv6建置發展計畫,應用推廣分項計畫協同主持人、開放網路電話交換聯盟 (IPOX)計畫顧問,專精研究領域為網路系統整合、TCP/IP 通訊協定核心設計、多媒體通訊、NAT穿越、網路流量暨話務量工程,在IT產業擁有15年研究開發、技術支援、產品行銷等經歷,並著有「SIP會談啟始協 議操典」、「3G第三代行動通信網路技術」等書籍。

矽谷興起wiki網站創業熱

矽谷興起wiki網站創業熱

CNET新聞專區:NYTimes授權 Robert Levine  05/09/2006

每天都有數百萬人上維基百科(Wikipedia)查詢,尋求解答各種瑣碎或嚴肅的疑難雜症。Jack Herrick則在此處尋獲他想要的商業模式。

2004年,Herrick收購基本知識指南網站eHow.com。這個網站聘請自由作家撰稿,雖然網站有利可圖,但他認為靠賣廣告賺營收,支撐不了他構思中的龐大網站。Herrick說:「如果網頁談的是如何取得抵押貸款,就行得通;但我想建置的是一個包羅萬象的入門知識網站。」




所以,2005年1月,他創立wikiHow,採用跟維基百科一樣的開放原始碼軟體建置,所以可讓任何人共同撰寫、編輯詞條。令他訝異的是,他發現網路使用者不收分文撰寫的文章,內容竟比自由撰稿作家的文章更豐富、翔實。

Herrick說:「Wikipedia證明,用別的方法也能達到目標。」

數月前,他把eHow賣掉,專心經營新網站。如今wikiHow已收入1萬則以英文、西班牙文和德文撰寫的詞條。

wiki 模式效率高、成本低,正鼓勵一群創業家建立營利性的網站,Herrick就是其中之一。維基百科雖由非營利基金會管理,但以廣告支持的維基網站(wiki sites),正與部落格(blogs)和社交網站(social networking sites)三足鼎立,成為矽谷創業計畫的一大模式。

目前已有Wikia,鎖定維基百科不適合收錄的玄奧主題文章。此外,還有專門評論產品的ShopWiki,以及提供旅遊建議的Wikitravel等等。另有幾家新創公司讓使用者管理自己的維基網站。

自建維基網站Wetpaint的執行長Ben Elowitz說:「維基百科是一部百科全書,而本網站收納的是圖書館裡其他99萬9,000本書。」

但令人好奇的是,這些如雨後春筍般興起的線上知識庫究竟能擴充到多大?

目前,以消費者為導向的維基網站經營者都是私人企業,並未公開營收數字。但可確定的是,目前為止,沒有任一個網站的人氣接近維基百科。根據 Nielsen/NetRatings的調查,7月份WikiHow吸引110萬名訪客,Wikia訪客人數超過27萬人,其他幾個wiki網站到訪人數太小,未達到Nielsen/NetRatings測量的門檻。

科技諮詢公司Gartner的研究部主任Andrew Frank說,這股維基熱可能基於天真的假設。

Frank說:「認定維基網站的經營成本低廉,是有問題的假設。」

舉例說,要銷售數量可觀的廣告,維基網站恐怕必須過濾掉不適當和不雅的內容。他認為,在維基網站上登廣告,每次曝光(per impression)的費率可能低於瞄準特定對象的廣告。

他說:「我認為,維基網站會百家爭鳴。但我不確定有多少網站能賺錢。」

其他人比較樂觀。上個月,以購買網域名稱聞名的企業家John Gotts同意支付286萬美元,買下Wiki.com。

Gotts說:「若是買其他的網域名,我絕不會付這麼高的價錢。我想不出比這個更有價值的網域名。」他指出,Wiki.com網站雖然內容不多,但已經吸引可觀的流量。

wiki概念是電腦科學家Ward Cunningham在1994年首創。他寫了一個稱為「WikiWikiWeb」的電腦程式,用來與其他人分享程式設計技巧。這個程式以夏威夷語命名,取其「快速」之意。

Cunningham說:「我的構想是讓同好分享撰寫好程式必備的知識,但我發現wiki可以有更廣泛的應用。這個媒介比電子郵件等系統更容易促成眾人合作。」

過去數年來,wiki已進入商業界,用於企業的內部網路,以促進複雜任務的協同作業。Gartner預測,到2009年,半數的企業會在內部使用某種 wiki工具。就連新聞界也嘗試用wiki:洛杉磯時報就曾推出線上版「wikitorials」,但很快就宣告實驗失敗。

就連維基百科創辦人Jimmy Wales也設法擴大wiki的用途,並希望從中獲利。仰仗Marc Andreessen與Mitchell Kapor等科技界名人的資助,他與Angela Beesley共同創立營利性的Wikia公司,建置了1,500個獨立的wikis,從專論星際大戰的Wookieepedia,到讓使用者自己抒發憂鬱症經驗的網頁,不一而足。

Wikia雖是營利公司,但創立的宗旨也帶有幾分維基百科的理想主義色彩,且Wikia的商業計畫也標榜會把部分獲利捐給基金會。

該公司執行長Gil Penchina說:「這絕不會是營收十億美元的生意。」他表示,該網站目前每一網頁每月賺不到1美元,但隨著網頁數目增多,廣告收入可能積少成多。

倘若維基網站壯大成巨額的生意,原始的理想主義色彩可能消褪--而使用者可能變得不願免費貢獻一己之力。但目前為止,志願者的踴躍投入,讓這些維基網站快速擴張。

75歲的佛州退休人士Sondra Crane說,他己為wikiHow撰寫了數十篇文章,主題有的很實用(如何做罐燜牛肉),有的很深奧(如何在年歲增長的同時保持年輕心境)。

她說:「我一生都在搖筆捍,總是希望能成名。有稿費可拿當然樂意,畢竟我花了時間和心血。但知道有人因此獲益,也是樂事一樁。」

Wikia和wikiHow的經營方式頗類似Wikipedia:都讓使用者投稿,且明訂任何投稿內容都供人免費使用,就像開原碼軟體一般。其他新創公司,包括Wiki.com在內,則偏離wiki模式的傳統協作精神,讓使用者決定准許誰投稿到他們所創始的維基網站。

買下Wiki.com的Gotts說,他打算與利用Wiki.com建置wiki網站的人分享營收。Gotts說:「我們獲利的主要途徑,是引領一股趨勢:讓使用者賺錢。」

Gotts表示,他會讓使用者免費註冊Wiki.com次網域名,建置主題任選的網頁,例如討論足球的soccer.wiki.com或smokedsalmon.wiki.com等等,希望能引來廣告收入或電子商務商機。

但另一個自建維基網站業者PBwiki的共同創辦人Ramit Sethi說,現在要判斷哪一種商業模式會把wiki網站轉化為搖錢樹,還言之過早。

他說:「天知道什麼是wiki的最佳商業模式。這還是個有待開墾的大西部。」(唐慧文/譯)

Monday, September 04, 2006

吸引開發人員 網路公司平台化

吸引開發人員 網路公司平台化

CNET 新聞專區:Martin LaMonica 
 04/09/2006

友善列印 Email文章給朋友 儲存文章

儘管大多數造訪Amazon.com的網友看到的只是一個漂亮的電子商務網站,但創業家Dave Cotter看到的卻是一個資料寶藏和賺錢的法門。

Cotter二年前離開了商業軟體大廠BEA Systems,希望「站在程式網站的肩膀上」建立一家新公司。他與Greg Harrison合夥成立了Mpire,該網站使人們能夠利用Amazon.com、eBay.com、Craigslist等網站在網上購買和銷售產品,它還能夠分析採購模式資料,找出最優惠的購買價格。

隨著越來越多的應用軟體網路化,網路服務 (Web services) 供應商競相吸引諸如Mpire這類公司的軟體開發人員。作為Mpire的行銷總監,Cotter表示,「過去在企業世界裡,你有微軟開發商程式來跟 IBM、甲骨文、BEA作競爭。我們發現,各大網際網路服務供應商紛紛拉攏新創公司,使它們開發能夠強調自家平台的產品。」

Amazon Web Services上周啟動了一項beta版服務計畫,讓開發人員利用Amazon資料中心的處理能力。

名為Elastic Compute Cloud(EC2)的該服務能夠與Amazon的Simple Storage Service,以及即時通訊、搜尋、電子商務等其他服務相通,Amazon透過API提供這些服務。

EC2這種類似公用運算式的服務使得Amazon成為了IBM、惠普、昇陽的競爭對手。

Amazon的開發人員計畫還有意搶奪為傳統軟體供應商服務的程式人員。Amazon等網際網路巨頭不會將程式人員「固定」在一種作業系統或資料庫上,而是使它們的運算基礎設施能夠執行第三方代管應用軟體。

Google、雅虎、eBay等網際網路公司目前都仿照微軟或開放原始碼專案的方式制訂開發人員計畫,並借鑒微軟的經驗,為開發人員提供文件、免費工具、程式碼範本等協助。

eBay Developers Program負責人Greg Isaacs表示,「任何爭奪開發人員注意力的平台都需要參與競爭。開發人員的心靈佔有率 (mind-share) 相當寶貴,因為開發人員的數量有限。」

他表示,「eBay將繼續向外界開放更多的功能,這種策略的優點是,我們成為了電子商務活動的作業系統。」

而對於最近很熱門的Web 2.0 新公司而言,提供API讓第三方能夠從多方資料來源「混合」(mash up) 資料已經成了一種常態。

但是,Amazon不僅提供開發人員存取其產品目錄的程式,還向他們開放自家「久經考驗」的運算基礎設施。

Amazon Web Services負責產品管理和開發人員關係的副總裁 Adam Selipsky 表示,「我們計畫透過Amazon

Web Services提供Amazon身為大型網站以及Web基礎設施的規模優勢。」

無需與代管公司聯繫、購買硬體和招聘員工,客戶可以利用Amazon的運算能力、儲存等通用運算服務。Selipsky說,「第三方可以善用Amazon.com工程師在過去數年中創建的性能、可靠性、安全。」

Amazon.com在技術方面的投資已經超過了15億美元。例如,照片共用網站SmugMug.com就利用了Amazon的儲存服務,使得它在存取量大增的情況而仍然能夠只雇用15名員工。

Selipsky表示,Amazon Web Services對Elastic Compute Cloud服務的定價非常積極--每小時每伺服器實例僅為10美分,目的是降低門檻,招攬更多的客戶。他說,「如果有一個好的創意,並願意努力工作,在實 現創意方面,大學生和大公司有著同樣的機會。」

支持者表示,就像大量的應用軟體能夠提高作業系統的吸引力一樣,較大的附加代管服務「生態體系」能夠吸引更多的客戶。

Salesforce.com已經讓自家AppExchange開發架構成為代管客戶關係管理應用軟體業務不可或缺的一部分。在最近的一次會議上, Salesforce.com執行長Marc Benioff表示,這種策略的基本原理是「讓千朵花兒圍著Salesforce.com綻放」。

Salesforce.com已經收購了一家新創公司,利用AppExchange在Salesforce.com和Google AdWords之間建立聯繫。

各大網路服務平台供應商在吸引外部開發人員的動機方面略有不同。例如,eBay讓第三方存取其內容,整合其線上購物車,加速通過eBay網站進行的交易。

Amazon的網路服務則並非完全與其零售電子商務相關。Selipsky表示,該公司最初發佈API的目的是通過合作夥伴促進其電子商務網站業務的成 長,但隨著時間的推移,它開始將開發人員看作是截然不同的客戶。例如,Amazon應客戶需求推出了Elastic Compute Cloud服務;Amazon Web Services則是Amazon.com旗下一個以盈利為目的的部門。

雅虎和Google則是面向消費者的網站,它們開放Web工具的目的是讓第三方利用外掛協助強化它們針對消費者的服務,並帶動流量;微軟的策略則與純粹的軟體服務化供應商有所不同,強調傳統軟體與Live線上服務的整合。

eBay的Isaacs表示,儘管都在爭奪開發人員,網路服務平台供應商希望在各自的服務之間建立聯繫,因為這些服務能夠被整合在一起。

在使用的程式語言和產品方面,程式人員將有更大的靈活性。對於傳統軟體開發而言,人們通常需要進行選擇--使用C、.Net、Java,或者腳本語言。

Cotter表示,「以前你可能會說,我是微軟的開發人員程式人員;現在,你可能會改口說,我是網際網路開發人員,可以使用不同的工具和通訊協定。」

對於Amazon而言,它的技術開發的重點是開放更多的後端、資料中心處理能力。儘管其電子商務業務更知名,進一步進入效用運算領域是吸引開發人員所不可或缺的。

Selipsky表示,「我的經驗是,當推出具有創新性的服務時,我們將獲得最多的關注和爆炸性的成長。」

rsync Remote Backups

主機的備分問題一直是粉多人的煩惱之一
在這裡使用 rsync 這個套件 來作兩台電腦的資料備份

環境說明

server (需要備份的主機.目前運作中的機器) :
O/S:Redhat 9.0
ip : 192.168.0.2
user : root
欲備份目錄 : /test (實驗用.預設沒有此目錄請自行建立)

client (遠端存放備份的機器.不提供服務只備份資料) :
O/S:Redhat 9.0
ip : 192.168.0.253
user : root
存放資料目錄 : /test (實驗用.預設沒有此目錄請自行建立)

分兩個部分來做

server 部分:

1.首先檢查有沒有rsync 套件 (Redhat 預設都會裝)
#rpm -q rsync
rsync-2.5.5-4

2.開啟rsync的服務並檢查狀態
#chkconfig rsync on
#chkconfig rsync --list
rsync 開啟

client 部分:
為了使用SSH加密傳輸且不需要輸入密碼

1.#cd /root/.ssh (進入到/root/.ssh/ 目錄下)
2.#ssh-keygen -d (產生ssh的公鑰和私鑰)
Generating public/private dsa key pair.
Enter file in which to save the key (/root/.ssh/id_dsa): (產生到何處.按Enter 就可以了)
Enter passphrase (empty for no passphrase): (要不要設定passwd.避免問我們按Enter 就可以了)
Enter same passphrase again: (再按一次Enter)
Your identification has been saved in /root/.ssh/id_dsa.
Your public key has been saved in /root/.ssh/id_dsa.pub.

此時目錄下會產生公鑰id_dsa.pub和私鑰id_dsa
現在要把id_dsa.pub丟到192.168.0.2 並且更名為 authorized_keys

3.#scp id_dsa.pub 192.168.0.2:/root/.ssh/authorized_keys
root@192.168.0.2's password:
id_dsa.pub 100% |*****************************| 613 00:00

試試看 ssh 到server 應該就不用輸入密碼了
4.#ssh 192.168.0.2
#exit (記得離開)
5.#cd /usr/local/bin (要寫一個shell script 在 /usr/local/bin下 故先到此目錄下)
#vi sync
rsync -avlR --delete -e ssh 192.168.0.2:/test /
(把192.168.0.2下面的 /test 目錄 備份到本機上的 / , 因為備份會產生test這個資料夾.所以本機上設定為/)
(讓/test => /test 而不是 /test => /test/test)
參數意義如下﹕

-a, --archive
It is a quick way of saying you want recursion and want to preserve almost everything.
-v, --verbose
This option increases the amount of information you are given during the transfer.
-l, --links
When symlinks are encountered, recreate the symlink on the destination.
-R, --relative
Use relative paths. 保留相對路徑...才不會讓子目錄跟 parent 擠在同一層...
--delete
是指如果Server端刪除了一文件,那客戶端也相應把這一文件刪除,保持真正的一致。
-e ssh
建立起加密的連接。
6.#chmod 700 sync 只讓root 可以使用
7.#./sync (執行sync這個script.........此時你就會發現兩台電腦的/test是同步的呢^_^)


參考文件
小弟的心得是參考以下的文件來製作

http://www.adj.idv.tw/server/linux_rsync.php
http://www.fanqiang.com/a6/b7/20010908/1305001258_b.html
http://phorum.study-area.org/viewtopic.php?t=15553&highlight=rsync
http://linux.tnc.edu.tw/techdoc/rsync.htm

===========================================================
底下是2 => 1 (2台到一台backup server)
我有做過2部server對1部用戶端
方 法是先在用戶端產生1部server的id_dsa再下scp指令將檔案複制到第一部server後刪除authorized_keys2再產生第二部 server的id_dsa1(注意檔名有改,請自訂)將產生的authorized_keys2內容copy 起來貼到id_dsa.pub(第一部產生的檔案)累加(不同行)存檔後再下scp指令將檔案複制到第二部server,然後2部就不用再key密碼了.
=----------=
將二個用戶端產生的authorized_keys2內容結合為一放到server內就可以了

===========================================================
Yukie:
剛剛看到一篇文章,它提到 server 如果有開 ssh 的話,即使未安裝 rsync server 也是可以的。所以我就試了一下,將 server 端的 rsync server 關掉,然後由 Windows 端以 rsync via ssh 進行備份,果然成功。所以備份的準備工作就更加簡單了。

原文網址在此:
http://www.longren.org/2005/07/09/quick-and-easy-remote-backups/

===========================================================
Yukie:
參考各位網友們的資料後,我寫了一篇在 Windows 上應用 rsync與 ssh 備份資料的文章,歡迎參考:

利用 rsync 備份 Wins 資料

因為怕格式亂掉,所以沒有直接貼過來,抱歉。

Saturday, September 02, 2006

漫談IP新世代電信服務(4)VoIP服務網路的設計與挑戰—流量規畫與服務品質迷思

漫談IP新世代電信服務(4)VoIP服務網路的設計與挑戰—流量規畫與服務品質迷思

文/iThome (記者) 2006-08-29

VoIP需要在單一網路上,同時協調語音和數據的傳輸要求,和傳統電信網路的服務品質相比,VoIP的服務品質(QoS)問題更具挑戰性。


在傳統電信網路上,線路資源的瓶頸往往導致用戶的呼叫無法接通,特別是在春節、中秋、優惠時段及重大社會活動等特定時間內,突然爆增的話務量導致交換機系統超載,進而出現電路擁塞、接通率下降,甚至服務癱瘓的現象,為電信業者和個人都造成不可彌補的損失。

這些問題肇因於線路老舊或其他技術因素,而讓使用者感受到接通時間過久,或是聲音延後、回音、斷續、響度過小、雜音等通話障礙。傳統電信網路不知花了多少時間和金錢,才建立出今天大多數用戶可以接受的服務品質。

VoIP的服務品質
與傳統電信網路的服務品質相比,VoIP的服務品質(QoS)問題更具挑戰性,其關鍵原因就是VoIP需要在單一網路上,同時協調語音和數據的傳輸要求。

在頻寬資源有限下,IP電信設備所能承載的呼叫容量,並非如傳統電信設備般,可由設備本身的硬體能力得到確定的數字;IP電信設備在接近臨界點前,效能與服務品質就會開始逐步下降,直到所有客戶都不能接受為止,嚴重影響IP電信產業的發展。

與資料通訊相比,語音通訊對網路品質的要求高出許多,當網路上有大量突發的數據傳送時,必然會影響語音封包的傳送,輕則延後到達,重則導致網路設備來不及 處理而丟棄,或是封包延遲以致於傳輸表現時好時壞,這些服務品質指標包括封包傳輸延遲(Packet Latency)、封包遺失(Packet Lost),以及封包延遲變異(Jitter)等。

服務品質如何衡量?
業界主要有主觀測試方法和客觀測試方法兩種,ITU-T的P.800標準定義了平均意見分數(Mean Opinion Score,MOS)的主觀測試方法,其測試程序採用ITU-T標準推薦的4個不同的語音原始檔案,並由由2男2女組成的評審團隊,重複測試10次,並測 試在同一設備/不同設備間、各種編解碼演算法下的語音品質。以及在良好網路、一般網路和較差三種網路狀況下的語音品質對比,。最後得到「優、良、中、差、 劣」5個等級的分數。見表一

MOS平均主觀值達到4分或更高,一般被認定為較佳的語音品質,而若MOS值低於3.6,則表示大部分接聽者不滿意該語音品質。

雖然平均主觀測試被大多數人認定有效,但這個主觀方法存在的最大問題就是,由一組受過訓練的人士以人耳來評價語音的品質,測試代價非常高昂,且容易受測試環境的潛在干擾影響。

在平均主觀測試法的公平性受到詬病後,人們又不斷地探索客觀測量的方法,以儀器實際量測各項影響VoIP服務品質參數的客觀量測方法於焉誕生見表二、表三, 這項新的客觀測量主要是看封包漏失率和抖動,及延遲對語音品質的影響,並可透過ITU-T G.107規範中的E-Model方式匯整出一個總分,也就是R值。R值的範圍從0到100分,R值的計算從沒有網路傳輸設備的損失影響開始,此時語音品 質是最好的,當受到上述因素影響時次第衰減。

代表E-model的前提是,假設語音品質的損失因素總是由網路實體層在傳遞過程中所附加的,那麼若能靈活地加入諸如雜訊、回音、延遲、編碼器性能、抖動等網路損失因素的估算值,「使用者體驗」的因素就能被全面客觀的服務品質等級所估計。

R值(滿分100分)和MOS值(滿分5分)可相互換算,考量透過網路傳送與實際語音之間存在必然的轉換損失,這種固有的損耗使得R值最大只能達93.2分,對應到平均主觀的MOS值只有4.4分。

VoIP流量規畫常犯的錯誤
對語音網路的主要要求是能夠提供連續的資料傳輸流程,即為穩定的資料串流(Streaming)。為達到最終用戶期望的通話品質,幾乎無法容忍通 話用戶間出現語音信號中斷的現象,這也是傳統語音網路採用電路交換(Circuit Switch)技術設計的原因,因此對任何VoIP服務網路來說,在終端用戶之間勻速地發送和接收語音信號的能力至關重要。

很多廠商往往誇大了VoIP語音技術壓縮封包的能力,只以一路G.711語音編碼佔64Kb,一路G.729語音壓縮編碼佔8Kb含混帶過。事實 上,一個在IP網路上傳送的IP封包結構依序包含MAC Header、IP Header、UDP Header、RTP Header及Voice Payload。

一般所稱的8Kb語音頻寬指的是CODEC(編碼器)處理過的語音籌載內容(Voice Payload),而且它會經由RTP協定來承載,RTP的協定資料單元是用UDP協定來承載的,最後再加上IP和MAC等表頭。

圖一:IP語音封包的結構

圖二:主要Codec實際佔用的網路頻寬

為了儘量減少傳輸延遲,語音籌載的淨值通常都很短,由圖一可看出,IP語音的頻寬吃重,約有66%~80%的頻寬被浪費(深色部份),真正有意義的內容不到只有約20%~33%(淺色部份)。

由圖二計算的結果顯示,8Kb編碼率的G.729,在每20ms取樣一次的條件下(取樣間隔愈短佔用網路頻寬愈高,因每取樣包裝一次就產生上圖中 的浪費(Overhead)),在IP傳輸層傳輸需要24kbps,在實際乙太網路(MAC層)上佔用了高達39.2kbps的頻寬。

若是G.711編碼則更為驚人,在MAC層一路語音就佔用了126.4kbps,在現行以MAC層提供上網服務的ADSL線路上,上行 128Kb,下行1M的產品,就只能勉強傳輸一路語音而已。這結論和許多人的想像不同,也是很多VoIP網路在規畫時就以一路語音8K來計算其所佔用頻 寬,所產生的一大謬誤。
提高VoIP服務品質的對策
(1) 靜音偵測及舒適噪音生成技術
為節省語音頻寬,可採用語音啟動檢測技術(VAD),或稱為靜音偵測技術,以及舒適噪音生成(CNG)技術。

VAD技術只有當檢測到語音處於活動狀態時,編碼器的輸出信號才被送到網路上。理論上進行交談的雙方,同一時間內只會有一方在講話,而傾聽的另一方不會發出聲音,因此VAD可節省可觀的頻寬,並能有效的把每通語音的信息量降低三分之一以上。

而在靜音時段採用CNG技術,在用戶終端上模擬產生與背景雜訊相匹配的較舒適的靜音,讓使用者仿佛聽到對方的背景雜訊,如此一來使可以避免用戶產生不自然的交談感受。目前大部分的網路設備都已支援這項技術。

(2) 差異化服務
在IP網路上可將封包畫分為多個服務類別,網路管理者可定義多個不同的服務類別,網路根據預先定義的策略設置優先權。一般而言,高優先權資料流將立即得到 處理,低優先權流量則插入佇列(Queue),按比例分享現有有限頻寬並延遲傳送,在出現擁塞的情況下,低優先順序的傳送可能被丟棄。

差異化服務可分為主動和被動模式兩類,所謂主動模式是網路設備利用IP表頭上用於標識服務類型(TOS)的三個位元,定義每個封包的服務類別,為預先分配有限的頻寬資源提供了相當大的靈活性。

IP被動模式優先權功能則可在IP封包必經之路上,由路由器或頻寬管理器以封包來源或目的地的IP或MAC位址、服務埠號或其他方式,判斷不同應用程式的優先權分配。最簡單的實作方式就是轉送時語音優先的做法,雖然簡單還是具有一定的效果。

但很多舊有網路設備並不支援差異化服務的功能,因此在企業網路規畫中,將語音與數據分流,避免兩者相互干擾,是一個簡單好用的策略。

(3) 呼叫允入控制(CAC)
在VoIP系統中常有呼叫允入控制(Call Admission Control,CAC)的設定,其用意是在避免系統接受的呼叫過多,超過頻寬的承載能力,近而影響到每一通呼叫的通話語音品質,因此當系統參考頻寬有 240Kbps時,依VoIP流量規畫的經驗法則,代表可以承載10通24Kbps(G.729/20ms)的呼叫10通,故CAC值就會設為允許10 通,拒絕第11通的呼叫進入。

理論上設定較保守的CAC值,可確保每一通VoIP通話的服務品質,讓每次通話的客戶滿意度保持一致的水準;但大量呼叫時的阻塞率也會上昇,又會對整體的客戶滿意度造成衝擊。因此CAC值的設定在VoIP系統管理上是一個頗費斟酌的問題。

(4)前向糾錯技術(FEC)
有些先進的VoIP設備會採用前向糾錯技術(Forward Error Correction,FEC)來保證音質。IP封包在傳送過程中有可能損壞或遺失,在這種情況下,FEC技術能發揮重要作用。

FEC通常是一種結合Codec編碼方式的演算法,它的技術有兩級,第一級是Intra-Packet,第二級是Extra-Packet。第一 級是在同一語音封包內加冗餘數據,以便接收方糾錯、恢復、還原話音資料,以保證音質。第二級是在每一個話音封包中存放前後封包的冗餘數據,以便接收方從已 經接收到的封包中恢復被丟失的話音封包。FEC可以降低10%~20%的封包漏失率,以保持高音質。但是FEC要多消耗高達30%的網路頻寬,可說是一種 損人不一定利己的方法,因此在企業網內部一般不會採用FEC,除非在軍事通訊等具有特定考量的網路內。

最簡單的前向糾錯技術就是將已察覺遺失的前一個封包複製一份,讓封包漏失時的聲音聽起來較平滑,不會有明顯的中斷,因為在取樣間隔50ms的VoIP服務下,漏失一個封包即代表有100ms的聲音中斷,連續漏失兩個封包代表有150ms的聲音中斷。

另外,企業也可採用多重路徑中繼的技術,簡單的說,就是將相同語音內容重覆的透過不同的路徑或節點轉送,只要有一份成功到達,就可以獲得100%的聲音品質,但是代價可能是增加了一倍以上的網路頻寬。

(5)頻寬保證協定
 頻寬保證協定(RSVP)是用來設定路由器,保證某一個服務可取得固定傳輸速率的通訊協定,RSVP可由VoIP裝置主動送出,沿者語音傳遞路 徑,通過路徑中各實現了RSVP功能的中繼節點,進行一系列的RSVP訊息協商,以建立起一條從發送端到接收端的資源預留路徑,如此一來即可確保稍後的語 音封包在這個建立起來的專屬貴賓通道中,不致發生壅塞。

RSVP的問題是,並非每一顆沿線的路由器都支援這種協定,只要有一顆不支援RSVP協定,就無法建立一條點對點的QoS通道,而事實上,大部分的路由器都不支援,即便ISP的路由器有支援也「不方便」啟動它。

(6)壅塞控制機制
加權公平佇列(WFQ)是常見的路徑封包規畫演算法,將資料流量按不同頻寬的延遲要求,畫分為不同類別的傳送佇列,並確定將封包發送到傳輸線路上的順序。

WFQ能以IP位址、埠號或封包進入介面(Input Port)等方式畫分類別。WFQ在分配現有頻寬給優先權較低的服務時,會保證低延遲要求的高優先權封包和低優先權業務流量都一定會傳送出去。高優先權資 料流會立即得到處理,低優先權流量則按比例分享現有有限頻寬,插入佇列之中並延遲傳送。在網路出現擁塞的情況下,設備可能會丟棄(Drop)低優先順序的 數據封包,以維持語音的服務品質。

另外,加權隨機早期檢測(WRED)也是一種避免擁塞的演算法,它與TCP等傳輸協定協同合作,可避免網路同時進行TCP傳送時導致的壅塞狀態。

WRED加權隨機早期檢測功能結合了RED和IP優先順序,可對不同的封包類別標明不同的「丟棄」處理策略。當網路阻塞發生時,WRED可對特殊 的封包提供優先待遇,允許優先順序高的封包通過,而抑制級別較低的封包。網路管理者可以定義不同服務類別的定義值,如排隊長度的最大和最小門檻值及封包丟 棄機率。由犧牲優先權較低者的傳送權力換取優先權較高者的絕對傳送權力。

限制訪問速率(CAR)也是一種分類IP封包後,定義不同服務類型(IP優先權和QoS類別)的機制,並能執行頻寬管理功能和通過速率限制等功能。而「流量管理器」或稱為「頻寬管理器」的裝置即是CAR功能的具體實現。

CAR為網路管理者提供了一個可依業務目的地分配頻寬,並制定超過頻寬分配額度時的處理策略。CAR既可用於網路入口,也可用於網路出口。CAR 的門檻值可根據埠號、IP位址和應用程式型態設定。CAR的概念與CAC一樣,都是限制過多的連接,以避免產生過大的網路流量,差別是在於CAC是以限制 VoIP呼叫通數為出發點,CAR則是限制TCP或UDP連線建立次數。

(7)主動式QoS監控體系
主動式QoS監控體系又有人稱為遠端網路QoS遙測系統,包括了「主動感測」的方法,以一定數量的感測器,或稱為探針,分散置於全球網際網路各個 適當節點上,通過協定分析、流量特徵與異常檢測等技術自動蒐集並測試QoS數據,或藉由主動向遠端網路節點發送頻次、長短不等的測量請求,由回饋數值為依 據評估品質參數,藉此有效並動態地估算遠端任意兩個網路節點間的封包漏失(Packet Lost)、延遲(Delay)、跳動(Jitter)及傳輸速率(Throughput)等品質參數,最後統一回傳至QoS中心管理系統做為分析和運 用。

一般而言,QoS監控體系獲得的即時資訊,可提供給IP電信服務業者做為早期預警的決策支援使用,譬如可和CAC結合,暫時限制用戶撥出;或啟用繞道程序,以避開壅塞的網段或節點;甚至可提供給用戶,做為服務品質保證的承諾等等。

建立VoIP服務品質的正確觀念
IP網路動態資源分享的缺點是,只能提供最佳的傳輸服務,但不能保證特定通信流的性能級別,這種特性又稱為盡力而為(Best Effort)的傳輸。為了克服IP性能的這些侷限性,企業開始使用頻寬管理技術,如優先順序管理,來保證重要應用所需的性能。但是頻寬管理只是分配頻寬 給重要的應用,同時也影響了其他應用,而這些應用中有些對企業同樣的重要。

無限制增加頻寬也不一定是最佳的解決辦法,因為增加的頻寬有時候會被某些獨佔性強的應用所消耗(如果企業內部並不管制P2P下載或FTP下載的話),並不一定能分配到最重要的應用。

由於現有的IP網路不是為承載即時性的電信業務所設計,要能完全解決QoS問題,尚有賴於「IP電信網」新網路架構下所推出的QoS技術方案。 IP電信網的概念就是要透過加強對IP網路設備的控制能力,在網路上實施QoS控制更容易,以讓IP網路來達到承載電信業務的能力。

總之,企業或服務供應商在部署VoIP服務時,可根據實際網路情況和業務開展的需要,鎖定特殊需求分析和逐步最佳化,以達到最佳效果。運用上述單 一的QoS功能或組合使用,在適當的網路特性條件下,正確選擇實施適當的QoS管理策略,將有效保障IP網路用戶具有很好的QoS網路連接,為VoIP等 多媒體應用提供了堅實的服務品質保證(SLA)機制。

網路電話的服務品質問題並沒有想像中嚴重,很多案例只不過是因為規畫上觀念就有錯誤,提供了不足的頻寬(問問還有多少資訊人員還停留在一路網路電 話只佔8K的觀念?),在今日網路頻寬愈來愈廉價的狀況下,只要企業改善連外網路頻寬,提供充裕的頻寬給網路電話使用,大多數的聲音品質,都可達到市內電 話品質的境界。

如果用戶抱怨VoIP聲音有迴音或雜訊等,通常問題是出在與傳統電話系統(PABX)界接的界面匹配特性沒有妥善調校。但若用戶抱怨的是網路電話 聲音斷斷續續,那麼增加連外頻寬,十之八九可以解決這個問題。倘若增加連外頻寬有困難的話,採購一套有效的頻寬管理設備,建立一套企業內部的頻寬管理政 策,也是一個好的選擇。

作者/賈文康
第一線技術顧問、台北市電腦商業同業公會顧問、NICI全國IPv6建置發展計畫,應用推廣分項計畫協同主持人、開放網路電話交換聯盟 (IPOX)計畫顧問,專精研究領域為網路系統整合、TCP/IP 通訊協定核心設計、多媒體通訊、NAT穿越、網路流量暨話務量工程,在IT產業擁有15年研究開發、技術支援、產品行銷等經歷,並著有「SIP會談啟始協 議操典」、「3G第三代行動通信網路技術」等書籍。

表一:以MOS級別判斷VoIP服務品質標準

級別 評分 用戶滿意度
4~5 很好,聽的清楚,延遲很小,溝通順暢。
3.5~4 稍差,聽的清楚,延遲小,交流尚順暢,有點雜音。
3~3.5 還可以,聽不太清楚,有一定延遲,可以交流。
1.5~3 勉強,聽不太清楚,延遲較大,溝通需重複多次。
0~1.5 極差,聽不懂,延遲大,溝通不順暢


表二:封包漏失率和抖動對網路的影響

網路等級 封包漏失率 抖動
良好 0% 1ms
一般 1% 20ms
5% 60ms


表三:延遲對語音品質的影響

網路等級 封包延遲時間 使用者感受
良好 <=150ms 最好,為大多數用戶應用程式所接受
尚可 150~250ms 可接受,部分用戶感受到品質有些許影響
一般 250~400ms 大多數用戶明顯感受到品質的降低
>=400ms 大多數用戶不能接受