www_dong的博客

参数名说明示例值is_debug是否为 Debug 构建truefalse是否编译测试代码false（生产时建议关闭）启用 H264 支持true（需额外引入 openh264/ffmpeg）启用 protobuf 支持（部分 API 需要）true是否使用组件构建（生成多个动态库）false（一般推荐falseuse_rtti启用 RTTI（运行时类型识别）true（如你需要 C++ RTTI）使用自定义 libc++（通常用于 macOS/iOS）falsetarget_cpu架构目标。

WebRTC 本身只处理媒体流的。WebRTC 的 PeerConnection 建立流程，需要两端完成。

DTLS（Datagram Transport Layer Security）是WebRTC 不直接用 DTLS 传输音视频，而是通过它协商出密钥后，用于 SRTP/SRTCP 加密 RTP/RTCP 流。

RTCP 是 RTP 的控制协议，，并与 RTP 一起工作。RTP 用于传输媒体数据（如音视频），RTCP 则用于传输控制信息。RTCP 通常和 RTP，并通过。

RTP 用于（如音频、视频），它不提供可靠传输，而是关注低延迟、高实时性。

WebRTC 的 JitterBuffer 构建了高度模块化、可插拔、跨平台的实时缓冲机制，实现了在复杂网络环境下高质量的音视频通信体验。特性音频（NetEq）视频（FrameBuffer）缓冲粒度RTP 包（10ms）视频帧解码策略严格 10ms 推进根据时间和帧依赖丢包处理PLC / CNGNACK / 丢弃时间同步插值输出 / 静音填充控制解码控制内部自动控制外部线程主动拉帧解码延迟适配加速 / 减速控制解码时机或丢帧。

audio：媒体类型9：端口（通常为 9，占位，由 ICE 协商真实端口）：传输协议，表示使用 SRTP over DTLS111：payload type，用于后续a=rtpmap对应实际编解码器。

目的：确保双方选用兼容的音视频编解码器、分辨率、码率和传输参数，实现高质量的实时通信。载体：基于 SDP（Session Description Protocol）协议，描述媒体的相关能力。流程一方创建并发送包含自身支持能力的 SDP Offer对方收到后生成 SDP Answer，确认兼容参数双方通过设置本地和远端描述完成协商内容包括编解码器列表（如 VP8、H.264、Opus）媒体流方向（发送、接收、双向）带宽限制和媒体属性网络传输细节（ICE、DTLS安全层）结果。

步骤关键点候选地址收集候选交换通过 SDP + trickle ICE连通性检查STUN 探测路径可用性优选与提名基于优先级选最优地址对连接建立最终选中路径，建立 DTLS/SRTP。

因为它会增加。

Client（NAT内） ←→ STUN Server（公网）1. 客户端发送 STUN Binding Request（UDP）2. STUN 服务器接收后，记录源 IP+端口3. 服务器将记录到的外部地址封装进 Binding Response 返回客户端4. 客户端分析返回结果，得到自己 NAT 后的公网 IP:Port关键点描述功能获取 NAT 后公网地址，辅助 P2P 穿透协议类型UDP，轻量快速标准文档RFC 5389应用安全支持身份验证和消息完整性验证局限。

传统流媒体 vs P2P 流媒体项目传统流媒体（CDN）P2P 流媒体架构中心化服务器去中心化节点服务器负载高低延迟中等视策略而定扩展性受限于服务器带宽极强成本高低。

浏览器A | | 浏览器B || || 1. 获取本地媒体流 (getUserMedia) || || || 2. 创建 RTCPeerConnection 对象 || || 3. 创建 Offer SDP（Session Description） || || | 4. 接收 Offer SDP| | 5. 创建 RTCPeerConnection| | 6. 创建 Answer SDP| || 7. 接收 Answer SDP || |

核心对象：WebRTC 不定义信令协议，常用方案：信令交换内容包括：通信流程服务端组件架构虽然 WebRTC 是 P2P，但实际场景常常需要以下服务器支撑：