Термин
Transport-CC
Формат congestion-control-обратной-связи WebRTC. Получатель шлёт отправителю детальные per-packet arrival times через RTCP, давая bandwidth-estimator-у отправителя принимать точные решения.
Transport-CC (определён в `draft-holmer-rmcat-transport-wide-cc-extensions`, изначально контрибуция Google, широко используется с 2016) – механизм per-packet обратной связи, на котором стоит современный WebRTC bandwidth estimation. Где классические RTCP receiver reports дают грубую loss/jitter-статистику раз в несколько секунд, Transport-CC шлёт компактное RTCP-сообщение с точным временем прихода каждого недавнего RTP-пакета каждые несколько сотен миллисекунд.
Отправитель использует этот поток таймингов для оценки bottleneck bandwidth и queueing delay. Алгоритм Google GCC (Google Congestion Control) – дефолт WebRTC в Chrome и Firefox – использует Transport-CC-feedback для непрерывной подстройки send rate. Итог – гораздо более отзывчивая bandwidth-адаптация, чем при классическом RTCP, что критично для суб-секундного WebRTC, где буфера для поглощения ошибок нет.
Transport-CC асимметричен – получатель шлёт богатую обратную связь, отправитель ею подстраивается. Поддержка нужна обоим (согласуется через SDP-расширение `transport-cc` и строки `goog-remb` / `goog-cc`). Каждый современный WebRTC-стек по умолчанию умеет Transport-CC; старые или специализированные стеки могут откатываться на receiver-side bandwidth estimation, что работает с меньшей точностью. Кастомные WebRTC-пайплайны под low-latency live часто пишут свои bandwidth-estimator-ы, потребляющие Transport-CC напрямую.
Считаете параметры для своего продукта?
Поможем собрать энкодер-леддер и посчитать стоимость доставки – до старта разработки.