На станцию установлен Е1 с многоканальным номером. Все вызова идут на одну группу операторов (USD). Позвонившим воспроизводятся сначала один ролик, после повторяется второй до ответа оператора, в промежутках музыка с внешнего источника. Требуется ограничить количество вызовов, находящихся в ожидании. Проблема в следующем, при привышении лимита вызовов в ожидании все равно проигрывается первое сообщение, а после отбой. Если ставить таймер первого сообщения на 1, то операторы иногда (при низкой загрузке) успевают взять трубку и приветствия не звучит. Как сделать так, чтобы сохранить голосовые сообщения, а при привышении лимита в очереди сразу давать отбой. Скрин: Нажмите для просмотра прикрепленного файла

Я правильно понял, что если VMIB Announce Timer 1 = 0 (гарантированное приветствие), то при превышении длины очереди вызов отбивается, но только после воспроизведения этого приветствия №1???? А нужно, чтобы отбой был сразу, без приветствия...???

А такой вариант: "Извините, сейчас все операторы заняты, перезвоните...." Это при условии всех занятых операторов. Другое дело, если заняты все линии многоканальника, здесь занято должен давать пров.

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

1. По поводу гарантированного приветствия. Тут изменить ничего нельзя. Гарантированное приветствие имеет более высокий приоритет. Корейцы проверяют занятость операторов и длину очереди после гарантированного приветствия.
Наверное, это не совсем верно, но чтобы они поменяли алгоритм нужно писать запрос. ИМХО, займет несколько недель (если они согласятся изменить софт).
В принципе можно попробовать сделать запрос на изменение.

2. Евгений предлагает Вам другой вариант: если все операторы заняты, то давать на входе какое-либо другое приветствие... Т.е. предупреждать клиента, что он дозванился правильно, но все операторы заняты. Далее он сам может решить ожидать в очереди или отбиться.
Это можно сделать за счет Альтернативного перенаправления вызова. В аттрибутах вашей UCD-группе указать в качестве альтернативного назначения другую (вторую) UCD-группу.
Создать вторую группу, к качестве ее агентов указать точно тех же операторов (агентов первой группы). В качестве гарантированного приветствия во 2-ой группе использовать какое-либо другое соответствующее по смыслу сообщение.
Будет:
- вход. вызов.
- если есть свободный агент, то вызов идет в группу 1.
- если нет свободного агента, то вызов идет в группу 2 (можно давать сообщение и отбивать линию, либо все-таки оставлять в очереди - как Вам будет удобнее).

Это в принципе подходит. Хотя и реализация через одно место..... попробую сделать. Там ещё есть Overflow Timer и Overflow Distanation, есть перевод на ячейку речевого ящика, вот только что будет после проигрывания сообщения, отбой? Т.е. следующий алогоритм :
1 вызов
2 приветствие
3 если нет свободных агентов ждём до истечения таймера
4 если таймер истёк то сообщение (нет операторов) и отбой.

будет ли это работать? (не уверен на счёт отбоя)

и в альтернативе тоже есть перевод на речевик, вот только работает ли он в связке с ограничением очереди?

Уважаемый harris, попробуйте сделать запрос, ибо это не правильно.

1. Оverflow ("переполнение") - это уже выход после ожидания в очереди. Это уже не связано с ограничением длины очереди.
Вызов из очереди можно передать на VMIB (в режим DISA для донабора номера) или на VMIB # (сообщение с последующим отбоем, без возможности донабора номера).
А можно и так: по окончанию таймера Overflow направить вызов в другую Hunt-группу (пустую, т.е. агентом группы прописать какого-либо неподключенного абонента, из последних абонентских портов), выдать в этой группе сообщение ("пардон, перезвоните...") и (если в этой пустой группе нет назначенного Overflow Destination) вызов будет отбиваться.
2. Правильно или неправильно - это все весьма относительно и субъективно. Вам нужно так, другим нужно совсем иначе... У корейцев была своя логика. Гарантированное сообщение - значит его нужно выдавать всегда, при любом вход. вызове.
ОК. На след. неделе попробую сделать запрос на изменение...

работает ли Max Queued Call Count в связке с Alternate Distanation? Это было бы хорошим решением.

Нет.

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

Работает ли Max Queued Call Count в связке с Alternate Destination? Если нет и будете делать запрос на изменение прошивки, то логичнее было бы сделать данную связку, чем отбой до гарантированного приветствия. Сам пока не экспериментировал.

Был вопрос:

ответили:


Эксперименты показали, что данная связка всё таки РАБОТАЕТ
Настройки сделаны в соответствии со скринами ниже:
Нажмите для просмотра прикрепленного файла и Нажмите для просмотра прикрепленного файла 621 группа из одного не существующего абонента.

Алгоритм следующий:
1. Всем позвонившим приветствие 1 ("Вы позвонили туда то")
2. Если есть свободные операторы то ответ оператора, иначе - 3.
3. Если есть место в очереди то сообщение 3 ("Дождитесь ответа оператора"), иначе перевод на группу 621
4. Сообщение 4 ("пардон, перезвоните позже") не поместившимся в очередь и отбой.

Соответственно для полного ажура нужно анализировать состояние очереди ДО гарантированного приветствия. и в Alternate Distanation иметь возможность переводить на ячейку голосовой почты.

1. Запрос в Корею сделан. Разработчики обещали изменить алгоритм в следующих релизах софта (анализ длины очереди после анализа Альтернативного назначения, но до гарантированного приветствия группы).
Подождем...., посмотрим...
2. По Альтернативе "иметь возможность переводить на ячейку голосовой почты"????
Уточните, чего Вы хотите добиться.

дать ответ перед отбоем позвонившим и не поместившимся в очередь, не используя для этого другую группу.

А чем не устраивает возможность выполнить то же самое через другую группу??
ИМХО, чем больше корейцы будут изменять сервис для Hunt-групп, тем больше вероятность поломать всЁ. Они уже и так не раз поясняли, что изменять софт для группового сервиса опасно - много всего "накручено"... ИМХО, лучше не стоит с этим к ним обращаться, поскольку нужный результат можно получить за счет другой группы.

....... ну и ладно , не стоит так не стоит, будем пользовать как есть. Когда ( если... ) сделают, то как узнать? Напишите в тему или на почту?

Ок. Сообщу на форуме, в этой теме..., если сделают....

ню..... сделали или нет? Воды то порядком утекло

Хмм, ну вообще-то, 4 месяца на изменение софта.... по корейским меркам - это совсем немного воды утекло...
Но в данном конкретном случае, да - уже сделали.
Пардон, я просто забыл сообщить Вам сообщить об этом на форуме.

На официальной версии 3.8Ct внесены изменения:
- Проверка длины очереди выполняется на входе в группу (до гарантированного приветствия, а не после как было раньше).
- Если длина очереди превышена, то вызов сразу отбивается без приветствия.


Версия, кажется, уже выложена здесь на сайте.

Ну это уже лучше, если не сказать что хорошо. (то же поправил )

О прошу прощения, зарапортовался.... Перепутал разные рекламации...
См. мой ответ выше я там исправил ответ....

И если не сложно, дайте ссылочку на прошивку. Когда буду шить предварительно слив настойки, после восстановление бекапа всё будет работать? И с какой версией админа будет работать эта прошивка?

Уважаемый Сергей Владимирович!
Я же Вам уже указал ссылку на софт... На этом же сайте, в разделе Download:
http://www.artcom.ru/download/
Далее выбираете нужную Вам модель станции (ipLDK100 или ipLDK300) и заходите в архив, относящийся к выбранной станции. Внизу страницы находите версию 3.8Ct для MPB.

Для этой версии нет отдельной версии PC-Admin'a. Нужен любой PC-Admin версии 3.8.

А какая сейчас версия у Вас установлена????

сорри, уже нашёл сам, спасибо огромное версия очевидно 3.6 но точно не уверен, завтра буду смотреть.

У Вас ipLDK-100 или ipLDK-300?????
Если 100-ка, то можно перепрошивать c 3.6 на 3.8.
Если же 300-ка, то нужно проверить вариант исполнения процессора. Для версии 3.7 и выше нужен процесоор Issue 6 или новый процессор - MPBN !!!!!!!! На старых процессорах (Issue 1~5) версия 3.8 не запустится.

Станция ipLDK100 версия MPB GS90P-3.7Bd. (смотрел Offline Admin) Если я правильно понял - то прошивка 3.7Bd. Волнует вопрос - чем шить и будет ли работать предыдущие настройки.

Перепрошивать ON-Line PC-Admin'ом версии 3.7.
Настройки сохранятся.
После перепрошивки нужно выполнить инициализацию версии 3.8 в ПГМ452.
Далее нужно пользоваться PC-Admin версии 3.8.

Ок. Спасибо harris помощь. Отпишусь по результатам.

ФУУУ, перелил прошивку..... Не без приключений. . После всех ресетов и заливки базы ни как не хотел подниматься поток. Я уж думал всё, кранты. Долбал поддержку на ГТС. Пока они там не догадались отбить каналы. Как сбросили каналы, всё покатилось тип топ. Ограничение количества ожидающих абонентов в очереди группы вроде работает. Буду завтра проверять. Спасибо harris за помощь, без вас бы это не срослось, ну и корейцам за оперативность .

P.S. А инициализация версии 3.8 в ПГМ452 с системника - пк11? Или я что то путаю.

Да. Все верно.