Опции сигнализации IXC

Опции сигнализации IXC

 

Софтсвитч несет в себе интеллектуальные возможности IP-сети. Его функции заключаются в координации управления обслуживания вызовов, сигнализации и функции, обеспечивающие установление соединения через IP-сеть.

Софтсвитч IXC поддерживает сигнализацию, как по протоколу SIP, так и по протоколу H.323. SIP и H.323 - протоколы которые лежат в основе технологии Voice over IP.

Рассмотрим как происходит процесс установления соединения через IXC Softswitch. На web-интерфейсе софтсвитча создаются точки входа (инпиры) и точки выхода (аутпиры).

Приходящее на свитч сообщение о запросе установления соединения, будь то INVITE для протокола SIP, или же Setup для H.323, обрабатывается и сопоставляется с одной из точек входа путем сравнения префикса телефонного номера вызывающей стороны, IP-адреса вызывающей стороны, и А-номера вызывающего абонента. Вся нужная для сопоставления звонка точке входа информация содержится в сигнальных сообщениях, также в них может находится и дополнительная информация для установления соединения со специальными настройками.

После того, как входящий на свитч звонок, сопоставлен с одной из точек входа, он обрабатывается по правилам заданным для данной точки входа настройками софтсвитча.

Далее звонок маршрутизируется на одну из точек выхода. Маршрутизация происходи на основании телефонного номера и IP-адреса вызываемой стороны, разрешенных маршрутов (список аутпиров), заданных в настройках точки входа, и далее по цене, длине префикса и приоритетам. Пользователь сам задает порядок приоритетности параметров, по которым будет осуществляться маршрутизация (цена, длина префикса и приоритет) в общих настройках софтсвитча.

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

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

Стоит отметить что IXC Softswitch поддерживает прото транскодинг, т.е. перекодировку сообщений по протоколу SIP в H.323 и обратно, в случае необходимости.

Также есть функция и медиа транскодинга, - перекодировка кодеков в случае если терминатор и оригинатор работают на разных кодеках. Настраивается медиа транскодинг легко и быстро в настройках точек входа и выхода.

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

Каждая из настроек сигнализации подробно описана ниже.

Рассмотрим IXC Softswitch, и уникальные настройки сигнализации доступные на web-интерфейсе.
Если звонок проходит по протоколу H.323 возможна настройка опций сигнализации:

I. Настройки H.245 туннелинга.

Протокол H.245, - протокол согласования параметров соединения. Является составляющей частью протокола H.323 . Прежде всего, используется для построения иерархии master-slave (ведущий-ведомый) между устройствами обменивающимися данными. H.245 производит настройку оконечных устройств и управляет логическими каналами (открытие, закрытие, изменение).

Туннелинг позволяет устанавливать соединение между оконечными точками по протоколу H.245 используя Н.225 каналы, не создавая отдельного TCP соединение.

Такой подход дает следующие преимущества:
- Позволяет сохранить ресурсы операционной системы, необходимые для установления TCP соединения;
- Более быстрое установление соединения, поскольку нету необходимости нового соединения и « трёхкратного рукопожатия».

При установление H.323 соединения без туннелирования использует два TCP соединения.

Рис.1. Пример соединения по протоколу H.323

Для настроек H.245 туннелинга на веб интерфейсе заданы такие опции, как:
- droptunneling - если стоит "y", -то H.245 туннелинг запрещен. Если "n", - туннелинг разрешен;
- droptunnelingwith H245 address - предназначено для случая, когда H.245 туннелинг разрешен и одновременно клиентское устройство запрашивает адрес для отдельной (не туннелированной) сессии H.245 . "y" означает, что в таком случае туннелинг отменяется и запрос адреса для сессии H.245 передается абоненту. По умолчанию туннелинг разрешается ("n");
- permitTunnelingInSetup - "y" - означает включение отправки параметров туннелинга в сообщении setup;
- startH245 - принудительное использование Н.245 tunneling.

II. Настройки специфической обработки сигнальных сообщений.

Рассмотрим процесс установления соединения по протоколу H.323.

Свитч ретранслирует сообщения полученные от терминатора и оригинатора.

Соединение устанавливается по протоколу H.225. Вызывающая сторона отправляет запрос на установление соединения Setup на транспортный адрес сигнального канала оборудования. Оборудование вызываемой стороны отвечает Call Proceeding, а затем Alerting. Вызываемая сторона получает сигнал о входящем вызове, а вызывающая сторона получает информацию, занят ли вызываемый абонент в этот момент или нет.

При принятии вызова терминатором, оригинатору отправляется сообщение Connect с указанием транспортного адреса управляющего канала H.245 . После чего открывается управляющий канал H.245 и выполняется обмен данными о функциональных возможностях, определение ведущего/ведомого оборудования, открытие однонаправленных логических каналов.

Далее происходит взаимный обмен голосовой информации по средствам RTP/UDP/IP между абонентами.
После завершения разговора происходи процесс завершения соединения. По H.245, от абонента завершающего разговор, передается сообщение endSessionCommand на что вторая сторона также отвечает endSessionCommand, - транспортный канал закрывается. После чего посылается сообщение Release Complete и сигнальный канал также закрывается.

На свитче задаются опции:
- dropprogressbeforealerting - "y" означает, что в случае, когда приходит H.323 Progress перед H.323 Alerting, он не будет пропускаться софтсвитчем. По умолчанию стоит "n", т.е. H.323 Progress, пришедший перед H.323 Alerting, будет пропускаться;
- dropnonstandard - "y" означает, что при сигнализации все нестандартные атрибуты будут убираться. По умолчанию стоит значение "y";
- replaceCallProceedingWithAlerting - "y" – включает отправление сообщения Alerting оригинатору после получения сообщения Call proceeding от терминатора;
- answer to RTDR -"y" – означает что софтсвитч будет отвечать round trip delay response на запрос round trip delay request.
Поддержка ответа на запрос о времени распространения по протоколу H.245 для управляющего канала;
- emptyFacility - "y" - означает что Facility которые не содержат технической информации не будут обрабатываться.
Сообщение Facility используется для обращения к дополнительным сервисам в соответствии с в соответствии с Рекомендациями ITU H.450.X;
- useFacility - принудительное использование Facility в Н.323 звонках.

III. Настройки FastStart.

FastStart - процедура быстрого установления голосового соединения по протоколу H.323 без открытия управляющего канала H.245 . При FastStart информация о логических каналах , адресах для обмена речевыми RTP данными и поддерживаемых кодеках передается оригинатором в сообщении Setup, а вызываемой стороной в сообщении Call proceeding или Alerting.

Настройки:
- dropfaststart - "y" означает запретить FastStart. По умолчанию FastStart разрешен.

IV. Настройки таймаутов и длительности разговора.

Свитчем может контролироваться таймауты RTP потоков, как односторонние так и двухсторонние. Задается период проверки наличия RTP потока, временные рамки ожидания сигнальных сообщений. Может ограничиваться максимальная длительность звонка. Настройки таймаута и ограничения максимальной длительности звонка применимы и для звонков по протоколу SIP .

Задаются опции:
- rtptimeoutenable - "y" означает включить контроль time out RTP потока при полном проксировании. По умолчанию – включено;
- rtptimeoutboth - обрывать звонок при отсутствии RTP потока в обоих направлениях в течение указанного времени в секундах (по умолчанию 60 сек.);

Звонки будут завершаться по инициативе софтсвитча если опция включена и RTP поток и от оригинатора и от терминатора отсутствует в течении указанного времени.
- rtptimeoutone - обрывать звонок при отсутствии RTP потока в одном направлении в течение указанного времени (по умолчанию 180 сек.);

Звонки будут завершаться по инициативе софтсвитча если опция включена и RTP поток и от оригинатора или от терминатора отсутствует в течении указанного времени;
- rtptimeoutperiod - период проверки отсутствия RTP потока (по умолчанию раз в 30 сек.);
- Q931 connecttimeout - время ожидания пакета Connect от терминатора.
Q.931 — рекомендация ITU-T и основанная на нём реализация протокола управления соединениями для цифровой телефонии ISDN;
- maxcalldurationinminutes - максимальная длительность разговора. Частота проверки - 1 раз в минуту.

V. Настройки полей сигнальных сообщений.

Некоторые поля сигнальных сообщений могут удалятся или добавляться или.

Одной из основных опций является нормалайзер и добавление поля Bearer Сapability, а также destinationAddress и destCallSignalAddress.

Нормалайзер может использоваться исключительно для звонков H.323 . Нормалайзер выполняет следующую функцию: сообщения приходящие на свитч обрабатываются и затем свитчем создаются сообщения по стандартной форме, определенной RFC, с информацией, имеющейся в пришедших, и передаются терминатору. При выключенном нормалайзере сообщения просто пересылаются свитчем в таком виде в котором они на него пришли.

Bearer capability – одно из информационных полей Q.931 Setup. Используется вызывающей стороной для определения типа канала B, который запрашивается. Может передаваться в сообщении Progress или Connect. Является составной частью Q931, а именно IE – информационный элемент. Определяет запрошенное обслуживание: тип соединения (пакетная или канальная коммутация), скорость передач данных, тип информации.
destinationAddress и destCallSignalAddress указывают адреса вызываемого абонента.

Если определены поля destinationAddress и destCallSignalAddress то звонок будет маршрутизироваться на них, алиасы, префиксы и т.д. далее не проверяются.
destinationAddress = 1 entries {
[0]=dialedDigits "тел. номер вызываемого абонента"
}
destCallSignalAddress = ipAddress {
ip = 4 octets {
“IP вызываемого абонента в шестнадцатеричном формате ”

Опции:
- addBearerToConnect - "y" – означает включение отправки bearer capability внутри сообщения connect;
- removeSymmetricOperation - "y" означает удаление поля Symmetric Operation Required;
- useNormalizer -"y" означает использование софтсвитчем нормалайзера (стандартизация всех сообщений, для этой опции требуется модуль конвертора протоколов);
- addDestinationAddress – добавляются поля destinationAddress и destCallSignalAddress (для Н.323 звонков).

Если звонок приходит по протоколу SIP, имеется следующий перечень настроек:

I. Настройка поддержки DTMF.
DTMF по протоколу SIP могут передаваться или с помощью сообщений INFO или при помощи RTP сообщений. Передача DTMF по SIP описана в рекомендации IETF RFC 2833 , где определена сигнализация для событий:
- тоны DTMF посылок ;
- тона, связанные с передачей факсов ;
- стандартные тональные сигналы линии ;
- тональные сигналы линии специфичные для каждой страны ;
- транковые события (trunk events) .

Опция:
- ForceInserting DTMF intoInvite - свитч принудительно добавляет поддержку DTMF (Dual-Tone Multi-Frequency).

II. Настройки полей сигнальных SIP сообщений.

Доступны настройки полей: Via, P-Asserted-Identity, Record-Route, RemoteParty ID.

Поле Via переносит информацию о списки элементов сети через которые запрос прошел на данный момент. Это необходимо что бы не возникали «петли», а также для того что бы запрос и ответ проходили по одному и тому же пути. Каждый прокси-сервер добавляет свой адрес. Параметр «branch» в поле заголовка Via используется как идентификатор транзакции для обнаружения «петель».

Содержит информацию о транспортном протоколе, сетевой адрес и, возможно, номер порта для получения ответов.
Via: SIP/2.0/UDP «IP прокси-сервера»:5060;branch=z9hG4bK-54959-1-0;received= «IP адресата»;rport=1329

Заголовок P-Asserted-Identity применяется в сообщениях между логическими
составляющими SIP, между которыми высокий уровень доверия, для переноса информации, удостоверяющей пользователя.
P-Asserted-Identity:

Заголовок Record-Route добавляется Proxy-серверами в запросы для того, чтобы последующие запросы в процессе диалога направлялись через данные Proxy-серверы.
Record-Route:
Этот заголовок является идентификатором удаленной стороны и предназначен для переноса информацию о абоненте на дальней стороне.
Remote-Party-ID: ;party=calling;privacy=uri;screen=yes
Указывается номер телефона с которого производится звонок и IP-провайдера.

Опции:
- supportVia - "y" -включение обработки поля via в сообщении Invite от оригинатора (ответ на адресс указанный в этом поле, а не на тот адрес с которого получили sip сообщение).
- isPAssertIdRequired - "y"означает что софтсвитч будет генерировать сообщение P-Asserted-Identity для терминатора;
- isTrusted - "y" - означает что софтсвитч не будет убирать сообщение P-Asserted-Identity;
- isRecordRouteRequired - "y" - означает что софтсвитч будет генерировать сообщение Record-Route;
- useRemotePartyID - добавляет в сообщение RemoteParty ID.

III. Настройки поддержки специальных сообщений.
Поддержка сообщения типа Accounting. Сообщения содержащие биллинговую информацию. Позволяет обмениваться финансовой информацией между поставщиками без использования биллинга типа поставщик-поставщик.

Опция:
- isAccSend- опция, которая указывает будут ли отсылаться сообщения типа Accounting .
На главной странице web интерфейса биллинга IXC опции сигнализации (Signalling options) находятся в группе Administrative tools.

Рис.2. Вид главной страницы web-интерфейса IXC Softswitch

В Signalling options можно создавать списки настроек опций сигнализации. Для этого необходимо нажать кнопку [:: Add ::]. Появляется список настроек сигнализации.

Рис.3. Вид страницы опций сигнализации web-интерфейса IXC Softswitch
Где:
rname–имя пользователя, на которого создается данный список опций сигнализации (из Userspermissions).
name - название созданного списка опций сигнализации.