Станция новая, LDK-100, процессор 3.8, соединена по VOIB с другими двумя LDK, общий номерной план.
Проблема в том, что любой разговор по VOIB-ному транку обывается через 3 минуты.
Независимо от того, входящий звонок или исходящий.

Трассировка звонка:


115618 H:T560+T560 ==> 262 (G116774 COL 088:15 04 St:co idle (00) Ev-I:seize req P1: A P2: 0 EVT: 15 <- 1,01
116774 C>15 04, F5 1A A1 04 03 80 90 A3 31 05 80 C0 A8 34 9B 6C 05 01 81 34 30 30 70 04 80 31 30 30
06/09/09 TIME: 13:31:00
116784 COL 088:15 04 St:wt sz rsp (00) VOIP EVT: evt_no=D1 p1=00 p2=00
116784 COL 088:15 04 St:wt sz rsp (00) Ev-I:pp sz ack P1: 0 P2: 0 EVT: 16 <- 88,44
116784 D>15 04, C0 00 109
116785 H:T560+ 265 ==> 000 (G:00-46)
116788 COL 088:15 04 St:dialing (00) VOIP EVT: evt_no=D0 p1=00 p2=00
117235 COL 088:15 04 St:dialing (00) EVT : D2 07 4C 05 21 80 31 30 30 (U0)
117235 H:T560+ 000 ==> 265 (G:00-26)
117235 D>15 04, C0 00 109
117235 D>15 04, D3 00 109
117236 COL 088:15 04 St:talk (00) Ev-I:dummy acd P1:26D6 P2: 0 EVT: 0 <- 88,44
117236 H:T560+ 265 ==> 000 (G:00-46)
06/09/09 TIME: 13:32:00
06/09/09 TIME: 13:33:00
06/09/09 TIME: 13:34:00
118981 COL 088:15 04 St:talk (00) EVT : DF 04 08 02 80 90 (U0)
118981 D>15 04, C1 00 00
118981 D>15 04, C5 00 00
118981 H:T560+T560 ==> 265 (G:00-00)
118981 H:T560+T560 ==> 265 (G:00-00)
118981 D>15 04, C5 00 00
118981 H:T560+T560 ==> 265 (G:00-00)
118981 COL 088:15 04 St:talk (00) EVT : E2 04 08 02 80 90 (U0)
118982 D>15 04, C5 00 00
118982 H:T560+T560 ==> 265 (G:00-00)
118982 COL 088:15 04 St:talk (00) Ev-T:isd rls gd P1: 0 P2: 0 TMR: 9 <- 88,44
118983 D>15 04, C5 00 00
118983 H:T560+T560 ==> 265 (G:00-00)
118983 H:T560+T560 ==> 265 (G:00-00)

Понимаю, что Н.323 отличается от PRI, но должно же быть сообщениe DISCONNECT (код 45).

Что делать?

В H.323 вместо сообщения Disconnect используется сообщение Release Complete, и в вашем случае станция получает его из сети.
ИМХО, разбираться нужно с сетью и с оборудованием на другом конце...
Была такого рода проблема при стыковке LDK c Панасоником по VoIP.
Поищите по форуму.

ОК, спасибо, поищу. Там схема подключения такая:
LDK-100 - тоннель VPN - CISCO - LDK-300

В данном случае трассировка снималась на LDK-300, звонок исходящий по отношению к ней самой.
То есть RELEASE приходит от LDK-100...
Админы CISCO говорят, что у них ничего нигде не блокируется, пакеты не фильтруются (если подозревать неправильный обмен пакетами RTP), никаких 3-х минутных интервалов не предполагается.

А может Release приходит от Cisco, а не от LDK-100...
Посмотрите, что происходит на LDK-100.

Я, если честно, не очень понимаю, как CISCO участвует в формировании Н.323.
Не может быть так, что это чисто транспортный уровень?
Тупо пересылает пакеты, знает, что RTP, а начинка понятна уже только LDK.

Попытаюсь снять трассировку на LDK-100 при первой возможности.

Удалось снять трассировку звонка со стороны LDK-100.

1123084 COL 009:05 01 St:co idle (00) Ev-I:seize req P1: A P2: 0 EVT: 15 <- 1,01
1123084 C>05 01, F5 1D A1 04 03 80 90 A3 31 05 80 C0 A8 32 9B 6C 05 01 81 32 30 30 70 04 80 34 31 37 50 01 00
1123095 COL 009:05 01 St:wt sz rsp (00) VOIP EVT: evt_no=D1 p1=00 p2=00
1123095 COL 009:05 01 St:wt sz rsp (00) Ev-I:pp sz ack P1: 0 P2: 0 EVT: 16 <- 9,44
1123095 D>05 01, C0 00 2C
1123097 COL 009:05 01 St:dialing (00) VOIP EVT: evt_no=D0 p1=00 p2=00
1123123 COL 009:05 01 St:dialing (00) VOIP EVT: evt_no=D2 p1=00 p2=00
1123123 D>05 01, C0 00 2C
1123123 COL 009:05 01 St:talk (00) Ev-I:dummy acd P1:26D6 P2: 0 EVT: 0 <- 9,44
08/11/09 TIME: 10:56:00
08/11/09 TIME: 10:57:00
08/11/09 TIME: 10:58:00
1124869 COL 009:05 01 St:talk (00) EVT : DF 04 08 02 80 90 (U0)
1124869 D>05 01, C1 00 00
1124869 D>05 01, C5 00 00
1124869 COL 009:05 01 St:talk (00) EVT :E2 04 08 02 80 90 (U0)
1124870 COL 009:05 01 St:talk (00) Ev-T:isd rls gd P1: 0 P2: 0 TMR: 9 <- 9,44
1124870 D>05 01, C5 00 00

На первый взгляд, выглядит так же, как со стороны LDK-300...

Системный администратор на объекте смотрел снифером пакеты. Лог обмена странный какой-то.

Там присутствуют только пакеты UDP и TCP между платами VOIB. Никакого RTP.

LDK-100 тоже получает Release из сети (а не посылает его). Так что она не является инициатором разъединения.

Вот и получается: обе станции получают релиз из сети...То есть что-то в оборудовании CISCO, на котором сетка сделана...
Админ CISCO жестко отрицает возможность проблем со стороны сети. Тупик.

А у них работа такая - всегда отрицать все претензии к работе сети.

а RTP и передаётся в пакетах UDP:)

Тем более...Если эта информация внутри UDP пакета...Вообще не знаю, как выяснять проблему (((

лог обмена, собранный снифером, в студию!

Решили использовать другой снифер, который позволяет видеть содержимое пакетов. Жду лог.

Вообще там сеть из нескольких АТС. Все они связаны через VPN-тоннели, одна станция - главная транзитная.
На днях я сделала, чтобы периферийные станции общались по VOIP без участия транзитной, и теперь там проблема 3-х минутных разрывов отсутствует...
Получается, что проблема есть, когда задействована именно транзитная станция.

Возможно, конечно, что там есть некие особенности топологии сети, которые объясняют это, и которые известны только админу, но теперь я не исключаю и неисправность платы VOIB...

модели плат VOIP и прошивки на ней, какие стоят на периферийных и транзитной станциях?

Дорогая Инночка, я когда софт на VOIP плате поменял на рекомендуемый, у меня, практически плата перестала отваливаться, а ты знаешь, что у меня атмосферный лазер на три километра. Как по линейной связи заработало.

И кодирование на атмосферной оптике свое, тоже инкапсуляция идет.

а VOIP плата при разрыве разговора перегражаеться ? я это к тому , что у меня тоже такое подобное было проблема была в сети открыты были какие то порты ( сейчас не помню надо у наших программеров спрашивать)

Итак, версии софта:
транзитная станция (LDK-300) - плата VOIBE 2.1D
две оконечные (LDK -100) - платы VOIB 4.3 A

При обрыве плата НЕ перезапускается.

Цитирую :
Вопрос был в форуме:
Имею станнцию LDK-600 прошивка 3.7 CE, есть плата VOIB 4.2Bd которая периодически зависает, имеет ли смысл её перепрошить?

Ответ Harris-а:
Хуже не будет!!! Последняя версия для платы VOIB - 4.3Ae - выложена здесь на сайте.

Только плата у меня не VOIB, а VOIBE
Там другие версии.

поставьте VOIBE B.2Ad
http://www.artcom.ru/download/Gs30HB2Ad.rom

ОК, сделаю, как только будет возможность.

Сейчас на объекте, перепрошила плату VOIBE на транзитной станции, не помогло.
Картина та же. Любое соединение через плату VOIBE разрывается через 3 минуты.
Периферийные станции общаются между собой нормально.

снифер в студию

Вообще там километровый лог, конечно. Но предположительный момент аномального дисконнекта вот он:


Нажмите для просмотра прикрепленного файла

Поясню: 192.168.50.155 - IP платы VOIBE на транзитной станции, 192.168.52.155 - IP VOIB периферийной.

Кстати, там ещё проблема с PCAdmin, и ситуация похожа - не работает подключение из той сети, где находится транзитная LDK-300, на сети, где периферийные LDK-100. А вот между периферийными сетями PCAdmin-ы работают очень хорошо.

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

что то странно - не видно RTP от 55.155 на 50.155
лучше лог сохранить в файл (а не картинку)
А слышимость в этом звонке была в оба направления?

Слышимость, кстати, отличная в обе стороны. Насчет RTP согласна. Обычно он отображается явно.

Ещё не совсем понимаю касательно снифера. Каким образом я вообще могу увидеть участие в процессе СISCO?
Источник и назначение - наши станционные платы VOIB. Между ними обмен пакетами. И всё.
Что там мутит CISCO, прогоняя через себя информацию, не видно.

давайте файл снифа

Файл огромный, около 4 Мб, не знаю, как такой прицепить.

положите на http://webfile.ru/

ОК, положу. Сейчас на объекте вообще началась катастрофа: станция подвисает периодически.
Источник проблем - сеть.
Выдернули из процессора патчкорд, вся станция перестала зависать, теперь зависает плата VOIB.
Отключаю от сети - всё хорошо. Как только включаю обратно - рестарты и не пингуется...

вот файлик:
http://webfile.ru/3948578

это вы про отключение от сети платы VOIB или MPB?

по трейсу в указонном вами на картинке пакете команда на сброс TCP 1720 соединения от 192.168.50.155 с 192.168.52.155
снифер делался рядом с транзитной станцией или с оконечной?
покажите PGM340 c оконечной и транзитной станции

Отключить от сети пришлось обе платы.
Но конкретно эту фразу я написала про плату VOIB - её поведение можно было безболезненно отслеживать. Процессор-то всю станцию подвешивал, а VOIB - только сама себя.

Про пгм 340.
Оконечная:
IP = 192.168.52.155
GATEWAY = 192.168.52.254
Mask = 255.255.255.0

остальное - по умолчанию (единственное, кодеки меняли несколько раз)

GK - не используем.

Транзитная:
IP = 192.168.50.155
GATEWAY = 192.168.50.254
Mask = 255.255.255.0

Межсетевое взаимодействие осуществляется через промежуточные CISCO.



Рядом с транзитной...Что же получается. Происходит сброс 1720 порта ТСР. Это ведь порт для сигнализации Н.323!

Можете конечно также сделать снифер того что прилетает в платы, но заведомо известного пакета который вызывает такое не назову, вообще хорошим тоном, что бы избегать подобных проблем, считаеся выделение оборудования, работающего с голосом в отдельную, можно виртуальню, сеть.

эти параметры выглядят по разному в зависимости от версии самой станции, поэтому и попросил

Вы уверены что рядом с транзитной?
Тогда опишите каким образом, по какой схеме это делалось?
Так как в таком случае получается виновата именно VOIBE транзитной станции(192,168,50,155), вадавшея пакет RSK(ресет), в чём я очень сомневаюсь.

Золотые слова!!!
Чем и занимались аврально админы весь вечер. Теперь посмотрим, что принесёт день грядущий)))



Рядом с транзитной 100%.
Насколько понимаю, сделали порт-зеркало того порта, в который втыкается плата VOIBE, и с него снифили.
Хотя это уточню по-достовернее.

Инночка! Хорошо выглядишь. Поздравляю с входом в нашу семью братьев меньших . (на рисунке). Работаешь до 12-ти ночи - так нельзя - береги себя.
У меня была похожая ситуация с атмосферной оптикой. Т. к. большое расстояние 3 км, некоторые команды внутреннего кодирования светового луча, приходя битыми и попадая на внутреннюю сетку, - подвешивали оборудование. Сделали, чтобы внутреннее кодирование луча, не попадало в мои сетки - работа оборудования стала идеальной.
Может дело в том, что на уровне транспорта, некоторые команды мешаются с помехами?

Уточнила метод работы со снифером. Действительно, порт-зеркало, но с двух портов - и того, куда втыкается проц, и того, куда VOIBE.
Пока станция работает нормально, всё на VLAN-ах со вчерашнего вечера.

Но проблема 3-х минут, увы, не исчезла.

давайте картинки 340 програм с обоих станций, как просил и назовите точно версии которые счас стоят на VOIB и VOIBE

Транзитная станция, версия B2Ad:

http://webfile.ru/3951762

Оконечная станция, версия 4.3 А:

http://webfile.ru/3951763

Сейчас пока только из офф-лайн просмотра картиночки.

какая вторая буква???

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

maint> bs
bs

Print Sys Config
SLOT BRD-TYPE FW-Ver. BRD-ISSUE SERVICE
---- ---------- ------- --------- -------

0 MPBN 3.8Bf
1 DSIB INS
2 SLIB12 INS
3 SLIB12 INS
4 LCOB INS
5 VOIB 4.3A 43 INS
6 ....
7 ....

зайдите на неё по http

Я в данный момент вне той сети. Но постараюсь найти там живого человека, чтоб он посмотрел

можно ещё подключитс к порту RS-232C на самой VOIB, чтоб посмотреть, но скорее всего у вас 4.3Ae - это последняя сужествующая для VOIB.

Да, посмотрели, уточнили. Именно 4.3 Ае.

и делает она это совершенно правильно, так как у неё истекает таймер во время которго она должна была получить подтверждение от оконечной станции (пакет TCP keep-alive) что соединение продолжается.
Таким образом нужно собрать снифером пакетики рядом с оконечной станцией, чтобы убедится что она отсылает TCP keep-alive и после этого с этим можно требовать от ваших администраторов настройки прохождения TCP keep-alive от оконечной станции к транзитной.

All is not what it seems, спасибо огромное!

Теперь понятно, что делать дальше!

Поскольку если я говорю: "Между двумя оконечками проблемы 3-х минут нет, значит, платы в порядке" - явно недостаточный аргумент для админов.
А уж если в логах будет явно видно, что пакеты отсылаются...