Работа голосовых сервисов в USD группе, ipLDK100 Опции

[Сергей Владимиро...]

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

[harris]

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

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

[Сергей Владимиро...]

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

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

[harris]

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

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

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

[Сергей Владимиро...]

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

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

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

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

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

[harris]

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

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

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

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

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