单向音频呼叫故障排除

单向音频呼叫故障排除

---

在媒体/RTP 方面，最常见的问题之一是所谓的“单向音频”，或者“一方听不到另一方的声音，但反之亦然”。

那么，让我们探讨一下如何解决此类问题。但首先，我们需要了解在 SIP 呼叫期间如何协商和设置媒体/RTP 流 - 这对于了解在出现问题时应在何处查找非常相关。

RTP 流量如何设置

让我们看一下呼叫者/UAC 通过 SIP 代理呼叫被叫者/UAS 的典型呼叫流程。UAC具有**IP** A，而UAS具有_IP B。_

一切都从 UAC 向被叫方发送 SIP INVITE 开始（当然是通过代理）。从媒体角度来看，UAC 将在 SDP（附加到 INVITE）中描述它希望在何处接收 RTP：IP 和端口。在我们的例子中，UAC 将通告**IP A和端口 X**以从另一方接收 RTP/媒体。

当被叫/UAS 收到 SIP INVITE 时，UAS 将在收到的 SDP 中包含有关将其 RTP 发送到何处的信息 – 因此 UAS 将知道它必须将 RTP 发送到**IP A和端口 X**（基于 SDP）通过 SIP INVITE 收到）

因此，我们有 RTP 从 UAS 流向 UAC（红色底线）的事实是因为从 UAC 收到的 INVITE 中的 SDP。

现在，当 UAS 应答呼叫时，将为收到的 INVITE 生成 200 OK SIP 回复。以类似的方式，UAS 将在 SDP（附加到 200 OK）中描述它想要在哪里接收 RTP：IP 和端口。在我们的例子中，UAS 将通告**IP B和端口 Y**以从 UAC 方接收 RTP/媒体。

现在，当呼叫者/UAC 收到返回的 200 OK 时，UAC 将在收到的 SDP 中包含有关将其 RTP 发送到何处的信息 – 因此 UAC 将知道它必须将 RTP 发送到**IP B和端口 Y**（基于在通过 200 OK 收到的 SDP 上）

因此，我们有 RTP 从 UAC 流向 UAS（绿色底线）的事实是因为从 UAC 收到 200 OK 中的 SDP。

以下是双向 RTP 信息交换以及生成的 RTP 流的最终图片：

注意：实际上，两个 RTP 流在信令会话完全设置后启动，因此 RTP 将在 200 OK 后双向运行。这里进行分离是为了提供 RTP 流和信令之间清晰的“因果”关系。

---

去哪里看？

现在很清楚在哪里查找是否缺少其中一个 RTP/音频流：

• 如果呼叫者/UAC没有音频，则意味着它发送到UAS的SDP（RTP信息）有问题——因此我们需要检查INVITE请求中的SDP。
• 如果被叫/UAS没有音频，则意味着它发送给UAC的SDP（RTP信息）有问题——因此我们需要检查200 OK回复中的SDP。

---

要检查什么

假设 SIP 部分工作正常，并且在呼叫建立期间没有丢失 SDP。那么，让我们重点关注SDP内部的信息。从这个角度来看，缺少音频意味着无效的SDP信息（IP和端口）。

那么，让我们看一下 SDP，看看如何找到 RTP IP 和端口：

......<span></span>
s=-<span></span>
c=IN IP4 1.2.3.4<span></span>
t=0 0<span></span>
m=audio 31310 RTP/SAVP 8 0 101<span></span>
a=rtpmap:8 PCMA/8000<span></span>
a=rtpmap:0 PCMU/8000<span></span>
.....

“c”行保存 IP 地址（此处为 1.2.3.4），而“m”行保存端口（此处为 31310）。请注意，如果存在多个 RTP 流（如音频和视频），SDP 可能具有多个“c”和“m”对。

为什么 SDP 信息无效？

无效的 SDP 信息（从 RTP 坐标角度来看）意味着 SDP 中通告的 IP 和端口是错误的。但这样的事情怎么会发生呢？

在大多数情况下，是因为NAT 的存在– UAC 或 UAS 位于用户 NAT 后面，因此设备将在 SDP 中通告RTP 的专用 IP。当然，呼叫中的另一方将无法将 RTP 发送到 NAT 后面的私有 IP。

为了处理这种情况，您需要实现对 NAT 穿越的支持，例如 STUN、TURN 或 COMEDIA，通常都在 SIP 代理端（以帮助终端设备穿越其 NAT）。这是我们在OpenSIPS 训练营培训期间教授的内容。

NAT 的存在是最常见的原因，但我们不应该忽视其他原因，例如：

• SIP ALG 干扰– 这与 NAT 场景有关，其中 SIP UA 位于执行 NAT 和 SIP ALG（应用层网关）的路由器后面。通常，SIP ALG 应该帮助 UA 穿越 NAT，但在大多数情况下（由于其对 SIP 协议的理解有限），它最终会在 SDP 上进行不正确的尝试。即使 ALG 将 SDP 中的私有 IP 更改为 NAT/路由器的公共 IP，它也无法正确地正确替换 SDP 端口或保持 NAT 针孔打开。处理此问题的最佳方法是实际尝试禁用路由器中的 SIP ALG 支持；
• 错误的 RTP 中继插入– 路径上的某些 SIP 代理尝试在媒体路径中插入媒体中继（如 rtprelay 上的 rtproxy），但它以错误的方式插入，例如可能不对称（在两个方向上），或者依赖会话设置不正确等。
• 防火墙存在- 即使实际的 SDP 信息正确，有时防火墙也可能会阻止设备接收传入的 RTP，因此值得检查。

---

结论

当遇到单向音频问题时，识别与丢失的 RTP 流相关的 SDP，检查 IP 和端口信息是否可路由。如果不是（私有 IP），则可能存在 NAT 问题。如果是，请检查 SDP IP 指向的位置并调查这是否是可以以某种方式将流量路由到静默设备的有效跃点。