Android webrtc 上的 Ice-Lite
Ice-Lite on Android webrtc
我想在 Android webrtc 中使用 Ice-Lite。
我想知道
- Ice-Lite 是服务器端组件还是客户端？
- Ice-Lite 是如何在 Android 上实现的？
- 如果使用 Ice-Lite，我们还需要 STUN 服务器吗？
- 当 Ice-Lite 用于 Android 时，ice-candidate 如何嵌入到 SDP 中？
我尝试在 c=IN IP4 0.0.0.0 之后在 SDP 中插入 a=ice-lite 并仅将 STUN 服务器传递给 RTCConfig 但这似乎不起作用！另外，我是在IceGathering 结束后才发送offer 和answer 的。
要为 Android 实施 Ice-Lite，我需要做些什么吗？
谢谢！
啊抱歉，我搞砸了 ICE 的 Aggressive 提名和 ICE-Lite。以下答案适用于 ICE 激进的提名程序。只需将这些视为附加信息即可。积极提名是一个程序，它定义调用者应如何通过发送 USE-CANDIDATE 来最终确定选定的候选人。
正确答案post：
在 ICE lite 过程中，客户端不会收集所有候选者，而只会收集本地主机候选者。这基本上是为 public IP 地址后面的端点设计的，当客户端在没有 NAT 的 public IP 后面时，它可以与任何其他候选者连接，即使另一端在后面对称 NAT。 ICE-Lite 不需要 STUN/TURN 服务器。您无法使用 SDP 线路实现此目的，因为在您获得候选人之前，ICE-Lite 程序首先出现。因此，如果您不设置 STUN/TURN 服务器，那么它将作为 ICE-Lite 工作（尽管它不是拥有 ICE-lite 的正式方式，ICE 客户端应该具有设置 ICE-Full 或 ICE-Lite 的定义方式）和现在一样，它只会收集主持人候选人。但是，如果您的端点位于某个 NAT 后面，而其他端点不在网络中，那么它将无法工作。如果您能确定客户端是否落后于 public IP 则更好。
您应该阅读 RFC 5245，它以非常易读的术语描述了 ICE-lite。
ICE-lite 预计只是完整 ICE 实施的垫脚石。如果端点具有完整的实现，则该端点可能不支持 ICE-lite 操作。
In order for ICE to be used in a call, both agents need to support
it. However, certain agents will always be connected to the public
Internet and have a public IP address at which it can receive packets
from any correspondent. To make it easier for these devices to
support ICE, ICE defines a special type of implementation called LITE
(in contrast to the normal FULL implementation). A lite
implementation doesn't gather candidates; it includes only host
candidates for any media stream. Lite agents do not generate
connectivity checks or run the state machines, though they need to be
able to respond to connectivity checks. When a lite implementation
connects with a full implementation, the full agent takes the role of
the controlling agent, and the lite agent takes on the controlled
role. When two lite implementations connect, no checks are sent.
For guidance on when a lite implementation is appropriate, see the
discussion in Appendix A.
It is important to note that the lite implementation was added to
this specification to provide a stepping stone to full
implementation. Even for devices that are always connected to the
public Internet, a full implementation is preferable if achievable.
ICE-lite 是您在服务器上会 运行 的东西。如果您的服务器使用 ICE-lite 并且您可以将服务器配置为发送可达地址，则无需 STUN 即可逃脱。
我认为 Android 没有 ICE-lite 实现。 Android 设备预计会更改地址，并且 Android 已经具有完整的 ICE，因此为 Android.
使用 ICE-lite 似乎没有什么意义
Ice-Lite 是服务器端组件还是客户端？
都没有。 ICE 独立于 "side"，因为它是为 p2p 制作的，所以在规范中一切都称为 "client"。但是，鉴于它仅用于具有持久静态 public IP 的客户端（对于在 public 互联网上运行的客户端-服务器连接中所谓的客户端，这种情况极为罕见）它实际上仅适用于网关和服务器。
Ice-Lite 是如何在 Android 上实现的？
不是。但是，有几个库实现了规范（lib nice，....）。
如果使用 Ice-Lite，我们还需要 STUN 服务器吗？
是和否。您不需要 STUN 服务器来在 public IP 上的客户端上获得反身候选者（duh！），但是，如果另一个客户端在 NAT 后面，那其他客户端将需要一个 STUN，可能是 TURN，服务器来与 ice-life 客户端建立连接。
当 Ice-Lite 用于 Android 时，ice-candidate 如何嵌入到 SDP 中？
与任何其他客户端相同。阅读规格。无论如何，您需要的不仅仅是在 SDP 中添加一个标志来启用 ice-lite。还有很多。
我想在 Android webrtc 中使用 Ice-Lite。
我想知道
- Ice-Lite 是服务器端组件还是客户端？
- Ice-Lite 是如何在 Android 上实现的？
- 如果使用 Ice-Lite，我们还需要 STUN 服务器吗？
- 当 Ice-Lite 用于 Android 时，ice-candidate 如何嵌入到 SDP 中？
我尝试在 c=IN IP4 0.0.0.0 之后在 SDP 中插入 a=ice-lite 并仅将 STUN 服务器传递给 RTCConfig 但这似乎不起作用！另外，我是在IceGathering 结束后才发送offer 和answer 的。
要为 Android 实施 Ice-Lite，我需要做些什么吗？
谢谢！
啊抱歉，我搞砸了 ICE 的 Aggressive 提名和 ICE-Lite。以下答案适用于 ICE 激进的提名程序。只需将这些视为附加信息即可。积极提名是一个程序，它定义调用者应如何通过发送 USE-CANDIDATE 来最终确定选定的候选人。
正确答案post： 在 ICE lite 过程中，客户端不会收集所有候选者，而只会收集本地主机候选者。这基本上是为 public IP 地址后面的端点设计的，当客户端在没有 NAT 的 public IP 后面时，它可以与任何其他候选者连接，即使另一端在后面对称 NAT。 ICE-Lite 不需要 STUN/TURN 服务器。您无法使用 SDP 线路实现此目的，因为在您获得候选人之前，ICE-Lite 程序首先出现。因此，如果您不设置 STUN/TURN 服务器，那么它将作为 ICE-Lite 工作（尽管它不是拥有 ICE-lite 的正式方式，ICE 客户端应该具有设置 ICE-Full 或 ICE-Lite 的定义方式）和现在一样，它只会收集主持人候选人。但是，如果您的端点位于某个 NAT 后面，而其他端点不在网络中，那么它将无法工作。如果您能确定客户端是否落后于 public IP 则更好。
您应该阅读 RFC 5245，它以非常易读的术语描述了 ICE-lite。
ICE-lite 预计只是完整 ICE 实施的垫脚石。如果端点具有完整的实现，则该端点可能不支持 ICE-lite 操作。
In order for ICE to be used in a call, both agents need to support it. However, certain agents will always be connected to the public Internet and have a public IP address at which it can receive packets from any correspondent. To make it easier for these devices to support ICE, ICE defines a special type of implementation called LITE (in contrast to the normal FULL implementation). A lite implementation doesn't gather candidates; it includes only host candidates for any media stream. Lite agents do not generate connectivity checks or run the state machines, though they need to be able to respond to connectivity checks. When a lite implementation connects with a full implementation, the full agent takes the role of the controlling agent, and the lite agent takes on the controlled role. When two lite implementations connect, no checks are sent.
For guidance on when a lite implementation is appropriate, see the discussion in Appendix A.
It is important to note that the lite implementation was added to this specification to provide a stepping stone to full implementation. Even for devices that are always connected to the public Internet, a full implementation is preferable if achievable.
ICE-lite 是您在服务器上会 运行 的东西。如果您的服务器使用 ICE-lite 并且您可以将服务器配置为发送可达地址，则无需 STUN 即可逃脱。
我认为 Android 没有 ICE-lite 实现。 Android 设备预计会更改地址，并且 Android 已经具有完整的 ICE，因此为 Android.
使用 ICE-lite 似乎没有什么意义Ice-Lite 是服务器端组件还是客户端？
都没有。 ICE 独立于 "side"，因为它是为 p2p 制作的，所以在规范中一切都称为 "client"。但是，鉴于它仅用于具有持久静态 public IP 的客户端（对于在 public 互联网上运行的客户端-服务器连接中所谓的客户端，这种情况极为罕见）它实际上仅适用于网关和服务器。
Ice-Lite 是如何在 Android 上实现的？
不是。但是，有几个库实现了规范（lib nice，....）。
如果使用 Ice-Lite，我们还需要 STUN 服务器吗？
是和否。您不需要 STUN 服务器来在 public IP 上的客户端上获得反身候选者（duh！），但是，如果另一个客户端在 NAT 后面，那其他客户端将需要一个 STUN，可能是 TURN，服务器来与 ice-life 客户端建立连接。
当 Ice-Lite 用于 Android 时，ice-candidate 如何嵌入到 SDP 中？
与任何其他客户端相同。阅读规格。无论如何，您需要的不仅仅是在 SDP 中添加一个标志来启用 ice-lite。还有很多。