AWS KVS(Kinesis Video Streams)之WebRTC

STUN 、TURN 和ICE如何工作 （两个端点交互流程）：

我们假设两个对等方A和B都使用WebRTC对等双向媒体流（例如，视频聊天应用程序）的情况。

要连接到B的应用程序，A的应用程序必须生成SDP offer。SDP offer包含有关A的应用程序想要建立的会话的信息，包括要使用的编解码器，这是音频还是视频会话等。它还包含 ICE candidates，它们B应用程序用于尝试连接A应用程序需要用到的A的IP和port。

为了建立ICE候选者列表，A的应用程序向STUN服务器发出了一系列请求。服务器返回发起请求的公共IP地址和端口对。A的应用程序将每对添加到ICE候选列表中，换句话说，它收集ICE候选。一旦A的应用程序完成了ICE候选者的收集，它就可以返回SDP。

接下来，A的应用程序必须通过这些应用程序进行通信的信令通道将SDP传递给B的应用程序。WebRTC标准未指定用于此交换的传输协议。它可以通过HTTPS，安全WebSocket或任何其他通信协议执行。

现在，B的应用程序必须生成一个SDP Answer。B的应用程序遵循上一步中使用的A步骤：收集ICE candidates等。然后B的应用程序需要将此SDP Answer通过信令服务器返回给A的应用程序。

在A和B交换了SDP之后，它们将执行一系列连接检查。每个应用程序中的ICE算法都从对方SDP中收到的列表中获取ICE candidates IP /端口对，并向其发送STUN请求。如果另一个应用程序返回了响应，则原始应用程序认为检查成功，并将该IP /端口对标记为有效的ICE候选者。

在对所有IP /端口对完成连接检查之后，应用程序进行协商并决定使用剩余的有效对之一。选择一对后，媒体开始在应用程序之间流动。(有效通道选择策略一般是host>p2p>releay)

如果任何一个应用程序都找不到通过连通性检查的IP /端口对，它们将向TURN服务器发出STUN请求以获取媒体中继地址。中继地址是一个公共IP地址和端口，用于转发与应用程序之间接收到的数据包并设置中继地址。然后将该中继地址添加到候选列表，并通过信令通道进行交换。

PS:实际上实现时，使用的是生成SDP和交换ICE candidates 可以是并行执行。即生成SDP并不需要与STUN服务器通信。ICE candidate 信息不用包含在SDP 中发送。这样可以提高建立链接的速度。不用等ICE candidate搜集完成后才进行信令通信。