Оператор номеров 8800, которого я советую своим клиентам, берет 2.42 руб/минуту с поминутной тарификацией, и 2.89 руб/минуту с посекундной. С посекундной, конечно, все проще, но тоже неприятно. За одну минуту можно совершить минимум 10 звонков, которые спишут с баланса владельца номера почти 15 рублей. За час это будет 900 рублей, и это если в один поток. В общем, проблема есть и явная.
Решение было найдено несложное, по традиции, все делается из вебморды FreePBX. Нам понадобится модуль Smart Routes, который я уже упоминал в предыдущей публикации, там же его можно скачать.
Логика проста — ищем в CDR последние звонки с текущего номера, и если их больше X за Y минут — сбрасываем звонок.
Запрос в модуле прост:
SELECT count(`calldate`) FROM `cdr` WHERE (`src`='${CALLERID(number)}') AND (`calldate` BETWEEN NOW() - INTERVAL 5 MINUTE AND NOW())Как видно, интервал указывается именно тут, в запросе. Запрос отберет количество звонков с текущего номера за последние 5 минут и выведет их в результирующем поле одной строкой.
Match Type нам необходимо установить в LESSER, по совпадению — переход на нужную нам точку, Failover устанавливаем, например, в Terminate => Hangup. Именно в этом поле настраивается число разрешенных звонков с текущего номера за интервал, указанный в запросе.
Default Destination также сброс.
Выглядит это так:
Остается направить звонки в модуль Smart Routes во входящих правилах и все!
Удачи и поменьше неадекватных людей вам на пути.
Комментарии (24)
NikiN
06.09.2016 17:10А что за оператор? если не секрет…
whoim
06.09.2016 17:11+1ТТК через iprating
— Искренне прошу прощения, не в ту таблицу посмотрел (
2.42 с поминутной, 2.89 с посекундной, ошибся (
Давно с 8800 не связывался, цены не держатся в голове
falsebyte
06.09.2016 21:34Хотелось бы увидеть живой пример нагрузки на mysql во время «многократного дозвона на номер для срабатывания тарификации».
Не получится ли так что «нормальный» звонок простаивает N секунд ожидая выполнения SELECT?
Для решения «по быстрому», согласен, решение имеет право на существование.whoim
06.09.2016 21:37Конечно, многое зависит от «серьезности» движений и числа одновременных звонков, но на современных системах запросы select, как мне кажется, неспособны создать серьезную нагрузку в рамках даже полусотни одновременных звонков и базы за год.
Конечно, если коллцентр не на pi и база не на флешке :)
А раз в полгода можно и почистить CDR, перенеся в соседнюю таблицу и натравив второй CDR-въювер на нее. А-ля «Архив».
Нагрузку врядле смогу показать — самому организовывать тестирование нет времени и желания, а клиентов пока ни разу не «долбили».
antirek
07.09.2016 08:10+2Аккуратное решение задачи.
Но в целом, на системе которая обслуживает на номере 8800 десятки-сотни звонков в минуту, проще использовать in-memory db, redis например. В редис данные имеют время жизни, т.е. пришел вызов, положили номер в бд с ttl 5 минут. Когда пришел следующий, проверили, если есть в бд по критериям, то hangup.
Может быть когда-нибудь включат в стандартную поставку возможность работы с redis напрямую из стандартного диалплана asterisk (вот уже есть проект https://github.com/tic-ull/func_redis), пока можно использовать redis-lua в диалплане на lua.ShadoWalkeR30
07.09.2016 11:54+2Я бы сделал трехуровневую систему — БД сама готовит данные для redis через созданную таблицы View. Redis кэширует для астериска. И исходя из моего опыта общения очень многие астерискеры имеют аллергию на pbx_lua.
antirek
07.09.2016 13:15можно и так заморочиться, только это зависит теперь от работы БД с cdr'ами
> имеют аллергию на pbx_lua
есть два типа астерискеров: одни пишут на lua, другие его еще не пробовали: )ShadoWalkeR30
07.09.2016 13:28Я сам к первым отношусь, но почему то попадаются только вторые. :)
Для некоторых астерискеров было открытием что AEL, оказывается, умеет ошибочные строки находить и выводить на экран, в отличие от диалплана.
Но у pbx_lua тоже есть свои проблемы. Верней у lua — а точней инфраструктура. Я использую luasql-mysql, но он уже 2 года как не обновляется и сам keplerproject мертв. Информации об этом никак не узнать, но пакет через luarocks доступен. Да и сам luarocks не позволяет запросить краткое описание пакетов и хотя бы дату последнего обновления.
Но все равно по сравнению с диалпланом астериска он намного лучше :)
Да — по поводу пробовать — документация по астериску, это отдельная черная дыра и очень отталкивает количество и качество описания pbx_lua.antirek
08.09.2016 07:38Проблемы с многими нишевыми вещами от отсутствия спроса, а спроса нет, т.к. нет понимания, что это удобнее. Будет спрос — будет развитие. Поэтому надо чаще упоминать об удобных инструментах, участвовать в жизни сообществ. Кстати, вы знаете про чат астерискеров? http://chat.asterisk-support.ru/
varnav
07.09.2016 12:46У меня на FreePBX машине innodb_buffer_size установлен больше, чем вся база. В результате она вся находится в памяти.
Berlic
08.09.2016 10:46+1Согласен про in-memory.
Я для такой задачи накидал AGI-скрипт в несколько строк, который закидывал данные в memcache с TTL, increment'ил и возвращал значение.
Если критерий проходит – Answer, нет – Hangup.
arheops
08.09.2016 08:46А что мешает звонящему указывать для каждого звонка новый CID? Сложность такого дополнения к звонилке практически нулевая.
whoim
08.09.2016 08:49+2То, что операторов, позволяющих подставлять свой CID — немного, все они требуют достаточно реальных данных в договоре и сами рискуют санкциями от своих партнеров, отследить такие звонки до реального физического лица через полицию в разы проще, да и реакция на заявку, которую достаточно оформить своему поставщику 8800, будет быстрой. Именно поэтому такие каналы думаю никогда не используют для спама, получить его непросто, потерять — легко.
Я свой канал, например, берегу. Он мне позволяет «пробрасывать» звонки на мобильные сотрудников клиентов. «Даю» только проверенным клиентам.arheops
08.09.2016 11:53siptraffic.com получить — элементарно, потерять — нежалко. Дает менять cid. Да и вообще почти любые операторы в английской части интернета такую услугу предоставляют. Не понял, почему фиксированный номер сложнее через полицию отследить. Наоборот проще, не?
whoim
08.09.2016 19:25думаю, как только им один раз воспользуются и будет жалоба с заявлением в полицию — элементарно получить возможность указывать свой cid сразу станет невозможно :)
Фиксированный в виде sim берется на левые паспортные данные и все… а там хз, в любом случае вопрос не в проще/сложнее, а в желаниях и возможностях органов и СБ тройки. SIP-движуха в любом случае идет через них, и получить эти данные можно очень быстро, и такие вещи их интересуют, начнут рыть без полиции.
las68
08.09.2016 09:01+1CID назначается оператором при инициации вызова и передаётся далее с оператора на оператора, до терминирования на вызываемой стороне. Подмена CID может делаться оператором, но там много ограничений, нарушение которых чревато отъемом лицензии. Пустой CID не передаётся, любое промежуточное оборудование его будет отбивать, потому что непонятно, на кого относить тарификацию за вызов.
Если вызывающая сторона умеет на ходу менять Caller ID, или у ней «случайно» есть несколько десятков управляемых сотовых телефонов, то это уже технически подготовленный call agressor получается. У конкурентов небольшой компании «Рога и Копыта» таких возможностей обычно нет.
whoim
Забыл указать настройки для СУБД, они идентичны указанным в прошлой статье, упоминаемой в посте.