我了解NAT穿孔，ICE和SIP VOIP呼叫的许多细节。关于这些主题，我已经回答了很多关于SO的问题。现在我有一个问题。
我试图了解在呼叫已经建立之后需要为SIP + ICE记录的RE-INVITE消息。
假设VOIP设备的拓扑结构通过SIP发信号并使用ICE（使用STUN / TURN）建立媒体连接。执行ICE连接检查后，两个端点都应确定最佳地址候选配对（IP，端口），并且应准备好在两个方向上流媒体。
但是我使用SIP和大量文档的经验表明，在被叫方发送200 OK消息以表明他处于应答状态后，调用者将发送一个带有SDP的RE-INVITE，其中包含由所选择的特定地址候选者。连通性检查。
使用ICE描述RE-INVITE的一些链接是here和here（步骤8）。 Rosenberg的tutorial（第30页）讨论了RE-INVITE“确保中间盒具有正确的媒体地址”。我不确定为什么这很重要。
收到RE-INVITE后，被叫方是否会根据收到的新SDP重新配置其ICE堆栈以切换套接字或地址？或者RE-INVITE只是一种协议形式，正式承认呼叫已经建立？如果跳过RE-INVITE步骤并且双方都开始流媒体，那么可能出现什么问题？
我问的原因是因为我正在探索使用ICE而不是SIP的信令服务。我想弄清楚是否需要模拟RE-INVITE。
答案 0 :(得分：5)
可能对ICE协商结果感兴趣的中间件的一个例子是带宽管理器。
想象一下企业部署，其中端点位于公司防火墙内，其他端点在Internet上或私有家庭防火墙后面漫游。部署还包括可公开访问的TURN服务器。然后让我们想象一下公司防火墙内的一个端点正在打电话。如果目的地恰好在同一网络上可达，则呼叫将主机到主机并且将不使用TURN服务器（即，将取消分配绑定）。这是本地网络，不需要施加带宽限制。另一方面，如果呼叫到达漫游端点，则TURN服务器将参与，并且数据将流经公司防火墙，通过可能是有限的带宽上行链路。我们可以想象一些想要限制呼叫带宽的策略。一种方法是让带宽管理器保留在信令路径中（使用SIP记录路由）并查看经过的任何INVITE的SDP，根据媒体地址重写带宽值。
我认为一般意图是，那种不具备ICE意识的传统设备应该继续在引入ICE端点的混合环境中工作。为了保持这种向后兼容性，ICE应该只引入新的处理（STUN检查等），但是从非ICE感知元素的角度来看，它不应该删除任何现有的规则（仍然需要re-INVITE来更改媒体流的目的地）。
答案 1 :(得分：4)
在Rosenberg的教程中，我认为发送re-INVITE是因为ICE选择的套接字与原始SDP AND的媒体和连接（m / c-lines）行中的套接字不同，以便任何网络元素都是在两个用户代理之间通知将要使用的实际套接字RTP，re-INVITE与SDP的媒体和连接线中的ICE选择套接字一起发送。
如果ICE选择的套接字与原始INVITE请求的SDP m / c线路中的套接字相同，则不需要re-INVITE请求。或者，如果您知道没有“中间盒”需要通知RTP套接字的更改，那么也不需要发送re-INVITE。