Понятия и определения

  • SIP-транк — представляет собой направление, работающее по протоколу SIP/SIP-Т/SIP-I/SIP-Q.
  • Контакт — точка подключения транка;
  • Форкинг — разветвление одного входящего вызова на несколько исходящих, используется в регистрации нескольких терминалов абонента под одним номером.
  • Сокет — порт SIP-сигнализации, открытый на определенном IP-адресе.

Интерфейсы SIP-адаптера

Введение

В данном разделе приводится общая информация об интерфейсах SIP-адаптера ECSS-10.

Внутренний интерфейс SIP-адаптера (далее "интерфейс") это логическая связка следующих параметров (структура), описывающая точку подключения внешнего соединения:

  • локальный IP-адрес и порт (на стороне SIP-адаптера);
  • удаленный IP-адрес и порт (на взаимодействующей стороне);
  • описание SIP-клиента: имя SIP-абонента и/или имя виртуальной АТС.

Подробное описание использования адресов и портов в системе ECSS-10 приведено в разделе Описание работы SIP-адаптера.

В системе ECSS-10 существует два типа интерфейсов SIP-адаптера:

  • SIP-транк (далее транк) — транковый интерфейс;
  • абонентская линия — интерфейс пользователя.

Описание SIP-интерфейса типа "Транк"

Общее описание

Транк описывается параметрами, которые используются для подключения и обслуживания соединения со встречной АТС (SIP-шлюзом):

  • IP или доменное имя узла;
  • номер порта;
  • используемый протокол (UDP или TCP), по умолчанию используется системная настройка (режим udp_prefer).

Как правило, точка подключения транка на удаленной стороне задается статически: IP-адрес или доменное имя встречного узла. 
Возможно динамическое подключение транка. В этом случае удаленная сторона отправляет запрос регистрации своего идентификатора ресурса ("имя абонента"@"доменное имя"). Зарегистрированный в этом случае контакт будет описывать параметры подключения.

Типы динамической регистрации:

  • "Proxy" тип регистрации подразумевает регистрацию с использованием одного аккаунта. При запросе данных аутентификации для всех вызовов используется один и тот же логин и пароль.
  • "User" тип регистрации подразумевает регистрацию с использованием разных аккаунтов. Для каждого абонента встречного шлюза должен быть заведен отдельный аккаунт (логин и пароль).

В системе ECSS-10 release 3.14 реализован "Proxy" тип регистрации. Регистрация выполняется с одним аккаунтом. В отличие от регистрации типа "User", операторская регистрация ограничена только одним контактом, режимы форкинга для транка не предусмотрены, то есть при регистрации нового контакта предыдущий будет удален.

Также, в системе предусмотрен встречный режим — транк отправляет удаленной стороне запросы регистрации с точкой подключения адаптера.

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

Емкость линии SIP-транка

SIP-транк можно считать аналогом Е1 PRI. SIP-транк это виртуальный канал между оператором и клиентом, работающий поверх сети Интернет. В отличие от канала E1 SIP-транк может иметь произвольную емкость линии, ограниченную только настройками SIP-адаптера ECSS-10.

В SIP-адаптере ECSS-10 ограничение емкости линии SIP-транка является обязательным, для чего предварительно создается группа каналов. При этом верхний предел для количества одновременных занятий (виртуальных каналов) не ограничен и определяется оператором, исходя из требований определенного направления и имеющихся ресурсов. 
Ограничение необходимо из-за идентификации каналов. Используется по аналогии с количеством одновременных соединений по одному транку.

По умолчанию установлено ограничение 256. Это значение может быть изменено для любого транка. Для смены значения , используется команда:

/domain/<DOMAIN>/trunk/set <TRUNK_GROUP> <TRUNK> bandwidth\total <NEW_LIMIT>

где

  • <DOMAIN> — имя виртуальной АТС;
  • <TRUNK_GROUP> — Транковая группа;
  • <TRUNK> — Имя транка;
  • <NEW_LIMIT> — количество каналов в SIP-транке.

Контроль направления

Для контроля доступности направления используется процедура периодической передачи запросов OPTIONS, которая настраивается в параметрах транка.

При отсутствии ответа на запрос соответствующий интерфейс переводится в неактивное состояние, что позволяет не отправлять запросы на установление соединения в интерфейс до тех пор, пока связь в данном направлении не восстановится — на запросы OPTIONS вновь не начнут поступать ответы. Данный функционал позволяет сэкономить ресурсы SIP-адаптера, если направление недоступно.

В целях проведения регламентных или восстановительных работ транк может быть заблокирован принудительно оператором. В этом случае и входящая, и исходящая связь по заблокированному транку будут запрещены.

Подробное описание приведено в разделе Команды управления SIP-транками.

Абонентская линия

Абонентская линия описывается параметрами, которые используются для подключения и обслуживания соединения с SIP-абонентом.

Точка подключения (контакт или контакты) присылается терминалом пользователя.

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

Режимы форкинга абонентской линии:

  • all-contacts — запрос на установление соединения (INVITE) отправляется одновременно на все зарегистрированные контакты;
  • find-me-with-q — запрос на установление соединения (INVITE) отправляется одновременно на все контакты с наивысшем приоритетом одного значения, если ни с одного контакта ответа нет, то выполняется одновременная отправка INVITE на все контакты со следующим по приоритету значением и так далее;
  • find-me-one-by-one — запрос на установление соединения (INVITE) отправляется на первый по списку контакт, если ответа нет, то отправляется следующему по списку и так далее;
  • disable — форкинг выключен. Для одного абонентского номера регистрируется один контакт, при попытке регистрации нового контакта текущий будет изменен на новый.

Режим форкинга может быть назначен абоненту или группе.

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

При форкинге событием перехода к следующему контакту является недоступность порта на вызываемой стороне или истечение заданного для виртуальной АТС тайм-аута, который задается командой:

/domain/<DOMAIN>/timers/sip/set find_me <TIMEOUT_IN_SECONDS>

Запросы на установление соединения (INVITE), на которые от клиентской стороны получены неуспешные финальные ответы, считаются успешно доставленными. В таком случае переключение не происходит, на исходящую сторону транслируется соответствующий неуспешный финальный ответ.

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

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

  • статические абоненты — в системе создаются персональные записи по абоненту: параметры интерфейса (SIP-подключения) и параметры алиаса (маршрутизация, услуги и другое). Также в системе хранятся данные аутентификации и тарификации по данному абоненту.
  • динамические абоненты — в системе создается только пул заданного размера, содержащий шаблон параметров интерфейса. При регистрации такого абонента SIP-адаптер выполняет запрос авторизации/аутентификации на соответствующий RADIUS-сервер. При успешном ответе сервера для данного SIP-абонента создаются интерфейс и алиас, существующие в течение времени регистрации абонента в системе. По истечении времени регистрации абонента (всех его контактов) или при получении от него запроса разрегистрации записи о соответствующем ему интерфейсе и алиасе удаляются. Данные аутентификации, параметры обслуживания и прочие настройки по таким абонентам хранятся на RADIUS-сервере. В системе ECSS-10 для динамических абонентов могут храниться лишь общие шаблонные настройки группы.
    Подробное описание приведено в разделе Настройка динамических абонентов и системы Radius.

Работа SIP-адаптера с сетью

Порты SIP-сигнализации

Работа параметров "node_ip" и "listen_ports"

Начиная с версии 3.4 для каждой виртуальной АТС (далее ВАТС) возможно использование более одного порта и более одного IP-адреса для SIP-сигнализации (сокета). В связи с необходимостью объявления адресов для поддержки резервирования в ECSS-10 реализована связка имен нод и IP-адресов, названых ip_set.

  • ip-set — это две или более (устанавливается по числу нод) связки IP-адресов и резервирующих друг друга нод.

Для каждой ВАТС должны быть объявлены следующие параметры:

  • listen_ports — список транспортных портов (UDP/TCP), минимальные требования один порт;
  • node_ip — сетевой ресурс виртуальной АТС. Объединяет связки "ip_set", которые будут использоваться одной виртуальной АТС. Как минимум должен включать одну связку "ip_set".

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

Одновременная работа с локальными и публичными адресами, не используя SBC или NAT, не рекомендуется.

Пример:

  • Кластер SIP-адаптера состоит из двух нод: sip1@ecss1 и sip1@ecss2.
  • На нодах открыты виртуальные адреса (резерв keepalive): 
    sip1@ecss1: 192.168.10.1 и 10.10.10.1
    sip1@ecss2: 192.168.10.2 и 10.10.10.2

Каждая нода работает со своими адресами. Если одна из нод выйдет из работы, то адреса отсутствующей ноды будут переданы для работы на активную ноду. Для корректной работы резервирования (с привязкой ВАТС и интерфейсов пользователей или транков к определенным подсетям) должны быть настроены следующие связки адресов:

admin@[mycelium1@ecss1#ECSS 010145]:/$ cluster/adapter/sip1/sip/network/set ip_set set.pub node-ip node = sip1@ecss1 ip = 192.168.10.1 
admin@[mycelium1@ecss1#ECSS 010145]:/$ cluster/adapter/sip1/sip/network/set ip_set set.pub node-ip node = sip1@ecss2 ip = 192.168.10.2 
admin@[mycelium1@ecss1#ECSS 010145]:/$ cluster/adapter/sip1/sip/network/set ip_set set.pub listen-ports list = [5060]
admin@[mycelium1@ecss1#ECSS 010145]:/$ cluster/adapter/sip1/sip/network/set ip_set set.loc node-ip node = sip1@ecss1 ip = 10.10.10.1 
admin@[mycelium1@ecss1#ECSS 010145]:/$ cluster/adapter/sip1/sip/network/set ip_set set.loc node-ip node = sip1@ecss2 ip = 10.10.10.2
admin@[mycelium1@ecss1#ECSS 010145]:/$ cluster/adapter/sip1/sip/network/set ip_set set.loc listen-ports list = [5060,5062] 
admin@[mycelium1@ecss1#ECSS 010145]:/$ domain/test.arko/sip/network/set ip_set [set.pub, set.loc] 
admin@[mycelium1@ecss1#ECSS 010145]:/$ domain/test.arko/sip/ip-sets --complete                                                    
Executed on the sip1@ecss1
┌───────────┬──────────────────────────────────┐
│    pbx    │             ip-sets              │
├───────────┼──────────────────────────────────┤
│ test.arko │ set.pub: 5060                    │
│           │ set.pub: sip1@ecss1 192.168.10.1 │
│           │ set.pub: sip1@ecss2 192.168.10.2 │
│           │ set.pub: dscp 0                  │
│           │ set.loc: 5060, 5062              │
│           │ set.loc: sip1@ecss1 10.10.10.1   │
│           │ set.loc: sip1@ecss2 10.10.10.2   │
│           │ set.loc: dscp 0                  │
└───────────┴──────────────────────────────────┘
┌─────────────┐
│ elements: 2 │
└─────────────┘

Имена для связки выбираются произвольно. Каждая связка описывает пару (при двух нодах в кластере) адресов одной подсети.

Кроме того, должен быть назначен список портов для прослушивания, минимальные требования — один порт. Порт по умолчанию — 5060.По умолчанию параметр "listen_ports" назначен как единственный 5060. При необходимости можно изменить номер и количество портов для прослушивания сигнализации SIP. В примере выше для ip_set set.pub был выставлен порт 5060, для ip_set set.loc была выставлена пара портов 5060 и 5062.
На объявленных портах в зависимости от режима работы открываются сокеты (для режима udp_preffer):

  • udp — используется для входящих и исходящих соединений;
  • tcp — используется для входящих соединений.

Использование "ip-set" и "listen_ports" SIP-интерфейсами

SIP-транки для приема входящих и совершения исходящих вызовов используют порт из списка "listen_ports", настроенный в параметрах транка. Для SIP-абонентов также используется порт из списка "listen_ports" для приема входящих и совершения исходящих вызовов, но используется только тот порт, через который была осуществлена регистрация. В настройках SIP-абонента дополнительно порт настраивать не нужно.

Аналогично работает привязка "ip-set" — для транков декларативно, для пользователей по сокету регистрации.

Использование портов

В системе установлено раздельное использование сокетов виртуальными АТС. В этом случае для каждой ВАТС должен быть назначен свой SIP-интерфейс — уникальные сочетания IP-адресов и портов. То есть возможно использование одного IP-адреса, но разных списков портов, или одинаковых портов, но на разных IP-адресах.

Возможности модификации и расширения сигнализации SIP

Описание

SIP-адаптер системы ECSS-10 относится к типу B2BUA. В таком случае вызов, установленный через ECSS-10, разбивается на два плеча: входящее для вызова и исходящее. Получается два участка обработки сигнализации, на каждом из которых SIP-адаптер ECSS-10 работает как независимый агент. Функции, описанные в данном разделе, позволяют определить специфичные заголовки SIP-сообщений, которые необходимо протранслировать в исходящее плечо. Трансляция заголовков может осуществляться без изменений либо с модификацией.

В системе реализовано:

  • транзит всего RURI, транзит только хост части RURI, транзит заголовков;
  • исключение или модификация принятых заголовков;
  • передача дополнительной информации о событиях в течение диалога.

Транзитные функции

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

Транзит параметров для SIP-транков настраивается командой:

domain/<DOMAIN>/trunk/sip/set <GROUP_NAME> <IFACE_NAME> sip-transit set <PARAMETERS>

Транзит параметров для SIP-абонентов настраивается командой:

domain/<DOMAIN>/sip/user/set *|<GROUP_NAME> [*|<IFACE_NAME>] sip-transit set <PARAMETERS>

где

  • <GROUP_NAME> — имя группы транков;
  • <DOMAIN> — имя домена;
  • <IFACE_NAME> — имя интерфейса транка или абонента;
  • <PARAMETERS> — настраиваемый параметр для транзита SIP-абонентов.
    • headers = [<HEADER1>, <HEADER2>, ...],
      • <HEADER> — имя SIP-заголовка.

Транзит заголовков

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

Из списка будут исключены "Call-ID", "To", "From", "CSeq", которые не могут быть протранслированы, поскольку не должны дублироваться.
Для удаления правил транзита заголовков в команде вводится пустой список.

Примеры:

/domain/test.domain/trunk/sip/set sip.test SEA.A sip-transit set headers=[User-Agent, Subject]
/domain/test.domain/sip/user/set export 410@192.168.23.166 sip-transit set request_line = domain_name, headers = [User-Agent, Subject]
/domain/test.domain/sip/user/set export 410@192.168.23.166 sip-transit set headers = []

Удаление всех правил

Удаление всех правил транзита выполняется командой:

  • для SIP-транков:

/domain/<DOMAIN>/trunk/sip/set <GROUP_NAME> <IFACE_NAME> sip-transit clean

  • для SIP-абонентов:

/domain/<DOMAIN>/sip/user/set *|<GROUP_NAME> [*|<IFACE_NAME>] sip-transit clean

где

  • <GROUP_NAME> — имя группы транков;
  • <IFACE_NAME> — имя интерфейса транка или пользователя.

Команда удаляет все правила для режимов и транзита заголовков. Предусмотрено предупреждение с возможностью прервать выполнение команды.

Пример:

/domain/test.domain/trunk/sip/set tmip TMIP.Public sip-transit clean
[set] This command clears of all transit rules. Undo will be impossible.
Continue: yes/no ?> yes
Executed on the pa_sip@alex
complete

Модификации

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

Модификации могут быть настроены для SIP-транков и SIP-абонентов.

Модификации для SIP-транков настраиваются командой:

/domain/<DOMAIN>/trunk/sip/set <GROUP_NAME> <IFACE_NAME> sip-modifications <COMMAND>

Модификации для SIP-абонентов настраиваются командой:

/domain/<DOMAIN>/sip/user/set *|<GROUP_NAME> [*|<IFACE_NAME>] sip-modifications <COMMAND>

где

  • <GROUP_NAME> — имя группы транков;<IFACE_NAME> — имя интерфейса транка или абонента;
  • <COMMAND> — команда модификации:
    • clean <HEADER> — очистка правила модификации;
    • ignore headers = [<HEADER1>, <HEADER2, ...] — список заголовков, которые должны быть исключены;
    • set <PARAMETERS> — формирование правила модификации.

Исключение заголовков

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

sip-modifications ignore headers = [<HEADER1>, <HEADER2, ...]

где

  • <HEADERn> — имя заголовка, который не должен быть отправлен в исходящем сообщении.

Пример:

/domain/test.domain/trunk/sip/set tmip TMIP.Public sip-modifications ignore headers = [Accept, Category]
/domain/test.domain/sip/user/set export 410@192.168.23.166 sip-modifications ignore headers = [Accept, Category]
/domain/test.domain/sip/user/set export 410@192.168.23.166 sip-modifications ignore headers = []

Коррекция заголовков

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

sip-modifications set <PARAMETERS>

где

  • <PARAMETERS> — правила модификации:
    • header — имя заголовка, к которому будет применено правило, опциональный параметр;
    • add_start — текст, который будет добавлен в начале заголовка;
    • add_end — текст, который будет добавлен в конец заголовка;
    • add_new — текст, который будет добавлен в новый заголовок;
    • delete — текст, который должен быть удален, если имеются повторения указанного текста, то будет удалено только первое его упоминание;
    • insert — текст, вставляемый на место удаляемого, без параметра "delete" не используется.

Имя заголовка является обязательным условием. В правиле должен быть как минимум один параметр модификации. Разные правила модификации можно использовать одновременно.

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

Примеры:

в начале заголовка Contact будет добавлено имя "TEST CONTACT" с пробелом после кавычки:
/domain/test.domain/trunk/sip/set tmip TMIP.Public sip-modifications set header = contact, add_start = "TEST CONTACT " 

в конце заголовка Contact будет добавлен параметр "; test":
/domain/test.domain/trunk/sip/set tmip TMIP.Public sip-modifications set header = contact, add_end = ; test

будет создан новый заголовок Test-Header и в него будет добавлен параметр "text"
/domain/test.domain/trunk/sip/set tmip TMIP.Public sip-modifications set header = test-header, add_new = text

в заголовке Supported "replaces" будет заменено на "test":
/domain/test.domain/trunk/sip/set tmip TMIP.Public sip-modifications set header = supported, delete = replaces, insert = test

модификация удаляется, заголовок Supported будет передаваться без изменений:
/domain/test.domain/trunk/sip/set tmip TMIP.Public sip-modifications clean supported

Очистка всех правил

Удаление всех правил модификации выполняется командой:

sip-modifications clean <HEADER>

где

  • <HEADER> — имя заголовка, для которого нужно отменить модификации. При указании символа "*" будет выполнена очистка правил модификации для всех заголовков.

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

Пример:

/domain/test.domain/trunk/sip/set tmip TMIP.Public sip-modifications clean *
[set] This command clears of modification. Undo will be impossible.
Continue: yes/no ?> yes
Executed on the pa_sip@alex
complete

Дополнительная информация о событиях

Для предоставления возможности полноценного съема информации посредством зеркалирования трафика система позволяет отправлять в рамках SIP диалога информацию по сервисным событиям, таким как: постановка/снятие удержания, передача.
Событие отправляется в SIP-запросе INFO, Content-type: text/plain.
Текст сообщения может содержать следующую информацию:

  • Event=hold (вызов поставлен на удержание)
  • Еvent=hole (вызов снят с удержания)
  • Event=transfer (вызов переведен)

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

Команда:
send_services_info true|false

Пример:

cluster/adapter/sip1/sip/properties/set send_services_info true

Донабор DTMF после ответа вызываемого абонента

На адаптере реализована возможность автоматически осуществлять донабор после ответа вызываемого абонента. Донабор отделяется символом "w".

Например: 73832101001w3091, здесь 73832101001 уйдет в CDPN, а 3091 — будет после отправки 200-го ответа будет передано ядру последовательностью DTMF. Для ядра и стороны Б это никак не отличается от того, что эти цифры бы были набраны стороной А после ответа.