Subnets.ru blog

Многие у кого в компании больше одного сервера Asterisk зачастую сталкиваются с задачей: экспорт состояния номеров на другом сервере

Например когда появляется желание мониторить состояние exten`а на другом сервере (BLF). Чтобы при том что ваш телефон подключен к одному Asterisk серверу, а второй телефон к другому. По научному это называется Distributed Device State.

Реализация подобной задачи возможна и самый распространенный путь это путь через Jabber (XMPP PubSub). Для этого соответственно вам будет необходим Jabber сервер, а так же настройка ваших Asterisk`ов.

Как то и сам я столкнулся с этой задачей. Понадобилось сделать BLF для нцать внутренних телефонов, которые находятся на другом сервере и как и следовало я углубился в доку.

Как выяснилось позднее — это не такая простая задача как может показаться на первый взгляд. У меня то ли лыжи не едут, то ли …

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

И вот не так давно на многим известном ресурсе asterisk.ru появляется очередная тема посвященная данному вопросу: Distributed Device State: SUBSCRIBE между двумя Астерисками

Как и водится начинается она как раз с выше обозначенного способа с XMPP, но затем пользователь litnimax высказывает следующую мысль:

Проблема не так просто решается.
На сегодня есть такие варианты (мне известные):
— Jabber сервер и res_xmpp для Asterisk: позволяет обмениваться состояниями, требует кучу времени на установку, жрет немерянно ресурсов (тяжелое Java приложение, зачем оно нужно на сервере телефонии?)
— PJSIP: в новом канале есть распределенные состояния (res_pjsip_pubsub.so), однако от примеров конфигов дымится моск.
— Ну и третий вариант — ØMQ модуль для астериск и скрипт ØMQ Asterisk Manager Interface (AMI) Broker — https://github.com/litnimax/zmq-ami-broker/

Автором третьего вариант является Ваш покорный слуга, который за#$% от того, что для связи двух и более серверов требуются какие-то индейские пляски.

После данного поста и почитав доку о ZMQ Broker меня прямо осенило ! Почему мой мозг так покорно уперся только в один единственный вариант с XMPP я объяснить не могу, но именно это привело к тому, что я не мыслил шире и сам не допетрил до подобной мысли, а именно собственный метод пересылки состояний. Ведь для этого у меня уже все есть:

• возможность в Asterisk`е устанавливать Custom state для пира
• Websocket сервер и Websocket клиент, которые создавались нами под другую задачу, но вполне могут быть применены и для этой задачи

А больше нам ничего и не надо. Точнее все же надо, но это уже другое, а именно светлая голова и прямые руки 🙂

Создадим тестовый стенд. Допишем в диалплан (файл extensions.conf) exten`ы с такими именами для наглядности:

[devstate_test]
exten => 1234,hint,Custom:mystate
exten => 1234,1,NoOp(Test custom state for exten 1234)
exten => set_inuse,1,Set(DEVICE_STATE(Custom:mystate)=INUSE)
exten => set_not_inuse,1,Set(DEVICE_STATE(Custom:mystate)=NOT_INUSE)
exten => check,1,NoOp(Custom:mystate is ${DEVICE_STATE(Custom:mystate)})

Затем инклюднем данный контекст в тот же контекст где ваш телефон и сделаем себе пару тестовых EXTEN для того чтобы вызывать set_inuse, set_not_inuse и check.

После чего можно будет набрать эти EXTEN`ы и смотреть в CLI, где будет нечто подобное:

-- Executing [set_inuse@devstate_test:1] Set("SIP/6003-00000f41", "DEVICE_STATE(Custom:mystate)=INUSE") in new stack
-- Executing [check@devstate_test:1] NoOp("SIP/6003-00000f43", "Custom:mystate is INUSE") in new stack
-- Executing [set_not_inuse@devstate_test:1] Set("SIP/6003-00000f44", "DEVICE_STATE(Custom:mystate)=NOT_INUSE") in new stack
-- Executing [check@devstate_test:1] NoOp("SIP/6003-00000f46", "Custom:mystate is NOT_INUSE") in new stack

Т.е. как мы видим все работает — состояние устанавливается. Теперь посмотрим что происходит с состоянием самого exten`а 1234, для которого и написан hint и создадим подписку (SUBSCRIBE) настроив свой телефонный аппарат путем настройки BLF на любой кнопке. После того как телефон подпишется на состояние 1234, то мы сможем это наблюдать в CLI:

*CLI> sip show subscriptions
172.16.10.12 6003 1800900375-6060 1234@users Idle dialog-info+xml <none> 000300

После чего снова вызовем set_inuse и посмотрим состояние снова:

  -- Executing [set_inuse@devstate_test:1] Set("SIP/6003-00000f6e", "DEVICE_STATE(Custom:mystate)=INUSE") in new stack
*CLI> sip show subscriptions
172.16.10.12 6003 1800900375-6060 1234@users InUse dialog-info+xml <none> 000300

Как мы можем видеть состояние изменилось на InUse и кнопка на моем телефоне покраснела.

Теперь вызовем set_not_inuse и снова посмотрим:

 -- Executing [set_not_inuse@devstate_test:1] Set("SIP/6003-00000f74", "DEVICE_STATE(Custom:mystate)=NOT_INUSE") in new stack
*CLI> sip show subscriptions
172.16.10.12 6003 1800900375-6060 1234@users Idle dialog-info+xml <none> 000300

Как мы видим состояние изменилось на Idle и кнопка на моем телефоне позеленела обратно.

Механизм работает, а значит пора приступать ко второй части — передачу состояния на другой сервер. Главное тут две вещи:

• осознать как это должно работать
• наладить канал поставки и импорта/экспорта состояний

Как это должно работать ? По такой схеме:

AMI <-> «Брокер» сервер А <-> «Брокер» сервер Б <-> AMI

Словами это можно представить так:

• в AMI сервера А происходит событие изменения состояние exten
• программный клиент, который подключен к AMI сервера А и слушает такие события передает их «Брокеру» сервера A
• «Брокер» сервера A пересылает сообщения на «Брокер» сервера Б
• «Брокер» сервера Б передает их программному клиенту, который в свою очередь подключен к AMI сервера Б
• в AMI сервера Б исполняется команда

Соответственно в обратную сторону от сервера Б к серверу А все тоже самое.

Для экспорта состояния мы слушаем события в AMI, пример такого события:

Event: ExtensionStatus
Privilege: call,all
Exten: 1234
Context: devstate_test
Hint: Custom:inuse
Status: 0

Для импорта состояния в AMI мы выполняем команду Setvar:

Action: Setvar
Variable: DEVICE_STATE(Custom:ВАШ_EXTEN)
Value: ЗНАЧЕНИЕ

Где «ВАШ_EXTEN» это номер который мы мониторим, а «Значение» это состояние (inuse, not_inuse или иное).

В моем случае у меня Asterisk 1.8 и потому для меня есть несколько НО:

• у него в AMI нет «Event DeviceStateChange«, у него есть «Event ExtensionStatus«, так же отсутствует presence state (оно появилось начиная с Asterisk 11)
• «Event ExtensionStatus» приходит только по тому номеру НА который звонят, а по тому КТО звонит ничего нет, но это решаемо, решаемо через «Event Newstate«

После того как вы доставили сообщение к AMI сервера, вам остается сделать контекст, в котором и выполнять hint`ы для таких экстеншенов.

В виду того что символ @ в названии exten не стоит использовать, т.к. у парсера Asterisk`а сносит крышу от этого когда в строке появляется две @ 
Потому я  для себя (пока или на совсем не знаю) выбрал такой формат: НОМЕР*DNS_ИМЯ_СЕРВЕРА

[externalStates]
exten => _XXX*[a-z].,hint,Custom:${EXTEN}
exten => _XXX*[a-z].,1,NoOp(Call to ${CUT(EXTEN,*,1)} on ${CUT(EXTEN,*,2)})

После чего мы можем инклюднуть этот контекст туда где живет ваш же телефон и в настройках вашего телефона настроить BLF на подписку на exten НОМЕР*my.domain.ru.

И вуаля. При вызове НОМЕР на сервере Б, ваш телефон который подключен к серверу А теперь видит, что состояние НОМЕР изменилось и моргает вам лампочкой 🙂

Как я уже писал выше в кач-ве «брокера» я у себя использовал Websocket.

Таким образом задача была решена и с тех пор все работает как часы и без надстроек в виде XMPP.

З.Ы. При копировании статьи ссылка на источник ОБЯЗАТЕЛЬНА ! Уважайте чужой труд.

Автор: Николаев Дмитрий (virus (at) subnets.ru)

Похожие статьи:

Не найдено