3. Посредники, которые маршрутизируют запросы SIP от инициатора к терминатору.
SIP-T не является новым протоколом, а представляет собой набор механизмов для согласования традиционной телефонной сигнализации с SIP. Целью SIP-T является предоставление трансляции протокола и прозрачность свойств через точки взаимосвязи ТфОП-SIP. Он предназначен для использования там, где сеть VoIP (сеть SIP в данном документе) имеет интерфейс с ТфОП.
При использовании SIP-T имеются три базовых модели взаимодействия вызова со шлюзом. Вызов, возникающий в ТфОП, может проходить через шлюз для достижения оконечной точки SIP, например, IP-телефона. Наоборот, IP-телефон может осуществлять вызов, проходящий через шлюз для достижения ТфОП. Наконец, IP-сеть, использующая SIP, может служить транзитной сетью между шлюзами — вызов может исходить и заканчиваться в ТфОП, но проходить через сеть SIP.
Интерфейсы ОКС №7 на соответствующем шлюзе определяют версии реализации протокола ISUP, поддерживаемые шлюзом. Поддержка шлюзом той или иной версии ISUP определяется тем, может ли шлюз предоставить прозрачность свойств при обслуживании вызова.
Ниже перечислены основные агенты сети, использующей SIP-T.
ТфОП (PSTN — Public Switched Telephone Network) — представляет собой совокупность полностью связанных между собой компаний местной, междугородной и международной телефонной связи. В примерах, приведенных ниже, термин Local Exchange Carrier (LEC) используется для обозначения части (чаше всего регионального подразделения) ТфОП.
Оконечные точки IP — любой агент пользователя SIP, который может действовать как инициатор или терминатор вызовов. Таким образом, следующие устройства классифицируются как оконечные точки IP:
1. Шлюзы. Телефонный шлюз предоставляет точку конвертирования протоколов сигнализации (ISUP и SIP), а также аудио информации сети с коммутацией каналов и сети с коммутацией пакетов. Термин Контроллер транспортного шлюза (Media Gateway Controller — MGC) также используется в этом документе в приведенных примерах и диаграммах для обозначения крупномасштабных кластеров декомпозированных шлюзов и управляющей логики, как часто делается на сегодняшний момент. Например, шлюз SIP-ISUP «общается» с ТфОП посредством ISUP, а с сетью Интернет — посредством SIP, и отвечает за конвертирование из одного типа сигнализации в другой, а также за обмен ассоциированной аудио информацией.
2. SIP-телефоны. Термин используется для обозначения всех оконечных устройств, которые могут создавать или принимать вызовы SIP VoIP.
3. Интерфейсные точки между сетями, где осуществляется административная политика (middleboxes, proxy-серверы или шлюзы).
Proxy-серверы. Proxy-сервер является посредником SIP, который направляет запросы SIP по месту их назначения. Например, proxy-сервер может направить запрос SIP на другой proxy-сервер, шлюз или S IP-телефон.
На рис. 25 облако VoIP выступает в роли транзитной сети для телефонных вызовов, исходящих из какой-либо из двух LEC, a SIP применен как протокол VoIP, используемый для установления и разрушения
этих VoIP-вызовов. На границе изображенной сети MGC преобразует сообщения ISUP в запросы SIP и посылает их на proxy-сервер, который направляет вызовы на другие MGC. Хотя на рисунке изображено только два MGC, сеть VoIP обычно имеет много таких точек связи с ТфОП (обычно для диверсифицикации среди тарифных центров ТфОП). Для вызовов, исходящих от LEC1 и оканчивающихся в LEC2, исходным в SIP-T является шлюз, генерирующий запрос SIP для вызова в сети VoIP, а терминальным является шлюз — получатель запроса SIP. Таким образом, MGC1 является инициатором, a MGC2 — терминатором. Следует отметить, что один или несколько proxy-серверов могут использоваться для маршрутизации вызова от инициатора к терминатору.
При инкапсуляции информации ISUP в сигнализацию SIP, сеть SIP может гарантировать, что никакая информация, критичная для реализации свойств, не будет потеряна при осуществлении транзита вызовов между двумя сегментами ТфОП.
Важно отметить, что определяющим в данной ситуации является обмен информацией ISUP между двумя шлюзами, для транспортировки сигнальной информации может быть использован любой протокол, избегая необходимости использования SIP и, соответственно, SIP-T. SIP-T применяется с целью усиления выгоды от использования SIP и его положительных качеств: маршрутизация запросов и управление вызовом улучшается, благодаря использованию proxy-серверов, легкое создание услуг SIP, систем согласования возможностей SIP, и т.д. Трансляция информации из параметров передаваемого сообщения ISUP в поля заголовка SIP позволяет посредникам SIP использовать эту информацию при обслуживании вызова. SIP-T, таким образом, облегчает установление вызова и использование новых телефонных услуг на сети IP, одновременно предоставляя метод высокофункционального (feature-rich) соединения с ТфОП.
Сценарий на рис. 25 представляет собой один из нескольких потоков, в которых может быть использован SIP-T — голосовые вызовы не всегда возникают и заканчиваются в ТфОП (через шлюзы); SIP-теле-фоны также могут быть оконечными точками в SIP-T-сеансе. В следующих разделах нами будут детализованы следующие возможные потоки:
ТфОП исходящая — ТфОП входящая. Исходный шлюз получает сообщения ISUP из ТфОП и сохраняет эту информацию (с помощью инкапсуляции и трансляции) в сообщениях SIP, которые он пересылает по направлению к терминальному шлюзу. Термин&чьный шлюз извлекает содержимое сообщения ISUP из полученного сообщения SIP и использует эту информацию для сигнализации, передаваемой в ТфОП.
ТфОП исходящая — IP входящая. Исходный шлюз получает сообщения ISUP из ТфОП и сохраняет эту информацию (с помощью инкапсуляции и трансляции) в сообщениях SIP, которые он пересылает по направлению к терминальному агенту пользователя SIP. Терминальный агент пользователя SIP не нуждается в инкапсулированной информации ISUP и игнорирует ее.
IP исходящая — ТфОП входящая. SIP-телефон инициирует VoIP-вызов, который маршрутизируется одним или несколькими proxy-серверами к соответствующему терминальному шлюзу. Терминальный шлюз конвертирует поступившую информацию в сигнализацию ISUP и направляет вызов на соответствующий интерфейс ТфОП, базируясь на информации, содержащейся в принятом заголовке SIP.
IP исходящая — IP входящая. Это случай «чистого» SIP. SIP-T (инкапсуляция и трансляция информации ISUP) не используется, т.к. нет взаимодействия с ТфОП.
2.3.2. Сценарии SIP-T
Данный раздел рассматривает наиболее существенные потоки SIP-T. Необходимо отметить, что так как за маршрутизацию запросов SIP (основанных на Request-URI) обычно отвечают прокси-серверы, возможные оконечные точки, на которых будет завершаться запрос SIP, как правило, не известны инициатору. Таким образом, инициатор не выбирает из сценариев, описанных в этом разделе (как в случае статичной конфигурации, так и в случае повызывной конфигурации), напротив, каждый запрос маршрутизируется сетью SIP независимо, и это может проиллюстрировать любой из сценариев, рассмотренных далее, как это диктует логика маршрутизации сети.
2.3.2.1. Мост SIP (ТфОП - IP - ТфОП)
Сценарий, в котором сеть SIP соединяет два сегмента ТфОП, называется мостом SIP (SIP bridging). Когда вызов, инициированный в ТфОП, предназначен сети SIP, сообщение ISUP OKC №7, в конечном счете, будет получено шлюзом, который является точкой взаимодействия с сетью ТфОП. Этот шлюз, с точки зрения протокола SIP, является клиентом агента пользователя (user agent client) для этого запроса установления соединения.
Традиционная маршрутизация SIP используется в сети IP для определения соответствующей точки назначения (в данном случае —
шлюза), для установления диалога SIP и для начала медиа-сеанса между инициатором и терминатором.
Шлюз терминатора тогда передает сообщения сигнализации ISUP в ТфОП, повторно используя инкапсулированные сообщения сигнализации ISUP, представленные в запросе, который он получает. Пример потока сообщений для моста S1P показан ниже.
Пакетная сеть связи общего пользования - cтраница №17
Пример потока сообщений иллюстрирующий сигнализацию ISUP и SIP для вызова, инициированного в ТфОП и завершающегося в оконечной точке SIP.
2.3.2.3. Инициирование в IP — завершение в ТфОП
Вызов инициируется с телефона SIP и завершается в ТфОП. В отличие от предыдущих двух потоков здесь отсутствует инкапсуляция сообщений ISUP в запросе — поэтому шлюз терминатора лишь осуществляет трансляцию заголовков SIP, чтобы извлечь значения параметров ISUP.
Рис. 30. ИнициированиевIP—завершениевТфОП
Пример потока сообщений, иллюстрирующий различные участки маршрута вызова, показан ниже.
Рис. 31. ПотоксообщенийSIP - ISUP
2.4. Роли и поведение SIP-T
В сети SIP VoIP, взаимодействующей с ТфОП, с функциональной точки зрения существует три отдельных класса элементов:
1. Инициаторы сигнализации SIP.
2. Терминаторы сигнализации SIP.
3. Посредники, которые маршрутизируют запросы SIP от инициатора к терминатору.
2.4.1. Инициатор
Функцией инициирующего клиента агента пользователя является генерация запросов установления вызова SIP (т.е. INVITE). Когда вызов инициируется в ТфОП, шлюз является клиентом агента пользователя; другими словами, клиентом агента пользователя является оконечная точка SIP. Необходимо отметить, что в любом случае, инициатор вообще не может предсказать, какой тип объекта будет терминатором, т.е. будет ли точка назначения запроса в сети SIP или в ТфОП.
В случае вызовов, инициируемых в ТфОП (см. рис. 26 и рис. 28), инициирующий шлюз предпринимает необходимые шаги для сохранения информации ISUP путем инкапсуляции ее в запрос SIP, который он создает.
Инициирующий шлюз отвечает за идентификацию версии ISUP (ETSI, ANSI, ISUP-R, и т.д.), которую он получил, и обеспечивает присутствие этой информации в инкапсулированном сообщении ISUP (обычно путем добавления многосоставного тела MIME с соответствующими заголовками MIME). Далее он создает заголовки запроса INVITE SIP из параметров сообщения ISUP, которое он получил из ТфОП. Это может, например, повлечь за собой отображение в поле заголовка То: в INVITE номера вызываемой стороны (Called Party Number) из полученного IAM ISUP.
В других случаях (как на рис. 30), телефон SIP является инициатором вызова VoIP. Обычно телефон SIP посылает запросы к про-кси-SIP, который отвечает за маршрутизацию запроса к соответствующей точке назначения.
В этом случае сообщения ISUP отсутствуют и их инкапсуляция в клиенте агента пользователя не производится, так как нет интерфейса с ТфОП. Хотя вызов и может завершаться в телефонной сети и
для этого требуется передать сообщения ISUP, инициатор не может предвидеть этого и нельзя требовать, чтобы все клиенты агента пользователя SIP VoIP имели бы возможность генерировать сообщения ISLP. Поэтому оконечные точки IP, подобно телефону SIP, не обязаны генерировать инкапсулированные сообщения ISUP.
Таким образом, инициатор должен генерировать сообщения сигнализации SIP при выполнении инкапсуляции ISUP и, когда это возможно, трансляцию (имеется в виду случай, когда вызов был инициирован в ТфОП).Требования к инициатору: инкапсуляция сообщений ISUP, трансляция информации от ISUP к SIP, поддержка многосоставного MIME (только для шлюзов).
2.4.2. Терминатор
Терминатор SIP-T является получателем вызовов SIP. Терминатор является стандартным агентом пользователя (UA) SIP, который может быть либо шлюзом, который взаимодействует с ТфОП, либо телефоном SIP.
В случае направления вызова в ТфОП (см. рис. 30 и рис. 31), выходной шлюз является оконечной точкой для сети SIP. Терминатор генерирует сообщение ISUP, соответствующее сигнализации ТфОП из входящего сообщения SIP. Значения для конкретных параметров ISUP могут быть взяты из заголовков SIP или извлечены непосредственно из тела инкапсулированного ISUP. Проще говоря, шлюз использует любые инкапсулированные сообщения ISUP как шаблон для сообщения, которое будет отправлено, но он переопределяет значения параметров в шаблоне в соответствии с транслированным заголовком SIP или добавляет некоторые значения параметра, которые отражают его локальную политику. Некоторые конечные MGC могут изменять инкапсулированные сообщения ISUP для устранения условий, характерных для изначального канала, например, флаги контроля непрерывности в Типе индикаторов соединения (Nature of Connection Indicators), и т.п.
В случае завершения в IP (рис. 28), UAS S1P, который получает сообщения SIP с инкапсулированным ISUP, обычно игнорирует сообщение ISUP. Это, однако, вводит общее требование, чтобы устройства, такие как телефоны SIP, корректно (gracefully) обрабатывали многосоставные сообщения MIME и неизвестные типы MIME.
Требования к терминатору: стандартная обработка SIP, интерпретация инкапсулированных сообщений ISUP (только для шлюзов), поддержка для многосоставного MIME, корректная обработка неизвестного содержимого MIME (для всех, кроме шлюзов).
2.4.3. Посредник
Посредники, такие как прокси-серверы, отвечают за маршрутизацию сообщений между собой, а также к шлюзам и телефонам SIP. Каждый прокси-сервер принимает решения о передачи далее запроса SIP на основе значений параметров различных заголовков, или «маршрутизируемых элементов» (routable elements) (включая Request-URI, заголовки маршрутизации, и многие другие элементы запроса SIP).
SIP-T вводит некоторые дополнительные соображения для дальнейшей передачи запроса, что может привести к новым особенностям и требованиям для посредников. Прозрачная передача сообщений ISUP является центральным понятием SIP-T. Проблема совместимости между различными версиями реализации протокола ISUP, инициирующего и завершающего интерфейсы ТфОП, автоматически ведет к необходимости сквозной передачи. Таким образом, прокси-серверы заинтересованы в тех вариантах ISUP, которые инкапсулируются с запросами — вариант, сами могли бы стать маршрутизируемым элементом. Завершение запроса в большей близости к конечному назначению (тарифные соображения) также являются важными соображениями.
Выбор решения — есть компромисс между простотой функционирования и ценой. Требование обеспечения разумного тарифа может диктовать, чтобы вызов SIP-T перекрывал несходные интерфейсы ТфОП (мост SIP через различные шлюзы, которые в целом не поддерживают какие-либо варианты ISUP). Чтобы произвести оптимизацию прозрачности и тарифов, операторы посредников могут рассмотреть следующим действия:
а) Необходимость в сквозной передаче сообщений ISUP может потребовать различной трансляции (преобразования) сообщений ISUP, т.е. преобразования из одной версии ISUP в другую, чтобы облегчить завершение вызова через интерфейс шлюза, который не поддерживает версию ISUP инициирующего интерфейса ТфОП. Даже при этом приемлемость специальной информации ANSI в сети ETSI (и наоборот) остается под вопросом. Ясно, что возможности SIP-T реализуются, когда инкапсулированный 1SUP включает использование фирменных параметров. Хотя преобразование может быть выполнено в любой точке на пути запроса, оптимальным является произвести его в точке наиболее приближенной к завершающему шлюзу. Это может быть выполнено путем передачи вызова приложению, которое может выполнить преобразование между рагтичными версиями. Сквозная передача в этом случае сопряжена с доступностью ресурсов для проведения преобразования ISUP, а это ведет к увеличению времени установления соединения.
б) Альтернативный вариант пренебрегает прозрачной передачей сообщений ISUP, передавая вызов шлюзу, который не поддерживает версию ISUP инициирующей стороны. В этом случае завершающий MGC игнорирует инкапсулированный ISUP и использует информацию в заголовке SIP для завершения вызова.
Таким образом, было бы желательно для прокси-серверов, имеющих для этого возможности, делать выбор на основе доступных опций.
Требования к прокси: способность маршрутизировать вызов на основе выбора маршрутизирующих элементов.
2.4.4. Общие требования к поведению
Если инициатором SIP-T является шлюз, который получил запрос ISUP, то он должен всегда выполнять как инкапсуляцию, так и трансляцию сообщений ISUP, независимо от того, где по предположению инициатора может завершиться запрос.
Если терминатор не понимает сообщений ISUP, то он игнорирует их во время осуществления стандартной обработки SIP. Если терминатор не понимает сообщений ISUP, а должен обратиться к ТфОП, то он должен повторно использовать инкапсулированные сообщения ISUP, если он понимает эту версию реализации ISUP. При этом терминатор должен выполнить следующие шаги:
1.Извлечь информацию ISUP из тела сообщения и использовать эту информацию как шаблон сообщения. Необходимо отметить, что если в сообщении нет инкапсулированного ISUP, то шлюз возможно вместо этого должен будет использовать стандартный шаблон для типа сообщения (предварительно заполняемое сообщение ISUP, сконфигурированное в шлюзе).
2.Перевести заголовки запроса SIP в параметры 1SUP, переписывая любые значения в шаблоне сообщения.
3.Применить любую локальную политику в конфигурировании параметров. Посредник должен быть способен маршрутизировать вызов на основе выбора маршрутизирующих элементов в заголовках SIP.
2.5. Требуемые механизмы SIP
2.5.1. Базовый SIP
SIP-Т использует методы и процедуры SIP, определяемые RFC 3261.
2.5.2. Трансляция
Трансляция включает в себя все аспекты преобразования протокола сигнализации между SIP и ISUP. К проблеме трансляции относятся по существу два компонента:
1. Отображение сообщения ISUP на SIP. Оно описывает соответствие между ISUP и SIP на уровне сообщений. При реатизации SIP-Т на шлюзы возлагается задача генерации специачьного сообщения ISUP для каждого получаемого сообщения SIP и выполнение обратной функции. Это необходимо для определения правил, регулирующих соответствие между сообщениями ISUP и SIP (т.е., какие сообщения ISUP посылаются, когда получено конкретное сообщение SIP: IAM должно быть гослано при получении INVITE, REL при получении BYE и так далее).
2.Отображение параметров ISUP на заголовок SIP. Запрос SIP, используемый для установления телефонного соединения, должен содержать информацию, обеспечивающую ему правильную маршрутизацию к месту назначения прокси-серверами сети SIP — например, номер телефона, набранный вызывающим пользователем. Это важно для стандартизации набора правил, определяющих процедуру трансляции информации ISUP в SIP (например, Номер Вызываемой Стороны (Called Party Number) в ISUP IAM должен быть отображен в поле заголовка То и в Request-URI протокола SIP, и т.п.). Эта задача становится значительно более сложной, если учесть, что заголовки запроса SIP (и 15 частности INVITE) могут быть трансформированы в промежуточных пунктах, в результате чего заголовки SIP и инкапсулированные части ISUP могут выдавать противоречащие друг другу значения — фактически часть инкапсулированного ISUP может считаться ненужной и устаревшей.
2.5.3. Инкапсуляция
Инкапсуляция сигнализации ТфОП является одним из основных требований SIP-T. SIP-T использует мультисоставные части MIME для того, чтобы сообщения SIP могли содержать в себе разнообразную полезную нагрузку (Протокол описания сеанса — Session Description Protocol (SDP), ISUP, и т.д.). В настоящее время существуют многочисленные версии ISUP; тип ISUP MIME позволяет получателям опознавать тип ISUP (и таким образом определять, поддерживают они данную версию или нет) наиболее быстрым возможным образом.
2.5.3.1. «Прозрачный» транзит для сообщений ISUP
Чтобы позволить шлюзам получить преимущество полного набора услуг, предоставляемого существующей телефонной сетью при установлении вызовов от ТфОП к ТфОП через сеть SIP, сообщения SIP должны быть способны к транспортировке полезной нагрузки ISUP от шлюза к шлюзу. Агентам пользователя SIP, которые не понимают ISUP, разрешается игнорировать опциональные тела MIME.
2.5.3.2. Понимание многосоставных тел MIME
В большинстве ситуаций взаимодействия ТфОП, тела сообщений SIP будут нести информацию описания сеанса (SDP), в дополнение к ISUP и/или биллинговой информации. Узлы взаимодействия ТфОП должны понимать тип MIME мультисоставной/смешанный (multipart/ mixed), как определено в RFC2046. Клиенты выражают поддержку этому, путем включения ;multipart/mixed; в заголовок ;Accept;.
2.5.3.3. Согласование содержания SIP
Инициатор запроса SIP-T должен упаковать оба элемента SDP и ISUP в одно и то же сообщение SIP, используя мультисоставной формат MIME. В SIP принято, что если терминальное устройство не поддерживает мультисоставную нагрузку (мультисоставную/смешанную) и/или конкретный тип ISUP MIME, то оно должно отклонить этот запрос SIP ответом 415 (Unsupported Media Type — не поддерживаемый тип медиа-соединения) с указанием поддерживаемых типов средств (по умолчанию, application/SDP). Затем инициатор должен вновь послать запрос SIP, убрав из него нагрузку ISUP (т.е. только с нагрузкой SDP), и тогда он будет принят.
Это довольно громоздкая процедура, и поэтому крайне желательно иметь механизм, посредством которого инициатор мог бы пометить
обязательные и необязательные элементы так, чтобы принимающая сторона могла просто отбрасывать необязательные элементы, которые она не понимает (позволяя телефону SIP игнорировать нагрузку ISUP, если ее обработка не является критичной). Это возможно, если принимающая сторона имеет поддержку мультисоставного/смешанного типа содержимого (Content-type) и доступ к заголовку расположения содержимого (Content-Disposition) для выявления критичности.
2.5.3.4. Примеры обмена сообщениями
1. Поддержка ISUP не является обязательной. Поэтому UA2 принимает запрос INVITE независимо от того, может ли он обрабатывать ISUP.
UAl UA2
INVITE-->
(Сог. с or. r. -type :rr.uitipart/mixed;
Content.-typo: applicat ior./sdp;
Content-disposition: session; handling=required,
Content.-type : applicat io.n/i sup;
Cor. tout disposition.: signal; handling=opt ional; )
<--18x
2. Поддержка ISUP желательна. UA2 не поддерживает ISUP и отвергает запрос INVITE посредством сигнала 415 Unsupported Media Type Туре (не поддерживаемый тип медиа-соединения). UA1 отбрасывает сообщение ISUP и вновь посылает INVITE с одним лишь SDP, и тогда этот запрос принимается.
UAl UA/
INVITE-->
(Content type :rr.ultipart /mixed; .Content-typo: applieation/sdp;
Content-dispos:tion: session; handling-required;
Contenttype: appi ication/isup;
Content-disposition: signal; hand!ing=required;)
<--415 (Accept: application/sdp)
/\CK-->
INVITE - >
(Content■type: appi ication/sdp)
< -18x
3. Поддержка ISUP обязательна для установления вызова. UA2 не поддерживает ISUP и отвергает запрос INVITE посредством сигнала 415 Unsupported Media type Type (не поддерживаемый тип медиа-соединения). Тогда UA1 перенаправляет свой запрос к UA3.
UAl UA2
INVITE-->
(Content-type:multipart/mixed;
Content-type: application/sdp;
Content-disposition: session; handling=required;
Content-type: appiication/isup;
Content-disposition: signal; handling=required;)
<--415 (Accept: application/sdp)
ACK-->
UAl UA3
INVITE-->
(Cont ent - type: rr.ul t ipar t /mixed ;
Content-type: application/sdp;
Content-disposition: session; har.dling=required;
Content-type: application/isup;
Content-disposition: signal; handling=required;)
Необходимо отметить, что вышеприведенный обмен сообщениями не является полным. Более подробно тип ISUP MIME рассмотрен в соответствующих спецификациях.
2.5.4. Надежная передача предварительных ответов (Provisional Responses)
Предварительные ответы (в классе 1хх) используются в передаче информации о прохождении вызова. Взаимодействие ТфОП, в частности, основывается на этих сообщениях для управления медиа-каналом и синхронизации этапов вызова. При взаимодействии с ТфОП, сообщения SIP должны надежно пересылаться из конца в конец; надежность запросов гарантируется базовым протоколом.
2.5.5. Предответное проключение (Early Media)
Предответное проключение означает возможность запустить медиа-информацию (звук для телефонии) до установления сеанса SIP (до
того, как был послан код ответа 2хх). Для телефонии желательно установление медиа-соединения в обратном направлении, т.к. можно выдать частоты и сигналы уведомления, особенно при взаимодействии с сетью, которая не может сигнализировать о состоянии вызова вне полосы речевого сигнала (как то сеть MF). В случаях, когда межсетевого взаимодействия не осуществляется, использование предответного приключения почти всегда нежелательно, т.к. это занимает ресурсы медиа-канала, от которой нет никакой пользы.
Так как INVITE почти всегда содержит SDP, необходимую для отправки медиа-информации в обратном направлении, и требует, чтобы агенты пользователя сами подготовились для получения обратного медиа-каната, как только INVITE был передан, базовый протокол SIP имеет достаточную поддержку для рудиментарных однонаправленных систем предответного проключения. Однако этот механизм имеет некоторые ограничения — например, медиа-потоки, предлагаемые SDP INVITE, не могут быть изменены или отклонены, и двунаправленный RTCP, необходимый для установления сеанса, не может быть установлен.
В сетях SIP не только коммутаторы, но также и агенты пользователя могут генерировать коды ответа 18х и инициировать в обратном направлении предответное проключение. Поэтому некоторые шлюзы могут ввести такую политику, которая ограничит использование проключения в обратном направлении от произвольных агентов пользователя.
2.5.6. Поддержка сигнализации во время разговора
Чистый SIP не имеет средств для передачи какой-либо управляющей информации во время разговора, которая генерировалась бы во время сеанса. Для этой цели должен использоваться метод INFO. Однако, следует заметить, что INFO не может применяться для управления набором. Также INFO не рекомендуется использовать для сигнализации при применении во время разговора частотных сигналов набора номера DTMF.
Передача информации DTMF
То, как набираемые пользователем частоты DTMF передаются шлюзом, полностью противоположно тому, как взаимодействуют SIP и ISUP. Однако, поскольку передача DTMF является компонентом законченного шлюзового решения, то здесь предлагается некоторое руководство. Так как кодек, выбранный для передачи голоса, может не совсем хорошо подходить для передачи информации DTMF, поэтому желателен символический метод передачи этой информации в разговорном спектре.
2.5.8. Mid-Call. Транзакции, не изменяющие состояние SIP
При взаимодействии с ТфОП имеют место ситуации, когда шлюзам необходимо будет отправить сообщения друг другу через SIP, что не соответствует никаким операциям SIP.
Для поддержки mid-call транзакций и других событий ISUP, которые не соответствуют существующим методам SIP, шлюзы SIP должны поддерживать метод INFO, определенный в RFC2976. Следует отметить, что этот документ не предписывает и не рекомендует использование INFO для передачи цифр DTMF.
Шлюзы должны принять «метод 405 не разрешен» (;405 Method Not Allowed;) и «501 не используется» (;501 Not Implemented;), как допустимые (non-fatal) ответы на запросы INFO — т.е. любой вызов при установлении не должен быть отклонен, если точка назначения таким образом отвечает на запрос INFO, посланный шлюзом.
2.5.9. Защита секретности
ISUP имеет концепцию ограничения предоставления — механизм, с помощью которого пользователь может определить, что он не хочет, чтобы его телефонный номер отражался на дисплее вызываемого абонента (возможно некто с Caller ID). Когда шлюз получает запрос 1SUP, который требует ограничения предоставления, то он должен каким-то образом скрыть номер вызывающего абонента.
Базовый протокол SIP поддерживает метод спецификации анонимности пользователя. Однако, эта система имеет некоторые ограничения — например, она открывает идентификационный номер самого шлюза, что может нарушить секретность. Поэтому шлюзы могут поддерживать более сложные системы секретности.
2.5.10. Причины отмены (CANCEL)
В ISUP имеется способ сигнализировать о том, что вы хотели бы прервать попытку установления вызова — в прямом направлении посылается сообщение общего назначения RELease. Аналогичная концепция имеется и в SIP — запрос CANCEL, который посылается, чтобы прервать установления диалога SIP. По различным причинам, однако, запросы CANCEL не могут содержать тела сообщения, и поэтому, чтобы передать необходимую информацию в REL (код причины), в случаях сквозного соединения sip, инкапсуляция ISUP не может использоваться.
Обычно это не является большой проблемой, т.к. для практических целей единственной причиной, когда выдается REL для отмены попытки установления вызова, является ситуация, когда пользователь повесил трубку телефона во время установления соединения (что соответствует коду отмены ;Normal clearing;). Однако, в исключительных случаях, типа внезапного отказа сети, REL может быть послан с другим кодом причины, и было бы удобно, если бы сеть S1P могла передавать код причины из конца в конец. Поэтому шлюзы могут поддерживать механизм для сквозной передачи таких причин отказа.
2.6. Отображение сигнализаций SIP-ISUP
Этот раздел описывает логику и процедуры, которые может использовать MGC для осуществления отображения между SIP и ISUP, путем иллюстрации соответствий между протоколами на уровне сообщений и уровне параметров. Он также описывает взаимодействие между параллельными оконечными автоматами (state machines) для этих двух протоколов как рекомендацию для реализаторов, чтобы синхронизировать события протокола во взаимодействующих архитектурах.
Основное внимание уделено трансляции сообщений ISUP в сообщения S1P и отображении параметров ISUP в заголовках SIP. Для вызовов ISUP, которые проходят через сеть SIP, целью трансляции является разрешить элементам SIP, таким как прокси-сервера (которые обычно не понимают ISUP), принимать решения по маршрутизации на основе такого критерия ISUP, как номер вызываемой стороны. Этот документ последовательно обеспечивает SIP только для тех параметров ISUP, которые могут быть использованы посредниками в маршрутизации запросов SIP. Как побочный эффект этого подхода, трансляция также увеличивает общую способность к взаимодействию путем обеспечения критической информацией о вызове оконечных точек SIP, которые не могут понять инкапсулированный 1SUP, или которые, возможно, просто не понимают отдельный вариант инкапсулированного в сообщение ISUP.
Эта глава принимает во внимание лишь функциональность вызова ISUP. Сообщения установления соединения, имеющие дело с каналами ТфОП, обслуживаются постольку, поскольку они влияют на управление исходящим вызовом; в противном случае эти сообщения не требуют никакого аналога в SIP.
Сообщения, указывающие на ошибку или состояние перегрузки в ТфОП (МТР-3) и механизмы восстановления, использующие такие
сообщения ISUP как User Part Available и User Part Test, выходят за рамки рассмотрения в данном документе.
Этот документ описывает, когда разговорный тракт, связанный с вызовом SIP, должен быть инициирован, закрыт, изменен и т.д., но не вдается в детали, такие как выполнение инициализации или какие протоколы используются для этой цели.
Механизмы набора номера с перекрытием (overlap dialing mechanisms) (исггользование Последующего адресного сообщения — Subsequent Address Message (SAM)) рассмотрены в отдельном разделе. Данный раздел предполагает, что шлюзы, взаимодействующие с сетями ISUP, в которых используется overlap dialing, будут использовать таймеры, чтобы удостовериться, что все цифры были собраны до передачи INVITE в сеть SIP.
В некоторых случаях, шлюзы могут принять неполные сообщения ISUP, что обусловлено сегментацией сообщения при чрезмерной длине сообщения. Обычно эти сообщения будут сопровождаться сообщением сегментации (Segmentation Message (SGM)), содержащим остаток исходного сообщения ISUP. Неполное сообщение может не содержать достаточных параметров для верного отображения в SIP; аналогично, инкапсуляция (см. ниже) неполного сообщения ISUP, может вносить неясность для завершающих шлюзов. Следовательно, шлюз должен ждать, пока не будет принято полное сообщение ISUP (что может означать ожидание поступления одного или более SGM) до отправки любого соответствующего INVITE.
Отображение между ISUP и SIP описывается с использованием диаграмм потоков вызова и конечных автоматов. Один конечный автомат обрабатывает вызовы от SIP к ISUP, а другой — от ISUP к S1P. Некоторые подробности, такие как повторные передачи и некоторые состояния (ожидание RLS, ожидание АСК, и т.д.), не показаны на рисунках с целью их упрощения.
Прямоугольники обозначают различные состояния шлюза, а стрелки показывают изменение этих состояний. События, вызывающие изменения состояния и действия, которые должен выполнить шлюз написаны у стрелки: событие/раздел, описывающий соответствующие действия.
Рекомендуется, чтобы шлюзы реализовывали функциональное соответствие с потоком вызова. Различия между этими потоками допускаются для обеспечения поддержки национальных вариантов спецификаций ISUP, или консервативных политик.
2.7. Отображение SIP на ISUP 2.7.1. Потоки вызовов от SIP к ISUP
Приведенные потоки вызовов иллюстрируют порядок сообщений в типичном случае и в случаях ошибок при установлении соединения, инициированного сетью SIP. Подтверждения «100 Truing» на запросы INVITE не показаны, хотя они требуются во многих архитектурах.
На этих диаграммах вся сигнализация (SIP, ISUP) к и от MGC; опрерирование медиа-информацией (проключение аудиоканала, освобождение канала) выполняется MG под управлением MGC. Для упрощения они показаны одним узлом, обозначенным как «MGC/MG».
2.7.1.1. Установление вызова с блочной сигнализацией (без автоответа)
Рис. 32. Установлениевызовасблочнойсигнализацией (безавтоответа)
1.Когда пользователь SIP желает инициировать сеанс связи с пользователем ТфОП, узел SIP выдает запрос INVITE.