IP 電話廣泛應用於企業通訊、調度系統、客服中心、校園、工業現場、飯店及公共服務網路。大多數現代 IP 電話使用 SIP 協定，這使得它們易於註冊到 SIP 伺服器、IP PBX 平台、軟交換系統和統一通訊平台。然而，在部署過程中可能出現一個常見問題：單向音訊。
單向音訊表示通話已接通，但只有一方能聽到另一方。SIP 信令可能看似正常，電話會響鈴，通話也能成功接聽，但語音串流未能正確地雙向傳輸。此問題通常與 NAT、RTP 傳輸、防火牆政策、SIP ALG、編解碼協商、終端設定或伺服器媒體設定有關。
從信令與媒體的差異開始
SIP 電話通話包含兩個重要部分：信令與媒體。SIP 信令用於註冊、撥號、響鈴、通話建立及通話拆線。RTP 則用於在通話建立後傳輸實際的語音串流。此差異是理解單向音訊為何發生的關鍵。
許多情況下，SIP 部分是成功的，因為網路允許預設的 SIP 連接埠（通常是 UDP 或 TCP 5060）。電話可以正常註冊、撥號及接聽。但用於語音的 RTP 連接埠與 SIP 信令連接埠不同。如果 RTP 路徑被阻擋、路由錯誤、轉換不正確或發送到錯誤的 IP 位址，通話可能會接通卻沒有正常的雙向語音。
因此，故障排除不應止於 SIP 註冊狀態。成功註冊的電話仍可能有媒體問題。工程師應檢查通話期間雙方是否都能發送和接收 RTP 封包。
NAT 是音訊方向問題的常見來源
NAT 允許區域網路內的裝置透過公用 IP 位址存取外部網路。這在企業辦公室、分支機構、飯店、工廠及遠端地點很常見。當 IP 電話或 SIP 伺服器位於 NAT 後面時，裝置可能會在 SIP 或 SDP 資訊中宣告私有 IP 位址。遠端方隨後可能會嘗試將 RTP 封包發送到無法連線的私有位址。
這是單向音訊最常見的原因之一，特別是當 SIP 伺服器部署在公用網路上而 IP 電話位於不同 LAN 環境時。通話可能已建立，但媒體串流無法返回到正確的內部裝置。
為了解決此問題，部署應採用適當的 NAT 穿透設計。常見方法包括 STUN、TURN、對稱式 RTP、公用位址映射、連接埠轉送、SBC 部署，或透過 SIP 伺服器進行媒體中繼。最佳選擇取決於網路拓撲，以及系統是部署在私有網路內、跨公用網路還是多個分支站點之間。
防火牆規則必須包含 RTP 流量
防火牆政策是單向音訊的另一個常見原因。許多管理員僅開放了 SIP 信令連接埠，卻忽略了 RTP 連接埠範圍。結果是電話可以註冊、通話可以建立，但語音封包無法通過防火牆。
RTP 通常使用 UDP 連接埠。連接埠範圍取決於電話、PBX、SIP 伺服器、SBC 或媒體平台的設定。在許多 SIP 環境中，RTP 可能使用如 UDP 16384-32768 的範圍，或系統管理員定義的其他自訂範圍。應在電話設定與伺服器設定中檢查確切的範圍。
為了獲得可靠的雙向音訊，防火牆規則應允許所需的 UDP 媒體連接埠雙向通行。如果部署涉及多個 VLAN、VPN 通道、分支路由器、雲端伺服器或公用 IP 映射，則應檢查每個網段。單一被阻擋的網段就可能造成單向或無音訊的症狀。
RTP 路由需要清晰的媒體路徑
IP 電話語音由 RTP 串流承載。如果 RTP 目的地位址、來源位址、連接埠或路由路徑不正確，音訊可能只會在單一方向運作。這不僅可能發生在公用網路場景，也可能發生在私有 LAN 內部。
例如，電話與伺服器可能使用不同的 RTP 連接埠範圍，或者伺服器預期媒體要經過媒體代理，而終端卻嘗試直接將媒體發送到另一支電話。有些系統支援終端間的直連媒體，而另一些則要求所有 RTP 流量都經過伺服器或 SBC。如果此模式設定錯誤，就可能出現單向音訊。
在部署期間，專案團隊應確認語音路徑是終端對終端、終端對伺服器還是終端對 SBC。通話流程中的所有裝置都應使用可達的 IP 位址和相容的 RTP 連接埠設定。
SIP ALG 既能幫助也可能破壞通話
許多路由器和防火牆包含 SIP ALG 功能。它旨在檢查和修改 SIP 封包，使 SIP 流量更容易通過 NAT。理論上這聽起來很有用。實務上，SIP ALG 有時會錯誤地修改 SIP 或 SDP 資訊，導致單向音訊、通話失敗或註冊不穩定。
如果網路已使用適當的 SBC、公用位址映射、STUN 或媒體中繼機制，SIP ALG 可能會變得多餘甚至有害。在許多故障排除案例中，在路由器或防火牆上停用 SIP ALG 可以解決單向音訊問題。
正確的選擇取決於網路設計。如果使用 SIP ALG，應仔細測試。如果系統已有受控的 NAT 穿透方法，停用 SIP ALG 通常是較佳的選項。
編解碼協商應保持一致
IP 電話通常支援多種語音編解碼，如 G.711、G.729、G.722 及其他音訊格式。這些編解碼在 SIP 協商過程中選定。如果雙方沒有共同的相容編解碼，通話可能會出現無音訊、音訊失真或媒體行為不穩定的情況。
編解碼不匹配不一定是單向音訊的首要原因，但仍應檢查。當來自不同供應商的電話、軟體電話、閘道器、PBX 平台和錄音系統一起使用時，這一點尤其重要。
一個實用的解決方案是在所有裝置中優先採用常見的編解碼。例如，G.711 因其簡單性和語音品質常在 LAN 環境中使用，而當頻寬有限時可能會使用壓縮編解碼。編解碼策略應與實際網路狀況相符。
電話端設定不容忽視
有些單向音訊問題是由終端設定引起的。IP 電話可能有錯誤的 RTP 連接埠設定、NAT 模式、SIP 帳戶設定、媒體中繼選項、本地網路介面設定或編解碼優先順序。在某些情況下，電話也可能被靜音、話筒線鬆脫，或者喇叭和麥克風設定不正確。
當只有一支或幾支電話出現問題時，終端比對法很有用。工程師可以比較正常運作的電話與有問題的電話，檢查 SIP 帳戶設定、網路位址、RTP 連接埠範圍、編解碼清單、NAT 穿透模式、韌體版本及音訊裝置狀態。
這種方法通常比立即更改全域伺服器設定更快。如果問題僅限於單一終端，根本原因通常更接近該終端或其本地網路。
伺服器與媒體代理設定影響所有通話
SIP 伺服器設定也可能導致單向音訊。媒體伺服器位址、RTP 代理模式、外部 IP 位址、內部 IP 位址、連接埠範圍、直連媒體政策、NAT 處理及中繼設定等都會影響 RTP 路徑。
應謹慎調整這些設定，因為全域伺服器變更可能會同時影響許多使用者。如果只有部分電話出現單向音訊，最好先分析網路拓撲與終端設定，再變更核心伺服器參數。
當問題複雜時，封包擷取與伺服器日誌很有用。透過檢查 SIP/SDP 資訊與 RTP 封包流，工程師可以看到正在通告的 IP 位址和連接埠、RTP 串流發送到何處，以及對方是否收到。
多網路介面可能將媒體發往錯誤方向
有些 IP 電話、SIP 伺服器、閘道器或通訊平台具有多個網路介面。例如，伺服器可能有一個介面用於 LAN，另一個用於公用網路，還有一個用於管理網路。如果媒體服務選擇了錯誤的介面，RTP 封包可能會被發送到錯誤的路徑。
這可能造成一種情況：信令看似正常，但音訊無法正確返回。裝置可能在 SDP 中通告了錯誤的 IP 位址，或者從非預期的網路介面發送 RTP 封包。
為防止此問題，專案團隊應確認正確的繫結位址、路由表、預設閘道、媒體介面及 NAT 映射。多網卡環境應在部署時清楚記錄。
實用的故障排除流程
結構化的故障排除流程優於隨機更改參數。首先，確認問題是發生在所有通話上還是僅特定電話。其次，檢查受影響的通話是內部、外部、跨站點、基於 VPN 還是公用網路通話。第三，驗證 SIP 註冊與通話建立是否正常。
之後，聚焦於 RTP。檢查防火牆政策、RTP 連接埠範圍、NAT 穿透設定、SIP ALG 狀態、編解碼協商、媒體中繼模式及伺服器外部 IP 設定。如果問題仍不明確，使用封包擷取來確認通話期間 RTP 封包是否雙向發送和接收。
良好的故障排除基於通話路徑。一旦完整路徑清晰，單向音訊問題就更容易定位。
規劃穩定的雙向音訊
最好的解決方案是在設計階段就降低單向音訊發生的機率。對於小型 LAN 部署，保持網路簡單，並確保電話、PBX 和閘道器使用一致的 RTP 設定。對於多站點部署，在安裝電話之前規劃 NAT 穿透、防火牆規則、VPN 路由及 SBC 位置。
對於公用網路或雲端 PBX 部署，通常最好使用媒體中繼或 SBC 來控制 RTP 路徑。這樣可以避免許多與 NAT 相關的問題，並提高不同網路環境之間的相容性。
文件記錄也很重要。應記錄 SIP 連接埠、RTP 連接埠範圍、編解碼政策、NAT 方法、伺服器 IP 位址、媒體代理設定及防火牆規則，以便日後維護。
結論
IP 電話系統中的單向音訊通常不是由單一固定問題引起的。它可能來自 NAT 轉換、RTP 連接埠被阻擋、防火牆政策錯誤、SIP ALG 干擾、編解碼不匹配、終端設定、伺服器媒體設定或多網路介面路由。
一個好的解決方案始於理解 SIP 信令與 RTP 媒體之間的差異。註冊和撥號可能正常運作，但語音傳輸卻失敗。透過逐步檢查媒體路徑，專案團隊可以更快地定位問題，並建立更穩定的 IP 語音通訊系統。
常見問題
為什麼 IP 電話可以成功註冊但仍然沒有雙向音訊？
註冊使用 SIP 信令，而語音使用 RTP 媒體。如果 SIP 被允許但 RTP 連接埠或媒體路由被阻擋，電話可以註冊但音訊可能失敗。
是否應該永遠停用 SIP ALG？
並非總是如此，但應仔細測試。如果系統已經使用 SBC、媒體中繼、STUN 或適當的 NAT 映射，停用 SIP ALG 通常能提高穩定性。
確認 RTP 問題的最快方法是什麼？
封包擷取是最快的技術方法。它可以顯示通話期間 RTP 封包是否雙向發送和接收。
編解碼不匹配會導致單向音訊嗎？
會。編解碼不匹配可能導致無音訊、單向音訊或異常語音行為，尤其是在混合供應商的 SIP 環境中。
單向音訊通常是硬體故障嗎？
通常不是。大多數情況是由設定、網路路由、防火牆規則、NAT 處理或媒體設定引起的。在排除常見設定原因後，才應檢查硬體故障。
問題解決後應該記錄什麼？
記錄 SIP 連接埠、RTP 連接埠範圍、NAT 方法、編解碼政策、伺服器媒體設定、防火牆規則以及最終的正常運作拓撲，以便日後維護。
