циклический выбор сл в PRI, нет циклического выбора сл при Networking Опции

[Marina]

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

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?
Вообще возможно ли это?

[Marina]

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

[ИгорьS]

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

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

[Marina]

Почти неделю все было нормально. Сегодня пришла на работу одна линия висит. К сожалению ночью трассировка была выключена, поэтому момент блокировки упустила.
Вот часть трассировки в момент выхода на заблокированную линию №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]

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

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

[Marina]

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

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

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

Прикрепленные файлы

 060514.txt ( 3,03 килобайт ) Кол-во скачиваний: 3

 

[harris]

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

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

[Marina]

Чтобы убедиться, что со стороны LIK указатель вызова был послан правильно, нужно снимать трассировку непосредственно модуля PRIM, подключившись к нему по RS-232 или по Telnet.

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

[harris]

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

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

[Marina]

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

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

Прикрепленные файлы

 120514.txt ( 195,43 килобайт ) Кол-во скачиваний: 4

 

[harris]

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

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

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

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

[Marina]

Ну, если неизвестно, какие именно линии "зависали" и неизвестен момент, когда это произошло, то каким образом можно вычленить это из 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 достаточно большой, но если нужен, выложу.