Топик «Односторонняя слышимость» (в нашей редакции) Назад Back

Топик «Односторонняя слышимость» (немного отредактировано) Назад Back

DJ2 (Posted: 07 Aug. 2003, 14:52 )

Говорят, что при успешном установлении соединения односторонняя слышимость ("ты слышишь, тебя нет" и наоборот), на 90% вызвана неполадками в системах передачи, а не коммутационного оборудования. Так ли это?

abessonov (Posted: 07 Aug. 2003, 15:47)

Если мы говорим о соединении в разговорной фазе (после получения сигнала "ответ" в любой системе сигнализации) и именно об односторонней слышимости - то на 99,999% виновато оборудование передачи.

DJ2 (Posted: 07 Aug. 2003, 16:17 )

Да, вроде, именно так (в тт-файле в поле 35 "Call Status"=0 (Normal call, no fault in incoming junctor, no system restart).

abessonov (Posted: 07 Aug. 2003, 16:48)

Я видел пару раз обратный случай, т.е. когда сигнала "ответ" не было, а разговаривать можно было в обе стороны. Это был глюк именно коммутационной станции, естественно 3-х этажный интерворкинг.

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

DJ2 (Posted: 07 Aug. 2003, 17:59 )

Да, нашли фолтовый речевой канал, при занятии которого слышимость была только в одну сторону. Мой комментарий: В данном случае это был интерфейс PRI EDSS1. В одну сторону работал канал на плате PRI на встречной УПАТС. Плату заменили.

Теперь вопрос: а если порт станции работает только в одну сторону, станция это определяет? Переводит этот канал в CBL?

abessonov (Posted: 07 Aug. 2003, 19:00)

Есть специальная процедура под это - Continuity Check. Если она используется (нужно железо и софт на станции), такие каналы выявляются и блокируются. Но даже если ее нет, фолтовый канал рано или поздно заблокируется SEQAR-ом (Seizure Quality Supervision), если данный надзор активирован и выставлены верные пороги.

DJ2 (Posted: 07 Aug. 2003, 21:57 )

Андрей, ещё раз спасибо за ценнейшую информацию для нас в образовательном плане... Я много раз на этот Continuity check... как баран на новые ворота . И полезность SEQAR'а прочувствовал только сейчас . Many thanks.

AXEMAN (Posted: 11 Aug. 2003, 20:02)

Односторонняя слышимость бывает еще и в следующем случае: В RC стоит параметр FCP и в то же время сигнал "ответ" не доходит по какой-то причине. Тогда слышимость только в направлении от вызываемого абонента.

Vadim (Posted: 12 Aug. 2003, 15:12)

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

abessonov (Posted: 12 Aug. 2003, 16:38)

Цитата (из Vadim'а): «Проблема односторонней слышимости очень часто встречается при CCS7, если смещены потоки с разговорными каналами.»

Я бы сказал, что тогда не будет никакой слышимости. Если речь идет о несовпадении CIC...

Мой комментарий: Согласен. Тут, скорее, всего, будут попадать «не туда», что и было отмечено далее Всеволодом. Хотя на 100% утверждать не берусь: «Есть много, друг Горацио, такого, что и не снилось нашим мудрецам…» J (за точность цитаты тоже не ручаюсь).

Valdr (Posted: 14 Aug. 2003, 18:23)

Quote (abessonov @ 12 Aug. 2003, 16:38) «Я бы сказал, что тогда не будет никакой слышимости. Если речь идет о несовпадении CIC...»

Ну, да, скорее всего.

Я по данной проблеме тоже много работал. Получается, что такие случаи бывают на уплотнённых каналах. SEQAR мне никак помог - срабатывает на все девайсы подряд, никакой системы. Единственное средство, как было сказано, CCH. Кто-то пользуется?

lew (Posted: 01 Nov. 2003, 14:16)

А у нас был глюк в ОКСЕ причину не выяснили всё восстановилось после EXDAE EXDAI на DEV гличного DIPа. Вот так...................................

DJ2 (Posted: 01 Nov. 2003, 14:49 )

to lew - Как вы определили этот девайс - с помощью TCTDI ?

to Valdr и всем - Неужели никто не пользуется, хотя бы иногда, для проверки? Недавно при транзитном соединении из ТфОП после IAM пришло сообщение COT (там говорилось об успешной continuity) , затем обмен пошёл как обычно, соединение состоялось.

Artem (Posted: 04 Nov. 2003, 15:24)

у нас такое было, все произошло из-за несовпадения cic'ов. 30 потоков, из них 10 в середине были перемешаны. соотв народ жаловался на одностороннюю слышимость, но только в ЧНН (селекшен тайп был 7 и 6 с разных сторон). гимора было много, но обнаружили это дело относительно быстро.

DJ2 (Posted: 05 Nov. 2003, 15:01 )

Попробовал воспользоваться, результаты какие-то сомнительные - ничего, выходит, не дождались после CCR, выставили REL и TESTRESULT SUCCESSFUL?

TCCCI:DEV=updnr-xxxx, norck;

CONTINUITY CHECK TEST RESULT

DEV TCDEV TESTRESULT

UPDNR-xxxx SUCCESSFUL

FAULTTYPE

END

ISUP MESSAGE MONITOR RESULT

TIME MSG DIR

13:34:43:3 CCR S

TIME MSG DIR

13:34:43:4 REL S Location 10, Cause 127

TIME MSG DIR

13:34:43:5 RLC R

END

При звонках в ТфОП:

ISUP MESSAGE MONITOR RESULT

TIME MSG DIR

13:56:13:5 IAM S

TIME MSG DIR

13:56:13:6 COT S (Cont. ind.=1 (successful))

TIME MSG DIR

13:56:38:8 REL S (Location=12, Cause=16)

TIME MSG DIR

13:56:38:8 RLC R

END

abessonov (Posted: 05 Nov. 2003, 16:40)

To DJ2: а железо у вас под ContCheck есть?

DJ2 (Posted: 05 Nov. 2003, 16:43 )

Хотя всё правильно: У COT и CCR направление forward. На часть номеров ТфОП звонки проходят с COT:

IAM-COT-ACM-ANM-REL-RLC => поставишь CCH=1 на руте и на часть номеров абонент не дозвонится?

DJ2 (Posted: 05 Nov. 2003, 16:46)

Да, это платы TCD, плата широкая, на два посадочных места. Иначе continuity checking у нас бы не получился.

abessonov (Posted: 05 Nov. 2003, 21:14)

С ContCheck нужно вообще осторожным быть с точки зрения работы со смежными станциями. Старые станции (или устройства типа VoiceMAil и т.д.) СОТ-ы могут просто не понимать, некоторые не умеют корректно с ним работать. Другие могут АСМ генерить не дожидаясь COT-a. В этом случае на рутах имеет смысл CEND=1 прописывать. А так - все работает вроде.

DJ2 (Posted: 05 Nov. 2003, 22:36)

Спасибо за информацию. Ещё бы на PRI чего-то такое соорудить. Там есть что-то вроде, но на уже установленных речевых каналах.

DJ2 (Posted: 05 Nov. 2003, 23:39)

Теперь такой вопрос: А что делать с результатами CCH в случае многозвенного

соединения? У кого фолтит? передавать по инстанции? Так теперь в эпоху либерализации связи тебе зачастую даже не скажут, кто следующий оператор. Или CCH работает только на звене связи, как протокол HDLC?

abessonov (Posted: 06 Nov. 2003, 00:50)

CCH выполняется только на одном участке (ближайшем к станции, желающей выполнить проверку), о чем сообщается в ИАМе (там идет запрос на петлю на этом участке). Далее ИАМ идет с указанием, что CCH выполнялся на пред. участке и для станций это должно (ИМХО) являться неким "тормозом" к выдаче АСМ - т.е. не увидел СОТ (который должен проходить в прямом направлении по всему пути) с успешным индикатором - не выдавай АСМ. Если АСМ будет отправлен раньше, чем пройдет СОТ, соединение развалится (будет unexpected message ACM в UPDBP), но это лечится выставлением CEND=1 на исход. роут, с которого раньше времени лезет АСМ (в этом случае наверное придерживается выдача ИАМа туда до получения СОТа).

Мне кажется, что если не стоит никакой аппаратуры "уплотнения" - ССН не нужен. Если стоит - нужен и помогает.

Мой комментарий: Затем этот топик получил такое продолжение:

Топик «Снова односторонняя слышимость» (в нашей редакции)

Garuda (Posted: 13 Nov. 2003, 10:46)

При прописи ОКС 7 между AXE 10 и SI 2000 столкнулись с одной интересной проблемой. Проблема заключается в односторонней слышимости в 16 канале потока. С CIC'ами все вроде в порядке, тем более что сигнальный канал прописывали и в 1-ом и во 2-ом канале. На 16-ом канале соответственно сигнальный линк не вставал. Меняли плату на AXE, не помогло. Взяли другой порт, из другого магазина и TSM'а, тоже не помогло. Перепробовали 4 разных порта на SI 2000, тоже без результатно.

Канального оборудования нет. Станции соединяются напрямую на кроссах. В чем может быть дело?

vsevolod (Posted: 13 Nov. 2003, 12:26)

А DIP описан правильно? Там есть параметр на DIP'e как поступать с 16 таймслотом. Команда DTIDP и DTIDC

Garuda (Posted: 13 Nov. 2003, 13:09)

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

vsevolod (Posted: 13 Nov. 2003, 13:31)

Да не за что:-) Я уже давно привык что чудес не бывает нужно копать и как правило, копать не глубоко:-) Удивительное рядом но оно запрещено:-)) (с) В.Высоцкий

У нас тут недавно обрубили волокно на ИКМ-120, через которую работал RSS. После восстановления волокна вынос не поднялся. Дело уже было к полуночи. Я разопределил один CLC и определил вновь. Не помогло потом сделал LARGE RESTART не помогло. Разопределил и определил второй CLC. Не помогло. Но стала появляться авария EMG TRANSMISSION FAULT при попытках поднять вынос. Потом поехал на вынос поменял платы ETB. Не помогло. Поехал на HOST поменял плату ETC на нулевом мастере. Не помогло.

Еще раз разопределил и опеределил CLC. Не помогло. Все та же авария EMG TRANSMISSION FAULT. Ушел домой в 2 часа ночи. Уверенный что причина в системе передач. К шести утра вместо меня вышел мой напарник и ребята из системы передач. Продолжили проверки. В результате удалось поднять вынос без одного из мастер магазинов.

Как только пробовали его поднять вынос падал с аварией EMG TRANSMISSION FAULT. К 11 утра пришел я и тут напарника осенило! Подав команду EXCLP:CLC=ALL он увидел что для этого RSS ни для одного из мастеров не прописан девайс RT2 16 таймслота. Т.е. EXCLI подавалась просто

без указания параметра DEV. Как только все правильно прописали вынос заработал. От такая история. Было это всего несколько дней назад:-)

vsevolod (Posted: 13 Nov. 2003, 13:35)

Вообще я бы создал отдельный FAQ по подобным вещам. Т.к. в принципе ошибка простая и легкоустранимая но поведение станции или те аварии, которые она выдает иногда сбивают тебя с толку и уводят от правильного пути поиска. Почитать хотя бы рекомендации по аварии EMG TRANSMISSION FAULT.

vsevolod (Posted: 13 Nov. 2003, 13:44)

Или вот еще по C7 Если перепутать CIC то иногда это проявляется как потеря слышимости при небольшом трафике или если маршрут активно используется то тогда абоненты жалуются что не туда попадают:-) . Хотя на самом деле станции просто не те каналы коммутируют:-)

<...................................................>

vsevolod (Posted: 13 Nov. 2003, 17:50)

To DJ2 Предлагаю общаться на ты:-)

И к администратору сайта есть все-таки настойчивое предложение сделать FAQ по проблемам описанным и подобным тем что описаны в этом топике.

DJ2 (Posted: 13 Nov. 2003, 18:03 )

Всеволод! Кто, кроме нас, сделает FAQ ? J . <...> На моей страничке уже есть кое-что.

Если есть инфо какая, предложения и т.д., присылай dj-2@yandex.ru .

DJ2 (Posted: 13 Nov. 2003, 18:07 )

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

DJ2 (Posted: 13 Nov. 2003, 19:04 )

to vsevolod и всем - Чтобы сделать 16-й слот однонаправленным, нужно установить MODE=1 ? Но там сказано про single 64 kbit/s channel, а не oneway? Или другой параметр?

Кстати, что это за сигнализация такая симплексная?

Главная страница Main Page

Командные сценарии для WinFIOL’а WinFIOL Scripts

Толковый словарь по телекоммуникациям Telecom Glossary