Asterisk *

Как мы Cisco Phone с SIP дружили
Завелся тут у клиентов новый зверек Cisco CP6921, с виду нормальный телефон только со своими закосами. До этого все cisco настраивались прямо с самого аппарата, да и были они классом повыше 79хх.
Пришлось разгребать кучу мануалов. Перепробовать кучу конфигов. Пости на любом конфиге телефон понимает инструкцию версии прошивки и в случае чего перепрошивается. На какой то версии конфига он не понимает чего от него вообще мы хотим и раз в секунд 30 перезагружает конфиг. Но ни одного пакета не шлет к астериску.

Немногим известно, что IP телефоны Digium — это не совсем обычные телефоны. Казалось бы зачем производителю выпускать аппараты собственной марки на таком насыщенном и низкомаржинальном рынке? Но поверьте — оно того стоило. Помимо отличных физических характеристик: приятный пластик, яркий экран, отличные динамики и микрофон. Эти аппараты обладают своим API и вы можете написать свое приложение под них!

Кто другой может похвастаться таким функционалом?

Добрый день уважаемые читатели. Началась история в маленькой компании, но со множеством отделов, разделённых глухими бетонными стенами. Занимала она в многоэтажке несколько помещении, а в жилых домах сегодня популярны домофоны. Домофон это хорошо, но когда одна трубка и работников то одних нет на месте, то других, в следствии динамичной работы, уж и не знаешь где её разместить. К тому же, беготня до трубки, очень отвлекает от работы. Пускать всех подряд не вариант, жильцы очень строги, тем более был печальный случай с ограблением старушки в этом подъезде. Что же можно придумать, чтобы угодить жильцам и сотрудникам компании? Ответ был найден на просторах Интернета «Скрестить АТС с домофоном» и желательно недорого.

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

Компания выпускает IP устройства оповещения: динамики громкой связи, домофоны, усилители, индикаторы звонка, адаптеры, ассессуары и прочее. И все это работает по протоколу SIP.

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

Возникла необходимость в интеграции офисной АТС (Asterisk) и промышленной АТС (Миником DX-500).

У производителя DX-500, есть решение MSG-1, но в рамки ограниченного бюджета оно не влезло.
Было решено интегрироваться через канал Е1, благо был как-раз свободный.
У меня уже были проекты интеграции Asterisk по Е1, и через раз в них были жесточайшие пляски с бубном вокруг прерываний для плат интерфейса E1, плюс они ограничивают возможности виртуализации, по этому плату брать остро не хотелось.
Давно хотелось попробовать ELF2-AE от Новосибирской Parabel.

Не большая предыстория

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

Итак, что мы имеем: офисная АТС на Asterisk (версия = 1.8.15.1), реализована функция перехвата вызова и уведомлений о звонке через jabber.

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

В Asterisk версии 12 появился REST интерфейс (Asterisk REST Interface — ARI).

Да, это RESTful API в натуре.

Пока имеются следующие ресурсы:

• Asterisk
• Bridges
• Channels
• Endpoints
• Events
• Recordings
• Sounds
• Applications
• Playbacks
• Devicestates
• Mailboxes

Или, интерфейсы к Каналам, Девайсам, Бриджам, Записям, Звукам. Вероятно, будут наращивать мощности :-)

Ну и главная фишка, это возможность подключения через WebSocket на /ari/events и в режиме постоянного соединения получать события.
В отличие от AMI, тут гуляют объекты в JSON формате, и работать с событиями крайне удобно.
Пример скрипта на ARI:

Так как не все sip-телефоны умеют автодозвон, а иногда хочется его иметь, я попробовал его реализовать средствами *. Сам собой напрашивается вариант через call-файлы, но тут есть одна неприятность: при соединении у обоих абонентов аппараты звонят одновременно, и когда адресат автодозвона снимает трубку и слышит гудок ожидания, он иногда пугается и вешает трубку (хотя, у меня в офисе все довольно быстро привыкли). Я опробовал 2 варианта, второй показался мне более универсальным и логичным. Различаются они необходимостью править (переназначать) дефолтный контекст from-internal.

Хочу поделиться с хабросообществом Астерискеров и IP телефонистов о том, как мы провели двух-дневную конференцию в Дубне на прошедших выходных.

Кстати сказать, это вторая в России конференция по Asterisk. Дэвид Даффетт из Digium, прилетевший из Лондона, рассказал, что самое активное сообщество в Канаде, где каждый месяц собирается 70-100 астерискеров (вот бы у нас так!). Забегая вперед, скажу, что всем так понравилось, что организаторы конференции подписались делать это каждый год.

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

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

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




Ну а кому интересно долго и во всех подробностях, милости прошу под кат.

Предисловие

В прошлом году компания, в которой я работаю, стала активно переходить на IP-телефонию. Для этих целей был использован дистрибутив FreePBX. Опыта работы с телефонией практически не было, поэтому проблем было много. Всего у нас используется 2 сервера FreePBX, примерно по 30 транков на каждом. Некоторые транки ведут себя не очень хорошо и порой теряют регистрацию. Поэтому возникла необходимость мониторить состояние регистрации, чтобы узнавать о неработающей телефонии раньше пользователей.
Для мониторинга IT-инфраструктуры мы уже давно используем Zabbix. Заводить элементы данных на каждый транк (т.е. около 60) — задача нудная, утомительная и неинтересная. Кроме того, надо постоянно следить за списком транков в мониторинге и актуализировать его. Поэтому, решено было использовать одну из самых интересных особенностей этой системы мониторинга — низкоуровневое обнаружение. Итак, что было сделано.

Задача: Настроить телефоны (или любой другой абонентский девайс) автоматически на основе MAC-адреса, желательно не доставая устройство из коробки.

Идея централизованной настройки абонентских устройств давно была у меня и, наконец, нашла свою реализацию в одном из проектов. Видео в конце поста.
Практически все (Cisco, Polycom, D-Link, Escene) IP-телефоны, с которыми мне доводилось встречаться, в том или ином виде поддерживают централизованную настройку с сервера, т.е. Auto-Provisioning по нашему автопровизия. В данном случае рассмотрен пример с телефонами Polycom, но по сути, аналогичный подход позволит настроить любой телефон с определенными корректировками.

Как это работает (про Polycom)?

Телефон по умолчанию настроен на получение IP-адреса по DHCP, помимо самого адреса телефон получает от DHCP ряд опций в числе которых обычно указываются шлюз, маска сети и DNS- сервер, кроме того можно указать SNTP-сервер и еще много чего. Polycom’ы смотрят по умолчанию в опцию 66 и 160, там они пытаются найти адрес/имя сервера автопровизии. Если телефон обнаруживает адрес сервера, он пытается подключиться к нему по уполчанию через FTP (поддерживает еще HTTP, HTTPS, TFTP), используя в качестве логина и пароля:

Username	PlcmSpIp
Password	PlcmSpIp

Телефон запрашивает у сервера версию (файл sip.ver) и сами файлы прошивки и конфигурационные файлы. Телефон выкачивает новую прошивку, обновляется, затем после перезагрузки снова обращается к серверу, видит, что ПО не требует обновления, скачивает и применяет конфигурационные файлы в формате XML. В общем случае аппарат запрашивает следующие файлы.

Недавно в компании сменили IP-телефоны. На замену gigaset'ам пришли cisco SPA504G и cisco SPA303. В телефонии я не специалист, поэтому режим dnd (Do not Disturb) был для меня новинкой. Новинка быстро прижилась в компании. Но вот незадача: телефон при переключении режимов никоим образом не уведомляет сервер. Звонок на недоступный телефон заканчивался статусом «занято». Звонящему оставалось гадать — разговаривает абонент сейчас по телефону или его нет на месте. Вот эту проблему я решил исправить.

Доброго времени суток, уважаемые хаброжители.

Усилиями сотрудников нашей компании уже были проведены тестирования телефонов Digium с Asterisk, AsteriskNow и Switchvox. На мой взгляд, было бы некорректно не дополнить данный список тестированием работы телефонов с популярным дистрибутивом Elastix.

Заинтересовавшихся прошу под кат.

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

• Воспроизвести заранее записанный файл
• Произнести персонализированную задолженность пользователя
• Соединить с оператором при желании пользователя
• Иметь веб интерфейс и статистику

В первой части мы установили MySQL и собрали Астериск из исходников с поддержкой res_config_mysql (Asterisk Realtime Architecture)

Настройка DHCP-сервера

У меня в двух рабочих средах развёрнуты разные DHCP-серверы, покажу настройки для трёх самых (имхо) популярных: Windows Server DHCP, Mikrotik, DNSMasq

Исходные данные

Итак, у нас есть желание развернуть офисную телефонию на Астериске.
Отличное желание, прекрасное open-source решение.

OS: Centos 6.5 64-bit
PBX Version: Последний стабильный релиз из SVN (в данный момент это Asterisk SVN-branch-12-r409131)
Телефоны: Тут выбор пал на Cisco SPA504G (для SMB-сегмента рынка)

Часто попадали в ситуацию когда на мобильном обнаруживаешь пропущенный звонок с городского и при попытке перезвонить попадаешь на голосовое меню какой-нибудь фирмы и совершенно непонятно кто тебе звонил? Я часто, а также и клиенты нашей компании каждый день сталкиваются с этим… С этим решено было что-то делать. Все последующие действия актуальны для trixbox v2.8.0.4 (с некоторыми корректировками или, возможно, даже без них можно реализовать и на других системах)

Предисловие

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

Введение

Как компании «доходят» до разработки CRM «под себя» и собственной телефонии — вопрос скорее политический и бизнесовый, чем технический, поэтому на вопросы «зачем» ответов дать не смогу. Но факт остаётся фактом — в один прекрасный день нам понадобилось решение, способное обеспечить взаимодействие телефонной части с CRM.

Исходные данные:

• 2 колл-центра (далее — КЦ) на большом расстоянии (один в РФ, второй, скажем, в Эстонии)
• порядка 500 одновременно работающих операторов в каждом (входящие и исходящие звонки)
• одна точка входа (для простоты считайте, что сервер CRM всего один)
• оба КЦ обрабатывают звонки по РФ
• у каждого КЦ — свой сервер Asterisk (для простоты будем считать, что все Asterisk настроены и в полностью рабочем режиме)
• CRM является client-server приложением с web-мордой

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

Но, к сожалению, выше приведенное утверждение верно только для крупных городов России и СНГ. А как же поступать в случаях, где SIP недоступен? Использовать PRI? Довольно дорого, тем более для маленькой компании с небольшим количеством звонков, да и опять же не везде доступно. Использовать аналоговую телефонию по старинке? Безусловно, нет. Ответ кажется довольно очевидным: GSM-шлюз решит все ваши проблемы.

На первый взгляд, все довольно просто в реализации, однако при более детальном продумывании станет понятно, что шлюз сам по себе мало функционален и является лишь своего рода преобразователем GSM в SIP, а для реализации пусть и незаоблачных, но все-таки “хотелок” необходима АТС (например IVR, маршрутизация, очереди). Для минимизации процесса затрат допустим, что это наш любимый open-source Asterisk. Если речь идет уж о совсем глобальной экономии, то можно сразу сказать: “Ага, а сервер под Астериск? Он тоже не бесплатный!” (Хотя по-моему мнению у запасливого админа всегда найдется железка под Астер:))

А теперь представьте, что все выше написанное можно реализовать всего лишь средствами одного GSM-шлюза? Невероятно? Что ж, прошу под кат.

Поисковые системы выдают огромное количество результатов разной полезности на запрос вынесенный в заголовок.
На Хабрахабре такой статьи не нашел, а значит её нужно написать!
За основу я взял проект asterisk cdr viewer.
Перевел язык web интерфейса на великий могучий и «озвучил» его, т.е. добавил возможность прослушивать файлы записей разговоров в браузере, а так же скачивать их.
Количество полей фильтра сокращено до минимума, остались только самые необходимые.
Скриншоты, сорцы и подробное описание инсталляции уютно разместились под хабракатом.

UPDATE_2016
Готов новый интерфейс.
Небольшой видео-гайд:

Подробнее здесь