ipLDK-60 отбой звонка через 4 секунды Опции

[korneff]

Добрый день!
Столкнулся со следующей проблемой.
Имеем ipLDK60, подключена к городу по потоку. Все настроено и работает нормально, НО.
Провайдер меняет схему подключения, была медь, станет оптика. Провайдер уже поставил голосовой шлюз, т.е. подключение к PSTN состоит из двух частей: провайдерская АТС-шлюз (SIP) и шлюз-ipLDK (E1)
Вчера сделал попытку переключиться на новую схему.
Исходящая связь работает нормально, а вот с входящей проблемы.
Входящий вызов принимается станцией, соединение устанавливается, но обрывается через 4 секунды.
Совместно с провайдером отдебажили обе стороны. И вот тут то как раз затык. Вот трэйсы с ipLDK-60:

021104 COL 004:06 01 St:co idle (00) EVT 5(SETUP) 2B 05 A1 04 03 90 90 A3 18 03 A9 83 81 1E 02 81 83 6C 0C 01 83 39 30 33 31 39 33 39 36 35 33 70 0B
A1 34 39 35 35 33 30 34 30 30 31 (U0)
021104 C>06 01, D1(PROCEED) 06 02 18 03 A9 83 81
021104 COL 004:06 01 St:co idle (00) Ev-I:ring start P1: 0 P2: 0 EVT: 11 <- 4,61
021104 D>06 01, C0 00 60
021104 COL 004:06 01 St:di-dialing(00) Ev-I:disa dgt P1: 4 P2: 0 EVT: 80 <- 4,61
021104 COL 004:06 01 St:di-dialing(00) Ev-I:disa dgt P1: 9 P2: 0 EVT: 80 <- 4,61
021104 COL 004:06 01 St:di-dialing(00) Ev-I:disa dgt P1: 5 P2: 0 EVT: 80 <- 4,61
021104 COL 004:06 01 St:di-dialing(00) Ev-I:disa dgt P1: 5 P2: 0 EVT: 80 <- 4,61
021104 COL 004:06 01 St:di-dialing(00) Ev-I:disa dgt P1: 3 P2: 0 EVT: 80 <- 4,61
021104 COL 004:06 01 St:di-dialing(00) Ev-I:disa dgt P1: A P2: 0 EVT: 80 <- 4,61
021104 COL 004:06 01 St:di-dialing(00) Ev-I:disa dgt P1: 4 P2: 0 EVT: 80 <- 4,61
021104 COL 004:06 01 St:di-dialing(00) Ev-I:disa dgt P1: A P2: 0 EVT: 80 <- 4,61
021104 COL 004:06 01 St:di-dialing(00) Ev-I:disa dgt P1: A P2: 0 EVT: 80 <- 4,61
021104 COL 004:06 01 St:di-dialing(00) Ev-I:disa dgt P1: 1 P2: C EVT: 80 <- 4,61
021104 C>06 01, D0(ALERT) 06 01 18 03 A9 83 81
021104 COL 004:06 01 St:di-dialing(00) Ev-I:dummy acd P1:26F3 P2: 0 EVT: 0 <- 4,61
021105 COL 004:06 01 St:di-dialing(00) Ev-I:dummy acd P1:26AF P2: 3 EVT: 0 <- 4,61
021134 COL 004:06 01 St:di-dialing(00) Ev-T:v-conn dly P1: 0 P2: 0 TMR: 86 <- 4,61
021135 C>06 01, D2(CONNECT) 01 07
021154 COL 004:06 01 St:di-dialing(00) Ev-T:vmib delay P1: 0 P2: 0 TMR: 38 <- 4,61
021155 D>06 01, C0 00 60
021155 COL 004:06 01 St:ds-dialing(0D) Ev-I:dvu play P1: 0 P2: 1 EVT: 0 <- 2,88
021187 COL 004:06 01 St:ds-dialing(0D) EVT F(RELEASE) 05 4D 08 02 80 E6 (U8)
021187 C>06 01, E0(RLS COMPLETE) 05 5A 08 02 80 E6
021187 D>06 01, C1 00 00
021187 D>06 01, C5 00 00
021190 COL 004:06 01 St:ds-dialing(0D) Ev-T:isd rls gd P1: 0 P2: 0 TMR: 9 <- 4,61
021190 D>06 01, C5 00 00

Как видно - LDK не получает от провайдера CONNECT ACK, ну и через 4 секунды пот таймеру T313 разрывает соединение.

Казалось бы налицо проблема со стороны провайдера, НО!
Вот трэйсы со шлюза провайдера:
SMG-1016M. SN: VI1F002865 Software Version: V.3.4.0.1464 M Build: Sep 11 2015 11:37:22
Log started at: 18:38:00.458975 27/02/16
Trace levels:
alarm - 00
calls - 00
isup - 00
q931 - 01
sipt - 00
rtp - 00
msp - 00
radius - 00
18:38:07.742369 [INFO] Q931. Line 00/00. Create Call, entry 01. Call 0003 (Outgoing)
18:38:07.742497 [INFO] Q931. Line 00/00. Setup from SIPT:0321 (enblock)
18:38:07.742545 [INFO] Q931. Line 00/00. Call 0003. State 'Null'
18:38:07.743154 [INFO] Port PRI:00:01. Set calling
18:38:07.743223 [INFO] Q931. Line 00/00. Call 0003. 'Dial' in state 'Null'. <4955304001.>(11)
18:38:07.743283 [INFO] Q931. Line 00/00. Call 0003. 'OutDial' result [11]
18:38:07.743344 [INFO] Line 00/00. Search B-chan: chan -1, mask 00010001 {chan mask: 00010021} - chan order: 2, dir=1, start=2
18:38:07.743386 [INFO] Line 00/00. Search B-chan: chan -1, mask 00010001 {chan mask: 00010021} - found free chan 1 (cycle dir 1)
18:38:07.743426 [INFO] Q931, Line 00/00. Call 0003. Create Seize - entry 01, channel 01
18:38:07.743469 [INFO] Q931. Line 00/00. Call 0003. State 'Call Initiated'
18:38:07.743515 [INFO] Q931. Line 00/00. Call 0003. Timer 'T303' (4 sec) start in state 'Call Initiated'
18:38:07.743672 [INFO] Q931. Line 00/00. Call 0003. TX 48
DUMP: 08.02.00.03.05.A1.04.03.90.90.A3.18.03.A9.83.81.
1E.02.81.83.6C.0C.01.83.39.31.36.38.31.32.39.36.
37.33.70.0B.A1.34.39.35.35.33.30.34.30.30.31.
0x0003 (from orig), MSG=SETUP:
[sending complete]
[bearer capability:
cap=3.1 kHz audio
std=CCITT
rate=64 kbit/s
mode=circuit
layer1=G.711 A-law]
[channel id: channel=1 (exclusive)] Coding=CCITT
[progress ind: Origin not isdn]
[calling party number: 9168129673 (type=unknown, plan=ISDN, present.allowed, network provided)]
[called party number: 4955304001 (type=national, plan=ISDN)]
---------------------------------
18:38:07.910397 [INFO] Q931. Line 00/00. Call 0003. RX 10
DUMP: 08.02.80.03.02.18.03.A9.83.81.
0x0003 (to orig), MSG=CALL PROCEEDING:
[channel id: channel=1 (exclusive)] Coding=CCITT
---------------------------------
18:38:07.910473 [INFO] Q931. Line 00/00. Call 0003. Timer 'T303' stop in state 'Call Initiated'
18:38:07.910557 [INFO] Q931. Line 00/00. Call 0003. State 'Outgoing Call Proceeding'
18:38:08.009361 [INFO] Q931. Line 00/00. Call 0003. RX 10
DUMP: 08.02.80.03.01.18.03.A9.83.81.
0x0003 (to orig), MSG=ALERTING:
[channel id: channel=1 (exclusive)] Coding=CCITT
---------------------------------
18:38:08.009438 [INFO] Q931. Line 00/00. Call 0003. Timer 'T301' (180 sec) start in state 'Outgoing Call Proceeding'
18:38:08.009487 [INFO] Q931. Line 00/00. Call 0003. State 'Call Delivered'
18:38:11.012521 [INFO] Q931. Line 00/00. Call 0003. RX 5
DUMP: 08.02.80.03.07.
0x0003 (to orig), MSG=CONNECT:
---------------------------------
18:38:11.012638 [INFO] Q931. Line 00/00. Call 0003. Timer 'T301' stop in state 'Call Delivered'
18:38:11.012692 [INFO] Q931. Line 00/00. Call 0003. State 'Active'
18:38:11.012757 [INFO] Q931. Line 00/00. Call 0003. TX 6
DUMP: 08.02.00.03.0F.
0x0003 (from orig), MSG=CONNECT ACKNOWLEDGE:
---------------------------------
18:38:15.005986 [INFO] Q931. Line 00/00. Call 0003. RX 9
DUMP: 08.02.80.03.45.08.02.80.E6.
0x0003 (to orig), MSG=DISCONNECT:
[cause: Recovery on time expiry (location=user, std=CCITT)]
---------------------------------
18:38:15.006066 [INFO] Q931. Line 00/00. Call 0003. Recv 'Disconnect'. Cause: 'Recovery on time expiry'
18:38:15.006111 [INFO] Q931. Line 00/00. Call 0003. State 'Release Request'
18:38:15.006161 [INFO] Q931. Line 00/00. Call 0003. Timer 'T308' (8 sec) start in state 'Release Request'
18:38:15.006236 [INFO] Q931. Line 00/00. Call 0003. TX 10
DUMP: 08.02.00.03.4D.08.02.80.E6.
0x0003 (from orig), MSG=RELEASE:
[cause: Recovery on time expiry (location=user, std=CCITT)]
---------------------------------
18:38:16.131424 [INFO] Q931. Line 00/00. Call 0003. RX 12
DUMP: 08.02.80.03.7D.08.02.80.E2.14.01.0B.
0x0003 (to orig), MSG=STATUS:
[cause: Message not compatible/not implemented (location=user, std=CCITT)]
[call state: 0x0b]
---------------------------------
18:38:16.308462 [INFO] Q931. Line 00/00. Call 0003. RX 9
DUMP: 08.02.80.03.5A.08.02.80.E6.
0x0003 (to orig), MSG=RELEASE COMPLETE:
[cause: Recovery on time expiry (location=user, std=CCITT)]
---------------------------------
18:38:16.308545 [INFO] Q931. Line 00/00. Call 0003. Recv 'Release complete'. Cause: 'Recovery on time expiry'
18:38:16.308643 [INFO] Q931. Line 00/00. Call 0003. State 'Null'
SMG-1016M. SN: VI1F002865 Software Version: V.3.4.0.1464 M Build: Sep 11 2015 11:37:22
Log stopped at: 18:38:19.396724 27/02/16


Я в замешательстве. Что предположить не знаю. У провайдера своя правда, у меня своя.

Подумал, что вдруг LDK почему-то не отображает CONNECTION ACK у себя в трэйсах. Но нет, вот трэйс входящего вызова при подключении по старой схеме (которую через пару дней провайдер отключит):
016071 COL 012:06 09 St:co idle (00) EVT 5(SETUP) 28 05 A1 04 03 80 90 A3 18 03 A9 83 89 6C 0D 00 83 38 39 30 33 31 39 33 39 36 35 33 70 0B A1 34 39
35 35 33 30 34 30 30 31 (U0)
016071 C>06 09, D1(PROCEED) 06 02 18 03 A9 83 89
016071 COL 012:06 09 St:co idle (00) Ev-I:ring start P1: 0 P2: 0 EVT: 11 <- 12,61
016071 D>06 09, C0 00 68
016071 COL 012:06 09 St:di-dialing(00) Ev-I:disa dgt P1: 4 P2: 0 EVT: 80 <- 12,61
016071 COL 012:06 09 St:di-dialing(00) Ev-I:disa dgt P1: 9 P2: 0 EVT: 80 <- 12,61
016071 COL 012:06 09 St:di-dialing(00) Ev-I:disa dgt P1: 5 P2: 0 EVT: 80 <- 12,61
016071 COL 012:06 09 St:di-dialing(00) Ev-I:disa dgt P1: 5 P2: 0 EVT: 80 <- 12,61
016071 COL 012:06 09 St:di-dialing(00) Ev-I:disa dgt P1: 3 P2: 0 EVT: 80 <- 12,61
016071 COL 012:06 09 St:di-dialing(00) Ev-I:disa dgt P1: A P2: 0 EVT: 80 <- 12,61
016071 COL 012:06 09 St:di-dialing(00) Ev-I:disa dgt P1: 4 P2: 0 EVT: 80 <- 12,61
016071 COL 012:06 09 St:di-dialing(00) Ev-I:disa dgt P1: A P2: 0 EVT: 80 <- 12,61
016071 COL 012:06 09 St:di-dialing(00) Ev-I:disa dgt P1: A P2: 0 EVT: 80 <- 12,61
016071 COL 012:06 09 St:di-dialing(00) Ev-I:disa dgt P1: 1 P2: C EVT: 80 <- 12,61
016071 C>06 09, D0(ALERT) 06 01 18 03 A9 83 89
016071 C>06 09, D2(CONNECT) 01 07
016071 D>06 09, C0 00 68
016072 D>06 09, C0 00 68
016072 COL 012:06 09 St:dd-rng req(02) Ev-I:dummy acd P1:26F3 P2: 0 EVT: 0 <- 12,61
016072 COL 012:06 09 St:dd-rng req(02) Ev-I:dummy acd P1:26AF P2: 3 EVT: 0 <- 12,61
016072 COL 012:06 09 St:dd-rng req(02) Ev-I:dvu play P1: 0 P2: 58 EVT: 0 <- 2,88
016073 COL 012:06 09 St:dd-rng req(02) EVT 3(CONNECT ACK) 01 0F (U8)
016088 COL 012:06 09 St:dd-rng req(02) Ev-I:dv-ply end P1: 0 P2: 58 EVT:126 <- 2,88
016088 D>06 09, C0 00 68
016088 D>06 09, C5 05 01
016088 D>06 09, C5 00 00
016088 D>06 09, C0 00 68
016088 D>06 09, C5 11 01
016088 COL 012:06 09 St:hnt-ring (00) Ev-I:dd rng ack P1: 0 P2: 0 EVT: 82 <- 7,01
016180 COL 012:06 09 St:hnt-ring (00) EVT E(DISCONNECT) 09 45 08 02 80 90 1E 02 82 88 (U10)
016180 C>06 09, DF(RELEASE) 05 4D 08 02 80 90
016180 D>06 09, C1 00 00
016180 D>06 09, C5 00 00
016180 D>06 09, C5 00 00
016180 COL 012:06 09 St:hnt-ring (00) Ev-I:ring stop P1: 0 P2: 0 EVT: 12 <- 12,61
016180 D>06 09, C5 00 00
016184 COL 012:06 09 St:co idle (00) EVT :E0(RLS COMPLETE) 01 5A (U0)
016184 D>06 09, C1 00 00
016184 D>06 09, C5 00 00
016184 D>06 09, C5 00 00
016184 D>06 09, C5 00 00
016187 COL 012:06 09 St:co idle (00) Ev-T:isd rls gd P1: 0 P2: 0 TMR: 9 <- 12,61

Тут все нормально. На CONNECT со стороны LDK АТС провайдера честно отвечает CONNECT ACK.


У меня складывается такое ощущение, что провайдерский шлюз либо посылает CONNECT ACK в каком-то не том формате, что его не понимает LDK. Либо же не посылает его вообще, хотя и пишет об этом в трэйсах.
Или же, этот ACK приходит на LDK слишком поздно (хотя по трэйсам со шлюза ACK уходит сразу же после получения шлюзом CONNECT-a).

В общем что делать не знаю. Провайдер говорит что проблема у нас. Если бы я хотя бы мог поиграть со значением таймера T313, может быть что и получилось, но я так и не нашел где в LDK-60 можно настроить этот параметр.

Похожая проблема описана тут: http://www.artcom.ru/forum/?showtopic=11344&hl=t313, но мне это мало чем поможет.

В общем, прошу помощи, либо как прижать провайдера, либо как поправить настройки на LDK-60.

[ЛыЖник]

Добрый день!
Столкнулся со следующей проблемой.
Имеем ipLDK60, подключена к городу по потоку. Все настроено и работает нормально, НО.
В общем, прошу помощи, либо как прижать провайдера, либо как поправить настройки на LDK-60.

Логика простая. У вас раньше работал поток по меди. Т.е. все было настроено на на стороне LDK. Плате PRI без разницы по какому каналу передавать информацию. Теперь, провайдер меняет канал передачи, ставит какие-то устройства и у вас перестает работать связь. Предложение. Для пробы вернитесь к старому каналу, покажите провайдеру, что на этом канале все работает. А на новом канале не работает. Второй вариант. У вас договор с провайдером. Надо его читать. Пишите претензию на его основе. Вы платите деньги, провайдер вам предоставляет канал передачи. Вот провайдер и доказывает, что это ваша вина. Пусть он делает трассировки и пр. Могу еще добавить. У меня LDK-300 работала по меди через мультиплексор Zelax-1. Провайдер проложил оптику. Поставил оптический мультиплексор Zelax-2. Патчкорд из платы PRI переткнул из одного мультиплексора в другой и АТС продолжила работать.

[korneff]

Да это все понятно.
Сейчас и так все вернулось назад, к старой схеме. Провайдер вроде как согласен запросить помощи у производителя шлюза. Но бодаться можно очень долго. А связь нужна.

[ЛыЖник]

Да это все понятно.
Сейчас и так все вернулось назад, к старой схеме. Провайдер вроде как согласен запросить помощи у производителя шлюза. Но бодаться можно очень долго. А связь нужна.

Согласен. Зачастую такое положение возникает, что у провайдера специалисты узкие, как например в нашем Ростелекоме. Одни ADSL модемами занимаются, но не знают ничего о мультиплексорах. Другой-якобы Е1, как ученая "абизяна". Поток на выходе их мультиплексора есть, но что дальше делать или что делать, если есть ошибки специалист не знает. И проверить не может, и заканчивается знаменитым-"У нас всё в порядке, это на вашей стороне" Вот недавно мне звонили и из моего бывшего отдела связи УВД, и из Ростелекома. Не могут состыковать какую-то систему оповещения и поток Е1. Одни валят на других.