Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 25
Несколько лет назад подобную задачу решали на nodejs. Не знаю как сейчас, но в тот момент экосистема nodejs для подобных сервисов была предпочтительнее.
Даже мне, как пхпшнику, было проще работать с Asterisk'ом с помощью NodeJS. Как-то проще, что ли.
Само веб-приложение работает на apache — php — mysql. Так что подключать туда js не хотелось, да и если признаться не очень хорошо я знаю js. Но соглашусь, с websocket работать в nodejs куда удобнее.
crm была в облаке (sfdc), в ней таких вещей не сделаешь, поэтому решение должно было хоститься на своих мощностях. По этой причине было больше свободы в выборе инструментов. PHP не рассматривали по вышеописанной причине, хотя 2 из 3х разработчиков пхппешники, третий — perl. Прототип на perl пхпешникам не вкатил )), попробовали на nodejs — покатило, даже без экспертных знаний в JS
зы
сейчас бы сделал на GO
зы
сейчас бы сделал на GO
Лет 10 назад делал на C#. Вообще без разницы на чем делать. Если что-то может создать TCP клиента — работать будет.
На самом деле могу начаться холивары про демонов на PHP, но нода действительно удобнее. Сменили всех пхп(pami) демонов на аналогичных js -> nami
Ваше решение превращает браузер в телефон?
То есть то, что написано в статье не отговорило вас задать этот вопрос?)
Моё решение позволяет видеть телефонный номер в веб-приложении и искать по номеру клиента.
Моё решение позволяет дозваниваться с телефонного аппарата (физического) до клиента. При этом вызов инициируется из веб-приложения т.е. диспетчеру не нужно набирать номер на телефонном аппарате (физически тыкать пальцами не нужно), а разговор всё также идёт через трубку (не софт телефон).
Так что даже и не знаю, является ли браузер телефоном. При определённой модификации точно им может стать.
Моё решение позволяет дозваниваться с телефонного аппарата (физического) до клиента. При этом вызов инициируется из веб-приложения т.е. диспетчеру не нужно набирать номер на телефонном аппарате (физически тыкать пальцами не нужно), а разговор всё также идёт через трубку (не софт телефон).
Так что даже и не знаю, является ли браузер телефоном. При определённой модификации точно им может стать.
Уведомление о входящем, ответе на него и завершении звонка:
https://github.com/antirek/asti — сервер
https://github.com/antirek/asti.js — клиент для браузера
и да, nodejs
выложите ваш пример на гитхаб, можно будет попробовать
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/
По поводу рабочего решения — вы же уже выложили все, только по кусочкам, уже могут не понять — теперь эти же файлы в репо на гитхаб. И всё.
В общем, развития в решении ваших задач. Не останавливайтесь!
Присоединяйтесь к чату по астериску 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, но так больше геморроя.
Нет, можно конечно отслеживать переадресации по спец событиям, в которых есть unique_id1 и unique_id2, но так больше геморроя.
В СEL есть один серьезный недостаток из зак которого этот механизм довольно неудобно использовать в чем то еще кроме логирования:
Выборки из CEL очень дорогие операции хотя бы по тому что UniqueID и LinkedID это строковые значения.CEL даже при минимальной конфигурации кладет в бд очень много записей (взять chanStart и chanEnd например — это 4 записи на один звонок) соответственно все это дело может вызвать рассинхронизацию при запросе из за long query со всеми вытекающими.
Выборки из CEL очень дорогие операции хотя бы по тому что UniqueID и LinkedID это строковые значения.CEL даже при минимальной конфигурации кладет в бд очень много записей (взять chanStart и chanEnd например — это 4 записи на один звонок) соответственно все это дело может вызвать рассинхронизацию при запросе из за long query со всеми вытекающими.
Тоже решал подобную задачу еще года 3 тому назад на nodejs, даже в мыслях не было что подобная поделка на пару часов работы, заинтересует кого-либо на хабре.
Делал что-то похожее, только у меня был питон. От самописных демонов отказался, сделал через AGI.
Между клиентом и астериском у меня поднят centrifugo. Из астериска через dial plan вызывается скрипт, в который передается внутренний номер клиента и входящий номер (долго искал эти значения, помог verbose режим в консоли астериска). Клиент подключается к той же centrifugo на канал со своим внутренним номером и получает эти сообщения.
А вот исходящие через AMI сделаны.
В итоге кода минимум — десяток строк на скрипт, пару строк на исходящий (но тут уже заслуги сторонней библиотеки, так бы чуть больше вышло).
Между клиентом и астериском у меня поднят centrifugo. Из астериска через dial plan вызывается скрипт, в который передается внутренний номер клиента и входящий номер (долго искал эти значения, помог verbose режим в консоли астериска). Клиент подключается к той же centrifugo на канал со своим внутренним номером и получает эти сообщения.
А вот исходящие через AMI сделаны.
В итоге кода минимум — десяток строк на скрипт, пару строк на исходящий (но тут уже заслуги сторонней библиотеки, так бы чуть больше вышло).
Я читал и про ARI и про AGI. Ещё был предложен вариант сделать через веб-интерфейс телефонного аппарата, но его я отбросил сразу по целому ряду причин.
Обмозговав всё, было решено идти через AMI. В asterisk`e не силен и влезать в dial plan не очень хотелось. Так что от AGI я отказался. В ARI я не нашел всё, что мне было нужно.
Обмозговав всё, было решено идти через AMI. В asterisk`e не силен и влезать в dial plan не очень хотелось. Так что от AGI я отказался. В ARI я не нашел всё, что мне было нужно.
В свое время тоже написал три варианта для различных интеграций — демон, прослушивающий ami; вызовы agi из диаплана; асинхронные вызовы скриптов через вебсервер из диаплана через system — wget.
Последнее показало лучшую производительность при прочих равных. Один нагруженный проект прошел эти три стадии и остановился на последнем варианте.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Asterisk и информация о входящих звонках в браузере