Добрый день!
LDK-300, прошивка 3.8Ah.

Пытаюсь добиться проигрывания сообщения "Все линии заняты" в случае, когда очередь Max Queued Call Count в UCD-группе полна.
При попытке реализовать это через Alternate destination (hunt на специальную группу) переход осуществляется ДО проверки очереди (то есть очередь пуста, и вместо очереди звонящий перекидывается на Alternate Destination).
Собственно, вопрос - можно ли как-то реализовать задуманное (проиграть сообщение перед сигналом "занято" по достижении Max Queued Call Count)?

А Alt if No Member? Вам же написали в другой ветке...

Нет.
- Alternate destination выполняется сразу же при поступлении вызова в группу при условии занятости всех агентов группы;
- Все речевые сообщения внутри группы привязаны к таймерам (время ожидания в очереди), а не к событиям.

А по событию достижения макс. длины очереди возможна только одна процедура - разъединение вызова.
Вызов может покинуть очередь только сразу же (на входе в группу) по Альтернативе или по таймеру Overflow.
з группы вызов может только сразу же по Альтернативе, или по таймеру Overflow.
Так что в вашем случае, ИМХО, нужно просто держать вызов некоторое время в очереди, а по достижению времени ожидания обслуживания = таймеру Overflow, отправлять дальше (например, в другую группу) или отбивать вызов.
Перед выходом из группы по таймеру Overflow можно выдать речевое сообщение - для этого нужно просто подобрать подходящее значение таймера/ов Voice Announce (таймеры Announce 1/2), которое должно быть меньше таймера Ovverflow (примерно на величину длительности этого сообщения).

Такое решение ("все операторы заняты" - отбой) фирму не устраивает.
Нужно именно "все операторы заняты, ждите" - [в очередь] - "все линии заняты, перезвоните позже" (если очередь полна)

поиск на форуме показал, что в одной из версий прошивок можно было завязать alternate destination на Max Queued Call Count:

http://www.artcom.ru/forum/index.php?showt...ost&p=20142

Но в моей версии alternate destination срабатывает ДО постановки вызова в очередь.

Ну, сейчас так и настроено.
Странно, что разработчик не предусмотрел нашей ситуации.
Спасибо.

А почему отбой то?

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

Какая у Вас версия прошивки??

Сейчас все настроено так:


То есть сообщение "приветствие" - перевод на абонента (если доступен) - сообщение "ждите" - в очередь; если очередь заполнена, отбой (короткие гудки); если таймаут ожидания - сообщение "линии заняты", отбой.

Как я понимаю, можно отказаться от очереди в пользу таймаута ожидания, но тогда возникает вопрос с контролем занятости линий (возможна ситуация, когда звонящие занимают ВСЕ внешние линии).

Прошивка 3.8Ah (указал в первом сообщении).
У меня сейчас при задействованном Alt Dest происходит переброс ДО проверки доступности очереди.
Хотелось бы, чтобы сначала проверялась доступность очереди, и лишь потом проброс на пустую группу с сообщением.

А сколько у вас абонентов в группе прописано?

12 станций

А тут в чем проблема? Ну заняты все внешние линии, И...

Как я понимаю, в этом случае у абонентов возникнут проблемы с звонками "наружу".
А звонящие будут вместо "приветствия" будут попадать на "занято".

Это да! Но, даже и при контроле очереди, звонящие могут слышать "занято" - часть линий заняты входящими вызовами, остальные исходящими...

Завтра предложу техдиректору попробовать схему без очереди, но с длинным Overflow.
Все же очень жаль, что нельзя реализовать мою задачу штатными средствами или перепрошивкой вверх/вниз.

Вы неправильно поняли тему, на которую ссылаетесь.
- Alt Dest. всегда проверяется на входе в группе, на 1-ом этапе!! Если Alt.Destю назначено и все агенты заняты, то всё - вызов не попадая в группу уходит на альтернативное назначение.
- А вот дальше, "на 2 -ом этапе"... :
до версиии 3.8Ct: если было назначено гарантированное приветствие (Timer1 =0), то оно и выдавалось, и только потом проверялось превышение длины очереди... Если Альтенатива не назначена, но агенты заняты, то получалось так: позвонил клиент, прослуслушал Приветствие ("Здравствуйте, вы позвонили в контору Пупкин и Ко "), и только после станция проверяет длину очереди, и по ее превышению отбивает вызов.... Клиент "оплеван"..

начиная с версии 3.8Сt, на" 2-ом этапе": проверка длины очереди выполняется до выдачи гарантированного приветствия, как мы и запрашивали у корейцев... Т.е. если длина очереди превышена, то вызов просто отбивается (клиент получает банальный сигнал "занято") без какого-либо приветствия... И все.
См. схему ниже (из нашего запроса в Корею).


Все ситуации невозможно предусмотреть и реализовать... Одним пользователям нужно одна фича, другим - прямо противоложная...

Первая часть вашей задачи решается очень просто, т.к. каждый абонент может быть одновременно агентом нескольких Hunt-групп (но группы - одного и того же типа, например, UCD).
Тогда:
- Создаете 2 Hunt-группы одинакового типа и с одним и тем списком агентов. Например, это группы H620 и Н621. В обеих группах прописаны одни и те же абоненты (например, 100, 101, ..., 111)
- Вызовы направляете в первую Hunt-группу, например, Н620. В атрибутах H620 в поле ALT DEST указываете группу H621.
- В атрибутах H621 указываете гарантированное приветствие ("Все операторы заняты, пожалуйста, ожидайте...")
- Если есть свободный оператор, то вызов остается в группе Н620.
- Если все операторы заняты, то вызов перебрасывается в группу Н621 (состоящую из тех же самых операторов), и клиенту гарантированно выдается речевое сообщение (заняты... ожидайте). Вызов будет в очереди пока не осводится агент или не истечет таймер Overflow. Потом можно дать другое сообщение (Извиняйте, перезвоните...).
Но вот связать выдачу второго приветствия с превышением кол-ва вызовов в очереди - не получится.

Длину очереди можно понимать по-разному:
- кол-во вызовов, ожидающих обслуживания (Max Queue Count)
- время, в течении которого данный вызов находится в очереди (Overflow). В вашем случае можно реализовать Overflow.

А если цикл из 2-х групп сделать - из одной выбрасывается в дгугую по пинку, пардон, максимуму кол-ва аб-в в группе, а в другой сообщение, ожидание и обратно по пинку (пардон) - переполнению в 1-ю группу - и так до посинения, пардон, - до освобождения члена 1-й группы

Ты там, упражняясь с тяжестями, не надорвался, случаем? Сам то понял, что написал?
Тихий троечник..

Простите, если что не так - я пошел спать..

- Overflow всем хорош, но как контролировать нагрузку на линии без Max Queue Count?
У нас есть пул цифровых линий на четыре номера. Один из номеров - Call-center. Если я буду использовать только Overflow, в пиковую нагрузку возможна ситуация, когда весь пул займут ожидающие звонящие в Call-center (все линии "лягут" на телефонный номер call-center). В этом случае остальные три номера не будут доступны, не говоря уже об исходящих из офиса звонках.

Вопросы:

1. Существует ли альтернативный Max Queue Count вариант контроля линий (ограничения количества линий на один номер), который позволит держать свободные линии для других телефонных номеров?

2. При использовании Max Queue Count возможно переопределить сигнал "занято" на голосовое сообщение "все линии заняты, перезвоните позже"? Отличаются ли с точки зрения АТС сигналы "занято" и "отбой" (в первом случае - нет свободного абонента, во втором - абонент положил трубку), можно ли сделать эти сигналы разными?

У вас в группе 12 абонентов. Включаете Alt if No Member на другую группу(к примеру, терминальную), в которой прописан абонет из плана нумерации даже и не существующий физически. В этой группе выставляете Overflow Timer 1 сек., Overflow Destination на VMIB c #(сообщение "все линии заняты, перезвоните позже").
При отсутствии свободных абонентов в первой группе вызов уйдет во вторую, где будет произнесена фраза "все линии заняты, перезвоните позже", после чего соединение будет разорвано. Такой вариант вам не подойдет?
Max Queue Count для первой группы, естественно, больше, чем абонентов в этой группе.

- А возможен третий вариант:
сейчас в группе приема вызовов 12 абонентов. Допустим, я проэмулирую очередь, добавив в группу 16 неиспользуемых станций (номера станций, не обслуживаемые телефонными аппаратами).
Ставлю Overflow в 5 минут, Alternate Destination - на группу с сообщением "все линии заняты, перезвоните позже".
Мои надежды, что это будет работать аналогично Max Queue Count: 12 звонков обслуживает 12 "живых" абонентов, 16 звонков ждут приема от "мертвых" станций (и при освобождении "живых" попадают на нее), 29-й позвонивший слышит сообщение "все линии заняты" и отбой.
Будет ли схема работать так, как я хочу? Не попадут ли звонящие на "мертвые" линии в вечное ожидание?

Я вам такое еще вчера хотел предложить, но сам в такой комбинации не пробовал! Но, по моему разумению, если вызов пришел на "мертвую" станцию, при освобождении "живой", он на нее не уйдет.

Но ведь при включенном Alt if No Member никто не будет попадать в очередь!
Реализовать выдачу сообщения "перезвоните позже" при отсутствии свободных операторов задача очевидная и легкая. Но нужно другое - в пиковую нагрузку держать пул ожидающих звонящих (иначе мы, выдавая им "занято", их теряем - не факт, что они перезвонят еще раз).
В моем последнем сообщении я изложил еще один вариант реализации очереди - можете посмотреть и сказать, будет ли работать?

ну теоретически как раз вроде бы должен уйти - это же UCD ("Группа РАВНОМЕРНОГО приема")!
впрочем, я с ldk-300 первую неделю работаю, до конца ни в чем не уверен...

Да, все так, никто и не спорит!
А вы смотрели вариант, который вчера предложил ув. harris?

1) Каких линий??? У Вас аналоговые 2-х проводки или ISDN??
2) Уже несколько Вам писали, что по событию = превышение Max Queue Count станция выполняет разъединение линии и ничего более. Переопределить действие для этого события нельзя!
Какие сигналы Вы хотите сделать разными??? Отбой - он и есть отбой. Станция разъединяет линию ("кладет трубку"), а уже городская АТС генерит для вызывающего абонента сигнал "Занято" (короткие гудки).

С чего бы ему уходить, коль "мертвый" номер свободен и принимает вызов.. Хотя, еще раз повторю, такое я сам не пробовал.

Да, смотрел. Но, насколько я понял, при таком подходе нагрузка на линии ничем не контролируется (по сути, предложенное ничем не отличается от Overflow при использовании одной группы).
Для меня принципиально важно зафиксировать число линий, занятых одновременно.
Думаю попробовать вариант с "мертвыми" станциями в качестве эмуляции очереди (только надо подумать, как проверить работоспособность схемы).

А "мертвые" номера вы какие хотите прописывать, те, которые физически имеются, но не используются?

Мда, пожалуй...

Да, и "мертвые" номера должны быть реальные!

[quote name='sunturner' date='21.6.2011, 10:46' post='51636']
- Overflow всем хорош, но как контролировать нагрузку на линии без Max Queue Count?
У нас есть пул цифровых линий на четыре номера. Один из номеров - Call-center. Если я буду использовать только Overflow, в пиковую нагрузку возможна ситуация, когда весь пул займут ожидающие звонящие в Call-center (все линии "лягут" на телефонный номер call-center). В этом случае остальные три номера не будут доступны, не говоря уже об исходящих из офиса звонках.

30 минус 12(абонентов в позиции ответа) минус такое такое кол-во абонентов в очереди, чтобы остались линии и для занятия для исходящей

И в том, и в другом случае ничего не получается - звонящий либо попадает в вечное ожидание, либо получает отлуп "все линии заняты".
Остается один вариант - использовать Overflow, а линии ограничивать физически (просить телефонного оператора зафиксировать пул линий за номером колл-центра). Это тоже не очень хорошо, так как большую часть времени (кроме пиковой нагрузки) линии не будут использоваться.
Интересно, может ли оператор связи не фиксировать пул, а установить максимум линий на номер (чтобы при низкой нагрузке линии распределялись по номерам, а при пике на номер колл-центра не выделялось линий больше установленного максимума)?

вроде того, но как это реализовать БЕЗ Max Queue Count?

Что и следовало доказать, в общем то!

Как я понял, в этом случае произойдет "вечное ожидание" - оператор свободен, но не берет трубку; звонящий ждет, когда оператор ответит; и ждать будет до истечения Overflow — так лучше уж сразу его отлупливать, а то больно безнадежно все.

Да.

Ну, ежели это все так критично, берите отдельный поток для номера колл-центра, все свои проблемы решите!

Ну да, и АТС-ку поменять )))
Кстати, интересно - есть какие-нибудь вспомогательные "девайсы", которые помогли бы в этой ситуации (LDK пробрасывает все входящие на вспомогательный АТС, он раздает их абонентам и организует очередь)?

Это не будет работать. Длина очереди никак не связана с кол-вом агентов, за исключением случая, когда Max Queue Count = 0. Тогда длина очереди =0, т.е. сколько агентов в группе, столько и вызовов в группу (остальным вызовам - отбой).
Прописать "неживых" агентов - бессмысленно. Если это будут неживые (неподключенные) системники, то это равносильно тому, что они вообще отсуствуют в группе, станция их не будет учитывать при распределении вызовов. Если прописать неподключенные SLT, то станция будет распределять на них вход. вызовы, и в UCD группе эти вызовы уже не вернутся на реально работающего агента, т.е. вызовы будут потеряны (вызов будет выброшен из группы по Overflow).

За удобства, знаете ли, приходится платить...

Мне вот чего не понятно! Ну хотите вы оставить часть линий для исходящей гарантированно, полюбому, будет ситуация, что к вам не дозвонятся! И стоит ли извращаться ради того, чтобы проговорить, что все абоненты заняты и дать отлуп...
С точки зрения звонящего, это мое мнение, конечно, лучше сразу услышать сигнал "занято", чем предварительно прослушать сообщение о невозможности принять вызов, причем заплатив уже за этот вызов...

Да, мы с Дроном уже пришли к этому выводу. Сегодня на совещании буду предлагать вариант без очереди и с маленьким (1 минута) Overflow.
В конечном счете, узкое место - явный недостаток агентов при пиковой нагрузке. Даже если реализовать ту задачу, которую я поставил, звонящие по межгороду будут ждать по 5-8 минут и все равно отлупливаься.

Обсудил сложившуюся ситуацию и возможности выхода с руководством.
Принято решение:

1. От очереди отказываемся
2. Выставляем Overflow в 1 минуту (в случае загрузки всех линий - уменьшаем до 30 секунд)

Спасибо всем принявшим участие в обсуждении!
Персональная благодарность пользователям Dron и Harris.

П.С. мне тему закрывать или оставить открытой?

А что подразумевается под закрытием темы??? Как Вы собираетесь ее "закрыть"??
Или Вы хотите подвезти ящик пива и тем самым закрыть вопрос??? (Шутка, и только шутка!!)

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

Рано закрыл тему.
После недолгих раздумий все же сохранил очередь.
Окончательный результат выглядит так:

1. Фиксируем очередью максимальное число доступных для колл-центра линий (по формуле Max Queue Count = "Число линий для колл-центра" минус "число станций в группе").
2. Подбираем время ожидания (Overflow) таким образом, чтобы при пиковой нагрузке очередь не достигала максимального значения (в моем случае - 2 минуты).

В результате никого не выбрасывает по достижению предела очереди (все выбрасываются по истечении времени ожидания); междугородние клиенты не висят по 5-6 минут с последующим отлупом; у человека, перезвонившего после выброса по времени ожидания, больше шансов дозвониться (очередь двигается заметно быстрее).

Так у вас работает Overflow! Количество вызовов в очереди не достигает просто значения Maq Queue Count, вот и все! А если превысит, то будет отлуп...
Работает все так, как оно работает.
Вывод один - если все это так при пиковой нагрузке, чего ж вы боялись, что не останется линий для исходящей связи?