Кратко

  • RFC 9607 регистрирует audio/scip и video/scip, описывает их отображение в SDP и требует пересылать переменную нагрузку без перекодирования, фильтрации по форме и модификации.
  • SDP согласует применение SCIP, а не внутренний кодек или состояние защиты; прибытие RTP, сборка, проверка целостности, обмен SCIP, личность партнёра и воспроизведение остаются разными фактами.
  • Документ прямо сообщает, что IETF не проводила аудит безопасности SCIP и не проверяла содержащиеся в нём заявления о безопасности.

Пограничное устройство сохранило предложение, а вызов не состоялся

В SDP-оффере динамический тип 97 был связан с scip/90000. Ответ сохранил отображение, пограничное устройство не удалило неизвестный псевдокодек, а RTP достиг другой стороны. На сетевом уровне всё выглядело исправно.

SCIP-сеанс всё же не завершился. Это не противоречие, а граница измерения. Внешняя сигнализация открыла возможность использовать SCIP. Она не собрала внутренние сообщения, не согласовала версию и возможности, не удостоверила партнёра и не декодировала видео.

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

Динамический номер живёт только внутри конкретной договорённости

Для audio/scip установлена частота 8000 Гц, для video/scip — 90000 Гц. Строка m= называет аудио или видео, а a=rtpmap связывает номер, имя scip и частоту. Порядок в offer/answer выражает предпочтение.

Сам номер не является глобальной идентичностью формата. Значение 96 или 97 определяется SDP именно этого сеанса. Журнал RTP без исходного offer и answer теряет координату, необходимую для толкования пакета.

Даже правильное отображение не выбирает внутренний аудио- или видеокодек. Возможности и версия согласуются сообщениями SCIP внутри непрозрачного канала. Внешнее согласие, внутренний режим и защищённый сеанс нельзя сводить к одной строке состояния.

Инспектор шифротекста становится тормозом обновления

Размер, ритм и форма нагрузки SCIP меняются вместе с состоянием протокола и скрытым медиа. RFC 9607 запрещает сети перекодировать, сжимать с потерями, менять или фильтровать её по текущему наблюдаемому рисунку.

Если межсетевой экран обучится на сегодняшнем шифротексте, завтра законное обновление перестанет соответствовать шаблону. Тогда развитие конечного протокола потребует разрешения каждого устаревшего устройства на пути. Такая зависимость является оссификацией, даже если продавалась как функция безопасности.

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

Ограничение MTU заканчивается до доказательства сборки

Приложение SCIP передаёт RTP материал, не превышающий MTU. На приёме слой SCIP RTP идентифицирует пакеты, восстанавливает порядок и собирает сообщение. При необходимости приложение обнаруживает ошибки и выполняет повторную передачу.

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

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

Проверка целостности даёт право отказать

Изменение нагрузки SCIP обнаруживается конечным узлом как нарушение целостности, после чего возможен повтор, а при продолжении проблемы — отказ связи. Промежуточный узел не может незаметно «улучшить» защищённые байты.

Событие доказывает отказ конкретного объекта в конкретном состоянии, но не готовую атрибуцию атаки. Возможны повреждение, рассинхронизация и дефект реализации. Оно не сообщает, прибыл ли повтор. Отсутствие отказов не доказывает полноту, правильного партнёра или понятный результат.

Следует связывать направление, объект, диапазон RTP, результат проверки, запрос повтора, замену и решение приложения. Тогда видно различие между работающим механизмом запрета и работающим разговором.

Внутреннее шифрование не закрывает заголовок и RTCP

SCIP шифрует содержимое RTP payload. Заголовок RTP и пакеты RTCP этим не защищаются. Приложение может выбрать SRTP для дополнительных поверхностей, но RFC 9607 оставляет такую защиту необязательной.

Выбор AVP, AVPF, SAVP или SAVPF поэтому является отдельным решением. Feedback о потерях AVPF/SAVPF тоже опционален, поскольку SCIP сам повторяет часть потерянных или ошибочных пакетов. Внутреннее восстановление и внешний feedback имеют разные состояния и сроки.

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

RFC стандартизировал шов, а не вынес вердикт всей системе

RFC 9607 недвусмысленно говорит: IETF не проводила проверку безопасности SCIP и не подтверждала соответствующие заявления. Статус Standards Track относится к определённому формату RTP/SDP и регистрации медиа, а не к сертификации всего скрытого протокола.

Это позволяет правильно разделить тесты. Имя, частота, отображение SDP, прозрачная пересылка и запрет модификации проверяются по RFC. Управление ключами, аутентификация партнёра, конфиденциальность и устойчивость к атакам требуют других источников и испытаний.

Требование «соответствует RFC 9607» не должно закрывать раздел безопасности закупки. Каждое ожидаемое свойство получает владельца, тест, срок годности доказательства и план отказа.

Источники