UAC 应如何处理 SIP 183 会话进度

UAC 应如何处理 SIP 183 会话进度

我有以下情况:

2 UAC 正在尝试通过远程 SIP 服务器 (openSER/Kamailio 3.1.3) = 客户端基础架构进行通话。UAC 软件是在使用 Asterisk 的本地测试基础架构上开发的,在该基础架构上可以建立正常通话。

问题在于在客户端基础设施上测试时没有音频。

我不了解完整的客户端基础架构,但从服务器的日志/响应(路由标头字段)可以得出结论,有一个代理授权服务器、一个 CiscoSystem SIP GW 以及 PSTN。而且,我们位于 NAT 后面,客户端也位于 NAT 后面。据我所知,没有使用 STUN 服务器。

呼叫流程的主要区别在于,在测试基础设施中我们总是收到 180 消息(振铃),而在客户端基础设施中我们收到 183 会话正在进行中。在日志中可以看到两个设备都开始发送 rtp 流,但仍然没有音频。

我还有一个商业软件,我们用它测试了客户端基础设施,它运行良好。我们比较了商业软件和我们客户端发送的消息,几乎没有区别。

我能找到的唯一区别是在 inv/407/ack 循环之后的消息中:

商业软件:

开始新的分支号 x

  • 发送 inv + auth 字符串 - 分支/交易编号 x

  • 获得响应 - 分支/交易号 x

  • 发送确认消息 - 分支/传输号 x

我们的客户:

开始新的分支号 y

  • 发送 inv + auth 字符串 - 分支/交易数字 y

  • 获得响应 - 分支/交易号 y

  • 发送确认消息 - 一个新的分支/交易 - z

这可能是导致音频丢失的原因吗?同样的情况在 Asterisk 中也可以正常进行。

答案1

(我假设所涉及的实体是 RFC 3261 SIP 设备,并且忽略了与 RFC 2543 设备的互操作。)

如果涉及 NAT,你应该检查的第一件事是

  • c=SDP 负载标头中的 IP
  • Contact标头中的 IP

具体来说,这些 IP 都应该可以被对方访问。

在“inv/407/ack 之后”场景中,对非 2xx 响应的 ACK 应该具有相同的branchID。但是,2xx 响应终止INVITE 事务,因此对 2xx 响应的 ACK 将具有不同的 branch与 INVITE 相同。

(当然RFC 3261是 SIP 基础知识的权威资源,我发现RFC 3665对于了解事物的工作原理非常有帮助。

相关内容