[[PageOutline(2-5,Содержание:)]] [[span(style=color: #FF0000, Статья находится в стадии создания! Представленная информация может быть неполной и/или неточной.)]] = Подсистема SS7 = == Структура == Плата VE-01 (VE-02) содержит до четырех независимых инстанций SS7 SSP (Service Switching Point). Подсистема SS7 плат VE-01/VE-02 испльзует два типа канальных окончаний - сигнальные линки (SS7lnk) и разговорные каналы (SS7). Каждое из этих канальных окончаний "привязано" к одной из инстанций SSP. {{{#!plantuml @startuml cloud "Каналы сигнализации" as NET1 cloud "Каналы сигнализации" as NET2 cloud "Речевые каналы" as CC1 cloud "Речевые каналы" as CC2 package "VE-01 (VE-02)" { package "SSP3" { agent "..." } package "SSP2" { agent "..." as u2 } package "SSP0" { agent SS7lnk as L1 agent SS7lnk as L2 agent SS7 as C1 agent SS7 as C2 agent SS7 as C3 agent SS7 as C4 } package "SSP1" { agent SS7lnk as L3 agent SS7lnk as L4 agent SS7 as C5 agent SS7 as C6 agent SS7 as C7 agent SS7 as C8 } } L1 <---> NET1 L2 <---> NET1 L3 <---> NET2 L4 <---> NET2 C1 <-[#blue]--> CC1 C2 <-[#blue]--> CC1 C3 <-[#blue]--> CC1 C4 <-[#blue]--> CC1 C5 <-[#blue]--> CC2 C6 <-[#blue]--> CC2 C7 <-[#blue]--> CC2 C8 <-[#blue]--> CC2 @enduml }}} Канальные окончания SS7lnk представляют собой сигнальные линки MTP2 и выполняют функции передачи сигнальных и управляющих сообщений. Канальные окончания SS7 представляют собой разговорные каналы для передачи речевой информации. Шлюз платы VE-01 (VE-02) обеспечивает преобразование сигнализации SS7 ISUP на стороне TDM в сигнализацию SIP на стороне IP и обратно, преобразование данных речевых каналов TDM и потоки RTP и обратно. Пример сети с полно-ассоциированными линками (непосредственное подключение сигнальных каналов к удаленной станции): {{{#!plantuml @startuml package SSP0 { agent SS7lnk as L1 agent SS7lnk as L2 collections SS7 } node АТС L1 <---> АТС L2 <---> АТС SS7 <=[#blue]==> АТС @enduml }}} Пример сети с квази-ассоциированными линками (сигнальные каналы подключены серез STP). {{{#!plantuml @startuml package SSP0 { agent SS7lnk as L1 agent SS7lnk as L2 collections SS7 } node АТС node STP1 node STP2 L1 <---> STP1 L2 <---> STP2 STP1 <-> STP2 STP1 <--> АТС STP2 <--> АТС SS7 <=[#blue]=> АТС @enduml }}} == Описание работы == === Установка соединения с сигнальной сетью === Соединение с сигнальной сетью (сигнальные линки) выполняется канальными окончаниями SS7lnk. Исходное состояние канального окончания - состояние `Down`. При успешной установке соединения MTP2 по сигнальному каналу с удаленным SP канальное окончание переходит в состояние `Up`. После этого SP обмениваются сообщениями STD_TEST и TRA. === Прием вызова со стороны сети IP === Прием телефонных вызовов со стороны сети IP выполняют канальные окончания SS7. Прием вызовов выполняется только на втором проходе поиска. Если канальное окончание SS7 свободно (то есть находится в состоянии `Idle`), и SSP, к которому привязано канальное окончание, успешно подключился к сигнальной сети (находится в состоянии Up), канальное окончание SS7 выполняет проверку на совпадение вызванного номера (имени пользователя) с регулярным выражением, установленным конфигурационным параметром "Рег. выражение вызова". Если обнаружено совпадение, проверяется наличие общего поддерживаемого аудиокодека для медиапотока RTP. Если общий поддерживаемый аудиокодек найден, канальное окончание SS7 обслуживает данный вызов (формирует и отправляет в сеть TDM сообщение IAM). ==== Базовый сценарий вызова ==== Базовый сценарий вызова со стороны IP приведен на следующий диаграмме: {{{#!PlantUml @startuml title Базовый сценарий вызова со стороны сети IP skinparam ParticipantPadding 80 skinparam sequenceMessageAlign center participant "Абонент А (IP)" as A participant "окончание SS7" as B participant "Абонент Б (TDM)" as C A -> B: INVITE B -> A: 100 Trying B -> C: IAM C -> B: ACM (вызываемый свободен) note right: вызываемый абонент слышит звонок B -> A: 180 Ringing ... note over C: абонент ответил на вызов C -> B: ANM B -> A: 200 OK A <-[#0000ff]-> B: //медиапоток// A -> B: ACK note over A, C: абоненты А и Б ведут разговор @enduml }}} При получении сообщения 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). Таким образом, вызывающий абонент имеет возможность слышать речевые анонсы и/или другие акустические информационные сигналы, передаваемые в речевом канале. Пример сценария вызова с активацией медиапотока до ответа вызываемого абонента: {{{#!PlantUml @startuml title Сценарий вызова со стороны сети IP c early-media skinparam ParticipantPadding 80 skinparam sequenceMessageAlign center participant "Абонент А (IP)" as A participant "окончание SS7" as B participant "Абонент Б (TDM)" as C A -> B: INVITE B -> A: 100 Trying B -> C: IAM C -> B: CPG (event="Inband info") B -> A: 183 Session Progress A <-[#0000ff]-> B: //медиапоток// note right of C: вызываемый абонент слышит звонок C o-[#gray]> A: // КПВ// ... note over C: абонент ответил на вызов C -> B: ANM B -> A: 200 OK A -> B: ACK note over A, C: абоненты А и Б ведут разговор @enduml }}} В данном примере поле event сообщения GPC имеет значение "Inband info", указывающее на наличие данных в речевом канале. При его получении канальное окончание SS7 сформировало сообщение SDP в теле ответа "183 Session Progress" и активировало медиапоток, дав возможность вызывающему абоненту прослушивать акустический сигнал "Контроль посылки вызова" (КПВ), сформированный оборудованием вызываемой стороны. === Вызов в сторону сети IP === ==== Базовый сценарий вызова ==== При получении сообщения IAM плата VE-01 (VE-02) выполняет ряд проверок для определения возможности обслужить поступивший вызов, основные из которых перечислены ниже: 1. Выполняется поиск разговорного канала (канального окончания SS7) с указанным в сообщении кодом CIC. Если канал не найден, сообщение игнорируется. 1. Проверяется находится ли найденное канальное окончание SS7 в исходном состоянии. Если состояние отлично от `Idle` и `RBlocked` (см. ниже об удаленной блокировке канала), сообщение игнорируется. 1. Проверяется значение поля Transmission Medium Requirements. Если его значение отлично от `speech` (и `3.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`. Пример сценария вызова приведен ниже: {{{#!PlantUml @startuml title Базовый сценарий вызова со стороны сети TDM skinparam ParticipantPadding 80 skinparam sequenceMessageAlign center participant "Абонент А (TDM)" as A participant "окончание SS7" as B participant "Абонент Б (IP)" as C A -> B: IAM B -> C: INVITE C -> B: 100 Trying C -> B: 180 Ringing note right: вызываемый абонент слышит звонок B -> A: ACM (status="Subscriver free") B o-[#blue]> A: //КПВ// ... note over C: абонент ответил на вызов C -> B: 200 OK B <-[#0000ff]-> C: //медиапоток// B -> C: ACK B -> A: ANM note over A, C: абоненты А и Б ведут разговор @enduml }}} ==== Сценарий вызова с overlap dialing (только ITU) ==== Рассмотренный выше сценарий предполагал, что сообщение IAM содержит в себе полный номер вызываемого абонента (En Bloc Dialing) и, таким образом, имеющейся в нем информации достаточно для трансляции вызова в SIP сообщение INVITE. В варианте протокола ITU возможны сценарии, в которых сообщение IAM содержит только часть (одну или несколько первых цифр) номера вызываемого абонента, а иногда не содержит цифр номера вообще. В таком случае оставшиеся недостающие цифры номера передаются в последующих сообщениях SAM. При получении сообщения IAM с неполным номером канальное окончание SS7 проверяет, есть ли в номере хотя бы один символ. Если номер пуст, в речевой канал передается акустический сигнал готовности к набору номера (dialtone). После этого канальное окончание переходит в состояние `Dialing` и ожидает сообщение SAM. При получении от вызывающего абонента сообщений SAM содержащиеся в них символы номера вызываемого абонента добавляются к ранее принятым. Сигнал готовности, если был включен, отключается. Ожидание цифр номера заканчивается либо при получении очередного сообщения SAM с признаком окончания набора номера (символ '#'), либо если в течение 6 секунд не поступило ни одного нового символа. По окончании приема номера канальное окончание передает в сторону вызывающего абонента сообщение ACM, после чего формирует и передает в сеть сообщение INVITE. Далее процесс установки соединения ничем не отличается от приведенного выше базового сценария. Пример сценария с overlap dialing: {{{#!PlantUml @startuml title Cценарий вызова со стороны сети TDM с overlap dialing !pragma teoz true skinparam ParticipantPadding 80 skinparam sequenceMessageAlign center participant "Абонент А (TDM)" as A participant "окончание SS7" as B participant "Абонент Б (IP)" as C A -> B: IAM (Called Party Number="") B o-[#blue]> A: dialtone A -> B: SAM (Called Party Number="1") A <-[#blue]x B: dialtone off A -> B: SAM (Called Party Number="2") A -> B: SAM (Called Party Number="3") A -> B: SAM (Called Party Number="4") {start} A -> B: SAM (Called Party Number="5") ||35|| {end} B -> A: ACM . {start} <-> {end} : 6 секунд B -> C: INVITE "12345" C -> B: 100 Trying C -> B: 180 Ringing note right: вызываемый абонент слышит звонок B -> A: CPG B o-[#blue]> A: //КПВ// ... note over C: абонент ответил на вызов C -> B: 200 OK B <-[#0000ff]-> C: //медиапоток// B -> C: ACK B -> A: ANM note over A, C: абоненты А и Б ведут разговор @enduml }}} ==== Замена номера вызывающего абонента ==== При получении вызова со стороны TDM в принятом сообщении ACM, как правило, содержится номер вызывающего абонента. Встречаются ситуации, когда номер вызываемого абонента приходит не в том формате, который требуется на стороне IP (например приходит только зоновый номер без кода страны и города). Функция замены по регулярному выражению номера вызывающего абонента, приходящего со стороны TDM, позволяет исправить эту ситуацию. Для решения проблемы в конфигурации канального окончания SS7 имеется конфигурационный параметр "Преобразование Caller-ID", позволяющий выполнять замену номера по регулярному выражению. Значение параметра задается в виде строки формата `//`, где `` - регулярное выражение, на совпадение с которым проверяется полученный номер, `` - строка, которой заменяется номер в случае совпадения с регулярным выражением. В замене могут использоваться группы из регулярного выражения, которые подставляются с помощью комбинаций \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`). Примеры сценариев отбоя на разных этапах соединения: {{{#!PlantUml @startuml title Сценарий неуспешного вызова (отбой вызываемой стороной) skinparam ParticipantPadding 80 skinparam sequenceMessageAlign center participant "Абонент А (TDM)" as A participant "окончание SS7" as B participant "Абонент Б (IP)" as C A -> B: IAM B -> C: INVITE C -> B: 100 Trying C -> B: 486 Busy Here B -> C: ACK B -> A: REL A -> B: RLC @enduml }}} {{{#!PlantUml @startuml title Сценарий неуспешного вызова (отбой вызывающей стороной) skinparam ParticipantPadding 80 skinparam sequenceMessageAlign center participant "Абонент А (TDM)" as A participant "окончание SS7" as B participant "Абонент Б (IP)" as C A -> B: IAM B -> C: INVITE C -> B: 100 Trying ... A -> B: REL B -> A: RLC B -> C: CANCEL C -> B: 200 OK (CANCEL) C -> B: 487 Request Terminated (INVITE) B -> C: ACK @enduml }}} {{{#!PlantUml @startuml title Отбой успешно установленного соединения со стороны TDM skinparam ParticipantPadding 80 skinparam sequenceMessageAlign center participant "Абонент А (TDM)" as A participant "окончание SS7" as B participant "Абонент Б (IP)" as C note over A, C: абоненты А и Б ведут разговор A -> B: REL B -> A: RLC B -> C: BYE C -> B: 200 OK @enduml }}} {{{#!PlantUml @startuml title Отбой успешно установленного соединения со стороны IP skinparam ParticipantPadding 80 skinparam sequenceMessageAlign center participant "Абонент А (TDM)" as A participant "окончание SS7" as B participant "Абонент Б (IP)" as C note over A, C: абоненты А и Б ведут разговор C -> B: BYE B -> C: 200 OK B -> A: REL A -> B: RLC @enduml }}} === Контроль целостности разговорной цепи (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 и продолжает обработку вызова обычным образом. Далее показан пример сценария вызова с успешным контролем разговорной цепи. {{{#!PlantUml @startuml title Сценарий вызова с контролем разговорной цепи skinparam ParticipantPadding 80 skinparam sequenceMessageAlign center A -> B: IAM (Continuity Check Required) A -[#blue]> B: //2010 Гц// B -[#blue]> A: //1780 Гц// A -> B: COT (success) B ->]: INVITE B <-]: 180 Ringing B -> A: ACM B <-]: 200 OK B -> A: ANM note over A, B: абоненты А и Б ведут разговор @enduml }}} В случае, если станция 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`). С этого момента разговорный канал снова способен обслуживать вызовы. Ниже показан пример сценария с неуспешными проверками разгорорного канала. {{{#!PlantUml @startuml title Сценарий неуспешного контроля разговорной цепи !pragma teoz true skinparam ParticipantPadding 80 skinparam sequenceMessageAlign center A -> B: IAM (Continuity Check Required) {c1} A -[#blue]>x B: //2010 Гц// ||30|| {c2} A -> B: COT (failed) {c1} <-> {c2}: 2 сек. ||45|| {c3} A -> B: CCR . {c33} A -[#blue]>x B: //2010 Гц// {c2} <-> {c3}: 5 сек. ||30|| {c4} A -> B: COT (failed) {c33} <-> {c4}: 2 сек. ||45|| {c5} A -> B: CCR . A -[#blue]> B: //2010 Гц// B -[#blue]> A: //1780 Гц// {c4} <-> {c5}: 2 мин. A -> B: COT (success) B -> A: REL A -> B: RLC @enduml }}} == Параметры конфигурации == == Состояния == 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:: Удаленная блокировка канала. === Упрощенная диаграмма состояний === {{{#!plantuml @startuml title упрощенная диаграмма состояний канального окончания SS7 Idle: Исходное состояние\n(канал свободен) Proceeding: Принят INVITE Dialing: Ожидание цифр номера Calling: Послан INVITE,\nожидается ответ Connected: идет разговор Release: ожидается RLC Loopback: ожидается COT COT: ожидается тестовая\nчастота state "COT fail" as fail: канал неисправен fail --> COT: CCR Idle --> Dialing: принято IAM с\nнеполным номером Idle --> Calling: принято IAM с\nполным номером Idle --> COT: принято IAM COT --> Proceeding: тест успешен COT --> fail: тест неуспешен Idle --> Loopback: получено CCR или\nIAM с COT Loopback --> Idle: получено REL Loopback --> fail: получено COT\nс test failed Loopback --> Calling: получено COT\nс test success Loopback --> Dialing: получено COT\nс test success Dialing --> Dialing: принято SAM Dialing --> Calling: таймаут набора Dialing --> Calling: принято SAM с\nполным номером Calling --> Connected: принято 200 OK Calling --> Release: принято 486 Busy Here Calling --> Idle: принято REL Connected --> Release: принято BYE Connected --> Idle: принято REL Release --> Idle: принято RLC Idle --> Proceeding: принято INVITE Proceeding --> Idle: принято REL Proceeding --> Connected: принято ANM/CON @enduml }}}