Версия для печати темы

Автор: Marina 28.4.2014, 2:49

Добрый день! Так как никто не ответил на предыдущую тему, решила упростить вопрос.

LIK600
MFIM/GS97M-6.0Bo DEC/12
Boot Version-2.1Aa NOV/12
Kernel Version-6.0Ap
H/W issue-3

Город включен по PRI.
Как сделать «циклический выбор» сл в потоке, если 9 прописана в Networking пгм 324 линии PSTN?
Вообще возможно ли это?

Автор: Dron 28.4.2014, 6:39

В таком варианте никак.

Автор: stasmar 28.4.2014, 9:58

Андрей!
У меня негде сейчас посмотреть следующее:
для Station Number есть такая настройка
Prefer CO or Group
System will seize this CO Line or CO group number when the station dials “9” (First available Co access code)
CO Line #88095 88ххх
or CO Grp #803 8хх
то-есть по смыслу есть возможность для абонента указать ему предпочитаемую CO-линию, которую он получит при нажатии 9;
я даже не знаю для какой атс у меня записана эта инфа - куча атс сейчас в голове, включая Авая, скоро у меня все это в кашу сварится..

Автор: AXEL 28.4.2014, 10:24

если у вас эта станция транзитная, то для своих абонентов можно параллельно использовать LCR.
LCR никакого влияния не оказывает на транзитные вызовы, я для своих абонентов это будет высший приоритет.
То есть прописываете 9-тку как int lcr тип и оставляете её в 324 программе. Для LCR работает циклический выбор.

Автор: Dron 28.4.2014, 10:41

Для LCR оно конечно.

To Marina:
А чем так критично цикличное занятие линий в потоке?

Автор: stasmar 28.4.2014, 10:42

я тоже мысленно не согласился с Андреем, подумав про ЛСР, но не стал спорить..

Автор: Dron 28.4.2014, 10:55

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

Автор: stasmar 28.4.2014, 11:30

Такое было уже у кого то здесь на форуме, я даже ссылку искал у себя в кондуитах на топик.. не нашел..
Можно провайдера попросить поменять выбор линий в потоке, вроде..

Автор: ИгорьS 28.4.2014, 17:04

Не с того направления пытаетесь решать проблему.
Если идет блокирование каналов провайдера, то найти проблему с последовательным занятием-быстрее если оно постоянно, а не спорадически.
При чем тут смена порядка занятия.
Смешная ситуация была несколько лет назад, когда пров отрезал канал лишний -16-й, плата же за 15(и получалось что переодически шел отлуп).
Так что уточняете, не было ли изменений настроек потока провайдера.
Поток на мониторинг-дальше по результам.

Автор: Marina 30.4.2014, 2:11

Простите, что потерялась и не ответила сразу. Работа. Пришлось отлучиться на 2 дня.
Циклический способ занятия нужен на тот момент, когда канал заблокирован, а меня нет на месте. Абоненты 9-ой выходят на заблокированный канал. Т.к. отбой это секундное дело, то практически все тыкаются в этот канал.
Циклический способ занятия это промежуточное решение проблемы.
Основное это выяснить причину блокировки. В log-ах пишу целый день трассировку. Пока понять ПОЧЕМУ не получается. Тем более проблема возникает не каждый день.

Автор: Marina 30.4.2014, 2:14

Штудирую описание. Думаю причина в нестыковке отбойных таймеров. Может у кого-нибудь опыт есть в этом вопросе.

Автор: ИгорьS 30.4.2014, 14:54

Марина, разговаривать можно долго и строить предположения.
На данный момент, от вас нет даже трассировки попытки занятия блокированного канала.

Автор: Marina 30.4.2014, 15:29

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

Автор: Marina 6.5.2014, 3:02

Почти неделю все было нормально. Сегодня пришла на работу одна линия висит. К сожалению ночью трассировка была выключена, поэтому момент блокировки упустила.
Вот часть трассировки в момент выхода на заблокированную линию №65

(USER) --------->>
(CO 65) SETUP
IE_BEARER_CAPABILITY
CCITT standardized coding
speech
circuit mode
64kbits
recommandation G.711 A-law
IE_CHANNEL_INFO
interface implicitly identified
other inferface
exclusive
is not D-channel
B1 channel
CCITT standard coding
indicated by num in following octet
B channel units
83
IE_CALLING_NO
subscriber number
ISDN numbering plan
presentation allowed
not screened
233710

214758669 CM-W>0007 60 003F, 1C 0029, 060
214758678 E>0007 60 0041, B0 0005, 5A8
214758678 PRI: 65 Asc: S 1880 St:wt sz rsp (00)(00) Ev-P:i-rls comp P1:5A P2:8 EVT: 0
<<====== [NETWORK]
(CO 65) RELEASE COMPLETE
IE_CAUSE
CCITT standardized coding
user
request not available

214758678 C>0007 60 0041, 41 0002, 8383
214758678 C>0007 60 0041, 44 0004, 1C2
214758678 C>0007 60 0041, 44 0004, 1C2
214758678 C>0007 60 0041, 44 0004, 1C2
214758681 CM-W>0007 60 003F, 1C 0032, 060
214758690 PRI: 65 Asc: S 1880 St:wt sz rsp (00)(00) Ev-T:isd rls gd P1:FFFF P2:FFFFFFFF TMR: 9
214758690 C>0007 60 0041, 44 0004, 1C2
214758693 CM-W>0007 60 003F, 1C 000D, 060
214759140 PRI: 65 Asc: St:co idle (00)(00) Ev-I:seize req P1: 0 P2:0 EVT: 15 From[IPKT:281]
214759140 C>0007 60 0041, 41 0002, 8383
214759140 C>0007 60 0041, A5 0015, 54

Автор: harris 6.5.2014, 8:26

Эта трассировка ничего нового не дает.
Провайдер отбил исходящий от вас вызов с причиной №44 - Запрошенный канал недоступен.
Почему канал заблокирован - ИМХО, это должен "копать" провайдер на своей стороне.

А что, провайдер требует использовать Overlap, а не Enblock?? Или вы сами выбрали Overlap??

Автор: Marina 6.5.2014, 9:33

Overlap используем сами, так исторически сложилось.
Наконец-то выловила момент блокировки. Кусок большой, прикрепила файл.

Автор: harris 6.5.2014, 9:53

Там тоже нет ничего криминального со стороны LIK. Нормальное завершение вызова, Disconnect приходит от провайдера с Прогрессом. LIK освобождает канал посылкой Relaese. А вот провайдер завершает освобождение канала посылкой Release_Complete, но почему-то дает сначала причину "Несоответствие указателя вызова" (что очень странно), а уже потом дает повторно Release_Complete c причиной "Нормальное завершение". Что-то у провайдера, ИМХО, странное происходит.
Чтобы убедиться, что со стороны LIK указатель вызова был послан правильно, нужно снимать трассировку непосредственно модуля PRIM, подключившись к нему по RS-232 или по Telnet.

Автор: Marina 6.5.2014, 10:49

Никогда не подключалась к PRIM по RS-232. На осваевание уйдет время. Надо когда-то начинать.

Автор: Marina 6.5.2014, 10:53

Так вот в этом то и причина: провайдер в нашу сторону высылает сигнал освобождения, а при этом занятие этой линии дает отбой.

Автор: harris 6.5.2014, 11:01

Это не причина, а суть проблемы.
Провайдер запросил разъединение.
LIK освободила канал
Провайдер тоже формально освободил канал - выдал Release_Comp
Но при этом канал (ресурсы, связанные с этим каналом) на стороне провайдера остались занятыми.
Почему?? Это провайдер должен разобраться у себя.
Единственное, так это была указана причина от провайдера - invalid call reference value.
Вот это странно. Чтобы проверить это, нужно более детальную трассировку на модуле PRIM.

Может, у провайдера проблемы с гор. сетью. Возможно, что канал не освободился, т.к. не освободились ресурсы (канал) в городском транке.

Автор: harris 6.5.2014, 11:20

Можно через Telnet на IP-адрес PRIM'а на порт 5003.

Автор: Marina 12.5.2014, 10:21

Уважаемый, Harris!
Сняла трассировку с PRIM. Файл в приложении.
Точно засечь на какой сл и во сколько были блокировки(быстро отбиваются) не смогла. До этого 4 часа писала логи с MFIM было 6 блокировок. Из этого файла мне ничего не понятно.
Если возможно расшифруйте результаты трассировки.

Автор: harris 12.5.2014, 11:31

Ну, если неизвестно, какие именно линии "зависали" и неизвестен момент, когда это произошло, то каким образом можно вычленить это из 4-х часовой трассировки??

В прошлой трассировке мелькнуло, что канал освобожден с причиной №81 ( invalid call reference value).
В данной трассировке ни одной такой записи нет.

А вы не спрашивали провайдера по поводу физического уровня канала?? Там все в норме по синхронизации?? Нет слипов в канале??

Автор: Marina 13.5.2014, 2:21

С сигнализациями все в порядке в мою сторону точно, по словам провайдера в его сторону тоже.

Автор: Marina 14.5.2014, 4:21

Добрый день!
Снимала трассировку одновременно с 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 достаточно большой, но если нужен, выложу.

Автор: Marina 14.5.2014, 4:26

Забыла прикрепить файл

Автор: harris 14.5.2014, 9:36

Да. 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 во всех вызовах нормальные!!!

ИМХО, по-любому проблема на стороне провайдера. Пусть они разбираются детально с "глюками" на своей АТС.

Автор: Marina 14.5.2014, 10:40

Большое спасибо!!! есть что сказать провайдеру.
Завтра буду предметно разговаривать с ними.