Обрывы входящей связи |
Здравствуйте, гость ( Вход | Регистрация )
Обрывы входящей связи |
17.3.2014, 12:20
Сообщение
#1
|
|
Ветеран форума Группа: Участники Сообщений: 658 Регистрация: 16.1.2010 Из: г.Самара Пользователь №: 14209 |
День добрый.
В районах стали устанавливать 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 =========================================================================== Собираю выезжать на местА сам, но вдруг кто с подобным сталкивался. |
|
|
17.3.2014, 12:27
Сообщение
#2
|
|
Ветеран форума Группа: Участники Сообщений: 2500 Регистрация: 6.3.2008 Из: Кишинёв Пользователь №: 9703 |
раньше LDK вы стыковали по потоку? можете ещё и версию поднять. какой- нибудь прибор, иммитирующий PRI имеете?
|
|
|
17.3.2014, 12:46
Сообщение
#3
|
|
ГУРУ Группа: Участники Сообщений: 12388 Регистрация: 23.11.2006 Из: Москва Пользователь №: 146 |
Собираю выезжать на местА сам, но вдруг кто с подобным сталкивался. Сталкивались..., и не раз. Это самое обычные дело - когда провайдер просто не хочет (или не может) разбираться со своими проблемами. У провайдера всегда виновата оконечная сторона, а он - во всем белом... На представленной трассировке: - абонент LDK ответил на входящий вызов, станция отправила провайдеру сообщение Connect. В ответ станция должна получить Connect_Ack, но провайдер не подверждает соединение (нету Connect_Ack от провайдера) - вместо этого провайдер присылает RELEASE (отбой), т.е. сам провайдер разъединяет вызов, а вовсе не LDK. Нехай провайдер внимательнее посмотрит трассировки на своей стороне! -------------------- Аксиома Коула: Общая сумма разума на планете - величина постоянная, а население растет ...
|
|
|
17.3.2014, 13:05
Сообщение
#4
|
|
ГУРУ Группа: Участники Сообщений: 12388 Регистрация: 23.11.2006 Из: Москва Пользователь №: 146 |
После Connect'а LDK должна получить Connect_Ack в течении 4 сек, в противном случае LDK должна отбить вызов посылкой Disconnect.
На трассировке, правда, не видно отправки Disconnect от LDK, а вот от провайдера приходит Release. Пусть провайдер разберется, почему его станция (АЛС ??) не выдает Connect_Acknowledge. Если провайдер реально получил на своей стороне Disconnect (допустим, что LDK не отобразила это в трассировке), то причина - только в том, что от провайдера нет Connect_Ack. Если же Disconnect от LDK не было, то все равно нужно смотреть на стороне АЛС: а) почему не ответили сообщением Conneсt_Ack б) почему разъединили вызов посылкой Release (с причиной №16 - Нормальное завершение вызова). -------------------- Аксиома Коула: Общая сумма разума на планете - величина постоянная, а население растет ...
|
|
|
17.3.2014, 16:39
Сообщение
#5
|
|
Ветеран форума Группа: Участники Сообщений: 658 Регистрация: 16.1.2010 Из: г.Самара Пользователь №: 14209 |
Сталкивались..., и не раз. Это самое обычные дело - когда провайдер просто не хочет (или не может) разбираться со своими проблемами. У провайдера всегда виновата оконечная сторона, а он - во всем белом... На представленной трассировке: - абонент 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 |
|
|
17.3.2014, 17:01
Сообщение
#6
|
|
ГУРУ Группа: Участники Сообщений: 12388 Регистрация: 23.11.2006 Из: Москва Пользователь №: 146 |
06 02 ?? слот 6 , канал 2 - это относится к внутр. трассировке платы, а не к данным, передаваемым по ISDN.
Вместо улыбающейся рожи - D5 (внутр. событие, получение входящего Setup'а). CR - Call Reference?? Нет, насколько я понимаю, -это какой-то внутр. CR, не тот, который реально посылаются в линию. ИМХО, для нас это не имеет значения. Важно то, что посылается в линию, т.е. начиная с 3-го байта. У нас нет никакого описания по этим полям внутр. событий, мы также как и вы просто разбираем ISDN-сообщения по стандарту Q.931 (или ETSI). Т.е. здесь в трассировке есть как данные, действительно относящиеся к EDSS1 (передаваемые по ISDN линии), так и к внутренние события. Это все-таки трассировка платы, а не самой линии. Там есть нюансики, но чтобы понять суть происходящего эта трассировка очень даже вполне годится. -------------------- Аксиома Коула: Общая сумма разума на планете - величина постоянная, а население растет ...
|
|
|
17.3.2014, 17:41
Сообщение
#7
|
|
Ветеран форума Группа: Участники Сообщений: 658 Регистрация: 16.1.2010 Из: г.Самара Пользователь №: 14209 |
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, и т.д. - это к чему отнести? |
|
|
17.3.2014, 17:54
Сообщение
#8
|
|
ГУРУ Группа: Участники Сообщений: 12388 Регистрация: 23.11.2006 Из: Москва Пользователь №: 146 |
Так, более менее проясняется. Но основное правильно? COL XXX и т.д. запросы от прова С>XX XX, и т.д. ответы станции D>XX XX, и т.д. - это к чему отнести? D>XX XX, и т.д. - это тоже внутр. команда для платы на подключение/отключение канала к внутренней TDM шине (в коммутационной матрице), на подключение к опред. тайм-слоту внутри станции (MOH, например) и пр. Еще раз повторю, это уже не имеет особого значения при трассировке потока, нужно ведь смотреть сигнальные сообщения, а не то, что именно в данные момент станция включает внутри себя... Так?? У нас нет описания этих команд, это есть только у корейцев... Мы может только пытаться отгадывать... опытным путем. Ну так что там говорит провайдер?? -------------------- Аксиома Коула: Общая сумма разума на планете - величина постоянная, а население растет ...
|
|
|
17.3.2014, 17:54
Сообщение
#9
|
|
Ветеран форума Группа: Участники Сообщений: 658 Регистрация: 16.1.2010 Из: г.Самара Пользователь №: 14209 |
|
|
|
17.3.2014, 17:56
Сообщение
#10
|
|
ГУРУ Группа: Участники Сообщений: 12388 Регистрация: 23.11.2006 Из: Москва Пользователь №: 146 |
Да - раньше стыковал. Имхо не в версии станции дело. А что за прибор Вы имеете в виду? Он, наверное, имеет в виду анализатор потока типа "Авроры". -------------------- Аксиома Коула: Общая сумма разума на планете - величина постоянная, а население растет ...
|
|
|
17.3.2014, 18:01
Сообщение
#11
|
|
Ветеран форума Группа: Участники Сообщений: 2500 Регистрация: 6.3.2008 Из: Кишинёв Пользователь №: 9703 |
|
|
|
17.3.2014, 19:13
Сообщение
#12
|
|
Ветеран форума Группа: Участники Сообщений: 658 Регистрация: 16.1.2010 Из: г.Самара Пользователь №: 14209 |
Ну так что там говорит провайдер?? Говорит, что дает setup, видит call proceeding, alerting, conect- отвечает conect_ask и получает disconect. Предоставил трейс вызова(не выше описаного, но тоже с обрывом), правда в собственном формате .prt и прогу для чтения. В проге действительно отображены все выше перечисленные команды(и если развернуть менюшку команды, то можно увидеть IE и HEX). Только вот информационный элемент CONNECT от нас присутствует, а информационный элемент команды CONNECT ACKNOWLEDGE - <отсутствуют> - так и написано. А далее команда DISCONECT от нас c ie 80 E6- истечение таймера ответа я так понимаю. После от прова RELEASE с ie 81 90 ну и дальнейшее завершение. Завтра попробуем снять двусторонние трейсы, и "бодать..." разбираться дальше. |
|
|
17.3.2014, 19:37
Сообщение
#13
|
|
ГУРУ Группа: Участники Сообщений: 12388 Регистрация: 23.11.2006 Из: Москва Пользователь №: 146 |
Говорит, что дает 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. Ок, завтра, если получится, попробуем смоделировать на тестовой станции... -------------------- Аксиома Коула: Общая сумма разума на планете - величина постоянная, а население растет ...
|
|
|
17.3.2014, 20:07
Сообщение
#14
|
|
Ветеран форума Группа: Участники Сообщений: 658 Регистрация: 16.1.2010 Из: г.Самара Пользователь №: 14209 |
Ага, тогда: - значит 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 |
|
|
17.3.2014, 20:48
Сообщение
#15
|
|
ГУРУ Группа: Участники Сообщений: 12388 Регистрация: 23.11.2006 Из: Москва Пользователь №: 146 |
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?? -------------------- Аксиома Коула: Общая сумма разума на планете - величина постоянная, а население растет ...
|
|
|
18.3.2014, 10:03
Сообщение
#16
|
|
Ветеран форума Группа: Участники Сообщений: 658 Регистрация: 16.1.2010 Из: г.Самара Пользователь №: 14209 |
Мдя.. Так по этой трассировке непонятно, почему LG ответила Disconnect'ом, если она получила Connect_Ack. Пустой Connect_Ack - это нормально, там и не может быть ничего кроме IE "Display" (мало кто использует). А пришлите эту трассировку, там можно разобраться с временными метками?? Через сколько секунд после Connect приходит Connect_Ack?? Отправил на garry@lgericsson.com |
|
|
18.3.2014, 10:06
Сообщение
#17
|
|
ГУРУ Группа: Участники Сообщений: 12388 Регистрация: 23.11.2006 Из: Москва Пользователь №: 146 |
Отправил на garry@lgericsson.com Нет, так не дойдет. У нас сейчас другой почтовый сервер: garry@ericsson-lg.com (временно, через пару недель опять будет изменен на новый). -------------------- Аксиома Коула: Общая сумма разума на планете - величина постоянная, а население растет ...
|
|
|
18.3.2014, 10:16
Сообщение
#18
|
|
Ветеран форума Группа: Участники Сообщений: 658 Регистрация: 16.1.2010 Из: г.Самара Пользователь №: 14209 |
|
|
|
19.3.2014, 15:46
Сообщение
#19
|
|
Ветеран форума Группа: Участники Сообщений: 658 Регистрация: 16.1.2010 Из: г.Самара Пользователь №: 14209 |
День добрый коллеги.
Отпишусь о результатах изысканий. С помощью многоуважаемого Игоря (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). Далее следует разрушение канала и освобождение линии. |
|
|
20.3.2014, 8:33
Сообщение
#20
|
|
Ветеран Группа: Участники Сообщений: 4439 Регистрация: 4.12.2006 Из: г.Ульяновск Пользователь №: 186 |
День добрый коллеги. Отпишусь о результатах изысканий. С помощью многоуважаемого Игоря (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). Далее следует разрушение канала и освобождение линии. Как всё запущено... Жесть! -------------------- В любой вещи на свете есть изъян. В Ламборджини, например, тяжело педали валенками нажимать.
|
|
|
Текстовая версия | Сейчас: 3.5.2024, 1:05 |