Обрывы входящей связи Опции

[ИгорьS]

День добрый.

В районах стали устанавливать LDK 60 с платами потока.
На данный момент установлены четыре станции.
На всех, одна и та же проблема - произвольный обрыв входящего вызова.
На всех площадках станция провайдера - "АЛС"
Провайдер утверждает, что инициатор обрыва наша сторона.
Трассировка "оборванного" вызова ниже.
Версия LDK 60 - 3.8Al

CODE

=======================================================================
====
Start to Save Trace Data at 12:51:15PM, March 14, 2014
===========================================================================
maint> 03/14/14 TIME: 12:40:00
023118 COL 009:06 02 St:co idle (00) EVT 5 26 05 A1 04 03 80 90 A3 18 03 A9 83 82 1E 02 81 83 6C 0C 20 83 38 34 36 3X 3X 3X 3X 3X 3X 3X 70 06 80 3X 3X 3X 3X 3X (U0)
023118 C>06 02, D1 06 02 18 03 A9 83 82
023118 COL 009:06 02 St:co idle (00) Ev-I:ring start P1: 0 P2: 0 EVT: 11 <- 9,61
023118 D>06 02, C0 00 61
023118 COL 009:06 02 St:di-dialing(00) Ev-I:disa dgt P1: 2 P2: 0 EVT: 80 <- 9,61
023118 COL 009:06 02 St:di-dialing(00) Ev-I:disa dgt P1: 7 P2: 0 EVT: 80 <- 9,61
023118 COL 009:06 02 St:di-dialing(00) Ev-I:disa dgt P1: X P2: 0 EVT: 80 <- 9,61
023118 COL 009:06 02 St:di-dialing(00) Ev-I:disa dgt P1: X P2: 0 EVT: 80 <- 9,61
023118 COL 009:06 02 St:di-dialing(00) Ev-I:disa dgt P1: X P2: C EVT: 80 <- 9,61
023118 COL 009:06 02 St:dd-rng req(00) Ev-I:dummy acd P1:26F3 P2: 0 EVT: 0 <- 9,61
023118 COL 009:06 02 St:dd-rng req(00) Ev-I:dummy acd P1:26AF P2: 1 EVT: 0 <- 9,61
023118 COL 009:06 02 St:dd-rng req(00) Ev-I:dummy acd P1:26F3 P2: 0 EVT: 0 <- 9,61
023118 COL 009:06 02 St:dd-rng req(00) Ev-I:dd rng ack P1: 0 P2: 0 EVT: 82 <- 8,03
023118 D>06 02, C0 00 61
023118 D>06 02, C5 11 01
023118 C>06 02, D0 06 01 18 03 A9 83 82
023270 COL 009:06 02 St:dd-wt ans (00) Ev-I:seize req P1: 6 P2: 0 EVT: 81 <- 8,03
023270 D>06 02, C5 00 00
023270 D>06 02, C5 00 00
023270 C>06 02, D2 0F 07 4C 0C 21 81 38 34 36 37 36 3X 3X 3X 3X 3X
023270 D>06 02, C0 00 61
023270 COL 009:06 02 St:ds-talk (00) Ev-I:dummy acd P1:26F3 P2: 0 EVT: 0 <- 9,61
023270 COL 009:06 02 St:ds-talk (00) Ev-I:dummy acd P1:26D6 P2: 0 EVT: 0 <- 9,61
023322 COL 009:06 02 St:ds-talk (00) EVT F 05 4D 08 02 81 90 (U8)
023322 C>06 02, E0 05 5A 08 02 81 90
023322 D>06 02, C1 00 00
023322 D>06 02, C5 00 00
023325 COL 009:06 02 St:ds-talk (00) Ev-T:isd rls gd P1: 0 P2: 0 TMR: 9 <- 9,61
023325 D>06 02, C5 00 00


===========================================================================
Stop Saving Trace Data at 12:52:07PM, March 14, 2014
===========================================================================

Собираю выезжать на местА сам, но вдруг кто с подобным сталкивался.

[vitalii]

раньше LDK вы стыковали по потоку? можете ещё и версию поднять. какой- нибудь прибор, иммитирующий PRI имеете?

[harris]

Собираю выезжать на местА сам, но вдруг кто с подобным сталкивался.

Сталкивались..., и не раз. Это самое обычные дело - когда провайдер просто не хочет (или не может) разбираться со своими проблемами. У провайдера всегда виновата оконечная сторона, а он - во всем белом...
На представленной трассировке:
- абонент LDK ответил на входящий вызов, станция отправила провайдеру сообщение Connect. В ответ станция должна получить Connect_Ack, но провайдер не подверждает соединение (нету Connect_Ack от провайдера)
- вместо этого провайдер присылает RELEASE (отбой), т.е. сам провайдер разъединяет вызов, а вовсе не LDK.

Нехай провайдер внимательнее посмотрит трассировки на своей стороне!

[harris]

После Connect'а LDK должна получить Connect_Ack в течении 4 сек, в противном случае LDK должна отбить вызов посылкой Disconnect.
На трассировке, правда, не видно отправки Disconnect от LDK, а вот от провайдера приходит Release.
Пусть провайдер разберется, почему его станция (АЛС ??) не выдает Connect_Acknowledge.

Если провайдер реально получил на своей стороне Disconnect (допустим, что LDK не отобразила это в трассировке),
то причина - только в том, что от провайдера нет Connect_Ack.

Если же Disconnect от LDK не было, то все равно нужно смотреть на стороне АЛС:
а) почему не ответили сообщением Conneсt_Ack
б) почему разъединили вызов посылкой Release (с причиной №16 - Нормальное завершение вызова).

[ИгорьS]

Сталкивались..., и не раз. Это самое обычные дело - когда провайдер просто не хочет (или не может) разбираться со своими проблемами. У провайдера всегда виновата оконечная сторона, а он - во всем белом...
На представленной трассировке:
- абонент LDK ответил на входящий вызов, станция отправила провайдеру сообщение Connect. В ответ станция должна получить Connect_Ack, но провайдер не подверждает соединение (нету Connect_Ack от провайдера)
- вместо этого провайдер присылает RELEASE (отбой), т.е. сам провайдер разъединяет вызов, а вовсе не LDK.

Нехай провайдер внимательнее посмотрит трассировки на своей стороне!

День добрый Игорь.
Не прошу и не настаиваю, но может пояснишь...(думаю данная информация будет интересна не только мне).
Не могу до конца понять трассировку снимаемую со станций LG.

Попробую разобрать(в общих чертах) трассировку мною выложенную.

023118 COL 009:06 02 St:co idle (00) EVT 5 26 05 A1 04 03 80 90 A3 18 03 A9 83 82 1E 02 81 83 6C 0C 20 83 38 34 36 3X 3X 3X 3X 3X 3X 3X 70 06 80 3X 3X 3X 3X 3X (U0)

Входящий (по линии 9) SETUP от прова
Что за цифры 06 02 ?
(00) EVT 5 26- это элемент CR ?
MT 05 A1
04 03 80 90 A3 18 03 A9 83 82 - голосовые настройки
1E 02 81 83 - прогресс индикатор
6C 0C 20 83 38 34 36 3X 3X 3X 3X 3X 3X 3X -вызывающий абонент
70 06 80 3X 3X 3X 3X 3X - вызываемый абонент

023118 C>06 02, D1 06 02 18 03 A9 83 82 - call proceeding

023118 C>06 02, D0 06 01 18 03 A9 83 82 - allerting от станции

023270 C>06 02, D2 0F 07 4C 0C 21 81 38 34 36 37 36 3X 3X 3X 3X 3X -connect от станции

023322 COL 009:06 02 St:ds-talk (00) EVT F 05 4D 08 02 81 90 (U8) -release от прова cause 90 (нормальное разъединение)

023322 C>06 02, E0 05 5A 08 02 81 90 - release complete от станции cause 90

[harris]

06 02 ?? слот 6 , канал 2 - это относится к внутр. трассировке платы, а не к данным, передаваемым по ISDN.
Вместо улыбающейся рожи - D5 (внутр. событие, получение входящего Setup'а).
CR - Call Reference?? Нет, насколько я понимаю, -это какой-то внутр. CR, не тот, который реально посылаются в линию.
ИМХО, для нас это не имеет значения. Важно то, что посылается в линию, т.е. начиная с 3-го байта.
У нас нет никакого описания по этим полям внутр. событий, мы также как и вы просто разбираем ISDN-сообщения по стандарту Q.931 (или ETSI).
Т.е. здесь в трассировке есть как данные, действительно относящиеся к EDSS1 (передаваемые по ISDN линии), так и к внутренние события. Это все-таки трассировка платы, а не самой линии. Там есть нюансики, но чтобы понять суть происходящего эта трассировка очень даже вполне годится.

[ИгорьS]

06 02 ?? слот 6 , канал 2 - это относится к внутр. трассировке платы, а не к данным, передаваемым по ISDN.
Вместо улыбающейся рожи - D5 (внутр. событие, получение входящего Setup'а).
CR - Call Reference?? Нет, насколько я понимаю, -это какой-то внутр. CR, не тот, который реально посылаются в линию.
ИМХО, для нас это не имеет значения. Важно то, что посылается в линию, т.е. начиная с 3-го байта.
У нас нет никакого описания по этим полям внутр. событий, мы также как и вы просто разбираем ISDN-сообщения по стандарту Q.931 (или ETSI).
Т.е. здесь в трассировке есть как данные, действительно относящиеся к EDSS1 (передаваемые по ISDN линии), так и к внутренние события. Это все-таки трассировка платы, а не самой линии. Там есть нюансики, но чтобы понять суть происходящего эта трассировка очень даже вполне годится.

Так, более менее проясняется.
Но основное правильно?
COL XXX и т.д. запросы от прова
С>XX XX, и т.д. ответы станции
D>XX XX, и т.д. - это к чему отнести?

[harris]

Так, более менее проясняется.
Но основное правильно?
COL XXX и т.д. запросы от прова
С>XX XX, и т.д. ответы станции
D>XX XX, и т.д. - это к чему отнести?

D>XX XX, и т.д. - это тоже внутр. команда для платы на подключение/отключение канала к внутренней TDM шине (в коммутационной матрице), на подключение к опред. тайм-слоту внутри станции (MOH, например) и пр.
Еще раз повторю, это уже не имеет особого значения при трассировке потока, нужно ведь смотреть сигнальные сообщения, а не то, что именно в данные момент станция включает внутри себя... Так??
У нас нет описания этих команд, это есть только у корейцев... Мы может только пытаться отгадывать... опытным путем.

Ну так что там говорит провайдер??

[ИгорьS]

раньше LDK вы стыковали по потоку? можете ещё и версию поднять. какой- нибудь прибор, иммитирующий PRI имеете?

Да - раньше стыковал.
Имхо не в версии станции дело.
А что за прибор Вы имеете в виду?

[harris]

Да - раньше стыковал.
Имхо не в версии станции дело.
А что за прибор Вы имеете в виду?

Он, наверное, имеет в виду анализатор потока типа "Авроры".

[vitalii]

Да - раньше стыковал.
Имхо не в версии станции дело.
А что за прибор Вы имеете в виду?

чтобы включиться вместо провайдера и доказать ему правильность ваших настроек. (AETRA)

[ИгорьS]

Ну так что там говорит провайдер??

Говорит, что дает setup, видит call proceeding, alerting, conect- отвечает conect_ask и получает disconect.


Предоставил трейс вызова(не выше описаного, но тоже с обрывом), правда в собственном формате .prt и прогу для чтения.

В проге действительно отображены все выше перечисленные команды(и если развернуть менюшку команды, то можно увидеть IE и HEX).
Только вот информационный элемент CONNECT от нас присутствует, а информационный элемент команды CONNECT ACKNOWLEDGE - <отсутствуют> - так и написано.
А далее команда DISCONECT от нас c ie 80 E6- истечение таймера ответа я так понимаю.
После от прова RELEASE с ie 81 90
ну и дальнейшее завершение.

Завтра попробуем снять двусторонние трейсы, и "бодать..." разбираться дальше.

[harris]

Говорит, что дает setup, видит call proceeding, alerting, conect- отвечает conect_ask и получает disconect.
Ни чего нового

Предоставил трейс вызова(не выше описаного, но тоже с обрывом), правда в собственном формате .prt и прогу для чтения.

В проге действительно отображены все выше перечисленные команды(и если развернуть менюшку команды, то можно увидеть IE и HEX).
Только вот информационный элемент CONNECT от нас присутствует, а информационный элемент команды CONNECT ACKNOWLEDGE - <отсутствуют> - так и написано.
А далее команда DISCONECT от нас c ie 80 E6- истечение таймера ответа я так понимаю.
После от прова RELEASE с ie 81 90
ну и дальнейшее завершение.

Завтра попробуем снять двусторонние трейсы, и "бодать..." разбираться дальше.

Ага, тогда:
- значит LDK все-таки послал сообщение Disconnect c причиной #102 (Recovery on timer expiry). Это правильно, т.к. не было ответа на Connect. Ну, и Release от провадйера - тоже правильно, коль он получил Disconnect.
Но Disconnect он получил заслуженно.
Провайдер должен разобраться с Connect_Ack.
Это ж ISDN линия, а не VOIP/H.323, где Connect_Ack является необязательным.
- вот только непонятно, почему сообщение Disconnect не попало в трассировку LDK. Ок, завтра, если получится, попробуем смоделировать на тестовой станции...

[ИгорьS]

Ага, тогда:
- значит LDK все-таки послал сообщение Disconnect c причиной #102 (Recovery on timer expiry). Это правильно, т.к. не было ответа на Connect. Ну, и Release от провадйера - тоже правильно, коль он получил Disconnect.
Но Disconnect он получил заслуженно.
Провайдер должен разобраться с Connect_Ack.
Это ж ISDN линия, а не VOIP/H.323, где Connect_Ack является необязательным.
- вот только непонятно, почему сообщение Disconnect не попало в трассировку LDK. Ок, завтра, если получится, попробуем смоделировать на тестовой станции...

PS: По провайдерской трассировке происходило следующее.

SETUP - от прова- с данными
CALL PROCEEDING - от LG - с данными
ALERTING - от LG - с данными
CONNECT -от LG - с данными
CONNECT ACKNOWLEDGE - от прова - пусто
DISCONECT - от LG - 80 E6 (Recovery on time expiry)
RELEASE - от прова - 81 90
CONNECT ACKNOWLEDGE - от прова- пусто
RELEASE - от прова - 81 90
STATUS - от LG 80 Е2 (Message not compatible with call state or not implemented)
RELEASE - от прова - 81 90
RELEASE COMPLETE - от LG - 81 90

[harris]

PS: По провайдерской трассировке происходило следующее.

SETUP - от прова- с данными
CALL PROCEEDING - от LG - с данными
ALERTING - от LG - с данными
CONNECT -от LG - с данными
CONNECT ACKNOWLEDGE - от прова - пусто
DISCONECT - от LG - 80 E6 (Recovery on time expiry)
RELEASE - от прова - 81 90
CONNECT ACKNOWLEDGE - от прова- пусто
RELEASE - от прова - 81 90
STATUS - от LG 80 Е2 (Message not compatible with call state or not implemented)
RELEASE - от прова - 81 90
RELEASE COMPLETE - от LG - 81 90

Мдя.. Так по этой трассировке непонятно, почему LG ответила Disconnect'ом, если она получила Connect_Ack.
Пустой Connect_Ack - это нормально, там и не может быть ничего кроме IE "Display" (мало кто использует).
А пришлите эту трассировку, там можно разобраться с временными метками??
Через сколько секунд после Connect приходит Connect_Ack??

[ИгорьS]

Мдя.. Так по этой трассировке непонятно, почему LG ответила Disconnect'ом, если она получила Connect_Ack.
Пустой Connect_Ack - это нормально, там и не может быть ничего кроме IE "Display" (мало кто использует).
А пришлите эту трассировку, там можно разобраться с временными метками??
Через сколько секунд после Connect приходит Connect_Ack??

Отправил на garry@lgericsson.com

[harris]

Отправил на garry@lgericsson.com

Нет, так не дойдет. У нас сейчас другой почтовый сервер: garry@ericsson-lg.com (временно, через пару недель опять будет изменен на новый).

[ИгорьS]

Нет, так не дойдет. У нас сейчас другой почтовый сервер: garry@ericsson-lg.com (временно, через пару недель опять будет изменен на новый).

Отправил, в ближайшее время будем снимать трассировку с обоих сторон одновременно.

[ИгорьS]

День добрый коллеги.

Отпишусь о результатах изысканий.
С помощью многоуважаемого Игоря (aka Harris), была выяснена причина обрывов входящих вызовов.

Причина - не своевременный приход ответа Connect_ask станции прова, на сообщение Connect.

В рекомендациях таймер T313 (выдержка времени между посылкой сообщения CONNECT и приемом сообщения CONNECT ACKNOWLEDGE) составляет 4 секунды.
Если в течении данного времени на user сторону не поступает CONNECT ACKNOWLEDGE, сторона посылаемая CONNECT - должна ответить DISCONECTом, что и происходит.

В трассировке (снятой с платы) видно, что в случае успешных вызовов CONNECT ACKNOWLEDGE приходит в течении данного таймера.
В "оборванном" вызове(это не видно с трассировки MPB) - так же CONNECT ACKNOWLEDGE пришел - но через 5 сек , перед этим LG уже отправила DISCONECT с причиной 80Е6 (Recovery on time expiry).
Далее следует разрушение канала и освобождение линии.

[ЛыЖник]

День добрый коллеги.

Отпишусь о результатах изысканий.
С помощью многоуважаемого Игоря (aka Harris), была выяснена причина обрывов входящих вызовов.

Причина - не своевременный приход ответа Connect_ask станции прова, на сообщение Connect.

В рекомендациях таймер T313 (выдержка времени между посылкой сообщения CONNECT и приемом сообщения CONNECT ACKNOWLEDGE) составляет 4 секунды.
Если в течении данного времени на user сторону не поступает CONNECT ACKNOWLEDGE, сторона посылаемая CONNECT - должна ответить DISCONECTом, что и происходит.

В трассировке (снятой с платы) видно, что в случае успешных вызовов CONNECT ACKNOWLEDGE приходит в течении данного таймера.
В "оборванном" вызове(это не видно с трассировки MPB) - так же CONNECT ACKNOWLEDGE пришел - но через 5 сек , перед этим LG уже отправила DISCONECT с причиной 80Е6 (Recovery on time expiry).
Далее следует разрушение канала и освобождение линии.

Как всё запущено... Жесть!