asterisk.ru

Сейчас использую стандартный способ т.е. есть статические и динамические агенты, алгоритм такой:
Первый агент не справлется и в очереди накапливается, 2 звонящих.
Второй агент видит, что нужна помощь, и хочет помочь с одним звонком:
1. Он набирает "номер группы * #"
2. Затем вешает трубку
3. К нему приходит звонок
4. Разговор заканчивает, он кладет трубку
5. Снова берет трубку, набирает: "номер группы ** #". Чтобы отписаться от этой группы.
Гораздо лучше было бы если второй агент просто брал трубку набирал некоторую комбинацию получал звонок из очереди и все, чтоб ему не надо было записываться/отписываться от группы.
Спасибо если поможете

Если у второго оператора телефон с программируемыми кнопками - может ему эти подписаться/отписаться на кнопки быстрого набора повесить?
Или поставить FOP2 и в нем пикапить себе звонок из очереди.

Простите меня за ушлость, но Ваш вопрос больше на ТЗ смахивает, только вот чего-то не хватает...

простое решение - это использовать pickupgroup и callgroup в настройках номеров , и когда необходимо перехватывать звонок с транка , в котором прописанны нужные callgroup.

добавить динамической регистрацию в очереди с нужным пенальти
тогда не нужно будет по сорок раз регаться/разрегаться
вызываться будет только при перегрузах основных агентов

я делал через комбинацию номер_очереди*пенальти
номер_очереди* - регистрация с пенальти 0
номер_очереди*пенальти - регистрация с заданным пенальти

Спасибо за варианты! Попробую

Vlad1983 писал(а):добавить динамической регистрацию в очереди с нужным пенальти
тогда не нужно будет по сорок раз регаться/разрегаться
вызываться будет только при перегрузах основных агентов

я делал через комбинацию номер_очереди*пенальти
номер_очереди* - регистрация с пенальти 0
номер_очереди*пенальти - регистрация с заданным пенальти

Особенно , когда оператор отошел в делам , и телефон звонит , не умолкая . Так на следующий приоритет никогда не прилетит. Так появится еще один топик)

Особенно , когда оператор отошел в делам , и телефон звонит , не умолкая . Так на следующий приоритет никогда не прилетит. Так появится еще один топик)

вот для этого доступ к Monast ещё есть чтоб ставить на паузу ушедших или выкидывать совсем
но подобное случается редко

можно так же коды добавить для этих целей

Мы для клиентских операторов автопаузу включаем , или как альтернатива обходим механизм анализа приоритетов в app_queue.c , когда переход на приоритет выше проиходит по заданному в очереди таймауту при любом раскладе, чтобы можно было не использовать автопаузу, наш new-way так сказать.
Monast конечно крут, тут спорить даже не буду, как никак twisted и его мощь. Но не все питоноведы могут осилить поломки в кастомных фабриках разработчиков продукта , если что случится. Без каски в код там точно не полезешь))

обходим механизм анализа приоритетов в app_queue.c , когда переход на приоритет выше проиходит по заданному в очереди таймауту при любом раскладе

странно что до сих пор digium не включил эту возможность в стандартный набор параметров очереди

Такова задумка самого алгоритма разработчиков. Метаться туда сюда тоже вариант.