【ZeroRange WebRTC】REMB（Receiver Estimated Maximum Bitrate）技术深度分析

REMB（Receiver Estimated Maximum Bitrate）技术深度分析

概述

REMB（接收端估计最大比特率）是WebRTC中实现带宽自适应的核心机制之一。它允许接收端根据网络状况主动估计可用带宽，并通过RTCP反馈消息将这一信息传递给发送端，从而实现动态的码率调整，确保在变化的网络环境下维持最佳的音视频质量。

基本原理

1. 工作机制

REMB基于以下核心原理工作：

接收端主动测量：

• 接收端监测网络状况，包括丢包率、延迟、抖动等指标
• 基于这些指标计算当前网络的承载能力
• 生成带宽估计值并发送给发送端

发送端自适应调整：

• 发送端接收REMB消息，解析带宽估计值
• 根据估计值调整发送码率，避免网络拥塞
• 实现平滑的码率过渡，保证用户体验

反馈闭环控制：

• 形成"测量-反馈-调整"的闭环控制系统
• 持续监测网络变化，实时调整策略
• 平衡带宽利用率和传输质量

2. 与TWCC的区别

在WebRTC生态中，存在两种主要的带宽估计机制：

特性	REMB	TWCC
测量位置	接收端	发送端（基于接收端反馈）
反馈内容	直接带宽估计值	详细的包接收状态
计算复杂度	较低	较高
精度	中等	高
兼容性	广泛支持	较新机制
响应速度	中等	快速

协议格式详解

1. RTCP REMB报文结构

REMB作为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|  FMT=15 |    PT=206     |             length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     SSRC of packet sender                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      SSRC of media source                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Unique identifier 'R' 'E' 'M' 'B' (0x52454D42)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Num SSRC     |   BR Exp    |  BR Mantissa                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          SSRC 1                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          SSRC 2                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                              ...                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

字段详细说明：

RTCP头部：

• V (Version): 2位，协议版本号，固定为2
• P (Padding): 1位，填充标志
• FMT (Format): 5位，格式类型，对于REMB固定为15
• PT (Packet Type): 8位，包类型，206表示负载特定反馈
• length: 16位，RTCP包长度（32位字减1）

REMB特定字段：

• SSRC of packet sender: 32位，发送此反馈包的SSRC
• SSRC of media source: 32位，被反馈的媒体流SSRC（通常为0）
• Unique identifier: 32位，REMB标识符"REMB"（0x52454D42）
• Num SSRC: 8位，后续SSRC列表的数量
• BR Exp: 8位，比特率指数的8位值
• BR Mantissa: 16位，比特率尾数的16位值（实际为24位，跨字段）
• SSRC list: 变长，受此REMB影响的SSRC列表

2. 比特率编码机制

REMB使用指数-尾数（Exponential-Mantissa）编码来表示比特率值：

// 比特率计算公式
bitrate = mantissa * (2^exponent)

// 实际编码（24位尾数）
// BR Mantissa占用16位 + BR Exp的高8位提供额外的8位
mantissa = (pPayload[RTCP_PACKET_REMB_IDENTIFIER_OFFSET + SIZEOF(UINT32)] & 0x03) << 16 |
           getUnalignedInt16BigEndian(pPayload + RTCP_PACKET_REMB_IDENTIFIER_OFFSET + SIZEOF(UINT32) + SIZEOF(BYTE));

编码优势：

• 支持大范围的比特率值（几kbps到几Gbps）
• 保持相对精度
• 节省报文空间

3. 协议解析实现

从代码分析可见REMB报文的解析过程：

STATUS rembValueGet(PBYTE pPayload, UINT32 payloadLen, PDOUBLE pMaximumBitRate, 
                    PUINT32 pSsrcList, PUINT8 pSsrcListLen)
{
    // 1. 验证REMB标识符
    const BYTE rembUniqueIdentifier[] = {0x52, 0x45, 0x4d, 0x42}; // "REMB"
    CHK(MEMCMP(rembUniqueIdentifier, pPayload + RTCP_PACKET_REMB_IDENTIFIER_OFFSET, 
               SIZEOF(rembUniqueIdentifier)) == 0, STATUS_RTCP_INPUT_REMB_INVALID);
    
    // 2. 提取比特率值
    UINT32 mantissa = getUnalignedInt32BigEndian(pPayload + RTCP_PACKET_REMB_IDENTIFIER_OFFSET + SIZEOF(UINT32));
    mantissa = htonl(mantissa);
    mantissa &= RTCP_PACKET_REMB_MANTISSA_BITMASK; // 0x3FFFF
    
    UINT8 exponent = pPayload[RTCP_PACKET_REMB_IDENTIFIER_OFFSET + SIZEOF(UINT32) + SIZEOF(BYTE)] >> 2;
    DOUBLE maximumBitRate = mantissa << exponent; // 比特率 = 尾数 * 2^指数
    
    // 3. 提取SSRC列表
    UINT8 ssrcListLen = pPayload[RTCP_PACKET_REMB_IDENTIFIER_OFFSET + SIZEOF(UINT32)];
    for (UINT32 i = 0; i < ssrcListLen; i++) {
        pSsrcList[i] = getUnalignedInt32BigEndian(
            pPayload + RTCP_PACKET_REMB_IDENTIFIER_OFFSET + 8 + (i * SIZEOF(UINT32)));
    }
    
    *pMaximumBitRate = maximumBitRate;
    *pSsrcListLen = ssrcListLen;
}

带宽估计算法

1. 基础算法原理

REMB的带宽估计基于以下网络指标：

丢包率（Packet Loss Rate）：

• 丢包率是网络拥塞的直接指标
• 低丢包率（<2%）：网络状况良好，可以增加带宽
• 中等丢包率（2%-10%）：网络轻度拥塞，需要谨慎调整
• 高丢包率（>10%）：网络严重拥塞，需要大幅降低带宽

接收速率（Receive Rate）：

• 测量实际接收的数据速率
• 作为带宽估计的基础参考值
• 结合丢包率计算理论最大带宽

抖动和延迟（Jitter & Delay）：

• 网络延迟的变化反映拥塞程度
• 延迟增加通常预示着拥塞发生
• 抖动影响实时性体验

2. 算法实现策略

基于Amazon Kinesis WebRTC SDK的代码分析，REMB的实现策略包括：

// 简化的REMB计算逻辑
typedef struct {
    DOUBLE currentBitrate;          // 当前比特率
    DOUBLE estimatedBitrate;        // 估计比特率
    DOUBLE averageLossRate;         // 平均丢包率
    UINT64 lastAdjustmentTime;      // 上次调整时间
    UINT32 consecutiveLossEvents;   // 连续丢包事件数
} RembEstimator;

DOUBLE calculateRembBitrate(RembEstimator* estimator, 
                           UINT32 packetsLost, UINT32 packetsReceived,
                           UINT64 currentTime) {
    DOUBLE lossRate = (DOUBLE)packetsLost / (packetsLost + packetsReceived);
    
    // 指数移动平均滤波
    estimator->averageLossRate = EMA_FILTER(estimator->averageLossRate, lossRate, 0.2);
    
    // 基于丢包率的带宽调整
    if (estimator->averageLossRate < 0.02) {
        // 低丢包率：增加带宽
        estimator->estimatedBitrate = MIN(estimator->estimatedBitrate * 1.05, MAX_BITRATE);
    } else if (estimator->averageLossRate > 0.10) {
        // 高丢包率：大幅减少带宽
        estimator->estimatedBitrate *= (1.0 - estimator->averageLossRate);
        estimator->consecutiveLossEvents++;
    } else {
        // 中等丢包率：轻微调整
        estimator->estimatedBitrate *= (1.0 - estimator->averageLossRate * 0.5);
    }
    
    // 确保比特率在合理范围内
    estimator->estimatedBitrate = MAX(estimator->estimatedBitrate, MIN_BITRATE);
    
    return estimator->estimatedBitrate;
}

3. 时间窗口和滤波

为了提高估计的稳定性，REMB使用多种滤波技术：

指数移动平均（EMA）：

#define EMA_FILTER(current, new_value, alpha) \
    ((alpha) * (new_value) + (1.0 - (alpha)) * (current))

// 应用EMA滤波
estimator->averageLossRate = EMA_FILTER(estimator->averageLossRate, lossRate, 0.2);

时间窗口控制：

// 避免频繁调整
#define REMB_ADJUSTMENT_INTERVAL_MS 1000  // 1秒间隔

if (currentTime - estimator->lastAdjustmentTime < REMB_ADJUSTMENT_INTERVAL_MS) {
    return estimator->currentBitrate;  // 保持当前比特率
}

实现机制详解

1. REMB接收处理

当接收端收到REMB消息时的处理流程：

STATUS onRtcpRembPacket(PRtcpPacket pRtcpPacket, PKvsPeerConnection pKvsPeerConnection)
{
    UINT32 ssrcList[MAX_UINT8] = {0};
    DOUBLE maximumBitRate = 0;
    UINT8 ssrcListLen;
    
    // 1. 解析REMB值
    CHK_STATUS(rembValueGet(pRtcpPacket->payload, pRtcpPacket->payloadLength, 
                           &maximumBitRate, ssrcList, &ssrcListLen));
    
    // 2. 查找对应的收发器
    for (UINT32 i = 0; i < ssrcListLen; i++) {
        PKvsRtpTransceiver pTransceiver = NULL;
        if (STATUS_SUCCEEDED(findTransceiverBySsrc(pKvsPeerConnection, &pTransceiver, ssrcList[i]))) {
            // 3. 触发带宽估计回调
            if (pTransceiver->onBandwidthEstimation != NULL) {
                pTransceiver->onBandwidthEstimation(pTransceiver->onBandwidthEstimationCustomData, 
                                                   maximumBitRate);
            }
        }
    }
}

2. 带宽估计回调处理

应用程序注册带宽估计回调函数：

// 注册带宽估计回调
STATUS transceiverOnBandwidthEstimation(PRtcRtpTransceiver pRtcRtpTransceiver, 
                                       UINT64 customData, 
                                       RtcOnBandwidthEstimation rtcOnBandwidthEstimation)
{
    PKvsRtpTransceiver pKvsRtpTransceiver = (PKvsRtpTransceiver) pRtcRtpTransceiver;
    
    pKvsRtpTransceiver->onBandwidthEstimation = rtcOnBandwidthEstimation;
    pKvsRtpTransceiver->onBandwidthEstimationCustomData = customData;
}

// 示例回调函数实现
VOID sampleBandwidthEstimationHandler(UINT64 customData, DOUBLE maximumBitRate)
{
    SampleStreamingSession* pSampleStreamingSession = (SampleStreamingSession*) customData;
    
    DLOGI("Received REMB bitrate estimation: %.2f bps", maximumBitRate);
    
    // 根据REMB值调整编码参数
    if (maximumBitRate > 0) {
        // 调整视频编码比特率
        updateVideoEncoderBitrate(pSampleStreamingSession, maximumBitRate);
        
        // 调整音频编码比特率（通常比例较小）
        updateAudioEncoderBitrate(pSampleStreamingSession, maximumBitRate * 0.1);
    }
}

3. 编码器码率调整

根据REMB估计值调整编码器参数：

STATUS updateVideoEncoderBitrate(SampleStreamingSession* pSession, DOUBLE rembBitrate)
{
    // 1. 考虑协议开销（通常15-25%）
    UINT64 effectiveBitrate = (UINT64)(rembBitrate * 0.8);  // 保留20%余量
    
    // 2. 考虑音频占用（通常10%）
    UINT64 videoBitrate = effectiveBitrate * 0.9;
    
    // 3. 确保在编码器能力范围内
    videoBitrate = MAX(videoBitrate, MIN_VIDEO_BITRATE);
    videoBitrate = MIN(videoBitrate, MAX_VIDEO_BITRATE);
    
    // 4. 平滑过渡，避免突变
    if (pSession->currentVideoBitrate > 0) {
        UINT64 targetBitrate = (pSession->currentVideoBitrate + videoBitrate) / 2;
        pSession->targetVideoBitrate = targetBitrate;
    } else {
        pSession->targetVideoBitrate = videoBitrate;
    }
    
    // 5. 应用新的比特率设置
    return applyEncoderBitrateSettings(pSession, pSession->targetVideoBitrate);
}

性能优化策略

1. 平滑过渡机制

避免比特率的剧烈变化，使用平滑算法：

typedef struct {
    DOUBLE currentBitrate;
    DOUBLE targetBitrate;
    DOUBLE smoothingFactor;  // 平滑因子，如0.1
    UINT64 lastUpdateTime;
} SmoothBitrateController;

DOUBLE smoothBitrateTransition(SmoothBitrateController* controller, UINT64 currentTime) {
    DOUBLE timeDiff = (DOUBLE)(currentTime - controller->lastUpdateTime) / 1000.0;  // 秒
    
    if (timeDiff > 0) {
        // 指数平滑
        DOUBLE alpha = 1.0 - exp(-timeDiff / controller->smoothingFactor);
        controller->currentBitrate += alpha * (controller->targetBitrate - controller->currentBitrate);
        controller->lastUpdateTime = currentTime;
    }
    
    return controller->currentBitrate;
}

2. 多流协调

当存在多个媒体流时，协调各流的码率分配：

VOID distributeBitrateAmongStreams(UINT64 totalBitrate, MediaStream* streams, UINT32 streamCount) {
    // 1. 计算各流的优先级权重
    DOUBLE totalWeight = 0;
    for (UINT32 i = 0; i < streamCount; i++) {
        streams[i].weight = calculateStreamWeight(&streams[i]);
        totalWeight += streams[i].weight;
    }
    
    // 2. 按比例分配比特率
    for (UINT32 i = 0; i < streamCount; i++) {
        DOUBLE ratio = streams[i].weight / totalWeight;
        streams[i].allocatedBitrate = (UINT64)(totalBitrate * ratio);
        
        // 3. 确保在最小需求之上
        streams[i].allocatedBitrate = MAX(streams[i].allocatedBitrate, 
                                       streams[i].minBitrate);
    }
    
    // 4. 处理剩余比特率的二次分配
    distributeRemainingBitrate(streams, streamCount);
}

3. 网络类型自适应

根据不同的网络类型调整REMB策略：

typedef enum {
    NETWORK_TYPE_WIRED,      // 有线网络
    NETWORK_TYPE_WIFI,       // WiFi网络
    NETWORK_TYPE_CELLULAR_4G, // 4G移动网络
    NETWORK_TYPE_CELLULAR_5G, // 5G移动网络
    NETWORK_TYPE_SATELLITE   // 卫星网络
} NetworkType;

RembConfig getAdaptiveRembConfig(NetworkType networkType) {
    switch (networkType) {
        case NETWORK_TYPE_WIRED:
            return (RembConfig){
                .increaseStep = 1.05,      // 5%增长
                .decreaseFactor = 0.9,      // 10%下降
                .adjustmentInterval = 1000, // 1秒
                .lossThreshold = 0.02      // 2%丢包阈值
            };
            
        case NETWORK_TYPE_WIFI:
            return (RembConfig){
                .increaseStep = 1.03,      // 3%增长（更保守）
                .decreaseFactor = 0.85,    // 15%下降
                .adjustmentInterval = 1500, // 1.5秒
                .lossThreshold = 0.03      // 3%丢包阈值
            };
            
        case NETWORK_TYPE_CELLULAR_4G:
            return (RembConfig){
                .increaseStep = 1.02,      // 2%增长（非常保守）
                .decreaseFactor = 0.8,     // 20%下降
                .adjustmentInterval = 2000, // 2秒
                .lossThreshold = 0.05      // 5%丢包阈值
            };
    }
}

实际应用考量

1. 与编码器的集成

REMB需要与具体的编码器实现紧密集成：

// H.264编码器的比特率调整
STATUS adjustH264Bitrate(H264Encoder* encoder, UINT64 targetBitrate) {
    // 1. 设置目标比特率
    encoder->bitRate = targetBitrate;
    
    // 2. 调整GOP结构（关键帧间隔）
    if (targetBitrate < encoder->previousBitrate * 0.7) {
        // 大幅降低时，增加关键帧频率以快速恢复
        encoder->keyFrameInterval = 30; // 1秒一个关键帧
    } else if (targetBitrate > encoder->previousBitrate * 1.3) {
        // 大幅增加时，可以适当延长关键帧间隔
        encoder->keyFrameInterval = 60; // 2秒一个关键帧
    }
    
    // 3. 调整编码参数
    updateEncoderParameters(encoder);
    
    encoder->previousBitrate = targetBitrate;
    return STATUS_SUCCESS;
}

2. 场景适配

不同的应用场景需要不同的REMB策略：

视频会议场景：

• 优先保证音频质量
• 视频可以适当降低分辨率
• 快速响应网络变化

直播场景：

• 优先保证视频质量
• 可以接受更大的延迟
• 渐进式码率调整

屏幕共享场景：

• 需要高清晰度
• 对文本清晰度要求极高
• 码率波动容忍度低

3. 性能监控

建立完善的REMB性能监控体系：

typedef struct {
    // 基础统计
    UINT64 rembMessagesReceived;    // 收到的REMB消息数
    DOUBLE averageRembBitrate;       // 平均REMB比特率
    DOUBLE minRembBitrate;         // 最小REMB比特率
    DOUBLE maxRembBitrate;         // 最大REMB比特率
    
    // 性能指标
    UINT64 bitrateAdjustmentCount;  // 码率调整次数
    DOUBLE averageAdjustmentSize;  // 平均调整幅度
    UINT64 overuseEvents;           // 过载事件数
    UINT64 underuseEvents;          // 欠载事件数
    
    // 质量指标
    DOUBLE averageLossRate;         // 平均丢包率
    DOUBLE averageDelay;           // 平均延迟
    UINT64 qualityDegradationEvents; // 质量下降事件数
} RembStatistics;

VOID logRembStatistics(RembStatistics* stats) {
    DLOGI("REMB Statistics:");
    DLOGI("  Messages received: %llu", stats->rembMessagesReceived);
    DLOGI("  Average bitrate: %.2f bps", stats->averageRembBitrate);
    DLOGI("  Bitrate range: [%.2f, %.2f] bps", stats->minRembBitrate, stats->maxRembBitrate);
    DLOGI("  Adjustments: %llu (avg size: %.2f%%)", 
          stats->bitrateAdjustmentCount, stats->averageAdjustmentSize * 100);
    DLOGI("  Overuse events: %llu, Underuse events: %llu", 
          stats->overuseEvents, stats->underuseEvents);
}

故障排除与最佳实践

1. 常见问题诊断

REMB值不更新：

// 诊断检查列表
BOOL diagnoseRembNotUpdating(PKvsPeerConnection pPeerConnection) {
    // 1. 检查回调是否注册
    if (pPeerConnection->onBandwidthEstimation == NULL) {
        DLOGW("Bandwidth estimation callback not registered");
        return FALSE;
    }
    
    // 2. 检查REMB消息是否接收
    if (pPeerConnection->rembStats.rembMessagesReceived == 0) {
        DLOGW("No REMB messages received from remote peer");
        return FALSE;
    }
    
    // 3. 检查网络连接状态
    if (pPeerConnection->connectionState != RTC_PEER_CONNECTION_STATE_CONNECTED) {
        DLOGW("Peer connection not in connected state");
        return FALSE;
    }
    
    return TRUE;
}

码率调整过于频繁：

// 防抖机制
VOID debounceRembAdjustment(RembEstimator* estimator, DOUBLE newBitrate, UINT64 currentTime) {
    static UINT64 lastAdjustmentTime = 0;
    static DOUBLE lastBitrate = 0;
    
    // 时间防抖
    if (currentTime - lastAdjustmentTime < MIN_ADJUSTMENT_INTERVAL_MS) {
        return;
    }
    
    // 幅度防抖（避免小幅震荡）
    DOUBLE changeRatio = ABS(newBitrate - lastBitrate) / lastBitrate;
    if (changeRatio < MIN_SIGNIFICANT_CHANGE) {
        return;
    }
    
    // 执行调整
    performBitrateAdjustment(newBitrate);
    lastAdjustmentTime = currentTime;
    lastBitrate = newBitrate;
}

2. 性能优化

内存优化：

// 使用对象池减少内存分配
typedef struct {
    RembMessage msgPool[MAX_POOL_SIZE];
    UINT32 poolIndex;
    MUTEX poolLock;
} RembMessagePool;

RembMessage* acquireRembMessage(RembMessagePool* pool) {
    MUTEX_LOCK(pool->poolLock);
    RembMessage* msg = &pool->msgPool[pool->poolIndex++ % MAX_POOL_SIZE];
    MUTEX_UNLOCK(pool->poolLock);
    return msg;
}

CPU优化：

// 批量处理REMB消息
VOID processRembMessagesBatch(RtcpPacket* packets[], UINT32 count) {
    // 预分配批量处理所需资源
    preallocateBatchResources(count);
    
    // 批量解析和处理
    for (UINT32 i = 0; i < count; i++) {
        // 使用SIMD指令优化（如果支持）
        processRembMessageOptimized(packets[i]);
    }
    
    // 批量清理
    cleanupBatchResources();
}

3. 最佳实践建议

配置建议：

// 推荐的REMB配置参数
RembConfig recommendedConfig = {
    .minBitrate = 30000,        // 30 kbps 最小值
    .maxBitrate = 2000000,      // 2 Mbps 最大值
    .initialBitrate = 300000,   // 300 kbps 初始值
    .adjustmentInterval = 1000, // 1秒调整间隔
    .smoothingFactor = 0.2,     // 20% 平滑因子
    .lossThreshold = 0.02,      // 2% 丢包阈值
    .increaseStep = 1.05,       // 5% 增长步长
    .decreaseFactor = 0.85      // 15% 下降因子
};

部署建议：

1. 监控关键指标：丢包率、延迟、码率变化频率
2. A/B测试：对比不同REMB策略的效果
3. 渐进式部署：先在小范围测试，再逐步推广
4. 回退机制：准备快速回退到备用策略的方案
5. 用户反馈：收集用户体验数据，持续优化算法

总结

REMB作为WebRTC带宽自适应的经典机制，在实时音视频通信中发挥着重要作用。通过接收端的主动测量和发送端的自适应调整，REMB能够有效应对网络环境的变化，在保证传输质量的同时最大化带宽利用率。

Amazon Kinesis Video Streams WebRTC SDK的REMB实现展现了以下技术特点：

1. 标准兼容性：严格遵循RFC规范，确保与其他WebRTC实现的互操作性
2. 高效编码：使用指数-尾数编码，在有限空间内表达大范围的比特率值
3. 灵活配置：支持多种参数配置，适应不同应用场景
4. 平滑过渡：避免码率突变，保证用户体验的连续性
5. 完善统计：提供详细的性能指标，便于监控和优化

在实际应用中，REMB特别适合以下场景：

• 需要快速部署的实时通信应用
• 对兼容性要求较高的系统
• 网络环境相对稳定的场景
• 作为更高级带宽控制策略的基础组件

随着WebRTC技术的不断发展，虽然TWCC等更先进的机制正在兴起，但REMB凭借其简单性、兼容性和可靠性，仍然是带宽自适应领域的重要技术选择。

参考资源

• RFC draft-alvestrand-rmcat-remb-03
• RFC 3550 - RTP: A Transport Protocol for Real-Time Applications
• RFC 4585 - Extended RTP Profile for RTCP-Based Feedback
• WebRTC Bandwidth Estimation
• Google Congestion Control Algorithm