網路語音／停頓的聲音工程
你停下說話後，通話替房間留了一口氣
深夜打網路電話，你說完一句話，停下來等對方回應。耳機裡沒有立刻變成全黑的寂靜，仍有一層很淡的風扇聲、空調聲，或說不清來源的沙沙聲。這層聲音讓人覺得線路還連著，也讓停頓不像突然被剪斷。
那幾秒不一定把遠端房間的錄音逐格原封不動送到你耳邊。有些啟用語音活動偵測、非連續傳輸與舒適噪音的語音系統，會在有人說話時密集傳送音訊；停話後，系統可能省略部分連續音訊，只留下稀疏的背景描述，或交給編解碼器自己的機制在接收端補出相近底噪。不同通話服務、編解碼器與設定會採用不同方法，以下說的是一種常見設計思路，不是每一通電話的共同承諾。
向下，看聲音如何被抽稀再織回來01／停話先發生在嘴巴，不在房間
房間沒有跟著嘴巴停下來
先回到說話者的桌邊。嘴巴停下來，風扇仍在轉，麥克風也仍能收到房間的聲音。真正改變的不是房間，而是語音系統準備如何處理接下來的聲音。
連續聲音進入編碼器後，會被切成一小段、一小段的音訊框。系統因此能逐段估計：這一格較像人聲，還是較像穩定背景。這個判斷通常稱為語音活動偵測，英文縮寫是 VAD。它不需要理解你說了什麼；它只需要判斷現在是否有值得按語音方式繼續傳送的活動。
- 說話編碼器密集產生語音框，接收端依封包順序與時間連續播放。
- 停話部分系統省略連續背景，只留下稀疏的 SID 或編解碼器內建線索。
- 重建接收端依少量線索生成近似底噪，讓房間感不會突然消失。
02／人聲保留每一段細節
說話時，聲音密集上路
當系統判定有人正在說話，編碼器持續產生語音資料，網路也連續帶走一包又一包音訊。接收端依照封包的順序與時間，把短框排回可播放的聲音。此時你聽見的人聲與背景，大多沿著同一串音訊資料一起抵達。
這條路徑必須足夠密，因為母音、子音、呼吸與短促停連都會改變一句話。省掉太多，人聲就可能破碎。RFC 7587 在描述 Opus 的非連續傳輸時，也明確提醒：若頻寬條件允許，連續傳輸通常能維持較高品質；進入 DTX 雖能再降低傳輸量，聲音品質會有些代價。
03／背景不再逐格上路
停話時，系統開始抽稀
當 VAD 連續把音訊框判成背景，部分系統會進入非連續傳輸，也就是 DTX。這時網路不必繼續把每一格安靜錄音都照原速送走。通用 RTP 舒適噪音格式可以偶爾送出一個 Silence Insertion Descriptor，簡稱 SID；RFC 3389 規定，這種描述至少帶有噪音音量，也可以附帶頻譜資訊。
另一種編解碼器可能把 DTX 與補音方法放在自己的規格裡。以 Opus 的 RTP 格式為例，安靜區間可以不傳送部分編碼訊號，再由接收端的解碼器產生舒適噪音；該規格反而不建議把 RFC 3389 的通用舒適噪音格式直接套在 Opus 上。兩條路做法不同，目的相近：少送重複的安靜資料，同時不要讓播放端突然掉進生硬的數位零。
04／連續感在另一端長回來
接收端把底噪重新織回去
接收端拿到的若是 SID，它得到的不是一段可以直接播放的遠端錄音，而是關於背景的少量線索。RFC 3389 的格式用噪音音量與可選的頻譜資訊描述背景；3GPP 的 AMR-WB 舒適噪音規格也會估計背景能量與頻譜，再把參數放進 SID 框送往接收端。
接收端依這些線索合成一層新的聲音。它不用重演風扇每一片葉片當時造成的細節，只要讓音量與音色接近遠端背景，聽者就不會在每次停話時遭遇突兀的斷崖。3GPP 的規格特別指出，背景聲若隨 DTX 快速出現又消失，會讓聽者感到惱人；在車內等高噪音環境，問題甚至可能妨礙語音理解。
所以，那層淡淡的沙聲可以真實地維持「房間仍在」的感覺，材料卻可能是在你的接收端才生成。它保存的是背景的輪廓，不是遠端房間逐樣本的副本。
05／同樣沒有資料，原因可以完全不同
刻意停話，不能和封包遺失混成同一件事
這裡有一個關鍵轉折：網路沒有送某一段音訊，可能是編碼器刻意進入 DTX，也可能是封包真的在路上遺失。接收端若把兩者混為一談，就可能把故障當成安靜，也可能在正常停頓裡反覆啟動錯誤補償。
RTP 的序號與時間資訊就是分辨線索之一。RFC 3551 說明，接收端可利用序號與時間戳，區分遺失封包與刻意沒有資料的時段；採用靜音抑制的應用，也可在停頓後第一個語音封包上標記新一段話語的開始。Opus 的 RTP 規格則說，接收端可以查看序號是否出現缺口，判斷 DTX 與封包遺失。
這項差別也說明了舒適噪音的邊界。它負責讓正常停頓聽起來連續，不能替網路故障洗白；封包遺失另有錯誤隱藏、前向錯誤更正等處理。3GPP 對 EVS 語音編解碼器的介紹，也把 VAD、舒適噪音與遺失封包的錯誤隱藏列成不同功能。
停話中：網路帶只留下兩個 SID／背景描述節點，標示音量與頻譜；接收端依線索生成連續底噪。
- 說話中：密集語音框連續上路，接收端播放遠端音訊。
- 停話中：只留下稀疏背景描述，接收端依線索生成連續底噪。
- 封包遺失：序號出現跳號，接收端需啟動錯誤隱藏、修復或其他處理。
06／回到深夜的風扇
安靜是一個播放決定
回到深夜那台風扇。你停下說話後，耳機裡留下的一口房間聲，可能來自仍在連續傳送的音訊，也可能是遠端偶爾送來背景描述，再由你的裝置補出的近似底噪。只靠耳朵，無法替某一個 App 判定它當下使用哪一種編解碼器、是否啟用 DTX，或實際傳了多少資料。
但你可以重新理解那段停頓：通話裡的安靜不只是一個空白。它是發送端判斷、網路取捨與接收端播放共同做出的結果。採用這類設計的系統省下重複的聲音資料，也用一層經過重建的房間呼吸，告訴你連線尚未從耳邊消失。
資料來源與事實邊界
- IETF RFC 3389〈Real-time Transport Protocol (RTP) Payload for Comfort Noise〉：通用 RTP 舒適噪音 payload、SID 的噪音音量與可選頻譜資訊。
- IETF RFC 3551〈RTP Profile for Audio and Video Conferences with Minimal Control〉：靜音抑制期間的 RTP 序號、時間戳與 talkspurt marker 行為。
- IETF RFC 7587〈RTP Payload Format for the Opus Speech and Audio Codec〉：Opus 的連續傳輸、DTX、接收端舒適噪音及其品質取捨。
- 3GPP TS 26.192〈AMR Wideband Speech Codec; Comfort Noise Aspects〉與 3GPP EVS 官方介紹：SID 背景參數、接收端合成及 CNG／錯誤隱藏的功能邊界。
本文說明標準中可採用的設計，不聲稱每個通話服務都啟用 DTX 或使用同一種舒適噪音方法；特定 App 的實際行為仍須看它當下使用的編解碼器、設定與實作。
