关于Android接入AWS KVS with WebRTC实现P2P视频（一）

关注博主个人简介，技术不迷路~

前言

最近接到需求需要接入亚马逊的KVS SDK来实现P2P视频；由于本人也是初次接触这块内容，所以接入过程难免有一些坑要踩的。。。所以趁有时间也把是把遇到的问题在此记录一下，也希望能帮助其它同学避免踩坑。本篇主要是一些概念相关的知识点的记录。关于问题点可以前往 【关于Android接入AWS KVS with WebRTC实现P2P视频（二）】

Tips：由于都是一些概念上的东西，所以这里也就把AWS KVS文档移过来了。这些内容也是我在完成需求后认为比较重要的知识点；尤其是第一次接触的同学，最好仔细看下并理解这些概念，这样会在后面的接入过程中更好的帮助理解AWS提供的Demo。本人就是因为开始没有好好看这些文档，所以导致后面在接入过程遇到棘手的问题后花了不少时间和精力去看这些知识点。

一、Amazon Kinesis Video Streams WebRTC基本概念（简称：AWS KVS）

WebRTC 是一个开放的技术规范，它通过简单的 API 支持跨浏览器和移动应用程序的实时通信 (RTC)。它使用对等技术在连接的对等方之间进行实时数据交换，并提供 human-to-human 交互所需的低延迟媒体流。除了用于可靠和安全的实时媒体和数据流的协议规范外，WebRTC 规范还包括一组 IETF 协议，包括建立交互式连接、使用中继绕 NAT (TURN) 进行遍历和用于建立 peer-to-peer 连接的 NAT 会话遍历实用程序 (STUN)。

这里关于google的webrtc有一个很坑的点（问题描述：三星、一加等机型可以拉取到视频流，而像oppo、vivo、华为等包括google的手机会显示黑屏现象）。可以前往 【关于Android接入AWS KVS with WebRTC实现P2P视频（二）】查看解决方法

Amazon Kinesis Video Streams 提供符合标准的 WebRTC 实现作为完全托管的功能。您可以使用 Amazon Kinesis Video Streams with WebRTC 安全地进行媒体的实时流式传输，或在任何摄像头 IoT 设备与符合 WebRTC 的移动或 Web 播放器之间执行双向音频或视频交互。借助这项全面托管的功能，您不必构建、运营或扩展任何与 WebRTC 相关的云基础设施（例如信令或媒体中继服务器）便能安全地在应用程序和设备间流式传输媒体。

二、Kinesis Video Streams with WebRTC 工作方式

以下是使用 WebRTC 的 Amazon Kinesis Video Streams 特有的关键术语和概念。

• 信令通道（Signaling channel）

  一种资源，使应用程序能够发现、设置、控制和终止 peer-to-peer 通过交换信令消息进行连接。信令消息是两个应用程序相互交换以建立的元数据 peer-to-peer 连接。此元数据包括媒体编解码器和编解码器参数等本地媒体信息，及两个应用程序互相连接以进行实时流式传输而可能使用的网络候选路径。

  流式传输应用程序可以与信令通道保持持续连接，并等待其他应用程序连接到它们。或者，只有当它们需要实时流媒体时，才能连接到信令通道。信令信道使应用程序能够在 one-to-few 模型，使用 one 的概念主设备连接到多个查看器。发起连接的应用程序使用 ConnectAsMaster API 承担主设备的责任，并等待查看器连接。然后，多达 10 个应用程序可以通过调用 ConnectAsViewer API 来承担查看器责任，以连接到该信令通道。连接到信令信道后，主应用程序和查看器应用程序可以互相发送信令消息以建立 peer-to-peer 用于直播媒体的连接。

• 对等（Peer）

  配置为通过 Kinesis Video Streams with WebRTC 实现实时双向流式传输的任何设备或应用程序（例如，移动或网络应用程序、网络摄像头、家庭安全摄像头、婴儿监视器等）。

• 主实例（Master）

  发起连接并连接到信令通道的对等方，能够发现媒体并与任何信令通道的已连接查看器交换媒体。 目前，一个信令通道只能有一个主设备。

• 查看者

  连接到信令通道的对等方只能通过信令通道的主设备发现和交换媒体。查看器无法通过给定的信令通道发现其他查看器或与其交互。一个信令通道最多可以有 10 个连接的查看器。

三、WebRTC 技术概念

• NAT 的会话遍历实用工具 (STUN)

  一种协议，用于发现您的公有地址并确定路由器中阻止与对等方直接连接的任何限制。

• 使用中继绕过 NAT 的遍历 (TURN)

  通过打开与 TURN 服务器的连接并通过该服务器中继所有信息来绕过对称 NAT 限制的服务器。

这里我因为粗心造成打开TURN服务失败，导致无法跨网络推拉流，也头痛了一下

• 会话描述协议 (SDP)

  一种描述连接的多媒体内容的标准，例如分辨率、格式、编解码器、加密等，以便一旦传输数据，两个对等方就可以相互理解。

• SDP 提议

  由代理发送的 SDP 消息，代理生成会话描述以创建或修改会话。它描述所需媒体通信的各个方面。

• SDP 应答

  应答者响应从提议人收到的提议而发送的 SDP 消息。应答指出了已接受的各个方面。例如，提议中的所有音频和视频流是否都被接受。

• 交互式连接建立 (ICE)

  允许您的 Web 浏览器与对等方连接的框架。

• ICE 候选项

  发送对等方能够用于通信的方法。

四、STUN、TURN 和 ICE 如何协同工作

让我们来看看两个对等方 A 和 B 的情况，它们都使用 WebRTC 对等双向媒体流式传输（例如，视频聊天应用程序）。当 A 想打电话给 B 时会发生什么？

要连接到 B 的应用程序，A 的应用程序必须生成 SDP 提议(SdpOffer)。SDP 提议包含有关 A 的应用程序要建立的会话的信息，包括要使用的编解码器(主流编解码器：VP8、9，H264等)、这是音频会话还是视频会话等。它还包含 ICE 候选项(IceCandidate)列表，这些候选项是 B 的应用程序可以尝试用来连接到 A 的 IP 和端口对。

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

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

现在，B 的应用程序必须生成 SDP 应答(SdpAnswer)。B 的应用程序遵循 A 在上一步中使用的相同步骤：收集 ICE 候选项等。然后，B 的应用程序需要将此 SDP 应答返回给 A 的应用程序。

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

在所有 IP/端口对上完成连接性检查后，应用程序协商并决定使用剩余的有效对之一。当选择一个对时，媒体开始在应用程序之间流动。

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