Важные функции и инструменты, отличающие PJSIP от SIP (Фичи PJSIP)

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

Configuration Wizard

В первую очередь хотелось бы рассказать про такой мощную вещь, как PjSIP Configuration Wizard. Ранее, в статье «PJSIP. Глубокая настройка глобальных параметров» я упоминал, и бегло рассматривал её.

Итак, что же это такое? Configuration Wizard – это инструмент разработанный для того, чтобы упростить настройку стандартных сценариев в Астериске (начиная с версии 13.2, именно в ней визард был введен), таких как, например, настройка транка, учетной записи и прочих. Предоставляет большую гибкость и контроль, используя объекты chan_pjsip, он сводит работу к одному единственному объекту объекту «wizard».

В качестве примера рассмотрим создание транка без регистрации:

Результат будет одинаковым, но вот количество конфигов разнится. Также можно сказать, что визард создает стандартные объекты chan_pjsip вне нашего поля зрения (например, создание эндпоинта и aor с тем же именем что и визард или добавление outbound_auth в endpoint).

Вот еще несколько нюансов, на которые стоит обратить внимание при работе с configuration wizard:

• Между именами, созданными визардом, и именами объектов (endpoint, aor и проч.) из pjsip.conf, которые были созданы вручную, не будет конфликта (но только если у созданных визардом объектов присутствует параметр @pjsip_wizard=[имя визарда])
• Конечная точка и aor создаются для каждого wizard’a (с тем же именем, что и визард)
• Параметры передаются с помощью префиксов endpoint/ и aor/ и т.д.
• sends_auth вызывает создание объекта исходящей аутентификации (имя будет вида [имя визарда]-oauth)
• accepts_auth вызывает создание объекта входящей аутентификации (имя будет вида [имя визарда]-iauth)
• sends_registrations вызывает создание объекта исходящей регистрации для каждого удаленного хоста (имя будет вида [имя визарда]-reg-[n], где n от 0 и увеличивается для каждого удаленного хоста.)
• Если задан параметр accepts_registrations, стоит помнить то, что параметр remote_hosts не должен быть указан. Это вызовет конфликт при попытке регистрации.
• Все созданные визардом объекты видны в CLI и AMI, также, как и созданные руками в pjsip.conf

Ну и в завершении разговора о визарде можно рассмотреть пример использования визарда в связке с использованием шаблона для создания множественных учетных записей:

Скрипт для перехода с chan_sip на res_pjsip

Еще одним очень полезным инструментом может стать скрипт для миграции с chan_sip на pjsip – написанный на питоне sip_to_pjsip.py. Он присутствует во всех сборках Астериска использующих res_pjsip. Его прямое предназначение — преобразование файла конфигурации chan_sip (sip.conf) в аналогичный файл с конфигурацией для res_pjsip (pjsip.conf).

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

#sip_to_pjsip.py [опции] [входной файл] [выходной файл]

Чтобы понять, о чем вообще речь, рассмотрим пример конвертации и работы скрипта с файлом sip.conf, в котором прописаны простейшие настройки транка и пары учетных записей для телефонов:

Publishing Extension State

Publishing Extension State или же публикация состояния экстеншена – механизм, позволяющий публиковать состояние экстеншена для другой сущности (например, Kamailio, т.к. имеет поддержку композитора состояний событий). Другими словами, это означает, что вместо того, чтобы каждое устройство подписывалось на Астериск и получало сообщение NOTIFY при изменении состоянии экстеншена, в PJSIP настраивается отправка одного PUBLISH запроса для каждого изменения состояния экстеншена другому объекту, т.е. публикация состояния позволяет функции SUBSCRIBE и NOTIFY обрабатываться другим объектом. Эти запросы запускаются на основании хинтов прописанных в диалплане. На схеме это выгдядит примерно таким образом:

Настраивается в файле pjsip.conf путем указания исходящей публикации в секции outbound publish. Пример конфигурации:

Опция @body указывает тип тела для публикации и является обязательным параметром.

Опция @context указывает фильтр для контекста.

Опция @exten указывает фильтр для экстеншенов.

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

RLS

Resource List Subscriptions (RLS) – это механизм, введенный с 13й версии Астериска, который используется для уменьшения объема трафика связанного с SUBSCRIBE сообщениями и для упрощения его обработки станцией.

Немного подробнее о необходимости, т.е. для чего был реализован этот механизм. Предположим, есть офис на 30 сотрудников, у каждого свой сиповый ip-телефон. Каждое из этих устройств подписывается на состояние всех остальных в офисе, т.е. плодить по 29 подписок (не 30, потому что нет необходимости подписываться на себя же). Исходя из этого наш Астериск будет поддерживать 870 подписок. Увеличим количество сотрудников с ip-телефонами – соответственно возрастет количество поддерживаемых подписок, причем в геометрической прогрессии. Такую ситуацию назвали N-squared problem. Иначе говоря, объем трафика и количество серверных ресурсов пропорциональны квадрату количества пользователей системы. Итак, исходя из этого можно столкнуться с двумя нюансами:

1.  При одновременном запуске, все устройства будут посылать свои сип-подписки одновременно, сильно увеличивая нагрузку на процессор станции
2.  Появляется необходимость поддерживать N-квадратные сип-диалоги, что требует больше системных ресурсов (например, возрастает объем необходимой оперативной памяти)

С причинами разобрались, теперь переходим к описанию конфигурации. Как и многие другие настройки RLS прописывается в файле pjsip.conf, а именно в секции resource_list. Пример простейшей настройки ресурс-листа:

Разберем немного подробнее содержимое секции:

• type – тип секции
• event – пакет событий (в нашем случае presence – определение используется устройство или нет. Так же есть еще 2 вида событий – dialog и message-summary)
• list_item – раздел с именами устройств принадлежащих к ресурс-листу.
• full_state — по умолчанию опция отключена и нужна для того чтобы протокол RFC4662 не частичное уведомление состояния, а полное.
• В дополнение к вышесказанному можно отметить, что есть еще одна опция notification_batch_interval, запускающая таймер, во время которого все дальнейшие изменения состояния устройств в ресурс листе объединяются с исходным изменением, которое таймер запустило, и по истечении времени таймера, все изменения отправляются в одном сообщении NOTIFY. Измеряется в милисекундах.