О документе
Рабочая группа Network Working Group A. Vemuri
Запрос комментариев: 3372 Qwest Communications
BCP: 63 J. Peterson
Категория: Best Current Practice NeuStar
Сентябрь 2002
Session Initiation Protocol for Telephones (SIP-T):
Контекст и архитектуры
1. Введение
Session Initiation Protocol (SIP [1]) — это протокол управления
прикладного уровня, который может устанавливать, изменять и завершать
мультимедийные сеансы или вызовы. Эти мультимедийные сеансы включают
мультимедийные конференции, интернет-телефонию и сходные приложения. SIP
является одним из ключевых протоколов, используемых для реализации Voice
over IP (VoIP). Хотя выполнение сигнализации телефонных вызовов и передача
связанного звукового медиапотока по IP дают значительные преимущества по
сравнению с традиционной телефонией, сеть VoIP не может существовать
изолированно от традиционных телефонных сетей. Жизненно важно, чтобы
телефонная сеть SIP взаимодействовала с PSTN.
Популярность шлюзов, обеспечивающих взаимодействие между PSTN и сетями
SIP, побудила опубликовать набор общих практик, способных обеспечить
согласованное поведение во всех реализациях. Недостаток компетенций по SIP
за пределами IETF указывает на то, что IETF является наилучшим местом для
выполнения этой работы, особенно поскольку SIP находится в состоянии
относительных изменений по сравнению с базовыми протоколами PSTN. Более
того, рабочие группы IETF, сосредоточенные на SIP (SIP и SIPPING), находятся
в наилучшем положении, чтобы установить, обоснованы ли какие-либо новые
расширения SIP для взаимодействия с PSTN. Эта концептуальная основа
рассматривает общий контекст, в котором могут развёртываться шлюзы
взаимодействия PSTN-SIP, приводит сценарии использования и определяет
механизмы, необходимые для взаимодействия.
Важной характеристикой любой телефонной сети SIP является прозрачность
функций по отношению к PSTN. Традиционные телекоммуникационные услуги,
такие как ожидание вызова, номера freephone и т. д., реализованные в
протоколах PSTN, таких как Signaling System No. 7 (SS7 [6]), следует
предлагать сетью SIP таким образом, чтобы исключить любое существенное
различие в пользовательском опыте, не ограничивая при этом гибкость SIP.
С одной стороны, необходимо, чтобы SIP поддерживал примитивы для
предоставления таких услуг, когда конечной точкой является обычный телефон
SIP (см. определение в разделе 2 ниже), а не устройство, способное работать
с SS7. Однако также существенно, чтобы информация SS7 была доступна на
шлюзах — точках соединения SS7-SIP — для обеспечения прозрачности функций,
не поддерживаемых иным образом в SIP. Если возможно, информация SS7 должна
быть полностью и без каких-либо потерь доступна доверенным сторонам в сети
SIP через интерфейс PSTN-IP; одна из веских причин для этого также возникает
из того факта, что некоторые сети используют проприетарные параметры SS7
для передачи определённой информации через свои сети.
Другой важной характеристикой телефонной сети SIP является
маршрутизируемость запросов SIP: запрос SIP, устанавливающий телефонный
вызов, должен содержать в своих заголовках достаточно информации, чтобы
прокси-серверы в сети SIP могли надлежащим образом маршрутизировать его к
месту назначения. Чаще всего это означает, что параметры вызова, например
набранный номер, следует переносить из сигнализации SS7 в запросы SIP. На
маршрутизацию в сети SIP, в свою очередь, могут влиять такие механизмы, как
TRIP [8] или ENUM [7].
Инициатива SIP-T (SIP for Telephones) предоставляет основу для интеграции
устаревшей телефонной сигнализации в сообщения SIP. SIP-T обеспечивает две
указанные выше характеристики посредством методов, известных соответственно
как «инкапсуляция» и «трансляция». На шлюзе SIP-ISUP сообщения SS7 ISUP
инкапсулируются в SIP, чтобы информация, необходимая для услуг, не
отбрасывалась в запросе SIP. Однако от посредников, таких как прокси-серверы,
которые принимают решения о маршрутизации запросов SIP, нельзя ожидать
понимания ISUP, поэтому одновременно некоторая критически важная информация
транслируется из сообщения ISUP в соответствующие заголовки SIP, чтобы
определить, как будет маршрутизирован запрос SIP.
Хотя чистый SIP располагает всеми необходимыми средствами для установления
и завершения вызовов, он не имеет базового механизма для передачи по пути
сигнализации SIP в ходе сеанса какой-либо информации в ходе вызова (например,
запроса ISUP INF/INR). Эта информация в ходе вызова не приводит к каким-либо
изменениям состояния вызовов SIP или параметров сеансов, инициируемых SIP.
Также необходимо средство для передачи такой необязательной информации
прикладного уровня.
Определение проблемы: обеспечить прозрачность ISUP при взаимодействии
SS7-SIP
Требования к взаимодействию SS7-SIP Функции SIP-T
==================================================================
Прозрачность сигнализации ISUP Инкапсуляция ISUP в теле SIP
Маршрутизируемость сообщений SIP, Трансляция информации ISUP
зависящая от ISUP в заголовок SIP
Передача сообщений сигнализации ISUP Использование метода INFO для
в ходе вызова сигнализации в ходе вызова
Таблица 1: Функции SIP-T, удовлетворяющие требованиям к соединению
PSTN-IP
Хотя настоящий документ определяет приведённые выше требования, он
предоставляет механизмы для их удовлетворения — однако настоящий документ
действительно служит основой для документов, которые предоставляют эти
механизмы; все эти документы упомянуты в разделе 5.
Следует отметить, что в телефонии используются многие режимы сигнализации
(SS7 ISUP, BTNUP, Q.931, MF и т. д.). Этот документ сосредоточен на SS7 ISUP
и предназначен для определения поведения только на интерфейсах ISUP-SIP.
Со временем область инициативы SIP-T может также охватить другие системы
сигнализации.
2. SIP-T для соединений ISUP-SIP
SIP-T — это не новый протокол, а набор механизмов для сопряжения
традиционной телефонной сигнализации с SIP. Назначение SIP-T состоит в
предоставлении трансляции протоколов и прозрачности функций через точки
соединения PSTN-SIP. Он предназначен для использования там, где сеть VoIP
(сеть SIP для целей настоящего документа) взаимодействует с PSTN.
При использовании SIP-T существуют три базовые модели взаимодействия
вызовов со шлюзами. Вызовы, возникающие в PSTN, могут пройти через шлюз и
завершиться на конечной точке SIP, например IP-телефоне. И наоборот,
IP-телефон может совершить вызов, проходящий через шлюз и завершающийся в
PSTN. Наконец, сеть IP, использующая SIP, может служить транзитной сетью
между шлюзами: вызов может возникнуть и завершиться в PSTN, но где-то
посередине пройти через сеть на основе SIP.
Интерфейсы SS7 конкретного шлюза определяют варианты ISUP, которые этот
шлюз поддерживает. Поддерживает ли шлюз конкретную версию ISUP, определяет,
может ли он обеспечить прозрачность функций при завершении вызова.
Ниже перечислены основные агенты в сети с поддержкой SIP-T.
o PSTN (Public Switched Telephone Network): этим обозначается вся
взаимосвязанная совокупность местных, междугородных и международных
телефонных компаний. В приведённых ниже примерах термин Local Exchange
Carrier (LEC) используется для обозначения части (обычно регионального
подразделения) PSTN.
o Конечные точки IP: любой пользовательский агент SIP, который может
действовать как инициатор или получатель вызовов. Таким образом, следующие
устройства классифицируются как конечные точки IP:
* Шлюзы: телефонный шлюз предоставляет точку преобразования между
протоколами сигнализации (такими как ISUP и SIP), а также между
звуковыми медиапотоками с коммутацией каналов и с коммутацией пакетов.
Термин Media Gateway Controller (MGC) также используется в примерах и
диаграммах данного документа для обозначения крупномасштабных кластеров
декомпозированных шлюзов и управляющей логики, которые часто
развёртываются сегодня. Так, например, шлюз SIP-ISUP использует ISUP
для связи с PSTN и SIP для связи с Интернетом и отвечает за
преобразование между типами сигнализации, а также за обмен любыми
связанными звуковыми медиапотоками-носителями.
* Телефоны SIP: термин, используемый для обозначения всех устройств
конечных пользователей, которые инициируют или завершают вызовы
SIP VoIP.
* Точки интерфейса между сетями, в которых применяются административные
политики (потенциально middleboxes, прокси-серверы или шлюзы).
o Прокси-серверы: прокси-сервер — это посредник SIP, который
маршрутизирует запросы SIP к их местам назначения. Например, прокси-сервер
может направить запрос SIP другому прокси-серверу, шлюзу или телефону SIP.
********************
*** ***
* *
* ------- *
* |proxy| *
* ------- *
|----| |----|
/|MGC1| VoIP Network |MGC2|\
/ ---- ---- \
SS7 / * * \ SS7
/ * ------- * \
/ * |proxy| * \
-------- * ------- * ---------
| LEC1 | ** ** | LEC2 |
-------- ********************* ---------
Рисунок 1: Мотивация для SIP-T при взаимодействии ISUP-SIP
На рисунке 2 облако VoIP служит транзитной сетью для телефонных вызовов, исходящих из пары LEC, где SIP применяется в качестве протокола VoIP, используемого для установления и завершения этих вызовов VoIP. На границе изображённой сети MGC преобразует сигналы ISUP в запросы SIP и отправляет их прокси-серверу, который, в свою очередь, маршрутизирует вызовы к другим MGC. Хотя на этом рисунке изображены только два MGC, в развёртываниях VoIP обычно имеется много таких точек межсоединения с PSTN (обычно для диверсификации по тарифным центрам PSTN). Для вызова, исходящего из LEC1 и завершающегося в LEC2, инициатором в SIP-T является шлюз, который формирует запрос SIP для вызова VoIP, а терминатором является шлюз, который является получателем запроса SIP; следовательно, MGC1 будет инициатором, а MGC2 — терминатором. Обратите внимание, что для маршрутизации вызова от инициатора к терминатору могут использоваться один или несколько прокси-серверов.
В этом потоке для бесшовной интеграции IP-сети с PSTN важно сохранить полученную информацию SS7 в запросах SIP на исходящем шлюзе и повторно использовать эту информацию SS7 при сигнализации в PSTN на завершающем шлюзе. Инкапсулируя информацию ISUP в сигнализации SIP, сеть SIP может гарантировать, что при соединении SIP вызовов между двумя сегментами PSTN не будет потеряна никакая информация SS7, критически важная для реализации функций.
Тем не менее, если бы здесь был значим только обмен ISUP между шлюзами, для достижения этого можно было бы использовать любой протокол транспортировки сигнальной информации, устраняя необходимость в SIP и, следовательно, в SIP-T. SIP-T применяется, чтобы использовать неотъемлемые преимущества SIP: маршрутизацию запросов и управление вызовами с использованием прокси-серверов (включая использование ветвления),
простоту создания сервисов SIP, системы согласования возможностей SIP и так далее. Преобразование информации из параметров полученного сообщения ISUP в поля заголовка SIP позволяет промежуточным элементам SIP учитывать эту информацию при обработке запросов. Таким образом, SIP-T способствует установлению вызова и предоставлению новых телефонных сервисов через IP-сеть, одновременно обеспечивая способ многофункционального межсоединения с PSTN.
Наконец, сценарий на рисунке 2 является лишь одним из нескольких потоков, в которых может использоваться SIP-T: голосовые вызовы не всегда одновременно исходят из PSTN и завершаются в PSTN (через шлюзы); конечными точками сеанса SIP-T также могут быть телефоны SIP. В последующих разделах будут подробнее рассмотрены следующие возможные потоки:
1. Инициация в PSTN — завершение в PSTN: исходящий шлюз получает ISUP из PSTN и сохраняет эту информацию (посредством инкапсуляции и преобразования) в сообщениях SIP, которые он передаёт в направлении завершающего шлюза. Терминатор извлекает содержимое ISUP из полученного им сообщения SIP и повторно использует эту информацию в сигнализации, отправляемой в PSTN.
2. Инициация в PSTN — завершение в IP: исходящий шлюз получает ISUP из PSTN и сохраняет эту информацию ISUP в сообщениях SIP (посредством инкапсуляции и преобразования), которые он направляет завершающему пользовательскому агенту SIP. Терминатор не использует инкапсулированный ISUP и игнорирует его.
3. Инициация в IP — завершение в PSTN: телефон SIP инициирует вызов VoIP, который один или несколько прокси-серверов маршрутизируют к соответствующему завершающему шлюзу. Завершающий шлюз преобразует сигнализацию в ISUP и направляет вызов к соответствующему интерфейсу PSTN на основании информации, содержащейся в полученном заголовке SIP.
4. Инициация в IP — завершение в IP: это случай для чистого SIP. SIP-T (ни инкапсуляция, ни преобразование ISUP) не применяется, поскольку отсутствует взаимодействие с PSTN.
3. Потоки SIP-T
В следующих разделах подробно рассматриваются существенные потоки SIP-T. Обратите внимание, что, поскольку прокси-серверы обычно отвечают за маршрутизацию запросов SIP (на основании Request-URI), конечные точки, в которых в итоге завершится запрос SIP, обычно неизвестны инициатору. Поэтому инициатор не выбирает один из потоков,
описанных в этом разделе, ни в качестве статической конфигурации, ни для каждого отдельного вызова; вместо этого каждый вызов независимо маршрутизируется сетью SIP и может реализовать любой из приведённых ниже потоков, согласно логике маршрутизации сети.
3.1 Соединение SIP (PSTN - IP - PSTN)
********************
*** ***
* *
* ------- *
* |proxy| *
* ------- *
|---| |---|
/|MGC| VoIP Network |MGC|\
/ --- --- \
/ * * \
/ * ------- * \
/ * |proxy| * \
-------- * ------- * ---------
| PSTN | *** *** | PSTN |
-------- ********************* ---------
Рисунок 2: Инициация в PSTN — завершение в PSTN (соединение SIP)
Сценарий, в котором сеть SIP соединяет два сегмента PSTN, называется «соединением SIP». Когда вызов, предназначенный для сети SIP, исходит из PSTN, шлюз, являющийся точкой межсоединения с сетью PSTN, в конечном счёте получит сообщение SS7 ISUP. С точки зрения протокола SIP этот шлюз является клиентским пользовательским агентом для данного запроса на установление вызова. В IP-сети используется традиционная маршрутизация SIP, чтобы определить соответствующую точку завершения (в данном случае шлюз), установить диалог SIP и начать согласование медиасеанса между конечными точками инициации и завершения. Затем выходной (завершающий) шлюз передаёт сигнализацию ISUP в PSTN, надлежащим образом повторно используя любой инкапсулированный ISUP, присутствующий в полученном им запросе SIP.
Ниже показан очень простой поток вызова для соединения SIP.
PSTN MGC#1 Proxy MGC#2 PSTN
|-------IAM------>| | | |
| |-----INVITE---->| |
| | | |-----IAM----->|
| |<--100 TRYING---| |
| | | |<----ACM------|
| |<-----18x-------| |
|<------ACM-------| | | |
| | | |<----ANM------|
| |<----200 OK-----| |
|<------ANM-------| | | |
| |------ACK------>| |
|====================Conversation=================|
|-------REL------>| | | |
|<------RLC-------|------BYE------>| |
| | | |-----REL----->|
| |<----200 OK-----| |
| | | |<----RLC------|
| | | | |
3.2 Инициация в PSTN — завершение в IP
********************
*** ***
* *
* *
* *
* *
|----| |-----|
/|MGC | VoIP Network |proxy|\
/ ---- ----- \
/ * * \
/ * * \
/ * * \
-------- * * -------------
| PSTN | ** ** | SIP phone |
-------- ********************* -------------
Рисунок 3: Инициация в PSTN — завершение в IP
Вызов исходит из PSTN и завершается на телефоне SIP. Обратите внимание, что на рисунке 5 прокси-сервер выступает регистратором для рассматриваемого телефона SIP.
Ниже приведён простой поток вызова, изображающий сигнализацию ISUP и SIP для вызова, исходящего из PSTN и завершающегося на конечной точке SIP:
PSTN MGC Proxy SIP phone
|----IAM----->| | |
| |--------INVITE------>| |
| | |-------INVITE------->|
| |<------100 TRYING----| |
| | |<-------18x----------|
| |<---------18x--------| |
|<----ACM-----| | |
| | |<-------200 OK-------|
| |<-------200 OK-------| |
|<----ANM-----| | |
| |---------ACK-------->| |
| | |---------ACK-------->|
|=====================Conversation========================|
|-----REL---->| | |
| |----------BYE------->| |
|<----RLC-----| |---------BYE-------->|
| | |<-------200 OK-------|
| |<-------200 OK-------| |
| | | |
3.3 Инициация в IP — завершение в PSTN
********************
*** ***
* *
* *
* *
* *
|-----| |----|
/|proxy| VoIP Network |MGC |\
/ ----- ---- \
/ * * \
/ * * \
/ * * \
------------ * * ---------
|SIP phone | ** ** | PSTN |
------------ ********************* ---------
Рисунок 4: Инициация в IP — завершение в PSTN
Вызов исходит от телефона SIP и завершается в PSTN. В отличие от двух предыдущих потоков, поэтому в запросе отсутствует инкапсуляция ISUP; следовательно, завершающий шлюз выполняет только преобразование заголовков SIP для получения значений параметров ISUP.
Простой поток вызова, иллюстрирующий различные участки вызова, показан ниже.
SIP phone Proxy MGC PSTN
|-----INVITE----->| | |
| |--------INVITE-------->| |
|<---100 TRYING---| |-----IAM---->|
| |<------100 TRYING------| |
| | |<----ACM-----|
| |<---------18x----------| |
|<------18x-------| | |
| | |<----ANM-----|
| |<--------200 OK--------| |
|<-----200 OK-----| | |
|-------ACK------>| | |
| |----------ACK--------->| |
|========================Conversation===================|
|-------BYE------>| | |
| |----------BYE--------->| |
| | |-----REL---->|
| |<--------200 OK--------| |
|<-----200 OK-----| |<----RLC-----|
4. Роли и поведение SIP-T
В сети SIP VoIP, взаимодействующей с PSTN, имеются три различных типа элементов (с функциональной точки зрения):
1. Инициаторы сигнализации SIP
2. Терминаторы сигнализации SIP
3. Промежуточные элементы, которые маршрутизируют запросы SIP от инициатора к терминатору
Поведение промежуточных ролей, описанных в разделах 4.1, 4.2 и 4.3, в вызове SIP-T рассматривается в следующих разделах.
4.1 Инициатор
Функция клиентского пользовательского агента-инициатора заключается в формировании запросов SIP на установление вызова (то есть INVITE). Когда вызов исходит из PSTN, UAC является шлюзом; в противном случае UAC является некоторой нативной конечной точкой SIP. В любом случае следует отметить, что инициатор, как правило, не может предвидеть, сущностью какого типа будет терминатор, то есть находится ли конечный пункт назначения запроса в сети SIP или в PSTN.
В случае вызовов, исходящих из PSTN (см. Figure 3 и Figure 5), шлюз-инициатор предпринимает необходимые шаги для сохранения информации ISUP, инкапсулируя её в создаваемый им запрос SIP. На шлюз-инициатор возлагается ответственность за определение версии ISUP (ETSI, ANSI и т. д.), которую он получил, и предоставление этой информации в инкапсулированном ISUP (обычно путём добавления составного MIME-тела с соответствующими MIME-заголовками). Затем он соответствующим образом формирует заголовки запроса SIP INVITE из параметров ISUP, полученных им от PSTN (см. Section 5). Например, это может повлечь установку поля заголовка 'To:' в INVITE таким образом, чтобы оно отражало набранный номер (Called Party Number) полученного ISUP IAM.
В других случаях (таких как Figure 7) инициатором VoIP-вызова является SIP-телефон. Обычно SIP-телефон направляет запросы прокси-серверу SIP, отвечающему за маршрутизацию запроса к подходящему пункту назначения. На стороне клиентского пользовательского агента нет ISUP для инкапсуляции, поскольку отсутствует интерфейс PSTN. Хотя вызов может завершаться в телефонной сети и для этого может требоваться сигнализация ISUP, инициатор не может этого предвидеть, и было бы неразумно требовать, чтобы все пользовательские агенты SIP VoIP имели возможность формировать ISUP. Следовательно, формирование инкапсулированного ISUP не является обязанностью конечных точек IP, таких как SIP-телефон. Таким образом, инициатор должен формировать сигнализацию SIP, выполняя инкапсуляцию и трансляцию ISUP, когда это возможно (то есть когда вызов исходил из PSTN).
Требования к инициатору: инкапсуляция ISUP, трансляция информации из ISUP в SIP, поддержка составного MIME (только для шлюзов)
4.2 Терминатор
Терминатор SIP-T является получателем вызовов SIP. Терминатор — это стандартный SIP UA, которым может быть либо шлюз, взаимодействующий с PSTN, либо SIP-телефон.
В случае завершения в PSTN (см. Figure 3 и Figure 7) выходной шлюз завершает вызов на своём интерфейсе PSTN. Терминатор формирует из входящего сообщения SIP ISUP, подходящий для сигнализации в PSTN. Значения некоторых параметров ISUP могут быть получены из заголовков SIP или извлечены непосредственно из инкапсулированного тела ISUP. В общем случае шлюз использует любой инкапсулированный ISUP как шаблон для сообщения, которое он отправит, однако он перезаписывает значения параметров в шаблоне при трансляции заголовков SIP или добавляет значения параметров, отражающие его локальные политики (см. Appendix A item 1).
В случае завершения на IP (Figure 5) SIP UAS, получающий сообщения SIP с инкапсулированным ISUP, обычно игнорирует сообщение ISUP. Однако это вводит общее требование, согласно которому устройства, такие как SIP-телефоны, должны корректно обрабатывать составные MIME-сообщения и неизвестные MIME-типы (это базовое требование SIP, но также область, где, как известно, поставщики допускали упрощения).
Требования к терминатору: стандартная обработка SIP, интерпретация инкапсулированного ISUP (только для шлюзов), поддержка составного MIME, корректная обработка неизвестного MIME-содержимого (только для нешлюзов)
4.3 Посредник
На посредников, таких как прокси-серверы, возлагается задача маршрутизации сообщений к другим посредникам, а также к шлюзам и SIP-телефонам. Каждый прокси-сервер принимает решение о пересылке запроса SIP на основе значений различных заголовков или «маршрутизируемых элементов» (включая Request-URI, заголовки маршрута и, возможно, многие другие элементы запроса SIP).
SIP-T действительно вводит некоторые дополнительные соображения для пересылки запроса, которые могут привести к новым возможностям и требованиям к посредникам. Прозрачность возможностей ISUP имеет центральное значение для концепции SIP-T. Совместимость между вариантами ISUP исходного и конечного интерфейсов PSTN автоматически приводит к прозрачности возможностей. Поэтому прокси-серверы могут учитывать варианты ISUP, инкапсулированные в запросах: сам вариант может стать маршрутизируемым элементом. Завершение вызова в точке, обеспечивающей большую близость к конечному пункту назначения (соображения тарифа), также является важным соображением. Предпочтение одного перед другим приводит к компромиссу между простотой эксплуатации и стоимостью. Требование обеспечить приемлемый тариф может диктовать, что вызов SIP-T проходит через неоднородные интерфейсы PSTN (соединение SIP через различные шлюзы, не поддерживающие ни одного общего варианта ISUP). Для оптимизации одновременно максимальной прозрачности возможностей и тарифа некоторые операторы посредников могут захотеть рассмотреть практики следующего характера:
a) Необходимость прозрачности возможностей ISUP может потребовать трансляции (преобразования) варианта ISUP, то есть преобразования одного варианта ISUP в другой, чтобы обеспечить завершение такого вызова через интерфейс шлюза, не поддерживающий вариант ISUP исходного интерфейса PSTN. (См. Appendix A item 2.) Хотя теоретически преобразование может выполняться в любой точке пути запроса, оптимально выполнять его в точке, наиболее близкой к завершающему шлюзу. Это может быть достигнуто доставкой вызова приложению, которое может выполнять преобразование между вариантами. Прозрачность возможностей в таком случае зависит от доступности ресурсов для преобразования ISUP и приводит к увеличению времени установления вызова.
b) Альтернативой было бы пожертвовать прозрачностью ISUP, передав вызов шлюзу, который не поддерживает версию исходного ISUP. Тогда завершающий MGC просто проигнорировал бы инкапсулированный ISUP и использовал бы информацию в заголовке SIP для завершения вызова.
Таким образом, может быть желательно, чтобы прокси-серверы обладали интеллектуальными средствами для принятия разумного решения с учётом доступных им вариантов.
Требования к прокси: возможность маршрутизировать на основе выбора маршрутизируемых элементов
4.4 Сводка требований к поведению
Если инициатор SIP-T является шлюзом, получившим запрос ISUP, он должен всегда выполнять как инкапсуляцию, так и трансляцию ISUP, независимо от того, где, по предположению инициатора, завершится запрос.
Если терминатор не понимает ISUP, он игнорирует его, выполняя стандартную обработку SIP. Если терминатор понимает ISUP и ему необходимо передавать сигнализацию в PSTN, ему следует повторно использовать инкапсулированный ISUP, если он понимает данный вариант. Терминатору следует выполнить следующие действия:
o Извлечь ISUP из тела сообщения и использовать этот ISUP в качестве шаблона сообщения. Следует отметить, что если в сообщении нет инкапсулированного ISUP, шлюзу следует вместо этого использовать канонический шаблон для рассматриваемого типа сообщения (предварительно заполненное сообщение ISUP, настроенное в шлюзе).
o Транслировать заголовки запроса SIP в параметры ISUP, перезаписывая любые значения в шаблоне сообщения.
o Применить любые локальные политики при заполнении параметров.
Посредник должен иметь возможность маршрутизировать вызов на основе выбора маршрутизируемых элементов в заголовках SIP.
5. Компоненты протокола SIP-T
Механизмы, описанные в следующих разделах, являются компонентами SIP-T, предоставляющими функции протокола, необходимые согласно требованиям.
5.1 Базовый SIP
SIP-T использует методы и процедуры SIP, определённые RFC 3261.
5.2 Инкапсуляция
Инкапсуляция сигнализации PSTN является одним из основных требований SIP-T. SIP-T использует составные MIME-тела, чтобы сообщения SIP могли содержать несколько полезных нагрузок (Session Description Protocol или SDP [5], ISUP и т. д.). Сегодня существует множество вариантов ISUP; MIME-тип ISUP позволяет получателям распознавать тип ISUP (и, следовательно, определять, поддерживают ли они данный вариант) наиболее быстрым из возможных способов. Одна схема выполнения инкапсуляции ISUP с использованием составного MIME описана в [2].
5.3 Трансляция
Трансляция охватывает все аспекты преобразования протокола сигнализации между SIP и ISUP. По существу, проблема трансляции включает два компонента:
1. Сопоставление сообщений ISUP—SIP: оно описывает сопоставление между ISUP и SIP на уровне сообщений. В развёртываниях SIP-T на шлюзы возлагается задача формирования определённого сообщения ISUP для каждого полученного сообщения SIP и наоборот. Необходимо определить правила, управляющие сопоставлением сообщений ISUP и SIP (то есть какое сообщение ISUP отправляется при получении конкретного сообщения SIP: при получении INVITE должен быть отправлен IAM, для BYE — REL и так далее). Возможное сопоставление сообщений ISUP и SIP описано в [10].
2. Сопоставление параметров ISUP—заголовков SIP: запрос SIP, используемый для установления телефонного вызова, должен содержать информацию, которая позволяет прокси-серверам в сети SIP надлежащим образом маршрутизировать его к пункту назначения, — например, телефонный номер, набранный исходным пользователем. Важно стандартизировать набор практик, определяющий процедуру трансляции информации из ISUP в SIP (например, Called Party Number в ISUP IAM должен быть сопоставлен с полем заголовка SIP 'To' и Request-URI и т. д.). Этот вопрос становится по своей природе более сложным вследствие того, что заголовки запроса SIP (особенно INVITE) могут преобразовываться посредниками и что, следовательно, заголовки SIP и инкапсулированные тела ISUP начинают выражать конфликтующие значения: фактически часть инкапсулированного ISUP может стать несущественной и устаревшей.
5.4 Поддержка сигнализации в ходе вызова
Чистый SIP не предусматривает переноса какой-либо управляющей информации в ходе вызова, которая генерируется во время сеанса. Для этой цели следует использовать метод INFO [3]. Однако следует отметить, что INFO не подходит для управления перекрывающимся набором номера (один из способов реализации перекрывающегося набора номера см. в [11]). Также следует отметить, что использование INFO для сигнализации DTMF-сигналов в ходе вызова не рекомендуется (рекомендуемый механизм см. в RFC2833 [9]).
6. Согласование содержимого SIP
Инициатор запроса SIP-T может упаковать как элементы SDP, так и ISUP в одно и то же сообщение SIP, используя формат составного MIME. Традиционно в SIP, если завершающее устройство не поддерживает составную полезную нагрузку (multipart/mixed) и/или MIME-тип ISUP, оно отклоняет запрос SIP ответом 415 Unsupported Media Type с указанием поддерживаемых им типов носителя (по умолчанию — 'application/SDP'). Впоследствии инициатору пришлось бы повторно отправить запрос SIP после удаления полезной нагрузки ISUP (то есть только с полезной нагрузкой SDP), и такой запрос был бы принят.
Это довольно громоздкая последовательность, поэтому крайне желательно иметь механизм, посредством которого инициатор мог бы указать, какие тела являются обязательными, а какие — необязательными, чтобы терминатор мог молча отбросить необязательные тела, которые он не понимает (позволяя SIP-телефону игнорировать полезную нагрузку ISUP, когда обработка ISUP не критична). Это зависит от того, поддерживает ли терминатор Content-type multipart/mixed и имеет ли доступ к заголовку Content-Disposition для выражения критичности.
1. Поддержка ISUP необязательна. Поэтому UA2 принимает INVITE независимо от того, может ли он обработать ISUP.
UA1 UA2
INVITE-->
(Content-type:multipart/mixed;
Content-type: application/sdp;
Content-disposition: session; handling=required;
Content-type: application/isup;
Content-disposition: signal; handling=optional;)
<--18x
2. Поддержка ISUP предпочтительна. UA2 не поддерживает ISUP и отклоняет INVITE ответом 415 Unsupported Media Type. UA1 удаляет ISUP и повторно отправляет INVITE только с SDP, и этот запрос принимается.
UA1 UA2
INVITE--> (Content-type:multipart/mixed;
Content-type: application/sdp;
Content-disposition: session; handling=required;
Content-type: application/isup;
Content-disposition: signal; handling=required;)
<--415
(Accept: application/sdp)
ACK-->
INVITE-->
(Content-type: application/sdp)
<--18x
3. Поддержка ISUP обязательна для установления вызова. UA2 не
поддерживает ISUP и отклоняет INVITE ответом 415 Unsupported Media
type. Затем UA1 направляет свой запрос UA3.
UA1 UA2
INVITE--> (Content-type:multipart/mixed;
Content-type: application/sdp;
Content-disposition: session; handling=required;
Content-type: application/isup;
Content-disposition: signal; handling=required;)
<--415
(Accept: application/sdp)
ACK-->
UA1 UA3
INVITE--> (Content-type:multipart/mixed;
Content-type: application/sdp;
Content-disposition: session; handling=required;
Content-type: application/isup;
Content-disposition: signal; handling=required;)
Обратите внимание, что приведённый выше обмен сообщениями показан не
полностью; показаны только сообщения, относящиеся к этому обсуждению.
Подробные сведения о MIME-типе ISUP можно получить из [2]. Параметры
'version' и 'base' здесь не показаны, но ДОЛЖНЫ (MUST) использоваться в
соответствии с правилами [2].
7. Соображения безопасности
SIP-T может использоваться как механизм междоменной сигнализации, к
которому могут применяться уже существующие отношения доверия между
административными доменами. Во многих правовых системах распространение
ISUP ограничено лицензированными операторами связи; SIP-T создаёт некоторые
трудности, поскольку он соединяет сигнализацию операторов связи с
сигнализацией конечных пользователей. Любому административному домену,
реализующему SIP-T, следует иметь надлежащую инфраструктуру безопасности
(включая элементы, управляющие соответствующими политиками противодействия
мошенничеству и учёта расчётов в междоменной среде), чтобы обеспечить, что
передача информации ISUP не приведёт к каким-либо нарушениям безопасности.
Передача ISUP в телах SIP может создавать возможности для злоупотреблений,
мошенничества и возникновения проблем конфиденциальности, особенно когда
запросы SIP-T могут генерироваться, инспектироваться или изменяться
произвольными конечными точками SIP. Тела MIME ISUP следует защищать
(предпочтительно с помощью S/MIME [4]) для смягчения этой проблемы, как
описано в разделе Security Considerations базовой спецификации SIP [1].
Свойства аутентификации, предоставляемые S/MIME, позволили бы получателю
сообщения SIP-T удостовериться, что тело MIME ISUP было сформировано
авторизованной сущностью.
Шифрование обеспечило бы, что только операторы связи, обладающие
конкретным ключом расшифрования, способны инспектировать инкапсулированные
тела MIME ISUP в запросе SIP.
Конечные точки SIP-T ДОЛЖНЫ (MUST) поддерживать подписи S/MIME (CMS
SignedData) и СЛЕДУЕТ (SHOULD) поддерживать шифрование (CMS EnvelopedData).
8. Соображения IANA
Этот документ не вводит новых соображений для IANA.
Приложение A. Примечания
1. Некоторые завершающие MGC могут изменять инкапсулированный ISUP,
чтобы удалить любые условия, специфичные для исходного канала; например,
флаги проверки непрерывности в индикаторах характера соединения и т. п.
2. Тем не менее, релевантность информации, специфичной для ANSI, в сети
ETSI (или наоборот) вызывает сомнения. Очевидно, преимущество SIP-T
проявляется, когда инкапсулированный ISUP предполагает использование
проприетарных параметров.
Приложение B. Благодарности
Мы благодарим Andrew Dugan, Rob Maidhof, Dave Martin, Adam Roach, Jonathan
Rosenberg, Dean Willis, Robert F. Penfield, Steve Donovan, Allison Mankin,
Scott Bradner и Steve Bellovin за их ценные замечания.
Исходное предложение «SIP+» по взаимному соединению частей PSTN с помощью
мостового взаимодействия SIP было разработано Eric Zimmerer.