Кратко

  • RFC 5124 объединяет AVPF и SAVP в профиль SAVPF, сохраняя функции каждого слоя.
  • AVPF планирует RTCP-отзыв, а SAVP затем добавляет обработку и поля SRTCP.
  • Защитные поля в описанном контексте добавляют примерно 10–20 байт; стандартный пример — 14 байт.
  • Реализация обязана учитывать защищённый размер в avg_rtcp_size.
  • В приближении N <= B*T/R рост R уменьшает число событий, сообщаемых за ту же полосу и срок.
  • Режимы Immediate Feedback, Early RTCP и Regular RTCP отражают разную способность сообщать отдельные события.
  • Граница режимов зависит не только от числа участников, но и от потерь, кодека, частоты событий, полосы и размера пакета.
  • Успешный SAVPF не доказывает, что отзыв прибыл до прикладного T_max_fb_delay.
  • Он также не доказывает защищённую сигнализацию, установленный ключ, принятую SRTCP-посылку или восстановленный медиапоток.
  • Целостность SRTCP обязательна, но шифрование может быть NULL; групповая метка не всегда указывает одного автора.
  • Смешанное предложение безопасных и небезопасных профилей требует защиты от понижения.
  • Руководству нужен запас до порога, а не двоичный значок функции.

Переход, который не разрывает сессию

В небольшой группе каждый потерянный пакет почти сразу вызывает отзыв. Затем к сеансу присоединяются новые получатели. Соединение остаётся установлено, ключи продолжают проверяться, а профиль в SDP не меняется. Но отдельному участнику уже не хватает доли RTCP, чтобы сообщать каждое событие.

AVPF описывает этот сдвиг как переход от Immediate Feedback к Early RTCP. В Immediate доступной полосы достаточно практически для всех релевантных событий. В Early приходится выбирать, хотя некоторые сообщения всё ещё успевают повлиять на передачу. Ещё дальше лежит Regular RTCP: отзыв по отдельному событию теряет смысл из-за временного масштаба или размера группы.

Это не три флага согласования. Это режимы, возникающие из текущей экономики потока. Поэтому изменение может пройти без нового SDP и без аварии. Если наблюдение ограничено статусом SAVPF, система пропустит потерю запаса.

Безопасность увеличивает переменную R

RFC 5124 соединяет механизм времени AVPF из RFC 4585 с защитой SAVP из RFC 3711. Верхний слой определяет формат и момент RTCP-отзыва. Нижний преобразует назначенную посылку в SRTCP. Все RTCP-пакеты SAVPF должны иметь SRTCP-инкапсуляцию.

Индекс, метка аутентификации и возможный MKI занимают место. Документ оценивает добавку в рассматриваемых настройках как примерно 10–20 байт и приводит 14 байт для стандартного случая. Новые преобразования и выбранные длины могут дать другое число.

Нормативное следствие важнее исторической цифры: avg_rtcp_size должен отражать SRTCP. Если планировщик хранит средний размер открытого RTCP, он считает, будто располагает большим числом передач, чем реально допускает полоса.

Приближение RFC 4585 N <= B*T/R показывает направление. N — среднее число событий в интервале T, B — доля полосы RTCP получателя, R — средний размер. При неизменных B и T увеличение R уменьшает допустимое N.

Защита не является ошибкой. Ошибка — вынести её цену за пределы расчёта. Криптография может работать безупречно, пока своевременность постепенно ухудшается.

У порога нет универсального числа участников

На режим влияют тип отзыва, частота пакетов, вероятность и распределение потерь, кодек, наблюдаемая частота событий, выделенная полоса и средний размер. Две группы одинаковой численности могут находиться по разные стороны границы.

T_max_fb_delay задаёт максимальную задержку, после которой отзыв бесполезен для конкретного приложения. RFC 5124 не обещает общего значения. У аудио, видео и DTMF могут быть разные окна. Правильная SRTCP-посылка, пришедшая позже, остаётся криптографически правильной и операционно запоздалой.

Даже своевременность не равна восстановлению. Отправитель может не хранить исходный пакет, выбрать смену битрейта, не выполнить действие или потерять повтор. Декодер может уже лишиться опорного состояния. Нужны отметки обнаружения, планирования, отправки, принятия, действия, доставки медиаданных, декодирования и отображения.

Профиль не содержит криптографического контекста

SAVPF наследует услуги SAVP, но не определяет новый шифр или управление ключами. Рабочий SRTCP требует алгоритмов, мастер- и сеансовых ключей, индекса, replay-окна, срока действия и, возможно, MKI. Строка профиля в SDP не доказывает наличие этих значений.

RFC 3711 требует целостность SRTCP, поскольку подмена управления опасна для медиапотока. Шифрование отдельно и может быть NULL. Поэтому «защищённый профиль» не позволяет автоматически заявить конфиденциальность содержимого.

В группе общая метка способна показать, что пакет создал кто-то из держателей ключа, но не всегда кто именно. Сам стандарт ограничивает смысл слова authentication в подобных обстоятельствах. Утверждение о происхождении должно следовать фактической схеме ключей.

Пакет может быть отвергнут из-за старой эпохи, неверного индекса или replay-окна. Это результат проверки, а не опровержение того, что SAVPF когда-то был согласован. Обе записи должны сохраниться.

До защищённого пакета есть незащищённый выбор

RFC 5124 предупреждает: одновременное предложение безопасных и небезопасных альтернатив позволяет bidding-down и подобные атаки. Если обе семьи всё же предлагаются, сигнализацию согласования необходимо должным образом защитить.

Локальный порядок предпочтения недостаточен. Нужна целостность предложения, последовательности, атрибутов и ответа. SRTCP начинает защищать управление после выбора и ключей; он не может задним числом удостоверить изменённое SDP.

Для одного описания AVP, AVPF, SAVP и SAVPF взаимоисключающие варианты. Если отвечающая сторона не поддерживает предложенный SAVPF, она должна отклонить этот медиаканал. Если она хочет SAVPF, которого не было в предложении, она также отклоняет канал и может позже послать встречное предложение.

Согласование идёт по медиалиниям. Аудио может быть принято, видео — отвергнуто. Разные RTP-сессии могут использовать разные профили. Единый зелёный индикатор звонка теряет эту структуру.

Совместимость имеет узкий шов

Участники SAVP и SAVPF могут находиться в одной безопасной RTP-сессии; AVP и AVPF — в одной небезопасной. Но безопасную и небезопасную семьи нельзя смешивать в той же RTP-сессии, поскольку RTP и SRTP не взаимодействуют так на проводе. В отдельных RTP-сессиях профили могут различаться.

В описанном RFC 5124 RTSP-процессе клиент выбирает ровно один профиль на поток в SETUP, а сервер подтверждает или отказывает. Смена требует TEARDOWN и нового SETUP. Это переход транспорта и ключевого состояния, которому нужны собственные доказательства непрерывности.

При объявлении через SAP, веб или почту интерактивного ответа нет. Инициатор отвечает за доступные альтернативы и защиту параметров. Inline-ключи RFC 4568 требуют конфиденциального канала; последующий SRTCP не исправляет ранее раскрытый ключ.

RFC 8866 позже заменила старое SDP, RFC 7826 — старый RTSP, а RFC 5763/5764 дали последующий контекст DTLS-SRTP. Это история документов, а не свидетельство нынешнего внедрения или формальное обновление RFC 5124.

RFC Editor сохраняет RFC 5124 как Proposed Standard февраля 2008 года без указанных связей update или obsolete. IANA подтверждает распределение параметров. В источниках нет названного внедрения, инцидента, доли рынка, полевого измерения или доказанной пользовательской выгоды.

Источники