Покемон живет на странице с описанием API, т.е. в разделе, который заведомо интересен определенной аудитории. А полезная страница — это страница с контактами разработчиков, с которыми можно пообщаться, если есть вопросы по API.
>>В этом вся суть современного интернета — всё полезное спрятано и доступ к нему неочевиден.
Ох, как вы правы. Сейчас столько информации в закрытых социальных сетях, мессенджерах и других системах.
Проблемы с многими нишевыми вещами от отсутствия спроса, а спроса нет, т.к. нет понимания, что это удобнее. Будет спрос — будет развитие. Поэтому надо чаще упоминать об удобных инструментах, участвовать в жизни сообществ. Кстати, вы знаете про чат астерискеров? http://chat.asterisk-support.ru/
можно и так заморочиться, только это зависит теперь от работы БД с cdr'ами
> имеют аллергию на pbx_lua
есть два типа астерискеров: одни пишут на lua, другие его еще не пробовали: )
Аккуратное решение задачи.
Но в целом, на системе которая обслуживает на номере 8800 десятки-сотни звонков в минуту, проще использовать in-memory db, redis например. В редис данные имеют время жизни, т.е. пришел вызов, положили номер в бд с ttl 5 минут. Когда пришел следующий, проверили, если есть в бд по критериям, то hangup.
Может быть когда-нибудь включат в стандартную поставку возможность работы с redis напрямую из стандартного диалплана asterisk (вот уже есть проект https://github.com/tic-ull/func_redis), пока можно использовать redis-lua в диалплане на lua.
Тестировать более логично программный код, поэтому удобнее использовать диалплан на lua.
Если вы будете развивать систему долгие годы, то посмотрите в сторону lua: разделение на компоненты диалплана, тесты каждого компонента и т.д. Т.е. всю логику можно тестировать и без реального астериска. Это не исключает тестирования «боевого поведения пользователя», но отделит тестирование логики от тестирования боевого поведения и сделает второе более простым.
У вашего подхода есть хороший плюс — он сразу проверит прохождение тональных сигналов, но и это можно сделать отдельным тестом по вашему подобию и тоже на lua; )
P.S. Впервые вижу, что кто-то так заморочился тестированием ivr, это впечатляет.
Наверное, можно было бы вынести всю логику во внешнее приложение AGI, которое бы вам в диалплан возвращало только значение можно звонить или нет, не надо было бы переписывать диалплан.
Использование и xml, и бд? Можно все хранить в БД?
Зачем выкладывать куски кода на хабр? Выложит их в репо на гитхаб — можно почитать, посмотреть, попробовать.
функция api_build_url имеет больше 3-х параметров? Передавайте ассоциативный массив, который будет заполнен частично. Дефолтные значения подставите в самой функции.
конкатенация строк через точку? если не хотите понимать спецификаторы в sprintf, то хотя бы в массив через запятую, а затем join.
str_replace? все таки бы глянули sprintf: )
Еще подумал, что в целом-то CRM (и 1С в частности) не обязательна. Т.е. если локальная БД при астериске будет хранить данные типа [дата звонка, номер клиента, вн.номер менеджера], то этого уже достаточно, чтобы предложить персональное меню для клиента. Необходимо лишь при входящих и исходящих состоявшихся звонках пополнять данные.
А как получать данные на странице из демона тогда?
демон по идее может делать несколько дел одновременно: 1) пулять запросы в астериск и обрабатывать ответы на них, 2) быть веб-сервером, который делает SSE и/или websocket.
Как время появится, выложу на github.
А я стал практиковать другой подход: все временное и быстрое на гитхабе, а уже как становится близко к рабочему варианту уходит в закрытые репо.: ) Поэтому на ранних этапах всегда можно спросить, обсудить, поделиться, а затем уже прятать "сокровище". Например, у меня есть похожий проект: https://github.com/antirek/asti на node.js, который получает от астериска события очередей Queue и отдает их подключившимся клиентам по ws через js-либу https://github.com/antirek/asti.js В итоге на какой-либо странице подключаем asti.js и вешаем обработчики на определенные события, т.е. делаем всплывающие подсказки, моргания, запрос доп.данных из CRM.
Т.е. вы раз в 1 секунду бомбите астериск запросами CoreShowChannels, чтобы получить актуальные данные?
А еще зачем вам memcache, если у вас есть демон? Все актуальные данные о звонках вы можете хранить в памяти демона, не так ли?
Почему выбрали SSE, а не websockets?
Исходников на гитхабе не будет (попробовал бы ваше решение, но выдергивать из статьи долго)?
Э-э… а практический пример применения методики? x,p, q, с и iddqd — это, конечно, хорошо. Но вот у меня есть apache, nginx, mysql, php, node.js, sphinx и много-много своего кода. Как жить?
Еще в docker можно мануал обернуть — тогда любой сможет скачать, развернуть и попробовать в считанные минуты.
Респект за терпение в интеграционном решении: )
Не понял: все коллеги пушили в «домашний репо», который синхронизировался в гитхаб, затем кто-то сел и почистил его, и вы приходите к выводу, что надо бэкапить гитхаб репозитории? А что такое «домашний репо»? Он на локальном компьютере разработчика стоит? Тогда зачем «новый сотрудник решил привести в порядок» на компьютере разработчика? Так принято: «я новенький — поэтому сейчас наведу порядок»?: ) Или домашний репо — это репо в стенах вашей компании на сервере репозиториев? Тогда почему вы с него не делаете бэкапов?
А, в целом, да, репозитории с гитхаба надо регулярно клонировать в надежное место. А то знаете ли, его и заблокировать могут.
К вашему стремлению претензий нет: ) У вас отличная схема, подробные детали.
Вопрос в том, что, например, я хочу воспроизвести и пощупать ваше предложение, разобраться что к чему, как можно это еще переконфигурировать. И для этого я должен ставить на свою систему весь набор перечисленного софта: wget, mysql, freeradius, easyhotspot и т.д. (оцените примерное время на копирование команд, проделывание это вручную, возможные ошибки в последоватльности действий) Это, в целом, повышает порог для подключения к вашему проекту. Если же бы вы предоставили готовую сборку, например, на основе docker'а, то тогда было бы дело пары команд развернуть копию вашей системы и реально опробовать со своим хотспотом. Плюс из статьи можно было бы исключить некоторые детали типа установки wget, и сосредоточиться на ключевых моментах с точки зрения понимания работы изнутри.
Правильно ли понимаю, что можно использовать и какие-то другие точки доступа, а не только Cisco WLC5508? И, в целом, здесь две компоненты: биллинг и точка доступа Wi-Fi? Биллинг у нас содержит: radius-сервер + бд + веб-морда к бд (портал управления пользователями). Есть ли другие подобные easyhotspot решения?
Думаю, все подобные рецепты по установке и/или конфигурированию сервисов пора описывать в виде Dockerfile'ов или скриптов с комментариями: а) проще воспроизвести, б) проще поправить
>>В этом вся суть современного интернета — всё полезное спрятано и доступ к нему неочевиден.
Ох, как вы правы. Сейчас столько информации в закрытых социальных сетях, мессенджерах и других системах.
> имеют аллергию на pbx_lua
есть два типа астерискеров: одни пишут на lua, другие его еще не пробовали: )
Но в целом, на системе которая обслуживает на номере 8800 десятки-сотни звонков в минуту, проще использовать in-memory db, redis например. В редис данные имеют время жизни, т.е. пришел вызов, положили номер в бд с ttl 5 минут. Когда пришел следующий, проверили, если есть в бд по критериям, то hangup.
Может быть когда-нибудь включат в стандартную поставку возможность работы с redis напрямую из стандартного диалплана asterisk (вот уже есть проект https://github.com/tic-ull/func_redis), пока можно использовать redis-lua в диалплане на lua.
Если вы будете развивать систему долгие годы, то посмотрите в сторону lua: разделение на компоненты диалплана, тесты каждого компонента и т.д. Т.е. всю логику можно тестировать и без реального астериска. Это не исключает тестирования «боевого поведения пользователя», но отделит тестирование логики от тестирования боевого поведения и сделает второе более простым.
У вашего подхода есть хороший плюс — он сразу проверит прохождение тональных сигналов, но и это можно сделать отдельным тестом по вашему подобию и тоже на lua; )
P.S. Впервые вижу, что кто-то так заморочился тестированием ivr, это впечатляет.
Использование и xml, и бд? Можно все хранить в БД?
Зачем выкладывать куски кода на хабр? Выложит их в репо на гитхаб — можно почитать, посмотреть, попробовать.
функция api_build_url имеет больше 3-х параметров? Передавайте ассоциативный массив, который будет заполнен частично. Дефолтные значения подставите в самой функции.
конкатенация строк через точку? если не хотите понимать спецификаторы в sprintf, то хотя бы в массив через запятую, а затем join.
str_replace? все таки бы глянули sprintf: )
демон по идее может делать несколько дел одновременно: 1) пулять запросы в астериск и обрабатывать ответы на них, 2) быть веб-сервером, который делает SSE и/или websocket.
А я стал практиковать другой подход: все временное и быстрое на гитхабе, а уже как становится близко к рабочему варианту уходит в закрытые репо.: ) Поэтому на ранних этапах всегда можно спросить, обсудить, поделиться, а затем уже прятать "сокровище". Например, у меня есть похожий проект: https://github.com/antirek/asti на node.js, который получает от астериска события очередей Queue и отдает их подключившимся клиентам по ws через js-либу https://github.com/antirek/asti.js В итоге на какой-либо странице подключаем asti.js и вешаем обработчики на определенные события, т.е. делаем всплывающие подсказки, моргания, запрос доп.данных из CRM.
А еще зачем вам memcache, если у вас есть демон? Все актуальные данные о звонках вы можете хранить в памяти демона, не так ли?
Почему выбрали SSE, а не websockets?
Исходников на гитхабе не будет (попробовал бы ваше решение, но выдергивать из статьи долго)?
Респект за терпение в интеграционном решении: )
А, в целом, да, репозитории с гитхаба надо регулярно клонировать в надежное место. А то знаете ли, его и заблокировать могут.
Вопрос в том, что, например, я хочу воспроизвести и пощупать ваше предложение, разобраться что к чему, как можно это еще переконфигурировать. И для этого я должен ставить на свою систему весь набор перечисленного софта: wget, mysql, freeradius, easyhotspot и т.д. (оцените примерное время на копирование команд, проделывание это вручную, возможные ошибки в последоватльности действий) Это, в целом, повышает порог для подключения к вашему проекту. Если же бы вы предоставили готовую сборку, например, на основе docker'а, то тогда было бы дело пары команд развернуть копию вашей системы и реально опробовать со своим хотспотом. Плюс из статьи можно было бы исключить некоторые детали типа установки wget, и сосредоточиться на ключевых моментах с точки зрения понимания работы изнутри.
Правильно ли понимаю, что можно использовать и какие-то другие точки доступа, а не только Cisco WLC5508? И, в целом, здесь две компоненты: биллинг и точка доступа Wi-Fi? Биллинг у нас содержит: radius-сервер + бд + веб-морда к бд (портал управления пользователями). Есть ли другие подобные easyhotspot решения?