Кратко

  • RFC 3351 предлагал включить текст, голос, видео, службы ретрансляции и личные предпочтения в SIP-сеанс, который можно менять без повторного вызова.
  • Это информационный документ с требованиями, а не стандартизированное расширение SIP и не доказательство того, что устройства и провайдеры реализовали описанные сценарии.

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

Опубликованный в августе 2002 года документ перенёс вопрос доступности с категории устройства на устройство самого сеанса. Профиль пользователя в нём — это способности и предпочтения, которые SIP может передавать и которыми должна определяться обработка сеанса. Текст, звук и видео можно сочетать в одном или обоих направлениях. Поток может проходить через службу преобразования, а шлюз — соединять SIP-агент со старым текстовым телефоном. Местом встречи этих выборов становился сеанс.

Но статус документа нельзя отодвигать на второй план. RFC 3351 имеет категорию Informational и прямо говорит, что не устанавливает интернет-стандарт. Слова MUST и SHOULD выражают желаемые авторами требования, но не превращают документ в стандартизированное расширение SIP. Он не сертифицирует реализацию и не подсчитывает доступные услуги. Сценарии в документе — модели проектирования, а не обследование внедрений.

Профиль пользователя одновременно помогает и создаёт риск раскрытия. Он может направить вызов по подходящему пути, но также выдать сведения о человеке. Поэтому RFC 3351 предусматривает, что собеседнику не обязательно сообщать о глухоте звонящего только потому, что в разговоре участвует ретранслятор. От посредников требуется публиковать политику конфиденциальности; провайдерам предлагается дать возможность не раскрывать способности и предпочтения в каждой транзакции. Доступность — это не только доставка текста, но и то, что служба узнаёт, сохраняет и раскрывает.

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

Сценарии не сводятся к субтитрам. В одном из них голосовой разговор продолжается, пока ретранслятор превращает речь в текст, а набранный ответ — снова в речь. В конференции для участников с разными предпочтениями соединяются преобразования «речь—текст», «текст—жестовый язык» и «жестовый язык—текст». Голосовое телефонное меню также может получить текстовый путь через посредника. Эти проекты ставят выбор пользователя в центр, однако каждое преобразование добавляет поставщика, политику, возможную плату и новую границу, через которую проходят данные.

Последующие RFC показывают развитие спецификаций, но не всеобщий успех. RFC 4103 определил RTP-формат для T.140 — текста реального времени — и рекомендовал избыточную передачу для восстановления части утраченных символов. RFC 5194 позднее описал более подробную SIP/IP-структуру для текста, преобразования, представления и взаимодействия; он ссылается на RFC 3351 в контексте вызова ретрансляторов. RFC 4504 рекомендовал SIP-телефонам поддерживать требования доступности из RFC 3351.

Ещё позднее RFC 8865 описал передачу T.140 по надёжным упорядоченным каналам данных WebRTC, а RFC 9071 рассмотрел смешивание текста в многопользовательских RTP-сеансах и обновил RFC 4103. Каждый документ уточняет свою часть пути, но ни один не доказывает, что этот путь доступен на каждом устройстве, у каждого провайдера или в каждой службе экстренной помощи.

Исторический вклад RFC 3351 в том, что он включил эти решения в проектирование разговора: смена медиа не должна требовать нового вызова, а сам человек должен влиять на способ такой смены. Технически расширяемый сеанс всё ещё может быть недоступным, несовместимым, дорогим или отклонённым провайдером. Профиль, облегчающий выбор, может одновременно раскрыть чувствительные сведения. RFC 3351 поставил вопросы контроля, цены и конфиденциальности в центр обсуждения, но не утверждал, что реальный мир уже нашёл равновесие.

Источники: RFC 3351 · Запись RFC 3351 · RFC 3351 в Datatracker · RFC 2119 · RFC 8174 · SIP: протокол установления сеанса, RFC 3261 · Модель offer/answer для SDP, RFC 3264 · RTP-формат разговорного текста, RFC 4103 · Структура текста реального времени через SIP, RFC 5194 · Требования к SIP-телефонам, RFC 4504 · Текст T.140 через каналы данных WebRTC, RFC 8865 · RTP-микширование текста для нескольких участников, RFC 9071 · Минимальная начальная спецификация, локализованное решение в будущем и добровольное принятие · Приоритет работающего кода