Инкапсуляция ISUP в SIP

Протокол SCTP и ассоциированные с ним уровни адаптации обеспечивают возможность пересылать информацию протокола приложений ОКС7 из оконечного пункта ТфОП в центр сети VoIP, где расположен Softswitch, получающий таким образом доступ к сигнальной информации для маршрутизации вызовов в сети VoIP. Сами протоколы приложений ОКС7 могут использоваться или не использоваться в сети VoIP; в последнем случае такие протоколы, как ISUP, отображаются в таких эквивалентных протоколах VoIP, как рассмотренный в главе 4 протокол SIP. Отображение SIP-ISUP рабо­тает очень хорошо, если одна сторона соединения является узлом VoIP, а другая - узлом ТфОП. Однако когда IP-сеть с Softswitch обес­печивает функции транзита между TDM-сетью коммутации каналов на исходящей стороне и такой же сетью на входящей стороне, могут возникать проблемы. Поскольку протоколы SIP и ISUP разработаны разными способами, редко удается найти прямое соответствие между сообщениями и параметрами одного протокола и сообщени­ями и параметрами другого. Кроме того, чтобы обеспечить взаимо­действие, нужно учитывать различия между конечными автоматами, таймерами и пр. Результат получается хотя и работоспособным, но часто далеким от совершенства. Причина состоит в том, что один протокол может быть несколько лучше в одном отношении, а дру­гой -лучше в другом отношении. Следовательно, взаимодействие часто происходит по схеме логического И, т.е. функциональные воз­можности, получаемые в результате взаимодействия, ограничены только теми возможностями, которые поддерживают оба протокола. Например, поля заголовков SIP могут переносить информацию, которой просто нет в ISUP. Таков, в частности, заголовок Retry-after, поле которого в ISUP вовсе негде отобразить.

ISUP тоже содержит информацию, которую нелегко отобра­зить в заголовках SIP (если вообще возможно). Часто приходится отображать такую информацию в SIP лишь частично, или вооб­ще отбрасывать. Это не так уж плохо, если вызов поступает от пользователя ТфОП к пользователю SIP, поскольку сервер агента пользователя SIP все равно не смог бы эту информацию интерпре­тировать. Но когда речь идет о связях TDM-IP-TDM (например, при междугородной/международной связи с использованием VoIP), то в точке входа в IP-сеть ISUP преобразуется в SIP, а в точке выхода из этой сети происходит обратное преобразование SIP в ISUP. В этом случае результат может оказаться таким, что сообщения ISUP, выхо­дящие из транзитной сети, будут отличаться от сообщений, которые в нее поступили. Чтобы решить эту проблему, можно инкапсулиро­вать сообщение ISUP в тело сообщения SIP. Запросы и ответы SIP используются между Softswitch, и там, где надо, они должны содер­жать тело сообщения SDP, чтобы описать для этих Softswitch инфор­
мацию, которую необходимо передавать между управляемыми ими шлюзами MG. Некоторые из сообщений SIP могут содержать в сво­ем теле также и сообщение ISUP в двоичной форме. В этом случае тело сообщения SIP будет переносить и описание сеанса SDP, кото­рое используют Softswitch и шлюзы MG, и инкапсулированное сооб­щение ISUP, которое транспортируется через сеть IP прозрачно.

Рассмотрим сценарий, который изображен на рис. 9.5.

Коммутатор ТфОП

Коммутатор ТфОП

Softswitch-1

Softswitch-2

IAM

IAM

SIP INVITE

Описание сеанса Инкапсулированное IAM

ACM

SIP 183

Описание сеанса Инкапсулированное ACM

Одностороннее аудио

ANM

SIP 200

Описание сеанса Инкапсулированное ANM

SIP ACK

ANM

Двухстороннее аудио

Рис. 9.5. Инкапсуляция сообщений ISUP в сообщения SIP

ACM

Входящее сообщение IAM отображается в SIP-сообщении INVITE, которое содержит описание сеанса SDP, а также исход­ное сообщение ISUP. В пункте выхода из IP-сети информация SDP используется для организации сеанса связи между шлюза­ми, а информация ISUP извлекается для передачи в ТфОП. Когда соединение в ТфОП установлено, принятое сообщение ACM отображается в SIP-ответе 183 (продолжение сеанса), который содержит временное описание информации SDP и инкапсули­рованное ISUP-сообщение ACM для передачи в исходящий узел ТфОП. Аналогичный процесс имеет место при ответе на вызов, когда от входящего узла ТфОП поступает сообщение ANM.

Чтобы инкапсулировать сообщение ISUP в тело сообщения SIP, параметр Content-Type в поле заголовка сообщения SIP не должен указывать application/sdp. Вместо этого должен быть следующий формат:

Content-type: multipart/mixed; boundary = SDP-ISUP-boundary Content-type указывает, что тело сообщения содержит разные наборы информации в различных форматах. Границу между одним и другим описанием внутри тела сообщения указывает поле грани­цы. Его использование описано в документе RFC 2046 «Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types».

Внутри тела сообщения начало каждой части полезной нагрузки указывается с помощью границы «--boundary» в соответствии со спецификацией в Content-type: header. Поэтому, если бы сообщение SIP должно было содержать поле Content-type, как показано ранее, каждая часть полезной нагрузки в теле сообщения указывалась бы строкой «--SDP-ISUP-boundary». После последней части полезной нагрузки находится другая строка с форматом «--boundary--». В на­шем примере последней строкой будет «--SDP-ISUP-boundary--».

SIP-сообщение INVITE с инкапсулированной полезной нагрузкой может выглядеть следующим образом:

INVITE SIP: 8129606293@niits.ru SIP/2.0 From: SIP: 8123151515@skri.sut.ru; tag=abcd12345 Call-ID: 123456789@niits.ru Content-length: xxx

Content-Type: multipart/mixed; boundary = SDP-ISUP-boundary MIME-Version: 1.0

--SDP-ISUP-boundary Content-Tipe: application/adp v=0

o=agold 8129606293 IN IP4 4444.333.222.111 S=

c= IN IP4 4444.333.222.110 t=0 0

m=audio 5555 RTP/AVP 0 -- SDP-ISUP-boundary

Content-Type: application/ISUP; version = ANSI