Кратко

  • RFC 3087 разрешила SIP-клиенту или прокси выбирать особый Request-URI для приёма сообщения, нужного приветствия, выдачи записей или запроса PIN.
  • URI выбирал локально настроенное поведение. Он не доказывал личность звонящего, право на ящик, реальную причину переадресации, сохранение сообщения или его прослушивание.

Исходный адресат остался, текущая услуга сменилась

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

Путь SIP был подвижнее. Запрос мог пройти через несколько прокси и не раз поменять фактическую цель. Поле To при этом сохраняло имя первоначального логического адресата. RFC 3087 приводит короткий пример: A звонит B, B переводит все вызовы на C, а C — на собственную голосовую почту. Если приложение выберет ящик только по To: B, оно откроет не тот набор сообщений.

RFC 3087 была опубликована как Informational в апреле 2001 года и не добавляла новый метод или заголовок SIP. Она использовала уже заданное RFC 2543 различие: прокси мог переписывать Request-URI, в отличие от To. Текущей целью могла стать сервисная идентичность, которая одновременно выбирала начальное состояние приложения.

Главное изменение касалось ответственности. Конечному приложению больше не требовалось угадывать контекст по обломкам истории: выбор маршрута передавал его явно.

У одного сервиса появлялось несколько дверей

Документ описывает несколько SIP-идентичностей для одного абонента. Одна принимает запись с обычным приветствием, другая включает приветствие для занятой линии, третья — специальное. Для выдачи сообщений один вход может ожидать уже выполненную SIP-аутентификацию, другой сначала просит PIN голосом. Общие входы спрашивают, какой ящик нужен.

Прокси поиска абонента мог выбирать дверь. Если все контакты истекли без ответа, он направлял вызов на обычную запись. Если везде получено «занято», выбирал соответствующее приветствие. Режим «не беспокоить» мог вести к отдельной цели. Голосовая почта получала уже выбранный оперативный адрес и не восстанавливала решение по To, From и привычкам телефонной сети.

Однако читаемые слова в URI не были стандартизованными командами. RFC 3087 прямо предостерегала от обязательной семантики мнемонических строк. Оператор мог настроить deposit, номер, параметр или любой допустимый SIP URI. Словарь, связывающий идентичность с поведением, принадлежал локальной системе.

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

Правильная дверь ещё не была ключом

Сценарии получения сообщений отделяют выбор сервиса от допуска. Источник мог считаться доверенным благодаря защищённой связи и делегированной аутентификации. Успешная SIP-аутентификация могла открыть нужный сценарий. При её отсутствии или неудаче сервис либо защитный прокси перенаправлял запрос на URI с запросом PIN.

Таким образом, персональный URI для выдачи выбирал процесс, но не давал права чтения. Допуск определяли отношение доверия, SIP-реквизиты или PIN. Даже распознанный номер из PSTN был наблюдением, которому решил доверять оператор, а не криптографическим доказательством личности говорящего.

Все подробные схемы RFC предполагают защитный прокси и доверие между ним и голосовой почтой. Раздел безопасности не создаёт новой защиты и отсылает к механизмам SIP.

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

Локальная настройка ещё не была общим языком

RFC 3261 заменила раннюю спецификацию SIP, но сохранила механизм: Request-URI называет текущего пользователя или сервис, а прокси заменяет его при выборе цели. Поздние спецификации History-Info позволили переносить историю перенаправлений. Они объясняют слои, но не доказывают применение в конкретной системе RFC 3087.

В 2006 году RFC 4458 определила URI-параметры target и cause для голосовой почты и интерактивных голосовых приложений. Мотивировка показывает границу: каждый поставщик мог сделать локальные сопоставления настраиваемыми, но это не давало единого представления ящика и причины для систем управления вызовами, шлюзов и унифицированных сообщений разных производителей.

RFC 3087 показала URI как поверхность управления внутри архитектуры. RFC 4458 дала общие имена для обмена между реализациями. Появление второго документа не доказывает распространённость, коммерческий успех или неудачу первого.

Долговечный урок — в раздельном учёте свидетельств. Исходная цель, текущий Request-URI, причина переписывания, локальная карта, результат аутентификации, меню, медиасеанс и подтверждение хранения связаны, но не тождественны. Контекст в маршруте уменьшает догадки. Маршрут не становится личностью.

Источники

  1. https://www.rfc-editor.org/info/rfc3087
  2. https://www.rfc-editor.org/rfc/rfc3087.html
  3. https://www.rfc-editor.org/rfc/rfc3087.txt
  4. https://datatracker.ietf.org/doc/rfc3087/
  5. https://www.rfc-editor.org/errata/rfc3087
  6. https://www.rfc-editor.org/rfc/rfc2543.html
  7. https://www.rfc-editor.org/rfc/rfc3261.html
  8. https://www.rfc-editor.org/rfc/rfc4244.html
  9. https://www.rfc-editor.org/rfc/rfc4458.html
  10. https://www.rfc-editor.org/rfc/rfc3326.html
  11. https://www.rfc-editor.org/rfc/rfc5411.html
  12. https://www.rfc-editor.org/rfc/rfc7044.html