Кратко

  • mode-set-recv и recvmode выражают preference receiver, а sender вправе её игнорировать. Выполнение в начале session не доказывает выполнение после transition.
  • sendmode сообщает текущий режим, но SDP может отстать от RTP. Нужна timeline offer/answer, policy, encoder и frames, а не последний snapshot.

В начале звонка sender выбрал mode 0, как просил receiver. Через минуту encoder перешёл в mode 4. Последняя сохранённая SDP всё ещё показывала исходное состояние, а отчёт продолжал считать preference выполненной.

Никто не нарушил синтаксис. Потерялась версия решения.

Preference не создаёт постоянного обязательства

EVRC-WB использует mode-set-recv для набора желательных remote modes. EVRC-B использует recvmode для одного желательного mode. Оба поля receive-only.

Remote sender MAY проигнорировать запрос, а receiver продолжает decode. RFC 5188 приводит пример: offerer готов принимать mode 0, а answerer решает посылать mode 4.

Поэтому факт, что preference соблюдали в момент T0, не означает обязательство на весь срок. Запись должна хранить каждое policy decision, его основание и интервал действия. Иначе одно раннее совпадение становится вечным зелёным статусом.

Sendmode и running encoder имеют разные часы

sendmode сообщает текущий режим encoder. Но media RTP может прибыть задолго до первой или обновлённой SDP с этим полем.

Если transition произошёл в T1, packets пришли в T2, а SDP update в T3, то control state между T1 и T3 устарел. В T3 update не назначает режим каждому прошлому packet задним числом.

Нужно сопоставлять offer/answer version, encoder transition, RTP sequence и timestamp, отправку, получение и decoder ingestion. Поздняя сигнализация не равна неправильному кодированию; окончательное совпадение не стирает окно неопределённости.

Direction сохраняет владельца

mode-set-recv и recvmode относятся к приёму, sendmode — к передаче. Receive preference бесполезна для sendonly stream; sender declaration бесполезна для recvonly.

Если gateway копирует fmtp в обе стороны, строка теряет автора. Evidence должен хранить endpoint, direction, payload binding и SDP version. Значение без этих координат не говорит, кто предпочёл, кто объявил и кто исполнил.

Unknown parameter в offer следует игнорировать и не включать в answer. Echo неизвестного значения имитирует semantic agreement, которого нет.

Payload и clock не закрывают execution

audio/EVRCWB, EVRCWB0, EVRCWB1 выбирают interleaved/bundled, header-free и compact bundled packet formats. Это правило разбора bytes, не receipt режима каждого frame.

Modes 4 и 7 EVRC-WB interoperable с EVRC-B. Offerer должен также объявлять EVRC-B для legacy fallback. Выбранная codec family, receiver preference и sender mode остаются разными фактами.

RTP clock для EVRC-WB всегда 16 kHz, даже когда encoder input или decoder output работает на 8 kHz. /16000 доказывает шкалу timestamps, не acoustic bandwidth.

Legacy omission не равен отказу

RFC 5188 добавила recvmode и sendmode к EVRC-B из RFC 4788. Legacy implementation не отправляет их и игнорирует при получении, сохраняя interoperability.

Отсутствие может означать старый peer, optional omission, middlebox normalization или неполную capture. Нельзя автоматически подставлять mode 0 либо failure. Capability/version должна оставаться частью записи.

EVRCWB1 вводит другой предел

EVRCWB1 должен сохранять одну fixed rate и mode на протяжении session. Здесь transition под той же identity — отдельное событие, а не обычная свобода sender.

Новая валидная SDP недостаточна. Требуется доказать конец старого binding, начало новой session или payload и принадлежность каждого packet. Fixed invariant усиливает identity receipt, но не превращает preference в command.

Долговечный receipt

Он начинается с immutable session/change ID, ролей, direction, offer/answer versions, payloads, subtype, clock и raw rtpmap, fmtp, ptime, maxptime.

Затем фиксируются preference и owner, решение sender уважить или отклонить её, каждый sendmode и время, encoder transitions, sequence, timestamp, arrival и mode frames. Legacy capability, unknown-extension handling и EVRCWB1 boundary входят в ту же цепь.

Завершают decoder acceptance, output и application outcome. Decode не доказывает preference; preference не доказывает качество. Каждый слой свидетельствует только о своём состоянии.

Решение для руководства

Управлять нужно переходами, а не последним значением. Preference, policy, declaration и execution должны иметь отдельные версии и интервалы.

Тогда разрешённое изменение sender не превращается в ложное нарушение, а старое совпадение не маскирует новый режим. Если оставить только финальную SDP, организация знает последнюю фразу, но не историю media.

Источники

  1. RFC 5188 HTML
  2. RFC 5188 текст
  3. RFC 5188 информация
  4. Datatracker RFC 5188
  5. История RFC 5188
  6. Ссылки RFC 5188
  7. Errata RFC 5188
  8. RFC 4788
  9. RFC 4788 информация
  10. RFC 3558
  11. RFC 3558 информация
  12. RFC 3264 offer-answer
  13. RFC 3264 информация
  14. RFC 4566 SDP
  15. RFC 3550 RTP
  16. IANA audio/EVRCWB
  17. IANA RTP parameters
  18. Heng Lu — слои реальности
  19. Heng Lu — минимальная спецификация
  20. Heng Lu — приоритет работающего кода