"Опять менеджеры жалуются. Дескать по графику идет больше звонков на одного, а второй проставивает без дела" - вновь хотелки и недовольство.
Вот ведь совсем недавно сделал им механизм управления звонками. Казалось бы - работай и радуйся. Опять не все благополучно :(


От чего отталкиваться.

Сама история разработки всех этих хотелок описана в одном из моих топиков http://wapo-spb.livejournal.com/6250.html

Там, кстати, упоминалось и об использовании метода случайного распределения RAND, который, кстати, тоже вызывал нарекания: на некоторых менеджеров звонки шли чаще, а на кого-то не поступали вообще.

Конечно, можно было бы использовать чудесное приложение Queue c соответствующим методом распределения. Ну а самих дежурных "загонять" в очередь автоматически скажем в 5 утра с помощью AMI-скрипта. Так вообщем-то и делалось у одного из заказчиков. Но в данном случае использовать эту навороченность попросту незачем. Достаточно сделать что-то типа механизма инвертирования.
Т.е. комбинация списка номеров типа 213524313830 должна меняться: первый номер со вторым, третий с четвертым и обратно. (последние два номера являются стандартным резервом если уж вообще никто не отвечает.

Решение.

Вообщем-то сложности практически не возникло. Правда первоначально хотелось значение флага закинуть в mysql (по привычке), но потом все-таки отказался от этой идеи.
Взял и в существующее решение просто добавил следующий кусок:

exten => s,n,GotoIf($[${DB(var/flag)}!=2]?set2)
exten => s,n,Set(DB(var/flag)=1)
exten => s,n,Goto(ring)

exten => s,n(set2),Set(DB(var/flag)=2)
exten => s,n,Set(newvar=${variant:2:2}${variant:0:2}${variant:6:2}${variant:4:2}${variant:8})
exten => s,n,Set(variant=${newvar})

exten => s,n(ring),NoOp( Now is: ${variant})

Т.е. само содержимое флага находитсся в "родной" БД Asterisk-а и при каждом последующем вызове меняется с 1 на 2 и наоборот. Ну и соответственно, идет изменение внутри шаблона номеров.

Вот так и отделался легким испугом :)

До встречи.