Asterisk *

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

Очень часто, созданию базы данных CDR отводится мало места в описаниях настройки. Как правило, все сводится к цитате SQL команд и обещанию, что если кинуть ее в консоль то «все будет ОК».

В Asterisk 2 типа трансферов:

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

Мне понадобилось совместить простоту первого и функционал второго. Без AMI/ARI/AGI. Без костылей.

Велосипед под катом.

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

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

Каждый, кто занимался организацией телефонии, сталкивался с фразой «Плохая связь!». А что такое «плохая связь»? С одной стороны это субъективный параметр, с другой стороны это вполне конкретные цифры. Полагаться на субъективные оценки пользователя мы не будем, потому что это не «тру». Попробуем оценить качество связи вполне конкретной цифрой.

Очень неожиданная новость пришла из солнечной Испании, где разрабатывают популярную надстройку под названием Elastix для управления в первую очередь Asterisk, а во-вторую большим количеством дополнительных сервисов, удобно собранных в одном дистрибутиве. Есть возможность наращивания функционала с помощью модулей. Дистрибутив с большим комьюнити по всему миру. Первая версия была представлена в 2006 году, более 3 миллионов загрузок дистрибутива на сегодня.

И сегодня появилась новость от разработчиков про Elastix 5.

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

Пришлось побывать мне в офисе некоторой компании, где использовались только аналоговые телефоны. И у этих людей было стойкое желание перейти хотя бы отчасти на IP телефонию с возможностью «протянуть» телефоны из внешней сети. Как АТС у них использовалась аппаратная Avaya. Все было заведено на нее: роботы, диалпланы, режимы работы. Полностью готовый офис. Но аналоговый.

«К Avaya можно подключить и IP телефоны», – скажете вы. И будете правы. Но т.к. это полностью проприетарный продукт – нужна лицензия и стоит эта лицензия очень ощутимых денег – больше стоимости самих IP-телефонов. Причем лицензии нужны на все. Была поставлена задача: создать гибридную связь с разумным количеством IP телефонов в пределах сети с минимальными затратами.

Очередной вебинар от команды Centos-admin.ru пройдет в ближайшую среду, в 12-00 по московскому времени. Мы расскажем о том, зачем и каким образом можно использовать базы данных в связке с Asterisk. Поговорим о встроенной базе данных AstDB и о подключении к внешним СУБД.

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

Прямая ссылка на видео | Cсылка для регистрации

Приглашаем всех желающих 23 ноября. Приходите!

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

У большинства администраторов, работающих с телефонией на базе Asterisk, в компаниях, где штат превышает 500+ сотрудников, рано или поздно встает вопрос о полноценной кластеризации Active/Active. Предпосылками к этому может быть и наличие региональных ответвлений, и желание сделать систему надежнее. Тема обширная и не является целью данной статьи в полном объеме, которая написана с целью показать один из самых быстрых и надежных способов добыть информацию о регистрации устройств на серверах в кластере, с целью последующей централизации или/и дистрибуции внутри кластера. Логично предположить, что самый производительный способ — это быть частью самого Asterisk.

Прочитав заголовок, вы, наверное, подумаете «Избитая тема, да сколько можно об это писать», но всё равно не смог не поделиться своими велосипедами с костылями наработками.

Введение

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

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

Приветствую, астерискеры и сочувствующие! Вчера ночью на одном популярном форуме в тематике asterisk наткнулся на вопрос: как же можно «по быстрому» защитить свой номер 8800 от методики, которую нередко используют конкуренты — многократному дозвону на номер для срабатывания тарификации у владельца номера?

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

Есть система дистанционного обслуживания – клиент может позвонить в call-центр и проверить/изменить настройки своей учётной записи без участия оператора. Для перехода по меню и управления настройками используются тональные сигналы (DTMF). АТС в свою очередь взаимодействует с ядром основной системы через API, возвращая результаты пользователю в виде голосовых сообщений.

Задача: настроить автоматизированную проверку системы (правильно отвечает на запросы/выполняет нужные команды).
Главные требования:

• максимальная правдоподобность имитации пользователя: т.е. нужно именно звонить и нажимать кнопки, а не вызывать методы API в обход call-центра.

  
  

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

  
  

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

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

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

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

Нужны были более "мягкие" и простые способы для расширения функций и интеграции с другими системами.

Так появились интерфейсы AGI и AMI.

FreePBX — это наиболее популярный web интерфейс для настройки серверов на базе Asterisk. FreePBX — это гибкая, модульная система. Предлагает богатый функционал по настройке станций. Самое приятное — это проект с открытым исходным кодом.

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

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

Очередной вебинар от команды Centos-admin.ru пройдет в ближайший понедельник, в 12-00 по московскому времени. В этот раз мы рассмотрим использование FreePBX для быстрого развертывания системы офисной телефонии. Плюсы и минусы, основные настройки.

Вебинар рассчитан на системных администраторов, еще не имеющих опыта работы с FreePBX.

Прямая ссылка на видео | Cсылка для регистрации

Приглашаем всех желающих 29 августа. Приходите!

В этой статье хочу рассказать, как мы решили не типовую задачу на FreePBX. Под определением «не типовую» я имею в виду, что ее нельзя решить стандартными средствами, без дополнительных инструментов.

Предыстория

Есть группа сотрудников, которая занимается обзвоном клиентов. Дабы экономить на исходящих звонках, для разных направлений используются разные номера телефонов. Это спокойно решается с помощью шаблонов (масок) номеров в Outbound Routes. Но часть направлений, например, звонки на мобильные, остается платным. Чтобы в конце месяца счет компании за телефонные услуги не перевалил XXX$, необходимо жестко контролировать и, при необходимости, ограничивать соответствующие направления звонков.

Задача

Установить индивидуальный дневной лимит для группы менедежеров. Запретить исходящие звонки на определенные направления при исчерпании лимита. При достижении пороговых значение: >50%, >90% и >100% отправлять соответствующее уведомление на email сотрудника. Если сотрудник в течении дня полностью не исчерпал свой дневной лимит, остаток должен перейти на следующий день.