Вот ведь совсем недавно сделал им механизм управления звонками. Казалось бы - работай и радуйся. Опять не все благополучно :(
От чего отталкиваться.
Сама история разработки всех этих хотелок описана в одном из моих топиков 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}
exten => s,n,Set(variant=${newvar})
exten => s,n(ring),NoOp( Now is: ${variant})
Т.е. само содержимое флага находитсся в "родной" БД Asterisk-а и при каждом последующем вызове меняется с 1 на 2 и наоборот. Ну и соответственно, идет изменение внутри шаблона номеров.
Вот так и отделался легким испугом :)
До встречи.
Comments