циклический выбор сл в PRI, нет циклического выбора сл при Networking |
Здравствуйте, гость ( Вход | Регистрация )
циклический выбор сл в PRI, нет циклического выбора сл при Networking |
6.5.2014, 11:20
Сообщение
#21
|
|
ГУРУ Группа: Участники Сообщений: 12388 Регистрация: 23.11.2006 Из: Москва Пользователь №: 146 |
Никогда не подключалась к PRIM по RS-232. На осваевание уйдет время. Надо когда-то начинать. Можно через Telnet на IP-адрес PRIM'а на порт 5003. -------------------- Аксиома Коула: Общая сумма разума на планете - величина постоянная, а население растет ...
|
|
|
12.5.2014, 10:21
Сообщение
#22
|
|
Продвинутый пользователь Группа: Участники Сообщений: 189 Регистрация: 26.8.2008 Пользователь №: 11715 |
Можно через Telnet на IP-адрес PRIM'а на порт 5003. Уважаемый, Harris! Сняла трассировку с PRIM. Файл в приложении. Точно засечь на какой сл и во сколько были блокировки(быстро отбиваются) не смогла. До этого 4 часа писала логи с MFIM было 6 блокировок. Из этого файла мне ничего не понятно. Если возможно расшифруйте результаты трассировки.
Прикрепленные файлы
|
|
|
12.5.2014, 11:31
Сообщение
#23
|
|
ГУРУ Группа: Участники Сообщений: 12388 Регистрация: 23.11.2006 Из: Москва Пользователь №: 146 |
Уважаемый, Harris! Сняла трассировку с PRIM. Файл в приложении. Точно засечь на какой сл и во сколько были блокировки(быстро отбиваются) не смогла. До этого 4 часа писала логи с MFIM было 6 блокировок. Из этого файла мне ничего не понятно. Если возможно расшифруйте результаты трассировки. Ну, если неизвестно, какие именно линии "зависали" и неизвестен момент, когда это произошло, то каким образом можно вычленить это из 4-х часовой трассировки?? В прошлой трассировке мелькнуло, что канал освобожден с причиной №81 ( invalid call reference value). В данной трассировке ни одной такой записи нет. А вы не спрашивали провайдера по поводу физического уровня канала?? Там все в норме по синхронизации?? Нет слипов в канале?? -------------------- Аксиома Коула: Общая сумма разума на планете - величина постоянная, а население растет ...
|
|
|
13.5.2014, 2:21
Сообщение
#24
|
|
Продвинутый пользователь Группа: Участники Сообщений: 189 Регистрация: 26.8.2008 Пользователь №: 11715 |
|
|
|
14.5.2014, 4:21
Сообщение
#25
|
|
Продвинутый пользователь Группа: Участники Сообщений: 189 Регистрация: 26.8.2008 Пользователь №: 11715 |
Ну, если неизвестно, какие именно линии "зависали" и неизвестен момент, когда это произошло, то каким образом можно вычленить это из 4-х часовой трассировки?? Добрый день! Снимала трассировку одновременно с MFIM и с PRIM для того, чтобы сопоставить время событий. По трассировке с MFIM ориентировалась по фразе «public network serving local user invalid call reference value». Получилось следующее: Дата 14/05/13. Время диапазон 1 минута: 10/45 - 10/46 сл№1 (со 63) 10/47 - 10/48 сл№3 (со 65) 10/48 - 10/49 сл№1 (со 63) 12/13 - 12/14 сл№1 (со 63) 12/15 - 12/16 сл№3 (со 65) 12/19 - 12/20 сл№29 (со 91) 12/29 - 12/30 сл №4 (со 66) 14/31 - 14/32 сл№24 (со 86) 15/53 - 15/54 сл№6 (со 68) По времени событие можно отыскать в трассировке с PRIM. Файл с MFIM достаточно большой, но если нужен, выложу. |
|
|
14.5.2014, 4:26
Сообщение
#26
|
|
Продвинутый пользователь Группа: Участники Сообщений: 189 Регистрация: 26.8.2008 Пользователь №: 11715 |
|
|
|
14.5.2014, 9:36
Сообщение
#27
|
|
ГУРУ Группа: Участники Сообщений: 12388 Регистрация: 23.11.2006 Из: Москва Пользователь №: 146 |
Забыла прикрепить файл Да. OK, нашлось: [301465126]L3:4, [U00]<<{08027F040504038090A31803A983846C084180323333363130} [301465133]L3:4, [U01]>>{0802FF040D1803A983841E028088} [301465370]L3:4, [U02]<<{08027F047B70028032} [301465430]L3:4, [U02]<<{08027F047B70028038} [301465571]L3:4, [U02]<<{08027F047B70028032} [301465652]L3:4, [U02]<<{08027F047B70028036} [301465700]L3:4, [U02]<<{08027F047B70028038} [301465731]L3:4, [U02]<<{08027F047B70028030} [301465737]L3:4, [U02]>>{0802FF0402} [301465755]L3:4, [U03]>>{0802FF04011E0280821E0200081E028088} [301466324]L3:4, [U04]>>{0802FF04071E02808229060E050D0A2D32} [301466331]L3:4, [U10]<<{08027F040F} [301466337]L3:4, [U10]>>{0802FF045A080282D1} [301467955]LAYER3_UnexpectedMsg [301467955]L3:0, [U00]<<{08027F045A080280D1} [301467955]L3:255, [U00]>>{0802FF0445080282901E028088} ИМХО, здесь не видно причины грешить на неправильную работу LIK. Вот один из вызовов: Исходящий вызов от LIK был принят провайдером и нормально обработан. Никаких претензий к Call Reference не было. Более того, на этот вызов был ответ вызываемого абонента. LIK подтвердила соединение, и тут после этого провайдер сбрасывает вызов посылкой Rel_Comp с причиной №81 (Invalid Call Reference). Это почему?? Call Reference во всех сообщения этого вызова был в порядке и не менялся. В других случаях провайдер сбрасывает вызовы (Rel_Comp + Cause #81) в любой момент, даже когда вызов уже состоялся и абонент LIK нормально его завершил, то провайдер все равно присылает Rel_Comp вместо Rel и опять с причиной №81. Но все Call Reference во всех вызовах нормальные!!! ИМХО, по-любому проблема на стороне провайдера. Пусть они разбираются детально с "глюками" на своей АТС. -------------------- Аксиома Коула: Общая сумма разума на планете - величина постоянная, а население растет ...
|
|
|
14.5.2014, 10:40
Сообщение
#28
|
|
Продвинутый пользователь Группа: Участники Сообщений: 189 Регистрация: 26.8.2008 Пользователь №: 11715 |
Большое спасибо!!! есть что сказать провайдеру.
Завтра буду предметно разговаривать с ними. |
|
|
Текстовая версия | Сейчас: 11.5.2024, 11:44 |