Очереди для транков

[Sanek]

Всем привет!
Опять вопросы и опять тупик.
Может мои вопросы покажутся глупыми - прошу не пинать, я ведь только учусь.

Сервер: Asterisk 1.8.12.0 FreePBX 2.10.0.8
На * поднято 12 исходящих транков (GOIP 8 и GOIP 4) - на каждый транк 1 канал и один входящий транк без ограничения на количество каналов.
Задача сделать выбор исходящих транков в зависимости от нагрузки на них: в первую очередь выбираются транки с наименьшей нагрузкой по звонкам. В исходящей маршрутизации такое сделать не получается: транки выбираются по порядку не зависимо от нагрузки на них.
Теоретически я представляю, как это сделать, но на практике зашел в тупик.

И так, в звездочке есть понятие очереди и режим дозвона, но в очередь можно запихнуть только внутренние номера (может я ошибаюсь со * знаком 2-ю неделю). Пробовал линии шлюзов регить на * как внутренние номера, но тогда встает задача как передать до шлюзов набираемые номера.

Подскажите, плиз, примерное решение моей задачи, желательно без глубокого ковыряния конфигов.

[ded]

Теоретически я представляете, как это сделать?
Ну тогда дайте практическое (количественное) определение "большая нагрузка" и "маленькая нагрузка".
Конфиги придётся глубоко ковырять, и не только конфиги.

[Sanek]

Теоретически я представляете, как это сделать?
Ну тогда дайте практическое (количественное) определение "большая нагрузка" и "маленькая нагрузка".

Задача такова (для простоты рассмотрим 3 канала): допустим через 1-й канал прошел звонок длительностью 10 сек, через 2-й 12 сек, по третьему каналу не дозвонились (занято, либо абонент не ответил), значит в очереди должны эти каналы расположиться след. образом: первым становится третий канал; вторым первый и третьим второй. Т.е. вверх ставятся каналы с меньшим суммарным временем звонков, а вниз - с большим. Так же очередь должна изменяться и от количества звонков: меньше звонков - вверх очереди; больше звонков - вниз.

Догадываюсь, что эту стратегию можно реализовать с помощью стратегии дозвона в очередях. Вопрос: как правильно создать очереди?

Конфиги придётся глубоко ковырять, и не только конфиги.

Ну что-ж, раз надо - зачит надо. Буду учиться и курить мануал.

[ded]

дайте практическое (количественное) определение "большая нагрузка" и "маленькая нагрузка"

а не теоретический алгоритм выбора. Если через 1-й канал прошел звонок длительностью 10 сек, через 2-й 12 сек, по третьему каналу не дозвонились, то значит предполагаются какие-то счётчики, которые накапливают информацию по транкам, не так ли? И на основе этой информации строится таблица приоритетов, верно?
Вот это всё Вам и надо писать и считать.
Само название темы - Очереди для транков сразу рождает картинку из прошлого - Междугородный переговорный пункт. Очередь. "Новокузнецк - 17-ая кабина!"

[Sanek]

Но какой-то алгоритм уже заложен в стратегию дозвона (очереди FreePBX):
Вот некоторые, как я думаю, могут подойти под мою задачу

самому-незанятому: звонок поступает наименее занятому оператору в этой очереди
rrmemory: звонок поступает любому не занятому оператору, но с учетом того, кто отвечал на последний звонок
случайный-выбор: использует занятость агентов как вес в качестве приоритета выбора

Или очереди отметать и реализовывать по другому?

Но в любом случае нужно распределять нагрузку по каналам, иначе на верхние каналы будет максимальная нагрузка, а нижние будут отдыхать. Если я не ошибаюсь, в маршрутизации идет выбор транков строго по порядку, начиная с первого?

[Aven]

Очереди не для этого существуют.

Простой способ - делать выборку из CDR и считать наименьший транк.
Но чем больше записей там - тем медленнее выполняться запрос, поэтому нужно агрегировать статистику звонков в отдельной таблице за выбранные интервалы времени и уже делать запрос по ней.

А зачем вообще это мудрить?

[SolarW]

Trunk Cost / Load Balancing - может этого хватит для решения проблемы?

[Sanek]

Очереди не для этого существуют.

Простой способ - делать выборку из CDR и считать наименьший транк.
Но чем больше записей там - тем медленнее выполняться запрос, поэтому нужно агрегировать статистику звонков в отдельной таблице за выбранные интервалы времени и уже делать запрос по ней.

Ясно, спасибо за направление. Будем думать над реализацией, но хотелось по проще. Получается нужно будет автоматически править конфиги в зависимости от таблиц.

А зачем вообще это мудрить?

У нас в стране жестокий антифрод и если через одну симку будут постоянно идти звонки - ее моментально забанят (проверено - живет не более суток). По этому приходится что-то мудрить с "отдыхом" карточек.

Про очереди: а нельзя никак передать набираемый номер в саму очередь? Дело в том, что если я GSM модуль регистрирую на * как внутренний номер, то при звонке на этот номер шлюз "поднимает трубку" и дает возможность набрать номер вызываемого абонента.

[Sanek]

Trunk Cost / Load Balancing - может этого хватит для решения проблемы?

Будем изучать.
Большое спасибо.