Comments 24
Забыл указать настройки для СУБД, они идентичны указанным в прошлой статье, упоминаемой в посте.
А что за оператор? если не секрет…
ТТК через iprating
— Искренне прошу прощения, не в ту таблицу посмотрел (
2.42 с поминутной, 2.89 с посекундной, ошибся (
Давно с 8800 не связывался, цены не держатся в голове
— Искренне прошу прощения, не в ту таблицу посмотрел (
2.42 с поминутной, 2.89 с посекундной, ошибся (
Давно с 8800 не связывался, цены не держатся в голове
Хотелось бы увидеть живой пример нагрузки на mysql во время «многократного дозвона на номер для срабатывания тарификации».
Не получится ли так что «нормальный» звонок простаивает N секунд ожидая выполнения SELECT?
Для решения «по быстрому», согласен, решение имеет право на существование.
Не получится ли так что «нормальный» звонок простаивает N секунд ожидая выполнения SELECT?
Для решения «по быстрому», согласен, решение имеет право на существование.
Конечно, многое зависит от «серьезности» движений и числа одновременных звонков, но на современных системах запросы select, как мне кажется, неспособны создать серьезную нагрузку в рамках даже полусотни одновременных звонков и базы за год.
Конечно, если коллцентр не на pi и база не на флешке :)
А раз в полгода можно и почистить CDR, перенеся в соседнюю таблицу и натравив второй CDR-въювер на нее. А-ля «Архив».
Нагрузку врядле смогу показать — самому организовывать тестирование нет времени и желания, а клиентов пока ни разу не «долбили».
Конечно, если коллцентр не на pi и база не на флешке :)
А раз в полгода можно и почистить CDR, перенеся в соседнюю таблицу и натравив второй CDR-въювер на нее. А-ля «Архив».
Нагрузку врядле смогу показать — самому организовывать тестирование нет времени и желания, а клиентов пока ни разу не «долбили».
Если сделать индекс по (src, calldate) — то даже самый глупый оптимизатор запросов сумеет им воспользоваться.
А вот без такого индекса да под нагрузкой и с большим размером базы возможно всякое.
А вот без такого индекса да под нагрузкой и с большим размером базы возможно всякое.
Аккуратное решение задачи.
Но в целом, на системе которая обслуживает на номере 8800 десятки-сотни звонков в минуту, проще использовать in-memory db, redis например. В редис данные имеют время жизни, т.е. пришел вызов, положили номер в бд с ttl 5 минут. Когда пришел следующий, проверили, если есть в бд по критериям, то hangup.
Может быть когда-нибудь включат в стандартную поставку возможность работы с redis напрямую из стандартного диалплана asterisk (вот уже есть проект https://github.com/tic-ull/func_redis), пока можно использовать redis-lua в диалплане на lua.
Но в целом, на системе которая обслуживает на номере 8800 десятки-сотни звонков в минуту, проще использовать in-memory db, redis например. В редис данные имеют время жизни, т.е. пришел вызов, положили номер в бд с ttl 5 минут. Когда пришел следующий, проверили, если есть в бд по критериям, то hangup.
Может быть когда-нибудь включат в стандартную поставку возможность работы с redis напрямую из стандартного диалплана asterisk (вот уже есть проект https://github.com/tic-ull/func_redis), пока можно использовать redis-lua в диалплане на lua.
Я бы сделал трехуровневую систему — БД сама готовит данные для redis через созданную таблицы View. Redis кэширует для астериска. И исходя из моего опыта общения очень многие астерискеры имеют аллергию на pbx_lua.
можно и так заморочиться, только это зависит теперь от работы БД с cdr'ами
> имеют аллергию на pbx_lua
есть два типа астерискеров: одни пишут на lua, другие его еще не пробовали: )
> имеют аллергию на pbx_lua
есть два типа астерискеров: одни пишут на lua, другие его еще не пробовали: )
Я сам к первым отношусь, но почему то попадаются только вторые. :)
Для некоторых астерискеров было открытием что AEL, оказывается, умеет ошибочные строки находить и выводить на экран, в отличие от диалплана.
Но у pbx_lua тоже есть свои проблемы. Верней у lua — а точней инфраструктура. Я использую luasql-mysql, но он уже 2 года как не обновляется и сам keplerproject мертв. Информации об этом никак не узнать, но пакет через luarocks доступен. Да и сам luarocks не позволяет запросить краткое описание пакетов и хотя бы дату последнего обновления.
Но все равно по сравнению с диалпланом астериска он намного лучше :)
Да — по поводу пробовать — документация по астериску, это отдельная черная дыра и очень отталкивает количество и качество описания pbx_lua.
Для некоторых астерискеров было открытием что AEL, оказывается, умеет ошибочные строки находить и выводить на экран, в отличие от диалплана.
Но у pbx_lua тоже есть свои проблемы. Верней у lua — а точней инфраструктура. Я использую luasql-mysql, но он уже 2 года как не обновляется и сам keplerproject мертв. Информации об этом никак не узнать, но пакет через luarocks доступен. Да и сам luarocks не позволяет запросить краткое описание пакетов и хотя бы дату последнего обновления.
Но все равно по сравнению с диалпланом астериска он намного лучше :)
Да — по поводу пробовать — документация по астериску, это отдельная черная дыра и очень отталкивает количество и качество описания pbx_lua.
У меня на FreePBX машине innodb_buffer_size установлен больше, чем вся база. В результате она вся находится в памяти.
Согласен про in-memory.
Я для такой задачи накидал AGI-скрипт в несколько строк, который закидывал данные в memcache с TTL, increment'ил и возвращал значение.
Если критерий проходит – Answer, нет – Hangup.
Данный модуль можно указывать в качестве Destination в других местах?
А что мешает звонящему указывать для каждого звонка новый CID? Сложность такого дополнения к звонилке практически нулевая.
То, что операторов, позволяющих подставлять свой CID — немного, все они требуют достаточно реальных данных в договоре и сами рискуют санкциями от своих партнеров, отследить такие звонки до реального физического лица через полицию в разы проще, да и реакция на заявку, которую достаточно оформить своему поставщику 8800, будет быстрой. Именно поэтому такие каналы думаю никогда не используют для спама, получить его непросто, потерять — легко.
Я свой канал, например, берегу. Он мне позволяет «пробрасывать» звонки на мобильные сотрудников клиентов. «Даю» только проверенным клиентам.
Я свой канал, например, берегу. Он мне позволяет «пробрасывать» звонки на мобильные сотрудников клиентов. «Даю» только проверенным клиентам.
siptraffic.com получить — элементарно, потерять — нежалко. Дает менять cid. Да и вообще почти любые операторы в английской части интернета такую услугу предоставляют. Не понял, почему фиксированный номер сложнее через полицию отследить. Наоборот проще, не?
думаю, как только им один раз воспользуются и будет жалоба с заявлением в полицию — элементарно получить возможность указывать свой cid сразу станет невозможно :)
Фиксированный в виде sim берется на левые паспортные данные и все… а там хз, в любом случае вопрос не в проще/сложнее, а в желаниях и возможностях органов и СБ тройки. SIP-движуха в любом случае идет через них, и получить эти данные можно очень быстро, и такие вещи их интересуют, начнут рыть без полиции.
Фиксированный в виде sim берется на левые паспортные данные и все… а там хз, в любом случае вопрос не в проще/сложнее, а в желаниях и возможностях органов и СБ тройки. SIP-движуха в любом случае идет через них, и получить эти данные можно очень быстро, и такие вещи их интересуют, начнут рыть без полиции.
CID назначается оператором при инициации вызова и передаётся далее с оператора на оператора, до терминирования на вызываемой стороне. Подмена CID может делаться оператором, но там много ограничений, нарушение которых чревато отъемом лицензии. Пустой CID не передаётся, любое промежуточное оборудование его будет отбивать, потому что непонятно, на кого относить тарификацию за вызов.
Если вызывающая сторона умеет на ходу менять Caller ID, или у ней «случайно» есть несколько десятков управляемых сотовых телефонов, то это уже технически подготовленный call agressor получается. У конкурентов небольшой компании «Рога и Копыта» таких возможностей обычно нет.
Если вызывающая сторона умеет на ходу менять Caller ID, или у ней «случайно» есть несколько десятков управляемых сотовых телефонов, то это уже технически подготовленный call agressor получается. У конкурентов небольшой компании «Рога и Копыта» таких возможностей обычно нет.
Sign up to leave a comment.
Защита от «спама» на 8800 во FreePBX