LIK-600
MFIM/GS97M-6.1Bf DEC/14
Boot Version-2.1Aa NOV/12
Kernel Version-6.0Aq
H/W issue-3

В Flexible DID Conversion(231) прописана группа *625 (Ring), в Station Group Attributes(191) для этой группы указан Overflow Timer - 15 и Overflow Destination SYS SPD - 2000. То есть я предполагаю, что если никто не ответит за 15 секунд, то звонок переведется на номер, указанный в System Speed Dial 2000. Однако звонок не переводится.

Если в Flexible DID Conversion(231) указать не группу, а прямо SPD 2000, то звонок уходит в город как положено. Прямой набор SPD 2000 тоже работает. Даже если в свойствах группы *625 указать STA/NET or Hunt внутренний номер, то все нормально (то есть Overflow Destination - срабатывает).

Что это может быть? Как решить задачу переводить звонок по неответу группы на сотовый?

P.S. Можно попробовать "прокладку" в виде еще одной группы, используя Forced Forward Destination для нее.
P.P.S. Не помогло.

Проверил у себя на 6.1Bf- работает.
У вас нет в группе голосового сообщения?

Ага, спасибо за потраченное время на проверку. Попробую перезагрузить станцию с перезалитием конфига (станция работает уже несколько лет). Могу показать конфигурацию - вдруг там есть какие косяки, которых я в упор не вижу (у меня уже была ситуация, когда я банально "тупил").

Изначально оно было - проигрывалось перед тем как попасть в *625 группу. Но потом я его убрал для локализации проблемы.

Просто может влиять длинна голосового сообщения, если оно больше чем время overflow, то переадресация не сработает.

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

Голосовое сообщение проигрывается ДО переадресации в группу. В 231 программе указано VSF1, а в DID/DISA Destination(167) (при этом CCR Table(228) - пустая) указана группа для обработки ошибки и занятости. Для проверки я убрал голосовое сообщение вообще и в 231 программе указал новую только что созданную Ring группу *625, а в ней прописал уже переадресацию по Overflow. Сама переадресация срабатывает, но только если указан внутренний номер. А если указать SPD, то ничего не происходит. В самой группе Station Group Attributes(191) VSF не прописаны.

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

[quote name='ADv' date='31.5.2016, 13:57' post='97281']
Сама переадресация срабатывает, но только если указан внутренний номер. А если указать SPD, то ничего не происходит. В самой группе Station Group Attributes(191) VSF не прописаны.
[quote]

Если с внутреннего номера позвонить на группу, переадресация будет?
Какой тип городских линий стоит Normal или DID?
По этим линиям в 144 программе что прописано?

Тип линий DID - это поток. В 144 программе ничего нет. На группу звонить не пробовали.

Не важно что поток. Поток может работать и как Normal. В 144 точно ничего нет, вы проверяли по всем линиям?
Попробуйте просто с внутреннего порта набрать номер группы, будет ли переадресация?

cos co-co???

влиять не должно.

При прямом вызове группы со внутреннего номера - все переадресуется.

Кстати, DISA COS(166) стоит в 7. Но ведь это не DISA-набор.

Возможно, проблема в АОН при попытке переадресации.
Проверьте АОН (CLI), который станция посылает при переадресации в поток.
В ПГМ 143 опция [CLI TRANSIT] должна быть = CFW.
И у системного аттенданда должен быть прописан правильный АОН, т.к. при переадресации из группы используется именно АОН сист. аттенданта.

Да, действительно, там стояло ORI. Исправил, проверил - не работает. АОН у системного аттенданта правильный, правда используется Station CLI 2. В общем-то, это следовало ожидать, поскольку при указании SPD 2000 в 231 программе перевод осуществляется без проблем, а если добавить "прокладку" в виде группы - нет.

1. Снимите трассировку потока при переадресации. И посмотрите АОН!!
2. АОН типа CLI 2 может не работать при переадресации (так же, как при транзите).
Поэтому пропишите нужный АОН для аттенданта в виде Normal.

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

Возникла задача один в один. Прошивка станции та же. Входящий городской приходит на группу из двух внутренних, затем должен переадресовываться на сотовый...


АОН абонентов в группе прописан правильный в CLI1. При наборе группы с внутреннего переадресация происходит. При наборе с городского на группу нет.
В ПГМ 143 опция [CLI TRANSIT] стоит = CFW.
У системного аттенданта стоит альтернативный АОН в CLI1 и при наборе группы с внутретреннего АОН приходит не аттенданта, а вызывающего абонента.

Пробовал сделать переадресацицию по не ответу в ПГМ 120. Если на прямую, то работает. если вызов через группу приходит, то так же переадресация не проходит.

А какие настройки группы?

Это все для входящих линий?

В группе 2 вн. номера. Переадресация на ячейку SPD по Overflow Destination.

Да.
Входящие линии поток Е1. При звонке на городской номер в ПГМ231 настроен вызов на Station Group.

А ячейка как прописана? Через какие линии номер набирается? Имеется в виду, эти линии разрешены аттенданту для исходящей?

Еще у аттенданта может быть включено BLOCK Back Call.

BLOCK Back Call=off
Для аттенданта никаких запретов нет.
При наборе с внутреннего группы напрямую, переадресация на SPD срабатывает. И АОН идет не аттенданта, а именно вызывающего абонента.

Это другая ситуация! Тут задействована ОДНА внешняя линия. В проблемном варианте задействованы ДВЕ внешние линии и переадресованный вызов осуществляется как бы от аттенданта.

Проверил вариант с задействованием двух внешних линий. Поставил в ПГМ120 при звонке на вн. номер переадресацию на SPD по неответу. Настроил городской на этот вн. номер и набрал его. Сработало. Вызов с городского ушел на сотовый.

Тут тоже не совсем та ситуация! Тут переадресация для конкретного номера. У вас же вызов на Station Group и Overflow на SPD.
Аттендант может звонить по тем же линиям, по которым номер из ячейки набирается?

Аттендант у меня это последний номер в плане нумерации моей АТС. Физически он не существует. Ограничения никакие ему не прописывались. Прописывался лишь АОН.
В ячейке настроен выход на группу городский линий (поток Е1) по которым и поступает вх. вызов.

PS Перенастроил аттенданта на цифровой порт. Все тоже самое. Причем звонок куда то уходит. Вызывающий слышит посылку вызова, а до номера в ячейки звонок так и не доходит.

Так и было ранее?

Да.
Попросил оператора посмотреть с каким АОНом уходит мой вызов при переадресации. Думал АОН не правильный и АТС оператора просто меня не "пропускает". Так вот смотря весь поток, он увидел, что входящий звонок регистрируется, а дальше никакая линия не занимается. Переадресация по ячейке не срабатывает. Звонок "гуляет" где то внутри АТС, а вызывающий абонент слышит посылку вызова.

Вообще, весь принцип работы основной перекочевал с ipLDK. Как и на Aria Soho. Так вот, в свое время на Aria Soho я обнаружил, что имеется баг в вашем варианте - на ячейку вызов уходил через раз. Т.е. первый вызов на ячейку, второй на аттенданта (возможно по назначению для error, тут я глубоко не копал). Я и тут про это в свое время писал.
Возможно, тут тот же баг остался. Не могу сказать, сам давно так не пробовал настраивать.
Могу просто предложить вариант назначить Overflow на Station для которого уже переадресацию настроить на вашу ячейку.

Спасибо. Только этот вариант и работает.
Только до сих пор не понятно откуда береться АОН? Высветился АОН (дефолтный на потоке) не аттенданта и не вн. абонента на которого пришел городской вызов.

Видимо, подставляет провайдер. Обычно провайдер сам подставляет АОН, если получает неправильный АОН или если АОНа нет вовсе.
В нормальном варианте должен бы высвечиваться АОН абонента, у которого вызов переадресовывается.