С чем обычно связана ошибка CAUSE: #102 - RECOVERY ON TIMER EXPIRY. Что она значит?
Происходит соединение и через 4 сек. отваливается с таким касом. Меридиан тут не виноват это точно. Просто интересно что значит эта ошибка?

Какой-то из T3xx кончился. Какой именно - так не скажешь, всю трассировку надо смотреть, от сетапа до дисконнекта. Ну и читать ETS 300 102-1, ибо все таймеры - там :)

Спасибо, сейчас скачаю и покапаюсь.

Доброго времени суток. В зависимости от загруженности шлюза на дальнем конце, у меня то наступает, то нет (соединение происходит нормально) CAUSE#102

из лога видно что происходит это через 4е секуды по инициативе моего М1.
-------------------------
DCH 12 UIPE_OMSG CC_SETUP_REQ REF 00004F3F CH 2 29 TOD 13:26:34 CK 9AF15764
PROGRESS: INTERWORKING WITH PRIVATE WORK
CALLING #:XXXX NUM PLAN: E164 TON: UNKNOWN
CALLED #:YYYY NUM PLAN: E164 TON: NATL

DCH 12 UIPE_IMSG CC_MORE_INFO_IND REF 00004F3F CH 2 29 TOD 13:26:34 CK 9AF15823

DCH 12 UIPE_OMSG CC_DISC_REQ REF 00004F3F CH 2 29 TOD 13:26:38 CK 9AF17E0D
CAUSE: #102 - RECOVERY ON TIMER EXPIRY


DCH 12 UIPE_IMSG CC_RELEASE_IND REF 00004F3F CH 2 29 TOD 13:26:38 CK 9AF17EC8

DCH 12 UIPE_OMSG CC_RELEASE_RESP REF 00004F3F CH 2 29 TOD 13:26:38 CK 9AF17ED1
--------------------
соединение устанавливается с телефона станции BCM50 , для которой мой Меридиан прописан как iptrunk-remote_gateway.
Подскажите плиз, Какой таймер в М1 отвечает за эти 4с ?
tnx
читаю ETS 300 102-1

Если же МЕРИДИАН успевает получить
PROGRESS: CALL IS NOT END TO END ISDN
то таймер этот насколько я понимаю отключается и соединение устанавливается успешно.

НАверное это больше проблема удаленной стороны, но
все таки хотел бы попробовать решить ее увелисением таймера у себя.
----
нужный таймер нашел в форуме. для этого PRI он
T203 : 10
те получается иницирует CAUSE: #102 - RECOVERY ON TIMER EXPIRY именно вызывающая станция, bcm50 и нужно в ней шукать аналогичный таймер?

Подскажите плиз, Какой таймер в М1 отвечает за эти 4с
Setup message timer T303.
AFAIK из оверлеев не настраивается, "зашит".

Прошу прощения, я в своем первонач сообщении отредактирвать успел уже 2 раза 8). хочу все таки разобраться по чьей инициативе cause 102 наступает

по чьей инициативе, можно однозначно определить:
OMSG - Outgoing MeSsaGe
IMSG - Incoming MeSsaGe

Интервал времени, в течении которого вызывающая сторона должна в ответ на SETUP получить от вызываемой стороны CALL_PROC или ALERT или SETUP_ACK или REL_COM , задается таймером Т303.

Если ответ не получен, вызывающая сторона посылает DISCONNECT c CAUSE: #102 - RECOVERY ON TIMER EXPIRY.

Да эт понятно что outgoing
DCH 12 UIPE_OMSG CC_DISC_REQ REF 00004F3F CH 2 29 TOD 13:26:38 CK 9AF17E0D
CAUSE: #102 - RECOVERY ON TIMER EXPIRY
вот приводит к нему. срабатывание таймера на М1 или на вызывающей строне BCM50
Лог на BCM при этом соединении заканчивается вот так:
[Trunk 4 11:45:59 < CC < CRef Origin: CRef 696 DISCONNECT Normal]
[Cause - Normal]
[Location: User]
[Coding Standard: CCITT standardized coding as described below]
[Cause Class: Normal Event]
[Cause: Normal clearing]
[05 00 80 00 10 00 ]

Спасибо PhoneMan
но чтот я такого таймера на этом PRI не вижу:

DCH: 12 LINK PARAM CONFIRM TIME: 11:56:50
MSDL : 12
PORT : 1
INTERFACE : ****(00000011 )
OPER MODE : RS422/DTE/USR/64000/EXT CLK
T200 : 3
T203 : 10
CREF LENGTH : 2
EARLY NR CHECK : NO
SHORT HDR ERR : YES
IMMEDIATE ACK : NO
MAX B-CHNL : 31
INI CLR CALL : U25 U19 U17 U15 U12 U11 U9 U6 U3 U2 U1
RLS CLR CALL : U25 U19 U17 U15 U12 U11 U9 U8 U7 U6 U4 U3 U2 U1
INI TMREXP : 64
T310 : 120
TABLE ID : 132 (ETSI)
N200 : 3
N201 : 260
K : 7
ISDN MCNT: 300

Ты ответы читаешь через один или как?


Setup message timer T303.
AFAIK из оверлеев не настраивается, "зашит".

угу пардон 8). все понял. спасибо. а какое значение у него? 4 секунды? неуниверсально как-то. низачто б на nortel не подумал.
Ну и "зашит аппаратно" - знач можно его раскопать в дебрях станционной OS наверное....

Нашел в ETS 300 102-1 , T303 = 4s
спасибо еще раз

но все таки, оказалось инициатором call clearing был bcm50
вот с транзита лог.
DCH12 - в сторону дальней стороны (вызываемого абонента)
DCH10 - в сторону bcm50 (вызывающего абонента)
---------------------------------
DCH 10 IMSG SETUP REF 00008189 CH 95 0 0 0 TOD 12:21:26
CALLING #:xxxx NUM PLAN: PRIVATE/UNKNOWN (UNKNOWN)
CALLED #:yyyy NUM PLAN: E164/NATIONAL / NPA

DCH 10 OMSG STP ACK REF 00008189 CH 95 0 0 0 TOD 12:21:26

DCH 12 UIPE_OMSG CC_SETUP_REQ REF 00005B44 CH 2 24 TOD 12:21:26 CK C3AC7D53
PROGRESS: INTERWORKING WITH PRIVATE WORK
CALLING #:xxxx NUM PLAN: E164 TON: UNKNOWN
CALLED #:yyyy NUM PLAN: E164 TON: NATL

DCH 12 UIPE_IMSG CC_MORE_INFO_IND REF 00005B44 CH 2 24 TOD 12:21:26 CK C3AC7E15

DCH 12 UIPE_IMSG CC_PROCEED_IND REF 00005B44 CH 2 24 TOD 12:21:28 CK C3AC8724

DCH 10 OMSG CALLPROC REF 00008189 CH 95 0 0 0 TOD 12:21:28

DCH 10 IMSG DISC REF 00008189 CH 95 0 0 0 TOD 12:21:30
CAUSE :RECOVERY ON TIMER EXPIRY

DCH 10 OMSG RELEASE REF 00008189 CH 95 0 0 0 TOD 12:21:30

DCH 12 UIPE_OMSG CC_DISC_REQ REF 00005B44 CH 2 24 TOD 12:21:30 CK C3ACA3EF
CAUSE: #102 - RECOVERY ON TIMER EXPIRY


DCH 10 IMSG REL COMP REF 00008189 CH 95 0 0 0 TOD 12:21:30

DCH 12 UIPE_IMSG CC_RELEASE_IND REF 00005B44 CH 2 24 TOD 12:21:30 CK C3ACA493

DCH 12 UIPE_OMSG CC_RELEASE_RESP REF 00005B44 CH 2 24 TOD 12:21:30 CK C3ACA49B
---------------------------------
те получается OMSG CALLPROC на bcm50 уходит, но не становится причиной сброса таймера T303 и звонок сбрасывется через стандартные 4 секунды.
НАсколько я облазил BCM element manager , никаких настроек этого таймера не обнаружил, да и собственно T303 это страндарт,
он и в Меридиане не настраивается как подсказали выше.
Сталкивался кто-нибудь с таким? Если моё предположение верно, то это по всей видимости, только патчем от Нортел должно лечиться?
p.s. с самой транзитной станции все звонки абсолютно нормально проходят .

T303 - это таймер не 2-го уровня(звена), а третьего.

Ещё возможно как то опщионально пыставить на встречной стороне передачу PROGRES сразу после приёма SETUP видел на некоторых станциях.

А разве вот это не аналог PROGRES?
...
DCH 10 OMSG CALLPROC REF 00008189 CH 95 0 0 0 TOD 12:21:28
...
BCM на него никак не раеагирует.