VoIP（Voice-over-Internet-Protocol）的時代已經到來，藉由將電話與資料通訊兩個世界合而為一，可以透過成本低廉的網際網路連結，以串流方式傳送封包化的語音及傳真資料。此一從線路交換轉換到封包交換網路的轉移過程正在如火如荼地進行，讓相關應用得以在相同的架構下，從單純的語音傳輸擴展到其它型態的資料傳送。然而，這些嵌入式設計所面臨的挑戰，在於如何挑選出成本效益高、佈署容易、又能夠針對市場需求提供具有擴充性的解決方案。更具體的說，嵌入式解決方案的一項優勢是使用一個能夠實現低通道數量VoIP解決方案之外，還有充足空間來增加像是視訊、音樂、影像及系統控制之類附加價值的處理器。本文將介紹上述的解決方案。

何謂VoIP

現今的語音網路，如PSTN（Public Switched Telephone Network；公眾交換電話網路），是利用數位交換技術來建立發話者與受話者之間的專用連結。雖然這種連結方式只能提供有限的頻寬，但它確實提供了可接受程度的品質，而不須動用到複雜的編碼演算法。

VoIP則是使用網際網路協定，在網際網路或私人網路上傳送數位化的語音流量，其IP封包含有一控制標頭（header）及一資料負載（payload），標頭為封包提供了網路導引資訊，而資料負載則攜帶著壓縮過的語音資料。

與線路交換電話不同，資料傳輸為封包方式，因此資料的片段（chunk）須經過封包化與壓縮， 再透過網路來傳送，最後在接收端上重新被組合還原。如此一來，發射端與接收端之間就不須要專屬的連結。

封包化對於透過網路來傳送“資料”（例如JPEG檔案或是email）而言，是很合適的作法，因為此方式的傳送會是屬於“最大努力（best-effort）”，網路能有效的在相同的媒體上搬移來自多個來源的資料。然而，對於語音應用而言，“最大努力”的傳送方式並不恰當，因為在接收端上解碼後的音頻訊號品質，可能會受到封包在網路上傳送時不定的延遲時間所影響，而變的令人無法接受。這也是為何VoIP協定，會將重點放在透過QoS來提供一固定份量的網路頻寬，以避免延遲所造成的語音品質下降。

語音的封包化須要在語音資料塊（block）上加入封包頭（header）及封包尾（trailer）資訊，但封包化的額外負擔必須儘量的減小以避免延遲增加。因此，在處理上必須於傳送延遲與網路頻寬有效運用兩者間取得平衡。當然，較小的封包大小能傳送的更頻繁，較大的封包則會須要較長時間來組合。不過，在較大的封包中，由於封包頭及封包尾會由較多的語音資訊所分攤，因此它們使用的網路頻寬會比小封包來得少。

由於網路的特性，資料的傳送速率會有不小的變化，此變化就是大家所熟悉的抖動量（jitter）。要將抖動量移除，可以將封包予以足夠長的緩衝以確保最慢的封包也能夠即時到達並被依正確的順序解碼開來。當然抖動量緩衝器會對系統增加一全面性的延遲。

延遲之所以是一項重要的參數，在於它代表了透過IP系統所導致的時間延誤。單向的延遲指的是一個字從被說出一直到通信話對方聽到所須的時間，往返延遲則是將兩個單向延遲加起來的總合。對於北美的PSTN電話系統而言，往返延遲低於150ms。當然，越低的延遲值會讓通話的品質表現越自然。

對於VoIP系統而言，單向延遲的可接受範圍達到200ms之譜。造成該VoIP系統延遲的最大因素，是通話雙方的網路及閘道器（gateway）。語音編解碼器也會造成一些延遲的增加，但相對之下通常是較小的（＜20ms）。

當語音網路應用的延遲很大時，迴音消除及重疊消除就成了最大的技術挑戰。迴音消除與感受到的品質有直接的關係，當往返延遲超過50ms時會成為一重要問題；語音重疊則是在單向延遲大於250ms時會造成問題。

現有和即將出現的VoIP相關應用

由於網路是用來做為傳輸的機制，VoIP系統的重要優點之一，就在於每一通訊時段（session）的成本會較低。此外，VoIP通話方式能讓網路營運商避免掉與線路交換電話系統相關的大部份互連費用，而完成VoIP通話只須非常小的基礎建設的增加，亦即利用現有已佈署的家用或商用電腦的網路。另一個低成本的原因，是由於數據網路營運商通常都有未用到的頻寬，因此增加VoIP服務所帶來的額外負擔基本上是微不足道的。

VoIP使用者總會認為所使用的連結是免費的，因為可以頻繁地與全世界的各個角落通話，費用卻只要每分鐘幾分錢。然而實際上使用者須向網際網路服務提供廠商繳交月費，只不過這筆費用可以由資料及語音服務所共同負擔。

透過VoIP，不僅服務的費用比線路交換方式來的便宜，更能提供許多新的功能。舉例來說，PSTN上的來電可以被自動轉接到使用者的VoIP電話，只要該VoIP電話有接到網路節點上。此優點在能夠全球通行的行動電話上特別有其意義，因為不會有漫遊費用的產生。換句話說，使用者所在的地點從VoIP的角度來看是沒有差異 的，因為該地點只不過是代表著另一網路連結點。這讓符合802.11標準的VoIP手機特別吸引人，因為透過此特性，全球WiFi熱點上的通話可以不用再擔心通訊基礎建設與傳送標準的相容性問題。

到目前為止所討論到的話題雖然圍繞在透過IP來傳送語音，但事實上也可延伸到其它型態的資料通訊。畢竟，一旦資料被數位化與封包化，內容是什麼已不太重要了。VoIP基礎建設能夠實現各種的新型網路即時應用，像是：

深入檢視VoIP系統

如(圖一)所示，為VoIP系統中的四大構成元件：訊號 （signaling）、編碼/解碼器、傳輸（transport）機制，以及交換式閘道器（switching gateway）。其中訊號包含了節點之間連結的建立、維護及終止。

《圖一　VoIP系統四大構成元件》

為了降低網路頻寬需求，音訊及視訊在傳送之前及接收後必須加以編碼與解碼的處理，此壓縮及轉換過程，必須根據各種的音訊及視訊串流的編解碼標準做為處理依歸。

經過壓縮的封包必須根據一個或多個傳送協定在網路中流動，交換閘道器能確保封包在目的地上另一IP型態的系統或PSTN系統中具有互用性。當到達最後的目的地時，封包會被解碼並換為音訊訊號，再透過接收端的聽筒或喇叭播放出來。

(圖二)詳細說明了OSI（Open System Interconnection；開放系統連結）模型中各階層所用到的一些協定，這些協定解釋了網路的框架。

《圖二　OSI模型中各階層所用到的協定》

時段（session）控制：H.323 vs. SIP

VoIP系統中的第一個需求為時段控制協定，藉以建立存在性（presence）及找出使用者，並設定、修改及終結時段。目前普遍使用中的協定有兩種。就先後性來說，H.232為第一種出現的協定，但後起的SIP（Session Initiation Protocol；時段啟始化協定）很快的取而代之成為主要的標準。接下來，將分別深入了解此兩套協定。

H.323

H.323原本是針對即時多媒體（語音及視訊）會議及輔助資料傳送所制定的ITU-T（ITU電信標準化部門）標準，該標準目前已快速發展成能夠符合VoIP網路的需求。技術上來說，它是一個能容納多組必要與選項網路及媒體編解碼標準的容器，其連結訊號處理部份是由H.225協定來負責，功能特性協商則是由H.245來加以支援。

SIP（Session Initiation Protocol；時段啟始化協定）

SIP是由RFC 3261下的IETF（Internet Engineering Task Force；網際網路工程任務小組）所制定，雖然有許多部份與H.323有所重疊，但SIP比較新且是專為IP電話及其它網際網路服務所開發出來的，因此該標準通常被視為主流的解決方案。

SIP是與SDP（Session Description Protocol；時段敘述協定）一起用來辨認出使用者，並負責提供特性協商及通話管理。SDP本質上是用來在時段宣佈（session announcement）及邀請（invitation）階段中，敘述串流媒體啟始參數的一種格式。某種程度而言，SIP/SDP就相當於H.323標準中的H.225/H.245協定。

SIP可以使用於只有兩個端點（endpoint）的系統中，而不須要伺服器基礎建設。不過，在公眾網路中，會使用到特殊的防火牆及註冊伺服器來建立連結。在這樣的設立中，每一個用戶會在伺服器中註冊，以便來話者可以在網際網路上的任何角落找到該用戶。

傳輸協定

上文討論過的訊號處理協定，會負責網路上的多媒體時段設定。一旦連結建立起來，媒體便會根據一種或多種傳輸協定（像是UDP或TCP等）流動於網路節點間。

UDP（User Datagram Protocol；使用者資料包協定）

UDP是一種只負責將封包廣播傳送出去的網路協定，其中並沒有來自接收端的封包已接收到回應通知。也就是說，此類傳送並沒有保障，因此在網路的負載巔峰時間上，語音傳送如果只使用UDP，效果可能不會很理想，這就是為何除了UDP外，通常還會有像是RTP之類的媒體傳輸協定在其上面執行。

TCP（Transmission Control Protocol；傳送控制協定）

TCP使用了用戶/伺服器通訊模型，用戶要求（同時也被提供）來自網路上另一台電腦的（伺服器）服務，每一個用戶要求都會被個別處理，與先前的要求完全無關，如此可確保其它的通道可以使用到空閒的網路通路（network path）。

TCP能產生出較小的封包，透過網際網路傳送出去，並由通話另一端的TCP層所接收，並將這些封包重新組合還原成原來的訊息。IP層可處理每一個封包的位址欄，以確保封包能被送到正確的目的地。

相對於UDP，TCP就能夠保障接收端完整的接收到封包。不過，由於其作法是容許封包的重傳，所造成的延遲對於即時語音來說並不合適，這是因為重傳而遲到的封包與遺失封包所造成的負面影響其實沒有太大差別。由於此一特性，TCP並不被視為即時串流媒體傳送的適當傳輸選擇。

媒體傳輸

如前面所提到，就即時通訊而言，直接在傳輸協定上傳送媒體資料並不是有效率的作法，因此通常是由媒體傳輸層來負責有效率的資料處理。

RTP（Real-time Transport Protocol；即時傳輸協定）

《圖三　RTP框架的封包頭架構及封包內容》

RTP為即時封包化的音訊及視訊資料提供傳遞的服務，是在IP網路上傳輸即時資料的標準方式。該協定存在於UDP上，以便將封包頭的額外負擔降到最低，但這相對的會有其附帶的代價，就是無法保證封包次序的可靠性。與TCP相比，RTP的可靠度較低，但由於封包頭的額外負擔比起TCP來說小了很多，因此在封包的傳送上延遲也較小。

為了維持一定水準的QoS，RTP為每一個送出的封包提供了時間戳記（time stamp）、順序編碼（sequence numbering）以及傳遞確認訊息。它同時也支援了多種糾錯機制以增加可靠性，並具有某些基本的安全選項來進行封包加密處理。

《圖四　可靠性與效能比較圖》

RTCP（RTP控制協定）

RTCP為一輔助型態的協定，用來溝通控制訊息，如寄送與遺失的封包數量、抖動量、延遲及端點敘述等。其最大的價值在於時段時基（session timebase）的管理，或是RTP串流的QoS分析等。該協定也提供了後門通道（backchannel），用來限制RTP封包的重傳動作。

媒體編解碼器

VoIP協定堆疊的最後一個構成元件負責處理實際在傳輸中的媒體，有不少的音頻及視頻編解碼標準可適用於媒體傳輸層。

有效的語音編解碼對於網路頻寬使用率的最佳化是很重要的，而語音編解碼就是用來壓縮/解壓縮語音資料封包。所有的壓縮技術都必須在品質及頻寬之間做一取捨，不過，有些考量因素可做為判斷所需語音編解碼器的依據，像是系統頻寬的使用效率有多高、處理封包遺失的處理方式，以及有哪些成本會牽涉其中（如智慧財產權等）。

由於語音交談中大部份的時間都屬於所謂的“呆時（dead time）”，也就是雙方都沒有在說話的狀態，因此編碼器可針對此一事實現象，在該時段中不傳送任何資料。為此，“靜默壓縮（silence compression）”就必需包含一偵測語音活動的方式、一可在沒有語音活動時停止傳送資料的方式，以及一能夠產生舒適雜訊（comfort noise）以確保當雙方都沒有在說話時，線路上也不會變得完全安靜的方法。

在一標準的線路交換式電話系統中，有幾個原因會導致迴音而降低服務品質，最常見的原因為線路交換式PSTN網路上的阻抗不匹配（線路迴音；line echo），另一個常見的原因則是電話上麥克風與喇叭之間的音頻耦合（音頻迴音；acoustic echo）。線路迴音在網路中有兩線對四線轉換的場合中（比方說，類比訊號轉為T1系統的地方）相當容易發生。

由於VoIP系統可能會連結到PSTN，因此必須能夠應付線路迴音。此外，在IP電話的麥克風與喇叭之間的迴授，則會造成音頻迴音的出現。

迴音消除標準（如G.168）可將系統中的迴音除去，且可針對線路迴音、音頻迴音或兩者同時進行最佳化，而消除的效果則是直接由所採用的演算法之品質來決定。

迴音消除的一個重要參數，是其操作上所採用的封包長度。簡單的說，迴音消除器會保留一份傳送訊號的複本，在該訊號傳出的特定時間後，迴音消除器會試圖將傳送出去的訊號與回來的反射訊號進行關聯比對（correlate）及相減。當然，此接收的訊號為已經過延遲，且在振幅上也變小。一般的關聯比對窗（correlate window）長度為32ms、62ms或128ms。當迴音超出關聯比對窗的外圍時，迴音消除器就無法正確處理該迴音。

VoIP之實際應用

傳統的VoIP嵌入式解決方案是使用了兩個處理器核心來提供VoIP功能，Blackfin處理器則提供了統一核心架構的聚合解決方案，由訊號處理單元負責語音處理，而RISC MCU則負責處理網路及使用者界面。此一提供完整VoIP功能於一聚合處理器的能力，提供的好處包括單一化的軟體發展環境、較快速的系統除錯開發，及較低的整體系統成本。

這些處理器必須能為VoIP的開發提供必要的整合度、性能及低功耗。該晶片需具有多組整合串列埠（可不須透過額外元件而直接連接到音訊類比/數位及數位/類比轉換器）、外部記憶體控制器、用來接上LCD或視訊編解碼器的平行週邊介面（PPI）、以及10/100BaseT 乙太網路MAC。如有需要，還可以透過外部記憶體介面提供第二組的乙太網路MAC。

一個包含語音及網路堆疊（networking stack）在內的通訊通道，只須使用低於75MHz的處理器頻寬。許多同類的VoIP方案通常在性能上容易出現瓶頸，且不具備增加功能及產品區隔特性的能力。由於多媒體壓縮與解壓縮的必要性日趨提高，因此超過600MHz的性能才可容許充裕的處理能力來實現各類的VoIP產品。

VoIP的衍生產品

對於VoIP應用來說，基於Blackfin的設計主要適用於高品質、低通道數量的VoIP解決方案，並提供足夠的處理能力空間來增加類似音訊、視訊、影像等的傳輸，以及系統的整體控制。以下為市場上一些現有的VoIP產品，範圍從開放來源解決方案到大量OEM參考設計都涵蓋在內。

Blackfin/（Linphone）

Blackfin VoIP系統可以透過uClinux平台上的開放軟體來進行設計，uClinux是由相當普及的GNU-Linux OS所發展出的嵌入式版本。線路電話為此類的GPL授權軟體套件包之一，已被套用到uClinux上供處理器的開發使用，該軟體套件包是基於SIP協定，因此能夠讓Blackfin參考設計和任何的SIP相容端點進行通訊。在具有適當SIP伺服器及閘道器基礎建設的公眾網路中，此系統甚至可以和PSTN節點上的電話連結。就語音編碼與解碼而言，目前使用Blackfin設計的有線電話成品能支援G.711（A-law及μ-law）、GSM及Speex。

參考設計中使用到的主要元件為：

Linux TCP/IP 網路堆疊

包含必要的傳輸與控制協定，如TCP與UDP等。

linphone

主要的VoIP應用，包括在Blackfin上開發出的G.711與GSM編解碼器成品等。另外還有一套能在桌上型電腦上使用的圖形化使用者界面（GUI）軟體，以及指令鍵入式應用軟體以供不具圖形化能力的嵌入系統使用。

oRTP

針對線路電話所開發的RTP堆疊成品，可在LGPL授權下提供。

oSIP

具有執行緒安全（thread-safe）能力的SIP協定成品，可在LGPL授權下提供。

Speex

Speex編解碼器的開放來源參考成品，針對Blackfin最佳化的定點式Speex成品已被加入主線碼分支（mainline code branch）中。

Fusion Voice Gateway

Fusion Voice Gateway為Unicoi Systems所推出的完整語音閘道器/終端轉接器（Voice Gateway/Terminal Adapter）參考設計，由於在同一顆核心處理器上可執行路由器功能（router）與全功能的SIP電話，因此客戶可在很短的時間內利用Fusion Voice Gateway開發出終端轉接器並推出上市。

Fusion Voice Gateway的BOM包括G.168迴音消除及多種G.7xx語音編解碼器。Fusion參考設計還整合了9組路由器（router）、4埠乙太網路交換機、與VoIP閘道器等功能，以提供全功能的電話與路由器功能。

Blackfin BRAVO VoIP參考設計

對於從事多功能高性能與低成本的VoIP桌上型電話、視訊電話及電話轉接器的OEM廠商來說，完整的系統解決方案在設計上需包含VoIP應用所須的完整軟體套餐，並藉由API以方便使用者進行核心系統功能的客製化與控制。

就音頻而言，該設計能支援多種G.7xx音頻編解碼器、符合G.168標準的網路迴音消除，以及音頻迴音消除等，以強化音訊的清晰度。在選項上，可以將RF收發器整合到設計中，以提供無線音頻的能力。此設計同時支援了H.323及符合SIP的軟體堆疊。

在視訊前端上，寬頻音訊/視訊通訊參考設計支援了高達30fps的CIF視訊功能，包括ITU標準H.263及H.264視訊編解碼器、子母畫面、具有重疊效果的高解析度影像，合成（alpha）及去背功能（chroma keying）、以及防閃爍（antiflicker）濾波等。

音訊編解碼器

G.711

與這裏所介紹的其它幾個標準相比，1988年所推出的G.711為一簡單的標準。該標準所使用的唯一壓縮為companding（使用μ法則或A法則標準），該標準將每一個資料取樣壓縮為8位元，產生出64kbps的輸出位元率。根據H.323的規範，必須以G.711做為其語音通信的基準。

G.723.1

G.723.1是以ACELP所發展出來的雙位元率編解碼器，該標準在1996推出，主要的訴求為VoIP的應用。G.723.1的編碼框架為30mS，而每一個框架能被編碼為20或24位元組，以分別轉為5.3kbps及6.3kbps的串流。位元率能透過語音活動偵測及舒適雜訊產生等技術來有效的降低。此編解碼技術能針對框架遺失及位元錯誤等網路問題，提供良好的免疫力。此語音編解碼標準為H.324系列標準中所規定的視訊會議應用的一部份。

G.729

G.729為1996年所出現的另一個語音編解碼標準，該標準將語音切割為10ms的框架，藉以降低延遲程度。G.729使用了名為Conjugate Structure ACELP （CS-ACELP）的演算法，並將8kHz取樣的16位元訊號透過10ms的框架壓縮為8kbps的標準位元率，該標準還支援6.4kbps與11.8kbps資料速率。此外，G.729也提供了語音活動偵測及舒適雜訊產生。

GSM

GSM語音編解碼器在全世界的行動電話系統中都有其發揮的舞台，負責管控這些標準的組織單位是歐洲電信標準協會（ETSI），事實上在這些標準中是有其演化過程的，最早出現的版本為GSM全速率（GSM-FR），該標準採用了由CELP衍生出的Regular Pulse Excited Linear Predictive Coder （RPELPC；常態脈衝激勵線性預測編解碼器），輸入的語音訊號被切割為20ms的框架，再將每一個框架編碼為260位元，以產生出13kbps的總位元率。市面上有免費的GSM-FR產品，可在某些限制規定下使用。

Speex

Speex為Xiph.org所推出的音頻編解碼器，其目標是要提供一完全沒有專利考量的語音解決方案。就像許多其它的語音編解碼器，Speex為基於CELP並附帶餘數（residue）編碼技術，該標準可接受8kHz、16kHz及32kHz的線性PCM訊號，並可將它們編碼成為從2到44kbps範圍內的位元率。Speex能夠容忍網路錯誤，且支援語音活動的偵測。除了容許可變的位元率外，Speex的另一個獨特優點為立體聲的編碼能力。Speex.org可對外提供Speex的原始程式，包括浮點運算參考設計及定點運算的版本。

視訊編解瑪器

H.261

此一標準在1990年推出，為第一個受到普遍採用的視訊編解碼。該標準導入了將影像圖框（frame）分割為16×16巨塊（macroblock）、並有圖框間追蹤以決定動態補償的技術觀念，主要的市場目標是在於ISDN線路上（p×64kbps，其中p的範圍是1到30）的視訊會議應用。其輸入圖框一般是30fps的CIF（352×288），輸出的壓縮圖框在10 fps時會佔用64～128Kbps的頻寬。雖然目前仍有在使用中，但在大部份的場合中該標準早已被其後繼者，如H.263所取代。不過，在H.323中仍然闡述必須以H.261做為視訊通信的基準（baseline）。

H.263

此編解碼器為目前視訊會議中最為普遍採用的標準，其位元率表現優於H.261，輸入的來源通常是30fps的QCIF（176x144）或CIF，輸出位元率在10fps的條件下則可低於28.8Kbps，並提供與H.261相同的性能表現。因此，相對於H.261必須透過ISDN線路才能實現，H.263可使用一般的電話線路來傳送。H.263在視訊電話及網路監控系統的產品市場中非常適用，在以IP為基礎的應用中受到廣泛採用。

結語

很明顯的，VoIP技術具有全面改革大眾通信方式的潛力，不論使用者是在家中、在工作地點、插入式（plugged in）連線、無界限（untethered）連線、視訊開啟，或只是單純的音訊通訊。處理器的多樣化支援可讓VoIP逐漸普及於嵌入式環境中，此一事實，將會為尚未享受到此令人興奮科技的許多新市場創造出有附加價值的功能。