wiki:EndpointSS7

Version 7 (modified by alx, 3 years ago) ( diff )

--

Статья находится в стадии создания! Представленная информация может быть неполной и/или неточной.

Подсистема SS7

Структура

Плата VE-01 (VE-02) содержит до четырех независимых инстанций SS7 SSP (Service Switching Point). Подсистема SS7 плат VE-01/VE-02 испльзует два типа канальных окончаний - сигнальные линки (SS7lnk) и разговорные каналы (SS7). Каждое из этих канальных окончаний "привязано" к одной из инстанций SSP.

Канальные окончания SS7lnk представляют собой сигнальные линки MTP2 и выполняют функции передачи сигнальных и управляющих сообщений. Канальные окончания SS7 представляют собой разговорные каналы для передачи речевой информации. Шлюз платы VE-01 (VE-02) обеспечивает преобразование сигнализации SS7 ISUP на стороне TDM в сигнализацию SIP на стороне IP и обратно, преобразование данных речевых каналов TDM и потоки RTP и обратно.

Пример сети с полно-ассоциированными линками (непосредственное подключение сигнальных каналов к удаленной станции):

Пример сети с квази-ассоциированными линками (сигнальные каналы подключены серез STP).

Описание работы

Установка соединения с сигнальной сетью

Соединение с сигнальной сетью (сигнальные линки) выполняется канальными окончаниями SS7lnk. Исходное состояние канального окончания - состояние Down. При успешной установке соединения MTP2 по сигнальному каналу с удаленным SP канальное окончание переходит в состояние Up. После этого SP обмениваются сообщениями STD_TEST и TRA.

Прием вызова со стороны сети IP

Прием телефонных вызовов со стороны сети IP выполняют канальные окончания SS7. Прием вызовов выполняется только на втором проходе поиска. Если канальное окончание SS7 свободно (то есть находится в состоянии Idle), и SSP, к которому привязано канальное окончание, успешно подключился к сигнальной сети (находится в состоянии Up), канальное окончание SS7 выполняет проверку на совпадение вызванного номера (имени пользователя) с регулярным выражением, установленным конфигурационным параметром "Рег. выражение вызова". Если обнаружено совпадение, проверяется наличие общего поддерживаемого аудиокодека для медиапотока RTP. Если общий поддерживаемый аудиокодек найден, канальное окончание SS7 обслуживает данный вызов (формирует и отправляет в сеть TDM сообщение IAM).

Базовый сценарий вызова

Базовый сценарий вызова со стороны IP приведен на следующий диаграмме:

При получении сообщения INVITE канальное окончание SS7 формирует и отправляет в сеть TDM сообщение IAM и переходит в состояние Proceeding.

Удаленная станция (Абонент Б), получив сообщение IAM, передает вызываемому абоненту сигнал вызова и отвечает сообщением ACM, в поле индикатора статуса которого содержится значение "Абонент свободен" (1).

При получении сообщения ACM канальное окончание SS7 передает в сторону сети IP ответ "180 Ringing".

После ответа вызываемого абонента канальное окончание SS7 получает сообщение ANM. После этого окончание SS7 передает в сеть IP ответ "200 OK", активирует медиапоток и переходит в состояние Connected.

Сценарий вызова с early media

Если канальное окончание SS7 получает со стороны TDM сообщение CPG, содержащее в поле event значение "Progress" или "Inband info", сигнализирующее о наличии данных в речевом канале, канальное окончание направляет вызывающему абоненту ответ SIP "183 Session Progress" с ответом на предложением SDP в теле сообщения и активирует медиапоток (early media). Таким образом, вызывающий абонент имеет возможность слышать речевые анонсы и/или другие акустические информационные сигналы, передаваемые в речевом канале. Пример сценария вызова с активацией медиапотока до ответа вызываемого абонента:

В данном примере поле event сообщения GPC имеет значение "Inband info", указывающее на наличие данных в речевом канале. При его получении канальное окончание SS7 сформировало сообщение SDP в теле ответа "183 Session Progress" и активировало медиапоток, дав возможность вызывающему абоненту прослушивать акустический сигнал "Контроль посылки вызова" (КПВ), сформированный оборудованием вызываемой стороны.

Вызов в сторону сети IP

Базовый сценарий вызова

При получении сообщения IAM плата VE-01 (VE-02) выполняет ряд проверок для определения возможности обслужить поступивший вызов, основные из которых перечислены ниже:

  1. Выполняется поиск разговорного канала (канального окончания SS7) с указанным в сообщении кодом CIC. Если канал не найден, сообщение игнорируется.
  2. Проверяется находится ли найденное канальное окончание SS7 в исходном состоянии. Если состояние отлично от Idle и RBlocked (см. ниже об удаленной блокировке канала), сообщение игнорируется.
  3. Проверяется значение поля Transmission Medium Requirements. Если его значение отлично от speech3.1k audio при условии установки конфигурационного параметра "Принимать 3.1k audio"), канальное окончание посылает отбой (REL), при этом поле cause устанавливается в значение "Bearer capability not implemented" (65). Данная проверка выполняется только для варианта протокола ITU.

Если конфигурационный параметр "Преобразование Caller-ID" имеет непустое значение, выполняется замена номера вызывающего абонента по совпадению с заданным регулярным выражением. После этого канальное окончание SS7 формирует сообщение INVITE и отправляет его в сеть IP и переходит в состояние Calling.

При получении из сети ответа "180 Ringing" канальное окончание PRI передает в сторону TDM сообщение ACM, содержащее в поле Called party's status indicator значение "Subscriver free" (1), и начинает передавать в разговорный канал сигнал "Контроль посылки вызова" (КПВ).

При получении из сети ответа "200 OK", сигнализирующего об ответе вызываемого абонента, канальное окончание SS7 прекращает передачу в канал сигнала "КПВ", активирует медиапоток, передает в сторону TDM сообщение ANM и переходит в состояние Connected.

Пример сценария вызова приведен ниже:

Сценарий вызова с overlap dialing (только ITU)

Рассмотренный выше сценарий предполагал, что сообщение IAM содержит в себе полный номер вызываемого абонента (En Bloc Dialing) и, таким образом, имеющейся в нем информации достаточно для трансляции вызова в SIP сообщение INVITE. В варианте протокола ITU возможны сценарии, в которых сообщение IAM содержит только часть (одну или несколько первых цифр) номера вызываемого абонента, а иногда не содержит цифр номера вообще. В таком случае оставшиеся недостающие цифры номера передаются в последующих сообщениях SAM.

При получении сообщения IAM с неполным номером канальное окончсание SS7 проверяет, есть ли в номере хотя бы один символ. Если номер пуст, в речевой канал передается акустический сигнал готовности к набору номера (dialtone). После этого канальное окончание переходит в состояние Dialing и ожидает сообщение SAM.

При получении от вызывающего абонента сообщений SAM содержащиеся в них символы номера вызываемого абонента добавляются к ранее принятым. Сигнал готовности, если был включен, отключается. Ожидание цифр номера заканчивается либо при получении очередного сообщения SAM с признаком окончания набора номера (символ '#'), либо если в течение 6 секунд не поступило ни одного нового символа. По окончании приема номера канальное окончание передает в сторону вызывающего абонента сообщение ACM, после чего формирует и передает в сеть сообщение INVITE. Далее процесс установки соединения ничем не отличается от приведенного выше базового сценария.

Пример сценария с overlap dialing:

Замена номера вызывающего абонента

При получении вызова со стороны TDM в принятом сообщении ACM, как правило, содержится номер вызывающего абонента. Встречаются ситуации, когда номер вызываемого абонента приходит не в том формате, который требуется на стороне IP (например приходит только зоновый номер без кода страны и города). Функция замены по регулярному выражению номера вызывающего абонента, приходящего со стороны TDM, позволяет исправить эту ситуацию. Для решения проблемы в конфигурации канального окончания SS7 имеется конфигурационный параметр "Преобразование Caller-ID", позволяющий выполнять замену номера по регулярному выражению. Значение параметра задается в виде строки формата /<regexp>/<replacement>, где <regexp> - регулярное выражение, на совпадение с которым проверяется полученный номер, <replacement> - строка, которой заменяется номер в случае совпадения с регулярным выражением. В замене могут использоваться группы из регулярного выражения, которые подставляются с помощью комбинаций \1, \2 и т.д. Например если установить параметру "Преобразование Caller-ID" значение /^(.{7})$/7342\1, канальное окончание SS7 будет добавлять к принятому семизначному номеру префикс "7342".

Отбой соединения

Отбой соединения в направлении сети TDM выполняется передачей сообщения REL на любом этапе соединения. После передачи солобщения REL канальное окончание SS7 переходит в состояние Release и ожидает получения ответного сообщения RLC. После получения сообщения RLC канальное окончание SS7 переходит в исходное состояние (Idle). Инициатором отбоя может как вызывающая, так и вызываемая сторона.

При получении из сети TDM сообщения REL канальное окончание SS7 передает в сеть IP сообщения BYE, CANCEL или ответ с неуспешным кодом завершения в зависимости от текущего состояния траззакции SIP. В ответ на получение REL в сеть TDM передается сообщение RLC, после чего каналдьное окончание SS7 переходит в исходное состояние (Idle).

Примеры сценариев отбоя на разных этапах соединения:

Контроль целостности разговорной цепи (COT)

Так как в системе SS7 разговорные и сигнальные каналы могут проходить различными путями, в результате ошибок в конфигурации сети или возникновения каких-либо неисправностей возможны ситуации, когда выбранный для телефонного соединения разговорный канал неисправен (не транслирует речь абонентов между двумя коммутационными станциями (SSP)), что не мешает станциям успешно установить соединение, обмениваясь сообщениями по сигнальной сети. Для предотвращения таких ситуаций служит процедура контроля целостности цепи (Continuity Check, COT). Контроль заключается в том, что на одной стороне канала (стороне A) в него подается тональная частота, на другой стороне (стороне B) либо подключается шлейф разговорного канала, либо подключается приемник тональной частоты, и при ее обнаружении в канал в обратном направлении передается эта же или другая тональная частота. Сторона A, приняв тональную частоту из канала, делает вывод об исправности разговорного канала.

Конфигурационный параметр "Continuity check %" канального окончания SS7 определяет приблизительный процент исходящих (в направление скети TDM) вызовов, при которых выполняется контроль целостности цепи: например при значении параметра 0 контроль не выполняется никогда, при значении 100 контроль выполняется при каждом вызове, при значении 10 - при каждом десятом вызове и т.п.

При выполнении вызова с контролем исправности разговорной цепи канальное окончание SS7 исходящей станции (A) устанавливает в поле Nature of Connection Indicator передаваемого сообщения IAM флаг "Continuity Check Required", начинает передавать в разговорный канал тональную частоту 1780 или 2010 Гц (значение передаваемой частоты определяется конфигурационным параметром "Continuity check probe Tx"), переходит в состояние COT и ожидает приема из разговорного канала ответной тональнйо частоты (1780 Гц или 2010 Гц).

Канальное окончание SS7 входящей станции (B), получив сообщение IAM с установленным флагом "Continuity Check Required", подключает к разговорному каналу приемник тональной частоты и переходит в состояние Loopback. При получении из разговорного канала ожидаемой тональной частоты канальное окончание SS7 начинает генерировать в канал ту же самую или альтернативную частоту. Принимаемые и передаваемые частоты определяются конфигурационным параметром "Continuity check loopback".

В случае успешного приема станцией A из разговорного канала ожидаемой тональной частоты она отключает свой передатчик, передает станции B сообщение COT с признаком успешного выполнения теста и переходит в состояние Proceeding. Станция B, получив сообщение COT с признаком успешного выполнения теста, отключает от разговорного канала приемник и передатчик тональных частот, переходит в состояние Calling и продолжает обработку вызова обычным образом. Далее показан пример сценария вызова с успешным контролем разговорной цепи.

В случае, если станция A в течение 2 секунд с момента передачи тонального сигнала не получила обратный сигнал, она отключает генератор, передает станции B сообщение COT с индикацией неуспешной проверки, возвращает вызывающей стороне ответное сообщение SIP с неуспешным кодом и переходит в состояние COT fail, предотвращая таким образом последующие занятия неисправного разговорного канала. Станция B, получив сообщение COT с индикацией неуспешной проверки, отключает приемник от канала и также переходит в состояние COT fail.

Через 5 секунд после неуспешного завершения проверки разговорной цепи станция A инициирует повторную проверку, для чего передает станции B сообщение CCR, подключает к каналу генератор, переходит в состояние COT и ожидает обратной тональной частоты. Станция B, получив сообщение CCR, подключает к каналу приемник частоты и переходит в состояние Loopback. Последующая проверка проходит точно таким же образом, как и первая (после сообщения IAM). В случае неуспеха описанные повторные проверки целостности разговорной цепи повторяются каждые 2 минуты до тех пор, пока очередная проверка не завершится успешно. При успешном завершении повторной проверки станция A передает станции B сообщение COT с индикацией успешной проверки цепи. Получив это сообщение, станция B передает станции A сообщение REL и переходит в состояние Release. Станция A, получив сообщение REL, передает сообщение RLC и переходит в исходное состояние (Idle). Станция B, получив сообщение RLC, также переходит в исходное состояние (Idle). С этого омента разговорный канал снова способен обслуживать вызовы.

Ниже показан пример сценария с неуспешными проверками разгорорного канала.

Параметры конфигурации

Состояния

Idle
Исходное состояние (канал свободен).
Proceeding
Получено INVITE, отправлено IAM, ожидается ответ.
Dialing
Получено сообщение IAM с неполным номером, ожидаются сообщения SAM с дополнительными цифрами номера.
Calling
Получено IAM, отправлено INVITE, ожидается ответ.
Connected
Установлено соединение, ведется разговор.
Release
Отправлено REL или RSC, ожидается RLC.
Loopback
Выполняется входящий тест разговорной цепи. Получено CCR или IAM с запросом проверки целостности разговорной цепи, подключен шлейф разговорного канала, ожидается COT с результатом теста.
COT
Выполняется исходящий тест разговорной цепи. Отправлено CCR или IAM с запросом проверки целостности разговорной цепи, подключен генератор, ожидается прием тестовой частоты.
COT fail
Разговорная цепь неисправна: последний тест COT завершился неуспешно.
RBlocked
Удаленная блокировка канала.

Упрощенная диаграмма состояний

Attachments (4)

Download all attachments as: .zip

Note: See TracWiki for help on using the wiki.