你家楼顶

新房河西比较多，麓谷二期还在开发。
二手房河东选择多

信令

什么是 WebRTC 信令？

当一个 WebRTC Agent 被创建时，它对其他 peer 一无所知。它不知道它将与谁联系，也不知道它们将发送些什么！
信令是使呼叫成为可能的初始引导程序。交换信令消息后，WebRTC Agent 才可以直接相互通信。

信令消息只是文本。WebRTC Agent 并不关心它们的传递方式。信令通常使用 Websockets 分享，但这不是必需的。

WebRTC 信令如何工作？

WebRTC 使用到一种现有的协议，称为会话描述协议（Session Description Protocol，简称 SDP）。两个 WebRTC Agent 会将建立连接所需的所有状态通过此协议来分享。该协议本身亦易于阅读和理解。
但要理解 WebRTC 填充于协议中的所有值，是有些复杂的。

SDP 并不是 WebRTC 特有的。我们将首先学习会话描述协议，这里甚至不用提到 WebRTC。WebRTC 实际上仅是利用了 SDP 协议的子集，因此我们将仅介绍我们所需的内容。
理解协议后，我们将继续结合 WebRTC 来说明其在实际中的应用方法。

什么是 会话描述协议（SDP）？

会话描述协议定义于 RFC 8866 中。它是一个 key/value 协议，每一行是一个值。看起来类似于 INI 文件。
一个会话描述包含零个或多个媒体描述。对此模型，可以理解为会话描述包含了一个媒体描述的数组。

一个媒体描述通常映射到单个媒体流。因此，如果你想描述一个包含三个视频流和两个音轨的呼叫，需要五个媒体描述。

如何阅读 SDP 信息

会话描述中的每一行都将以一个单字符开始，这是你的 key。单字符后面将跟随一个等号。等号后的所有内容都是 value。value 结束的地方将有一个换行符。

会话描述协议定义了所有有效的 key。对于协议中定义的 key，你只能使用字母。这些 key 都有重要的意义，稍后将对此进行解释。

作为参考，下面是一个会话描述的部分内容：

a=my-sdp-value
a=second-value

这里有两行。每行的 key 都是 a。第一行的 value 为 my-sdp-value，第二行的 value 为 second-value。

WebRTC 仅使用了部分 SDP 的 key

WebRTC 并未使用会话描述协议定义的所有 key，只有那些在 JavaScript Session Establishment Protocol (JSEP，协议定义在RFC 8829) 中被使用到的 key 是重要的。你当前只需要理解下面的 7 个 key。

• v - Version，版本，版本，应等于 0。
• o - Origin，源，包含一个唯一 ID，用于重新协商。
• s - Session Name，会话名称，应等于-。
• t - Timing，时间，应等于 0 0。
• m - Media Description(m=<media> <port> <proto> <fmt> ...)，媒体描述，下面有详细说明。
• a - Attribute，属性，一个自由文本字段，这是 WebRTC 中最常见的行。
• c - Connection Data，连接数据，应等于 IN IP4 0.0.0.0。

会话描述中的媒体描述

一个会话描述中，可以包含无限数量的媒体描述。

一个媒体描述定义中，包含一个格式列表。这些格式映射到 RTP 有效负载类型。然后，实际的编解码器由媒体描述中的 rtpmap 属性定义。
RTP 和 RTP 有效负载类型的重要性将在后面的媒体章节中讨论。每个媒体描述可以包含无限数量的属性。

作为参考例子，下面是一个会话描述的部分内容：

v=0
m=audio 4000 RTP/AVP 111
a=rtpmap:111 OPUS/48000/2
m=video 4000 RTP/AVP 96
a=rtpmap:96 VP8/90000
a=my-sdp-value

这里面有两个媒体描述，第一个是音频，格式为 111，另一个是视频，格式为 96。第一个媒体描述只有一个属性。该属性将有效载荷类型 111 映射到 Opus 编解码器。
第二个媒体描述具有两个属性。第一个属性将有效负载类型 96 映射到 VP8 编解码器，第二个属性只是 my-sdp-value。

译注：参照前面 key 的定义，第 1 行的 v=0 表示版本为 0，第 2/3 行是第一个媒体描述，第 4/5/6 行是第二个媒体描述

完整示例

以下内容将我们讨论过的所有概念整合在一起。这些是 WebRTC 所使用的会话描述协议的所有特性。
如果你可以读懂这个例子，那么你可以读懂任何 WebRTC 会话描述！

v=0
o=- 0 0 IN IP4 127.0.0.1
s=-
c=IN IP4 127.0.0.1
t=0 0
m=audio 4000 RTP/AVP 111
a=rtpmap:111 OPUS/48000/2
m=video 4002 RTP/AVP 96
a=rtpmap:96 VP8/90000

• v, o, s, c, t 虽然被定义，但他们不对 WebRTC 会话产生影响。
• 这里有两个媒体描述。一个是 audio 即音频类型，一个是 video 即视频类型。
• 每个媒体描述都有一个属性。这个属性配置了 RTP 管道的详细信息，这部分将在 " 媒体通信 " 章节详细讨论

会话描述协议 和 WebRTC 如何协同工作

下一块拼图是理解 WebRTC _ 如何 _ 使用会话描述协议。

什么是 Offer 和 Answer？

WebRTC 使用 Offer/Answer 模型。这指的是，一个 WebRTC Agent 发出 "Offer" 以开始呼叫，如果另一个 WebRTC Agent 愿意接受 "Offer" 的内容，它会响应 "Answer"。

这使得应答者有机会拒绝媒体描述中的某些不支持的编解码器，也是两个 peer 互相理解他们希望交换何种格式的方式。

用于发送和接收的收发器（Transceivers）

收发器是 WebRTC 中特有的概念，你将在 API 中看到它。它的作用是将 " 媒体描述 " 暴露给 JavaScript API。每个媒体描述都将成为一个收发器。每次创建收发器时，都会将新的媒体描述添加到本地会话描述中。

WebRTC 中的每个媒体描述都包含一个 direction 属性。这样，WebRTC Agent 可以声明 " 我将向你发送此编解码器，但我不打算接受任何返回的内容 "。direction 属性有四个有效值：

• send
• recv
• sendrecv
• inactive

WebRTC 用到的 SDP 值

这个列表包含了你将在 WebRTC Agent 的会话描述中看到的一些常见属性。这些值控制着我们尚未讨论到的子系统。

group:BUNDLE

BUNDLE 是一种在单个连接上传输多种类型流量的行为。一些 WebRTC 实现对每个媒体流会使用专用的连接。但 BUNDLE 方式应该是首选。

fingerprint:sha-256

该属性是 peer 用于 DTLS 证书的哈希值。DTLS 握手完成后，你可以将其与实际证书进行比较，以确认你正在与预期的对象进行通信。

译注：下面是RFC 4572中的一个例子

a=fingerprint:SHA-1 \
          4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB

setup:

该属性控制了 DTLS Agent 的行为。在 ICE 连接后，该属性将确定 DTLS Agent 是作为客户端还是服务器来运行。有以下几个可能的值：

• setup:active - 作为 DTLS 客户端运行。
• setup:passive - 作为 DTLS 服务器运行。
• setup:actpass - 要求另一个 WebRTC Agent 选择。

mid

该属性是每个 Media Description 的唯一 ID。用于标识媒体。

ice-ufrag

该属性是 ICE Agent 的用户片段值。用于 ICE 流量的身份验证。

ice-pwd

该属性是 ICE Agent 的密码。用于 ICE 流量的身份验证。

rtpmap

该属性用于将特定的编解码器映射到 RTP 有效负载类型。有效负载类型不是静态的，因此对于每次呼叫，发起者都需要确定每个编解码器的有效负载类型。

fmtp

该属性为一种有效负载类型定义附加的值。要传递特定的视频配置文件或编码器设置时，这很有用。

candidate

该属性是来自 ICE Agent 的 ICE 候选地址。这是一个可能被 WebRTC Agent 使用的地址。这些将在下一章中详细说明。

ssrc

一个同步源（SSRC）定义了一个单独的媒体流。

label 是此媒体流的 ID。mslabel 是容器的 ID，该容器中可以有多个流。

WebRTC 会话描述示例

下面是一个 WebRTC 客户端生成的一套完整会话描述：

v=0
o=- 3546004397921447048 1596742744 IN IP4 0.0.0.0
s=-
t=0 0
a=fingerprint:sha-256 0F:74:31:25:CB:A2:13:EC:28:6F:6D:2C:61:FF:5D:C2:BC:B9:DB:3D:98:14:8D:1A:BB:EA:33:0C:A4:60:A8:8E
a=group:BUNDLE 0 1
m=audio 9 UDP/TLS/RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=setup:active
a=mid:0
a=ice-ufrag:CsxzEWmoKpJyscFj
a=ice-pwd:mktpbhgREmjEwUFSIJyPINPUhgDqJlSd
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10;useinbandfec=1
a=ssrc:350842737 cname:yvKPspsHcYcwGFTw
a=ssrc:350842737 msid:yvKPspsHcYcwGFTw DfQnKjQQuwceLFdV
a=ssrc:350842737 mslabel:yvKPspsHcYcwGFTw
a=ssrc:350842737 label:DfQnKjQQuwceLFdV
a=msid:yvKPspsHcYcwGFTw DfQnKjQQuwceLFdV
a=sendrecv
a=candidate:foundation 1 udp 2130706431 192.168.1.1 53165 typ host generation 0
a=candidate:foundation 2 udp 2130706431 192.168.1.1 53165 typ host generation 0
a=candidate:foundation 1 udp 1694498815 1.2.3.4 57336 typ srflx raddr 0.0.0.0 rport 57336 generation 0
a=candidate:foundation 2 udp 1694498815 1.2.3.4 57336 typ srflx raddr 0.0.0.0 rport 57336 generation 0
a=end-of-candidates
m=video 9 UDP/TLS/RTP/SAVPF 96
c=IN IP4 0.0.0.0
a=setup:active
a=mid:1
a=ice-ufrag:CsxzEWmoKpJyscFj
a=ice-pwd:mktpbhgREmjEwUFSIJyPINPUhgDqJlSd
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 VP8/90000
a=ssrc:2180035812 cname:XHbOTNRFnLtesHwJ
a=ssrc:2180035812 msid:XHbOTNRFnLtesHwJ JgtwEhBWNEiOnhuW
a=ssrc:2180035812 mslabel:XHbOTNRFnLtesHwJ
a=ssrc:2180035812 label:JgtwEhBWNEiOnhuW
a=msid:XHbOTNRFnLtesHwJ JgtwEhBWNEiOnhuW
a=sendrecv

从这个会话描述中，我们可以知道以下内容：

• 我们有两个媒体描述，一个是音频，一个是视频
• 这两个媒体描述都是 sendrecv 收发器。我们将得到两个流，也可以发送两个流回去。
• 我们有 ICE 候选地址和身份验证的详细信息，因此我们可以尝试连接
• 我们有一个证书指纹，因此我们可以进行安全的呼叫

译注：对照以上 4 点

• 两个媒体描述即是两个 m= 段
• 两个 m 段中都有 a=sendrecv，即是说可以收也可以发
• ICE 候选地址对应 a=candidate:foundation 到 a=end-of-candidates 之间的部分，身份验证信息参考前面的 ice-ufrag 和 ice-pwd 等
• 指的是 fingerprint:sha-256 属性

进一步的话题

在本书的后续版本中，还将讨论以下主题：

• 重新协商（Renegotiation）
• 同步广播（Simulcast）

多邻国很好，在用 ，APP采用对话形式提升学习趣味，每天不打卡浑身难受~~

是什么，为什么，如何使用

WebRTC 是什么？

WebRTC 是 Web 实时通信（Real-Time Communication）的缩写，它既是 API 也是协议。WebRTC 协议是两个 WebRTC Agent 协商双向安全实时通信的一组规则。开发人员可以通过 WebRTC API 使用 WebRTC 协议。目前 WebRTC API 仅有 JavaScript 版本。

可以用 HTTP 和 Fetch API 之间的关系作为类比。WebRTC 协议就是 HTTP，而 WebRTC API 就是 Fetch API。

除了 JavaScript 语言，WebRTC 协议也可以在其他 API 和语言中使用。你还可以找到 WebRTC 的服务器和特定领域的工具。所有这些实现都使用 WebRTC 协议，以便它们可以彼此交互。

WebRTC 协议由 IETF 工作组在rtcweb中维护。WebRTC API 的 W3C 文档在webrtc。

为什么我应该学习 WebRTC？

下面这些是 WebRTC 可以带给你的东西。这并不是一份详尽的清单，只是列举一些你在学习中可能感兴趣的点。如果你还不了解所有这些术语，请不要担心，本书将陆续将这些概念教给你。

• 开放标准
• 多种实现
• 在浏览器中可用
• 强制加密
• NAT 穿透
• 复用现有技术
• 拥塞控制
• 亚秒级延迟

WebRTC 协议是一组其他技术的集合体

这个主题需要整本书来解释。但是，首先，我们将其分为四个步骤。

• 信令（Signaling）
• 连接（Connecting）
• 安全加密（Securing）
• 通信（Communicating）

这四个步骤依次发生。上一个步骤必须 100％成功，随后的步骤才能开始。

关于 WebRTC 的一个特殊事实是，每个步骤实际上都是由许多其他协议组成的！为了让 WebRTC 工作起来，我们将许多现有技术结合在一起。从这个意义上讲，WebRTC 更像是 2000 年代早期以来就已经存在的一些易于理解的技术的组合和配置。

每个步骤都有专门的章节，但是首先从较高的层次上理解它们会有所帮助。由于它们彼此依赖，因此理解这些在进一步解释每个步骤的目的时会有所帮助。

信令：peer 如何在 WebRTC 中找到彼此

当 WebRTC Agent 启动时，它不知道与谁通信以及他们将要通信的内容。信令解决了这个问题！信令用于引导呼叫，以便两个 WebRTC Agent 可以开始通信。

信令使用一种现有的协议 SDP（会话描述协议）。SDP 是一种纯文本协议。每个 SDP 消息均由键 / 值对组成，并包含“media sections（媒体部分）”列表。两个 WebRTC Agent 交换的 SDP 所包含一些详细信息，如：

• Agent 可供外部访问的（候选的）IP 和端口。
• Agent 希望发送多少路音频和视频流。
• Agent 支持哪些音频和视频编解码器。
• 连接时需要用到的值（uFrag/uPwd）。
• 加密传输时需要用到的值（证书指纹）。

注意，信令通常发生在“out-of-band”。也就是说，应用通常不使用 WebRTC 本身来交换信令消息。在连接的 peer 中，任何适合发送消息的架构均可被用于传递 SDP 信息，许多应用程序都使用其现有的基础设施（例如 REST 端点，WebSocket 连接或身份验证代理）来解决适当客户端之间的 SDP 传递问题。

使用 STUN/TURN 进行连接和 NAT 穿透

现在，两个 WebRTC Agent 知道足够的详细信息以尝试相互连接。接下来，WebRTC 将使用另一种成熟的技术，称为 ICE。

ICE（交互式连接建立）是 WebRTC 前现有的协议。ICE 允许在两个 Agent 之间建立连接。这些 Agent 可以在同一网络上，也可以在世界的另一端。ICE 是无需中央服务器即可建立直接连接的解决方案。

这里真正的魔法是“ NAT 穿透”和 STUN/TURN 服务器。这两个概念是与另一个子网中的 ICE Agent 进行通信所需的全部。稍后我们将深入探讨这些主题。

ICE 成功连接后，WebRTC 就会继续建立加密传输。加密传输用于音频，视频和数据。

使用 DTLS 和 SRTP 加密传输层

现在我们有了双向通信（基于 ICE），我们需要建立安全的通信。这是基于 WebRTC 前已有的两种协议完成的。第一个协议是 DTLS（数据报传输层安全性），即基于 UDP 的 TLS。TLS 是一个加密协议，用于保护基于 HTTPS 的安全通信。第二种协议是 SRTP（安全实时传输协议）。

首先，WebRTC 通过在 ICE 建立的连接上进行 DTLS 握手来进行连接。与 HTTPS 不同，WebRTC 不使用中央授权来颁发证书。相反，WebRTC 只是判断通过 DTLS 交换的证书是否与通过信令共享的签名相符。然后，此 DTLS 连接可以被用于传输 DataChannel 消息。

接下来，WebRTC 使用 RTP 协议进行音频 / 视频的传输。我们使用 SRTP 来保护我们的 RTP 数据包。我们从协商的 DTLS 会话中提取密钥，用来初始化 SRTP 会话。在后续章节中，我们会讨论为什么媒体传输需要有它自己的协议。

现在我们完成了！你现在可以进行安全的双向通信。如果你的 WebRTC Agent 之间具有稳定的连接，以上这些就是你可能需要解决的所有复杂问题了。不幸的是，现实世界中存在数据包丢失和带宽限制等问题，下一节我们会介绍如何处理这些问题。

通过 RTP 和 SCTP 进行点对点通信

现在，我们有了两个具有安全的双向通信功能的 WebRTC Agent。让我们开始通信！跟前面一样，我们使用两个现有的协议：RTP（实时传输协议）和 SCTP（流控制传输协议）。我们使用 RTP 来交换用 SRTP 加密过的媒体数据，使用 SCTP 发送和接收那些用 DTLS 加密过的 DataChannel 消息。

RTP 很轻量，但是提供了实现实时流式传输所需的功能。最重要的是，RTP 为开发人员提供了灵活性，因此他们可以根据需要来处理延迟，丢失和拥塞。我们将在媒体章节中对此进行进一步讨论。

协议栈中的最后一个协议是 SCTP。SCTP 支持许多不同的消息传送选项。你可以根据需要开启不可靠传输，无序传输等选项，以便获得实时系统所需的低延迟。

WebRTC 是一系列协议的集合

WebRTC 解决了许多问题。初看起来，这似乎是过度设计的。实际上，WebRTC 非常克制。它并未认为它可以更好的解决所有问题。相反，它采纳了许多现有的解决某个特定问题的技术，然后将它们有机地结合起来。

这使得我们可以独立的检查和学习每个部分，而不会毫无头绪。实际上，从另一个角度去看“ WebRTC Agent”，它只是许多不同协议的协调器。

WebRTC（API）如何工作

本部分显示 JavaScript API 是如何跟协议相对应的。这不是一个 WebRTC API 的详细演示，更多的是为了创建一个思维模型，展现各个模块是如何串联起来的。如果你对各个模块都还不熟悉，那也不要紧。当你了解更多信息时，再回头看看这一部分，可能会很有趣！

new RTCPeerConnection

RTCPeerConnection 是最顶层的 "WebRTC 会话 "。它包含上述所有协议。调用后，所有子系统都会被创建，但是此时什么都还没有发生。

addTrack

addTrack 创建一个新的 RTP 流。会为这个 RTP 流生成一个随机的 SSRC（Synchronization Source/ 同步源）。在后续 createOffer 生成会话描述中，这个 RTP 流会被放入一个 media section。每次调用 addTrack 都会创建一个新的 SSRC 和一个对应的 media section。

在建立 SRTP 会话后，这些媒体数据包将被 SRTP 加密，然后立即通过 ICE 开始发送。

createDataChannel

当没有 SCTP 关联 (SCTP Association) 存在时，createDataChannel 将创建一个新的 SCTP 流。默认情况下，SCTP 是不启用的，只有在一方请求数据通道时才启动。

在 DTLS 会话建立之后，SCTP 关联将立即通过 ICE 发送数据包，并使用 DTLS 加密。

createOffer

createOffer 生成会话描述，里面是需要与远端 Peer 分享的本地信息。

调用 createOffer 的行为对于本地 Peer 没有任何改变。

setLocalDescription

setLocalDescription 提交所有请求的更改。 addTrack createDataChannel 和其他类似的调用都是临时的 (调用 setLocalDescription 后生效)。 调用 setLocalDescription 时，使用由 createOffer 生成的值。

通常，在此调用之后，你会将 offer 发送给远端 Peer，他们将调用 setRemoteDescription，将此 offer 设入。

setRemoteDescription

收到远端 Peer 发来的 offer 之后，我们通过 setRemoteDescription 通知本地 Agent。这就是使用 JavaScript API 传递“信令”的方式。

双方都调用过 setRemoteDescription 后，WebRTC Agent 现在拥有足够的信息来开始进行点对点（P2P）通信！

addIceCandidate

addIceCandidate 允许 WebRTC Agent 随时添加更多的远程 ICE 候选对象。该 API 将 ICE 候选对象发送到 ICE 子系统，并且对更大的 WebRTC 连接没有其他影响。

ontrack

ontrack 是收到远端 Peer 的 RTP 数据包时触发的回调。传入的 RTP 数据包的格式应该已在传递给 setRemoteDescription 的会话描述中声明。

WebRTC 使用 SSRC 并查找关联的 MediaStream 和 MediaStreamTrack，并使用 MediaStream 和 MediaStreamTrack 中的详细信息来触发此回调。

oniceconnectionstatechange

oniceconnectionstatechange 是 ICE Agent 的状态变化时触发的回调。当网络连接或断开时，你将得到此通知。

onconnectionstatechange

onconnectionstatechange 是 ICE Agent 和 DTLS Agent 状态的组合。当 ICE 和 DTLS 都成功完成时，你将得到此通知。