FEC

FEC（Forward Error Correction）是一种前向纠错技术。发送端将负载数据加上一定的冗余纠错码一起发送，接收端根据接收到的纠错码对数据进行差错检测，如果发现差错，则利用纠错码进行纠错。FEC 采用的是冗余发送机制，在带宽允许的情况下，FEC 可以起到预期的效果；但对于带宽严重限制的情况下，有可能带来副作用。
低延时（WebRTC）直播技术常用的 FEC 解决方案包含 ULPFec 和 RSFec 等；例如，Chrome 或 Firefox 浏览器进行直播或视频通话时可以选择启用 ULPFec，客户端、服务端也可以单独实现 RSFec；具体的 FEC 实现可以根据双方对端的 SDP 协商完成。

• ULPFec 标准参考：https://datatracker.ietf.org/doc/html/rfc5109
• RSFec 标准参考：https://datatracker.ietf.org/doc/html/rfc5510

ICE

请求意见稿 RFC 请参见 Interactive Connectivity Establishment (ICE)。

ICE（Interactive Connectivity Establishment）表示交互式连接建立。客户端与服务端之间发现 P2P（Peer to Peer）传输路径的机制，是一组基于 offer/answer 模式解决 NAT 穿越问题的协议族，NAT 穿越请参阅 STUN 协定。综合利用现有的 STUN、TURN 等协定，以更有效的形式来建设会话。

ICE 两端并不知道所处的网络的位置和 NAT 类型，通过 ICE 能够动态的发现最优的传输路径。如下图 L 和 R 是 ICE 代理，下面简称 L 和 R。L 和 R 有各自的传输地址，包括主机的网卡地址、NAT 上的外网地址、 TURN 服务地址。ICE 就是要从这些地址中，找到 L 和 R 的候选地址对，实现两端高效连通。ICE 两端可以通过信令服务器交换 SDP 信息。ICE 使用 STUN 和 TURN 等协议来建立会话。

ICE 模式分为 Full ICE 和 Lite ICE 两种类型。

• Full ICE：是单方都要进行连通性查看，实现的走一遍流程。
• Lite ICE：在 Full ICE 和 Lite ICE 互通时，只须要 FULL ICE 一方进行连通性查看， Lite 一方只需回应 response 音讯。这种模式常用于部署在公网设施上的场景。

ICE 有如下 5 种状态。

• Waiting：还未开始连通性查看，从 checklist 中抉择适合优先级的 pair 进行查看；
• In-Progress：连通性查看曾经开始，但还未完结；
• Succeeded：该 pair 连通性查看曾经实现并且胜利；
• Failed：失败；
• Frozen：连通性查看还未开始。

NACK

丢包重传（NACK）是抵抗网络错误的重要手段。NACK 在接收端检测到数据丢包后，发送 NACK 报文到发送端；发送端根据 NACK 报文中的序列号，在发送缓冲区找到对应的数据包，重新发送到接收端。 NACK 需要发送端，发送缓冲区的支持。

RTCP

请求意见稿 RFC 请参见 RTP: A Transport Protocol for Real-Time Applications

RTCP 协议负责流媒体的传输质量保证，提供流量控制等服务。在 RTP 传输期间，参与者周期性的发送 RTCP 报文，报文里面包含各种统计信息，据此可以动态的调整音视频的质量。

0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|  RC/FMT |      PT      |             length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

主要的 RTCP 类型如下表所示。

RTP

请求意见稿 RFC 请参见 RTP: A Transport Protocol for Real-Time Applications。

RTP 是一种网络音视频流媒体的数据封包格式；RTP 用来为 Internet 上的语音、图像、传真等多种需要实时传输的多媒体数据提供端到端的实时传输服务。RTP 为 Internet 上端到端的实时传输提供时间信息和流同步，但并不保证服务质量，服务质量由 RTCP 来提供。

0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X|  CC   |M|     PT      |       sequence number         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           timestamp                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          synchronization source (SSRC) identifier             |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|           contributing source (CSRC) identifiers              |
|                             ....                              |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|       extension profile      |            length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        header extension                       |
|                             ....                              |

标准 RTP header 字段含义如下表所示。

RTX

请求意见稿 RFC 请参见 RTP Retransmission Payload Format。

NACK 和 RTX 都是 WebRTC 里的丢包重传策略，两个策略之间有一定的联系。

• NACK：接收端通过 RTCP 将丢包的序列号通知给发送端，让发送端重传该包；
• RTX：发送端在新的 SSRC 上发送 NACK 重传包或者 FEC 冗余包。

在 RTX 模式下，有下列 2 种包。

1. 收到 NACK 重发的包；
2. 发送端发送的冗余 Padding 包。

SDP

SDP（Session Description Protocol）是一种通用的会话描述协议，主要用来描述多媒体会话；用途包括会话声明、会话邀请、会话初始化等。低延时（WebRTC）直播在 RFC8866 基础上进行了扩展，例如 ICE 和 DTLS 等。

• offer：发起方的 SDP；
• answer：接收到对端的 SDP；
• localSDP：本地 SDP；
• remoteSDP：对端 SDP。