iPECS-MG/GS55M-2.1Ac DEC/12
Boot Version-1.1Ab AUG/11
OS Version-1.1Ab AUG/11

Создал группу *620 RING.
В Incoming CO Ring Assignment для нескольких CO указал Feature - Stantion Group *620; Delay 0.

При вызове, если есть свободные операторы из 620 группы, то вызов направляется оператору и АТС не поднимает трубку и не проигрывает мелодию вызывающему абоненту.Вызывающий абонент слышит обычные гудки.

Но если в группе нет свободных операторов, то АТС берет трубку и проигрывает мелодию, что не желательно.
Как настроить, чтобы при занятости всех операторов в группе АТС не отвечала на вызов и не проигрывала мелодию.

Посмотрите, какое значение указано в опции [Queuing Tone Type].
ИМХО, в вашем случае там должно быть = Normal. (Я сам не проверял).

Выставил Queuing Tone Type=Normal в Greeting Announcement,First Queuing Announcement,Second Queuing Announcement.

Теперь АТС берет трубку и вызывающий абонент слышит обычные гудки, вместо мелодии. Как сделать чтобы АТС не брала трубку?

Max Queue Count = 0. Если я правильно понял, что вам надо. Сумбурно описано...

Попробуйте в опции [Provide Announcement with Answer] поставить значение = 1: w/o answer.

Я профан в АТС. Попробую описать понятней.

В 620-й группе есть абонент 100.
1. Поступает новый вызов абонент 100 принимает вызов.
2. Поступает еще один вызов.
3. Поскольку абонент 100 занят АТС ставит звонок в очередь 620-й группы.
4. АТС Проигрывает приветствие(Greeting Tone Type).
5. У вызывающего абонента начинается тарификация звонка(звонит с мобильного телефона)

Надо чтобы АТС ставила звонок в очередь 620-й группы, но тарификация у вызывающего не начиналась.

После установки Provide Announcement with Answer значения = 1: w/o answer. не дает видимого эффекта.
При установке Max Queue Count = 0 вызов не ставится в очередь, при занятых абонентах группы. Т.е. когда освобождается
абонент 100, то вызов к нему не придет.

Ну, ежели АТС проигрывает приветствие, то она ответила. Вам надо исключить все приветствия.



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

А, разве, в таком случае АТС берет трубку? Однако, не проверял специально как оно на MG. Надо будет проверить.

Да, станция занимает линию и генерит КПВ.

Ага, при установке Greeting Tone Type, Queuing Tone Type в Normal имеем Greeting Tone No, Queuing Tone No соответственно = 4 по-умолчанию из Tone Frequency/Cadence(264)[N]. Т.е., и без проверки понятно, что станция занимает линию и генерит КПВ.
Как то неправильно это... А я об этом и не задумывался...

А если выставить Greeting Play Timer, Queuing Forward/Second Queuing Annc. Timer, Queuing Forward Timer > Ring No-Answer Forward Timer. Может это поможет?
Сам то я завтра попробую...

Поставить нули ??
Я это проверял. - Нет. Все то же самое.

Нет, Ring No-Answer Forward Timer = 170, а Greeting Play Timer, Queuing Forward/Second Queuing Annc. Timer, Queuing Forward Timer = 180, например.
Или, достаточно только Greeting Play Timer = 180, так, видимо.

Какой смысл?? ИМХО, это все не имеет значения. Станция исходно, сразу же при попадании вызова в очередь проключает линию. Именно при попадании в очередь. Т.к. если агент свободен, но не отвечает на вызов, то линия не проключается, а остается в состоянии Ring.

Понятно. Но, завтра поэкспериментирую...

Ну, насколько я мог проверить - Да.

Может, имеет смысл отказаться в данном случае от использования Hunt-группы (Ring), и просто назначить одновременный вызов на несколько абонентов в ПГМ167 (назначить Ring Assign вместо Feature).
Все равно ведь никакие свойства группы не требуются.

Да, видимо, только так! Сегодняшние эксперименты с группой к положительным результатам не привели - станция однозначно отвечает, если в группе некому ответить (все операторы заняты).

Мдя.... Все-таки есть решение для использования Hunt (в данном случае Ring) группы.
Нужно для входящей линии (если это аналоговая СО) ВЫКЛЮЧИТЬ опцию [CPT Detect] в программе Incoming CO Attributes.

Нда... Я в этом направлении даже и не стал экспериментировать. Опять CPTU...

Выключил - ничего не изменилось! Что то еще плюсом??

Свойства группы как раз требуются. У меня диспетчерская с 12-ю операторами.
Сейчас работает Aria SOHO. Абоненты в RING группе и с постановкой в очередь звонка все нормально.
На MG хотел использовать тип группы Longest IDLE для равномерного распределения нагрузки на диспетчеров.
Неужели на флагманской модели LG нельзя настроить так же как и на сохе? Из каких соображений корейцы заложили принудительное проигрывание мелодии?
Просто этот момент довольно критичен. Клиент не сильно обрадуется, что вынужден платить за ожидание...

Когда я пробовал использовать Ring Assign, то получалось следующее:
Есть абонент 100.
1. Поступает новый вызов, абонент 100 принимает вызов.
2. Поступает еще один вызов.
3. Абонент 100 освобождается
4. Новый вызов остается "висеть" (гудок у вызывающего идет), но АТС не сигнализирует абоненту 100 о наличии вызова..
Абонент 100 это локальный SIP клиент.
Указываю только одного 100 абонента для наглядности.

Но все равно распределение вызовов с логикой заложенной в группы очень предпочтительно.

Я боюсь, что с sip абонентами не ивсе может быть хорошо в группе. Во всяком случае, на LIK'ке наблюдал шереховатости.
В принципе, на MG я проверю сейчас.

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

Я проверил, правда с одним вызовом. sip абонент занят - разговаривает с другим внутренним абонентом. В группу поступает вызов, после освобождения sip абонента на него поступает вызов.

И, все же, какая логика групповая вам нужна? У вас же группа ринговая - вызов поступает одновременно на всех. Что еще нужно?

Я в тестовом режиме запускал АТС и кстати даже при небольшом потоке звонков(3-4 одновременно) подмечал, что вызов висит на линии, но оператору не поступает. Тогда не придал этому значение. А получается, что такая проблема существует с SIP клиентами? И как с ней бороться? В пятницу собирался включить в час пик, а там будет около 20 вызовов в очереди..

Я не берусь утверждать, что такая проблема с SIP клиентами существует! Я это не проверял.
О, вы говорите о неких soft фонах? Я проверял с LIP-8002A.

По поводу использования HUNT группы:

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

В CO Line Attribute(160~163):
- выключить LOOP DETECT (Open Loop Dectct Timer = 0 )
В Incoming CO ATTR(165~166):
- выключить CPT Detect (= OFF)

+ вышеуказанные настройки атрибутов внутри группы.

И тогда линия при постановке в очередь не проключается.
Вот и решение задачи.

Проверил с двумя внешними вызовами на X-Lite - все нормально фунциклирует!

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

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

Спасибо!!! Буду сегодня пробовать.

И Provide Announcement with Answer = Without Answer!

Мы пользуемся собственной разработкой ПО. Если будут проблемы с распределением вызовов в группу абонентов, буду проверять на X-Lite.

Вызов только не сразу поступает после освобождения, а секунды через 2-3.

CPT Detect = OFF помогло. АТС не берет трубку и не проигрывает приветствие.

С SIP клиентами в вызывной группе есть проблема. Вернее совсем не понятно как распределяются вызовы.
Ситуация 1: есть группа 620 RING(или Longest IDLE). В группе 2 абонента. Абонент 100 - терминал и абонент 140 -локальный SIP клиент.
1. Поступает вызов на аналоговую CO
2. Вызов отображается на 100 и 140 абонентах.
3. После 20-ти секунд у 140 абонента наступает событие "RingingStop" и вызов от него "уходит", а у абонента 100 продолжает висеть гудок у вызывающего абонента продолжается.
Если в группе только SIP клиенты, то вызов уходит от всех и у вызывающего абонента идет гудок.


Ситуация 2: есть группа 620 RING в группе 4 SIP абонента. Группа привязана к 12-ти аналоговым CO.
1. Поступают 4 вызова.Абоненты принимают вызовы. Все абоненты заняты
2. Поступают еще 4 вызова, вызовы ставятся в очередь, поскольку все заняты.
3. 4 абонента освобождаются, но двум из них приходят вызовы из очереди, а два вызова остаются "висеть".
4. Поступает еще 1 вызов, он приходит одному из 2-х свободных абонентов.
5. Все абоненты освобождаются, но те 2 вызова все равно висят в очереди, пока вызывающие не скинут.
Отключение\подключение SIP клиентов, пока "висят" вызовы не помогает.АТС не распределяет вызовы.

Последовательность может быть разная. Но вызовы находящиеся в очереди не всегда, но очень часто не распределяются ни одному из SIP абонентов в группе.
Пробовал типы групп RING и Longest IDLE.

SIP клиент SoftPhon X-Lite(пробовал разные).

В первом случае наверно есть какой-то таймер?

А со вторым случаем совсем непонятно? Хотя может быть таймер виноват, по которому от SIP клиента "уходит" вызов?

1) А Вы не пробовали просто поиграться таймером, который указан в атрибутах группы??
[Member No-Answer Timer]
2) А какое значение стоит для таймера [Queuing Call Idle Member Check Timer] ??

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

1. Пробовал поиграться с Member No-Answer Timer, когда тип группы Longest IDLE. У диспетчеров стоит автоответчик, который хватает вызов сразу по поступлению. А так как когда оператор занят, то ему второго вызова и не придет, то разницу в настройке этого параметра не заметна.
Попробую поставить группу RING и Member No-Answer Timer=60. Получается через 60 сек.
вызов из очереди не придет SIP участникам группы? И почему вообще на терминале вызов остается, а SIP клиенте нет? Они же равнозначные участники группы, или они по другой логике работают? Завтра постараюсь попробовать и напишу. Какие еще параметры можно попробовать изменить?
2. Queuing Call Idle Member Check Timer = 5.

Вот вариант решения.
Сделать это можно, например, так.
В вашей группе Forvard Type = Time Out, Forvard Destination - ринговая группа без членов в атрибутах которой для First Queuing Announcement Quering Tone Type = Promt: Queuing Forward/Second Quering Annc. Timer = 1; для Second Queuing Announcement: Queuing Forward Timer = 0; все остальное оставляем по-умолчанию.

1) Нет. Проверил. В Ring группе этот таймер не имеет значения (и это правильно).
ИМХО, нужно бы посмотреть таймер No_Answer в самом SIP телефоне.
Хорошо бы трассировку посмотреть, чтобы понять, кто отбивает вызов: станция или SIP телефон.

А если нет в группе SIP телефонов, то все тоже самое. Это не о том.

А почему вызов уходит только с SIP клиента а на терминале он есть?
И взять вызов на терминале можно.
После чего MG перестает слать вызов? Как ее заставить слать вызов участникам группы пока вызывающий абонент сам не скинет?

Ваш терминал, видимо, аттендант. А по альтернативе что то назначено на аттенданта, видимо. Тут надо уже смотреть конфиг, чтобы понять что да как.
А у себя я сейчас проверил - в группе системник и X-Lite, звонить перестают оба!

?? Если не SIP, то у меня, например, системник LIP-8024 продолжает звонить до упора.

По таймеру, естественно! После чего ж ему еще прекращать слать вызов?! Или, если вызов перестает извне поступать.

Игорь, а что у тебя с другими настройками?
Ща я еще раз, конечно, проверю...

В-общем, ИМХО нужно бы трассировку смотреть. А так можно долго гадать.

Проверил - перестают звонить оба (естественно, по истечении Ring No-Answer Forward Timer). А внешний абонент продолжает слышать посылки вызова.

Я с LDP-7024D экспериментирую. Как оно с LIP в данной ситуации не знаю...

Похоже, MG не отбивает аналоговую линию "по Overflow". Получается, нужно предусматривать доп. меры для отбоя.