По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Всем привет! В сегодняшней статье мы расскажем, как победить очень надоедливый “баг” во FreePBX, который кочует из версии в версию и сильно мешает пользователям, которые используют кириллицу, то есть русские буквы, в именах внутренних номеров своей IP-АТС. Точно можно сказать, что данная проблема присутствовала в FreePBX 13 и перебралась в 14 релиз.
/p>
Как многие могли догадаться, речь пойдёт о неправильном отображении русской кодировки в модуле CDR, в простонародье – кракозябры в CDR.
Предыстория
Итак, вот вы установили самый последний актуальный FreePBX Distro SNG7-FPBX-64bit-1707-1, долго ждали когда же наконец закончится загрузка 571 пакета (если устанавливаете на VM)
Небольшой оффтоп для тех, кто устанавливает FreePBX 14 на VM и подумал, что процесс установки завис на 571 пакете и надо его прервать – НЕТ, он не завис, наберитесь терпения, правда. Да, это долго, мы, например, ждали полтора часа. Отдохните, попейте кофе, почитайте о нововведениях в FreePBX 14
И, наконец, дождались - всё готово, пора регистрировать абонентов. Вы добавили два внутренних номера с русскими именами, пусть будет Алексей Добронравов и Сергей Злонамеров
Зарегистрировали для каждого по софтфону и провели тестовый звонок – успех. А что же в CDR? Открываете Reports → CDR Reports и видите те самые “кракозябры”, которые мало чем напоминают имена наших внутренних абонентов.
Знакомо? Тогда читай дальше!
Быстро проверим таблицу cdr в базе asteriskcdrdb и убедимся, что там такая же картина:
Решение
Внимание! Прежде чем повторять дальнейшие инструкции – сделайте полный бэкап системы или снэпшот виртуальной машины. Компания Мерион Нетворкс не несёт ответственности за потенциальные проблемы, которые могут возникнуть на вашей IP-АТС. Неправильное выполнение нижеизложенных действий может привести к полной неработоспособности FreePBX и Asterisk!
В интернете можно найти много советов по устранению данной проблемы, начиная от выставления значения charset = utf8 в файле /etc/asterisk/cdr_mysql.conf и выполнения core reload, когда записи опять слетают и заканчивая написанием скрипта, который будет время от времени производить принудительную перекодировку записей. Но всё это либо “костыль”, либо не помогает вовсе.
На сайте разработчика freepbx.org по данной проблеме даже заведён официальный Bug FREEPBX-15268, который по сегодняшний день имеет статус (11.10.2017) DEV TESTING: Unresolved, то есть – не решён.
Более менее действенным способом решения этой проблемы является снос старого MySQL коннектора и установка mysql-connector-odbc-5.3.9 (ANSI Driver), а затем внесение изменений в файл /etc/odbc.ini следующего вида:
[MySQL-asteriskcdrdb]
driver=MySQL ODBC 5.3 ANSI Driver
После этого записи в CDR, конечно, будут отображаться корректно, однако, все логи будут завалены предупреждениями типа:
[2017-10-13 22:31:16] WARNING[8933] cel_odbc.c: Insert failed on 'asteriskcdrdb:cel'. CEL failed: INSERT INTO cel (eventtype,eventtime,cid_name,cid_num,cid_ani,cid_rdnis,cid_dnid,exten,context,channame,appname,appdata,amaflags,accountcode,uniqueid,linkedid,peer,userdeftype,extra) VALUES ('CHAN_START',{ts '2017-10-13 22:31:16.974567'},'Алексей Добронравов','175','','','','s','from-internal','SIP/175-00000001','','',3,'','1507923076.1','1507923076.0','','','')
[2017-10-13 22:31:18] WARNING[8933] cel_odbc.c: Insert failed on 'asteriskcdrdb:cel'. CEL failed: INSERT INTO cel (eventtype,eventtime,cid_name,cid_num,cid_ani,cid_rdnis,cid_dnid,exten,context,channame,appname,appdata,amaflags,accountcode,uniqueid,linkedid,peer,userdeftype,extra) VALUES ('ANSWER',{ts '2017-10-13 22:31:18.631244'},'Алексей Добронравов','175','175','','','175','from-internal','SIP/175-00000001','AppDial','(Outgoing Line)',3,'','1507923076.1','1507923076.0','','','')
При этом в самой таблице cel, на которую ругается сервер, всё будет нормально:
Вроде решение, CDR корректен, но лог будет буквально забит этими предупреждениями, а мы этого не хотим.
Итак, сейчас мы опишем способ решения, после которого и логи будут чистыми и никаких “кракозябр” в CDR вы не увидите.
Для начала, нужно удалить текущий mysql-connector-odbc, однако, в силу того, что он связан зависимостями, вместе с ним удалится и сам Asterisk. Поэтому, сначала нужно узнать, какой именно коннектор установлен на сервере, и удалить его отдельно. Для этого пишем команду:
rpm -qa | grep mysql-connector-odbc
Ну и после предыдущих манипуляций видим, что у нас установлен mysql-connector-odbc-5.3.9-1.el7.x86_64, вероятнее всего у вас будет mysql-connector-odbc-5.3.6. Теперь его нужно удалить, но не учитывая при этом его зависимости. Нам нужно удалить только коннектор, для этого пишем следующую команду:
rpm -e --nodeps "mysql-connector-odbc-5.3.9-1.el7.x86_64"
Теперь нужно установить новый коннектор, но только не от MySQL, а от MariaDB, для этого пишем:
Внимание! Ввод следующей команды без предварительного сноса прежнего коннектора может привести к полному отказу Asterisk!
yum install mariadb-connector-odbc
Теперь проверьте файл /etc/odbcinst.ini в нём обязательно должна быть запись:
[MariaDB]
Description=ODBC for MariaDB
Driver=/usr/lib64/libmaodbc.so
Setup=/usr/lib64/libodbcmyS.so
UsageCount=1
Теперь сделаем перезагрузку fwconsole restart и всё готово. Проводим ещё пару тестовых звноков, смотрим в модуль CDR во FreePBX и проверяем таблицу cdr в asteriskcdrbd:
И логи тоже проверьте, они будут чистыми, никаких предупреждений :)
На этом – всё. Надеемся, что наша статься будет вам полезна и поставит, наконец, точку в истории этого надоевшего всем бага. Выражаем благодарность нашим читателям, которые активно обсуждали данную проблему в комментариях и подсказали правильное направление для её решения.
Виртуализация часто применяется для поиска более простого способа решения некоторых проблем, отмеченных в начальных статьях этой темы, таких как разделение трафика. Как и все в мире сетевой инженерии, здесь есть компромиссы. На самом деле, если вы не нашли компромисс, вы плохо искали. В этом разделе будут рассмотрены некоторые (хотя, конечно, не все) различные компромиссы сложности в области виртуализации сети. Основой этого обсуждения будет триада компромиссов сложности:
Состояние: количество состояний и скорость, с которой изменяется состояние в сети (особенно в плоскости управления).
Оптимизация: оптимальное использование сетевых ресурсов, включая такие вещи, как трафик, следующий по кратчайшему пути через сеть.
Поверхность: количество слоев, глубина их взаимодействия и широта взаимодействия.
Поверхности взаимодействия и группы связей общих рисков
Каждая система виртуализации, когда-либо задуманная, реализованная и развернутая, создает в некотором роде общий риск. Например, рассмотрим одну линию, по которой передается несколько виртуальных каналов, каждый из которых передает трафик. Должно быть очевидным (на самом деле тривиальным) наблюдение, что в случае отказа одного физического канала произойдет сбой всех виртуальных каналов. Конечно, вы можете просто перенаправить виртуальные каналы на другой физический канал. Правильно? Может быть, а может и нет. Рисунок 1 иллюстрирует это.
С точки зрения A и D, есть две линии, доступные через B и C, каждая из которых обеспечивает независимое соединение между хостом и сервером. В действительности, однако, и провайдер 1, и провайдер 2 приобрели виртуальные каналы через единственное соединение у провайдера 3. Когда единственное соединение в сети провайдера 3 выходит из строя, трафик может быть перенаправлен с основного пути через провайдера 1 на путь через провайдера. 2, но поскольку оба канала используют одну и ту же физическую инфраструктуру, ни одна из них не сможет передавать трафик.
Говорят, что эти два звена в этой ситуации разделяют одну общую судьбу, потому что они являются частью Shared Risk Link Group (SRLG). Можно найти и обойти SRLG или ситуации с shared fate, но это усложняет плоскость управления и/или управление сетью. Например, невозможно обнаружить эти shared fate без ручного тестирования различных ситуаций отказа на физическом уровне или изучения сетевых карт, чтобы найти места, где несколько виртуальных каналов проходят по одному и тому же физическому каналу. В ситуации, описанной на рисунке 1, найти ситуацию с shared fate было бы почти невозможно, поскольку ни один из провайдеров, скорее всего, не скажет вам, что использует линию от второго провайдера, показанного на рисунке как провайдер 3, для предоставления услуг.
Как только эти ситуации с shared fate обнаружены, необходимо предпринять некоторые действия, чтобы избежать серьезного сбоя в работе сети. Обычно для этого требуется либо вводить информацию в процесс проектирования, либо усложнять дизайн, либо вводить информацию в плоскость управления (см. RFC8001 в качестве примера типа сигнализации, необходимой для управления группами SRLG в плоскости управления, спроектированной трафиком). По сути, проблема сводится к следующему набору утверждений:
Виртуализация - это форма абстракции.
Абстракция удаляет информацию о состоянии сети с целью снижения сложности или предоставления услуг за счет реализации политики.
Любое нетривиальное сокращение информации о состоянии сети так или иначе снизит оптимальное использование ресурсов.
Единственным противодействием конечному состоянию из этих трех, является протекание информации через абстракцию, поэтому можно восстановить оптимальное использование ресурсов - в этом случае отказ одного канала не вызывает полного отказа потока трафика через сеть. Единственное решение, таким образом, - сделать абстракцию сквозной абстракцией, что снизит эффективность абстракции при контроле области действия состояния и реализации политики.
Поверхности взаимодействия и наложенные плоскости управления
В сетевой инженерии принято накладывать друг на друга два протокола маршрутизации или две плоскости управления. Хотя это не часто рассматривается как форма виртуализации, на самом деле это просто разделение состояния между двумя различными плоскостями управления для контроля количества состояний и скорости изменения состояний, чтобы уменьшить сложность обеих плоскостей управления. Это также часто встречается при запуске виртуальных наложений в сети, поскольку между головным и хвостовым узлами туннеля будет существовать нижележащая плоскость управления, обеспечивающая достижимость, и плоскость управления наложением, обеспечивающая достижимость в виртуальной топологии. Две наложенные друг на друга плоскости управления будут взаимодействовать иногда неожиданным образом. Для иллюстрации используется рисунок 2.
На рисунке 2:
Каждый маршрутизатор в сети, включая B, C, D и E, использует две плоскости управления (или, если это проще, протоколы маршрутизации, отсюда протокол 1 и протокол 2 на рисунке).
Протокол 1 (оверлей) зависит от протокола 2 (базовый) для обеспечения доступности между маршрутизаторами, на которых работает протокол 1.
Протокол 2 не содержит информации о подключенных устройствах, таких как A и F; вся эта информация передается в протоколе 1.
Протокол 1 требует гораздо больше времени для схождения, чем протокол 2.
Более простой путь от B к E проходит через C, а не через D.
Учитывая этот набор протоколов, предположим, что C на рисунке 2 удален из сети, двум управляющим плоскостям разрешено сходиться, а затем C снова подключается к сети. Каков будет результат? Произойдет следующее:
После удаления C сеть снова объединится с двумя путями в локальной таблице маршрутизации в B:
F доступен через E.
E доступен через D.
После повторного подключения C к сети протокол 2 быстро сойдется.
После повторной конвергенции протокола 2 лучший путь к E с точки зрения B будет через C.
Следовательно, у B теперь будет два маршрута в локальной таблице маршрутизации:
F доступен через E.
E достижимо через C.
B перейдет на новую информацию о маршрутизации и, следовательно, будет отправлять трафик к F через C до того, как протокол 1 сойдется, и, следовательно, до того, как C узнает о наилучшем пути к F.
С момента, когда B начинает пересылку трафика, предназначенного для F в C, и момента, когда протокол 1 сойдется, трафик, предназначенный для F, будет отброшен.
Это довольно простой пример неожиданного взаимодействия наложенных протоколов. Чтобы решить эту проблему, вам необходимо ввести информацию о состоянии конвергенции протокола 1 в протокол 2, или вы должны каким-то образом заставить два протокола сходиться одновременно. В любом случае вы по существу добавляете состояние обратно в два протокола, чтобы учесть их разницу во времени конвергенции, а также создавая поверхность взаимодействия между протоколами.
Примечание: Этот пример описывает фактическое взаимодействие конвергенции между IS-IS и BGP, или протоколом Open Shortest Path First (OSPF) и BGP. Чтобы решить эту проблему, более быстрый протокол настроен на ожидание, пока BGP не сойдется, прежде чем устанавливать какие-либо маршруты в локальной таблице маршрутизации.
Всем привет! Мы продолжаем знакомить вас с бесплатным дайлером GoAutodial и сегодня расскажем, как создать простейшую компанию, загрузить в неё лидов для обзвона и, собственно, начать уже пользоваться благами данного решения.
Предисловие
В нашей прошлой статье мы показали пошаговую установку GoAutoDial и остановились на том, что получили доступ к вэб-интерфейсу администратора.
Не лишним будет отметить, что помимо интерфейса администратора, GoAutoDial CE 3.0 устанавливает ещё кучу полезных дополнительных интерфейсов. Ниже приводим таблицу всех доступов и дефолтные пароли всех интерфейсов, которые становятся доступными после установки:
Доступы
Логин
Пароль
MySQL (mysql -u root -p) http://IP-адрес_сервера/phpmyadmin/
root
vicidialnow
Limesurvey (Опросы) http://IP-адрес_сервера/limesurvey/admin/admin.php
admin
kamote1234
Интерфейс администратора – http://IP-адрес_сервера/
admin
goautodial
Интерфейс агента - http://IP-адрес_сервера/agent/
с agent001 до agent020
goautodial
Учётная запись (SIP)
с 8001 до 8020
goautodial
Настройка
Теперь, когда мы разобрались с доступами, переходим к настройке. Пока что нас интересует интерфейс администратора, поэтому просто вписываем адрес нашего сервера в адресную строку любимого браузера и вводим дефолтные реквизиты доступа: admin/ goautodial. Нас встречает довольно симпатичный дашборд:
Управление и навигация в интерфейсе администратора осуществляются с помощью панели задач, которая находится слева. Первое, что необходимо сделать, прежде чем мы сможем начать использовать GoAutoDial по назначению - это, конечно, настройка внешней линии (trunk) для звонков в PSTN. В GoAutoDial это называется - Carriers.
Итак, наводимся на панельку слева и выбираем Admin Settings → Carriers:
Перед нами открывается пошаговый помощник добавления новой внешней линии. Выберем тип Manual и продолжим:
В GoAutoDial доступно два вида аутентификации – IP Based и Registrationв зависимости от того, какой использует ваш VoIP провайдер – выберите подходящий. Заполняем все поля, как если бы создавали новый транк на FreePBX. Подробнее о том, как зарегистрировать транк – читайте в нашей статье. Заполняем все необходимые поля и кликаем Submit. Теперь линию нужно активировать, для этого открываем её ещё раз для редактирования и меняем предпоследний параметр в открывшемся к окне - Active с N на Y.
Отлично, теперь мы можем создать компанию обзвона. Для этого в панели слева выбираем Telephony → Campaigns. Откроется пошаговый помощник, который по умолчанию начнёт создавать компанию. Если вы хотите ввести ID и название компании самостоятельно - поставьте галочку в (check to edit campaign id and name):
Далее необходимо загрузить файл Excel, содержащий необходимые для обзвона данные. Главное- это сами номера и имена абонентов. Вы можете скачать пример нашего файла по ссылке, чтобы понять какой формат распознаёт GoAutoDial (поля не обязательно должны называться именно так как у нас в файле, также вы можете сделать дополнительные поля). Выберите код страны (в нашем случае это 7) и нажмите Next.
Скачать шаблон
Наконец, на последнем шаге выбираем метод набора (Есть автоматический - Auto-Dial, ручной - Manual и предиктивный - Predictive) и транк, который создавали ранее.
Чтобы загруженные лиды отображались корректно на русском, нужно зайти в mysql и для базы asterisk дать команду set names utf8;
Итак, наша компания обзвона готова к использованию, дело за малым. В первую очередь, нужно зарегистрировать на нашем сервере какую-нибудь конечную точку, например –софтфон Zoiper. В SIP Credentials нужно всего лишь ввести адрес нашего сервера, номер и пароль:
После чего, заходим в интерфейс соответствующего агента (в нашем случае agent005, так как его номер - 8005) и выбираем ранее созданную компанию.
Как только мы авторизовались, на наш софтфон поступит входящий звонок, необходимо его принять и не класть трубку, пока не закончится обзвон. Однако, на данном этапе звонки из компании обзвона поступать ещё не будут, так как наш агент стоит на холде. Чтобы начать обзвон – нужно нажать Resume
Можно также выбрать Manual Dial, набрать номер абонента вручную и нажать Dial Now.
После того, как разговор будет завершён можно указать результат звонка: