Кратко

  • RFC 5194 определяет real-time text как посимвольную разговорную среду. Итоговая стенограмма может сохранить слова, но скрыть задержку, потерю, исправление, границу шлюза и того, кому принадлежала реплика.
  • Для многостороннего разговора нужно связать участника и поток до смешивания, а затем отдельно хранить вход, передачу, восстановление, показ и архивную проекцию. Читаемость не создаёт отсутствующую provenance.

Когда порядок без автора недостаточен

Система могла доказать, что строка A появилась раньше строки B. Она не могла доказать, кто отвечал за A и кто исправил B. В обычной беседе это вызывает путаницу. В оперативном совещании или обращении за помощью меняется значение записи.

RFC 9071 развивает форматирование многостороннего real-time text и делает видимой проблему представления участников. Это более поздняя работа, но она подчёркивает границу, уже заложенную в модели RFC 5194: передать текст, представить разговор и сохранить его структуру — разные задачи.

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

Разговор начинается до готовой фразы

RFC 5194 говорит о передаче символов по мере ввода. Целые строки нельзя задерживать как обычную реализацию real-time text, потому что это нарушает требования к задержке символов.

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

Документ считает одну секунду хорошей end-to-end задержкой, отмечает ценность уменьшения до 300 мс и допускает приемлемость примерно двух секунд. Это не универсальный SLA. Это объяснение того, почему измерять следует путь отдельного символа от ввода до показа.

Одна сессия, несколько свидетельств

SIP устанавливает диалог. Offer/answer и SDP согласуют описание media. RTP переносит данные и даёт последовательность и время. Ни одна из этих поверхностей сама по себе не наблюдает экран пользователя.

Поэтому connected, text negotiated, RTP received, rendered и archived нельзя объединять в один первичный факт. Аудио и видео могут быть исправны при отсутствующем тексте. Пакеты могут приходить вовремя, пока renderer ждёт пунктуацию.

Полезная шкала хранит первое отправленное и принятое событие, непрерывность, потерю, восстановление, продвижение отображения и последнее наблюдение. Общий статус допустим только как ссылка на эту декомпозицию.

Redundancy восстанавливает, но не удостоверяет

RFC 4103 передаёт T.140 через RTP и может использовать redundant payload RFC 2198. Поздний пакет несёт недавние символы и способен закрыть предыдущую потерю.

Однако согласованный text/red — лишь возможность. Получатель должен знать, какой sequence gap возник, что восстановлено и что осталось неизвестным. RFC 5194 ожидает text-loss indication, если входящий текст всё-таки потерян.

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

Время теряется без потери символов

Строка может прийти целиком и слишком поздно. Сетевой transit будет отличным, если sender держал её восемь секунд и выпустил одним burst. Поэтому нужен путь input — transmit — arrival — decode — render.

Параметр cps RFC 4103 описывает rate capability или negotiation, но не подтверждает фактический ритм. Среднее по звонку также скрывает ранние символы, ожидавшие дольше остальных.

Для конференции важна ещё одна шкала: когда source identity была назначена, сохранена микшером и показана. Временная последовательность без этой связи не отвечает на вопрос, кто говорил.

Представление меняет запись

T.140 включает международные символы, новую строку, стирание и alerting. Архив, который возвращает удалённое при вводе слово, не описывает live presentation. Старый charset может повредить имя. Renderer может накопить своевременно принятые символы.

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

Gateway обозначает переход среды

RFC 5194 рассматривает interworking с PSTN text telephony, мобильными сервисами и instant messaging. Старая сторона может быть медленнее, half-duplex и иметь ограниченный charset. IM gateway может собирать символы до границы сообщения.

Такие преобразования бывают необходимы. Receipt gateway должен назвать вход и выход, buffer rule, rate, duplex change, character mapping, loss transformation и версию. Тогда можно честно сказать: этот участок был посимвольным, следующий — message-oriented.

Без границы локальная задержка приписывается сети, а итоговая читаемость — исходной среде. Interoperability означает контролируемый перевод, не отсутствие различий.

Emergency и relay

RFC 5194 требует возможности emergency call с real-time text и допускает relay service. Современные юридические требования различаются; статья не делает compliance-вывод.

Технически routing, готовность relay, media negotiation, первый двусторонний символ и последующая непрерывность — разные события. Ответ destination не доказывает, что человек уже мог объяснить ситуацию. Та же структура, что и в конференции: наличие текста не доказывает готовность и авторство.

Минимальная квитанция

Предлагаемый операционный receipt не является обязательным wire format RFC 5194. Он хранит session и media description, stream и participant, времена input/transmit/arrival/render, первичное и восстановленное получение, остаточную потерю и её показ, состояние каждой modality и преобразование gateway.

В терминах Heng Lu символ conversation complete должен оставаться ниже работающего кода, потока и экрана. Минимальная начальная спецификация сохраняет переносимые семантические границы, а локальные продукты свободны улучшать интерфейс. Свобода реализации не даёт transcript права изобретать timing или speaker identity.

Sources

  1. RFC 5194 HTML
  2. RFC 5194 текст
  3. Карточка RFC 5194
  4. Datatracker RFC 5194
  5. История RFC 5194
  6. Ссылки RFC 5194
  7. Errata RFC 5194
  8. RFC 4103
  9. Карточка RFC 4103
  10. RFC 9071
  11. Карточка RFC 9071
  12. RFC 4351
  13. RFC 3550
  14. RFC 2198
  15. RFC 3261
  16. RFC 3264
  17. RFC 8866
  18. Heng Lu — слои реальности
  19. Heng Lu — минимальная начальная спецификация
  20. Heng Lu — приоритет работающего кода