Столкнулся с проблемкой такой.
Имеем М1 "А", М1 "В". Между ними IPtrunk 3.01.6.
На "В" есть PRI наружу.
IP TRunk свежепоставленный, стоят рядом пока. В процессе тестирования транзита с "А" в межгород через "В", МС32 (та которая в "В") уходила в ребут на некоторых звонках. Момент ребута - как правило трансфер звонка на принимающей стороне.
Закономерность следующая:
1. на том конце IVR или messaging система
2. при этом "абонент" на том конце пользуется тем же провайдером телефонии.
Примеры:
а) колцентр провайдера, тех поддержка (ребут на переходе от "рекламы" к "операту"/ ответ звонка оператором).
б) офис фирсы, ребут на момент перевода звонка на автоответчик. Питается тоже у того же оператора.
В этих случаях падает всегда.
Остальное вроде работает, много что пробовалось.

Симптомы - звонящий до позелениния слушает длинный гудок типа никто не отвечает.
С консолях на обоих М1 тишина. Ну, только потом на неотвечающую МС ругань и прочие последствия.
На МС в консоли:
ITG Exception Handler
Exception: 16
Valid Flag: 0x00000007
SA registers:
Task Name: tTSM
и еще много много дампов памяти, стеков вызова и прочее.

Мой склероз пошептывает, что что то подобное здесь пролетало,может, кто сталкивался.

Вот д-канал на "В" (номера затер буквами):
DCH 15 UIPE_OMSG CC_SETUP_REQ REF 00001252 CH 1 29 TOD 19:32:00 CK 85B4ED5B
PROGRESS: CALL IS NOT END TO END ISDN
PROGRESS: INTERWORKING WITH PRIVATE WORK
CALLING #:13526 NUM PLAN: E164 TON: UNKNOWN
CALLED #:8aaabbbcccc NUM PLAN: E164 TON: NATL

DCH 15 UIPE_IMSG CC_PROCEED_IND REF 00001252 CH 1 29 TOD 19:32:00 CK 85B4F03B

DCH 15 UIPE_IMSG CC_ALERT_IND REF 00001252 CH 1 29 TOD 19:32:02 CK 85B4F8D4
PROGRESS: INBAND INFO OR PATTERN IS AVAIL

DCH 15 UIPE_IMSG CC_SETUP_CONF REF 00001252 CH 1 29 TOD 19:32:16 CK 85B56D0A
CONNECT #:aaabbbccee NUM PLAN: E164 TON: NATL

XMI001 18 EXUT


Симтомы наводят на мысли что у МС крышку сносит от какого то сигналинка в процессе звонка.. обновление номера той строны?.. хз

Есть икеи, тьфу, идеи куда копать?
PRI в "В" уже обкатан годами, претензий такого рода не было, да и опробовалось все.

ЗЫЖ еще пробовали с "В" уходить в наружу по СО вместо PRI. Все четко, насекомых не нашлось.

Давай посмотрим конфиг vDch с обеих сторон ?

Old Chap, все что угодно :)

"В", iptrunk:
ADAN DCH 29
CTYP DCHI
CARD 02
PORT 1
DES ip
USR ISLD
ISLM 382
OTBF 32
CLOK EXT
NASA NO
IFC SL1
SIDE USR
CNEG 1
RLS ID **
RCAP ND1
MBGA NO
OVLR NO
OVLS NO
T23 20
T200 3
T203 10
N200 3
N201 260
K 7
"В", наружу:
ADAN DCH 15
CTYP MSDL
CARD 01
PORT 1
DES B
USR PRI
DCHL 1
OTBF 32
PARM RS422 DTE
DRAT 64KC
CLOK EXT
IFC EURO
CNTY ETSI
PINX_CUST 0
ISDN_MCNT 300
CLID OPT1
PROG NCHG
CO_TYPE STD
SIDE USR
CNEG 1
RLS ID **
RCAP COLP
MBGA NO
OVLR YES
DIDD 0
OVLS NO
T310 120
INC_T306 120
OUT_T306 120
T200 3
T203 10
N200 3
N201 260
K 7
"А",iptrunk
ADAN DCH 19
CTYP DCHI
CARD 03
PORT 1
DES IP
USR ISLD
ISLM 382
OTBF 32
CLOK EXT
NASA NO
IFC SL1
SIDE USR
CNEG 1
RLS ID **
RCAP ND1
MBGA NO
OVLR NO
OVLS NO
T23 20
T200 3
T203 10
N200 3
N201 260
K 7

Попробуй поменять RCAP на д-каналах IP:
- убрать ND1 (или изменить на ND2),
- добавить COLP.

И прописать реальные RLS ID встречной стороны.

Old Chap пишет
Попробуй поменять RCAP на д-каналах IP:
- убрать ND1 (или изменить на ND2),
- добавить COLP.

И прописать реальные RLS ID встречной стороны.
записал в блокнотик, попробуем, спасибище

без ND плоховато, хотся имена, но для эксперимента попробуем всяко

Софт на карточку пробовал перезаливать?

Urri пишет
Софт на карточку пробовал перезаливать?
еще нет, фирмарь только обновил
попробую :)

кажется нашлось решение, вернее патчик

MPLR20205
IPT 3.01.22 cards reboot intermittantly due to a buffer overflow in mixMalloc memory caused by EPID larger than max allowed value in ComposeNpmCallFacility

99.99999% что оно

В мемориз, так сказать. Результат испытаний будет к ночи.

на МС тоже патчи надо ставить

Испытания прошли успешно.

bad пишет
на МС тоже патчи надо ставить
это да, всяко.. первые поиски для профилактики обнаружили всего 2 патча :(