циклический выбор сл в 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.