1. RTP协议基础解析：实时传输的核心骨架

RTP（Real-time Transport Protocol）作为互联网实时音视频传输的基石协议，其设计哲学体现在头部结构的每个bit中。协议头前12字节是固定部分，其中我最常关注的几个关键字段：

• 时间戳（Timestamp）：32位无符号整数，记录采样时刻。在视频场景中，相邻帧的时间戳差值取决于帧率。例如30fps视频中，这个差值应该是90000/30=3000（RTP时间戳以Hz为单位）。
• 序列号（Sequence Number）：16位循环计数器。每次发送数据包+1，用于检测丢包。我在排查问题时发现，超过1%的序列号不连续就会明显影响体验。
• 同步源标识（SSRC）：32位随机数，用于区分同一会话中的不同流。实践中遇到过SSRC冲突的情况，需要实现冲突检测和解决机制。

关键技巧：Wireshark的RTP流分析功能可以直观显示时间戳和序列号的连续性，是排查同步问题的利器。

2. WebRTC中的RTP魔改实践

WebRTC虽然基于RTP，但做了许多针对性优化。通过chrome://webrtc-internals可以看到这些细节：

• 动态码率调整：通过RTCP RR报文反馈网络状况，算法会根据丢包率动态调整VP8/VP9的量化参数。实测在20%丢包环境下，好的实现仍能保持可接受的画质。
• 头部扩展（Header Extensions）：WebRTC添加了abs-send-time等扩展头，精确到微秒级的发送时间戳，这对拥塞控制算法至关重要。
• FlexFEC前向纠错：在RTP包中携带冗余信息，可以恢复特定程度的丢包。配置时需要权衡冗余度和带宽开销，一般建议在移动网络启用。

3. 回声消除（AEC）的工程实现

"回音壁"问题本质是声学回声，WebRTC的AEC模块采用：

1. 自适应滤波算法（NLMS）建立回声路径模型
2. 双端检测（需要音频发送流作为参考）
3. 非线性处理抑制残留回声

调试时要注意：

• 采集设备要有足够的采样率（至少16kHz）
• 避免系统自带的软件降噪干扰AEC工作
• 延迟要控制在100ms以内，否则算法收敛困难

4. 最简WebRTC配置实践

实现基础视频通话需要这些模块协同工作：

在树莓派上实测的最低配置：

• 单核1GHz CPU
• 128MB内存
• 带宽≥512kbps（QCIF分辨率）

5. 典型问题排查手册

案例1：RTP包持续丢失

• 检查防火墙UDP端口开放情况
• 用tcptdump确认包是否到达网卡
• 调整ICE候选策略优先使用中继

案例2：视频卡顿但网络良好

• 检查编码器输出帧率是否稳定
• 确认没有启用软件编码（chrome://flags禁用）
• 调整RTCP反馈间隔为500ms

案例3：回声消除失效

• 确认参考音频流正确送达AEC模块
• 检查音频设备采样率是否匹配
• 尝试调整AEC aggressiveness参数

6. 性能优化实战记录

在4G网络下的优化经验：

• 启用transport-cc拥塞控制
• 设置DSCP标记（CS3用于语音，AF41用于视频）
• 使用ULPFEC替代FlexFEC降低CPU占用
• 关键帧请求间隔调整为2秒

移动端特别注意事项：

• 屏幕旋转时触发SDP重新协商
• 后台运行时切换为音频-only模式
• 使用硬件编码器节省电量