Конфигурация: Meridian 11C->Golden Line->Global One. Сигнализация R2MFC. Программирование станции не трогаем, там всё вылизано.

Проблема номер раз: постоянно лочатся DID линии. В день может отвалиться до 10 линий с сообщением TRK136. Иногда встают сами, но чаще приходится восстанавливать руками.

Проблема номер два: встроенные MFC приемники на процессорной плате не работают. Т.е. работают, но не больше минуты. После любого звонка приемник встает в disable и больше не просыпается. После 4-х звонков имеем полный затых по городу. С внешней MFC платой все работает идеально, ни одного затыка в течении 3-х месяцев.

Проблема номер три: Иногда умирают линии. По stat линия в IDLE, но реально не работает. Помогает disable-enable на оборудовании GoldenLine.

Так вот какой вопрос... Кто виноват??? Или, скажем так, кто максимально виноват? Может кто сталкивался с этими или похожими проблемами?

Конфигурация: Meridian 11C->Golden Line->Global One. Сигнализация R2MFC.
Программирование станции не трогаем, там всё вылизано.

Проблема номер раз: постоянно лочатся DID линии. В день может отвалиться до
10 линий с сообщением TRK136. Иногда встают сами, но чаще приходится
восстанавливать руками.

===Запустите тестирование нескольких линий в LD80 и постоянно звоните на них до зависания, при этом оставьте одну тестируемую линию для реальной работы.


Проблема номер два: встроенные MFC приемники на процессорной плате не
работают. Т.е. работают, но не больше минуты. После любого звонка приемник
встает в disable и больше не просыпается. После 4-х звонков имеем полный
затых по городу. С внешней MFC платой все работает идеально, ни одного
затыка в течении 3-х месяцев.
== совсем непонятно, но возможно проблема в конфигурации, опять-таки, после каких звонков она встаёт в disable?


Проблема номер три: Иногда умирают линии. По stat линия в IDLE, но реально
не работает. Помогает disable-enable на оборудовании GoldenLine.
== Аналогично - в момент умирания - LD80, и попытайтесь выйти на эту линию из города и соответственно в город, но скорее всего зависают GL.

Дмитрий.

Было нечто похожее на проблему номер раз.
А именно ситуация была такая:
Meridian - R2MFC - 5ESS(оператор 1) - СЛ(??) - (оператор 2)
Вызов из сети оператора 2 абоненту Meridian
Разговор
Абонент Meridian отбивается первым
Meridian шлёт отбой и ждет подтверждения (канал в BUSY)
Абонент сети оператора 2 не отбивается, истекает таймер DSI.
Выдаёт TRK136 (Release failure), канал переходит в LCKO.
Особенно часто к такой заморочке приводили модемные
соединения/разъединения (в Меридиане был сделан отвечающий пул).
Помогло следующее:
1) увеличили значение таймера DSI,
2) включили Tone to Last Party, до этого был выключен
Попробуй
Удачи

А какой релиз ? Блокирование MFCшных приемников, наблюдавшееся на некоторых релизах, лечилось патчем.

===Запустите тестирование нескольких линий в LD80 и =постоянно звоните на них до зависания, при этом оставьте =одну тестируемую линию для реальной работы.

Это ничего не даёт. Виснет на разных каналах, на разных звонках, независимо, кто отбивается первым и вообще без всякой системы.

Когда линия умирает - LD 80 ничего не показывает :) для него линия в IDLE.

Помогло следующее:
1) увеличили значение таймера DSI,
Попробую. На сколько увеличить?

2) включили Tone to Last Party, до этого был выключен

Сейчас TLP в таком виде:
.
TLP
XTON 159
XCAD 039
TLPT 30
.
Как я понимаю - всё включено?

релиз 23.47, патч установлен

который ?

стоят патчи:

P10064
MPLR09403
MPLR09521

Какой из них для MFC - не в курсе (где-бы прочитать?).

В момент умирания линни, зайдите в LD80, запустите трассировку, и попытайтесь занять с наружи и изнутри зависшую линию, распечатку - сюда.

> 1) увеличили значение таймера DSI,
> Попробую. На сколько увеличить?

Поэксперементируй. Попробуй поставить 1-2 минуты, для начала.

> TLPT 30
> Как я понимаю - всё включено?

Похоже на то. Его ведь слышно, когда он включен :) , и он
обычно очень похож на busy-тон.

в принципе, 09521 и 09403 оба, хотя по описанию 09403 относился к карте NT5K21. Они активны (в ld 22 видны) ?

Да, все патчи активны, в 22-м всё видно. А где описания патчей посмотреть? Или это, как всегда, секретная информация :) Вообще мы сейчас терзаем голден лайна на предмет качества каналов и прохождения сигнализации..

Да нет, почему - секретная ? Скорее, ДСП. Становитесь дистрибьютерами Нортеля - и вперед.
А по поводу качества - вообще говоря, R2 MFC можно оттрассировать на самом Меридиане, хотя, конечно, для разборок с сигнализациями лучше всего - специально обученная железка, разбирающая сигналы по винтикам и пишущая логи.

Интересно, как оттрассировать R2MFC на меридиане? через ld 80?

не только и не столько

Оно ведь тоже ДСП ... или нет?

Jet, скажи мне, плиз, зачем тему поднимать, если ничего сказать не можешь? Загадками меня кормить не надо, а если уж совсем припрет, спрошу за деньги у знающих людей. А ответы типа "не только и не столько" мне нафиг не нужны.

Я знаю - тебе лишнее. PDT-trace - так и скажите.

Что б ты фигней не страдал, а искал анализатор на попользоваться, и разобрался с провайдером - кто виноват.

Сказали. Стало легче ?

Адрес ?

desti@aha.ru :)

Jet:
А все просто: Белам - продавец, "мы знаем, что станции работают нормально у всех, разбирайтесь с провайдерами", Глобал - "мы вообще не в курсе, мы ваш сигнал пропускаем прозрачно, разбирайтесь со станцией или с глобалом", Глобал - "ничего не знаем.. мы от вас получаем сигнализацию, и на нее отвечаем корректно, разбирайтесь с гольденом или станцию проверяйте".

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

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

Уважаемый, ещё неделю назад я предложил вам оттрассировать линии - вы это сделали??? А если не сделали - то чего с умным видом занимаетесь болтологией? Трассировка в Meridiane по сути дела является небольшим анализатором и позволяет легко найти виноватого. Не ленитесь почитать документацтю по ld 80

Когда неясно, кто виноват - станция или провайдер, единственный способ выяснить что-либо - протоколирующий анализатор между ними. Потому как и продвинутые трассировки на станции могут ошибаться.
Если бы ты был в Питере - я, вероятно, мог бы подсказать - где его можно взять попользоваться, бесплатно или не очень.
В Москве - не знаю, увы. Сдана ли станция в эксплуатацию ? А то, может быть, проще и правильнее свести Белам с провайдером - пусть они между собой выясняют, где кривизна ?

Взаимно :)
ld 80 я, к несчастью, вызубрил наизусть. Но эта трассировка ничего не дает, кроме знания о том, что станция посылает сигнал на отключение канала, а в ответ иногда ничего не получает. Вот и возникает вопрос: кто виноват.. Провайдер не отдает, канал не пропускает или станция не воспринимает?
Поэтому тут ld 80 не катит, тут надо смотреть, что в канале идет.

Dimi:
Трасировка была запущена на уже висящий канал (LCKO)

.entd 1 6 0020
.gotr

.13:23:02 31/10/2000
LOCKOUT TN DTI 001 06

.13:38:22 31/10/2000
IDLE TN DTI 001 06

Вот кто может сказать, отчего он перешел в состояние IDLE?
Сам по себе, через 15 минут…

[звонки порезаны]

Теперь ситуация с локом канала.
Входящий звонок….. (отрезал все ненужные поля)

.13:40:30 31/10/2000
IDLE TN DTI 001 06

.13:41:30 31/10/2000 Подключились к станции
SENT SZAC 1101 RECV SEIZ 0001
PDCA 1 PAD 0 0 PCML A A
TERM NONE
MFC IC 010 0 00 00 SLOT 15 15
DIAL DN NONE
MAIN_PM DIAL AUX_PM
TALKSLOT NONE
QUEU DIAL

.13:41:32 31/10/2000 Набираем номер
SENT SZAC 1101 RECV SEIZ 0001
TERM NONE
DIAL DN 1015
MAIN_PM DIAL AUX_PM DNTRAN
QUEU DIAL

.13:41:34 31/10/2000 Набрали, звоним
SENT SZAC 1101 RECV SEIZ 0001
TERM 004 0 00 12 MARP 0 хххх 500
DIAL DN 1034
MAIN_PM RING AUX_PM
TALKSLOT ORIG 15 TERM 14
QUEU CAD

.13:42:48 31/10/2000 Сняли трубку, разговор
SENT CONN 0101 RECV CONN 0001
TERM 004 0 00 12 MARP 0 1034 500
DIAL DN 1034
MAIN_PM ESTD
TALKSLOT ORIG 3 TERM 31
QUEU NONE

.13:43:06 31/10/2000 Положили трубку, начало рассоединения
SENT CLRB 1101 RECV CONN 0001
TERM NONE
TDTN 0 SLOT 17 PTY SLOT 7
DIAL DN 1034
MAIN_PM HALFDISC
TALKSLOT NONE
QUEU 2S

Вот тут в ответ на CLRB должен появиться сигнал IDLE (1001), тогда канал нормально отключится и станет в IDLE. А сигнала нет… Ждем 30 секунд… и по таймауту умираем.

.13:43:38 31/10/2000
LOCKOUT TN DTI 001 06

.stpt

Я сомневаюсь, что это легко позволит обнаружить виновного..

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

По первому - отвисание канала через 15 минут.
LCKO - появляется в случае несоответствия сигнализации. Соответственно возможно оборудование провайдера реинициализировалось через некоторое время.
Хотелось бы уточнить - GL - прозрачно прокидывает канал до globe1 или на их стороне стоит телефонная станция.
Возможно со стороны Globe1 соединение разрывается только в том случае если с их стороны положили трубку, при этом их оборудование не распознаёт сигнал положенной трубки.
В любом случае, вышеприведённую распечатку можно с чистой совестью отсылать к той организации, к чьей телефонной станции вы подключены.
Скорее всего проблема не в настройке вашей станции.
Дмитрий.

Dimi:
По первому случаю - возможно. Или сигнализация таки пролезла по кабелю и обработалась. Но вопрос - как :)
После того, как канал сваливается в LCKO, он снимает из сигнализации свой запрос на отключение. Хотя кто его знает, как отрабатывается такой вариант.

По поводу локов - канал прозрачно проходит через GL сразу на провайдера. У провайдера всё настроено, у нас всё настроено, SICA сверены... Вчера сняли канал с MainStreem-a и включили напрямую с хаба в станцию. Ситуация не изменилась :) Короче, сейчас GL продолжает искать, где пропадает сигнализация.

Однозначно проблема в Global one. Логика работы на разрыв соединения - ваша телефонная станция посылает запрос на обрыв соединения, даже если в канале GL идут ошибки - телефонная станция у Global1 должна если не с первой посылки, так со второй разорвать соединение. Проблема исключительно у Global one. Есть ли у вас кроме DID другие виды транков? и есть ли проблема на них?
Удачи в разрешении вопроса.
Дмитрий.

Вот и долгожданный итог эпопеи:

Причина в телефонной станции Глобал. Когда моя станция посылает запрос (CLRB) на освобождение линии (мой абонент положил трубку), Глобал ждет, когда другая сторона тоже положит трубку и до тех пор, пока этого не произошло, не выдает сигнал IDLE. Моя станция честно ждет ответного сигнала и после истечения тайм-аута лочит линию. Такие ситуации происходят с некоторыми станциями МГТС и в случае, когда другая сторона не кладет трубку, а сдуру вешает полуотключенный звонок на холд.
Сейчас Глобал пытается договориться с МГТС и доработать софт на своей станции, чтобы канал освобождался сразу после получения нашего запроса без ожидания отбоя другой стороны. Вот, собственно, и всё. Спасибо всем, кто помог добрым советом.

..Я не,конечно,не Бог весть какой спец по Меридианам и Глобалам,просто,думается,нужно пояснить..Но,как мне видится,это общая проблема чисто "буржуйской" сигнализации и нашей "любимой R1.5".Рассмотри внимательно протоколы линейных сигнализаций R1,R1.5,R2.Можно заметить,что в R1,R2 сигналы Disconnect/Release выставляются как 00, а на R1,5 те же самые сигналы - 10. Таким образом Ты,вероятно, не можешь "понять : а чёй то от тебя хотят ?" Из каких соображений так протокол сделан не знаю (может Гольдштейн скажет ? :-))- я уже говорил,что R1.5 чисто советское изобрЕтение) )..Но,тем не менее, такая проблема существует практически везде, где R2 "перехлёстывается" по транзиту с R1.5..и не только между "Мерином" и "Глобусом". Например, Квант-Эска-Нек, МТ20-Хуавэй-Дефинити, АТСЦ90- Одекс100-Коралл,да много ещё где...Обнаруживается это достаточно элементарно : на транзитке,на её входящей СЛ ставится любой анализатор протокола и всё..Нужно только отловить атски,которые такую "бодягу" дают..В основном, это касается относительно старых электронных атс, адаптированных под СССР.Координатки тоже,по идее,этим больны,но там как-то где-то что-то перепаяли и работает сносно (по-крайней мере у нас :)) ). А вся это "бодяга",что творится у Вас по научному называется " ДВУСТОРОННИЙ ОТБОЙ" (если я правильно понял ситуацию). А Глобал,действительно,здесь не причём : в данном случае "труба" да и только..Можно, конечно,попросить их работать в режиме "тандем"..А оно им это надо ? Вот ещё вопрос..Тодысь ведь у них глюки могут начаться..
А вот по поводу лечения...Здесь,по-моему, "большой политИк" будет роль играть: за коррекции то денюжку платить надо (да и признать,что виноват то ты)..Хотя МГТС богатая контора..И ещё совет напоследок : как я помню, 2-сторонний отбой был запрещён в своё время Минсвязи ( "непродуктивное использование СЛ" - частые зависания),так,что можно на это давить..
Удачи Тебе в многотрудной борьбе с "оператором" :8)))))
Не обессудь за "словесный понос"..:))

Боюсь, что "ДВУХСТОРОННИЙ ОТБОЙ" в данной проблеме ни при чем - ведь глобаловская станция не отпускает канал при отбое абонента Б (т.е. абонента Меридиана - проблема, насколько я понял из дискуссии, наличествует при входящих звонках на Меридиан), и зачем-то ждет отбоя отбоя абонента А. Что вообще ни в какие рамки не лезет - потому как согласно 2ВСК при отбое абонента Б канал должен освобождаться всегда, и дополнительно, в случае поддержки станциями двухстороннего отбоя, он может быть также освобожден при отбое абонента А. Такое ощущение, что авторы софта глобаловской станции (или ее инстоллеры) как-то извратно поняли понятие "ДВУХСТОРОННИЙ ОТБОЙ", и освобождают канал только в случае прихода двух сигналов - "Отбой абонента А" и "Отбой абонента Б". А отбой абонента А вообще может не придти, потому как он приходит только со станций, поддерживающих двухсторонний отбой, а его в МГТС поддерживают далеко не все (потому как еще достаточно там АТС ДШ). Так что здесь однозначно виноват Глобал1, точнее, их станция.
Что же касается транзита из наших родимых 2ВСК/R1.5 в R2, то сконвертировать одни значения битиков в другие не проблема. Проблема в том, что в R2 нет понятия "двухсторонний отбой" - там канал освобождается только по отбою абонента Б. К сожалению, писатели софта для станций, которые используются в качестве гейтов, не всегда это корректно отрабатывают, чем и вызваны многие проблемы при транзите 2ВСК <=> R2. Но еще бОльшая проблема кроется в транзите самого R1.5 (т.е. импульсного челнока) во что-нибудь другое, а именно: исходящая сторона ждет очередного B-сигнала по умолчанию 4 секунды. Частотный обмен при нормальном местном вызове, после приема всех цифр номера, должен быть закончен сигналами B4 (абонент свободен), или B5 (абонент занят). А вот теперь представим, что по R1.5 через гейт подключена большая частная телефонная сетка, где на то, чтобы выяснить, свободен или занят абонент, требуется достаточно много времени, или пуще того, сотовый коммутатор, где время поиска в зоне обслуживания трубки исчисляется нередко десятками секунд. Вот тут-то мы уже поимеем куда более серьезные проблемы, когда исходящая сторона через 4 секунды будет рвать канал, так и не дождавшись B4 или B5.