• 時延（Latency）簡單來說就是因為在語音數(shù)據(jù)傳輸過程中，因為很多中間處理環(huán)境和設(shè)備需要經(jīng)過數(shù)據(jù)處理多次轉(zhuǎn)發(fā)引起的時間延遲。這些數(shù)據(jù)看起來到我們服務(wù)器時非�？欤�事實上，如果經(jīng)過了不同網(wǎng)絡(luò)，不同地區(qū)或者國家，就會導(dǎo)致一個時延。這個時延如果在一定合理的范圍內(nèi)，語音質(zhì)量就不會受影響。但是，如果超出了一定的范圍，語音質(zhì)量就會降低，最后影響了用戶體驗。圖例中介紹了數(shù)模轉(zhuǎn)換消耗的時間，數(shù)據(jù)收發(fā)時間和編碼轉(zhuǎn)換消耗的時間。

• 時延形成的原因。如上圖所示，時延形成的原因很多，它們主要包括模擬語音數(shù)字語音處理過程，網(wǎng)絡(luò)設(shè)備傳輸消耗的時間，網(wǎng)絡(luò)交換路由導(dǎo)致的時延，語音編碼轉(zhuǎn)換消耗的時間。通常情況下，這些都是客觀存在的因素。但是，我們盡可能想辦法降低這些時延帶來的風(fēng)險，例如，建議用戶使用質(zhì)量好的網(wǎng)絡(luò)設(shè)備，盡可能使用同一語音編碼，好的線路。

• 抖動（Jitter）簡單來說就是因為網(wǎng)絡(luò)傳輸過程中，數(shù)據(jù)包發(fā)送時長不一致，不統(tǒng)一，數(shù)據(jù)包大小不一致，導(dǎo)致的語音數(shù)據(jù)狀態(tài)不穩(wěn)定。通常情況下，可能是網(wǎng)絡(luò)傳輸設(shè)備中的路由路徑不同，或者數(shù)據(jù)抵達時間不一致，線路擁塞導(dǎo)致的數(shù)據(jù)不能正常收發(fā)，到達目的地以后數(shù)據(jù)，數(shù)據(jù)包大小不一致。很多時候也可能是時間戳錯誤，服務(wù)器端認(rèn)為是不正確的數(shù)據(jù)包，可能丟棄或者重新發(fā)送。在Asterisk中，幾個通信接口都支持了jitter buffer，采用了buffer 隊列的算法來優(yōu)化抖動問題。用戶可以在sip，IAX或者SS7 的配置文件中做相應(yīng)的調(diào)整。在下面的其中一個圖例中，大家可以看到，正常的低抖動的環(huán)境下，數(shù)據(jù)包大小基本一致（100，100，100）；但是在抖動嚴(yán)重的環(huán)境下，數(shù)據(jù)包大小不一致（50，150，100）。這樣，Asterisk可能丟棄過于小的數(shù)據(jù)包，并且通過Buffer來進行數(shù)據(jù)的優(yōu)化處理。

　　使用開源工具在Asterisk環(huán)境下測試時延的方式。比較幸運的是，開源社區(qū)很多技術(shù)人員已經(jīng)開發(fā)了測試系統(tǒng)時延的一些工具，asterisk 作為一個實時的語音系統(tǒng)，可以作為一個測試手段幫助用戶排查Asterisk服務(wù)器本身的問題。以下是Asterisk 環(huán)境下，使用Linux 工具的安裝運行方式：

• 使用第三方工具排查時延問題。根據(jù)很多用戶建議的說法，一般來說，時延在< 150 ms 是可以接受的范圍；抖動在< 10 ms 以下是可以接受的范圍。這是一個基本的判斷。如果滿足以上兩個條件，基本上一般的語音質(zhì)量都可以得到保障。當(dāng)然，作為專業(yè)的技術(shù)人員，我們建議用戶使用一些專業(yè)的VoIP測試工具來通過數(shù)據(jù)來檢測我們實際的工作環(huán)境。通常情況下，如果用戶環(huán)境需要部署Asterisk時，你可以根據(jù)用戶人數(shù)，網(wǎng)絡(luò)帶寬，語音編碼計算一個合理的結(jié)果。這樣，管理員部署時才能做到心中有數(shù)。

• 其他相關(guān)問題。VoIP領(lǐng)域涉及語音質(zhì)量的因素很多，也包括其他的相關(guān)的問題，例如MOS，Packet Loss，Echo，VAD，Silence Suppression和CNG等等。這些參數(shù)中，有的在Asterisk中本身沒有支持，例如VAD。有的需要終端配合檢查設(shè)置。這些參數(shù)很多時候也影響了語音質(zhì)量，如果用戶需要做一些測試的時，筆者也建議也盡可能考慮這些相關(guān)的參數(shù)。