Здравствуйте.
У меня возникла такая проблема.
Есть 2 станции соединенные друг с другом по SL-1. Одна из них соединена по EuroISDN с городом. Любые звонки в том числе и междугородние с той что напрямую с городом проходят нормально. А вот с другой, если набираешь по межгороду обычно тоже нормально, но не всегда. Иногда (как я понял когда звонок идет через транзитную координатку и она долго набирает его) примерно через 8-10 секунд станция выдает overflow tone.
Я думаю что дело в таймерах SL-1. В принципе "подозреваемых" не так много и можно опытами проверить какой нужно увеличить но придется отключать D канал а это нежелательно.
Не подскажете в чем тут загвоздка?
Спасибо.

Таймеры Д-канала здесь не виноваты.
И выключать D-ch не надо.

Дело в том, что эти таймеры у MCDN и EURO ничем не отличаются. И то, что при звонке MCDN-EURO к времени соединения добавляются десятые доли секунды - совершенно неважно.

Вообще, все решения подобных проблем следует начинать с МОНИТОРИНГА.
Следует убедиться, что:
- звонок вообще инициируется (т.е. setup в MCDN идет);
- сетап правильный;
- дисконнект присылает станция оригинатора (а не транзитный Меридиан или город);
- коз дисконнекта действительно связан с таймерами.

Вполне может быть, что просто абоненты набирают неполный номер. Ибо 8 секунд похоже на простой interdigit timer.

Здравствуйте.

>Дело в том, что эти таймеры у MCDN и EURO ничем не отличаются.
>И то, что при звонке MCDN-EURO к времени соединения добавляются
>десятые доли секунды - совершенно неважно.
Я думаю что может быть Euro не передает MCDN каких-то данных не дождавшись которых 61-ая станция (та что не напрямую) производит дисконект.


>Вообще, все решения подобных проблем следует начинать с МОНИТОРИНГА.
Я знаю только 2 способа мониторинга в LD 60 могу посмотреть занят или нет канал в PRI и в LD 80 могу проверить состояние канала по TRAD или TN по TRAC.
Если есть другие способы мониторинга PRI - подскажите?

>Вполне может быть, что просто абоненты набирают неполный номер.
>Ибо 8 секунд похоже на простой interdigit timer.
Я лично набирал с обоих станций. И потом пользовался REDIAL клавишей так что не думаю...

Там где на всем пути стоят только электронные станции соединение практически мгновенное. А там где не проходит звонок надо ждать для соединения 12-14 секунд.

Вот так выглядят распечатки звонка который не проходит:
.TRAD 24 1

ACTIVE TN 024 01
ORIG 004 0 05 09 MARP 0 3406 500
TERM 024 01 TIE RMBR 21 1
DIAL DN 8683846622907
MAIN_PM DIAL AUX_PM COMPLETE
TALKSLOT ORIG 8 TERM 8
QUEU NONE

AUX NARS



---- ISDN PRA CALL (TERM) ----
CALL REF # = 1
BEARER CAP = VOICE
CALL STATE = 9 INCOMING
CALLING NO = 1003406
CALLED NO = 8683846622907


И на транзитной станции:
.TRAD 2 1

ACTIVE TN 002 01
ORIG 001 01 TIE RMBR 9 1
TERM 002 01 TIE RMBR 21 1
DIAL DN 83846622907
MAIN_PM DIAL AUX_PM COMPLETE
TALKSLOT ORIG 8 TERM 8
EES_DATA:
NONE
QUEU NONE
CALL ID 103 75

AUX NARS

---- ISDN PRA CALL (ORIG) ----
CALL REF # = 1
BEARER CAP = VOICE
HLC =
CALL STATE = 9 INCOMING
CALLING NO = 1003406
CALLED NO = 8683846622907

---- ISDN PRA CALL (TERM) ----
CALL REF # = 17949
BEARER CAP = VOICE
HLC =
CALL STATE = 3 OUTGOING
CALLING NO = 1003406
CALLED NO = 83846622907

И после overflow tone
.TRAD 2 1

IDLE TN 002 01

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

А вот с выяснения доступных средств мониторинга, необходимо начинать эксплуатацию любой АТС.

Рекомендую пройтись поиском по доке, набрав "monitoring".
Можно еще напрячь аналитический аппарат и вспомнить, что maintanance Д-каналов осуществляется в LD 96. И, открыв книжку на нужной странице, хотя бы прочитать промты, доступные из этого оверлея.

Обсуждать предположения о проблемах с сигнализацией, не имея достаточно точных данных непосредственно о сигналах, можно практически бесконечно...

Спасибо за совет
Нашел в LD 96 команду ENL MSGO x
вот что с ее помошью удалось выяснить:
Непрошедший звонок на промежуточной станции:
CH 22 UIPE_OMSG CC_SETUP_REQ REF 000002B8 CH 2 1 TOD 9:46:34
PROGRESS: ORIGINATING END IS NOT ISDN
PROGRESS: INTERWORKING WITH PRIVATE WORK
CALLING #:1003406 NUM PLAN: E164
CALLED #:83846622907 NUM PLAN: E164

DCH 22 UIPE_OMSG CC_DISC_REQ REF 000002B8 CH 2 1 TOD 9:46:44
CAUSE: #102 - RECOVERY ON TIMER EXPIRY

DCH 22 UIPE_OMSG CC_RELEASE_RESP REF 000002B8 CH 2 1 TOD 9:46:44

При мониторинге на первой станции (той которая не напрямую с городом) результат похожий.
При поиске в документации по слову EXPIRY нашел
- - NT2 1- (26)-100 Post retransmission acknowledgment delay.
в LD74 но при попытке войти в нее выдает DSC0000 и выбрасывает обратно...

А команду
enl msgi
ты не заметил???
Мда-а-а...

Если после исходящего setup'а сразу не приходит например proceed, то проблему можно смело выкатывать дальней стороне.
Ибо, когда на свой запрос исходящего соединения по PRI, станция не получает НИКАКОЙ реакции от дальнего конца, то она вправе решить, что D-канал на той стороне потока - неисправен.
Иными словами, дальний конец потока обязан очень быстро (значительно быстрее 10 секунд) подтвердить ПОЛУЧЕНИЕ данных по установлению соединения. А вот непосредственно ПРОКЛЮЧЕНИЕ вызова может происходить значительно дольше.

Итак, необходимо отмониторить наличие ВХХОДЯЩИХ сообщений по Д-каналу.
А не только исходящих...

>А команду enl msgi ты не заметил???
>Мда-а-а...

enl msgi видел но подумал что оно распечатывает входящие звонки.
У меня нет ни специального связисткого образования ни образования по Meridian-у (кроме начальных недельных курсов).
И со станцией я работаю чуть больше года, читаю документацию и делаю все что могу.

Так выглядит мониторинг D-канала на основной станции:
DCH 9 O MSG SETUP REF 000001 CH Ђ24 1 TOD 13:39:36
FEAT :NAS
PROGRESS: ORIG ADDR IS NOT ISDN
CALLING #:1003406 NUM PLAN: PRIVATE
CALLED #:8683846622907 NUM PLAN: PRIVATE

DCH 9 IMSG CALLPROC REF 000001 CH 24 1 TOD 13:39:36

DCH 9 OMSG RELEASE REF 000001 CH 24 1 TOD 13:39:46
CAUSE :RECOVERY ON TIMER EXPIRY

DCH 9 IMSG REL COMP REF 000001 CH 24 1 TOD 13:39:46

Так выглядит звонок на промежуточной станции:
DCH 22 UIPE_OMSG CC_SETUP_REQ REF 000003AA CH 2 1 TOD 14:27:40
PROGRESS: ORIGINATING END IS NOT ISDN
PROGRESS: INTERWORKING WITH PRIVATE WORK
CALLING #:1003406 NUM PLAN: E164
CALLED #:83846622907 NUM PLAN: E164

DCH 22 UIPE_IMSG CC_PROCEED_IND REF 000003AA CH 2 1 TOD 14:27:40

DCH 22 UIPE_OMSG CC_DISC_REQ REF 000003AA CH 2 1 TOD 14:27:50
CAUSE: #102 - RECOVERY ON TIMER EXPIRY

DCH 22 UIPE_IMSG CC_RELEASE_IND REF 000003AA CH 2 1 TOD 14:27:50

DCH 22 UIPE_OMSG CC_RELEASE_RESP REF 000003AA CH 2 1 TOD 14:27:50

а) Проблема в переводе, а не в понимании и специальных знаниях.
Согласись: слова message и call имеют несколько разные значения.
б) Теперь интересно промониторить успешный звонок. Основываясь на разнице, можно будет принять решение о мерах.

>а) Проблема в переводе, а не в понимании и специальных знаниях.
>Согласись: слова message и call имеют несколько разные значения.
Согласен

>б) Теперь интересно промониторить успешный звонок. Основываясь на разнице, можно будет принять >решение о мерах.

Так выглядит мониторинг D-канала на основной станции при нормально прошедшем звонке
Я слышал КПВ, трубка на том конце не была поднята, я сам отбился

DCH 9 OMSG SETUP ЂREF 000001 CH 24 1 TOD 15:55:28
FEAT :NAS
PROGRESS: ORIG ADDR IS NOT ISDN
CALLING #:1003406 NUM PLAN: PRIVATE
CALLED #:8683842289016 NUM PLAN: PRIVATE

DCH 9 IMSG CALLPROC REF 000001 CH 24 1 TOD 15:55:28

DCH 9 IMSG ALERT REF 000001 CH 24 1 TOD 15:55:30
ЂPROGRESS: CALL IS NOT END TO END ISDN

DCH 9 OЂMSG DISC REF 000001 CH 24 1 TOD 15:55:52
CAUSE :NORMAL CALL CLEARING

DCH 9 IЂMSG RELEASE REF 000001 CH 24 1 TOD 15:55:52

DCH 9 OЂMSG REL COMP REF 000001 CH 24 1 TOD 15:55:52

Так выглядит звонок на промежуточной станции:
DCH 22 UIPE_OMSG CC_SETUP_REQ REF 00000438 CH 2 1 TOD 15:33:06
PROGRESS: ORIGINATING END IS NOT ISDN
PROGRESS: INTERWORKING WITH PRIVATE WORK
CALLING #:1003406 NUM PLAN: E164
CALLED #:83842289016 NUM PLAN: E164

DCH 22 UIPE_IMSG CC_PROCEED_IND REF 00000438 CH 2 1 TOD 15:33:06

DCH 22 UIPE_IMSG CC_ALERT_IND REF 00000438 CH 2 1 TOD 15:33:08
PROGRESS: CALL IS NOT END TO END ISDN

DCH 22 UIPE_OMSG CC_DISC_REQ REF 00000438 CH 2 1 TOD 15:33:22
CAUSE: #16 - NORMAL CALL CLEARING

DCH 22 UIPE_IMSG CC_RELEASE_IND REF 00000438 CH 2 1 TOD 15:33:22
DCH 22 UIPE_OMSG CC_RELEASE_RESP REF 00000438 CH 2 1 TOD 15:33:22

Итак, разница очевидна.
Во втором случае: через две секунды после PROCEED от оператора приходит ALERT.
В первом случае: ничего не приходит в течение 10 секунд.

Вариантов решения проблемы два:
- увеличить на Меридиановских Д-каналах таймер Т203;
- обратится к оператору.

Вариант первый может и не помочь.
Таймер Т203 определяет время между сигналами на Д-канале в процессе обработки вызова.
Он варьируется от 0 до 40 секунд. По умолчанию определено - 10 секунд. Нет никакой гарантии, что оператор, не присылая ничего за 10 секунд, пришлет что-нибудь за 40.

Теперь - о теории. Сигнализации Q931 создавались с учетом неоднородности ТФ сетей мира. В связи с этим, они черезвычайно гибки в интересах транзитных соединений с прочими сигнализациями.

На запрос соединения (SETUP) дальний конец обязан отреагировать достаточно быстро, чтобы станция-инициатор поняла, что с другой стороны потока кто-то есть. Но, в случае транзита на устаревшие сигнализации, дальний конец мгновенно установить соединение не сможет. Выход прост: приняв SETUP, станция сообщает о том, что она жива, сигналом PROCEED. Упрощенно говоря: она приступает к обработке вызова. Т.е. - запрос принят и начат процесс анализа полученной информации. Только потом будет отправлен сигнал о состоянии соединения. И он будет означать, что звонок обработан и скоммутирован или отбит. При транзитах на не-PRI-сигнализации, инициатору может быть отправлен сигнал PROGRESS, сообщающий о ПРОКЛЮЧЕНИИ звонка. Т.е. - о том, что процесс коммутации выполнен и звонок ушел в третью станцию. Может сразу придти ALERT, говорящий о том, что коммутация выполнена, ожидается поднятие трубки. По этим сигналам Т203 таймер выключается, ибо станции-инициатору ясно, что АТС на дальнем конце работает и не зависла в процессе выполнения задачи. В зависимости от полученного сигнала о состоянии соединения, включаются другие таймеры.
Если бы их небыло, то при любом сбое в обмене, каналы в потоке зависали бы навсегда.

По этому, имеет смысл сдать проблему оператору.
Они не должны оставлять после PROCEED такую гигантскую паузу. Ведь за 10 секунд можно запросто обработать миллионы бит. Как только в их станции звонок скоммутирован на какой-либо канал - они должны сообщать об этом. Цифровая АТС анализирует адрес, тип звонка, АОН, маршрутизацию на несколько порядков быстрее 10 секунд.

Хотя можно начать с увеличения таймера. Это поможет, если хоть какой-либо сигнал придет от оператора быстрее 40 секунд.

Здравствуйте. Большое спасибо за советы. Изменил T203 на всех 3 PRI но не помогло.
Кроме того есть еще одна мелочь, как я говорил если позвонить не с основной а прямо с промежуточной станции на номер который с основной недоступен то можно спокойно дозвонится а T203 на промежуточной стоит = 10 (стоял точнее)

И вот распечатка D-канала в этом случае:
DCH 22 UIPE_OMSG CC_SETUP_REQ REF 0000052D CH 2 30 TOD 9:21:20
PROGRESS: ORIGINATING END IS NOT ISDN
CALLING #:3900 NUM PLAN: E164
CALLED #:83846622907 NUM PLAN: E164

DCH 22 UIPE_IMSG CC_PROCEED_IND REF 0000052D CH 2 30 TOD 9:21:20

DCH 22 UIPE_IMSG CC_ALERT_IND REF 0000052D CH 2 30 TOD 9:21:34
PROGRESS: CALL IS NOT END TO END ISDN

DCH 22 UIPE_IMSG CC_SETUP_CONF REF 0000052D CH 2 30 TOD 9:21:44
PROGRESS: CALL IS NOT END TO END ISDN

DCH 22 UIPE_OMSG CC_DISC_REQ REF 0000052D CH 2 30 TOD 9:21:54
CAUSE: #16 - NORMAL CALL CLEARING

DCH 22 UIPE_IMSG CC_RELEASE_IND REF 0000052D CH 2 30 TOD 9:21:54

DCH 22 UIPE_OMSG CC_RELEASE_RESP REF 0000052D CH 2 30 TOD 9:21:54

Как я понимаю ALERT пришел через 14 секунд после PROCEED
Так что может быть в этом случае T203 не имеет отношения к проблеме?

На EURO работает другой таймер - T310.
Он больше.

А Т203 на MCDNах не помог...

Попробуй в EURO маршруте поставить PROG MALE.

Сначало перепутал и поставил MALE на D-канал в LD 17.
Потом нашел в LD 16 PROG но не могу поставить так как при попытке изменить роут даже при выключеном D-канале станция выдает:
DTRK YES
BRIP NO
DGTP PRI2
ISDN YES
одним блоком а PROG идет кажется после DTRK.
Уничтожал и создавал роут все равно после DTRK= YES сразу выдало BRIP

А запросы OVLR OVLS не могут никак влиять? У меня они стоят в YES хотя по умолчанию должны быть в NO
Ну чтоже буду звонить на городскую станцию может быть там помогут, будут присылать правильный сигнал.

Кажется - не верно.
PROG идет после IFC,CNTY... Короче - RTFM.

Набор (т.е. адрес абонента Б) может передаваться по Д-каналу двумя способами:
- единым блоком (все цифры сразу);
- по одной цифре.
Второй случай называется overlap.
Работа оверлапом увеличивает, естественно, нагрузку на Д-канал. Однако, фактически, все "старые" сигнализации (все DTI, например) работали оверлапом. И до сих пор есть АТС, которые не могут формировать набор блоком.
Меридиан к таковым не относится.

Исходя из мониторинга исходящих звонков нетрудно заметить, что в EURO набор успешно уходит блоком. Это говорит о том, что:
- станция оператора легко воспринимает блок;
- в Меридиане оверлап настроен не до конца.
Посему: OVLS смело можно ставить NO.

Если отмониторить входящие звонки, то станет понятно как наборы отправляет оператор.
Если набор приходит блоком, то можно поставить и OVLR NO тоже. Правда, есть тонкости, которые играют роль, если EURO транки - DID и оператор присылает больше цифр, чем запрограммировано в LDN0. Тем более, что со стороны оператора может "вдруг" пойти оверлап. А при OVLR YES Меридиан спокойно принимает и блок и оверлап тоже.

MEM AVAIL: (U/P): 1216580 USED U P: 115106 60953 TOT: 1392639
DISK RECS AVAIL: 472
RAN RTE AVAIL: 500 USED: 0 TOT: 500
REQ PRT
REQ NEW
TYPE RDB
CUST 0
DMOD
ROUT 21
DES BAR_2
TKTP TIE
ESN
CNVT
SAT
RCLS
DTRK YES
BRIP
DGTP PRI2
ISDN YES
MODE PRA
IFC EURO
CNTY ETSI
SBN
CTYP
INAC
CPFXS
DAPC
INTC
DSEL
PTYP
AUTO NO
DNIS
ICOG IAO
SRCH
TRMB
STEP
ACOD 7700
TCPP
TARG
BILN
SGRP
OABS
INST
IDC
ANTK
SIGO STD
ICIS
OGIS
CNTL
DRNG
CDR
NATL NO
TDG 8
SSL
CFWR
IDOP
MUS
PANS
FRL
TTBL
OPR
ALRM
PECL
DCTI
ANIE
CAC_CIS
Вот так я забивал роут

По документации:
- PROG a...a Progress signal (a...a = NCHG, MALE, or MCON)
Как я понимаю знак "-" означает что этот запрос появляется только если ответить YES на DTRK

Если OVLS не влияет на эту ситуацию то и бог с ним.
Связался с оператором городской АТС.

Еще, не подскажете где можно почитать спецификацию по EuroISDN? Хотя бы на английском. Хоть буду знать с чем работаю...:)

а) Ну да, конечно:
TKTP TIE и EURO, ETSI, MALE...
RTFM!!! Надо находить поиском в доке фичу и ПОЛНОСТЬЮ читать, как она программится.

б) На эту ситуацию - не влияет, но - запрограммировано не верно. Ибо не полностью. Реально идет блок.

в) Это правильно. Progress indicator все-же нужен.

г) Имеет смыл начать поиск с Интернета.
Поисковик - фраза - получение и обработка информации. Первые же ссылки по поиску "спецификация Euro ISDN" дают приличное количество интересной информации...

Ничего не понимаю!
Нашел EuroISDN Continuation в X11 Networking Features and services
Сделал по кальке с инструкции(правда там не TIE а DID роут ну для проверки сойдет)
Там черным по белому написано что PROG должен идти после CNTY CLID однако
REQ new
TYPE rdb
CUST 0
DMOD
ROUT 21
DES BAR_2
TKTP DID
SAT
RCLS
DTRK YES
DGTP PRI2
ISDN YES
MODE PRA
IFC EURO
CNTY ETSI
SBN
CPFXS
DAPC
INTC
DSEL
..........ничего не понимаю...
Контакты с оператором продолжаются, они протрасировали D канал и сказали то что я уже и так знал то что через ~9 сек после SETUP наша станция присылает им DISCONNECT. На мои попытки намекнуть что должны быть какието промежуточные сигналы они меня послали к таймеру:). Мол типа надо его найти увеличить и все будет ОК. Ну чтож буду искать и если не найду то буду его еще в понедельник доставать:)
Интересно, чем DID отличается от TIE... Оба вроде работают... (С PRI)

Прогресс налицо :-)))
а) Фича появилась не так давно. Возможно у тебя старый софт. Пакеты, надеюсь, ты сверил (см. Feature Packaging)?
б) Намекать не надо. Надо объяснять все как есть. Более того: они должны были сталкиваться с похожими проблемами при включении в свою сеть Цисок и Панасов. Оборудования, которое очень ждет progress indicator - достаточно много.
в) Вопрос неоднократно задавался в этой конфе. Имеет смысл воспользоваться поиском.

>а) Фича появилась не так давно. Возможно у тебя старый софт. Пакеты, надеюсь, ты сверил (см. Feature Packaging)?
Ну да сверил. (после того как Вы подсказали :-)
у меня нет:
Enhanced DPNSS1 Gateway (DPNSS189I) package 284.
Basic Alternate Route Selection (BARS) package 57;
Нужны они или нет бог его знает....
На промежуточной 25.15 11С на основной 18 - 61 опция.
>б) Намекать не надо. Надо объяснять все как есть. Более того: они должны были сталкиваться с похожими проблемами при включении в свою сеть Цисок и Панасов. Оборудования, которое очень ждет progress indicator - достаточно много.
Конечно не надо но:
1)Они могут просто не знать про все возможности своей собственной станции просто напросто.
2) Не хотеть заморачиватся с проблемой в надежде что я найду сам решение.
И еще я нашел в LD 15 строки
ACCD OVF OVF OVF BSY
CTVN OVF OVF OVF BSY
MBNR OVF OVF OVF BSY
CTRC OVF NAP OVF NAP
...
они никак не могут иметь отношение к этой проблеме?... 3-я колонка и не стоит ли поставить туда NAP...

привет.
Почитал я дискуссию несколько раз и появилась мысля. Как я заметил меридиан сам разваливает соединение. И еще - в незаконченных вызовах на город передается 10 цифр - как положено, а в законченных 12 цифр???. Может со второй станции не приходят все цифры и номер получаестя не законченный. Отсюда и отбой по времени.

Мысля появилась после прочтения моего первого поста: "...Вполне может быть, что просто абоненты набирают неполный номер. Ибо 8 секунд похоже на простой interdigit timer..." ?

И самое главное: со счетом плоховато...

Сравниваем:
"...мониторинг D-канала на основной станции:...
CALLED #:8683846622907 NUM PLAN: PRIVATE.."
и
"...при нормально прошедшем звонке...
CALLED #:8683842289016 NUM PLAN: PRIVATE...".


Хорошая мысля приходит опосля... (с) не мой :-)))))

Это вряд ли :)))

Вряд ли что?
Мысля появилась?
Или со счетом?

Karter!
Прокоментируйте если не сложно ситуацию:

После смены Т203 с 10 до 30 секунд я ничего не делал в смысле не перезагружал ни станцию ни Д-канал. Но вот по случаю выключил Д-канал, выключил плату DCHI вытащил ее опять вставил и включил. Через некоторое время проверил дозвон - все работает(УРА!!! :)).
Не будучи до конца уверен в результате чего это случилось я решил промониторить Д канал и вот результат:

Д канал на транзитной станции:
DCH 22 UIPE_OMSG CC_SETUP_REQ REF 00002CB0 CH 2 30 TOD 10:16:32
PROGRESS: ORIGINATING END IS NOT ISDN
PROGRESS: INTERWORKING WITH PRIVATE WORK
CALLING #:1003406 NUM PLAN: E164
CALLED #:83846622907 NUM PLAN: E164

DCH 22 UIPE_IMSG CC_MORE_INFO_IND REF 00002CB0 CH 2 30 TOD 10:16:32

DCH 22 UIPE_IMSG CC_PROCEED_IND REF 00002CB0 CH 2 30 TOD 10:16:44
PROGRESS: CALL IS NOT END TO END ISDN

DCH 22 UIPE_IMSG CC_ALERT_IND REF 00002CB0 CH 2 30 TOD 10:16:48
PROGRESS: INBAND INFO OR PATTERN IS AVAIL
PROGRESS: CALL IS NOT END TO END ISDN

DCH 22 UIPE_IMSG CC_SETUP_CONF REF 00002CB0 CH 2 30 TOD 10:16:52
PROGRESS: CALL IS NOT END TO END ISDN

DCH 22 UIPE_OMSG CC_DISC_REQ REF 00002CB0 CH 2 30 TOD 10:16:52
CAUSE: #16 - NORMAL CALL CLEARING

DCH 22 UIPE_IMSG CC_RELEASE_IND REF 00002CB0 CH 2 30 TOD 10:16:52
DCH 22 UIPE_OMSG CC_RELEASE_RESP REF 00002CB0 CH 2 30 TOD 10:16:52

И на основной:
DCH 9 OMSG SETUP REF 00001D CH 24 29 TOD 12:13:52
FEAT :NAS
PROGRESS: ORIG ADDR IS NOT ISDN
CALLING #:1003406 NUM PLAN: PRIVATE
CALLED #:83846622907 NUM PLAN: PRIVATE

DCH 9 IMSG STP ACK REF 00001D CH 24 29 TOD 12:13:52

DCH 9 IMSG CALLPROC REF 00001D CH 24 29 TOD 12:14:04

DCH 9 IMSG PROGRESS REF 00001D CH 24 29 TOD 12:14:04
PROGRESS: CALL IS NOT END TO END ISDN

DCH 9 IMSG ALERT REF 00001D CH 24 29 TOD 12:14:06

DCH 9 OMSG DISC REF 00001D CH 24 29 TOD 12:14:12
CAUSE :NORMAL CALLЂ CLEARING

DCH 9 IЂMSG RELEASE REF 00001D CH 24 29 TOD 12:14:12
DCH 9 OЂMSG REL COMP REF 00001D CH 24 29 TOD 12:14:12

Вроде появился PROGRESS во 2й распечатке но и еще какие-то запросы:
DCH 22 UIPE_IMSG CC_MORE_INFO_IND REF 00002CB0 CH 2 30 TOD 10:16:32
в первой и
DCH 9 IMSG STP ACK REF 00001D CH 24 29 TOD 12:13:52 во второй.
Что они сообщают и зачем они вобще?

Я просто не пойму в результате чего все заработало - толи в результате моих действий по включению выключению DCHI то ли мы тут надавили на городских и они там что-то у себя сделали ...

В Д-канале 22, в промте OVLS случайно YES не появилось?

А в этом же Д-канале на транзитной станции в OVLR YES не присутствует?

В 22-м оно давно стояло и OVLR YES и OVLS YES
А я недавно поставил OVLR YES и OVLS YES на том Д канале что с транзитной на главную, раньше там стояло OVLR NO и OVLS NO. А 22-й это на город с транзитной.

Ага.

Это оно. Процедуры обработки вызова совершенно разные.
Кстати, то что 203-й заработал - абсолютно не факт.
Можешь попробовать его покрутить.

>Это оно. Процедуры обработки вызова совершенно разные.
Ээээ.... "оно" в смысле городские связисты поработали?
>Кстати, то что 203-й заработал - абсолютно не факт.
>Можешь попробовать его покрутить.
... ну во первых он уже и так 30 секунд а главное пока работает лучше имхо вобще его не трогать пусть работает! :)

Нет.
В Меридиане программные процедуры обработки вызовов при оверлап и нблок обменах - совершенно разные.

Зря.
Потому что, скорее всего, - это не он "работает".
Убедиться можно, уменьшив его до нескольких секунд.