5

我了解 NAT 打孔、ICE 和 SIP VOIP 呼叫的许多细节。我已经在这些主题上回答了很多关于 SO 的问题。现在我有一个问题。

我试图了解在呼叫建立后记录为 SIP+ICE 的 RE-INVITE 消息的需求。

假设 VOIP 设备的拓扑结构通过 SIP 发出信号并使用 ICE（带有 STUN/TURN）来建立媒体连接。执行 ICE 连接检查后，两个端点都应该确定最佳地址候选配对（IP、端口），并且应该准备好双向流媒体。

但是我在 SIP 方面的经验和大量文档表明，在被叫方发送 200 OK 消息以表明他处于已应答状态后，呼叫者应该发送带有 SDP 的 RE-INVITE，其中包含通过连接检查选择的特定地址候选者.

一些描述使用 ICE 重新邀请的链接在此处和此处（第 8 步）。Rosenberg 的教程（第 30 页）讨论了 RE-INVITE “确保中间盒具有正确的媒体地址”。我不确定为什么这很重要。

收到 RE-INVITE 后，被调用者是否需要重新配置其 ICE 堆栈以根据收到的新 SDP 切换套接字或地址？还是 RE-INVITE 只是正式确认呼叫已建立的协议形式？如果跳过 RE-INVITE 步骤，双方都开始流媒体，会出现什么问题？

我问的原因是因为我正在探索在不是 SIP 的信令服务上使用 ICE。我试图弄清楚是否需要模拟 RE-INVITE。

4

2 回答 2

5

可能对 ICE 协商结果感兴趣的中间盒的一个示例是带宽管理器。

想象一下企业部署，端点位于企业防火墙内，其他端点在 Internet 上漫游，或位于私人家庭防火墙之后。该部署还包括一个可公开访问的 TURN 服务器。然后让我们想象一下公司防火墙内的一个端点进行呼叫。如果目的地碰巧在同一个网络上可达，呼叫将通过主机到主机，并且不会使用 TURN 服务器（即绑定将被解除分配）。这是一个本地网络，不需要施加带宽限制。另一方面，如果呼叫发送到漫游端点，则 TURN 服务器将参与其中，数据将通过公司防火墙，通过可能是带宽有限的上行链路。我们可以很好地想象一些想要限制呼叫带宽的策略。一种方法，

我相信总体意图是，那种不知道 ICE 的遗留设备应该继续在引入 ICE 端点的混合环境中工作。为了保持这种向后兼容性，ICE 应该只引入新的处理（STUN 检查等），但从非 ICE 感知元素的角度来看，它不应该删除任何现有规则（仍然需要重新邀请来更改媒体流的目的地）。

于 2013-04-15T15:10:27.083 回答
4

在 Rosenberg 的教程中，我相信发送 re-INVITE 是因为 ICE 选择的套接字与原始 SDP 的媒体和连接（m/c 线）线中的套接字不同，并且对于介于两者之间的任何网络元素，两个用户代理将被告知将要使用的实际套接字 RTP 一个 re-INVITE 与媒体和 SDP 的连接线中的 ICE 选择的套接字一起发送。

如果 ICE 选择的套接字与原始 INVITE 请求的 SDP m/c 行中的套接字相同，则不需要重新邀请请求。或者，如果您知道没有需要通知 RTP 套接字更改的“中间盒”，那么也无需发送重新邀请。

于 2013-04-10T23:32:27.663 回答