6. 聲音與IP封包之轉換

本章說明聲音與IP封包之轉換技術。聲音轉換包括幾個重要步驟，A2D Conversion、編碼(CODEC)、及包裝成封包(packetization)。負責聲音轉換成封包的設備於 PC-to-PC 及 PC-to-Phone 的情況下，是使用者的電腦負責執行的。於Phone-to-PC 或 Phone-to-Phone (All-IP Network 可以支援Phone-to-Phone模式)的情況下，這個轉換工作由電話機連上的上車gateway負責執行。讀者可以自行推論得到封包轉換為聲音的工作在那個設備上執行。

6.1 Analog-to-Digital and Digital-to-Analog Conversion

外界聲音由Mic 收進來之後，首先變成Analog 電子訊號，之後利用 A2D (Analog-to-Digital Converter) 轉成數位訊號，通常是符合 ITU-T G.711 標準的PCM (Pulse-Code-Modulation) 編碼。G.711 標準使用8000 samples/sec 取樣頻率，並用 8 bits/sample 編碼，得到的是 64Kbps 數位訊號。在VoIP 未出現之前，這樣的Codec 在通訊界已經流傳多年。反向的轉換工作稱做 D2A (Digital-to-Analog) Conversion。

如果是用在語音通訊中，A2D conversion 之後必須進行幾個重要動作，回音消除及按鍵音偵測(tone detection)、必要時可以做靜音消除。

(A) 回音消除

所謂的「回音」是發話者在經過一段延遲時間之後聽到自己所發出的聲音。一般在室內也會有回音，但是回音時間太短，說話者自己沒有感覺，如果回音時間恰當，形成正迴授，（回音與原音疊加在一起）對聲音將有加強之效果，例如在浴室唱歌聲音特別好聽，在音樂廳唱歌，聲音可以經由後面的回音壁放大，就是這個原理。

如果回音的延遲時間太長，發話者可以清楚的感覺到自己發出的聲音，那就會形成干擾，在設計不良的大禮堂內的聲音，無論講者或聽者都會聽到多次回音，那就是聲音在各牆壁間來回反射形成多次回音，而偏偏每個回音的延遲時間都很長，造成很糟糕的環境。禮堂裡面人多的時候，人體會吸收聲音，回音就比空曠的禮堂小很多。

電話之任何一端的的聲音由話筒或Mic 收進來之後無論以何種方式送達另一端之後都會產生回音，而因為距離太長或網路延遲之故，回音時間太長會對使用者產生干擾，必須消除方能維持通話品質。

受話端如果使用傳統電話機，電話機體本身是很好的傳音導體，聽筒送出來的聲音會循著機體傳到話筒，回傳到發話者的聽筒，造成回音，如圖6.1 所示。

圖6.1 回音在電話機Handset 上產生

一般的電話系統（交換機上)有針對這種情況所特製的回音消除電路，所以通話品質不受回音干擾。如圖6.2, 6.3所示，在接收端加入echo canceler，根據當時輸出訊號的狀況，將接收到的聲音反向並經過調節濾波 (Adaptation Filter)，與回音互相抵銷，藉以達到消除回音的目的。

圖6.2 回音消除原理

圖6.3 回音消除電路

如果是用Mic 及喇叭作為收放音的裝置時，如果喇叭發出的聲音不小心進入Mic 的話，將會產生很嚴重的回音，因為針對電話系統的回音消除演算法不是針對這種情況所設計的，VoIP的封包延遲比傳統電話的延遲大很多，傳統電話的回音消除演算法用於VoIP時效果也不佳，必須另行設計。

圖6.4 VoIP 產生回音的方式

(B) 按鍵音偵測(tone detection)

早期的自動交換機接受on/off 的脈波式撥接信號，後來有了電子交換機及按鍵式電話，電子交換機即使在通話中也必須能偵測到按鍵的聲音，（如此才可以在通話中利用按鍵下指令操作某些功能）。當發話端是電話時，上車gateway 應該具備偵測按鍵音的功能，當發話端是電腦時則不一定需要這個功能。 All-IP Network 預期使用者是使用傳統電話機，因此必須具備這個功能。

(C) 靜音消除

人在使用電話交談時，通常不會同時發話，總是一來一回的對話，因此平均有一半的時間沒有發話，這些靜音時間的訊號如果能在發話端偵測出來並消除掉，將可節省可觀的頻寬，尤其是在會議電話中，大部分時間只有一個人發話，靜音時間特別多，可節省更多的頻寬。

6.2 編碼 (CODEC)

A2D Converter 所產生的PCM 訊號接者送給編碼器(CODEC)進行編碼。 VoIP 所用的編碼通常加入壓縮的動作以減少頻寬的消耗。 CODEC 的效能是影響VoIP品質及效能的重要關鍵因素，值得大力研究。壓縮的執行，必須從音訊串流中，取得一段段的資訊再進行壓縮，再輸出一段段壓縮過的資訊。資訊的取得稱為 sampling，而一段段的資訊稱為 frame，而sampling 的時間，免不了的成為封包延遲時間的一部份。

一個frame 通常包含 10ms 至 30ms 的訊號，其大小則依不同的編碼標準有所不同。如以沒有壓縮的 G.711 編碼而言，10ms 訊號含有80 bytes 資料。如以有壓縮功能的G.729a 而言，10ms 訊號只含有10 bytes資料，壓縮比是八倍。這裡特別提醒，有壓縮的編碼標準需要比較長的時間，會造成比較長的延遲時間。

表6.1 是幾個比較有名的編碼標準的參數。

表6.1 編碼標準參數

Codec Bandwidth Packet Delay (ms)
G.711 64kbps 1.0
G.723 6.4 Kbps 67.5
G.729a 8 Kbps 25.0
iLBC 13.3/15 Kbps 30/20

Codec	Bandwidth	Packet Delay (ms)
G.711	64kbps	1.0
G.723	6.4 Kbps	67.5
G.729a	8 Kbps	25.0
iLBC	13.3/15 Kbps	30/20

ITU-T G.729

ITU-T G.729語音壓縮標準技術利用 Conjugate-Structure Algebraic Code Excited Linear Prediction (CS-ACELP)演算法所發展出來的技術，其所用語音 frame 為10ms，所以每一 frame 有80個取樣值(80 bytes)。在每10ms的時間內，語音訊號會被分析，並利用CELP演算法，取出其特性參數，然後編碼成80 bits 的 frame，裡面含有代表那段時域訊號對應於CELP的參數，壓縮比為8:1。通常會將 2 或 3 個frame 封裝在一個封包內，以增加傳輸效率（但增加了延遲時間)。

G.729語音壓縮標準的應用非常廣泛，如VoIP網路閘道、IP電話、視訊會議和電話會議等。ITU當初制定G.729語音壓縮標準時，為了使其具有低位元率、高音質、卻又低複雜度的特性，在G.729演算法中運用了相當多的專利技術，其中大部分的專利為國際各大主要電信業廠商所持有，這些公司包括法國電信(France Telecom)、Universite de Sherbrooke及日本電報電話公司(NTT)。它們於1998年3月組織了G.729專利聯盟，並委由Sipro Lab Telecom公司作為此聯盟的代表，負責處理各專利授權問題。業者必須事先獲得相關專利授權許可，方能合法使用生產ITU-T G.729相關產品。

iLBC

iLBC (internet Low Bitrate Codec) 是一種免授權的編碼標準。 iLBC在有封包遺失的條件下的其性能明顯優於 G.723、G.728、G.729、GSM等標準編碼。

iLBC是為專為提供穩健的IP語音通訊而開發的語音編碼，使用8kHz的取樣率。 iLBC編解碼器支持兩種frame size，在13.3kbps位元率下編碼的 frame size 為30ms，而15.2kbps 位元率下編碼的 frame size 則為20ms。

使用iLBC編碼的封包可以獨立解碼， IP封包丟時，聲音的損失只侷限在丟失的封包上，不會影響其他封包的解碼，因此iLBC抗封包遺失的能力高於其他編碼標準。

Frame Size

表6.2 Frame Size

Sampleing Freq	8000 Samples/Sec
Bits Per Sample	8 bits
Bits Per Second	64 Kbps
G.729 Frame Size (ms)	10ms
G.729 Frame Size (bytes)	80 bytes
G.729 Frame Size (bytes)	10 bytes
iLBC Frame Size (ms)	20/30ms
iLBC Frame Size (bytes)	160/240 bytes
iLBC Frame Size (bytes)	30/40 bytes

6.3 Packetization

編碼完成後，CODEC 輸出為一段一段經過壓縮的frame，這些 frame 必須加上header 一層層包裝成IP 封包才能送到 IP 網路上，再轉送到目的地。包裝時，先由RTP模組將frame 包裝成RTP封包，再由UDP模組包裝成UDP 封包，最後再包裝成 IP 封包。 IP 封包內含有目的地的IP 位址，送到IP網路中時，才能根據IP位址轉送到目的地。到了目的地解開IP 封包之後，交由 UDP 接收模組解開，最後再由RTP接收模組解開得到frame。 Frame 的內容取出後，由Codec解碼得到 PCM 語音碼，最後由音效卡裡的 D2A (digital-to-analog) converter 轉換得回語音訊號。

(A) Frames to Packets

Frame 經過層層包裝之後，變成包裝很厚但內容很少的封包，非常的不經濟，浪費太多頻寬，最好可以將數個frame 包裝在一起，比較節省頻寬，但如此一來會延遲太多時間。試想，如果我們將一整句話的 frame 全部放進封包，那就得等一整句話說完之後，才能進行包裝，再加上網路的延遲時間，那總延遲時間將會非常可觀。因此，一個封包內不能放太多frame。就iLBC 編碼而言，無論是20ms還是30ms 的frame，都只適合放一個frame。而其他使用10ms frame 的編碼，則放2或3個frame，可將等待封裝的時間限制在20ms 或30ms 之內。

圖6.5 包有RTP/UDP/IP header 的封包

RTP 的 header 佔用12 bytes，裡面含有序號及timestamp，如果沒有這些資訊，所收到的UDP封包可能是亂序的。而UDP header 佔用8 bytes，裡面含有兩個端點的socket編號。IP header 則佔用20 bytes，三個header 共佔用 40 bytes。

表6.3 Header Size

Protocol	Size (bytes)
RTP	12
UDP	8
IP	20
Total	40

(B) IP Addressing

VoIP 封包透過 PS Network傳遞到目的地端的某一個 IP 設備。如果目的地端是擁有IP 的電腦(PC-to-PC 或 Phone-to-PC)，則封包直接送到該電腦上，如果是電話(PC-to-Phone 或 Phone-to-Phone) 則封包就送到下車 gateway。接收IP 封包的設備的IP 位址必須填入 IP 封包內，所以當發話端撥一個電話號碼時，必須透過一個位址伺服器找出對應該電話號碼的IP 位址（電腦或gateway）。例如: 電話號碼 070-2345-6789 對應到 IP 位址 192.128.100.2。

參考文獻

U.S. Patent 5664055 ," CS-ACELP speech compression system with adaptive pitch prediction filter gain based on a measure of periodicity", http://www.freepatentsonline.com/5664055.html.
G.729, http://www.itu.int/rec/T-REC-G.729/e
iLBC, http://www.vocal.com/ilbc.html
Echo Cancellation, http://en.wikipedia.org/wiki/Echo_cancellation
Echo Cancellation, 相關網站： http://www2.okisemi.com/site/productscatalog/telecomics/echocancellers/EchoCancellerDesign.html