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 方法、编解码策略、服务器媒体设置、防火墙规则以及最终的正常工作拓扑，以便日后维护。
