Pull to refresh

Comments 25

Несколько лет назад подобную задачу решали на nodejs. Не знаю как сейчас, но в тот момент экосистема nodejs для подобных сервисов была предпочтительнее.
Даже мне, как пхпшнику, было проще работать с Asterisk'ом с помощью NodeJS. Как-то проще, что ли.
Само веб-приложение работает на apache — php — mysql. Так что подключать туда js не хотелось, да и если признаться не очень хорошо я знаю js. Но соглашусь, с websocket работать в nodejs куда удобнее.
crm была в облаке (sfdc), в ней таких вещей не сделаешь, поэтому решение должно было хоститься на своих мощностях. По этой причине было больше свободы в выборе инструментов. PHP не рассматривали по вышеописанной причине, хотя 2 из 3х разработчиков пхппешники, третий — perl. Прототип на perl пхпешникам не вкатил )), попробовали на nodejs — покатило, даже без экспертных знаний в JS

зы
сейчас бы сделал на GO
Лет 10 назад делал на C#. Вообще без разницы на чем делать. Если что-то может создать TCP клиента — работать будет.
На самом деле могу начаться холивары про демонов на PHP, но нода действительно удобнее. Сменили всех пхп(pami) демонов на аналогичных js -> nami
В моё время js не был мейнстримом, а вот php вполне. Исторически сложилось что в php я знаю чуть больше, чем в js.
Ваше решение превращает браузер в телефон?
То есть то, что написано в статье не отговорило вас задать этот вопрос?)
Моё решение позволяет видеть телефонный номер в веб-приложении и искать по номеру клиента.
Моё решение позволяет дозваниваться с телефонного аппарата (физического) до клиента. При этом вызов инициируется из веб-приложения т.е. диспетчеру не нужно набирать номер на телефонном аппарате (физически тыкать пальцами не нужно), а разговор всё также идёт через трубку (не софт телефон).

Так что даже и не знаю, является ли браузер телефоном. При определённой модификации точно им может стать.
Не сможет.
Чтобы браузер стал телефоном нужна поддержка webRTC и коннект конечных устройств к АТС по webRTC. То есть это перестроение архитектуры вашего приложения.
Уведомление о входящем, ответе на него и завершении звонка:
https://github.com/antirek/asti — сервер
https://github.com/antirek/asti.js — клиент для браузера
и да, nodejs

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

С исходниками хуже. Боюсь в компании не поймут, если я выложу готовое рабочее решение. Но и по тому, что я выложил можно сделать рабочий вариант.
nodejs и не моё: ) просто как инструмент для подобной задачи оказался проще, чем php (phpDaemon, Ratchet), python (twisted, tornado) (тем более что это все в той или иной мере использую достаточно регулярно). Но всему свое время.

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

В общем, развития в решении ваших задач. Не останавливайтесь!
Присоединяйтесь к чату по астериску http://chat.asterisk-support.ru/
У меня подобная штука в фирме используется для оповещения о звонках в ЦРМ (веб). Только с событий newstate/hangup/etc мы ушли на CEL events, оказалось удобнее. Звонок в событиях связан одним linked_id и всегда можно легко отследить все события одного звонка. В newstate/hangup/etc, если память не изменяет, нету общего связующего linked_id.
Вот это интересно. Я если честно дампил все события и выбирал те, что мне подходят. И нужную мне информацию можно выло взять из многих событий. Спасибо за наводку.
Честно говоря, на 100% утверждать не берусь, но вроде было так. События newstate/etc связаны между собой unique_id, которых в процессе разговора может быть несколько (например при любой переадресации заводится новый), а связующий целиком весь звонок linked_id я получил только в CEL ивентах, после их введения и переработки интеграции под них, путаница отпала.
Нет, можно конечно отслеживать переадресации по спец событиям, в которых есть unique_id1 и unique_id2, но так больше геморроя.
UFO just landed and posted this here
UFO just landed and posted this here
В СEL есть один серьезный недостаток из зак которого этот механизм довольно неудобно использовать в чем то еще кроме логирования:
Выборки из CEL очень дорогие операции хотя бы по тому что UniqueID и LinkedID это строковые значения.CEL даже при минимальной конфигурации кладет в бд очень много записей (взять chanStart и chanEnd например — это 4 записи на один звонок) соответственно все это дело может вызвать рассинхронизацию при запросе из за long query со всеми вытекающими.

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

С asterisk столкнулся впервые. Поэтому было приятно почитать на этом сайте статьи данной тематики для первого шага. А так и не знал с какой стороны подступиться. Думаю не мало людей также сталкиваются с подобным. Я добавил ещё один из вариантов со своими преимуществами и недостатками
Делал что-то похожее, только у меня был питон. От самописных демонов отказался, сделал через AGI.
Между клиентом и астериском у меня поднят centrifugo. Из астериска через dial plan вызывается скрипт, в который передается внутренний номер клиента и входящий номер (долго искал эти значения, помог verbose режим в консоли астериска). Клиент подключается к той же centrifugo на канал со своим внутренним номером и получает эти сообщения.
А вот исходящие через AMI сделаны.
В итоге кода минимум — десяток строк на скрипт, пару строк на исходящий (но тут уже заслуги сторонней библиотеки, так бы чуть больше вышло).
Я читал и про ARI и про AGI. Ещё был предложен вариант сделать через веб-интерфейс телефонного аппарата, но его я отбросил сразу по целому ряду причин.
Обмозговав всё, было решено идти через AMI. В asterisk`e не силен и влезать в dial plan не очень хотелось. Так что от AGI я отказался. В ARI я не нашел всё, что мне было нужно.

В свое время тоже написал три варианта для различных интеграций — демон, прослушивающий ami; вызовы agi из диаплана; асинхронные вызовы скриптов через вебсервер из диаплана через system — wget.


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

Sign up to leave a comment.

Articles