Кратко

  • В RFC 9725 статус 201 Created доказывает, что конечная точка приняла предложение, вернула SDP-ответ и адрес ресурса сессии; он не доказывает выбор пары ICE, завершение DTLS или устойчивое поступление SRTP.
  • Признание эфира рабочим требует отдельных квитанций от сети, криптографии, медиаприёмника, обработки, CDN и плеера с явным окном наблюдения.
  • DELETE завершает управляющий ресурс, но эксплуатационное закрытие доказано лишь после остановки соответствующего медиасостояния и освобождения relay, обработки и прочих зависимых ресурсов.

Ресурс уже есть, программы ещё может не быть

Контрольная плоскость действует быстро. Кодировщик отправляет JSEP-предложение с типом application/sdp. Конечная точка возвращает SDP-ответ, заголовок Location и 201 Created. Оркестратор видит корректную транзакцию и может преждевременно превратить её в зелёный индикатор прямого эфира.

RFC 9725 намеренно даёт этой транзакции ограниченный смысл. Карточка RFC Editor и IETF Datatracker фиксируют публикацию Proposed Standard в марте 2025 года; поиск errata на момент исследования не показывал относящейся к тексту поправки. Это происхождение стандарта, а не сертификат конкретной реализации.

Семантика 201 Created из RFC 9110 говорит о создании целевого ресурса. Конечная точка обработала предложение и выделила адрес, к которому позднее применяются PATCH и DELETE. Она не утверждает, что UDP проходит через сеть, DTLS сформировал ключи, кодировщик выдаёт кадры или аудитория видит их.

У одной сессии несколько независимых часов

WHIP использует один первоначальный обмен offer/answer и не поддерживает обычное последующее согласование медиапараметров, не относящихся к ICE. Сессия содержит один MediaStream, объединяет транспорт и мультиплексирует RTP/RTCP. Клиент обычно предлагает sendonly, сервер отвечает recvonly. Простота границы не делает весь сервис одной операцией.

Нужно различать время HTTP-допуска, выбора ICE, готовности DTLS-SRTP, первой и устойчивой медиапередачи, актуальной обработки, распространения и плеера, а также полного закрытия. У каждого этапа свой наблюдатель и своё окно. Единый флаг “live” скрывает случаи, когда ранние этапы зелёные, а поздние отсутствуют.

Ответ 201 может содержать Link на STUN или TURN по правилам RFC 8288. Ссылка на сервер — ещё не проверка доступности, полномочий или пропускной способности relay.

Кандидат ICE — предложение, а не пройденный маршрут

В RFC 8445 ICE собирает кандидаты, строит пары и проверяет их посредством STUN, прежде чем номинировать выбранную пару. Поэтому список адресов в SDP показывает пространство возможностей, но не реальный путь потока.

Trickle ICE позволяет досылать кандидатов после POST. Клиент применяет PATCH с application/trickle-ice-sdpfrag, формат которого определён RFC 8840, а сама PATCH — RFC 5789. Сервер может ответить 204 No Content и молча отбросить кандидата с неподдерживаемым транспортом либо неразрешимым адресом. Следовательно, 204 подтверждает обработку фрагмента, но не пригодность каждого кандидата.

Сетевое свидетельство должно называть поколение ICE, выбранную пару, прямой или relay-путь, локальный и удалённый tuple, момент номинации и дальнейшее состояние consent freshness. При ICE restart сильная ETag разделяет поколения: отсутствие условия даёт 428 Precondition Required, устаревшее значение — 412 Precondition Failed. Ответ 200 с новыми credentials, кандидатами и ETag описывает новую попытку; connectivity checks ещё должны состояться.

Защищённый транспорт не создаёт полезный контент

RFC 5764 использует DTLS-handshake для получения ключевого материала SRTP. Транспортные требования RFC 8835, медиаправила RTP из RFC 8834 и процедуры JSEP в RFC 9429 задают соседние обязательства. Завершённый handshake доказывает криптографический контекст на выбранном транспорте. Он не доказывает, что камера дала кадр, codec принят, а пакеты продолжают идти.

Медиаквитанция должна охватывать время: первый и последний пакет, рост счётчиков пакетов и октетов, SSRC, соответствие MID/RID нужной дорожке, последовательность, потери, jitter, bitrate и RTCP либо transport feedback. Первый пакет важен как отметка, но слаб как обещание доступности.

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

После WHIP ответственность не заканчивается

WHIP доставляет WebRTC-медиа в streaming service или CDN, но не стандартизирует decoder, transcoder, packager, origin, маршрутизацию запросов, cache и player. Архитектура CDNI в RFC 7336 разделяет эти функции. RFC 7937 показывает, что журналы CDN могут генерироваться, агрегироваться, фильтроваться, собираться и исправляться до передачи другой стороне.

Поэтому доказательство не должно без проверки переходить через границу команды. Ingest подтверждает пакеты, замеченные своим приёмником. Обработка подтверждает декодированный вход и продвигающиеся renditions. Distribution подтверждает свежие объекты и наблюдения в заявленных точках. Player probe подтверждает старт, движение аудио и видео и остановки с известной позиции.

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

Право создать сессию уже расходует ресурсы

WHIP требует поддержки HTTP-аутентификации и совместимой работы с bearer token, но не определяет распространение и бизнес-смысл токена. Принятый token может давать доступ к endpoint, не разрешая любой event, bitrate, регион, длительность или бюджет.

Состояние и вычисления возникают до первого медиапакета. Авторизованный клиент способен создать множество сессий, которые никогда не завершают ICE или DTLS. RFC 9725 обсуждает POST/PATCH flooding, rate limiting и лавину повторных подключений. Угадываемые URL сессии также опасны: чужой DELETE способен остановить передачу.

Операционная бухгалтерия должна разделять созданные, но не соединённые сессии; соединённые без DTLS; защищённые без медиа; нестабильные медиа; готовый ingest без distribution; distribution без player evidence; удалённые сессии без полного освобождения. Возраст и цена каждой когорты показывают угрозу точнее общего числа.

Первоначальный POST можно направить через 307 Temporary Redirect, сохранив метод и тело. Для PATCH и DELETE поддержка редиректов не обязательна. Журнал должен сохранять исходную власть, цепочку переходов, окончательную власть URL и фактический медиасервер.

DELETE подтверждает команду, а не весь результат

Клиент отправляет DELETE на URL из Location. RFC 9725 описывает удаление ресурса, освобождение ресурсов медиасервера и завершение ICE и DTLS. Consent freshness в RFC 7675 проверяет право продолжать отправку на конкретный five-tuple при неграциозном разрыве. Это транспортное разрешение, не человеческое согласие и не доказательство полезного эфира.

Надёжное закрытие называет инициатора, полномочие и причину, сессию и поколение, момент остановки ingress-счётчиков, прекращение DTLS или consent и освобождение TURN, decoder, transcoder, packager и origin. HTTP 200 может подтвердить приём команды. Возврат связанных ресурсов подтверждается отдельно.

Так применяется принцип Running-Code Primacy: работающий поток и зависимые от него люди важнее административной картинки. Принцип минимальной общей спецификации и локализованных последующих решений объясняет полезную сдержанность WHIP: общая граница остаётся небольшой, а правила допуска, ёмкости и мониторинга принадлежат оператору. Подход “реальность, а не защита позиции” из Why BTW.Media Exists требует хранить расхождение: HTTP успешен, медиа нет; ingest успешен, зритель не получает; DELETE принят, ёмкость ещё занята.

Sources

Первичные спецификации: RFC 9725, карточка RFC Editor, IETF Datatracker, поиск errata, RFC 8445, RFC 7675, RFC 5764, RFC 8834, RFC 8835, RFC 8836, RFC 8840, RFC 9429, RFC 9110, RFC 5789, RFC 8288, RFC 7336 и RFC 7937.

Атрибутированная аналитическая рамка: Running-Code Primacy, Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption и Why BTW.Media Exists — and Why Reality, Not Advocacy, Is the Product.