Добрый день всем,
у меня стоит Меридиан 11С 25 релиз подключен к городской АТС Алкатель S12 по PRI, и возникает такая проблема нехорошая переодически пропадает входящая связь,а исходящая работает нормально. Причём на моей стороне никаких ошибок не выпадает и отследить нельзя отвалился или нет. Только начинает шкалить счётчик ошибок по Д каналу выдаёт постоянно при достижении максимального значения 255, выдаёт следующее
DCH: 6 MAINT INDICATION TIME: 9:12:48
COUNTER VALUE
37 255
как я понял он считает каждую попытку внешнего звонока. Данная трабла решается только перезагрузкой модуля на стороне Алкателя, вот и вопрос: в чём может быть проблема и всё таки у кого, у них или у меня?
Буду благодарен всем кто откликнется,

С уважением
Поздеев Павел

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

Успехов

37 - count of layer 3 messages from far-end with invalid global call reference
На s12 - уровень три сообщений d-канала надо крутить для начала.

Попробуй с LPTI поиграться. Позажимай счетчики ошибок, может поможет. ИМХО проблемма с Алкателя.

---------------
Ingenear

все каналы свободны IDLE, как сделать трассировку если вызова не приходят? Как я понимаю трассировать можно только установившиеся соединения. вот кусок лога по Д каналу с момента последнего звонка до первого появления счётчика ошибок, никаких егоров вроде нету,
DCH 6 UIPE_IMSG CC_SETUP_IND REF 00001D80 CH 1 1 TOD 15:12:00
PROGRESS: CALL IS NOT END TO END ISDN
CALLING #:NO DIGIT NUM PLAN: UNKNOWN
CALLED #:8182217825 NUM PLAN: E164

DCH 6 UIPE_OMSG CC_PROCEED_REQ REF 00009D80 CH 1 1 TOD 15:12:00
DCH 6 UIPE_OMSG CC_DISC_REQ REF 00009D80 CH 1 1 TOD 15:12:00
CAUSE: #17 - USER BUSY

DCH 6 UIPE_IMSG CC_RELEASE_IND REF 00001D80 CH 1 1 TOD 15:12:00

DCH 6 UIPE_IMSG CC_SETUP_IND REF 00001000 CH 1 1 TOD 15:12:14
PROGRESS: CALL IS NOT END TO END ISDN
CALLING #:NO DIGIT NUM PLAN: UNKNOWN
CALLED #:8182217825 NUM PLAN: E164
DCH 6 UIPE_OMSG CC_PROCEED_REQ REF 00009000 CH 1 1 TOD 15:12:14

DCH 6 UIPE_OMSG CC_DISC_REQ REF 00009000 CH 1 1 TOD 15:12:14
CAUSE: #17 - USER BUSY

DCH 6 UIPE_IMSG CC_RELEASE_IND REF 00001000 CH 1 1 TOD 15:12:14

DCH 6 UIPE_OMSG CC_SETUP_REQ REF 0000001D CH 1 29 TOD 15:12:18
PROGRESS: ORIGINATING END IS NOT ISDN
CALLING #:8182217811 NUM PLAN: E164
CALLED #:654918 NUM PLAN: E164

DCH 6 UIPE_IMSG CC_PROCEED_IND REF 0000001D CH 1 29 TOD 15:12:18
PROGRESS: INBAND INFO OR PATTERN IS AVAIL

DCH 6 UIPE_IMSG CC_ALERT_IND REF 0000001D CH 1 29 TOD 15:12:20
PROGRESS: TERMINATING END IS NOT ISDN

DCH 6 UIPE_IMSG CC_SETUP_CONF REF 0000001D CH 1 29 TOD 15:12:24
PROGRESS: TERMINATING END IS NOT ISDN
CONNECT #:NO DIGIT NUM PLAN: E164
DCH 6 UIPE_OMSG CC_DISC_REQ REF 0000001E CH 1 30 TOD 15:13:36
CAUSE: #16 - NORMAL CALL CLEARING

DCH 6 UIPE_IMSG CC_RELEASE_IND REF 0000001E CH 1 30 TOD 15:13:36

AUD018 00000014 0000FFEE 0000FFFE

AUD516 00000009 1

VAS008 ADMIN VSID 9 CUST -- TIME & DATE 15:13:56 11/03/2002

AUD370 VSID 9 CUST --

DCH 6 UIPE_OMSG CC_SETUP_REQ REF 0000001E CH 1 30 TOD 15:14:04
PROGRESS: ORIGINATING END IS NOT ISDN
CALLING #:8182217856 NUM PLAN: E164
CALLED #:657765 NUM PLAN: E164

DCH 6 UIPE_IMSG CC_PROCEED_IND REF 0000001E CH 1 30 TOD 15:14:04
PROGRESS: INBAND INFO OR PATTERN IS AVAIL

VAS008 ADMIN VSID 9 CUST -- TIME & DATE 15:14:06 11/03/2002

AUD370 VSID 9 CUST --
DCH 6 UIPE_IMSG CC_PROGRESS_IND REF 0000001E CH 1 30 TOD 15:14:10
PROGRESS: CALL IS NOT END TO END ISDN

DCH 6 UIPE_IMSG CC_SETUP_CONF REF 0000001E CH 1 30 TOD 15:14:20
PROGRESS: TERMINATING END IS NOT ISDN
CONNECT #:NO DIGIT NUM PLAN: E164

DCH 6 UIPE_OMSG CC_DISC_REQ REF 0000001D CH 1 29 TOD 15:14:42
CAUSE: #16 - NORMAL CALL CLEARING

DCH 6 UIPE_IMSG CC_RELEASE_IND REF 0000001D CH 1 29 TOD 15:14:42

TIM000 15:15 11/3/2002 CPU 0

DCH 6 UIPE_IMSG CC_DISC_IND REF 0000001E CH 1 30 TOD 15:15:06
CAUSE: #16 - NORMAL CALL CLEARING
PROGRESS: INBAND INFO OR PATTERN IS AVAIL

DCH 6 UIPE_OMSG CC_RELEASE_REQ REF 0000001E CH 1 30 TOD 15:15:06
CAUSE: #16 - NORMAL CALL CLEARING

DCH 6 UIPE_IMSG CC_RELEASE_CONF REF 0000001E CH 1 30 TOD 15:15:08

DCH 6 UIPE_OMSG CC_SETUP_REQ REF 0000001E CH 1 30 TOD 15:17:02
PROGRESS: ORIGINATING END IS NOT ISDN
CALLING #:8182217812 NUM PLAN: E164
CALLED #:280130 NUM PLAN: E164

DCH 6 UIPE_IMSG CC_PROCEED_IND REF 0000001E CH 1 30 TOD 15:17:02
PROGRESS: INBAND INFO OR PATTERN IS AVAIL

DCH 6 UIPE_IMSG CC_ALERT_IND REF 0000001E CH 1 30 TOD 15:17:02
PROGRESS: TERMINATING END IS NOT ISDN
PROGRESS: INBAND INFO OR PATTERN IS AVAIL
DCH 6 UIPE_OMSG CC_DISC_REQ REF 0000001E CH 1 30 TOD 15:17:44
CAUSE: #16 - NORMAL CALL CLEARING

DCH 6 UIPE_IMSG CC_RELEASE_IND REF 0000001E CH 1 30 TOD 15:17:44

DCH: 6 MAINT INDICATION TIME: 15:21:20
COUNTER VALUE
37 255

В данном случае, входящая связь может пропадать из-за изменения маршрутизации на S12 по какой-либо причине. Надо бы узнать, что происходит со звонками после появления проблемы? Пусть трассировку сделают. И можно ли принудительно в обход маршрутизации позвонить через этот поток? Может на потоке какие ошибки появляются?

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

С уважением

;Recorded script. Editing may be required.
proc main
nachalo:
waitfor "REQ "
transmit "chg^M"
waitfor "TYPE "
transmit "pri2^M"
waitfor "FEAT "
transmit "lpti^M"
waitfor "LOOP "
; transmit "26^M"
waitfor "MFF "
transmit "aff^M"
waitfor "ALRM "
transmit "reg^M"
waitfor "G1OS "
transmit "yes^M"
waitfor "SLP "
transmit "255 1s 255 1s^M"
waitfor "BPV "
transmit "255 255^M"
waitfor "CRC "
transmit "255 255^M"
waitfor "FAP "
transmit "255 255^M"
waitfor "RATS "
transmit "10^M"
waitfor "GP2 "
transmit "255 1s 1s 1s 1s^M"
waitfor "MNG1 "
transmit "10s^M"
waitfor "NCG1 "
transmit "10s^M"
waitfor "OSG1 "
transmit "10s^M"
waitfor "MNG2 "
transmit "10s^M"
waitfor "NCG2 "
transmit "10s^M"
waitfor "OSG2 "
transmit "10s^M"
waitfor "PERS "
transmit "50^M"
waitfor "CLRS "
transmit "50^M"
waitfor "OOSC "
transmit "127^M"
goto nachalo
endproc

---------------
Ingenear

прописал, буду смотреть что будет дальше,
глюк всплывает с периодичностью от 1 до 10 дней,

С уважением
Павел Поздеев

---------------
Ingenear

Ну конечно, ошибок у них нет, кроме одной, которая называется Алкатель. :)

...Я,конечно,не спец по Меринам ( вмешиваюсь только потому,что дело касается S12), но меня смущают некоторые вещи,например :
"NO DIGIT NUM PLAN: E164" - как это понимать ? Что, вы получили цифры не соответствующие рекомендациям Е.164 ( ??? !). Или как-то ещё можно это интерпретировать ? Чушь какая-то !
Далее: " CAUSE: #16 - NORMAL CALL CLEARING ". Иными словами,Ваша РАВХина отрабатывает CAUSE нормально (???!).Но с другой стороны : "CALLING #:8182217812 NUM PLAN: E164 ", то бишь "попадаются,всё таки " "каледы",соответствующие Е.164 ? Насчёт алармов : так их здесь быть и не дОлжно! С какой такой радости ? Поток есть ? Есть... Мультифрэйм есть ? Как я понял - есть ! RJA ( авария удалённого конца,т.е.Вас ) есть? Нет ! Так чегой же лапшу на уши весить! Между нами (" девочками говоря") я бы на " алке" посмотрел данные взаимодействия устройств и то, как описана РАВХина...Всяко может быть в нашей жизни...Может РАВХ " криво " описана,
может в DID ( есть и в "алке" такое) какая-нибудь "кривая подмена" происходит.... Самое главное - это содрать с S12ой трассировку в момент такого события ( чего-чего, а уж по части трассировок у " алки" конкурентов мало : заявляю ответственно,так как и наши "меринщики" практически всегда ими пользуются) и посмотреть,а что-же в SETUPе они Вам дают ?Не верьте ушам - верьте глазам ( мой девиз:=) ). Тогда все проблемы отпадут.
А с " Санычем" я глубоко не согласен ( может,честь мундира ? :=) ) :с таким же успехом я могу сказать - " Какой то там " Мерин ", тем более австрийский (??? - по крайней мере, так у меня записано : нам тоже приходится иметь паспорта на УПАТСы к нам включённые), полностью не до конца поддерживающий EDSS1 ( видимо,германское влияние) ,есть ошибка природы. ...
Без обид,да ?
P.S. : ...А по-поводу моего последнего утверждения - можете попросить у своих " алковцев " т.н. 48-е аномальные рапорта ( 313-е ошибки), расшифровать их, взять ITUтешние рекомендации и почитать........ Улыбаться потом будете :=)

Может ентому алку ETSI не нравится, попробовать CNTY - FRA поставить, или какие другие национальные особенности?
"NO DIGIT NUM PLAN: E164" - это сообщение от s12 пришло.
Также не являясь спецом по алкам, имел ****а с ними много больше чем с другими станциями (EWSD, DX, AXE...). А может инженеры такие попадались. Кстати и к мерин в последнее время все меньше нравится. :) Имею право на личное субъективное мнение! :)

Давая вопрос на форум как раз и хотелось причину решить, а не обсуждать какая станция хуже,а какая лучше, спасибо всем кто откликнулся.
сообщение CALLING #:NO DIGIT NUM PLAN: UNKNOWN приходит с S12, когда они немогут передать мне номер звонящего, транзит с какой-нибудь станции,
и в принципе ничего страшного. Ваше послание я тем ребятам отправлю. Как они мне сказали, они запрограммили макросом от Алкателя стандартный евроISDN PRI, больше тонкостей я с них не добился.(Может знаете какой он у Алкателя стандартный) (мне знакомый прислал с такой же станции которая с S12 работатет и без всяких глюков) При зависании милый женский голос сообщает страждущему попасть к нам в контору абонету " Абонент временно не может быть вызван", но пока отработали пару дней без этих глюков, посмотрим что будет далее. Хотя бывает и неделю держится, а потом опять слетает.

С уважением
Поздеев Павел