不使用信令服务器的WebRTC协议的libp2p_core::Transport特质的实现。

概述

 ## ICE

RFCs: 8839, 8445 参见： https://tools.ietf.org/id/draft-ietf-rtcweb-sdp-08.html#rfc.section.5.2.3

WebRTC协议使用ICE来建立连接。

在典型的ICE设置中，有两个端点，称为代理，想要进行通信。其中之一可以是本地浏览器，而另一个代理则是连接的目标。

尽管在这个特定的上下文中我们只想进行简单的客户端-服务器通信，但记住ICE是为了解决NAT穿越问题而设计的，这会有帮助。

ICE工作流程如下

• "提议者"确定它可访问的方式（要么是一个IP地址，要么是通过使用TURN服务器的中继），这些被称为"候选人"。然后它生成一个小型的文本有效载荷，格式称为SDP，描述了连接请求。
• 提议者将这个SDP编码的消息发送给应答者。这种交换所通过的中介超出了ICE协议的范围。
• 应答者然后找到自己的候选人，并生成一个答案，再次以SDP格式。这个答案发送回提议者。
• 每个代理然后尝试连接到远程的候选人。

我们假装向远程代理（连接的目标）发送出价，然后假装它已经找到了自己的有效IP地址（即候选地址），然后假装包含此候选地址的SDP响应已经发送回。这将导致出价方执行第4步：尝试连接到远程的候选地址。

TCP或UDP

WebRTC本身没有为媒体流硬编码任何特定协议。相反，使用哪种协议是由出价方的SDP消息指定的。在我们的用例中（一个或多个数据通道），我们知道出价方将始终请求TCP+DTLS+SCTP或UDP+DTLS+SCTP。

当前实现仅支持UDP，因此如果出价方请求TCP+DTLS+SCTP，它将不会响应。未来可能会添加对TCP的支持（参见https://github.com/webrtc-rs/webrtc/issues/132）。

## DTLS+SCTP

RFCs: 8841, 8832

在TCP或UDP的两种情况下，下一层是DTLS。DTLS类似于众所周知的TLS协议，但它的传输顺序没有保证（因为这是由DTLS之上的SCTP层提供的）。换句话说，一旦TCP或UDP连接建立，浏览器将尝试执行DTLS握手。

在ICE协商期间，每个代理必须在它的SDP数据包中包含它将在DTLS握手中使用的自签名证书的哈希值。在我们的用例中，我们试图手动生成远程生成的SDP响应，这是有问题的。一种解决方案是将哈希值作为远程多地址的一部分。在服务器端，我们关闭证书验证。