Блокируются периодически транки и потом сами разблокируются через некоторое время. Вот что в этот момент происходит в потоке:

DCH 5 UIPE_OMSG CC_SETUP_REQ REF 00000003 CH 5 3 TOD 11:34:06
PROGRESS: CALL IS NOT END TO END ISDN
PROGRESS: INTERWORKING WITH PRIVATE WORK
CALLED #:6806 NUM PLAN: E164

DCH 5 UIPE_IMSG CC_REJECT_IND REF 00000003 CH 5 3 TOD 11:34:06
CAUSE: #44 - REQ CIRC/CHAN NOT AVAILABLE

ERR9032 5 3 11:34:06 7/05/2003

И вот что сразу пишет после этого.
Происходит тоже соединение в тоже время (секунда в секунду) по другому транку но уже удачное:

DCH 5 UIPE_OMSG CC_SETUP_REQ REF 0000001D CH 5 2 TOD 11:34:06
PROGRESS: CALL IS NOT END TO END ISDN
PROGRESS: INTERWORKING WITH PRIVATE WORK
CALLED #:6806 NUM PLAN: E164

DCH 5 UIPE_IMSG CC_PROCEED_IND REF 0000001D CH 5 2 TOD 11:34:06

DCH 5 UIPE_IMSG CC_ALERT_IND REF 0000001D CH 5 2 TOD 11:34:08

DCH 5 UIPE_IMSG CC_SETUP_CONF REF 0000001D CH 5 2 TOD 11:34:12

Сигнализация EuroISDN, на другом конце стоит M6501 (Mercator 01L). Подключено все это через Комкор, от точки присутствия Комкора до Меркатора по модемам xDSL.
Это проблема с настройками или может быть проблема с физикой, например с xDSL модемом, кто ни будь встречался с таким?

С уважением,
Андрей.
<P ID="edit"><FONT SIZE=1><EM>Отредактировано Ocean 07.05.2003 12:02 (время сервера).</EM></FONT></P>

Меридиан делает попытку занять вызовом канал.
Дальняя сторона сообщает, что данный канал - не в свободном состоянии и проключение по нему - невозможно.
Меридиан отмечает этот канал со своей стороны, как тот, который занимать не надо. Метка очищается аудитом транков или при поступлении запроса на занятие данного канала с дальней стороны (это значит, что ТАМ он "встал" в нормальное состояние).
Далее Меридиан пробует следующий канал маршрута.
Дальняя сторона проключает звонок.

Сценарий красивый.

Вопрос надо ставить так: почему дальняя сторона считает очевидно свободный канал занятым или выключенным или неисправным?
Для начала имеет смысл помониторить ОТБОИ звонков на этом потоке. А конкретно - интересны те звонки, которые были на проблемных каналах ПЕРЕД вышеописанным сценарием...

Спасибо, буду наблюдать что происходит на потоке.

С уважением,
Андрей.

Вот что я обнаружил:

Идет вызов со стороны Меркатора:

DCH 5 UIPE_IMSG CC_SETUP_IND REF 00002F00 CH 5 30 TOD 11:51:34
PROGRESS: ORIGINATING END IS NOT ISDN
CALLING #:6824 NUM PLAN: UNKNOWN
CALLED #:980 NUM PLAN: UNKNOWN

DCH 5 UIPE_OMSG CC_MORE_INFO_REQ REF 0000AF00 CH 5 30 TOD 11:51:34

DCH 5 UIPE_IMSG CC_INFO_IND REF 00002F00 CH 5 30 TOD 11:51:34
CALLED #:9 NUM PLAN: UNKNOWN

DCH 5 UIPE_IMSG CC_INFO_IND REF 00002F00 CH 5 30 TOD 11:51:34
CALLED #:2 NUM PLAN: UNKNOWN

DCH 5 UIPE_IMSG CC_INFO_IND REF 00002F00 CH 5 30 TOD 11:51:34
CALLED #:4 NUM PLAN: UNKNOWN

DCH 5 UIPE_IMSG CC_INFO_IND REF 00002F00 CH 5 30 TOD 11:51:34
CALLED #:5 NUM PLAN: UNKNOWN

DCH 5 UIPE_IMSG CC_INFO_IND REF 00002F00 CH 5 30 TOD 11:51:34
CALLED #:4 NUM PLAN: UNKNOWN

DCH 5 UIPE_IMSG CC_INFO_IND REF 00002F00 CH 5 30 TOD 11:51:34
CALLED #:4 NUM PLAN: UNKNOWN

DCH 5 UIPE_IMSG CC_INFO_IND REF 00002F00 CH 5 30 TOD 11:51:34
CALLED #:0 NUM PLAN: UNKNOWN

DCH 5 UIPE_IMSG CC_INFO_IND REF 00002F00 CH 5 30 TOD 11:51:34
CALLED #:3 NUM PLAN: UNKNOWN

DCH 5 UIPE_IMSG CC_INFO_IND REF 00002F00 CH 5 30 TOD 11:51:34
CALLED #:0 NUM PLAN: UNKNOWN

DCH 5 UIPE_IMSG CC_INFO_IND REF 00002F00 CH 5 30 TOD 11:51:36
CALLED #:&lt; NUM PLAN: UNKNOWN

DCH 5 UIPE_OMSG CC_PROCEED_REQ REF 0000AF00 CH 5 30 TOD 11:51:36

DCH 5 UIPE_OMSG CC_PROGRESS_REQ REF 0000AF00 CH 5 30 TOD 11:51:36
PROGRESS: INBAND INFO OR PATTERN IS AVAIL
PROGRESS: INTERWORKING WITH PRIVATE WORK

DCH 5 UIPE_OMSG CC_PROGRESS_REQ REF 0000AF00 CH 5 30 TOD 11:51:40
CAUSE: #17 - USER BUSY
PROGRESS: INBAND INFO OR PATTERN IS AVAIL
PROGRESS: INTERWORKING WITH PRIVATE WORK

DCH 5 UIPE_IMSG CC_RELEASE_IND REF 00002F00 CH 5 30 TOD 11:51:40
CAUSE: #17 - USER BUSY

Абонент занят.

DCH 5 UIPE_OMSG CC_SETUP_REQ REF 0000001E CH 5 30 TOD 11:51:40
PROGRESS: CALL IS NOT END TO END ISDN
PROGRESS: INTERWORKING WITH PRIVATE WORK
CALLED #:6821 NUM PLAN: E164

И сразу же в эту секунду идет вызов в сторону Меркатора и транк блокируется.
Может в Меркаторе этот транк не успевает установиться в IDLE, после последнего исходящего по нему вызова?

DCH 5 UIPE_IMSG CC_REJECT_IND REF 0000001E CH 5 30 TOD 11:51:40
CAUSE: #44 - REQ CIRC/CHAN NOT AVAILABLE

ERR9032 5 30 11:51:40 7/05/2003

DCH 5 UIPE_OMSG CC_SETUP_REQ REF 0000001D CH 5 29 TOD 11:51:40
PROGRESS: CALL IS NOT END TO END ISDN
PROGRESS: INTERWORKING WITH PRIVATE WORK
CALLED #:6821 NUM PLAN: E164

DCH 5 UIPE_IMSG CC_PROCEED_IND REF 0000001D CH 5 29 TOD 11:51:40

DCH 5 UIPE_IMSG CC_ALERT_IND REF 0000001D CH 5 29 TOD 11:51:42

DCH 5 UIPE_IMSG CC_SETUP_CONF REF 0000001D CH 5 29 TOD 11:51:48


С уважением,
Андрей.

В 5-ом Д-канале CNTY стоит ETSI ?

Стоит, может D-Ch заново создать, и ETSI принудительно прописать? Слышал была проблема.

С уважением,
Андрей.<P ID="edit"><FONT SIZE=1><EM>Отредактировано Ocean 07.05.2003 14:21 (время сервера).</EM></FONT></P>

Вот и я о том же.
Поиском набери "12272" и найдешь пару прошлогодних веток, где я эту тему подробно раскрывал.

Спасибо!
Так оно наверно и есть, вечером переделаю что бы клиентов не валить.

С уважением,
Андрей.

Походу так оно и есть, создал заново D-Ch указал ETSI принудительно и за целый день ни одного err9032, спасибо за наводку!

С уважением,
Андрей.