Новый канальный драйвер chan_pjsip в Asterisk 13

Канальный драйвер chan_sip протокола SIP, был создан около 14 лет назад в далёком 2002 году, когда был создан, относительно новый стандарт, описанный в RFC 3261. В то время никто не мог предположить, что протокол SIP, станет играть на рынке VoIP основную роль и получит множество расширений, в виде спецификаций RFC, последующих стандартов.

Реализация драйвера SIP канала, в Asterisk была сделана в одном модуле, который называется chan_sip, который не предполагал глобального развития протокола. И в 2012 году модуль chan_sip, достиг точки, где его структура была уже не в состоянии идти в ногу, с новыми технологиями и обновлениями.

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

Стек для Asterisk, был создан на основе мультимедийной библиотеки PJSIP с открытым исходным кодом, реализующую работу протоколов SIP, SDP, RTP, STUN, TURN и ICE. Она сочетает лучшие возможности SIP сигнализации, улучшенное преодоление NAT и высокий уровень взаимодействия с приложениями.

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

Несмотря на то, что канальный драйвер PJSIP в Asterisk 13 назван chan_pjsip - его целью является организация  моста, между стеком PJSIP и фактическим каналом PJSIP, исполняющим диалплан в астериске. Стек PJSIP состоит из множества других модулей, каждый из которых выполняет свой функционал. Данный подход имеет несколько преимуществ:

• Реализация функциональных возможностей работы, в стеке PJSIP изолирована, что дает возможность его легче расширять, поддерживать и даже заменить! Например код, который обрабатывает медиа-данные (голос, видео) и код установления соединений, находится в отдельных динамически загружаемых модулях. Таким образом это, позволяет пользователю загружать только те модули, функциональность которых ему нужна.

• Разработка нового функционала для стека PJSIP существенно проще, чем это было для драйвера канала chan_sip. Стек PJSIP в Asterisk содержит модули, которые предоставляют фреймворк, доступный для использования другим модулям, для получения нужного функционала. В качестве примера, один модуль, res_pjsip_pubsub, обеспечивает publish/subscribe фреймворк, для использования другими модулями, обеспечивающих функции уведомления о событиях (например BLF). 

На рисунке можно увидеть высокий уровень модульной архитектуры стека PJSIP в Asterisk 13, показан выше. Обратите внимание, что он не показывает все модули в настоящее время в стеке PJSIP,  а скорее отображает функциональные возможности, небольшого выбора наиболее часто используемых модулей.

• В новом Asterisk 13, в SIP-стек PJSIP добавлена поддержка списков ресурсов, определённых в RFC 4662, которые позволяют использовать Asterisk в качестве сервера RLS (Resource List Server). В том числе поддерживаются операции определения списков с данными о присутствии абонентов и состоянием почтовых ящиков, доступны средства управления подписками и пакетной доставки уведомлений подписчикам.

• SIP-стек PJSIP теперь может быть использован в роли средства для распространения данных о состоянии устройства или почтового ящика через отправку PUBLISH-запросов другим экземплярам Asterisk. Данная возможность реализована по аналогии с поддержкой кластеризации в Asterisk при помощи XMPP или Corosync, но в отличие от средств кластеризации использование стека PJSIP для распространения данных о состоянии не зависит от наличия специальных демонов или серверов.

Конфигурация для нового стека PJSIP использует несколько другую схему, чем исторический драйвер SIP канала - chan_sip. Вместо того, чтобы объединять всю конфигурацию для устройства в peer/user/friend, новый стек использует подход разделения конфигурации на логические разделы, поэтому создаются разные разделы для различных целей.

В качестве примера, в sip.conf SIP пира, возможно, увидеть что-то вроде этого:

[my_phone]
type = peer
context = from-internal
disallow = all
allow = alaw
host = dynamic
secret = super_secret
qualify = yes
dtmfmode = rfc2833

Конфигурация PJSIP для этой endpoint будет выглядеть следующим образом:

[my_phone_auth]
type = auth
auth_type = userpass
username = my_phone
password = super_secret
 
[my_phone_aors]
type = aor
max_contacts = 10
qualify_frequency = 300
 
[my_phone_endpoint]
type = endpoint
auth = my_phone_auth
aors = my_phone_aors
disallow = all
allow = alaw
context = from-internal
dtmfmode = rfc4733

Типы логических разделов PJSIP:

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

ENDPOINT

Модуль ENDPOINT определяет многочисленные параметры SIP, а также связь с другими модулями - AUTH, AOR и TRANSPORT. Раздел ENDPOINT должен быть обязательно связана с одной или несколькими разделами AOR. ENDPOINT является основным профилем SIP телефона или SIP транка в res_pjsip, аналогично пиру в sip.conf. Только если там определялись почти все параметры, то здесь часть ключевых свойств вынесены в специальные модули, которые и будут рассмотрены ниже. Пример транка провайдера Zadarma:

[111111]
type=endpoint
transport=udp-transport
context=zadarma-in
disallow=all
allow=alaw
allow=ulaw
outbound_auth=111111_auth
aors=111111
from_user=111111
direct_media=no

TRANSPORT

Настройка транспортного уровня res_pjsip. Возможно использование протоколов UDP, TCP, WebSockets и методов шифрования TLS/SSL. Можно настроить один транспортный раздел для использования множеством точек (ENDPOINT), или создать уникальный транспортный уровень для конкретной точки. Каждый транспорт в системе должен иметь уникальный порт (аналогично как и в sip_profiles во FreeSWITCH).

[udp-transport]
type=transport
protocol=udp
bind=0.0.0.0

AUTH

Раздел аутентификации содержит опции и полномочия для входящих и исходящих регистраций. С этим разделом ассоциируются такие разделы как ENDPOINT и REGISTRATIONS. Множество точек и регистраций могут использовать один и тот же раздел аутентификации, если это требуется.

[111111_auth]
type=auth
auth_type=userpass
password=Password
username=111111

AOR

Главная функция AoR (Address of Record) указать Asterisk, как связаться с ENDPOINT. Без соответствующей AOR раздела, точка ENDPOINT будет недоступна для вызова. Здесь также задаются соответствия голосовой почте, MWI, продолжительность действия регистрации -expiration и настройки qualify (периодической отправки SIP сообщений OPTONS для мониторинга состояния устройств).

Когда Asterisk получает запрос на регистрацию от устройства, он в первую очередь ищет соответствующую SIP заголовку To: «111»<sip:111@192.168.0.34;transport=UDP> запись в именах раздела AOR – в нашем примере [111]

[111111]
type=aor
contact=sip:111111@sip.zadarma.com:5060

REGISTRATION

Раздел регистраций отвечает за исходящие регистрации. Используется для регистрации в удаленных системах, будь то другой Asterisk или транк от провайдера. Для регистрации понадобится определить используемый транспорт и раздел аутентификации. Помимо этого, наверняка, потребуется указать контакт для входящих вызовов.

[111111]
type=registration
transport=udp-transport
outbound_auth=111111_auth
server_uri=sip:sip.zadarma.com
client_uri=sip:111111@sip.zadarma.com
retry_interval=60
expiration=120
contact_user=111111

IDENTIFY

Определяет конечные точки с помощью IP-адреса источника.

[111111]
type=identify
endpoint=111111
match=sip.zadarma.com

DOMAIN_ALIAS

Псевдоним домена, [Имя] данного раздела является псевдонимом, а конфигурационная опция domain=, доменным именем, которому сопоставлен псевдоним.

CONTACT

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

Узнать возможные варианты значений и параметры по умолчанию можно с помощью встроенной справки интерфейса командной строки (CLI):

config show help res_pjsip <configobject> <configoption>  

Наглядное отношение связей модулей стека PJSIP можно разделить:

ENDPOINT

• Множество ENDPOINTs связываются с множеством AORs
• Ноль или больше ENDPOINTs связаны с ноль или одной AUTHs
• Ноль или больше ENDPOINTs связаны с как минимум одним TRANSPORT
• Ноль или одна ENDPOINTs связана с определенной IDENTIFY

REGISTRATION

• Ноль или больше REGISTRATIONs связаны с ноль или одной AUTHs
• Ноль или больше REGISTRATIONs связаны с как минимум одним TRANSPORT

AOR

• Множество ENDPOINTs связываются с множеством AORs
• Множество AORs связаны с множеством CONTACTs

CONTACT

• Множество CONTACTs связываются с множеством AORs

IDENTIFY

• Ноль или больше ENDPOINTs связаны с определенным IDENTIFY объектом.

ACL, DOMAIN_ALIAS

• Эти объекты не имеют направленных связей с другими объектами.

Мы совершенно уверены, что новый стек PJSIP будет лучшим шагом вперед для SIP в Asterisk.

Коментарии: