Как стать автором
Обновить

Комментарии 16

Вместо
… AND MONTH(`calldate`)=MONTH(NOW()) AND YEAR(`calldate`)=YEAR(NOW())
лучше использовать
… AND `calldate` BETWEEN DATE_FORMAT(NOW(),'%Y-%m-01') AND LAST_DAY(NOW()) + INTERVAL 1 DAY;
Спасибо, попробую на практике
1)зачем харкодить лимиты?
2)почему не использовать pbx_lua и ходить в memcached?
3)почему не использовать agi/fastagi для этого( почти как pbx_lua, только теперь вообще на чём угодно можно).

вообщем, не делайте так.
3. Думаете agi/fastagi дает меньше накладкных расходов чем app_mysql.so?
3. Думаете agi/fastagi дает меньше накладкных расходов чем app_mysql.so?


как минимум, там можно нарисовать кеширование / агрегацию. т.е. копить пачку данных и потом выплёвывать в mysql(если уж так хочется её использовать).
у agi оверхед — порождение нового процесса.
у fastagi — accept нового tcp-соединения + парсинг достаточно простого протокола.
можно еще asyncagi использовать, но тут всё сложнее.

а насчёт бд я бы использовал что-то более быстрое типа mongodb.

кроме того, у этой схемы есть архитектурный косяк:

допустим, по транку мы наговорили 298 минут. следующий звонок может продлится час(ну или согласно лимиту на MSC у сотового оператора).
при этом мы вылетим за лимит и неслабо потеряем в деньгах.
т.е. тут надо более сложную логику, которую реализовывать в самом астериске неудобно и просто глупо.

если кому-то интересно, могу выложить код fastagi-сервера для астериска, где под капотом gevent.
Выложите всегда интересно посмотреть! Вообще мне кажется самое просто решение тут в создать еще табличку в базе где хранить результат предыдущего запроса в формате дата_запроса <----> колл-во минут <--> канал, соответственно каждый раз собирать информацию только по маленькому промежутку времени и делать update данныx в эту таблицу!
а можно просто завести h-extension, и в нём делать инкремент поля в табличке на длительность вызова.
А можно заюзать внутреннюю ДБ астера, быстрее неё ничего нет :)
имхо лишние движения, тогда придется делать отдельную переменную для каждого транка
ну завели бы табличку вида trunk_id, used, limit

насчёт архитектурного косяка — смотрите опцию S у Dial.
благодарю, добавил
А с табличкой — честно, не вижу смысла, здесь мы берем 1 параметр напрямую из cdr, и манипулируем уже с ним. Думаю, вышло бы более громоздко
Насчет архитектурного косяка, можно Dial попробовать добавить &wait($[${billsec} — 1])&hangup request (с правильным синтаксисом, разумеется) Либо запускать AGI c тем дже функционалом.
Получится перенести куски cdr во внутреннюю db — буду использовать ее.
Вообще это получается биллинг, и данные нужны в реальном времени
В своё время написал для служб такси отзвоны с перебором сим карт. Писал на AEL, использовал внутреннюю БД и макросы в диале при ответе абонента.
Дополнительно скриптик написал для контроля за каналами через вэб.
Готов скинут комплект если желаете добавить в статью :)
Я пытался написать страничку, чтобы просматривать статистику, но у меня возникли проблемы с многострочным выводом результата запроса, ну не силен я пока в PHP. Если возможно — скиньте в личку для ознакомления и общего развития, и напишите статью, буду рад присоединитсья к обсуждению, вот.
И с такси был опыт, там поставили GoIP, настроенный одним транком, он сам более-менее симки балансирует. А для базы VIP-клиентов тогдашний гуру использовал mysql, так что к чему приучился — тем и пользуюсь)
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории