Проблема при стратегии linear при realtime очередях

Question

Привет!

Астер 1,8,17. Очереди.

Есть стратегия linear, она отлично работает при работе из конфиг файлов. Но при использовании realtime порядок в очереди применяется восходящий, а не по uniqueID из базы. Таким образом если я хочу чтобы сначала звонил номер 333, а потом 111, и размещаю их соответственно в базе, астер мне говорит иди нафиг. И ставит сначала 111 а потом 333.

Нашел тут заметку в баг трекере астера https://issues.asterisk.org/jira/browse/ASTERISK-18480 , но там сделали рожу кирпичом и закрыли её, с формулировкой "это не баг"

Как быть? Перекинуть эту конкретную очередь в конфиг файл конечно можно, но это как то раково.

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

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

Answer 1

1

Это не баг , это функциональность. Добавляйте префисы к динамическим операторам , чтобы принудительно их сортировать.

ссылка удалить спам редактировать

ответил 2012-11-07 13:25:40 +0400

zzuz

7174 ● 2 ● 6 ● 75
http://line24.ru/

Comments

Можно пояснить этот момент? У меня в базе табличка queuemembers, в ней значения uniqueid, queuename, interface. И все. Куда добавлять префиксы?

Злобный Мыш ( 2012-11-07 13:31:01 +0400 )редактировать

Нашел что у меня не совсем верная таблица queuemembers, добавил поля membername и paused, но сортировка идет по значению в поле interface. А туда я не могу добавить префикса.

Злобный Мыш ( 2012-11-07 14:02:55 +0400 )редактировать

Ну если не работает одно решение , нужно искать другое. Для вашего продукта я ничего не могу посоветовать , потому что понятия не имею , что и зачем у Вас там. Задача простая - запихивать в очередь мемберов в порядке необходимом для Вас.

zzuz ( 2012-11-07 14:19:41 +0400 )редактировать

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

Злобный Мыш ( 2012-11-07 15:06:46 +0400 )редактировать

Ничего секретного тут нет. Если штатный механизм не удается победить - используйте свой созданный.

zzuz ( 2012-11-07 15:19:57 +0400 )редактировать

Answer 2

1

линейно из базы выбирает. без сортировки. как выбрало так и получилось. в чем пробелма то?

mysql при этом выдает в порядке вставки.

если вам нада сортировка по uniqueid то добавте ее в запрос,делов то. или создайте view который будет выдавать отсортированное по uniqueid

вообщемто view решает вашу проблему полность. без необходимости перекомпиляций.

и да, в диджиум правы. это НЕ баг.

с пенальти кстати тоже есть решение. ставите приоритеты по одному. и ставите queuerules увеличивать на 1 каждые 10 секунд. пойдет по очереди.

ссылка удалить спам редактировать

ответил 2012-11-11 22:46:50 +0400

meral

23347 ● 24 ● 20 ● 177
http://pro-sip.net/

обновил 2012-11-11 22:48:00 +0400

Comments

Наверно мы непоняли друг друга.

Соглашусь, это не баг, это "оно так работает". Если править запрос который отсылается в мускуль, то это уже править исходный код, ибо в конфиг файлах я этот код нигде не нашел, соответственно, примерно это и решали те патчи, они добавляли сортировку по uniqueid в то что вынималось из базы. Это я пожалуй делать не буду, не мой уровень. Я вообще думал написать скрипт который будет добавлять юзеров в очередь динамически, при этом создавать пустую очередь.

Ммм... можно чуток поподробней? view это технология из мускуля?

Ппенальти тоже хотел применить, но не подходит по идеологическим причинам, ибо звонок должен будет идти по кругу, т.е. после последнего вернуться к первому. А как сделать такое в queuerules я не знаю, мне показалось что вообще не возможно.

Злобный Мыш ( 2012-11-12 10:36:03 +0400 )редактировать

1

ну так. вот у вас 10 агентов. через 100 секунд сделать -10 (сбросить). view позволяет подсунуть вмето таблицы запрос. http://habrahabr.ru/post/47031/

meral ( 2012-11-12 10:50:08 +0400 )редактировать

Добрый день.Можно поподробнее о методе решения с VIEW. Получается нужно создать VIEW c именем queue_members, например, и прописать в файле extconfig.conf именно этот VIEW, верно?

Rockast ( 2018-04-09 16:26:46 +0400 )редактировать

астериску совершенно пофигу таблица там или view. Вы просто формируете view так, чтоб он был похож на таблицу и имел нужный набор столбцов. Что еще подробнее? Имя таблицы тоже может быть совершенно произвольным, но совпадать с тем именем, которое вы указали в extconfig.conf

meral ( 2018-04-11 07:27:02 +0400 )редактировать

Если чегото будет не хватать, то в debug on режиме вам об этом сообщат.

meral ( 2018-04-11 07:27:56 +0400 )редактировать

Answer 3

0

Может кому пригодится, чтобы сортировка работала по полю в таблице uniqueid, нужно: я работаю c res_config_mysql

Астериск версия 11.7

Правим файл

/addons/res_config_mysql.c

находим строку 464 там написано:

if (initfield) {

нужно весь этот IF поменять на

if (initfield) {
    if (strcmp(initfield, "interface")==0) {
        ast_str_append(&sql, 0, " ORDER BY `uniqueid`");
    } else {
        ast_str_append(&sql, 0, " ORDER BY %s", initfield);
    }
}

ну а далее:

make
make install

у меня теперь нормально сортирует.

ссылка удалить спам редактировать

ответил 2014-09-26 15:49:54 +0400

romariosar

588 ● 93 ● 11 ● 44
http://www.webunix.ru/

обновил 2014-09-26 15:50:19 +0400

Comments

достаточно использовать отсортированный view. то что вы написали это от большого незнания.

meral ( 2014-09-26 18:25:26 +0400 )редактировать

в других версиях возможно, но судя по дебагу все запросы в реалтайм идут по сортировке interface (ORDER BY interface) так что как не выдавай ему, он всеравно сам отсортирует по интерфейсу. Поэтому для нас было интереснее потратить 5 минут на редактирование исходника чем копаться с выдачей.

romariosar ( 2014-09-26 22:35:11 +0400 )редактировать

вы чтото намутили. все работало. без изменений исходников. то что для вас интереснее раком все уже поняли.

meral ( 2014-09-26 23:48:25 +0400 )редактировать

вы вообще поняли что и где вы поменяли? как у вас после этого функция REALTIME например работает? что за бред вообще?

meral ( 2014-09-26 23:53:52 +0400 )редактировать

короче. патчить resconfigmysql чтоб пофиксить app_queue(кстати в версии 11.13 я не вижу описаного вами бага) это просто за гранью добра и зла. а еще и "делится" этим это вообще.

meral ( 2014-09-27 00:03:20 +0400 )редактировать

ну я же написал что в других версиях возможно по другому работает. Просто мы исходили из дебага где водно что формарование SQL запроса идет в файле resconfigmysql.

вот дебаг кстате, который нормально уже работает

] DEBUG[1700]: resconfigmysql.c:501 realtimemultimysql: MySQL RealTime: Retrieve SQL: SELECT * FROM queuemembercc WHERE interface LIKE '%' AND queue_name = 'queue-1' ORDER BY uniqueid

так что на этот раз вы зря ругаетесь.

В 11.13 сортировка происходит по uniqueid? Если так то я обновлюсь.

romariosar ( 2014-09-27 09:54:26 +0400 )редактировать

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

meral ( 2014-09-27 22:51:52 +0400 )редактировать

Проблема при стратегии linear при realtime очередях

3 Ответа

Comments

Comments

Comments

Ваш ответ

Закладки и информация

Статистика

Похожие вопросы: