Русский
Русский
English
Статистика
Реклама

Asterisk

Виртуальная АТС. Часть 2 Решаем проблемы безопасности с Asterisk и настраиваем звонки

12.10.2020 14:18:52 | Автор: admin


В предыдущей статье мы рассмотрели простую установку IP АТС (IP PBX) Asterisk 16 из штатного репозитория на виртуальный сервер с Ubuntu 20.04. В такой конфигурации выставлять службу VoIP на всеобщее обозрение не стоит: необходимо сделать дополнительные настройки, связанные в том числе с информационной безопасностью.

Определяем модель угроз


Для начала разберемся, с какими рисками столкнется компания разместившая виртуальную АТС в интернет. Все их многообразие сводится к короткому списку:
  • утечки конфиденциальных данных и искажение содержимого (перехват сессии);
  • несанкционированный доступ к корпоративным информационным системам из-за уязвимостей в Asterisk и другом ПО на сервере, в частности из-за неправильной настройки;
  • нарушения работы виртуальной АТС из-за направленных на отказ в обслуживании атак;
  • перепродажа трафика после взлома АТС (наиболее распространенная разновидность атаки).

Какая-то часть уязвимостей связана непосредственно с программным обеспечением Asterisk. Разработчики IP АТС регулярно выпускают патчи, а системным администраторам остается только своевременно устанавливать обновления. Полной безопасности этот метод не гарантирует, поэтому стоит также ограничить доступ клиентов к серверу IP-телефонии. Посмотрим, что стоит сделать для организации безопасной телефонии.

Настраиваем межсетевой экран


Самый простой способ защиты ограничить клиентские подключения межсетевым экраном. Поскольку VDS имеет реальный IP, нет нужды решать проблемы с пропуском трафика через NAT. Остается разрешить входящие соединения от абонентов, а все прочие заблокировать посредством Netfilter. На с Ubuntu он настраивается с помощью предустановленной утилиты UFW (Uncomplicated Firewall). Если пакет ufw у вас не установлен, исправить это несложно:

sudo apt-get install ufw

Для начала проверим статус:
sudo ufw status verbose

По умолчанию UFW выключен (Status: inactive), но торопиться включать его не стоит: если не изменить настройки, все входящие пакеты начнут рубиться на корню и вы потеряете доступ к серверу по SSH. Как минимум стоит разрешить входящие соединения на 22-й порт, при этом можно использовать предустановленный профиль приложения OpenSSH (просмотр профилей: sudo ufw app list):

# Разрешаем входящие соединения SSH
# с любого IP, используя профиль приложения
sudo ufw allow OpenSSH
# или с фиксированного IP (можно указать подсеть)
sudo ufw allow from 95.32.20.106 to any port 22
# Разрешаем все входящие соединения с клиентских IP (подсетей) для работы с Asterisk
sudo ufw allow from 95.32.20.106
# Включаем межсетевой экран
sudo ufw enable


Для просмотра политики фильтрации используйте команду:

sudo ufw status verbose



Для удаления правил нужно посмотреть их номера:

sudo ufw status numbered
sudo ufw delete N




Есть и другие средства для настройки Netfiler (тот же iptables), но совмещать разные утилиты не стоит это чревато проблемами. Обойтись без фильтрации трафика не получится, потому что открытым всем ветрам ваш Asterisk не простоит и часа, как в консоли появятся вот такие веселые картинки:



Поскольку пользователи на удаленке сидят по домам (в теории), как правило они имеют реальный выделенный IP, и нам больше ничего не потребуется. В противном случае стоит позаботиться о создании защищенной виртуальной частной сети: она пригодится и для доступа к другим корпоративным ресурсам, которые не стоит выставлять на всеобщее обозрение. Более сложные средства защиты (fail2ban и т.д.) не имеют прямого отношения к Asterisk. Мы их рассмотрим в общем контексте и в других постах.

Избавляемся от лишних модулей


Эта часть настройки непосредственно с безопасностью не связана, однако в целом необходима. К тому же чем меньше возможностей предоставляет ваша АТС клиентам, тем труднее ее взломать отсутствие лишней функциональности до известной степени осложнит жизнь потенциальным злоумышленникам.

Минимальная функциональность АТС выглядит примерно так:
  • Поддержка SIP;
  • Поддержка кодека G711 alaw only (при желании можно добавить все доступные кодеки);
  • Запись звонков;
  • Поддержка формата WAV (при желании можно добавить поддержку всех доступных форматов);
  • Опционально: поддержка хранения детализации звонков на сервере баз данных.


Для управления сервисом Asterisk в интерактивном режиме используется встроенная текстовая консоль:

sudo asterisk -rvv

Файлы модулей *.so хранятся в каталоге /usr/lib/asterisk/modules/. Загружать и выгружать их можно в консоли без перезапуска сервера (имя модуля указывается без расширения, например, chan_sip вместо chan_sip.so):

module load NAME
module unload NAME


Настройки модулей Asterisk прописываются в конфигурационном файле /etc/asterisk/modules.conf. По умолчанию все доступные модули при старте сервера загружаются автоматически, но это легко изменить с помощью параметра autoload = yes|no. Отредактируем конфигурационный файл, предварительно сделав резервную копию дистрибутивного:

sudo mv /etc/asterisk/modules.conf /etc/asterisk/modules.conf.b
sudo nano /etc/asterisk/modules.conf


Есть два подхода к конфигурированию. В первом случае мы включаем автозагрузку всех существующих модулей, а ненужные отключаем через modules.conf (секция [modules]):

[modules]
autoload=yes
noload => module_name.so


Обратите внимание, здесь имя файла мы указываем с расширением.

Второй вариант: запретить автозагрузку всех и указать только нужные модули в секции [modules] файла modules.conf, например, так:

[modules]
autoload = no
load => chan_sip.so
load => codec_alaw.so
load => format_wav.so
load => app_dial.so
load => res_musiconhold.so


После редактирования меняем права доступа:
sudo chown asterisk:asterisk /etc/asterisk/modules.conf
sudo chmod 640 /etc/asterisk/modules.conf

Смотрим список загруженных модулей в консоли Asterisk:

module show



Прочие модули добавляем по вкусу. Так будет выглядеть файл modules.conf для настройки IP АТС с достаточно развитой функциональностью:

Содержимое modules.conf
[modules]

autoload=no ; отключаем автозагрузку всех модулей из /usr/lib/asterisk/modules/

; Поддержка VoIP (SIP)
load => chan_sip.so
load => res_sorcery_config.so
load => res_pjproject.so ; без него не загрузится res_rtp_asterisk.so
load => res_rtp_asterisk.so
load => app_dial.so ; приложение для звонка требует res_musiconhold.so
load => app_echo.so
load => bridge_simple.so ; нужен для соединения каналов
load => app_bridgewait.so
load => app_transfer.so ; приложение для перевода звонков
load => app_verbose.so ; приложение для детальной статистики в консоли
load => app_voicemail.so ; приложение голосовой почты требует res_adsi.so
load => app_playback.so ; приложение для проигрывания сообщений в линию
load => app_stack.so
load => app_confbridge.so ; приложение для конференций
load => app_directory.so
load => res_adsi.so
load => app_system.so ; нужно для запуска внешний приложений
load => app_queue.so ; нужно для поддержки очередей

; Требуются для получения статусов линий
load => func_devstate.so
load => app_chanisavail.so ; требуется для поддержки ChanIsAvail
load => func_cut.so ; требуется для поддержки функции cut

; Музыка при удержании вызова
load => res_musiconhold.so
load => pbx_config.so

; Поддержка доступных кодеков
load => codec_a_mu.so
load => codec_adpcm.so
load => codec_alaw.so
load => codec_ulaw.so
load => codec_gsm.so
load => codec_lpc10.so
load => codec_g726.so
load => codec_g722.so

; Поддержка форматов
load => format_gsm.so ; Raw GSM data
load => format_h263.so ; Raw h263 data
load => format_pcm.so ; Raw uLaw 8khz Audio support (PCM)
load => format_wav_gsm.so ; Microsoft WAV format (Proprietary GSM)
load => format_wav.so ; Microsoft WAV format (8000hz Signed Linear)
load => format_mp3.so ; mp3-format

; Поддержка плат Dahdi для аналоговых линий (на VDS это не нужно)
;load => chan_dahdi.so

; Парковка вызовов
load => res_parking.so

; Если используется res_monitor.so, могут понадобиться и другие модули
load => func_periodic_hook.so
load => func_strings.so ; поддержка STRFTIME
; поддержка CALLERID, если используется res_monitor.so для определения номера
load => func_callerid.so
load => func_volume.so
; поддержка записи разговоров
load => res_monitor.so
load => app_mixmonitor.so ; для app_mixmonitor.so требуется app_dial.so
load => func_channel.so

; Запись статистики звонков в базу данных MySQL напрямую (в конфигурации из статьи не используется)
;load => cdr_mysql.so
;load => res_config_mysql.so ; MySQL RealTime Configuration Driver

; Запись статистики звонков в базу данных MySQL через ODBC (в конфигурации из статьи не используется)
;load => res_odbc.so
;load => res_config_odbc.so
;load => cdr_odbc.so ;

; Поддержка SNMP (в конфигурации из статьи не используется)
;load => res_snmp.so

; Поддержка вызовов из /var/spool/asterisk/outgoing/ (в конфигурации из статьи не используется)
;load => pbx_spool.so

; Эти модули также могут пригодиться в хозяйстве (в конфигурации из статьи не используются)
;load => app_exec.so ; поддержка exec и execif
;load => app_while.so ; поддержка циклов в dialplan
;load => res_sorcery_astdb.so
;load => res_sorcery_realtime.so
;load => app_read.so
;load => app_stack.so
;load => cdr_csv.so ; выгрузка логов в /var/log/asterisk/cdr-csv/Master.csv
;load => func_cdr.so
;load => func_logic.so
;load => func_timeout.so
;load => func_shell.so
;load => pbx_ael.so
;load => res_ael_share.so
;load => res_agi.so
;load => res_speech.so ; требуется для res_agi.so


Обратите внимание: закомментировать строку можно с помощью точки с запятой.

После изменения файла modules.conf необходимо перезагрузить модули из консоли Asterisk:

module reload

Если требуется перезапустить Asterisk, вместо встроенной консоли воспользуйтесь следующей командой:

sudo systemctl restart asterisk

Все вызываемые модули должны быть установлены, иначе при попытке их загрузки Asterisk выдаст ошибку. Скажем, для поддержки формата MP3 придется установить пакет asterisk-mp3, а для работы с сервером MySQL напрямую понадобится asterisk-mysql:

sudo apt-get install asterisk-mp3
sudo apt-get install asterisk-mysql


Найти доступные в репозитории пакеты нетрудно с помощью команды:

apt-cache search asterisk

На самом деле модулей для Asterisk гораздо больше, мы перечислили далеко не все. Если вы, к примеру, установите АТС на физическом сервере и захотите подключить к нему аналоговые линии через плату интерфейсов телефонии, потребуется пакет asterisk-dahdi.

Конфигурируем VoIP


Теперь изменим файл sip.conf, таким образом, чтобы с Asterisk можно было работать:

sudo nano /etc/asterisk/sip.conf

Добавим в раздел [general] следующие строки, если вы этого еще не сделали:

alwaysauthreject=yes
allowguest=no


Первый параметр защищает сервер Asterisk от атаки перебором по номерам. Если его не включить, сервер будет сообщать злоумышленникам, когда абонента не существует. Найдя действующий номер, хакер может перейти к перебору паролей. При alwaysauthreject=yes ошибки аутентификации для существующих и несуществующих абонентов выглядят одинаково и подобрать пароль сложнее. Параметр allowguest=no запрещает т.н. гостевые звонки пользователям АТС. Можно также изменить порт, который слушает Asterisk на нестандартный с помощью директивы bindport (аналогично адрес, который слушает сервис VoIP настраивается с помощью bindaddr).

В файле sip.conf мы прописали абонентов (пиров от анг. peers) АТС. Если пользователь работает с фиксированных IP, стоит ограничить для него возможность подключения. Также необходимо создать стойкие пароли, ввести ограничение на количество звонков и, разумеется, прописать подключения к внешним провайдерам VoIP (т.н. транки от англ. trunk):

deny=0.0.0.0/0.0.0.0 ; запрет подключения со всех узлов
permit=xxx.xxx.xxx.xxx/24 ; разрешить подключение из определенной подсети
secret=сложный_пароль ; пароли абонентов должны быть стойкими к перебору
call-limit=2 ; ограничение количества одновременных звонков

В итоге файл sip.conf будет выглядеть примерно так:
Содержимое sip.conf
[general]
context=default
allowoverlap=no
udpbindaddr=0.0.0.0
tcpenable=no
tcpbindaddr=0.0.0.0
transport=udp
srvlookup=yes
alwaysauthreject=yes
allowguest=no

; Настройки подключения к SIPNET c использованием chan_sip
; директива register не требуется
[sipnet]
remotesecret=пароль
defaultuser=логин
host=sipnet.ru
type=peer
context=sipnet-trunk; должен существовать в dialplan (файл extensions.conf)
insecure=invite
callbackextension=s
fromuser=логин
fromdomain=sipnet.ru
disallow=all
allow=alaw,ulaw
nat=no
directmedia=no
dtmfmode=rfc2833

[office](!)
; Для начала сделаем шаблон для внутренних номеров, чтобы не повторять настройки.
; Тиражирование общих для всех параметров упрощает их изменение.
type=friend
host=dynamic ; регистрировать клиента по имени, а не IP для входящего звонка
nat=no ; абоненты работают не через NAT
deny=0.0.0.0/0.0.0.0 ; запрет подключения со всех узлов
call-limit=2
qualify=yes ; опрашивать телефон каждые 2 секунды
dtmfmode=rfc2833 ; способ передачи dtmf сигналов, обычно rfc2833
; Запрещаем все кодеки, а затем указываем допустимые в порядке приоритета
disallow=all
allow=ulaw
allow=alaw
allow=g729
allow=g723
allow=g726
allow=h261
allow=h263
allow=h264
allow=h263p

; Задаем абонентов (пиров) на основе шаблона office
[1001](office)
permit=XXX.XXX.XXX.XXX/Netmask
secret=сложный_пароль
callerid=Директор <1001>
context=homeoffice ; должен существовать в dialplan (файл extensions.conf)

[1002](office)
permit=YYY.YYY.YYY.YYY
secret=сложный_пароль
callerid=Секретарь <1002>
context=homeoffice


При этом абонент 1001 может подключиться с любого адреса определенной подсети, а 1002 только с фиксированного IP. Также мы задали абонентам номер, пароль, имя и контекст, который будет использоваться в плане маршрутизации звонков (dialplan). Инструкции по настройке транков лучше взять на сайтах поставщиков услуг: в нашем случае это . Параметры сходны с параметрами других пиров внутренних абонентов. Отметим также, что указанный в конфигурационном файле контекст (расскажем об этой сущности ниже) должен существовать в dialplan.

После внесения изменения конфигурационного файла sip.conf необходимо перезагрузить модуль SIP через консоль Asterisk:
sip reload

Другие команды встроенной консоли для работы с модулем SIP:

sip show peers вывод состояния всех транков/пиров;
sip show registry отображение всех регистраций;
sip show channels отображение активных каналов;
sip show settings просмотр глобальных настроек модуля SIP.



Dialplan и все-все-все


План маршрутизации звонков или dialplan часто называют сердцем Asterisk. Хранится он в файле /etc/asterisk/extensions.conf и по сути представляет собой сценарий, заставляющий АТС реагировать на внешние события. Писать скрипты плана звонков можно на разных языках, но мы рассмотрим встроенный, появившийся еще в первых версиях популярной IP АТС. После настройки и запуска Asterisk в файле extensions.conf будет какое-то содержимое. Заменим его собственным:

[general]
static=yes
writeprotect=no
priorityjumping=no
autofallthrough=yes
clearglobalvars=no

; Контекст по умолчанию принято закрывать ради удобства и безопасности
[default]
exten => _X.,1,NoOp()
same => n,Busy()
same => n,HangUp()

; Определяем контекст homeoffice
[homeoffice]
; разрешаем внутренние звонки
exten => _1XXX,1,Dial(SIP/${EXTEN})
; звонки по России производим через SIPNET
exten => _.7XXXXXXXXXX,1,Dial(SIP/${EXTEN}@sipnet)

; Определяем контекст sipnet-trunk, разрешаем входящие звонки через SIPNET
[sipnet-trunk]
; входящие звонки рассмотрим в следующей статье


Синтаксис сценария довольно очевиден, в подробностях мы разберем его в следующей статье. Отметим только, что план звонков Asterisk базируется на четырех центральных понятиях:

  • Контекстах (context) сообщающихся между собой именованных (названия заключены в квадратные скобки) частях кода: наборах инструкций;
  • Расширениях (extensions) сериях шагов для обработки вызовов, начинающихся со служебного слова exten;
  • Приоритетах шагах расширений, нумерованных (обозначенных числом) или не нумерованных (обозначенных буквой n next). Для упрощения кодинга помимо exten существует служебное слово same;
  • Приложениях (applications) выполняющих действия в текущем канале сущностях. Например, Dial это приложение, которому нужно передать аргументы.


Расширения сортируют звонки по использующей набор паттернов маске, начинающейся с нижнего подчеркивания оно дает нашей АТС понять, что речь идет о шаблоне:
exten => _1XXX,1,Dial(SIP/${EXTEN})

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

Перезагрузим dialplan с помощью консоли Asterisk:

dialplan reload

Чтобы посмотреть актуальный dialplan, воспользуйтесь командой:

dialplan show



Обратите внимание, что вносить изменения в dialplan могут, например, загруженные вами модули.

Сейчас АТС позволяет внутренним абонентам общаться между собой, а также совершать внешние звонки по России через SIPNET. Это не так много, но для второго занятия достаточно. В текущей конфигурации был использован устаревший модуль chan_sip, поддержка которого в Asterisk со временем будет прекращена. В следующей статье мы рассмотрим переход на библиотеку PjSIP для работы со стеком протоколов VoIP, а также расширим dialplan для приема входящих вызовов, организации конференций и решения других задач маршрутизации звонков. Внимательные читатели могли заметить, что некоторые загруженные модули не были задействованы в примерах: они нам понадобятся, чтобы научиться записывать звонки, создавать очереди и делать прочие интересные фокусы.



Читайте наш блог )



Подробнее..

Виртуальная АТС. Часть 3 Переводим Asterisk на PjSIP без лишних телодвижений

11.11.2020 18:11:34 | Автор: admin


В первой и второй частях цикла статей мы разобрались с установкой IP-АТС (IP-PBX) на работающий под управлением Ubuntu VPS от RuVDS и настройкой основных функций с использованием канального драйвера chan_sip. Этот подход считается устаревшим, и в будущих версиях Asterisk поддержка chan_sip будет прекращена. Вместо него лучше использовать открытую мультимедийную библиотеку PjSIP. Несмотря на кардинальные различия в файлах конфигурации, переход не так сложен, как может показаться на первый взгляд.

Что такое PjSIP?


Важно понимать, что PjSIP не какой-то новый протокол, а целая библиотека для работы со стеком обеспечивающих голосовую связь протоколов: SIP, RTP, SDP, STUN и т.д. Она представляет собой целую кучу модулей, что нашло отражение в конфигурационном файле pjsip.conf (он заменяет традиционный sip.conf). Файл разделен на секции, а работает с ним преимущественно модуль res_pjsip, при этом каждая секция определяет конфигурацию некоторого объекта. Имена секций традиционно заключаются в квадратные скобки, а в секции обязательно присутствует определяющая ее тип конструкция type =.

Типы секций могут быть следующими:

ENDPOINT аналог пира в sip.conf, который определяет опции протокола SIP и взаимодействие с AOR, AUTH и TRANSPORT. Обязательно связана хотя бы с одной секцией AOR;
AOR здесь описано, как связаться с ENDPOINT;
TRANSPORT в этой секции описываются настройки протоколов транспортного уровня, веб-сокеты и методы шифрования (наподобие general в sip.conf). Может быть одной для разных ENDPOINT или уникальной для некоторой точки;
REGISTRATION отвечает за исходящие регистрации, например, транки к провайдерам;
AUTH содержит опции и полномочия для входящих и исходящих регистраций. С ней ассоциируются ENDPOINT и REGISTRATIONS;
IDENTIFY здесь можно задать IP источника для ENDPOINT;
ACL используется res_pjsip для контроля входящих соединений, не привязан к ENDPOINT;
DOMAIN_ALIAS псевдонимы домена;
CONTACT нужна, чтобы явно не указывать SIP URI в Dialplan;
System системные опции;
Global глобальные опции;

Имена секций в большинстве случаев могут быть произвольными, но, к примеру, ENDPOINT и AOR должны именоваться идентично с заголовком SIP URI.

Нашу справку трудно назвать исчерпывающей, поскольку за кадром осталось много интересных фишек, вроде PjSIP Configuration Wizard: пока речь идет о миграции на новую библиотеку малой кровью. С нюансами и тонкостями можно разобраться позднее.

Конвертируем sip.conf в pjsip.conf


Из-за модульности структура конфигурационного файла pjsip.conf размазана тонким слоем по множеству секций она гораздо сложнее, чем у старого-доброго sip.conf. Разработчики Asterisk подумали о простых админах и создали сценарий для конвертации. Написан он на Python, и если вы собираете ПО из исходников, уже есть в дистрибутиве: в каталоге contrib/scripts/sip_to_pjsip/. Мы ставили Asterisk из входящего в репозиторий Ubuntu бинарного пакета, поэтому скрипты пришлось скачать с GitHub.

Хотя формат конфигурационных файлов для разных версий IP-PBX особо не менялся, лучше выбрать скрипты из установленной у вас версии Asterisk вместо последней по умолчанию в нашем случае 16.2.


Версию Asterisk можно посмотреть в консоли IP-PBX с помощью команды core show version

Вам понадобятся все файлы на Python из каталога contrib/scripts/sip_to_pjsip/ в репозитории на GitHub. Их нужно сложить в локальный каталог, перейти в каталог с конфигами Asterisk (обычно /etc/asterisk) и запустить скрипт sip_to_pjsip.py с привилегиями суперпользователя. Основная его задача, прочитать входной файл sip.conf и сделать новый pjsip.conf (подробности доступны в wiki Asterisk).


Сценарий сделает pjsip.conf, а дальше вас ждет его ручная полировка. Если вы устанавливали Asterisk по нашим статьям, придется еще настроить загрузку модулей в /etc/asterisk/modules.conf и изменить в Dialplan (/etc/asterisk/extensions.conf) вызов приложения Dial.

Сделанный конвертером файл /etc/asterisk/pjsip.conf на практике оказался нерабочим:

pjsip.conf
;--;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;Non mapped elements start;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;[general]allowoverlap = no[office]call-limit = 2[sipnet]remotesecret = пароль;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;Non mapped elements end;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;--;[transport-udp]type = transportprotocol = udpbind = 0.0.0.0[sipnet]type = aorcontact = sip:логин@sipnet.ru[sipnet]type = identifyendpoint = sipnetmatch = sipnet.ru[sipnet]type = endpointcontext = sipnet-trunkdtmf_mode = rfc4733disallow = allallow = alaw,ulawdirect_media = nofrom_user = логинfrom_domain = sipnet.ruaors = sipnet[1001]type = aormax_contacts = 1[1001]type = authusername = 1001password = пароль[1001]type = endpointcontext = homeofficedtmf_mode = rfc4733disallow = allallow = ulawallow = alawallow = g729allow = g723allow = g726allow = h261allow = h263allow = h264allow = h263pcallerid = Директор <1001>auth = 1001outbound_auth = 1001aors = 1001[acl]type = aclpermit = XXX.XXX.XXX.XXXdeny = 0.0.0.0/0.0.0.0[1002]type = aormax_contacts = 1[1002]type = authusername = 1002password = пароль[1002]type = endpointcontext = homeofficedtmf_mode = rfc4733disallow = allallow = ulawallow = alawallow = g729allow = g723allow = g726allow = h261allow = h263allow = h264allow = h263pcallerid = Секретарь <1002>auth = 1002outbound_auth = 1002aors = 1002


Синтаксис его понятен, подробности можно найти в wiki Asterisk. Чтобы довести конфигурационный файл до ума, потребуется ручная правка.

Исправленный /etc/asterisk/pjsip.conf (как и в sip.conf, в нем можно использовать шаблоны):

Исправленный /etc/asterisk/pjsip.conf
;===============TRANSPORT[transport-udp]type = transportprotocol = udpbind = 0.0.0.0;===============ACL[acl]type = acldeny = 0.0.0.0/0.0.0.0permit = XXX.XXX.XXX.XXX;===============SIPNET TRUNK[sipnet]type = registrationtransport = transport-udpoutbound_auth = sipnetserver_uri = sip:sipnet.ruclient_uri = sip:логин@sipnet.ruretry_interval = 60[sipnet]type = authauth_type = userpasspassword = парольusername = логин[sipnet]type = aorcontact = sip:логин@sipnet.ru[sipnet]type = endpointtransport = transport-udp; Контекст должен быть прописан в Dialplancontext = sipnet-trunkdtmf_mode = rfc4733disallow = allallow = alaw,ulawdirect_media = nofrom_user = логинfrom_domain = sipnet.ruoutbound_auth=sipnetaors = sipnet [sipnet]type = identifyendpoint = sipnetmatch = sipnet.ru;===============USER TEMPLATES [endpoint-template](!)type = endpointtransport = transport-udpcontext = homeofficedtmf_mode = rfc4733disallow = allallow = ulawallow = alawallow = g729allow = g723allow = g726allow = h261allow = h263allow = h264allow = h263p [auth-template-userpass](!)type = authauth_type = userpass [aor-template-single-reg](!)type = aor; PjSIP допускает и множественные регистрации с одного аккаунтаmax_contacts = 1;===============User 1001[1001](endpoint-template)auth = auth1001aors = 1001callerid = Директор <1001>[auth1001](auth-template-userpass)username = 1001password = пароль [1001](aor-template-single-reg);===============User 1002[1002](endpoint-template)auth = auth1002aors= 1002callerid = Секретарь <1002>[auth1002](auth-template-userpass)username = 1002password = пароль [1002](aor-template-single-reg)


С шаблонами писанины стало меньше, но есть и более интересный способ упростить админу жизнь Configuration Wizard. Пожалуй, это одна из самых удобных фишек PjSIP, с которой мы разберемся в следующей статье.

Загружаем модули


Переписываем Dialplan


Самая простая часть: достаточно заменить SIP на PJSIP в вызове приложения Dial. Пока мы немного изменили простейший тестовый Dialplan из предыдущей статьи, более сложными вещами займемся позднее.

Конфигурационный файл /etc/asterisk/extensions.conf
[general]static=yeswriteprotect=nopriorityjumping=noautofallthrough=yesclearglobalvars=no; Контекст по умолчанию принято закрывать ради удобства и безопасности[default]exten => _X.,1,NoOp()same => n,Busy()same => n,HangUp(); Определяем контекст homeoffice[homeoffice]; разрешаем внутренние звонкиexten => _1XXX,1,Dial(PJSIP/${EXTEN}); звонки по России производим через SIPNETexten => _.7XXXXXXXXXX,1,Dial(PJSIP/${EXTEN:1}@sipnet); Определяем контекст sipnet-trunk, разрешаем входящие звонки через SIPNET[sipnet-trunk]; входящие звонки рассмотрим в следующей статье

Переход с chan_sip на PjSIP оказался делом не особенно сложным, но требующим изрядной доли ручной работы. Автоматически конвертировать конфигурацию у нас не получилось: сценарий выдал неработоспособный вариант, который пришлось переписать вручную. В следующей статье мы разберем работу с Configuration Wizard и наконец расширим dialplan для приема входящих вызовов, организации конференций и решения других задач маршрутизации звонков.



Подробнее..

Как 3CX решает проблемы безопасности

30.03.2021 12:10:29 | Автор: admin
Как правило, современная IP-АТС имеет постоянный выход в интернет: так к системе могут подключаться операторы телефонии, а также внутренние абоненты. Кроме того, возможность администрирования IP-АТС из удаленных локаций очень востребована.

Оборотной стороной таких допусков является потенциальная угроза взлома IP-АТС. 3CX постоянно совершенствует встроенные методы антивзлома, что позволяет этой коммуникационной платформе успешно противостоять всем современным типам атак (не зафиксировано ни одного случая прямого взлома 3CX). Но и злоумышленники не стоят на месте: методы и алгоритмы взлома постоянно совершенствуются, и та защита, которая гарантированно отражала вчерашние атаки, может не сработать уже сегодня.

Для того, чтобы быть уверенным в неуязвимости IP-АТС, важно иметь последние обновления системы безопасности со своей стороны 3CX делает все, чтоб телефонная система пользователя стала неприступным бастионом для злоумышленников.

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

Сегодня VoIP-решения тесно интегрируются со сторонними CRM, ERP, CMS, а также с различными каналами бизнес-коммуникаций (e-mail, чат etc.). Таким образом, концепция унифицированных коммуникаций не только содержит в себе множество преимуществ, но и создает больше точек уязвимости. Недостаточный уровень защиты хотя бы одной из них может поставить под угрозу всю корпоративную сеть.

image

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

Защита телефонных разговоров

3CX содержит на борту следующие инструменты для безопасности телефонных переговоров и шифрования голосового трафика:

  • SIP TLS шифрованный протокол обмена сигнальным трафиком;
  • SIP SRTP безопасный протокол обмена голосом;
  • WebRTC SSL безопасный метод для организации рабочего места в веб-браузере;
  • 3CX Tunnel встроенный в 3CX-клиенты протокол, обеспечивающий шифрование в iOS, Android, Windows;
  • 3CX SBC Tunnel встроенный в 3CX SBC протокол, обеспечивающий шифрование удаленных устройств, подключенных через 3CX SBC;
  • TLS + SRTP используется IP-телефонами Yealink, Snom, Grandstream и другими производителями, что делает невозможным прослушивание разговоров даже в случае перехвата сетевого трафика.


Защита от несанкционированного подключения

Любая редакция 3CX содержит следующий набор функционала для собственной безопасности IP-АТС:

  • белый список IP-адресов, с которых разрешен доступ в интерфейс администратора;
  • ограничение подключения SIP-устройств без использования шифрования из публичных сетей;
  • ограничение работы без использования 3CX Tunnel;
  • черный список IP-адресов, в том числе, глобальный список от 3CX с известными злоумышленниками;
  • алгоритм защиты подключений от подозрительных SIP User Agent;
  • алгоритм защиты от перебора паролей и автоматической блокировки на 24 часа;
  • алгоритм безопасных паролей пользователей, не позволяющий использовать простые и короткие пароли.


Защита международных звонков

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


Внутренняя безопасность

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


Безопасность конфигурации

  • автоматический бэкап всех настроек на ежедневной основе (в ночное время);
  • выгрузка архива конфигурации и записей разговоров в безопасное хранилище по FTP;
  • пароль на изменение конфигурации.


Все перечисленные функции и возможности доступны в годовых лицензиях 3СХ, а также в бессрочных лицензиях при условии активной подписки Maintenance, которая, в том числе, дает доступ к обновлениям баз безопасности. То есть для обеспечения максимальной безопасности корпоративных коммуникаций подразумеваются обязательные ежегодные платежи в любом типе лицензирования.
Подробнее..

Реализация аудиоконференций в Telegram Asterisk

25.09.2020 20:20:19 | Автор: admin


В предыдущей статье я описывал реализацию выбора пользователем места жительства при регистрации в моем telegram боте, который я создавал вдохновившись идеей Телефонного эфира. В этой же статье я опишу интеграцию бота с Asterisk .

Зачем ?


Многим не нравится что в Telegram нельзя осуществлять групповые звонки.
Ну не использовать же Viber ?)
Также есть ряд кейсов именно для такой реализации, например:
  • Для проведения анонимных аудиоконференций, когда не хочется засветить свой номер либо id среди участников конференции (сразу на ум приходит шабаш хакеров либо клуба анонимных алкоголиков). Не нужно находиться в какой либо группе, сообществе, канале
  • Когда не известно кто подключиться к конференции вообще, но нужно ограничить доступ паролем
  • Все прелести Asterisk: управление конференцией (mute/umute, kick), организация гибридных аудиоконференций с участием клиентов, зарегистрированных на asterisk, telegram и PSTN. Неплохо можно сэкономить на международных звонках
  • Организация корпоративного callback via telegram и т.п.

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

Связка Asterisk VoIP- Telegram VoIP


Сама связка VoIP реализована благодаря библиотеки tg2sip. Использование ее описано в самом репозитории в разделе Usage. Есть еще несколько статей по настройке. Даже есть Docker образ.
Описание этой связки выходит за рамки данной статьи.
Единственный нюанс который я хотел бы озвучить это то, что нельзя позвонить на telegram_id, номера которого нет в Вашей книге контактов. Поэтому звонить нужно на номер телефона, на который зарегистрирован telegram.

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

Взаимодействие telegram bot Asterisk


Схема взаимодействия в моем боте выглядит следующим образом.
Пользователь выбирает желаемую комнату в меню бота, бот вызывает функцию взаимодействия с Asterisk по API передав в POST запросе параметры для подключения:
номер телефона абонента
идентификатор конференц комнаты
callerid для презентации в конференц комнате
язык для озвучивания пользователю уведомлений в системе Asterisk на родном языке
Далее, Asterisk осуществляет исходящий звонок через каналы telegram на номер, указанный в параметрах запроса. После ответа пользоветелем на звонок, Asterisk подключает его в соответствующую комнату.

Можно было бы использовать прямое подключение с бота на Astersik AMI, но я предпочитаю работать через API, чем проще тем лучше.

API на стороне Asterisk сервера


Код простого API на python. Для инициализации звонка используются .call файлы

#!/usr/bin/python3from flask import Flask, request, jsonifyimport codecsimport jsonimport globimport shutilapi_key = "s0m3_v3ry_str0ng_k3y"app = Flask(__name__)@app.route('/api/conf', methods= ['POST'])def go_conf():    content = request.get_json()    ## Блок авторизации    if not "api_key" in content:        return jsonify({'error': 'Authentication required', 'message': 'Please specify api key'}), 401    if not content["api_key"] == api_key:        return jsonify({'error': 'Authentication failure', 'message': 'Wrong api key'}), 401    ## Проверка наличия нужных параметров в запросе    if not "phone_number" in content or not "room_name" in content or not "caller_id" in content:        return jsonify({'error': 'not all parameters are specified'}), 400    if not "lang" in content:        lang = "ru"    else:        lang = content["lang"]    phone_number = content["phone_number"]    room_name = content["room_name"]    caller_id = content["caller_id"]    calls = glob.glob(f"/var/spool/asterisk/outgoing/*-{phone_number}*")    callfile = "cb_conf-" + phone_number + "-" + room_name + ".call"    filename = "/var/spool/asterisk/" + callfile    if calls:        return jsonify({'message': 'error', "text": "call already in progress"})    with codecs.open(filename, "w", encoding='utf8') as f:        f.write("Channel: LOCAL/" + phone_number + "@telegram-out\n")        f.write("CallerID: <" + caller_id + ">\n")        f.write("MaxRetries: 0\nRetryTime: 5\nWaitTime: 30\n")        f.write("Set: LANG=" + lang + "\nContext: conf-in\n")        f.write("Extension: " + room_name + "\nArchive: Yes\n")    shutil.chown(filename, user="asterisk", group="asterisk")    shutil.move(filename, "/var/spool/asterisk/outgoing/" + callfile)    return jsonify({'message': 'ok'})if __name__ == '__main__':    app.run(debug=True,host='0.0.0.0', port=8080)


При этом диалплан Asterisk в простом виде выглядит следующим образом:

[telegram-out]
exten => _+.!,1,NoOp()
same => n,Dial(SIP/${EXTEN}@telegram)

exten => _X!,1,NoOp()
same => n,Dial(SIP/+${EXTEN}@telegram)

[conf-in]
exten => _.!,1,NoOp()
same => n,Answer()
same => n,Wait(3)
same => n,Playback(beep)
same => n,Set(CHANNEL(language)=${LANG})
same => n,ConfBridge(${EXTEN})
same => n,Hangup


Данное API можно использовать и в других кейсах, например, для организации той же callback кнопки Перезвонить мне и т.п.

Функция вызова API


telephony_api.py
import requests# Заменить example.com на Ваш urlurl = "http://example.com:8080/api/conf"api_key = "s0m3_v3ry_str0ng_k3y"def go_to_conf(phone_number, room_name, caller_id, lang="ru"):    payload = "{\n\t\"phone_number\" : \""+phone_number+"\",\n\t\"room_name\" : \""+room_name+"\",\n    \"caller_id\" : \""+caller_id+"\",\n\t\"lang\": \""+lang+"\",\n\t\"api_key\": \""+api_key+"\"\n}"    headers = {        'content-type': "application/json",        'cache-control': "no-cache",        }    try:        response = requests.request("POST", url, data=payload, headers=headers, timeout=2, verify=False)        if "call already in progress" in response.text:            return False, "Ошибка. Звонок еще не завершен."        elif "error" in response.text:            print(response.text)            return False, "Ошибка. Произошел сбой. Попробуйте позже."        else:            return True, response.text    except:        return False, "Ошибка. Произошел сбой. Попробуйте позже."


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

Пример бота для инициализации вызова в конференц комнату



#!/usr/bin/python3.6import telebotfrom telephony_api import go_to_confbot = telebot.TeleBot("ВашTOKEN")pnone_number = "799999999999"# Ваш номер телефона, на который зарегистрирован telegram аккаунт@bot.message_handler(content_types=['text'])def main_text_handler(message):    if message.text == "Подключи меня в аудиоконференцию":        bot.send_message(message.chat.id, "Ok. Сейчас на telegram Вам прийдет звонок, ответив на который Вы будете подключены в аудиоконференцию")        func_result, func_message = go_to_conf(pnone_number, "ROOM1", "Bob", "ru")        if not func_result:            bot.send_message(chat_id=message.chat.id, text=func_message)if __name__ == "__main__":)   print("bot started")   bot.polling(none_stop=True)

В данном примере номер телефона задан статически, в реальности же можно например, делать запросы в базу на соответствие message.chat.id номер телефона.

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

I want to break free. Обзор беспроводной DECT гарнитуры Snom A170

24.09.2020 08:13:47 | Автор: admin
Доброго дня, коллеги.
Прошлой статьей мы завершили цикл обзоров на настольные телефоны, предлагаем теперь поговорить о гарнитурах, предоставляемых нашей компанией. Начнем с модели DECT-гарнитуры Snom A170. Посмотрите краткое видео о гарнитуре и приступайте к чтению!



Стандарт DECT


А почему собственно DECT?, наверняка спросит нас читатель. Давайте рассмотрим стандарт DECT в целом и его преимущества и недостатки по сравнению с другими возможными вариантами.
DECT (англ. Digital Enhanced Cordless Telecommunication) технология беспроводной связи на частотах 18801900 МГц. Технология, на данный момент очень широко распространена в решениях беспроводных домашних и офисных телефонов, а также беспроводных гарнитур. Популярность DECT для передачи голоса обусловлена несколькими факторами:

  • Стандарт DECT изначально предназначен именно для передачи голоса и используется только с этой целью. Это означает что нет необходимости думать о приоритизации трафика или загруженности частотного диапазона, его будут занимать исключительно устройства для передачи голоса.
  • Дальность действия. Дальность действия устройств, работающих по данному протоколу, ограничена в первую очередь мощностью передатчика. Максимальная мощность по данному стандарту ограничена 10 мВт, что дает возможность разнесения приемного и передающего устройства до 300 м в прямой видимости и до 50 метров в помещениях. Переключения между источниками сигнала при этом осуществляются быстрее чем в том же Wi-Fi, не позволяя пользователю услышать, что переключение произошло. Говоря о дальности действия нельзя сказать, что она принципиально больше, чем у конкурирующих технологий, но радиус действия источника сигнала DECT достаточно большой, чтобы обеспечить пользователю свободу перемещений или построить сеть на основе множества источников сигнала, покрыв значительную площадь.
  • Количество каналов. А значит и количество одновременно работающих устройств. Стандарт DECT подразумевает наличие 10 частотных радиоканалов, казалось бы, немного. Но каждый из частотных каналов подразделяется на 12 временных каналов, давая в сумме больше сотни каналов для передачи голоса.

Если говорить об использовании именно в качестве технологии для подключения беспроводных гарнитур, основным конкурентом DECT можно назвать технологию Bluetooth. В сравнении с данной технологией у DECT будут как преимущества, так и недостатки.
К преимуществам DECT перед Bluetooth можно отнести больший радиус покрытия (Bluetooth может обеспечить передачу данных на расстоянии в десяток метров, тогда как DECT в несколько раз больше), описываемое выше количество каналов, которое у Bluetooth будет несколько меньше и использование именно для передачи звука, что исключит наличие сторонних устройств, использующих эту же технологию связи и частотный диапазон.
К минусам же можно отнести относительно большое энергопотребление (Bluetooth-устройства потребляют заметно меньше энергии, а значит дольше обходятся без подзарядки) и необходимость подключения вашего телефона к базовой станции гарнитуры, для взаимодействия с ней.

Распаковка и комплектация


Перейдем теперь к рассмотрению самой DECT-гарнитуры.



Первое, что отмечаешь, распаковывая коробку комплектацию гарнитуры. Пожалуй, именно благодаря ей данную гарнитуру можно назвать универсальным рабочим инструментом и верным спутником практически в любой ситуации. Сама гарнитура представляет собой блок с микрофоном, динамиком и DECT-приемопередатчиком. Аккумулятор съемный и изначально на блоке он не установлен, причем самих аккумуляторов в комплекте идет 2 штуки.



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



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



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

  • Кабель USB-Mini USB для подключения к ПК
  • Кабель RJ9-RJ9 для передачи аудио между телефоном и гарнитурой
  • Специализированный кабель EHS для подключения к телефонам Snom
  • Кабель EHS для подключения к стандартизированному разъему

Такой набор переходников позволяет подключить гарнитуру к любому стационарному устройству и работать с ним.

Дизайн


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



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



Остальное управление гарнитурой осуществляется с базовой станции. Базовая станция гарнитуры выглядит также современно и элегантно.



На ней, как уже упоминалось, размещен специальный отсек для зарядки аккумулятора, а под ним находятся разъемы для подключения к ПК и телефонному аппарату и разъем для подключения блока питания.



На зарядной подставке гарнитуры расположены клавиши работы с телефонным аппаратом и ПК, клавиша регистрации гарнитуры на базе PAIR и индикатор режима Mute и заряжаемого аккумулятора. Клавишей регистрации вам придется пользоваться лишь в крайних случаях, по умолчанию гарнитура зарегистрирована на базе и не требует отдельных манипуляций для соединения с ней.



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

Функционал и эксплуатация


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



С телефоном же все еще проще подключаем гарнитуру в соответствующие разъемы и начинаем пользоваться. Для переключения между устройствами мы используем клавиши PC и PHONE на базовой станции. При нажатии клавиши загорается зеленым ее индикатор и можно пользоваться гарнитурой в удобных нам целях.
Максимальное расстояние между гарнитурой и базой в процессе эксплуатации 50 метров. Этого более чем достаточно, чтобы чувствовать себя свободно в пределах достаточно просторного офиса и заметно больше, чем может дать Bluetooth гарнитура.
Качество передаваемого и принимаемого гарнитурой звука на высоте. Естественно, для прослушивания музыки желательно включить широкополосный режим на базовой станции. В этом случае вы не заметите разницы в сравнении с проводными гарнитурами, но сможете спокойно перемещаться по помещению.



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

Подведем итог


Что же мы имеем в итоге? В итоге мы имеем качественный в своей простоте продукт, который будет вам верным спутником на рабочем месте и заставит ваших коллег обратить на вас внимание, послужив современным аксессуаром вашего повседневного образа.
Подробнее..

Офисные гарнитуры Snom A100M и A100D

27.10.2020 18:15:50 | Автор: admin
Здравствуйте хабровчане!
Мы продолжаем серию обзоров на модельный ряд гарнитур нашей компании, и сегодня обратим свое и ваше внимание на проводную модель гарнитуры: Snom A100. В зависимости от исполнения, гарнитура будет иметь индекс D (Dual) или M (Mono). Давайте рассмотрим ее поближе.



Комплектация


В комплектацию гарнитуры входит сама гарнитура, сменные амбушюры, а также переходник на RJ9.



Здесь стоит упомянуть что кабель самой гарнитуры имеет на конце QR-разъем, а подключение в интерфейсы устройств обеспечивают переходники для этих самых интерфейсов. Разъем QR (Quick Release), как и его аналог QD является 4-х пиновым разъемом для быстрого подключения и отключения гарнитур к переходникам и устройствам.

Дизайн


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



На одном из держателей также находится ось вращения микрофона. Микрофон описывает круг в 300 градусов, позволяя расположить гарнитуру на голове как с микрофоном на правом наушнике, так и на левом. Само вращение микрофона также происходит через фиксированные положения, которых достаточно много по диаметру вращения. Переход между ними осуществляется очень мягко, при этом, при нахождении в определенном положении, сам микрофон надежно фиксируется, не сдвигаясь с заданного направления.

Функционал и эксплуатация


Процесс эксплуатации гарнитуры начинается с подключения ее к устройству, с которым собственно будет осуществляться работа. Подключение это осуществляется через переходники, о которых мы сейчас поговорим.
Каждый из переходников позволяет подключать гарнитуру к своему типу разъема. Гарнитура поддерживает следующие переходники:

  • ACPJ
  • ACUSB
  • ACPJ25


Адаптер ACPJ позволяет подключать гарнитуру к разъему Jack 3.5 мм. Длинна кабеля адаптера 60 см, но часть кабеля выполнена в виде спирали, из-за чего общая длинна кабеля адаптера может значительно увеличиваться. Штекер кабеля 3-х пиновый, через переходник гарнитура отлично работает на смартфонах и прочих устройствах, обеспечивая более чем хорошее качество голоса как на прием, так и на передачу.



Адаптер ACUSB, как нетрудно догадаться, позволяет подключать гарнитуру по интерфейсу USB. Интересен этот адаптер еще и тем, что на нем присутствует пульт управления устройством, который позволяет изменять громкость динамика, отключать микрофон и посылать команду на совершение или завершение вызова, причем клавиши переходника передают команды на ПК или IP-телефон с которым работает гарнитура, а не просто изменяют усиление динамика самой A100.



Адаптер ACPJ25 позволяет подключать гарнитуру в разъем Jack 2.5 мм. Такой тип разъема часто используется на DECT-аппаратах. Помимо типа самого разъема, адаптер мало отличается от ACPJ.
Еще один важный момент в эксплуатации гарнитуры удобство ношения. За счет малого веса (всего 79 г) и эргономичной конструкции гарнитура практически не ощущается на голове. Амбушюры сделаны из приятного материала, и за счет формы и плотного прилегания к ушным раковинам обеспечивают пассивное шумоподавление, заметно снижая уровень внешних шумов.



Динамики A100 выдают чистый и качественный звук, весьма и весьма громкий. При подключении к ПК достаточно и половины громкости динамиков, чтобы звук казался излишне громким. Впрочем, понятие нормальной громкости у каждого свое. Динамики работают в диапазоне частот 150-6,800 Гц, мягко намекая что Snom A100 предназначена в первую очередь для ведения беседы. Нет, никаких принципиальных неудобств при прослушивании музыки не возникает, но низкие и высокие частоты звучат не столь ярко как в гарнитурах для этого предназначенных.



Микрофон в нашей гарнитуре захватывает чуть более широкий диапазон частот 100-10 000 Гц, имея пассивное шумоподавление микрофон обеспечивает достойное качество звука, оставляя его чистым и громким.

Итог


Что мы имеем в итоге? Гарнитура A100 удобна в использовании, и обеспечивает хорошее качество звука, а что еще нам нужно от проводной гарнитуры? За счет множества переходников обеспечивается универсальность использования, а разъем QR позволяет использовать гарнитуру с различными устройствами, осуществляя быстрое подключение и отключение от них когда это необходимо.
Подробнее..

Обзор микросотовой системы DECT Snom M700

11.11.2020 10:16:50 | Автор: admin

Доброго времени суток, дорогие читатели!


Мы с вами уже рассмотрели модельный ряд настольных телефонов и гарнитур. Что же дальше? Предлагаем вам взглянуть на наши телефонные аппараты, работающие по протоколу DECT, и начать с микросотовой системы на основе базы Snom M700. Перед прочтением обзора обязательно ознакомьтесь с видео по данной системе и одной из используемых трубок.


Микросотовая DECT-система и принципы её работы.


Уже дважды в наших обзорах мы обращались к вопросу работы протокола DECT в целом и устройств его использующих. Но микросотовая система имеет собственную специфику работы, выделяющую ее из общего ряда подобных решений. Начнем с задач, ради которых разрабатываются такие системы.
Как и любая технология, построенная на радиоволнах, технология DECT имеет определенный радиус действия. В данном случае это до 50 метров в помещениях и до 300 метров в прямой видимости. Казалось бы, расстояние немалое, но в масштабах складов, заводов и автоцентров не столь значительное, и его явно не хватит для полноценного покрытия таких мест. Кроме того, трубки в стандартных DECT-системах взаимодействуют только с одной базой единовременно, хотя и поддерживают роуминг.
Роумингом в DECT-системах называется возможность работать с несколькими базовыми станциями. При этом не подразумевается, что трубка работает с ними одновременно, имеется ввиду сама возможность запоминать базовую станцию и подключаться к ней при возможности (например, если уровень сигнала у нее выше) или необходимости (когда в радиусе действия нет других баз).
Помимо роуминга, в микросотовых DECT-системах существует понятие хендовера.
Хендовер это возможность трубок переключаться между базовыми станциями в процессе разговора без его прерывания. Именно эта технология делает использование микросотовой системы настолько удобным для абонентов, поскольку позволяет свободно перемещаться в пределах одного или нескольких зданий. Естественно, система на основе базовых станций M700 поддерживает как хендовер, так и роуминг.

Дизайн.




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



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

Функционал системы.


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



Чаще всего DECT-менеджер является отдельным устройством, которое не распространяет радиосигнал, а служит исключительно для управления, таким образом при приобретении микросотовой системы вам необходимо купить не только базовые станции, но и достаточно дорогостоящий контроллер, что повышает стоимость системы в целом.
Вторым очевидным минусом является отказоустойчивость подобных систем. Если настройки хранятся и применяются единственным устройством, то при отказе этого устройства ваша система становится полностью неработоспособной. Хорошо если устройства в системе универсальны и разделены только используемой сейчас ролью или версией ПО, но если DECT-контроллер еще и по своему устройству отличается от базы, то потеря его грозит долгим простоем оборудования, а если заранее не был сделан бэкап настроек то и полной перенастройкой системы.
Этих недостатков лишена наша микросотовая система. Суммарно в нее подключаются до 254 базовых станций, при этом данные об абонентах содержатся на каждой из базовых станций, отдельного контроллера в системе не существует.



Помимо базовых станций нас, естественно, интересуют и трубки, подключаемые к данной системе. В следующем обзоре мы максимально подробно поговорим о них, а пока скажем несколько слов о каждой. С микросотовой системой M700 работают следующие трубки:

Snom M85

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

Snom M65

Трубка для офисного использования. Оснащена достаточно емким аккумулятором, позволяющим работать до 250 часов в режиме ожидания и до 17 часов в режиме разговора. Трубка обладает большим ярким дисплеем, а взаимодействие с микросотовой системой позволяет выводить на него до 3000 контактов корпоративного телефонного справочника.

Snom M25

Наиболее бюджетная трубка данной микросотовой системы. В отличие от M65 данная трубка использует аккумуляторные батареи формата AAA, поэтому длительность работы в режиме ожидания у нее всего 75 часов. Трубка несмотря на бюджетность имеет весьма интересный, пусть и несколько минималистичный дизайн с металлизированной клавишей управления и элегантной металлизированной зарядной подставкой.
Упомянутых выше трубок к базовым станциям M700 подключается до 1000 штук.



О трубках мы вам рассказали, осталась еще составляющая DECT-системы, а именно DECT-ретранслятор M5. Ретранслятор используется для расширения радиуса действия базовых станций, при заметно меньшей стоимости по сравнению с базовой станцией, ретранслятор имеет тот же радиус распространения радиосигнала, хотя и не может стоять в промежутке между базами. Еще один минус использования ретранслятора уменьшение количества одновременных вызовов. Если сама базовая станция поддерживает до 8 одновременных вызовов на базу в режиме микросоты, то репитер лишь пять.

Итог




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

Обзор DECT трубок Snom M25, M65 и M85

23.11.2020 14:22:47 | Автор: admin

Здравствуйте, уважаемые читатели!


Как вы наверняка помните, прошлый наш обзор был посвящен микросотовой DECT системе Snom M700. Сегодняшний обзор посвящён трубкам, работающим с этой системой, а именно моделям M85, M65 и M25.



Микросотовая DECT-система. Синхронизация.


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

  • Достаточный уровень сигнала между базами
  • Настроенная синхронизация между ними же

Если с первым все более или менее понятно: располагаем базы достаточно близко друг к другу и учитываем затухание от стен и получаем удовлетворительный уровень сигнала в зоне покрытия системы, то со вторым все чуточку сложнее.
Синхронизация базовых станций подразумевает установление связи между всеми станциями, находящимися в одном сегменте микросотовой сети. Базовые станции синхронизируются с помощью радиосигнала, по воздуху, поэтому сегментом, или кластером называют часть микросотовой системы, изолированную от других частей с точки зрения радиосигнала. Имея N баз, которые являются кластером, мы начинаем настраивать синхронизацию. Синхронизация распределяется по уровням. В каждом кластере будет присутствовать одна база 1-го уровня и расходящиеся от нее базы более низких уровней. Первым делом назначаем базу 1-го уровня, стараясь чтобы она располагалась, физически, в центре вашего кластера. Ближайшие к ней базы получают уровень 2, следующие за ними 3-ий, и так далее. Чем меньше уровней тем лучше. Настройка повторяется в каждом из кластеров для корректной работы системы в целом.

Snom M85



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



Принципиально, M85 отличается от остальных трубок микросотовой системы наличием тревожной кнопки красного цвета на верхней плоскости корпуса. Она необходима в непредвиденных ситуациях, когда сотруднику требуется срочно оповестить коллег о возникшей проблеме, но не является единственным способом чтобы это сделать. M85 также содержит датчик положения в пространстве и может отправлять тревожный сигнал при резком изменении положения, например при падении, а также если изменения положения некоторое время не происходит. Подобный функционал позволяет работнику не просто оповестить коллег о непредвиденной ситуации, а сделать это в случае если он, по каким-либо причинам не может сделать этого самостоятельно. Но и это еще не все! Также, трубка имеет возможность присоединения петли, накидываемой на руку сотрудника и может подавать сигнал в случае отсоединения этой самой петли.

Snom M65



Данная модель предназначена для чуть более бережного обращения чем модель M85. Snom M65 имеет небольшие габариты и массу, что весьма важно для мобильных сотрудников в условиях офиса. Большую часть корпуса с лицевой стороны занимает цветной дисплей диагональю в те же 2 или 5 см. Над ним находится качественный динамик, обеспечивающий прекрасную слышимость собеседника, над которым расположился световой индикатор. Последний плавно переходит на верхнюю плоскость корпуса, позволяя вам, например, узнать о пришедшем сообщении голосовой почты вне зависимости от расположения трубки и вашего угла зрения.



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



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

Snom M25



Самая бюджетная трубка системы не является гадким утенком линейки и полностью справляется с возложенными на нее обязанностями средства связи. Как и упомянутые выше модели, M25 имеет разъем для гарнитуры 3.5 мм расположенный на боковой части корпуса. На другой стороне от разъема размещен световой индикатор. Решение визуально очень интересное и, благодаря тому, что индикатор чуть выступает за габариты корпуса, обеспечивая хорошую видимость, вполне функциональное.



Размер дисплей M25 по сравнению со старшими собратьями уменьшился до 1.44. Тем не менее, благодаря крупным иконкам меню и надписям интерфейса вся информация с дисплея воспринимается без каких-либо проблем. Клавиши номеронабирателя по размеру принципиально не отличаются от клавиш старшей модели, но расположены чуть дальше друг от друга, что упростит набор номера при наличии маникюра или перчатках, надетых на руки, что весьма актуально в наше время. Навигационные клавиши от старших моделей не отличаются, напоминая о принадлежности трубок к единой линейке и облагораживая внешний вид устройств.



Дополнительных функциональных клавиш трубка не имеет, все управление осуществляется из меню аппарата.
Еще одно отличие M25 от старших моделей в аккумуляторных батареях. Если в старших моделях используются литий-ионные аккумуляторы, то в младшей модели используются стандартные аккумуляторы формата AAA.



Решение стандартное для трубок подобного сегмента, имеет как свои недостатки, так и достоинства. Хотя такие аккумуляторы и обеспечивают чуть меньшее время работы трубки, они являются универсальными, легко заменяемыми и доступными, что часто бывает важно при массовом использовании устройств.

Итог


Микросотовая DECT-система M700 решение универсальное, и не только благодаря логике построения, выгодно отличающей ее от конкурентов, но и благодаря оконечным устройствам трубкам, обладающим широким функционалом, эргономичным и внешне весьма и весьма привлекательным.
Подробнее..

Snom A190 DECT-гарнитура для микросотовых систем

29.01.2021 10:18:54 | Автор: admin

Здравствуйте дорогие читатели!
Мы продолжаем цикл обзоров DECT-оборудования и сегодня познакомим вас с продуктом, который имеет не так уж много аналогов на рынке, хотя относится к уже знакомому вам классу DECT-гарнитур. Это гарнитура Snom A190, а в чем же ее особенность мы расскажем далее.

Интеграция гарнитур в DECT-системы

Все мы с вами привыкли пользоваться беспроводными гарнитурами, в быту и на рабочем месте, что в последнее время, правда, нередко означает одно и то же. Гарнитура не обладает полноценным функционалом телефонного аппарата, но она позволяет принимать, и даже совершать вызов, пусть и не путем набора номера. Однако, по сравнению с DECT-трубкой в микросотовой системе, гарнитура не так уж сильно выигрывает по степени свободы, пусть и освобождая ваши руки, но ограничивая вас в пространстве, куда вы можете переместиться. Особенно это заметно при использовании Bluetoth-гарнитур, но и DECT-гарнитуры помогают вам оставаться на связи лишь в относительно небольших пределах относительно собственного источника сигнала, как правило, базовой станции данной гарнитуры. Но есть и исключения
Как же, собственно, можно уйти от "поводка", привязывающего вас к единственному источнику сигнала? Правильно, привязаться к большому количеству источников, создав систему из них. Мы уже не единожды рассматривали концепцию микросотовой DECT-системы, так что не будем вдаваться в подробности ее устройства, поговорим о самой гарнитуре и о её месте в системе.

Дизайн

Комплект гарнитуры состоит из зарядной подставки (не будем путать ее с базовой станцией, как, например, это реализовано в Snom A170), блока питания и собственно самой A190. Зарядная подставка займет на вашем столе минимум места, обладая малыми габаритами, и надежно закрепиться на своем месте, благодаря прорезиненным ножкам. Сцепление с поверхностью этих ножек действительно феноменально, подставка как будто прилипает к столу и сдвигается в сторону очень неохотно, несмотря на отсутствие какого-либо сопротивления при попытке поднять ее вверх.

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

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

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

Функционал

Говоря о функционале гарнитуры хочется в первую очередь рассмотреть её режимы работы в микросотовой системе, которых поддерживается два.
В первом режиме работы гарнитура является самостоятельным абонентом микросоты, получает свою учетную запись через которую производятся все звонки. Такой режим подойдет тем, кто пользуется исключительно гарнитурой и не использует DECT-трубку для связи.
Второй режим позволяет "связать" гарнитуру с уже зарегистрированной в системе трубкой, используя для связанных устройств единую учетную запись. Этот режим предназначен для тех, кто может использовать как DECT-трубку, так и гарнитуру в зависимости от ситуации.

Естественно, поскольку A190 является полноценным компонентом микросотовой DECT-системы, она поддерживает роуминг и хендовер, предоставляя своему владельцу полную свободу перемещения в радиусе всей зоны покрытия микросотовых систем Snom. Подключается при этом А190 к любой из DECT-систем Snom, то есть к базам M900, M700, а также M300 и системам на их основе.
Какой параметр еще являются важным для любой гарнитуры? Естественно, время ее работы. Даже с таким малым весом, гарнитура обладает встроенным аккумулятором на 320 мАч, благодаря не самому высокому энергопотреблению аккумулятор обеспечивает до 7 часов работы в режиме разговора и до 100 часов работы в режиме ожидания.

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

Итог

Snom A190 - не просто гарнитура, а часть DECT-экосистемы. Подобные устройства очень полезны для мобильных сотрудников, которым нужны свободные руки и возможность перемещаться по предприятию оставаясь на связи. Однако и с точки зрения основной функции гарнитуры - долгой и качественной работы со звуком, ничуть не уступает, а во многом и превосходит иные подобные устройства.

Подробнее..

Конференц-связь Snom C520-WiMi и C52-SP Сценарии использования

23.02.2021 12:21:01 | Автор: admin

Здравствуй дорогой читатель!
Как и обещали, мы продолжаем обзор конференц-системы Snom C520-WiMi и спикерфона Snom C52-SP. Поговорим сегодня о предполагаемых сценариях использования этих устройств, как отдельно, так и в связке друг с другом.

Рабочее место дома

Начнем с трендов сезона. За последний год каждый из нас хотя бы раз участвовал в рабочей конференции из дома, а некоторые перешли на постоянный режим работы из уютного домашнего кресла. Естественно при работе из дома вопрос качества звука, в процессе совещания или при разговорах с коллегами и клиентами актуален как никогда. Решать его путем стандартным для офиса далеко не всегда удобно - подключение IP-телефона на удаленном рабочем месте сотрудника задача не стандартная, вероятнее всего придется организовывать VPN-соединение из его домашней сети для безопасного подключения телефона к телефонной станции, да и стоит игра свеч? Кроме того, мы все уже привыкли использовать ноутбук или ПК как одно из основных средств связи дома, так зачем здесь что-то менять? Вам достаточно лишь чуть-чуть усовершенствовать привычную для вас схему. Подключите к вашему домашнему ПК спикерфон C52-SP, используя DECT-донгл A230 и не ограничивайте себя в перемещениях по дому во время переговоров, расположив спикерфон в любом месте, где вам удобно обсуждать рабочие вопросы.

Качество связи на рабочем месте, на удивление просто.

Наверняка, каждый кто хоть раз проектировал и устанавливал систему телефонии в компании, сталкивался с дилеммой оборудования кабинетов крупных начальников. С одной стороны, руководителю необходим современный аппарат, с некоторым количеством BLF-клавиш, с трубкой, с большим дисплеем и удобной клавиатурой. Но помимо этого, телефон должен обладать хорошим качеством громкой связи и не только хорошим качеством звука, но и охватом площади значительно превосходящей стандартное рабочее место. Последнее редко может обеспечить стационарный аппарат, а конференц-телефон слишком узконаправленное устройство для обеспечения всех потребностей, возникающих в работе руководителя. Установка же двух аппаратов задваивает историю вызовов, усложняет настройку и упирается в проблему регистрации нескольких устройств на одном SIP-аккаунте, что до сих пор поддерживается не каждым сервером связи. Казалось бы, это тупик. Но это тупик лишь при попытке подойти к вопросу стандартно, мы же предлагаем чуть иной путь.


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

Оснащение небольших переговорных комнат

Множество раз мы сталкивались в своей работе с тем, что в переговорную комнату практически всегда требуется помимо конференц-телефона установить еще и аппарат для созыва сотрудников на совещание. Использовать для этого конференц-телефон не всегда удобно, поэтому в переговорных обычно размещается DECT-трубка или стационарный аппарат. Но почему бы не использовать данный аппарат как основной источник вызова, обеспечив его качественным акустическим дополнением в виде спикерфона?

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

Переговорные среднего размера.

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

В этом случае мы предлагаем следующую концепцию: На столе переговорной используется конференц-телефон Snom C520-WiMi. Если вам необходимо отойти от стола для каких-либо действий, вы вынимаете микрофон, являющийся частью устройства в обычное время, и забираете его с собой, обеспечивая хорошую слышимость всем участникам совещания. Беспокоитесь что изменение положения микрофона повлияет на общее качество звука? Не стоит. Микрофоны синхронизированы между собой и обеспечат хорошее качество связи в любом положении.

Конференц-залы и большие переговорные комнаты.

Размышляя об оснащении помещений различных размеров мы с вами добрались и конференц-залов. Принципиальное отличие здесь от предыдущих примеров, во-первых, в гораздо большем размере помещений, а во-вторых в необходимости работы со звуком из нескольких источников, разнесенных весьма далеко относительно друг друга. В этом случае одного конференц-телефона явно будет недостаточно, поскольку хоть выносные микрофоны и могут помочь получить звук из разных точек зала, они не обладают динамиками, а значит не донесут до говорящего реакцию собеседника. Что же делать? Снова вспоминать о спикерфоне!

Естественно, на этот раз Snom C52-SP не будет основным устройством для работы со звуком, а лишь частью системы, основанной на C520-WiMi. Максимум в систему можно подключить до 3-х C52-SP, обеспечив хорошей слышимостью каждый уголок конференц-зала.

Итог

Мы поразмышляли над применением Snom С520-WiMi и C52-SP со своей точки зрения. Уверены, вы найдете устройствам для конференц-связи множество применений, а мы всегда будем рады помочь вам с их реализацией, предоставив качественные и функциональные средства связи для ваших задач.

Подробнее..

Устройство громкого оповещения Snom PA1 и возможные сценарии использования 2

23.03.2021 16:07:11 | Автор: admin

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

Сценарий первый. Система оповещения

Общий сценарий построения данной системы мы уже рассмотрели в предыдущей статье. В данной схеме мы используем обе возможности передачи информации на динамики через PA1, как с помощью группы оповещения на АТС, так и с помощью мультикаста с консоли оповещения по сетевой инфраструктуре.
Зачем нам может быть это необходимо? Данный сценарий обычно применяется в рамках неких общественных пространств, это могут быть аэропорты, вокзалы, стадионы, крупные магазины и торговые центры и прочие подобные места. В таких пространствах часто бывает полезным и нужным не только производить оповещение "напрямую", в конкретный момент времени, но и использовать систему оповещения для создания некого "фона" - трансляции музыки и иногда рекламы. Для подобного сценария будет крайне полезен мультикаст, а в случае необходимости, сотрудник может воспользоваться "аппаратом оповещения" для передачи важной информации по всему пространству.

Можно ли использовать такую схему для построения системы оповещения при пожаре? Как основную, к сожалению, нельзя. Вы можете дублировать оповещение через систему построенную таким образом, но для построения пожарной системы оповещения необходимы устройства с соответствующей сертификацией, коим Snom PA1 не является.

В ситуации когда нам не нужно фоновое звучание, но мы имеем несколько физически разнесенных частей рабочего пространства, мы можем несколько видоизменить схему:

В данном случае систему оповещения можно использовать только для оповещения сотрудников, но благодаря возможности гибкой настройки со стороны АТС, по нажатию одной или другой клавиши мы можем передавать информацию сотрудником одного или нескольких конкретных помещений. При этом, использование IP-телефонии со стороны PA1 позволяет нам не обращать внимание на взаимную удаленность этих помещений, и производить оповещение, например, на складе, из головного офиса. Естественно, в этом случае нам необходима связь по локальной сети или VPN-соединение между сетевым оборудованием помещений, но построение такой сети вполне тривиальная задача в наше время.
Важный момент который стоит учитывать при выборе оборудования для связки с PA1, а именно динамиков, это мощность и собственное питание. PA1 имеет встроенный усилитель на 4 Вт, что позволяет подключать и пассивную акустику при близкой мощности динамика. Если мощности недостаточно - необходимо использовать динамики с собственным питанием.

Удобство построения системы и гибкость в процессе эксплуатации являются основными плюсами использования PA1 в таких схемах, которые составляют большую часть реализованных установок устройства. Сетевая инфраструктура сейчас присутствует на любом объекте, поэтому вам не придется с ноля протягивать все кабели для организации системы оповещения. При этом вы легко можете добавить в группы оповещения новые устройства или исключить ненужные, когда возникает такая необходимость.

Сценарий второй. Переговорная система лифта/поезда/система связи на парковке.

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

Благодаря малым размерам, PA1 можно разместить в стенной нише, колонне связи на парковке и т.д. При этом для инициации вызова можно подключить внешнюю кнопку к сухим контактам PA1, настроив действие по ее нажатию на вызов номера диспетчера. При этом через PA1 можно подключить и IP-камеру, обеспечив обзор в помещении или прилегающем пространстве. Опционально можно подключить упомянутый ранее динамик, что обеспечит слышимость в большем радиусе от вызывной панели, а также позволит подключить описанную схему к системе оповещения, когда это необходимо.

Основной аргумент в пользу построения схемы именно на PA1 в данном случае - простота подключения схемы. Нам необходимо подвести один сетевой кабель для передачи всей информации и запитать внешние устройства уже на месте, если это необходима. При этом настраивать PA1 можно удаленно благодаря веб-интерфейсу, а интеграция с IP-телефонией позволит диспетчеру не привязываться к конкретному физическому расположению для работы.

Сценарий третий. Домофон.

На нашем устройстве также присутствует группа контактов KBD, подразумевающая подключение клавиатуры. Когда это может пригодиться? В первой части обзора упоминалось что на основе PA1 можно собрать аналог домофона. Мы согласны с вами, что в большинстве случаев можно обойтись стандартной домофонной панелью, но PA1 может быть использован в случаях когда необходимо реализовать домофонию при входе, например, на территорию загородного участка. Большое количество управляемых контактов позволит одновременно контролировать дверь, ворота, добавить к этому включение звукового/светового оповещения при открытии двери, ко всему прочему через это же устройство можно подключить камеру, о чем мы также упоминали ранее. Последнее решение также уменьшит количество кабелей, которые необходимо будет прокладывать в сторону входной группы, и позволит осуществить звонок на камеру из любого места по протоколу SIP. Вы можете использовать для вызова ответной части звонок по IP или подключить обе части системы к IP-АТС, если ее наличие предполагается в рамках данного решения.

Первичная настройка.

Конфигурирование PA1 процесс совсем несложный. Устройство имеет собственный веб-интерфейс, через который и производится его настройка. По умолчанию устройство получает IP-адрес по DHCP. Подключите PA1 к сети и подождите пока оба светодиодных индикатора загорятся красным и зеленым соответственно. Подключите гарнитуру 3.5 мм в разъем подписанный Line Out, после чего нажмите на клавишу IP/Reset. Устройство сообщит вам свой IP-адрес через динамики подключенной гарнитуры. Зная IP-адрес мы входим на веб-интерфейс и приступаем к настройке.

Основные разделы которые нас интересуют при настройке:
Identity 1-4, здесь производятся настройки SIP-аккаунтов
Preferences и его подраздел PA1 Controls, здесь включается и настраивается подключенный динамик и PIN-коды для работы с сухими контактами

Advanced Settings, для настройки сетевых параметров и конфигурации в отношении SIP-протокола.

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

Итог

Мы предоставили вам свое видение вариантов использования Snom PA1. Это не законченное решение, но платформа, позволяющая решать различные задачи по подключению телекоммуникационной периферии, и интегрировать в общую систему уже существующие устройства.

Подробнее..

Прерывается голос, слышу эхо Проблема качества связи ip телефонии. Как можно решить самостоятельно?

07.04.2021 08:12:05 | Автор: admin
Источник: ЯндексКартинкиИсточник: ЯндексКартинки

Качество связи во время разговора играет весомую роль в работе компании. Это сказывается и на эффективности работы сотрудников, и на имидже компании в целом. Основные жалобы это: пропадают слова, прерывается голос, слышно эхо или речь приходит с задержкой.

Некоторые провайдеры, конечно подсказывают, что можно предпринять со своей стороны, в чем может быть проблема. Снимут дамп, сделают анализ и дадут рекомендации. Но таких крайне мало. Из памяти, пожалуй вспомню оператора Мобилон. Привет техподдержке, если читаете!

А что происходит, если провайдер не дал рекомендаций, не указал на причину?

Несомненно, у вас начнет закрадываться мысль о смене провайдера. Но решит ли это проблему? Если причина на нашей стороне, то очевидно, что проблема не решится, и качество будет также неудовлетворительным с новым провайдером. А переход, дело не простое и затратное. За такой исход событий руководство компании спасибо нам не скажет.

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

Что же еще можно предпринять? Казалось бы, вариантов больше не осталось...

Но может быть, все таки, разобраться самому? Возможно, это не так сложно?

Да, дорогие друзья!
Отвечу я вам. Всё гораздо проще, чем кажется на первый взгляд!

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

Для диагностики нам понадобится научиться снимать дамп сети (sniffer) с роутера и маршрутизатор Mikrotik. А также, настроить очереди (QoS) на роутере.

Для упрощения схемы, я поделил весь процесс на этапы:

  1. Настроить и запустить sniffer

  2. Воспроизвести проблемный вызов

  3. Проанализировать sniffer в Wireshark

  4. Настроить на роутере выделенную полосу (QoS) для телефонии

  5. Протестировать связь

1. Настройка и запуск packet sniffer

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

Настраиваем на Микротике packet sniffer: Tools->Packet Sniffer

На вкладке General оставляем значения по умолчанию.

Открываем настройку Packet SnifferОткрываем настройку Packet Sniffer

Вкладка Streaming: галочки Streaming Enabled и Filter Stream, в поле Server пишем адрес, куда будем отправлять данные, собираемые сниффером.

Прописываем адрес хоста куда слать снифферПрописываем адрес хоста куда слать сниффер

Я отправляю на свой ПК в той же сети, поэтому прописываю его локальный адрес. Но можно слать и на удаленный сервер, тогда прописываем его внешний ip.

Вкладка Filter: здесь необходимо в поле IP Address прописать ip адрес провайдера телефонии.

Желательно уточнить у самого провайдера адреса серверов, с каким сервером осуществляется обмен сигнальными сообщениями, а с каким - RTP.

Если не получилось выяснить адреса провайдера, то можно прописать просто 0.0.0.0/0

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

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

Прописываем адрес провайдера ip телефонииПрописываем адрес провайдера ip телефонии

Нажимаем Apply и Start. Внизу окна появится статус: running

Packet Sniffer запущенPacket Sniffer запущен

Сниффер на роутере запущен, теперь необходимо поймать пакеты.

На том ПК или сервере, адрес которого указали в поле Server, нужно запустить tcpdump.

На Windows:

а) нужно скачать утилиту tcpdump

Скачиваем с официального сайта версию не для коммерческого использования.

tcpdump.exe можно запустить даже с флэшки

Для этого запускаем cmd от имени администратора и проваливаемся в директорию с файлом tcpdump.exe

Запускаем tcpdump на WindowsЗапускаем tcpdump на Windows

Вводим команду tcpdump -D

Нам отобразится список доступных интерфейсов.

Выводим список доступных интерфейсовВыводим список доступных интерфейсов

Запускаем дамп в онлайн режиме, чтобы найти интерфейс, который нам нужно слушать.

Например: tcpdump -i 1 -v -n host 192.168.88.1

где 1 - это номер интерфейса, а host - адрес роутера.

У меня пакеты летят на интерфейсе под 4, его и буду слушать.

Запускаем tcpdump onlineЗапускаем tcpdump online

Далее запускаем команду для отлова сниффера с Микротика:

tcpdump host 192.168.88.1 -i 4 -C50 -n -v -w name_sniffer.pcap

где i - номер интерфейса, С50 - ограничение размера записываемого файла до 50Мб, n - отображать IP адреса вместо имени хостов, v - уровень отображения получаемой информации (1-й уровень), w - записывать данные в файл.

Запустили tcpdump для отлова Packet SnifferЗапустили tcpdump для отлова Packet Sniffer

На Linux :

Необходимо установить утилиту tcpdump. Обычно она присутствует в стандартном репозитории.

Более подробно про установку можно посмотреть, например, здесь.

Запускаем команду:

tcpdump host 192.168.88.1 -i any -C50 -n -v -w /var/tmp/name_sniffer.pcap

После запуска tcpdump вы должны увидеть отсчет улавливаемых пакетов (на Linux), в поле Got. Если отсчет не идет, значит что-то сделали неверно, перепроверьте.

Запустили tcpdump для отлова Packet SnifferЗапустили tcpdump для отлова Packet Sniffer

2. Фиксируем проблемный звонок

Теперь, когда у нас tcpdump ловит сниффер с Микротика, нужно зафиксировать проблемный звонок.

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

У меня получилось зафиксировать такой пример самостоятельно с одним из сотрудников:

Как мы слышим на записи, голос идет с прерываниями.

Но может быть и так, что на записи из личного кабинета виртуальной АТС провайдера всё будет отлично, а мы слышали человека на том конце провода плохо. Это значит, что к провайдеру голос приходит хорошего качества, а уже по пути от провайдера до нашего конечного устройства голос доходит с потерей пакетов. Для того, чтобы проверить это, нам поможет сниффер.

3. Останавливаем sniffer и анализируем его в Wireshark

Проблемный вызов необходимо проанализировать. Останавливаем tcpdump (Ctrl+C) и sniffer на Микротике (нажать Stop). Создастся файл name_sniffer.pcap.

Устанавливаем программу Wireshark. Скачать ее можно бесплатно с официального сайта. А на Линуксе можно установить из стандартного репозитория.

Открываем pcap файл в Wireshark и переходим в Телефония->Вызовы VoIP

Открываем pcap файл для анализаОткрываем pcap файл для анализа

В новом окне отобразятся все вызовы, которые попали в дамп. У меня такой один.

VoIP вызов в дампеVoIP вызов в дампе

Для удобства поиска вызовов (когда их в дампе много) установите галочку Время дня.

Выберите вызов и откройте Последовательность потоков, чтобы увидеть движение запросов по вашему звонку.

Дамп движения запросов звонка (последовательность потоков)Дамп движения запросов звонка (последовательность потоков)

Здесь мы увидим, с каким сервером провайдера идет обмен сигнальными сообщениями, а с каким сервером осуществляется передача голосовых пакетов (RTP).

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

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

Далее нас интересуют RTCP пакеты.

Из всего перехваченного сниффером трафика нужно отфильтровать только RTCP пакеты.

Прописываем фильтр:

(rtcp.ssrc.fraction>10)||(rtcp.ssrc.jitter>35)

- отобразить RTCP со значением потерь пакетов больше 10 или RTCP со значением джиттера больше 35.

Выбираем сообщение и разворачиваем RTCP -> Source 1 -> SSRC Contents

Анализ RTCP по звонкуАнализ RTCP по звонку

Здесь видим, что потеряно 50 пакетов из 256 и уровень джиттера 166 (хотя нормальный уровень это 30-70).

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

По каким причинам это может происходить?

  1. Забивается линия выделенная вам от интернет провайдера.
    Например, у нас 3Mб/с на "внешку". Устройства в локальной сети потребляют все 3Mб/с, но если просто сёрфить в браузере, то мы не заметим нехватку канала. Так как в этом случае, используется транспортный протокол TCP. А телефония использует UDP, которому свойственно теряться в процессе передачи, если весь ваш выделенный канал занят.

  2. Устройства подключены по воздуху (Wi-Fi).
    В таком случае будет высокий показатель джиттера.

  3. У провайдера на линии есть радиоканал.

  4. Проблема с вашим маршрутизатором.

  5. Проблемы на линии интернет провайдера

В этой статье, более подробно, рассмотрена причина под пунктом 1.

По остальным скажу кратко.

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

Пункт 3 и 5 - обратиться к интернет провайдеру, предоставив наши дампы, подтверждающие проблему.

Пункт 4 - диагностировать или заменить роутер.

Но в первую очередь, рекомендую всегда сначала проработать пункт 1.

4. Настраиваем выделенную полосу для ip телефонии

Необходимо в вашей локальной сети обеспечить для ip телефонии отдельную полосу пропускания (QoS), чтобы трафик других устройств не мешал.

Для начала, измерьте фактическую скорость интернета на "внешку".

Я измеряю через speedtest.net

Можно еще с помощью 2ip.ru или утилитой iperf

На speedtest.net я выбираю Change Server город отличный от моего, чтобы исключить вероятность замера скорости в пиринге.

Настраиваю speedtest.net для замера скоростиНастраиваю speedtest.net для замера скоростиВыбираю Change ServerВыбираю Change ServerРезультаты измерения скорости интернетаРезультаты измерения скорости интернета

У меня на загрузку скорость 11Мб/с, на отдачу 14Мб/с. Хотя по договору должно быть 15М в обе стороны. Поэтому и рекомендую измерять, какая у вас скорость по факту, а не по бумагам. Это поможет корректно настроить очереди на роутере.

Для настройки очередей открываем на Микротике Queues

QueuesQueues

Cоздаем правила в разделе Simple Queues.

На вкладке General задаем ограничение по скорости для всей локальной сети.

Я устанавливаю максимальные значения лимита меньше на 2М, чем полученные при замере.

Почему 2М? Беру с запасом, так как скорость может быть не постоянной и в моменте меняться как в большую, так и в меньшую сторону.

Настройки на вкладке GeneralНастройки на вкладке General

В Advanced выставить Queue Type распределение по pcq (это делается для того, чтобы устройства не мешали друг другу и равномерно использовали трафик).

Настройки на вкладке AdvancedНастройки на вкладке Advanced

Сохраняем это правило и создаем еще одно, для SIP.

Прописываем ip адрес (можно всю подсеть) провайдера ip телефонии.

Максимальные лимиты устанавливаем, как заявлено по договору интернет провайдера.

Настройки General для SIPНастройки General для SIP

В Advanced устанавливаем Limit At. Это позволит для телефонии оставлять 1Мб/с в любом случае, даже если идет максимальная нагрузка на канал другими устройствами.

Вкладка Advanced при настройке QoS для SIPВкладка Advanced при настройке QoS для SIP

Сохраняем и устанавливаем правило SIP на верхнюю позицию.

Порядок QoS правилПорядок QoS правил

ВНИМАНИЕ!

  1. Чтобы очереди (QoS) начали работать, необходимо деактивировать правило Fasttrack в IP -> Firewall -> Filter Rules.

  2. Учитывайте порядок настроенных правил. Обработка осуществляется сверху вниз. Поэтому обязательно правило SIP поднимаем на самый верх.

Пояснение по настроенным QoS:

  • весь трафик, который идет на ip адреса отличные от адреса voip провайдера, ограничивается 12Мб/с на загрузку и 9Мб/с на отдачу

  • весь остаток от этого до 15Мб/с оставляем для телефонии

  • и на тот случай, что если даже трафик проскочит выше лимитов, для телефонии отведен 1Мб/с принудительно

Далее проверяем ходит ли вообще трафик в настроенных QoS.

Нужно открыть настройки очереди и перейти на вкладку Traffic.

График трафика local QoSГрафик трафика local QoSГрафик трафика sip QoSГрафик трафика sip QoS

На вкладке Statistic можно увидеть, количество дропнутых пакетов и распределенных по pcq.

Статистика local QoSСтатистика local QoS

Также можно проверить, как отрабатывают очереди, с помощью утилиты iperf.

5. Тестируем связь

Теперь, когда QoS настроены, нужно протестировать связь.

Ставим дамп и делаем несколько тестовых звонков.

Я сделал несколько вызовов сотрудникам, и мы вместе убедились, что теперь прерываний не наблюдалось.

Вот пример одного из звонков.

В дампе этого вызова потерь пакетов не наблюдается.

Дамп звонка после настройки QoSДамп звонка после настройки QoSДамп звонка после настройки QoSДамп звонка после настройки QoS

Единственное, можно заметить, что уровень джиттера выше нормы.

Это обусловлено подключением voip устройства через Wi-Fi. И, так как устройство позволяет настроить джиттер-буфер, качество голоса не страдает.

Вы можете также и сами наглядно всё это увидеть в моих дампах. Скачать можно здесь:
дамп звонка до настройки QoS
дамп звонка после настройки QoS

Итог:

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

В некоторых организациях в локальной сети может находиться большое количество устройств с разными категориями. Например, помимо ip телефонии еще ip камеры, которые также используют udp протокол для передачи данных. Следовательно для ip камер тоже необходимо выделять QoS.

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

Более подробно про QoS можно изучить еще в этой статье.

Подробнее..

SRAPS (cлужба безопасного перенаправления и настройки)

07.04.2021 10:06:45 | Автор: admin

Здравствуйте, наши читатели.
Наверняка у каждого кто занимается телекоммуникациями и работает с оконечными устройствами, хотя бы раз, а скорее всего и не один, возникала задача преднастройки множества аппаратов. Если вы пользуетесь устройствами Snom и имеете доступ в интернет из сети где будут находиться телефоны, в этом нет ничего сложного!
Добро пожаловать в обзор службы безопасного перенаправления и настройки, или просто SRAPS.

Сервис доступен после бесплатной регистрации по ссылке: https://sraps.snom.com/

Функционал

Главный вопрос любого обзора: зачем нужно то или иное решение, давайте начнем с него.
SRAPS позволяет вам:

  • Безопасно направлять устройства на ваш локальный или удаленный сервер Autoprovision.

  • Удаленно настраивать устройства.

  • Удаленно обновлять программное обеспечение устройств Snom.

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

Преимуществ у такого решения множество главное из которых состоит в том, что вы можете администрировать и обновлять устройства, вне зависимости от вашего и их местоположения. При этом интерфейс платформы позволяет делать это просто, не углубляясь в процесс написания текстовых конфигурационных файлов, и безопасно, благодаря SHA-2 шифрованию. Добавлять устройства в систему можно заранее, зная их MAC-адрес, также заранее можно подготовить шаблон настроек, который телефоны подхватят при подключении. Физически сервера системы расположены во Франкфурте-на-Майне, система соответствует как строгому немецкому закону о защите данных, так и Европейскому общему регламенту о защите данных (GDPR).
Отдельным плюсом можно выделить тот момент, что система бесплатна и доступна для всех партнеров и клиентов Snom.
Основной минус такой системы связан с методом ее реализации. Поскольку система развернута в облаке, вам необходимо чтобы ваши устройства имели доступ в интернет для взаимодействия с ней.

Как это работает?

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

Направление устройств на локальный или удаленный сервер Autoprovision

Алгоритм работы телефона с нашей системой, следующий:
Любой телефон Snom при включении направляет запрос на сервер SRAPS для уточнения адреса сервера настроек. Каких-либо действий с аппаратом для этого производить не требуется, запрос отправляется в любом случае после загрузки устройства.

В ответ телефон получает ссылку с адресом сервера Autoprovision. Для вашего аппарата в этом случае неважно расположение самого сервера настроек. Находится ли ваш сервер относительно телефона локально или удаленно, получив адрес ссылки телефон направится по адресу, на который направил его SRAPS.
С сервера настроек в этом случае телефон загружает xml-файл с параметрами. Файл вам необходимо заранее выгрузить с настроенного телефона или написать вручную и разместить на сервере, отдельно для каждого устройства.

Удаленная настройка устройств

Второй вариант использования создание конфигурации для телефона непосредственно в системе SRAPS. Процесс добавления конкретных параметров через интерфейс SRAPS мы рассмотрим чуть позже в этом же обзоре. Принципиальное отличие удаленной настройки от простого перенаправления состоит в меньшем количестве шагов подготовки, у нас нет необходимости разворачивать http(s) сервер в своей сети или вне ее. Конфигурация наших устройств будет храниться непосредственно в системе SRAPS. Минус такого метода состоит в том же, в чем и минус самой платформы. Все ваши настройки хранятся удаленно и, если у вас нет доступа в интернет из сети с телефонами или из VLAN-а где они находятся, вам либо придется его предоставить, либо отказаться от использования системы. Это актуально в первую очередь для полностью закрытых сетей, в других случаях принципиальных проблем не возникает.

Сам метод в целом работает так же как и перенаправление, с той лишь разницей, что SRAPS указывает в качестве сервера настроек свой репозиторий, откуда телефон скачивает шифрованный конфигурационный файл. MAC-адреса на сервере привязываются к конкретному телефону по его MAC-адресу, передаваемому в шифрованном запросе.

Удаленное обновление программного обеспечения

Одно из самых часто выполняемых действий при администрировании парка аппаратов обновление программного обеспечения. В обычных условиях для обновления ПО большого количества телефонов необходимо решить 2 задачи:

  • Развернуть сервер и разместить на нем ПО

  • Направить аппараты на данный сервер за файлами

Первая задача реализуется просто, на ней мы отдельно останавливаться не будем.
Для направления аппаратов на сервер за ПО, а периодически и настройками обычно используют DHCP-опцию, для формирования которой необходимо произвести настройку сетевого оборудования. Это можно сделать и данный момент также не является сложным в реализации, но требует времени и не позволяет обновлять устройства выборочно, если это необходимо.
SRAPS при этом позволяет вам обновлять только необходимые устройства, при этом сохраняя все версии ПО загруженные ранее, из одного интерфейса и без дополнительных настроек.

Интерфейс

Система встречает нас стандартной формой входа. Вводим логин и пароль и начинаем рассматривать разделы интерфейса:

Интерфейс системы доступен, в том числе, на русском языке, что удобно, хотя и не критично важно. Он состоит из следующих разделов:

Управление конечной точкой

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

В разделе Телефоны будут отображаться все устройства, которые были добавлены в систему, изначально список пуст, но при большом количестве устройств вы всегда можете воспользоваться фильтрацией по сериям аппаратов или найти нужный вам телефон, указав его MAC-адрес.

Раздел Профили автонастройки позволяет создавать шаблоны конфигурации для настройки ваших аппаратов.Интерфейс создания шаблона выглядит так:

Здесь все просто, единственное поле заполняемое вручную - название шаблона. Параметры для настройки разбиты по разделам и расположены в правой части, при выборе конкретной настройки, она переносится на среднюю часть экрана. Остается только выбрать из списка или вписать значение для конкретной настройки, и сохранить шаблон.

Настройки телефона

Этот раздел отвечает за обновление ПО и сброс к настройкам по умолчанию. С помощью незамысловатого интерфейса создаем шаблоны для используемых моделей, и указываем версию ПО до которой необходимо обновить устройства.

Настройки

Этот раздел отвечает за параметры самой системы и вашей учетной записи в ней.

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

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

Система

Этот раздел содержит сохраненные данные о ваших устройствах добавленных в систему в CSV-формате, которые можно просмотреть и скачать нажав на Экспорт CSV. А также интерактивный журнал изменений, из которого можно "провалиться" в созданный ранее шаблон или измененный раздел, просто нажав на событие из списка.

Последний по счету, но не по значимости раздел, API

Да, данной системой вы можете управлять не только с помощью веб-интерфейса, но и с помощью API-запросов. Для этого нам необходимо иметь авторизационные данные с определенным уровнем доступа (их здесь 4) и получаем мы их создавая токен доступа через веб-интерфейс системы:

Второй подраздел является ссылкой на подробную документацию по использованию API данной системы, с которой мы, естественно, рекомендуем вам познакомиться.

Итог

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

Подробнее..

CRM в контакт-центре как создать единое окно для оператора

25.03.2021 18:04:40 | Автор: admin
Наша компания по роду деятельности обычно рассматривает работу контакт-центров со стороны организации телефонной связи. Однако даже более важный вопрос их работы это требования к единой системе (сервис-деску), которая способна заменить сразу несколько приложений в работе оператора колл-центра.

Каждый контакт-центр (КЦ) ежедневно сталкивается с двумя сложными задачами, вытекающими из самой деятельности этих подразделений.

Первая это управление КЦ. При высокой текучке необходимость постоянно нанимать и обучать новых сотрудников отнимает очень много времени. И в 90% случаев причина проблемы кроется в большом количестве приложений, необходимых для работы оператора и содержащих информацию о клиенте (статус заказа, товары в корзине, счета и пр.). Как правило, каждое приложение имеет свой алгоритм работы (с инструкциями на бумажных распечатках и в методичках).

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

Рассмотрим небольшой КЦ (до 50 операторов). На каждом клике оператор теряет доли секунды. Перемножив количество операторов, количество обращений, количество кликов, получим несколько человеко-дней, которые были потрачены на поиск информации и на ожидание ответа системы. За это время КЦ мог бы оказать услуги десяткам и сотням клиентов. Именно поэтому количество кликов должно быть минимальным, а скорость реакции максимальной.

Решение обеих проблем использование единой системы, сервис-деска, вместо большого количества разных приложений.

image

Как это сделать?

Единый сервис-деск должен обеспечивать три основных параметра:

  • функциональность;
  • безопасность;
  • юзабилити.

Функциональность


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

Что это значит? Отменить заказ и изменить заказ кардинально разные функции, которые могут задействовать разные приложения. Отмена заказа, изменение даты доставки это работа со статусом заказа. А что делать, если нужно заменить товар в заказе? То есть нужно из системы, где заказы обрабатываются (а это может быть и несколько приложений, например, логистика, склад) получить данные о том, что вообще есть на складе и на что можно поменять уже зарезервированный товар.

В этом случае задействованы:

  • данные клиента;
  • информация о статусе заказа;
  • каталог.

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

Что делать?

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

Все полученные данные формируют единое рабочее место оператора. Оно может также содержать элементы скриптов, чек-лист диалога и пр.

Юзабилити и безопасность


Когда собран весь функционал и разработана архитектура интеграции систем, можно переходить к юзабилити и безопасности.

Юзабилити это критически важный фактор в работе сервис-десков КЦ. Минимум кликов должен обеспечивать максимальный результат, а интерфейс должен быть интуитивно понятен.

Для этого нужно проработать каждый отдельный юзер-кейс. Сложность в том, что надо одновременно решить две противоположных задачи: с одной стороны, следует дать максимальный набор функций оператору, с другой стороны, если нагружать приложение кнопками, оно становится не юзабельным (что ведет к потере времени и снижению уровня сервиса).

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

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

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

Сервис-деск-платформы и CRM для контакт-центров могут быть самыми разными. Например, компания Omniline, которая помогла нам написать этот текст, предлагает решение Creatio, которое. Как только поступает звонок, система автоматически идентифицирует его по номеру и подтягивает в рабочий интерфейс оператора всю доступную на данный момент информацию об этом клиенте. Все происходит за секунды, и в момент соединения клиента с оператором у КЦ уже есть все необходимые данные.

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

image

Перечисленные положения и требования к организации рабочих мест операторов справедливы для любых CRM-систем и сервис-деск-платформ, которые используются в КЦ. При этом со стороны организации телефонной связи может использоваться также любая платформа, отвечающая требованиям КЦ и имеющая возможности для интеграции с CRM. Например, мы компания АйПиМатика поставляем программную коммуникационную платформу 3СХ от кипрских разработчиков.
Подробнее..

Как мы переводили MIKOPBX с chan_sip на PJSIP

30.09.2020 14:10:05 | Автор: admin

Предыстория

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

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

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

  • PJSIP поддерживает "множественную регистрацию". На одном аккаунте можно без проблем регистрировать несколько конечных UAC

  • Корректная работа входящей маршрутизации при настройке регистрации нескольких учетных записей провайдера на одном адресе (IP+PORT)

  • PJSIP более гибок в настройке

  • chan_sip не развивается и объявлен deprecated в Asterisk 17

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


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

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

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

  • Софтфон на ноутбуке

  • Софтфон на смартфоне

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

С чего начать?

В нашем случае был готовый файл конфигурации sip.conf. Стало интересно, возможно ли как то конвертировать старый конфиг в новый формат (структура pjsip.conf отличается значительно).

Готовый скрипт был найден в исходниках asterisk. Найти можно по пути:

contrib/scripts/sip_to_pjsip/sip_to_pjsip.py

Из встроенной справки:

Usage: sip_to_pjsip.py [options] [input-file [output-file]]Converts the chan_sip configuration input-file to the chan_pjsip output-file.The input-file defaults to 'sip.conf'.The output-file defaults to 'pjsip.conf'.

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

Настройка множественной регистрации

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

Каждую входящую регистрацию Asterisk рассматривает как contact.

Параметр "max_contacts" позволяет ограничить количество устройств, которые могут подключиться к endpoint.

;pjsip.conf[226] type = aormax_contacts = 5

Количество подключенных контактов можно посмотреть в CLI консоли Asterisk:

mikopbx*CLI> pjsip show contacts  Contact:  <Aor/ContactUri..............................> <Hash....> <Status> <RTT(ms)..>==========================================================================================  Contact:  201/sip:201@172.16.156.1:60616;ob              418d36496b Avail         3.793  Contact:  201/sip:201@172.16.156.1:60616;ob              ba56853d54 Avail         2.189  Contact:  203/sip:203@172.16.156.1:60616;ob              2cd641799f Avail         0.988Objects found: 3

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

Пример c комментариями:

;extensions.conf[internal-users]; контекст для набора 3х значных внутренних номеров; PJSIP_DIAL_CONTACTS - функция возвращает Dial-совместимую строку с контактами; Контакты разделены символом &; В качестве параметра функции необходимо передать ID endpointexten => _XXX,1,Set(dialContacts=${PJSIP_DIAL_CONTACTS(${EXTEN})}) ; Перед Dial обязательно необходимо проверить ; заполнена ли переменная "dialContacts"; если нет, то на endpoint никто не зарегистрировалсяsame => n,ExecIf($["${dialContacts}x" != "x"]?Dial(${DC},,Tt))

После правки dialplan началось интересное поведение системы.

Наши ожидания не оправдались. Мы предполагали, что при таком звонке, asterisk будет оперировать двумя каналами "Кто звонит" и "Кому звонит". На практике, все оказалось иначе.

О природе каналов и их происхождении

Каждый канал SIP и PJSIP непосредственно связан с SIP диалогом "PBX - UAC".

Проще говоря один INVITE = один канал вида SIP/104-0000XX.

Если к endpoint подключено несколько контактов, то при звонке на внутренний номер INVITE будет отправлен каждому контакту, будет создано несколько каналов.

Зная это, можно сделать следующие выводы:

  • Чем больше каналов, тем больше событий в AMI

  • Каждый канал пройдет определенный для него dialplan

  • Каждый канал повлияет на CDR записи

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

  • История звонков на АТС

  • Функция записи разговоров

  • Работа CTI приложений, завязанных на AMI

Автоподъем. Paging. Intercom

Это крайне интересные функции. Все они завязаны на функцию "Автоответ". Может работать как с настольными телефонами, так и с многими софтфонами.

Принцип работы многих UAC схож. Чтобы "поднять трубку" достаточно в INVITE передать дополнительный заголовок. Пример:

Call-Info:\;answer-after=0

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

При работе с chan_sip при originate достаточно было установить переменную SIPADDHEADER:

Action: OriginateChannel: SIP/104Context: from-internalExten: 74952293042Priority: 1Callerid: 104Variable: SIPADDHEADER="Call-Info:\;answer-after=0"

Работа с этой переменной была описана в chan_sip.си при звонке заголовок добавлялся автоматически в INVITE.

В случае с PJSIP подход отличается. Упрощенный пример extensions.conf:

[internal-users] exten => 204,1,Dial(${PJSIP_DIAL_CONTACTS(204)},,Ttb(dial_create_chan,s,1)))[dial_create_chan] exten => s,1,Set(PJSIP_HEADER(add,Call-Info)=\;answer-after=0) same => n,return 

Опция "b" в команде "Dial" позволяет созданный канал назначения с помощью Gosub направить в дополнительный контекст "dial_create_chan".

Только в этом месте есть возможность управлять SIP заголовками ДО отправки INVITE.

Интересный вывод: "dial_create_chan" - место в dialplan, где канал еще существует, но НЕ связан с SIP диалогом.

Теперь более правильный пример установки заголовка:

[internal-users] ; Получаем контактны:exten => _XXX,1,Set(dС=${PJSIP_DIAL_CONTACTS(${EXTEN})})  ; Считаем количество контактов:  same => n,ExecIf($["${FIELDQTY(dС,&)}"!="1"]?Set(__SIPADDHEADER=${EMPTY}))   same => n,ExecIf($["${dС}x" != "x"]?Dial(${DC},,Ttb(dial_create_chan,s,1)))[dial_create_chan] exten => s,1,ExecIf($["${SIPADDHEADER}x" == "x"]?return)  same => n,Set(header=${CUT(SIPADDHEADER,:,1)})  same => n,Set(value=${CUT(SIPADDHEADER,:,2)})  same => n,Set(PJSIP_HEADER(add,${header})=${value})  same => n,Set(__SIPADDHEADER=${EMPTY})   same => n,return 

С помощью функции "FIELDQTY" мы анализируем количество контактов, подключенных к endpoint. Если контактов несколько, то функцию лучше отключить, ведь сложно предугадать, на каком из телефонов сработает ответ на вызов.

С помощью функции "CUT" происходит разбор строки "SIPADDHEADER", выделяем имя заголовка и его значение.

Обязательно, после PJSIP_HEADER очищаем значение переменной SIPADDHEADER. Это страховка от случайного срабатывания "ответа" на вызов при переадресациях.

Получение значения UserAgent

Для выборка корректного SIP заголовка необходимо понимать какое конечное устройство подключено к endpoint. В случае с pjsip ситуация несколько изменилась. Пример:

[get-user-agent]exten => 300,1,NoOp(--- Incoming call ---)  same => n,Set(vContact=${PJSIP_AOR(300,contact)})  same => n,Set(vUserAgent=${PJSIP_CONTACT(${vContact},user_agent)})  same => n,NoOp(--- ${vContact} & ${vUserAgent} ---)  ... ... ...   same => n,Hangup()

Пример в одну строчку для AOR с ID 300. Для упрощения ID endpoint = ID AOR и = EXTEN:

; ${PJSIP_CONTACT(${PJSIP_AOR(${EXTEN},contact)},user_agent)}

В функцию "PJSIP_AOR" передаем ID AOR, и в качестве опции указываем, что вернуть нам следует поле "contact".

В функцию "PJSIP_CONTACT" передаем полученный контакт, и в качестве опции указываем, что вернуть следует поле "user_agent".

Обратите внимание, PJSIP_AOR(300,contact) вернет ID контакта, но это не тоже самое, что можно увидеть в CLI.

Пример результата PJSIP_AOR:

201;@e758f5661420b391e239386a94edbefe

Пример вывода в CLI:

pjsip show contacts 201/sip:201@172.16.156.1:57130;obContact:  201/sip:201@172.16.156.1:57130;ob

Исходящая регистрация

Согласно документации Asterisk, разработчики выделяют два основных вида проблем регистрации:

Временные (temporary) проблемы

  • No Response

  • 408 Request Timeout

  • 500 Internal Server Error

  • 502 Bad Gateway

  • 503 Service Unavailable

  • 504 Server Timeout

  • Некоторые 6xx ответы

Постоянные (Permanent) проблемы

  • 401 Unauthorized

  • 403 Forbidden

  • 407 Proxy Authentication Required

  • Прочие 4xx, 5xx, 6xx ошибки

В pjsip.conf при настройке исходящей регистрации обязательно необходимо описать опции для повторной попытки регистрации:

[74952293042] type = registration; Временные неудачи; Интервал для повторных попыток регистрацииretry_interval = 30; Максимальное количество попытокmax_retries = 100; "Постоянные" неудачи; Интервал используется при получении 403 Forbidden ответа.forbidden_retry_interval = 300; Интервал используется при получении Fatal ответов (non-temporary 4xx, 5xx, 6xx)fatal_retry_interval = 300

Если sip_to_pjsip.py для конвертации конфигурации, то эти опции придется описать вручную.

Идентификация провайдера

Для рада провайдеров телефонии может наблюдаться следующая картина:

  • Успешно проходит регистрация по адресу sip.test.ru

  • Допустим sip.test.ru резолвится в 10.10.10.10

  • Входящие вызовы поступают с 11.11.11.11

  • Входящие могут поступать и с 10.10.10.10

Вызовы могут не пройти авторизацию и будут завершены.

В PJSIP есть возможность идентификации по IP адресу:

[74952293042]type = identify; ... ... ...match=sip.test.ru,185.45.152.0/24,185.45.155.0/24;; ... ... ...

В параметре "match", через запятую, можно описать все IP адреса провайдера. В этом случае входящий будет корректно сопоставлен с нужным endpoint.

Кроме того, следует обратить внимание на опцию "endpoint_identifier_order".

Значение по умолчанию:

endpoint_identifier_order=ip,username,anonymous

Если у вас есть несколько учетных записей одного провайдера, которые регистрируются на одном и том же адресе IP:PORT, то имеет смысл поменять порядок идентификации:

endpoint_identifier_order=username,ip,anonymous

Пример, есть три транка:

  • 99999 - подключается к 10.10.10.10:5060

  • 88888 - подключается к 10.10.10.10:5060

  • 77777 - подключается к 10.10.10.10:5060

Если не настроить "endpoint_identifier_order", то:

  • все входящие будут направлены в контекст произвольного endpoint (идентификация пройдет по адресу IP:PORT), к примеру в контекст endpoint "99999" .

  • канал, созданный при входящем будет всегда ассоциироваться с одним и тем же endpoint, к примеру PJSIP/99999-0000XXX, на какой внешний номер бы ни звонил клиент

Входящие без регистрации SIP URI

Для ряда случаев удобно направлять входящие на АТС без регистрации.

Обязательно следует подгрузить модуль "res_pjsip_endpoint_identifier_anonymous.so".

Пример настройки pjsip.conf

[anonymous] type = endpointallow = alawtimers = nocontext = public-direct-dial

Пример extensions.conf

[public-direct-dial]exten => 74952293042,NoOp(--- Incoming call to ${EXTEN} ---)same => n,Dial(PJSIP/204,,TKg));same => n,Hangup()

Контекст public-direct-dial должен быть изолирован от исходящих dialplan.

В качестве exten описываются все DID номера и логика маршрутизации.

Подведу итоги

  • Переход на PJSIP состоялся. С chan_pjsip АТС работает стабильно, надежно

  • Нами был получен огромный опыт работы с PJSIP

  • PJSIP более гибок в настройке, предоставляет больше возможностей

  • Функция множественной регистрации крайне удобна и порой незаменима

  • chan_pjsip живой, активно развивается и поддерживается сообществом

Из минусов перехода на chan_pjsip стоит отметить:

  • Требуется модернизация dialplan

  • Изменение поведения AMI, что отражается на CTI клиентах

  • Меняется поведение CDR, требуется доработка легирования истории звонков

  • chan_pjsip активно развивается, в свежих релизах asterisk встречаются грубые ошибки. не стоит гнаться за новыми версиями, лучше выждать появления "certified" версий

Полезные ссылки

Подробнее..
Категории: Asterisk , *nix , Pbx , Mikopbx

Запись разговоров на астериск и их распознавание на Yandex.Speech

14.12.2020 14:08:42 | Автор: admin

Небольшой проект. Простая реализация. Заметка по диалплану астериск, командам консоли и АПИ распознавания Яндекса. Вы прочитаете и не наступите на мои грабли, я прочитаю через полгода-год и вспомню, что делал.

Задача: получать текстовое представление разговоров, записанных на астериске.

Сначала запись разговора

MixMonitor записывает разговор. Обычно MixMonitor записывает в один канал обоих собеседников. Нам надо получить каждый канал в отдельном файле. Поэтому есть две опции r и t, где мы можем указать файлы для записи разных каналов.

Также используется параметр b - для начала записи в момент начала разговора.

С 16 астериска была опция S - для синхронизации t и r файлов, (в тот, который позже начался записываться добавлялась тишина в начало файла). С 18 астериска опцию S убрали, т.к. это стало поведением по умолчанию, а добавили контр-опцию n. Но я использую b, поэтому эти дополнительные пляски мне не потребовались.

MixMonitor(record-o.wav,br(record-r.wav)t(record-t.wav),command)

Затем также в команде MixMonitor'а мы укажем команду для выполнения после записи. В рамках этой команды мы нормализуем каждую запись - выровняем по уровню и затем смерджим две записи в один двухканальный файл.

sox --norm record-t.wav record-t-norm.wav // нормализация записи одной стороны разговора

sox --norm record-r.wav record-r-norm.wav // нормализация записи второй стороны разговора

sox record-r-norm.wav record-t-norm.wav --channels 2 --combine merge record.wav // сливаем записи в один файл

Теперь итоговый файл можно прослушать в стерео режиме - в одном ухе слышно одного участника разговора, во втором - второго участника разговора. Интересный эффект присутствия, как будто по ролям читают, но не всем нравится такой формат прослушивания.

Для прослушивания можно использовать файл record-o.wav - первый файл из MixMonitor'а, записан традиционным методом, привычным для уха.

Файлы в формате wav достаточно много места занимают. Поэтому для хранения я их конвертирую в mp3 и копирую на хранилище.

Еще пара вариантов как организовать раздельную запись каналов на астериске

https://howto.a17.su/asterisk/call-recording.html

https://voxlink.ru/kb/asterisk-configuration/integraciya-asterisk-so-speech-analytics/

Теперь распознавание

Для распознавания дальше использую сервис Яндекса.

У Яндекса есть несколько API для распознавания: короткие аудио, длинные аудио и потоковое. Короткие - это до 30 секунд, поэтому пользуюсь API для длинных аудио.

Длинные аудио - передать можно wav или ogg файлы. С wav файлами дело не пошло, и в самом API еще необходимо указывать дополнительные параметры для wav-формата, поэтому я прежде чем отправлять на распознавание переконвертирую в ogg. Яндекс определит, что ogg двухканальный и распознает его по двум каналам без дополнительных параметров

/usr/bin/ffmpeg -i record.wav -acodec libopus record.ogg // команда переконвертации в ogg

Также есть пара нюансов

Во-первых, длинные аудио (прежде чем распознать) необходимо закачать в облако Яндекса, а в сервис распознавания передать уже ссылку на запись в облаке.

Хранилище Яндекса является S3-совместимым, поэтому для закачивания подойдет любая утилита или библиотека работающая с S3-хранилищем Амазона. Для хранения файлов в хранилще используются buckets.

Документация на Яндекс.Storage

Второе, сначала мы создаем задание на распознавание, получаем его id. А уже потом по его id чекаем на наличие результата (при этом количество операций на проверку статуса заданий ограничено, немало, конечно, но и не бесконечно).

Документация на Яндекс.Облако Распознавание длинных аудио

Документация на Яндекс.Облако Отслеживание статуса операции

Так получилось, что мое тестирование было в августе 2020, и попало на какой-то факап очереди заданий. И поэтому распознавания производились очень долго - по 2 и более часов.

Т.к. в Яндекс.Облаке и поддержка платная, отдельной строкой, то на мой тикет не отвечали оперативно. В чате же Яндекс.Облака достаточно быстро сообщили, что есть проблемы. Ну, а позже и на тикет ответили. И очередь починили. в штатном режиме все работает вполне оперативно.

По тарификации распознавания

Хранилище: место и операции - это тарифицируется. Распознавание - тоже. Все понемногу. Использую корпоративный тариф.

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

Посчитать на Тарификаторе Яндекса (раздел SpeechKit)

Ключи доступа. Тут главное не запутаться, так как у вас будут ключи и от сервиса распознавания (API ключ), и от хранилища S3 (статический ключ). Оба вида ключа на сервисном аккаунте.

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

Подробнее..

Asterisk Как управлять мультидоменом в реалтайм не привлекая внимания санитаров

22.12.2020 02:11:35 | Автор: admin

О чем собственно речь?

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

Есть у нас, к примеру, несколько (ну ладно, не несколько) однотипных филиальчиков на 10-100 сотрудников. Организовать телефонию можно разными путями:

  • Взять готовое решение в облаке провайдера

  • Поставить на каждый филиал свой мини-сервер и астериск

  • Сделать единый астериск в центре

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

Если же мы хотим оптимизации, экономии, упростить администрирование, то рано или поздно мы приходим к тому, что сервер в центре будет наиболее удачным решением. Но, как только мы попытаемся стандартизировать номерной план, мы столкнемся с проблемой плоской нумерации. Мы начинаем добавлять префиксы, наращивать длину номеров, и вот у нас уже не 3х значная нумерация, а 6ти значная. Сотрудники все чаще поглядывают косо - чтобы набрать соседа надо нажать 6 кнопок ("6 кнопок Карл! Я сюда не кнопки нажимать пришел!"), а заявление босса что компания еще немного выросла и появился еще один филиал приводит к судорожному перебиранию записей на листочке в поисках свободного префикса в 6ти значной нумерации.

Но как говорится, все уже придумано до нас - это SIP домены. К сожалению, не всегда эта тема так очевидна для администратора-универсала, и порой скрыта в глубинах англоязычных мануалов.

Попробуем разобраться, что это и как это настроить. Прежде всего, домен - это просто текстовая строка, но которую мы можем материализовать в виде днс-имени. А можем и не материализовать и оставить просто строкой. Как правильно? Ну как говорится, все сильно зависит от задачи - работать будет и так и так, но если много софтфонов, то лучше сделать ДНС - на одно поле меньше придется заполнять при настройке.

Тестировать будем астериск 18.1 со стеком PJSIP в связке с реалтайм базой данных.

Что мы будем хранить в базе? Конечно же наших любых юзверей, с их параметрами. Но мы чуть-чуть схитрим и отойдем от мануалов астериска. Не удобно вести те талмуды в базе данных, что предлагается документацией астериска "из коробки".

Поэтому начнем с создания удобной для нас таблички (Numbers), без оглядки на мануалы. И так, что мы должны знать об абоненте?

  • Конечно же, его номер (Number)

  • Пароль тоже нужен - вдруг это враг? (Secret)

  • Домен - ну раз тема про домен, очевидно, он тоже должен быть (domain)

  • CID - мы ж хотим чтобы он как то отображался при звонке

  • Опционально: протокол, DTMF, пикап-группа

  • Поле Flags - свои флаги-опции, которые станут канальными переменными. Адептов полного реалтайм просьба расслабиться, канальные переменные в разы быстрее реалтайма, поэтому такие флаги могут сильно сократить нагрузку на базу данных.

Будем считать, что табличка у нас есть. Что дальше? Ок, такую табличку астериск не прочитает, увы. Но у базы данных есть секретное оружие - вьюшки, старые добрые вьюшки, VIEW. Они позволяют взять данные, в удобном для нас виде, и представить их в удобном виде для астериска. Всего нам потребуется 3 шт:

  • Endpoints (ps_endpoints)

  • Авторизация (ps_auths)

  • Aors (ps_aors)

Это минимальный набор, по вкусу в это блюдо можно добавить и другие, для реалтайма или "волшебства" PJSIP. Позволю себе побыть лентяем и дам просто готовый код SQL:

/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;/*!40101 SET NAMES utf8 */;/*!50503 SET NAMES utf8mb4 */;/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;CREATE ALGORITHM=UNDEFINED SQL SECURITY DEFINER VIEW `ps_aors` AS select concat(`Numbers`.`Number`,if(`Numbers`.`domain` is not null,concat('@',`Numbers`.`domain`),'')) AS `id`,180 AS `default_expiration`,2 AS `max_contacts`,30 AS `minimum_expiration`,'yes' AS `remove_existing`,'' AS `contact` from `Numbers`;CREATE ALGORITHM=UNDEFINED SQL SECURITY DEFINER VIEW `ps_auths` AS select concat(`Numbers`.`Number`,if(`Numbers`.`domain` is not null,concat('@',`Numbers`.`domain`),'')) AS `id`,'userpass' AS `auth_type`,3600 AS `nonce_lifetime`,`Numbers`.`Secret` AS `password`,`Numbers`.`Number` AS `username`,`Numbers`.`domain` AS `realm` from `Numbers` where `Numbers`.`Secret` <> '';CREATE ALGORITHM=UNDEFINED SQL SECURITY DEFINER VIEW `ps_endpoints` AS select concat(`Numbers`.`Number`,if(`Numbers`.`domain` is not null,concat('@',`Numbers`.`domain`),'')) AS `id`,concat('transport-',lcase(`Numbers`.`Protocol`)) AS `transport`,concat(`Numbers`.`Number`,if(`Numbers`.`domain` is not null,concat('@',`Numbers`.`domain`),'')) AS `aors`,if(`Numbers`.`Secret` <> '',concat(`Numbers`.`Number`,if(`Numbers`.`domain` is not null,concat('@',`Numbers`.`domain`),'')),NULL) AS `auth`,'SIP' AS `context`,'all' AS `disallow`,concat('ulaw,alaw,opus',if(find_in_set('Video',`Numbers`.`Flags`),',h263,h261,h263p,h264','')) AS `allow`,concat(`Numbers`.`Number`,if(`Numbers`.`domain` is not null,concat('@',`Numbers`.`domain`),'')) AS `outbound_auth`,concat(`Numbers`.`CID`,' <',`Numbers`.`Number`,'>') AS `callerid`,if(`Numbers`.`Protocol` = 'TLS','sdes','no') AS `media_encryption`,`Numbers`.`PickupGroup` AS `named_pickup_group`,2 AS `device_state_busy_at`,concat('vRecord=',if(find_in_set('Record',`Numbers`.`Flags`) > 0,'yes','no'),';','vRussia=',if(find_in_set('Russia',`Numbers`.`Flags`) > 0,'yes','no'),';','vAbroad=',if(find_in_set('Abroad',`Numbers`.`Flags`) > 0,'yes','no'),';','vVoicemail=',if(find_in_set('Voicemail',`Numbers`.`Flags`) > 0,'yes','no'),';','vFilterCID=no') AS `set_var`,`Numbers`.`NumberID` AS `callerid_tag`,'username,auth_username,ip' AS `identify_by` from `Numbers`;/*!40101 SET SQL_MODE=IFNULL(@OLD_SQL_MODE, '') */;/*!40014 SET FOREIGN_KEY_CHECKS=IF(@OLD_FOREIGN_KEY_CHECKS IS NULL, 1, @OLD_FOREIGN_KEY_CHECKS) */;/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;

Здесь немного поясню. Решил немного усложнить задачу и дополнить условием - одновременно должно существовать два типа нумерации - "глобальная" и "местная":

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

  • Местная, пусть это будет 3х знак, некоторый универсальный номерной план внутри филиала, номера могут повторяться от филиала к филиалу, что позволяет нам сделать стандарт, типа, у директора филиала номер всегда 101, главного бухгалтера 102, зав склада по прозвищу "Вжик" 007 и т.д.

Ок, теперь заполним таблицу Numbers некоторыми тестовыми данными и взглянем на наши вьюшки.

Таблица Numbers:

Отлично, "входная точка для админа" выглядит вполне хорошо, минимум полей, максимум наглядности.

ps_endpoints

Вот он трешак реалтайма астериска, хорошо что это не нужно редактировать - вся табличка сама генерируется на основе таблицы Numbers.

ps_auth

ps_aors

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

Думаю многие уже догадались, где скрывается домен. Для тех кто пока еще не понял - посмотрите на столбцы id. Для 5ти знака, там записан просто номер - потому что мы не связываем с каким либо определённым доменом эту нумерацию. А вот для 3х знака мы прописываем после номера через @ домен. Дело в том, что астериск сначала ищет номер и авторизацию с доменом, и если такой в таблице нет - без.

Хочу акцентировать внимание на еще одном моменте. Он не очевиден, и многие спотыкаются и бросают эту тему. Имя AOR для endpointa ДОЛЖНО содержать домен, т.е. быть в формате номер@домен, если номер указан с доменом. Дело в том, что если в номере (id) присутствует домен, то астериск будет искать AOR с доменом. Это захардкорено в код. Еще раз - дать произвольное имя для AOR НЕ получится, это просто не будет работать. Нюанс, однако.

И так, почти все готово, давайте быстро пробежим по настройке связки астериска с базой.

pjsip.conf

Тут давайте немного тормознем, и посмотрим на опции.

disable multi domain

Это опция интересна тем, что по умолчанию она no. Серьезно, чаще всего инсталляции идут без поддержки домена. Но значение по-умолчанию дает астериску команду проверять домены. Если у Вас нет доменов, не поленитесь, поставьте здесь yes. Это сэкономит по 2 обращения на каждую авторизацию и каждый инвайт. База скажет вам спасибо.

endpoint identifier order

Эта опция интересна тем, что правильная ее настройка, экономит нам такты процессора. Значение по умолчанию у ней = ip,username. В такой конфигурации, астериск заточен на работу с транками без авторизации, т.е. когда авторизация идет по IP адресу. Если же у нас высоконагруженный сервер регистрации, мы можем вперед выставить username, что позволит астериску находить нужный endpoint на пару десятков тактов процессора быстрее.

по опциям все, погнали дальше по конфигам.

res config mysql.conf

Тут все очень просто, так что просто листинг - тестовая база стоит локально в этом примере:

extconfig.conf

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

ps_contacts можно не связывать, она прекрасно будет себя чувствовать и в astdb.

Spoiler

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

sorcery.conf

Мякоть магии реалтайм механизма астериска. Это мой пример, конечно же, конфигурировать нужно исходя из своих потребностей.

Перезапускаем астериск.

Собственно, где результат?

Если все сделано правильно, то у нас должны отобразиться такие endpoint в консоли астериска:

Не буду приводить всю портянку, суть видна на скрине и так. "Глобальные номера" у нас как и обычно без домена. А вот "местная нумерация" вся идет с доменном.

Обращаю внимание, что в диалплане нужно учитывать домен. Т.е., на 5ти знаки:

Dial(PJSIP/19960)

а вот на 3х знаки

Dial(PJSIP/123@test3)

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

Как зарегистрировать абонента?

Microsip, настройки будут выглядеть вот так:

Теперь каждый филиал может иметь свой номер 101 для директора. Разве это не прекрасно?

Подробнее..
Категории: Asterisk , Voip , Mysql , Realtime , Домены

Yet another Asterisk monitoring поддержка Prometheus

29.04.2021 06:19:38 | Автор: admin

image


Рассмотрим типичный день новоиспеченного asteriskера: после чтения тонн мануалов, примеров по установке и настройке Asteriska, отправок тысяч сообщений в соответствующие комьюнити-чаты, посылания в Гугл вы наконец-то получили работающий сервер PBX: внутренние пользователи заведены, транки от популярного SIP-провайдера настроены, роутинг есть, и всё вроде бы звонит. Но тут встаёт новый вопрос: а как всё это мониторить? Как узнать, онлайн ли мои пиры и транки? Сколько у меня текущих звонков? Каков uptime моего Asteriska?


Разумеется, на том же Хабре полной статей (статья 1, статья 2, статья N) по мониторингу Asterisk классическими методами: давно излюбленные Zabbix, Nagios, может Voipmonitor.


Но может в 2021 году появился какой-то новый вариант? Может он стильнее/моднее/молодежнее?


Смотрим changelogи Asteriska и видим:


Asterisk 17.0.0
Add native Prometheus support to Asterisk
(Reported by Matt Jordan)

Ура! Вот оно! К тестам!


Собираем Asterisk с поддержкой res_prometheus (выбираем в menuselect resources/res_prometheus).


Настраиваем конфиг /etc/asterisk/prometheus.conf


[general]enabled = yescore_metrics_enabled = yesuri = metrics                   

Не забываем включить http-сервер asterisk.


Добавляем job в настройках прометея (например):


- job_name: 'asterisk_res_prometheus'    metrics_path: /metrics    static_configs:      - targets: ['asterisk_ip:8088']

и смотрим, какие данные прилетают от Asteriska:


image


На самом деле нативных метрик от Asteriska пока не так и много:


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

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


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


автор поста Asterisk'ер компании Southbridge Михаил Комов.

Подробнее..

Asterisk. Оповещение о записи разговора

13.05.2021 12:17:12 | Автор: admin

Занимаюсь разработкой MikoPBX - простой в настойке АТС на базе Asterisk 16.

Недавно решили добавить функционал оповещения о записи разговора. Задачу сформулировали следующим образом:

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


Подключение модулей

Было принято решение использовать функционал приложения ChanSpy.

Для начала следует убедиться, что необходимые модули подгружается при начале работы asterisk. Добавим в modules.conf :

load => app_chanspy.soload => app_originate.so

Реализация dialplan

Путь к файлу записи оповещения опишем в extensions.conf, в секции global:

[globals] PBX_REC_ANNONCE=/var/mikopbx/media/custom/alert

Опишем dialplan для оповещений

[annonce-spy]exten => _.!,1,ExecIf($[ "${EXTEN}" == "h" ]?Hangup()  same => n,Set(chan=PJSIP/${EXTEN})  ; Проверка на существование канала.  same => n,ExecIf($["${CHANNELS(${chan})}x" != "x"]?Chanspy(${chan},uBq))  same => n,Hangup()[annonce-play]exten => annonce,1,Answer()  ; Воспроизведение медиа файла  same => n,Playback(${PBX_REC_ANNONCE})  same => n,Hangup()

Теперь, чтобы запустить оповещения достаточно знать имя канала и выполнить:

Originate(Local/${chan}@annonce-spy,exten,annonce-playback-in,annonce,1,10,a); 
  • опция "a" - указывает на то, что приложение будет выполнено асинхронно

  • "chan" - в переменной необходимо описать имя канала, без описания технологии.

  • Local/${chan}@annonce-spy - запускаем приложение Chanspy

  • "10" - как долго пытаться дозвониться до ${chan}@annonce-spy, в данном примере не имеет значения

  • exten,annonce-playback-in,annonce,1 - направляем в контекст с приложением Playback

Дополним dialplan входящих. В приложении Dial задействуем опцию "U" для перехвата момента соединения абонентов:

[incoming]exten => _XXX,1,Dial(${PJSIP_DIAL_CONTACTS(${EXTEN})},60,U(dial-answer))[dial-answer]exten => _[0-9*#+]!,1,Set(chan=${CUT(CHANNEL,/,2)})  same => n,Originate(Local/${chan}@annonce-spy,exten,annonce-play,annonce,1,2,a);  same => n,return

Теперь осталось протестировать входящие. Аналогично можно реализовать оповещение и для исходящих звонков.

Заключение

Относительно просто, без использования AGI, только на основе приложений dialplan возможно реализовать оповещение о записи разговоров.

Как ни странно, в сети довольно мало информации на эту тему.

Надеюсь эта статья будет полезна читателю :)

Полезные ссылки

Подробнее..
Категории: Asterisk , *nix , Pbx , Mikopbx

Asterisk. И снова AMI Originate

17.05.2021 18:06:47 | Автор: admin

Ранее я уже писал "AMI. Разносторонний Originate. Применение в CTI приложении". На тот момент мне казалось, что тема раскрыта, исчерпана. Но оказалось, есть куда стремиться.

Классический Originate

Action: OriginateChannel: PJSIP/201Context: all-peersExten: 203Priority: 1Callerid: 201

Пример контекста all-peers

[all-peers]exten => _X!,1,Dial(${PJSIP_DIAL_CONTACTS(${EXTEN})},30,Tt)same => n,Hangup()
  • 201 совершит вызов на 203

  • callerid у 201 отобразиться как 201 (значение параметра "Callerid" в команде Originate)

  • callerid у 203 отобращиться как 201 - все красиво

В истории звонков отобразится

2021-05-17 16:34:17|2021-05-17 16:34:20|2021-05-17 16:34:32|201|PJSIP/201-0000000a|203|PJSIP/203-0000000b

В истории все хорошо.

Чего не хватает:

  • 201 видит не корректный номер телефона, в идеале, отобразить номер, с кем планируем разговаривать

  • Не учитывается случай множественной регистрации, для 201 будет звонить последний зарегистрированный contact. Необходимо, чтобы звонили все зарегистрированные на 201 устройства одновременно


Учитываем множественную регистрацию

Опишем дополнительный контекст в extensions.conf

[internal-orig]exten => _X!,1,Set(DST_CONTACT=${PJSIP_DIAL_CONTACTS(${EXTEN})})  same => n,ExecIf($["${DST_CONTACT}x" != "x"]?Dial(${DST_CONTACT},30,Tt))

Теперь Originate примет вид:

Action: OriginateChannel: Local/201@internal-origContext: all-peersExten: 203Priority: 1Callerid: 201

Проблема множественной регистрации решена, звонят все телефоны одновременно. Но, в CDR теперь каша:

2021-05-17 17:01:09|2021-05-17 17:01:12|2021-05-17 17:01:17|203|Local/201@internal-orig-00000006;2|201|PJSIP/201-000000122021-05-17 17:01:09|2021-05-17 17:01:12|2021-05-17 17:01:17|201|Local/201@internal-orig-00000006;1|203|PJSIP/203-00000013
  • Теперь две записи

  • Появились Local каналы

Это все решается, но перейдем к этому вопросу позже.

Корректный CallerID для звонящего

Добавим в AMI команду дополнительную переменную origCid=203:

Action: OriginateChannel: Local/201@internal-origContext: all-peersExten: 203Priority: 1Callerid: 201Variable: origCid=203

Значение переменной будет совпадать с параметром "Exten" нашего запроса AMI.

Теперь дополним dialplan:

[internal-orig]exten => _X!,1,Set(D_CONT=${PJSIP_DIAL_CONTACTS(${EXTEN})})  same => n,Set(CALLERID(num)=${origCid})  same => n,ExecIf($["${D_CONT}x" != "x"]?Dial(${D_CONT},${ringlength},Tt))

Теперь на каждый увидит корректный callerid.

Исправляем информацию в CDR

Эта задача оказалась наиболее сложной и интересной. К сожалению в интернет на эту тему информации крайне мало.

Основная идея по порядку:

  • Как можно раньше убить Local каналы (hangup)

  • Local каналы НЕ должны создавать CDR записи

  • Необходимо перехватить канал звонящего при создании и направить его в контекст назначения

Теперь на примерах.

Для определения вновь созданного "реального канала" (НЕ Local) следует использовать опцию U(orig-answer-channel) в приложении Dial

Дополнительный контекст orig-answer-channel примет вид:

[orig-answer-channel]exten => s,1,Set(MASTER_CHANNEL(O_SRC_CHAN)=${CHANNEL})  same => n,return

Основная его задача - получить имя реального канала.

Дополним контекст назначения. В нем мы завершим все Local каналы и "Реальный канал" в контекст назначения:

[all-peers]exten => _X!,1,ExecIf($[ "${O_SRC_CHAN}x" != "x" ]?ChannelRedirect(${O_SRC_CHAN},${CONTEXT},${EXTEN},1))  same => n,ExecIf($[ "${O_SRC_CHAN}x" != "x" ]?Hangup())  same => n,Dial(${PJSIP_DIAL_CONTACTS(${EXTEN})},30,Tt)  same => n,Hangup()

В "all-peers" первым попадет Local канал. Это хорошо видно в verbose логе:

Executing [203@all-peers:1] ExecIf("Local/201@internal-orig-00000009;1", "1?NoCDR()")Executing [203@all-peers:2] ExecIf("Local/201@internal-orig-00000009;1", "1?ChannelRedirect(PJSIP/201-00000016,all-peers,203,1)")Executing [203@all-peers:3] ExecIf("Local/201@internal-orig-00000009;1", "1?Hangup()")

Было использовано приложение "ChannelRedirect" реальный канал будет переадресован в контекст назначения, а Local каналы будут завершены.

Executing [203@all-peers:1] ExecIf("PJSIP/201-00000016", "0?NoCDR()")Executing [203@all-peers:2] ExecIf("PJSIP/201-00000016", "0?ChannelRedirect(,all-peers,203,1)")Executing [203@all-peers:3] ExecIf("PJSIP/201-00000016", "0?Hangup()")Executing [203@all-peers:4] Dial("PJSIP/201-00000016", "PJSIP/203/sip:203@172.16.156.1:59442;ob,30,Tt")

В качестве "all-peers" лучше всего использовать контекст, определенный для конкретного sip пира, тогда звонок через Originate будет соответствовать аналогичному звонку напрямую с телефона.

Осталось только добавить NoCDR, чтобы убрать cdr записи Local каналов.

Итоговый вариант

Команда AMI примет вид:

Action: OriginateChannel: Local/201@internal-origContext: all-peersExten: 203Priority: 1Callerid: 201Variable: origCid=203

Итоговый dialplan, обратите в нем внимание на два вызова NoCDR:

[internal-orig]exten => _X!,1,NoCDR()same => n,Set(MASTER_CHANNEL(O_DST_CHAN)=${origCid})same => n,Set(CALLERID(num)=${origCid})same => n,Set(DST_CONTACT=${PJSIP_DIAL_CONTACTS(${EXTEN})})same => n,ExecIf($["${DST_CONTACT}x" != "x"]?Dial(${DST_CONTACT},${ringlength},TtU(orig-answer-channel),s,1)))[orig-answer-channel]exten => s,1,Set(MASTER_CHANNEL(O_SRC_CHAN)=${CHANNEL})  same => n,return[all-peers]exten => _X!,1,ExecIf($[ "${O_SRC_CHAN}x" != "x" ]?NoCDR())same => n,ExecIf($[ "${O_SRC_CHAN}x" != "x" ]?ChannelRedirect(${O_SRC_CHAN},${CONTEXT},${O_DST_CHAN},1))same => n,ExecIf($[ "${O_SRC_CHAN}x" != "x" ]?Hangup())same => n,Dial(${PJSIP_DIAL_CONTACTS(${EXTEN})},30,Tt)same => n,Hangup()

В CDR будет сохранена одна запись

2021-05-17 17:29:07|2021-05-17 17:29:10|2021-05-17 17:29:14|201|PJSIP/201-00000018|203|PJSIP/203-00000019

То, что надо! :)

Итоги

Я не утверждаю, что это единственное решение. Также не утверждаю, что оно для всех приемлемо и является верным. Реализация мне нравится, остался доволен полученным опытом и результатом.

Описанный прием мы успешно применили в нашей бесплатной АТС с открытым исходным кодом MikoPBX.

Полезный ресурсы

Подробнее..
Категории: Asterisk , Api , Ami , Pbx , Mikopbx

Категории

Последние комментарии

© 2006-2021, personeltest.ru