sgcWebRTC 功能矩阵
sgcWebRTC 为 TsgcRTCPeerConnection 添加的一切功能，按能力分类列出。信令和连接来自 sgcWebSockets Enterprise 中的基础组件；本附加包在此基础上解锁了媒体引擎 — 音频、视频、屏幕捕获、数据通道、加密和带宽评估。每项能力在 Delphi 和 C++ Builder 中的行为完全一致，每份许可证均附带完整源代码。
sgcWebRTC 为 TsgcRTCPeerConnection 添加的一切功能，按能力分类列出。信令和连接来自 sgcWebSockets Enterprise 中的基础组件；本附加包在此基础上解锁了媒体引擎 — 音频、视频、屏幕捕获、数据通道、加密和带宽评估。每项能力在 Delphi 和 C++ Builder 中的行为完全一致，每份许可证均附带完整源代码。
基础连接能力已经内置于 sgcWebSockets 中。sgcWebRTC 在同一个组件上解锁了 SDP、数据通道和媒体接口。
| 能力 | 随附于 | 说明 |
|---|---|---|
STUN 客户端（TsgcSTUNClient） | sgcWebSockets Standard | 服务器反射候选地址发现，Enterprise 以下版本即可使用。 |
TURN 客户端与服务器、ICE 客户端（TsgcTURNClient、TsgcICEClient） | sgcWebSockets Enterprise | 中继候选地址以及完整的 ICE 候选收集 / 提名。 |
基础 TsgcRTCPeerConnection、传统的 WebSocket 中继信令 | sgcWebSockets Enterprise | GatherCandidates、WriteData 以及 OnRTCWebSocket… / OnRTCCandidatePairNominated / OnRTCConnect 事件通过内置的 RTCPeerConnection 协议服务器驱动 ICE 连接和 DTLS 传输，不含 SDP、数据通道或媒体。 |
| 手动 SDP offer/answer 信令 | sgcWebRTC | CreateOffer、CreateAnswer、SetLocalDescription、SetRemoteDescription、AddIceCandidate、RestartIce — 浏览器所期望的 JSEP（RFC 8829）状态机。 |
| 重新协商与冲突处理 | sgcWebRTC | AddTrack / RemoveTrack 之后的重新 offer、OnNegotiationNeeded、回滚，以及通过 Polite 实现的 W3C 完美协商规则。 |
| 涓流式 ICE | sgcWebRTC | TrickleICE 和 RTCOptions.TrickleICEAuto 会在候选地址被发现时立即流式发送，而不是等待完整的收集超时。 |
| 连接与信令状态 | sgcWebRTC | ConnectionState（W3C RTCPeerConnectionState 子集）和 SignalingState（RTCSignalingState 子集），以及 OnConnectionStateChange 和 OnError。 |
| SCTP 数据通道、RTP 音视频、SRTP 加密 | sgcWebRTC | 参见下方各节 — 这三项功能都需要在 Enterprise 基础组件之上安装本附加包。 |
一次 AddTrack 调用即可为对等连接附加一个音频轨道；PCM 数据进，RTP 数据出，远端轨道的路径与之相反。
| 能力 | 成员 | 说明 |
|---|---|---|
| 附加一个音频轨道 | AddTrack(rtctkAudio, aCodec) | 返回一个 TsgcRTCTrack；RemoveTrack 停止发送该轨道。 |
| Opus 编解码器 | cctAudioOpus | 48 kHz / 立体声，通过动态加载的 libopus 绑定实现。 |
| G.711 编解码器 | cctAudioPCMU / cctAudioPCMA | 8 kHz / 单声道 μ-law 和 A-law，始终可用，无需外部库。 |
| 发送采集到的音频 | TsgcRTCTrack.SendPCM(aPCM, aSamplesPerChannel) | 按编码器的采样率和声道数排列的 16 位有符号交错 PCM。 |
| 接收解码后的音频 | OnAudio(aPCM, aSampleRate, aChannels, aSamplesPerChannel) | 在远端轨道的 RTP 数据到达并解码时触发。 |
| 编码器 / 解码器访问 | AudioEncoder / AudioDecoder | 底层的 TsgcAudioEncoderBase / TsgcAudioDecoderBase 对象，可按轨道替换。 |
| 轨道生命周期 | Enabled、Ended、OnEnded | Enabled := False 可在不重新协商的情况下静音；Ended 反映轨道被远端丢弃或重新 offer 的情况。 |
| 麦克风采集 | TsgcMediaCaptureSource 派生类 | 各平台的原生采集（Windows 上为 waveIn，另有 Linux、Apple 和 Android 后端）直接向 SendPCM 提供数据。 |
视频的工作方式与音频相同 — 帧数据进，RTP 数据出 — 编解码器按轨道选择，对于 H.264，底层使用平台自身的硬件编码器。
| 能力 | 成员 | 说明 |
|---|---|---|
| 附加一个视频轨道 | AddTrack(rtctkVideo, aCodec) | 与音频相同的调用，使用视频用的 TsgcCodecType。 |
| VP8 编解码器 | cctVideoVP8 | 动态加载的 libvpx 绑定，适用于 Windows 和 Linux。 |
| H.264 编解码器 | cctVideoH264 | 各平台的原生硬件编码器：Media Foundation（Windows）、VideoToolbox（iOS/macOS）、MediaCodec（Android）。Annex-B 码流，RFC 6184 负载封装，SPS/PPS 在每个关键帧上随流携带。 |
| Motion JPEG 编解码器 | cctVideoJPEG | 基于 GDI+，适用于 Windows 和 Delphi XE 及更高版本。 |
| 发送原始帧 | TsgcRTCTrack.SendVideoFrame(aFrame, aForceKeyFrame) | 编码并发送一个 TsgcVideoFrame（I420/NV12/RGB/BGR 系列）。 |
| 发送预先编码的帧 | SendEncodedFrame(aData, aIsKeyFrame) | 为已在外部编码好的帧绕过轨道自身的编码器。 |
| 接收解码 / 原始帧 | OnVideoFrame / OnEncodedFrame | 已解码的 TsgcVideoFrame，或带有关键帧标志的原始编码码流。 |
| 请求关键帧 | RequestKeyFrame | 向远端发送方发送一个 RTCP PLI。 |
| 编码器 / 解码器访问 | VideoEncoder / VideoDecoder | 底层的 TsgcVideoEncoderBase / TsgcVideoDecoderBase 对象。 |
| 摄像头采集 | TsgcMediaCaptureSource 派生类 | 各平台的采集后端（Windows、Linux、Apple、Android）直接向 SendVideoFrame 提供数据。 |
| 渲染 | TsgcMediaRenderer 派生类 | 各平台的渲染后端（Windows、Linux、Apple、Android），用于呈现已解码的远端视频。 |
有序或无序、完全可靠或受重传次数/生存期限制，全部基于 SCTP-over-DTLS 实现。
| 能力 | 成员 | 说明 |
|---|---|---|
| 打开一个通道 | CreateDataChannel(aLabel, aOrdered, aMaxRetransmits, aMaxPacketLifeTime, aProtocol) | 返回一个 TsgcRTCDataChannel；会强制开启 RTCOptions.DTLS。 |
| 远端打开的通道 | OnDataChannel(aChannel) | 当对端在此连接上打开一个通道时触发。 |
| 发送文本 / 二进制数据 | Send(aText) / SendBytes(aBytes) | 如果通道尚未打开则返回 False。 |
| 接收 | OnMessage(aText) / OnMessageBinary(aBytes) | 在驱动 SCTP 的线程上触发。 |
| 生命周期事件 | OnOpen、OnClose、OnError(aError) | 与 W3C RTCDataChannel 生命周期一致。 |
| 通道状态 | State、HasId、Id | SCTP 流 ID 只有在 DTLS 角色确定之后才最终确定（RFC 8832 奇偶性）。 |
| 流量控制 | BufferedAmount、MaxMessageSize | MaxMessageSize 跟踪对端自身的 a=max-message-size，并在本地拒绝超大发送。 |
| 可靠性内省 | Reliability、ReliabilityParam、Ordered、MaxRetransmits、MaxPacketLifeTime | 准确读回该通道所协商的参数。 |
| 关闭 | Close | 基于 RE-CONFIG 的关闭；State 依次变为 closing，然后 closed 并触发 OnClose。 |
| 对等连接层级 | DataChannelCount、DataChannels[i] | 枚举该连接上所有已打开的通道。 |
从 DTLS 握手开始，连接上的每个 RTP、RTCP 和 SCTP 数据包都会被加密 — 不存在明文模式。
| 能力 | 详情 |
|---|---|
| 密钥交换 | 在已提名的 ICE 候选对上进行 DTLS 握手（RFC 5764 DTLS-SRTP），推导出 SRTP 密钥材料。 |
| DTLS 角色 | 在手动信令中，角色来自 a=setup（offer 方为 passive，answer 方为 active）；角色确定后 IsDTLSClient 会报告该角色。 |
| SRTP 保护配置 | SRTP_AES128_CM_SHA1_80、SRTP_AES128_CM_SHA1_32、SRTP_AEAD_AES_128_GCM、SRTP_AEAD_AES_256_GCM，在 DTLS 握手期间协商。 |
| 按 SSRC 划分的加密状态 | 按照 RFC 3711 3.2.3 节的要求，每个 SSRC 各持有一个独立的加密上下文（翻转计数器、重放窗口），即使 BUNDLE 将每条 m-line 都放到同一个 DTLS-SRTP 传输上也是如此。 |
| 覆盖范围 | 涵盖 RTP/RTCP 媒体以及承载数据通道的 SCTP 关联 — 覆盖整个连接，而不仅仅是某一条 m-line。 |
| 后端 | 基于 OpenSSL 的 SRTP 实现。 |
一个类似 Google Congestion Control 风格的基于延迟的估算器持续跟踪链路状况，并驱动视频编码器的目标码率。
| 能力 | 成员 | 说明 |
|---|---|---|
| 基于延迟的估算器 | TsgcBWE_Estimator | 以 5 ms 为单位对发送突发数据分组，对组间延迟运行趋势线滤波，并将链路状态分类为正常、过载或欠载。 |
| 速率控制 | AIMD 控制器 | 过载时降至已确认速率的 85%，欠载时保持不变，正常时提升（远离上一次已知上限时为倍增，接近上限时为加性增长）。 |
| 丢包上限 | 丢包率跟踪 | 丢包率超过 10% 时上限下降；低于 2% 时每秒恢复 8%，直至 MaxBitrate。 |
| 全传输反馈 | TWCC（RTCP） | BuildRTCP_TWCC / ParseRTCP_TWCC 全传输拥塞控制反馈，对只支持 REMB 的对端则以 REMB 作为回退上限。 |
| 开启方式 | RTCOptions.Media.CongestionControl | 只有当远端描述也协商了匹配的头部扩展 / 反馈机制时才会生效。 |
| 丢包恢复 | RTCOptions.Media.RTX | 收到 RTCP NACK 时按 RFC 4588 对视频流进行重传。 |
| 前向纠错 | RTCOptions.Media.FEC | 对发出的视频流进行 RED / ULPFEC 保护。 |
| 发送节奏控制 | RTCOptions.Media.Pacing | 按估算码率对发出的视频数据包进行节奏控制，而不是集中突发发送。 |
| 关键帧恢复 | RTCP PLI | 接收端轨道上的 RequestKeyFrame 会在丢包后向发送方请求一个新的关键帧。 |