Кратко

  • RFC 3372 разделил сохранение и действие: сообщение ISUP помещалось в MIME-тело для способного его понять получателя, а выбранные параметры переводились в видимые поля SIP для работы прокси.
  • Целое тело не доказывало правильность маршрута или услуги; правильный маршрут не доказывал верность обратного преобразования, установление медиапотока или результат для абонента.

На границе телефонной и IP-сети сталкивались два способа описывать один вызов. SS7/ISUP содержал параметры традиционной телефонии. SIP-прокси принимал решение по URI и заголовкам. Он не должен был разбирать все разновидности ISUP, но выходному шлюзу мог понадобиться исходный материал, чтобы восстановить функцию на стороне PSTN.

RFC 3372 вышел в сентябре 2002 года как BCP 63. Авторы назвали набор механизмов SIP-T и подчеркнули, что это не новый протокол. Исторически важным стало признание: при переходе между архитектурами один вызов должен существовать в двух связанных представлениях.

Первое представление — инкапсулированное сообщение ISUP. Входной шлюз определял вариант ISUP и вкладывал его в тело SIP с MIME-типом из RFC 3204. Такой канал сохранял параметры, для которых у SIP не было прямого аналога. Выходной шлюз мог использовать тело как основу для сигнала, уходящего обратно в PSTN.

Второе представление — видимый запрос SIP. Шлюз переводил отдельные сведения, прежде всего вызываемый номер, в Request-URI и заголовки. Прокси получал поверхность, по которой можно выбрать направление. RFC 3372 называл первую задачу прозрачностью функций, вторую — маршрутизируемостью. Их нельзя было проверять одним индикатором.

Неизменённое ISUP-тело могло сопровождать ошибочно переведённый адрес и попасть не на тот выход. Запрос мог дойти до правильного шлюза, но потерять MIME-часть, получить повреждение или принести неподдерживаемый вариант ISUP. Сохранность контейнера и пригодность смысла оставались разными фактами.

Выходной шлюз не просто воспроизводил вложение. Он мог взять ISUP как шаблон, заменить значения, полученные из SIP-заголовков, и применить локальную политику. Если тела не было, использовался заранее настроенный канонический шаблон. Исходящий SS7-сигнал был результатом реконструкции, а не автоматической копией входа.

В начале не всегда было известно, чем закончится путь. Вызов из PSTN мог прийти на другой шлюз или на обычный SIP-телефон. Телефон обычно игнорировал ISUP, однако должен был корректно переносить multipart и неизвестные типы по правилам RFC 2046 и RFC 3261. SIP-телефон, начинающий вызов, не обязан создавать ISUP на случай ещё не выбранного PSTN-назначения.

Сигналы в середине разговора образовывали отдельную проблему. Некоторые сообщения ISUP не меняли состояние SIP-сеанса. RFC 3372 использовал для их передачи метод INFO из RFC 2976. Доставка INFO подтверждала передачу, но не понимание, исполнение функции или её видимость для человека.

TRIP в RFC 3219 и ENUM в RFC 2916 помогали находить телефонные направления и услуги, однако не заменяли сохранённый контекст ISUP. S/MIME по RFC 2633 мог подписать или зашифровать содержимое. Подпись не удостоверяла правильность перевода, полномочия локальной политики, открытие медиапути или корректный расчёт услуги.

RFC 3398 позднее подробно описал соответствия SIP и ISUP. RFC 3326 позволил переносить причину из конкретного протокольного пространства, но объяснение действия не становилось самим действием. RFC 3331 и RFC 3332 разместили разные функции адаптации SS7 поверх SCTP. Это соседняя история о расположении состояния; SIP-T — история о двух необходимых свидетельствах одного вызова.

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

Два текста Lu Heng помогают удержать границы. Минимальная начальная спецификация оставляет локальные решения видимыми. Разделение слоёв реальности требует отдельно фиксировать полученный SS7, вложенное тело, переведённый заголовок, маршрут прокси, реконструкцию на выходе, медиапуть и опыт пользователя. RFC 3372 сделал границу рабочей именно потому, что не объявил перенос смысла и действие над ним одним доказательством.

Источники