Pull to refresh

Comments 21

Возможно, стоит вынести клиентский код в расширение для браузера — тогда не нужен будет wormhole и уведомления будут работать на любых сайтах.
Это, конечно, от задачи зависит. Мы реализовывали подобную систему, но у нас были совсем другие задачи и условия, поэтому и решение в итоге получилось совсем другое.
Интересный подход, реализовали что-то подобное (у нас не входящие звонки, а пропущенные вываливаются в хром-плагин), но совсем другими средствами.
Если пропущенные, значит, смотрите в CDR?
У вас есть что-нибудь в паблике, а то мне тоже скоро предстоит эта задача, может, удастся сэкономить какое-то время.
у нас «самодельный» CDR, тк в астерисковом много лишних данных, если интересно можем обменяться опытом, пишите в личку.
Было бы интересно почитать про самодельный CDR.
Т.е. вы раз в 1 секунду бомбите астериск запросами CoreShowChannels, чтобы получить актуальные данные?
А еще зачем вам memcache, если у вас есть демон? Все актуальные данные о звонках вы можете хранить в памяти демона, не так ли?
Почему выбрали SSE, а не websockets?
Исходников на гитхабе не будет (попробовал бы ваше решение, но выдергивать из статьи долго)?
Действительно было бы полезно более целостное решение в виде исходников посмотреть. Сэкономит массу времени. Желательно с версткой.
Приходится бомбить, другого решения на тот момент не нашли. При event'ах теряется информация и оповещение приходит намного позже. Интеграция через push api от Asterisk'а в процессе. Возможно получится интегрировать и получение звонка.
С демонами столкнулся первый раз, тем более на php, поэтому был выбран memcache для передачи данных. А как получать данные на странице из демона тогда?
SSE как временное быстрое решение, дальше думаем подключить websocket, и вообще переписать на Go.
Как время появится, выложу на github.
А как получать данные на странице из демона тогда?

демон по идее может делать несколько дел одновременно: 1) пулять запросы в астериск и обрабатывать ответы на них, 2) быть веб-сервером, который делает SSE и/или websocket.

Как время появится, выложу на github.

А я стал практиковать другой подход: все временное и быстрое на гитхабе, а уже как становится близко к рабочему варианту уходит в закрытые репо.: ) Поэтому на ранних этапах всегда можно спросить, обсудить, поделиться, а затем уже прятать "сокровище". Например, у меня есть похожий проект: https://github.com/antirek/asti на node.js, который получает от астериска события очередей Queue и отдает их подключившимся клиентам по ws через js-либу https://github.com/antirek/asti.js В итоге на какой-либо странице подключаем asti.js и вешаем обработчики на определенные события, т.е. делаем всплывающие подсказки, моргания, запрос доп.данных из CRM.
у меня проще — демон на php слушает ami, делает выводы и держит в памяти структуру с актуальными данными, а другой скрипт по обращению с нему считывает структуру в массив и отдает нужные данные юзеру по https.
Ну а с той стороны хоть 1Ска, хоть веб-срм…
Поправьте если ошибаюсь: событие Bridge с состоянием Link генерится когда 2й абонент (которому звонят) поднимает трубку, т.е. и всплывающие сообщения у вас отображаются только после того как сотрудник снимет трубку ?

Обновите Asterisk, с 12й версии в AMI появилось событие AttendedTransfer, которое позволит вам подставлять/анализировать правильный номер телефона при переводе звонка между сотрудниками.
Да, Link генерируется после установки определенного соединения. Это еще одно условие, почему остановились в итоге на CoreShowChannels, при данном подходе сообщение показывается уже при начале звонка.

Спасибо, я читал про 12-ю версию, там все намного лучше, но к сожалению возможности обновления Asterisk'а нет, так как он находится не под нашим контролем, поэтому приходится писать вот такие штуки :)
Попробуйте тогда NewState, это событие уже есть в 11й версии.
Схема с прослушиванием событий AMI всё таки элегантнее, чем дергать asterisk -rx "core show channels"
можно же перед тем как dial к менеджеру вызывать отправить сообщение на сервер который отправит инфу в веб менеджера.
Тогда не надо бомбить астериск по АМИ. Он сам все сделает.
Интеграция через api в процессе, необходимо было быстрое решение.
Я бы лучше диалплан поправил и вписал бы в него оповещения во внешнюю систему — http://www.voip-info.org/wiki/view/Asterisk+cmd+System, в браузер воткнул бы pushbullet, а через setvar в параметрах пира бы токен вписывал. Трудозатраты вся конструкция бы заняла минут 5.

Из практики PAMI php на 1.8 астере вызывал иногда проблемы со стабильностью АТС.
Скорее всего, проблемы со стабильностью вызываются тем, что клиенты в конце скрипта не отключаются и их копятся тысячи. Мы наступили на эти грабли, но ни на что, кроме этого, пользователи не жаловались никогда.
Я тоже делал нечто такое, если кому интересно, демка лежит: http://callcenter.softcom.lv/
Она правда корявая, но если выбирать "зайти под оператором" а не админом то иде будет ясна.

Мы использовали именно уведомление от астериска, на каждый входящий звонок в диалпланах я делал post запрос на связку NodeJS + laravel, а они фигачат уже уведомления операторам.

На Git пока выкладывать не хочу, потому что ещё надеюсь на этом немного монет заработать, когда доведу до ума версию :) но консультации дать могу
позалипал на анимации подгрузки данных: )
По доброй традиции хаба «Клиентская оптимизация» поинтересуюсь:
— автор, вам известно значение термина, давшего название упомянутому хабу?
— какое отношение этот топик имеет к предметной области, описываемой этим термином?
Only those users with full accounts are able to leave comments. Log in, please.