Trunk loop
Модератор: Administrator
Trunk loop
Подскажите решение проблемы!
Есть транк 98, в нем 3 СО линии, Trunk direction: incoming.
Периодически status trunk выдает следующие
0098/001 01A1004 in-service/active no 01A1005
0098/002 01A1001 in-service/idle
0098/003 01A1005 in-service/active no 01A1004
Получается кольцо и линии так подвесают пока не сделать busyout/release.
Кольцо образуют только эти 2 порта, значит причина кроется в номерах которые висят на этих линиях. Кто-то повидимому устраивает конференцию или переводит не правильно.
Можно ли это как то отследить?
Есть транк 98, в нем 3 СО линии, Trunk direction: incoming.
Периодически status trunk выдает следующие
0098/001 01A1004 in-service/active no 01A1005
0098/002 01A1001 in-service/idle
0098/003 01A1005 in-service/active no 01A1004
Получается кольцо и линии так подвесают пока не сделать busyout/release.
Кольцо образуют только эти 2 порта, значит причина кроется в номерах которые висят на этих линиях. Кто-то повидимому устраивает конференцию или переводит не правильно.
Можно ли это как то отследить?
-
- ACS-Implement
- Сообщения: 575
- Зарегистрирован: Пн 05 фев 2007, 10:25
- Откуда: Москва. Небольшая конторка. Не интеграторствую.
- Контактная информация:
Chem-Li, шаг 1 надо просто не допускать такой ситуации. В свойствах транк-группы выставить Disconnect Supervisor In? N Out? N, да trunk-to-trunk transfer в sys fea запретить. Тогда не получится переводить вызовы на СО-линиях и соответственно подвешивать их. Второй шаг - установка отбойников. Шаг 3. Отказаться от СО в пользу isdn-pri если пользователям требуется переводить вызовы. Только так можно "лечить эту болезнь".
rtfm такой rtfm
Да, согласен. НО тогда не получится переводить поступившие на СО звонки на другую атс, если они соеденяются между собой через isdn-pri! А это достаточно критичная задача!War Dialer писал(а):Chem-Li, шаг 1 надо просто не допускать такой ситуации. В свойствах транк-группы выставить Disconnect Supervisor In? N Out? N, да trunk-to-trunk transfer в sys fea запретить. Тогда не получится переводить вызовы на СО-линиях и соответственно подвешивать их. Второй шаг - установка отбойников. Шаг 3. Отказаться от СО в пользу isdn-pri если пользователям требуется переводить вызовы. Только так можно "лечить эту болезнь".
-
- Участник форума
- Сообщения: 103
- Зарегистрирован: Вт 10 окт 2006, 11:59
- Откуда: Байконур
- Контактная информация:
Если мну память не изменяет ограничения на запрет перевода звонков можно обойти в COSe параметром
Restriction Override
Указанным пользователям разрешается обходить ограничения по
конференц-связи, переадресации или пересылке вызовов.
избранным этот COS назначить.
Restriction Override
Указанным пользователям разрешается обходить ограничения по
конференц-связи, переадресации или пересылке вызовов.
избранным этот COS назначить.
Кто *** в дождь и грязь - наша доблестная связь!
Если нет дождя и грязи - нас *** начальник связи!
Если нет дождя и грязи - нас *** начальник связи!
-
- Постоянный участник форума
- Сообщения: 2891
- Зарегистрирован: Пн 07 июл 2008, 16:51
- Откуда: Москва
- Контактная информация:
В настройках транка выставлено Direction - incoming, следовательно в транке с СО Disconnect Supervisor Out отсутствует т.к. уже указано направление звонков!Pterodahtil писал(а):вроде такой алгоритм:
в sys fea разрешить trunk-to-trunk transfer
в транке с СО Disconnect Supervisor In? Y Out? N
в транке PRI Disconnect Supervisor In? Y Out? Y
таким образом перевести пришедший по СО вызов опять на СО нельзя, а на PRI можно.
Если я правильно понял то вы предлагаете Restriction override none в cor'е назначенном этой транк-группе?!SaM писал(а):Если мну память не изменяет ограничения на запрет перевода звонков можно обойти в COSe параметром
Restriction Override
Указанным пользователям разрешается обходить ограничения по
конференц-связи, переадресации или пересылке вызовов.
избранным этот COS назначить.