Описание rfc протокола sip [айти бубен]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При отсутствии ответа на запрос соответствующий интерфейс переводится в неактивное состояние, что позволяет не отправлять запросы на установление соединения в интерфейс до тех пор, пока связь в данном направлении не восстановится — на запросы OPTIONS вновь не начнут поступать ответы. Данный функционал позволяет сэкономить ресурсы 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.1sip1@ecss2: 192.168.10.2 и 10.10.10.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» — для транков декларативно, для пользователей по сокету регистрации.

Диагностика с помощью лога TRN

Точнее всего диагностировать данную проблему можно анализируя лог-журналы oktell или трассировку пакетов wireshark, но для этого необходимо иметь определенные знания sip-протокола. Воспользуйтесь сборщиком лог-журналов (подробнее в статье Сборка_лог-журналов) и соберите лог-журнал(hardware\sip\trn) за время +\- 10 минут с момента попытки перерегистрации. Также лог-журнал вы можете найти в папке \oktell\server\Log\Hardware\SIP\trn_.log.

В логе trn фиксируются все поступившие пакеты на сервер Oktell. Найдите пакет Register, который был отправлен провайдеру. По Call-ID пакета найдите ответ от провайдера, в котором может содержаться причина неисправности. С этой ошибкой вы также можете обратиться к провайдеру связи для разъяснения. Расшифровку SIP-ответов можете прочитать в статье SIP ответы и их значения.

Пример получения сервером Oktell пакета REGISTER с верными регистрационными данными.

Предыстория

Материал изначально готовился как доклад для asterconf 2020. Теперь постараюсь описать все более подробно в этой статье.

MIKOPBX — это бесплатная АТС с открытым исходным кодом на базе Asterisk 16. Год назад мы взялись за переход на PJSIP.

Основные причины:

PJSIP поддерживает «множественную регистрацию». На одном аккаунте можно без проблем регистрировать несколько конечных UAC
Корректная работа входящей маршрутизации при настройке регистрации нескольких учетных записей провайдера на одном адресе (IP+PORT)
PJSIP более гибок в настройке
chan_sip не развивается и объявлен deprecated в Asterisk 17

Далее опишу с какими сложностями мы столкнулись и какие выгоды получили.

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

Лично у меня подключены следующие устройства:

Аппаратный телефон на рабочем столе в офисе
Софтфон на ноутбуке
Софтфон на смартфоне

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

Модификации

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

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

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

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

где

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

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

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

где

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

Пример:

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

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

где

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

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

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

Примеры:

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

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

где

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

Пример:

Описание

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

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

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

Проблема на сервере

1. Допущена ошибка в настройке самого телефона или карте сети. Воспользуйтесь статьей .

1.1 Если при регистрации сервер на запрос REGISTER сервер отвечает 404 NOT FOUND , то обратитесь к статье 404 not found от сервера Oktell

2. Убедитесь, что на сервере Oktell антивирус или брандмауэр не блокирует работу. Либо отключите(подвергаете систему опасности), либо добавьте в исключение процессы.

\oktell\server\oktell.ServerService.exe
\oktell\server\oktell.HALRemoteApp.exe.

Чтобы добавить процессы в исключения брандмауэра перейдите в Панель управления -> Брандмауэр Windows -> Разрешить запуск программы или компонента через брандмауэр Windows -> Разрешить другую программу -> Обзор

3. Возможно, порт 5060 занят сторонним приложением. В командной строке выполните команду

netstat -anop udp

Определите PID у порта 5060(в примере PID-4976). В диспетчере задач определите какому процессу принадлежит порт 5060 по PID. Если такого столбца нет, выполните Вид\Выбрать столбцы\ИД процесса(PID).

Если данный PID соответствует oktell.HalRemoteApp.exe, то порт занял oktell. Иначе отключите приложение, которое заняло порт 5060, перезагрузите службу сервера, в клиентском приложении выполните Администрирование/Общие настройки/Управление сервером/Перезагрузить службу сервера). Проверьте повторно после перезагрузки службы какой процесс занял порт 5060.