У меня на одном из PRI потоков (один отдельный рут) существует проблемка. К примеру установлено транзитое соединение между городским рутом и еще одним (проблемным) рутом. Если с городского рута положили трубку, то в D-канал проблемного рута сигнал запроса дисконнекта передается только через 32 секунды. На другие направления дисконект в подобной ситуации передается сразу.
Никак не могу найти причину задержки передачи дисконекта.

Попробуй в D-канале поставить таймеры INC_T306 и OUT_T306 в 0.

Борода! у меня на руте не таких промтов, релиз 25.15

Да-а-а...

Ночью другими делами заниматься надо :-)))

Русским-же языком тебе написали:

В Д-КАНАЛЕ !!!

Имеется ввиду EURO в город.

Да, наверное ты прав. Но у меня только " IFC ISIG " стоит таймеры другие:

ADAN DCH 18
CTYP MSDL
GRP 1
DNUM 0
PORT 0
DES MOBILON
USR PRI
DCHL 18
OTBF 32
PARM RS422 DTE
DRAT 64KC
CLOK EXT
IFC ISIG
ISDN_MCNT 300
CLID OPT0
CO_TYPE STD
SIDE NET
CNEG 1
RLS ID **
RCAP COLP
MBGA NO
OVLR NO
OVLS NO
T310 120
T200 3
T203 10
N200 3
N201 260
K 7

"Соединение с городом" по QSIG, да еще и будучи NET'ом...
Хм-м-м...
Мягко говоря - оригинально.
А "проблемный маршрут", наверное, как раз - EURO?

С такими схемами включения надо безумно радоваться, что вообще что-то работает.

Более того - Меридиан не Central Office Switch.
Это обычный PABX. И его возможности в качестве транзитного узла велики, но не беспредельны...

То, что со стороны абонента А по PRI приходит disconnect с progress indicator'ом, указывающим на необходимость удержания канала для трансляции акустического BUSY - вполне нормальный сценарий отбоя со стороны CO. Но Меридиановская фича "ISDN PRI CO connectivity" не подразумевает использования QSIG.

Если проблемное направление - EURO, то можно посмотреть промтик OUT_T306 там...
Хотя - в любом случае - это все сродни регулировке клапанов через выхлопную трубу :-)))) (с) не мой

Я прошу прощения за внесение неразберихи, но городское направление работает по EURO, и оно не проблемное. Проблемное как раз направление ISIG, но я хочу перепрограммировать его на EURO, может что-то измениться.

А-а...

Тогда повторю еще раз:
имеется ввиду входящее EURO направление.

Выставив в Д-канале INC_T306 в ноль, можно принудительно заставить Меридиан отбивать звонок (release), сразу после входящего disconnect.
Если PABX'ы, включенные в Меридиан транзитом, сами умеют формировать своим абонентам BUSY, то проблема будет решена.

Схема включения:

CO switch (net) --- EURO --- Meridian 1 (user) --- QSIG --- other PABX

совершенно правильная. Менять ее - нет абсолютно никакого смысла.

Да, изменив INC_T306 в ноль, все наладилось, но все-таки, на другие направления с городского рута EURO приходили disconnect-ы, а на проблемный нет. Почему Меридиан не посылал этот disconnect только на один рут?

Возникла такая же проблема на транзите EURO-EURO.

Схема включения следующая:
CO1 switch (net) -- EURO -- (DCH13) M1 opt.11C (DCH10) -- EURO -- CO2 switch (net)
Меридиан на обоих направлениях - user. Точно так же с CO2 приходит дисконнект с прогресс индикатором "INBAND INFO" и меридиан вообще не отдаёт дисконнект в СО1 (по крайней мере прослушивание коротких гудков на стороне СО1 в течение 2 минут ничего не даёт). Пробовал менять таймеры *T306 на стороне СО1 - эффект нулевой - такое ощущение что они вообще не работают.

DCH 13 UIPE_IMSG CC_SETUP_IND REF 00000040 CH 4 21 TOD 12:02:56
PROGRESS: ORIGINATING END IS NOT ISDN
CALLING #:0000000246 NUM PLAN: E164
CALLED #:88121051199 NUM PLAN: E164

DCH 10 UIPE_OMSG CC_SETUP_REQ REF 00000025 CH 1 15 TOD 12:02:56
PROGRESS: ORIGINATING END IS NOT ISDN
CALLING #:0000000246 NUM PLAN: E164
CALLED #:88121051199 NUM PLAN: E164

DCH 13 UIPE_OMSG CC_PROCEED_REQ REF 00008040 CH 4 21 TOD 12:02:56

DCH 10 UIPE_IMSG CC_PROCEED_IND REF 00000025 CH 1 15 TOD 12:02:56

DCH 10 UIPE_IMSG CC_PROGRESS_IND REF 00000025 CH 1 15 TOD 12:02:58
PROGRESS: CALL IS NOT END TO END ISDN

DCH 13 UIPE_OMSG CC_PROGRESS_REQ REF 00008040 CH 4 21 TOD 12:02:58
PROGRESS: CALL IS NOT END TO END ISDN

DCH 10 UIPE_IMSG CC_SETUP_CONF REF 00000025 CH 1 15 TOD 12:03:12
PROGRESS: CALL IS NOT END TO END ISDN

DCH 13 UIPE_OMSG CC_SETUP_RESP REF 00008040 CH 4 21 TOD 12:03:12
PROGRESS: CALL IS NOT END TO END ISDN
PROGRESS: INTERWORKING WITH PRIVATE WORK

DCH 13 UIPE_IMSG CC_SETUPCOMP_IND REF 00000040 CH 4 21 TOD 12:03:12

DCH 10 UIPE_IMSG CC_DISC_IND REF 00000025 CH 1 15 TOD 12:03:22
CAUSE: #16 - NORMAL CALL CLEARING
PROGRESS: INBAND INFO OR PATTERN IS AVAIL

вот в этот момент ничего и не происходит. у вызывающего абонента
просто идут бесконечные короткие гудки.

DCH 13 UIPE_IMSG CC_DISC_IND REF 00000040 CH 4 21 TOD 12:04:46
CAUSE: #16 - NORMAL CALL CLEARING
PROGRESS: INBAND INFO OR PATTERN IS AVAIL

DCH 13 UIPE_OMSG CC_RELEASE_REQ REF 00008040 CH 4 21 TOD 12:04:50
CAUSE: #16 - NORMAL CALL CLEARING

DCH 10 UIPE_OMSG CC_RELEASE_REQ REF 00000025 CH 1 15 TOD 12:04:50
CAUSE: #16 - NORMAL CALL CLEARING

DCH 13 UIPE_IMSG CC_RELEASE_CONF REF 00000040 CH 4 21 TOD 12:04:50

DCH 10 UIPE_IMSG CC_RELEASE_CONF REF 00000025 CH 1 15 TOD 12:04:50

Народ! Где собака порылась?

а) А зачем такой транзит?

б) Поменяй таймеры на 10 д-канале.

а) В каком смысле "такой". Просто 11-ая опция используется в качестве транзитной станции...
б) Спасибо за совет. Уменьшил до нуля таймеры - всё заработало.

а) По этому поводу я достаточно подробно высказался выше. Эта станция - НЕ "транзитная" (в данном контексте). Остается только сказать спасибо Нортелю, что софт достаточно гибок, и все-таки позволяет за меньшие деньги получать больше функциональности...

б) Пожалуйста.