p2p - 对于 ICE，SIP RE-INVITE 的需求是什么？

Question

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

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

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

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

一些描述使用 ICE 重新邀请的链接是 here和 here (第 8 步)。罗森伯格的 tutorial (第 30 页)讨论了 RE-INVITE “确保中间盒具有正确的媒体地址”。我不确定为什么这很重要。

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

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

Answer 1

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

想象一下企业部署，端点位于企业防火墙内，其他端点在 Internet 上漫游，或位于私有(private)家庭防火墙之后。该部署还包括一个可公开访问的 TURN 服务器。然后让我们想象一下公司防火墙内的一个端点进行调用。如果目的地碰巧在同一网络上可达，调用将通过主机到主机，并且不会使用 TURN 服务器(即绑定(bind)将被取消分配)。这是一个本地网络，不需要施加带宽限制。另一方面，如果调用发送到漫游端点，则 TURN 服务器将参与其中，数据将通过公司防火墙，通过可能是带宽有限的上行链路。我们可以很好地想象一些想要限制调用带宽的策略。一种方法是让带宽管理器保留在信令路径中(使用 SIP 记录路由)并查看任何通过的 INVITE 的 SDP，根据媒体地址重写带宽值。

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