Очередь Asterisk: что выбрать вместо «RingOne»

RingAll одновременно вызывает доступных участников очереди; если нужен последовательный обзвон, в Asterisk для этого есть стратегия linear. Название RingOne не подтверждается как встроенная стратегия очереди Asterisk, поэтому сначала проверьте, что именно так называет ваша PBX. Ниже — как выбрать механизм и отличить брошенный вызов от неудачной попытки дозвона.

Что именно делает RingAll и существует ли RingOne

RingAll — стратегия очереди Asterisk: она предлагает вызов всем доступным участникам одновременно и прекращает попытки, когда вызов принят либо завершился по другим условиям очереди. Встроенные стратегии и их точные названия перечислены в образце queues.conf самого проекта Asterisk; если стратегию явно не задать, в образце значением по умолчанию указан ringall. Среди них есть ringall, linear, rrmemory, rrordered, leastrecent, fewestcalls, random и wrandom; RingOne в этом перечне нет. Поэтому я не стал бы менять рабочую очередь на «RingOne», пока не выяснил, что подразумевает под этим словом конкретная панель управления или сторонний модуль. Возможно, это собственный режим интерфейса, но называть его штатной стратегией Asterisk без проверки нельзя. Имя кнопки — не спецификация.

Если под «один за другим» вы имеете в виду фиксированный порядок участников, начните с linear: документация указывает, что участники вызываются в порядке перечисления в конфигурации, а динамические — в порядке добавления. Это не универсальная «безопасная» замена RingAll. Первый участник получает преимущество, и если состав/порядок участников меняется, меняется и фактическое распределение. rrmemory и rrordered решают другую задачу: круговой выбор с сохранением точки, с которой продолжать следующий проход; rrordered сохраняет порядок участников конфигурации. Сначала формулируем требование — всем сразу, строго по списку или по кругу, — потом сопоставляем его со стратегией. Иначе настройка превращается в гадание с английскими словами. Практически это означает, что при анализе звонка нельзя опираться только на экран оператора или на число пропущенных в телефоне. Участник может быть включён в очередь, но считаться недоступным из-за паузы, состояния устройства или правил очереди. И наоборот: сигнал на трубке ещё не доказывает, что абонент уже слышит гудки или что аудиотракт исправен. Проверяйте журнал на стороне Asterisk и фактическое поведение конечного устройства. Для воспроизводимого результата запишите исходные условия: сколько участников вошло в проверку, кто занят, кто поставлен на паузу, какой порядок задан. Тогда можно повторить опыт после изменения и увидеть, что поменялось именно в обработке очереди.

Почему нельзя обещать потерю 40 % из-за одной стратегии

В исходном варианте этой статьи звучал пример: восемь операторов, неделя наблюдений, 40 % потерь до смены стратегии и 5 % после. Ни исходной выборки, ни выгрузки журнала, ни описания расчёта для этих чисел нет. Я удаляю их как доказанный результат. Одного факта, что очередь работает в RingAll, недостаточно, чтобы заключить, что именно стратегия вызвала уход абонентов: на результат влияют расписание, доступность участников, длина приветствия, ожидание в очереди, маршрутизация и то, как посчитан знаменатель. Придуманный процент выглядит убедительно ровно до первой просьбы показать данные.

Если вы разбираете похожий инцидент, сначала зафиксируйте период, входящие вызовы, входы в очередь, соединённые вызовы и уходы до ответа. Сравнивайте одинаковые интервалы и одинаковые правила подсчёта. Счётчик «ABANDON» нельзя автоматически читать как «виноват RingAll»: событие означает, что вызывающий покинул очередь, а не объясняет мотив и не указывает первопричину. Абонент мог устать ждать, ошибиться кнопкой, попасть в нерабочее время или уйти по другой причине. Отделяйте измеренное от гипотезы; иначе красивый отчёт лечит не ту неисправность. В условном примере с восемью сотрудниками корректный разбор начался бы не с утверждения «RingAll теряет звонки», а с выгрузки событий за выбранный период и точного определения метрики. Например, отдельно считают долю вошедших в очередь вызовов, завершившихся ABANDON, и долю попыток RINGNOANSWER; это разные знаменатели и разные события. Нельзя напрямую сравнивать их с числом пропущенных на телефонах: часть вызовов может не попасть в очередь, а один абонент может породить несколько попыток дозвона до CONNECT. Укажите временной интервал, рабочие часы и правила исключения тестовых вызовов. Без этого процент не воспроизводится, а значит, его нельзя предъявлять как результат настройки.

Как читать queue_log без ложного диагноза

Журнал очереди Asterisk по умолчанию хранится в /var/log/asterisk/queue_log; в записи есть время, идентификатор канала, имя очереди, участник, тип события и параметры. Это полезнее, чем одно число «потеряно», потому что события показывают разные этапы звонка. ENTERQUEUE фиксирует вход в очередь, CONNECT — соединение с участником, ABANDON(position|origposition|waittime) — уход вызывающего из очереди с позицией и временем ожидания. RINGNOANSWER означает, что попытка дозвониться до участника завершилась без ответа. Эти события отвечают на разные вопросы. Свалить их в одну колонку «пропущенные» удобно, но для расследования это примерно как считать звонящий телефон и положенную трубку одинаковой поломкой.

Смотрите цепочку одного вызова и сверяйте время ожидания, попытки вызова участников и итог. Если много RINGNOANSWER, проверьте доступность конечных устройств, регистрацию, состояние участника, расписание и то, что именно вызывается. Если растут ABANDON, сопоставьте время ухода с ожиданием, объявлениями и временем до первого предложения оператору. Если есть ENTERQUEUE без CONNECT, это ещё не готовый диагноз: выясните, как завершился вызов и какие события записаны далее. Структура журнала документирована и допускает разбор параметров; сохраняйте исходные строки, прежде чем строить сводку. Это помогает проверить выводы и пересчитать метрики, если определение «потери» поменялось. Минимальная таблица разбора может содержать время входа, имя очереди, исходное положение, время ожидания, число попыток дозвона и итоговое событие. Сопоставляйте записи по идентификатору канала и временным меткам, учитывая, что журналы могут ротироваться и что формат событий содержит поля после имени события. Не заменяйте исходный журнал агрегированным отчётом: сохраните копию за период, зафиксируйте часовой пояс и способ фильтрации. Так вы сможете проверить подсчёт, когда обнаружится, что один отчёт учитывал только ABANDON, а другой включал неответы устройств. Здесь нет волшебной кнопки «показать виноватого», зато есть проверяемая последовательность наблюдений.

Как выбрать стратегию и проверить участников

Я выбираю RingAll, когда требование действительно такое: свободные сотрудники должны получить предложение одновременно, а выиграет тот, кто первым ответит. При этом нужно проверить, кого очередь считает доступным, участвуют ли устройства, уже занятые разговором, и не получает ли один сотрудник параллельные вызовы из нескольких очередей. Параметр ringinuse связан с тем, будет ли Asterisk предлагать вызов участнику, чьё устройство уже занято; его смысл нельзя сводить к фразе «настройка от потери звонков». В официальном образце конфигурации есть отдельное описание опции и настройки на уровне очереди/участника. Ожидаемое поведение проверяют на ваших каналах и драйверах: состояние устройства должно корректно сообщаться системе.

Linear уместна, когда важен фиксированный порядок, например сначала дежурный, затем резервный сотрудник. Но «приоритет» в такой схеме не бесплатен: первые в списке будут получать больше предложений, а последние могут ждать дольше. Для распределения по кругу изучите rrmemory или rrordered; для выбора по числу завершённых вызовов — fewestcalls. У каждой стратегии свои условия учёта участника, и доступность важнее красивой теории. Не следует утверждать, что RingOne вызывает каждого ровно 15 секунд: это не подтверждённый встроенный режим, а общий timeout очереди имеет собственную логику и взаимодействует с вызовом приложения Queue(). Конкретное поведение зависит от конфигурации очереди, приложения и версии. Сверяйте действующий конфигурационный образец, а не случайный сниппет из старого форума. Не путайте стратегию распределения с управлением временем ожидания. В конфигурации очереди есть timeout и retry; приложение Queue() также принимает аргумент таймаута, а timeoutpriority влияет на то, какое значение важнее при переходе между попытками. Поэтому нельзя описать универсальное правило «позвонили первому 15 секунд, потом второму» без контекста конфигурации. Отдельно проверьте wrapuptime, паузы участников и правила joinempty/leavewhenempty, если звонки остаются в очереди без доступных операторов или покидают её раньше ожидаемого. Я фиксирую значения до изменения, затем проверяю на копии конфигурации или в согласованное окно, чтобы не получить сюрприз в рабочее время.

План проверки: от конфигурации к статистике

Перед изменением выпишите текущую стратегию, участников и их порядок, настройки timeout, retry и ringinuse, а также правила, по которым звонок входит в очередь и покидает её. Не копируйте значение таймаута из чужого кейса: duration предложения участнику и общее время, которое вызов проведёт в очереди, — не одна и та же величина. Для конкретной инсталляции проверьте документацию своей ветки Asterisk, образец queues.conf и параметры вызова Queue() в диалплане. Воспроизводите сценарии тестовыми звонками: свободны все участники; свободен только один; первый не отвечает; устройство занято; сотрудник на паузе; очередь пуста. Так обнаруживаются условия, которые не видны в строке strategy.

После изменения сравните одинаковые интервалы и разделите попытки дозвона, отвеченные вызовы, уходы абонентов и вызовы, завершившиеся по таймауту/маршруту. Проверьте, что журналирование очереди включено и что ротация не уничтожает период, который вы анализируете. Не делайте вывод за один короткий отрезок и не смешивайте рабочие и нерабочие часы. Если панель предлагает RingOne, найдите документацию именно этой панели и посмотрите, какое значение она записывает в queues.conf или передаёт через другой механизм. После этого проверьте очередь командой queue show и контрольными вызовами. Название режима следует переводить в фактическую конфигурацию, а итог — подтверждать событиями. Мониторинг не угадывает причину, зато помогает перестать спорить с ощущениями. Если после настройки доля ABANDON не изменилась, это не повод автоматически увеличить timeout. Сначала посмотрите, на каком этапе формируется ожидание: до входа в очередь, во время приветствия, между попытками вызова, при отсутствии доступных участников или после истечения общего срока ожидания. Затем сверяйте соответствующие события журнала с маршрутом в диалплане и расписанием. Смена RingAll на linear может лишь перенести нагрузку на первых участников и увеличить ожидание тех, кто стоит дальше; само по себе это не уменьшает число ушедших абонентов. Изменение считается полезным, если оно соответствует заданному сценарию и измеримые показатели улучшаются на сопоставимых данных, а не потому, что новая стратегия звучит убедительнее.

Частые вопросы