问题标签 [ice-protocol]

我正在用 C 语言开发一个小型 webrtc 应用程序。我正在使用 sip 信令进行 webrtc 调用。我对 stun/turn/ice 的使用有以下疑问。

当我开始通话时，我会发送带有提议 (SDP) 的邀请。在 SDP 中，我们需要放置 ICE 候选人。

我有两种可能的情况。为了解释它，我将举一个例子。假设两个端点是A和B。我有一个 sip 代理服务器说P。另外我有一个转弯服务器（支持眩晕和转弯），说它是T。

情况 1
所有实体A、B、P和T都在同一个专用网络中。这里需要 STUN 分辨率吗？如果是，那么我需要处理的所有眩晕请求/响应是什么？

案例 2
这里A在专用网络中。其他实体B、P和T在公共网络中。在这种情况下，我希望我们需要进行 STUN/TURN 解析。假设我从 STUN 开始，并获得了主持人和反身候选人。我在一些例子中看到，Permission，Channel Bind请求也被使用。如果我只使用 STUN（没有 TURN），在我得到主持人和反思候选人之后，我需要做任何额外的事情吗？

除此之外，是否有任何好的开源可用于 C 中使用 gnutls（无 openssl）的 stun/turn 客户端？

相关的 WebRTC，ICE 协议给出了哪对地址将用于地址对之间的直接媒体传输。

设 A 和 B 是两个端点

1. 为了选择用于 A 和 B 之间直接通信的地址，A 首先收集候选者，对候选者属性进行编码，对 SDP 提议消息进行编码，并将其发送到另一个端点。

2. 当 B 收到 A 的 offer 消息时，B 收集候选人，用自己的候选人列表对 SDP 回答消息进行编码，并将其发送给 A。

3. 在此过程结束时，每个代理都有本地候选人和远程候选人的完整列表。它将它们配对，从而产生候选对。要查看哪对有效，每个代理使用 STUN req/resp 执行连接检查。

执行多少次连通性检查以提名有效的候选对？

关于 webRTC 调用，剩下的 ICE 连接检查是什么？

要为 webRTC 调用开发 ICE 模块，我必须遵循 RFC5245 中的每个步骤或其他任何内容？

我有一个 WebRTC MCU ( kurento ) 在公共 IP 地址上运行，为一些只发送或只接收音频的客户端提供服务所以每个客户端都直接与具有公共 IP 地址的 MCU（而不是彼此）连接。

Q1：是否还需要使用 STUN 和 TURN 进行 NAT 穿越？？如果是这样为什么？
Q2：浏览器中的 WebRTC 是否有任何 hack 可以消除 STUN 和 TURN 的需要？

在我看来：大多数客户端-服务器架构对 NAT 后面的客户端没有任何困难。与 webrtc 有什么区别？

在 Webrtc 调用中，我使用 sip 信令和 sdp 进行媒体参数协商。

在通话开始之前，我进行了一个 stun-bind 事务并获得了自反候选人。除了基础和主机候选人之外，我还把这些反身候选人放在了 sdp 中。

一旦我们为 Invite 获得 200 OK，我们就需要启动媒体。对于媒体开始，我需要知道我需要使用哪个候选对。

我希望确定我需要使用哪个候选对，我们需要进行连通性检查。我不确定如何进行连接检查（例如要发送的消息……等）。

有人可以帮助我理解这一点。

还有一个开源（c，基于 linux），它提供了 ice/stun/turn 支持。

我需要测试 STUN/TURN/ICE 协议，是否有任何现有的测试框架。就像 SIPp 可以测试 SIP 场景一样，建议任何与 STUN/TURN/ICE 协议类似的东西。

我正在编写一个 WebRTC 应用程序，尽管在我的局域网内一切正常。ICE Failed但是，当对等方位于不同的网络上时，我会遇到错误。

我的 STUN 服务器返回公共 IP 候选者，所以我认为它设置正确。问题是候选 IP 没有“正确配对”。浏览器总是尝试将一个公共 IP 与一个私有 IP 连接，因此连接失败（请参阅候选对）。

这里可能是什么问题？信令服务器或rtcpeerconnection配置？

我们每次想向其他设备发送媒体消息时都需要使用STUN 服务器还是第一次使用它？

因为在我们发送第一条消息后，我们就知道了我们的公共 IP 地址。

我的意思是，如果我们第一次只需要STUN 服务器（以获取公共 IP 地址），那么如果我们在传输消息期间STUN 服务器停机，我们什么都不关心。

所以，我正在尝试webrtc video chat使用peer.js. 到目前为止一切顺利，一切似乎都正常。当我在我的私人服务器上运行我的应用程序时，问题就开始了。

每次我尝试接听或拨打电话时，视频开始播放几秒钟，但出现黑屏，然后我收到ICE Failed错误并断开连接。

如果两个用户共享相同的 IP 地址，则不会发生这种情况。如果用户共享相同的 ip，则视频聊天可以正常工作，完全没有问题。

这里可能是什么问题？

更新

我添加了 stun 并打开对等服务器，但我再次遇到同样的错误

这是关于由于 ICE 协商导致的 webrtc 呼叫建立延迟。我正在尝试进行音频通话，然后启用视频。一个新的视频流被添加到现有的对等连接中，并且为音频和视频轨道收集了 ICE 候选者。重新谈判开始。RE-INVITE 中的 SDP 有新的 ICE 候选音频和视频轨道。

为什么我们不能将 ICE 候选用于在初始音频通话期间已经存在的音轨？为什么要再次收集 ICE 候选人？

有问题的三个设备。

1. NAT 后面的 VoIP 电话
2. 我自己在 EC2 实例上的 Kamailio 服务器。
3. 我手机上的 Android 版 Linphone 应用程序。

我的手机在移动数据上，因为我有一个 MVNO，它似乎也被 NAT 过（私有 IP，如 192.0.0.X）。

我的问题是，虽然 SIP 信令工作得很好，但我无法让任一设备接收对方的 RTP 媒体流。

我在 kamailio.cfg 中定义了 WITH_NAT，但它似乎对收集候选人没有帮助。这是通过 Kamailio 之前和之后的邀请。

前：

后：

入站电话也是如此。

我期待 nathelper 模块添加类似

但显然不是。我可以修改o=并c=在标头中使用服务器收到邀请的 IP，但是服务器如何知道 RTP 媒体应该发送到哪些端口？服务器可以知道 的唯一端口是

1. 发送邀请的端口（私人和公共方面）
2. sdp 中提供的端口。但这些都是私人的。他们在公共方面肯定会有所不同吗？

对此的任何帮助将不胜感激。