В процессе телефонных разговоров VoIP абонентов временами происходит внезапное пропадание связи - тишина. Это происходит при соединениях с внешними абонентами как публичной сети (Е1), так и астерискоского транка (Е1).
Все телефонные параметры Н4К мною перепроверены и не вызывают сомнений.
Файл ошибок определяет наличие проблемы в линиях локальной компьютерной сети, соединяющие между собой отдельные составные части системы HiPath 4000 :

F5915 E8 N5110 NO ACT BPA LTUC PAYLOAD CONNECTION 11-05-12 12:05:08
ALARM CLASS:CENTRAL:033
** :LTG1 :LTU18:006: 00 : 0 Q2324-X NCUI4/1 BST:01 PLS:-13
FORMAT:43
REASON:00H IP BAD QUALITY

PARTY A (PEN): 1-18-7-37-1
PARTY B (PEN): 1-2-25-1-12
SOURCE IP ADDRESS: 192.168.42.2
DESTINATION IP ADDRESS: 192.168.42.7
NPCI: 1232
00000000FFFFFFFF00000000FFFFFFFF00000000FFFFFFFF00 00000DFFFFFFFF

1-18-7-37-1 = VoIP абонент
1-2-25-1-12 = Транк Е1 на публичную сеть

Description of auxiliary data
Byte 01-04: Round trip networking delay (in ms)
Byte 05-08: Filler with FFFFFFFF
Byte 09-12: Fraction outgoing packets (in %)
Byte 12-16: Filler with FFFFFFFF
Byte 17-20: Jitter last RTCP (in ms)
Byte 21-24: Filler with FFFFFFFF
Byte 25-28: Fraction incoming packets (in %)

Пытаюсь найти конкретный параметр, приводящий к коллизии, но кроме буквы D в 28 байте ничего не найти. Как я понял буква D в расшифровке означает, что у меня Fraction incoming packets составляет 13%. Хочу понять, что это за параметр не являются ли именно эти 13% причиной проблемы. И каким он должен быть?
Администраторы компьютерной сети помочь не могут.
Не поможет ли кто проанализировать ?
Спасибо.

В процессе телефонных разговоров VoIP абонентов временами происходит внезапное пропадание связи - тишина. Это происходит при соединениях с внешними абонентами как публичной сети (Е1), так и астерискоского транка (Е1).

Не поможет ли кто проанализировать ?
Спасибо.

попробуйте "пропинговать" абонента, и чтобы он со своей под сети сделал тоже самое в сторону вашего шлюза (IP "Registrar server")
команда для пинга: ping -l 1200 192.168.1.11 -t (IP впишите ваш) ;)
l это маленькая латинская "L"
пакеты будут по 1200 байт
Желательно это делать при наличии проблем во время разговора.

Удачи!

Да вот всё дело как раз в том, что пингуется идеально, проверено,на моей распечатке это тоже видно - в первых байтах нули, я даже на самые ответственные линии поставил Zabbix on-line круглосуточный мониторинг, где пинги как на ладони.
Видимо засада где-то очень глубоко, на уровне параметров сети.

Николай

Да вот всё дело как раз в том, что пингуется идеально, проверено,на моей распечатке это тоже видно - в первых байтах нули, я даже на самые ответственные линии поставил Zabbix on-line круглосуточный мониторинг, где пинги как на ладони.
Видимо засада где-то очень глубоко, на уровне параметров сети.

Николай
Повторю пакеты по 1200 байт
а не по 32 байта, или сколько у вас там есть :)
а можно и по максимуму 65500 байт ;)

так заметнее возможная неустойчивость канала.
Когда в канале будет полная уверенность, переходите к железякам и настройкам !!!

Да кстати, а IP ваши зарезервированы или нет, и как резервация произведена, по мас адресам?

Спасибо, выствлю 1200, но надежды на пинги небольшие.....

Ну начнём с того, что это не совсем VoIP абонент, ведь он находится на 18 полке- а это IPDA. и проблемы с обрывом у вас между NCUI и IPGW на основной станции.
Проблем может быть уйма.
Начиная от того, что лодвера на железяках с дырками и вам надоть обновить их (lodware for NCUI and STMI\HG35xx). Было бы не плохо и HF поставить последние... в конце концов, возможно вам на сети надо подымать QoS или для начала загнать в отдельный Vlan всё, что связано с VoIP HiPath 4000.

Такая же ерунда. Этот IP BAD QUALITY уже порядком надоел. Сеть гигабитная, пинги идут без проблем (любого размера), джиттеры небольшие. Дурацкий Скайп работает нормально на куда более худших интернет-каналах. А HiPath 4000 раз в день, но устраивает абонентам "тишину".

Николайс
А где Вы этот "Description of auxiliary data" взяли? Это прямо данные представленной ошибки? У меня их нет в STA-HISTA...

"Description of auxiliary data" я добыл из документа "HiPath 4000/OpenScape 4000 Troubleshoting" в PDF формате, 9 МВ.
В Hista этого нет.
Достал в Сименсе.

А, понял! Спасибо, сейчас у себя посмотрю....

Посмотрел. У меня тоже ненулевое значение только в Byte 25-28: Fraction incoming packets (in %) - конкретно 64, то есть 100%...
Это процент потерь входящих пакетов получается, что ли?

Вот с этого вопроса я и начал разматывать свою заморочку, возможно у нас одинаковые проблемы. Пытаюсь найти хоть одного грамотного админа, кто мог бы объяснить значение этого процента для передачи телефонного трафика.
Если узнаю - поделюсь информацией, если Вы узнаете, насколько влиятельно значение 28 байта, дайте знать!
С уважением,
Николай

Добрый день!
У меня тоже в свое время были подобные траблы с моим HP4000.
Тоже используется вынос. Сетевики перешли на другого оператора по IP-каналам и начались тоже разорванные разговоры и т.д.
Слава богу у нас нормальные и адекватные ребята...дружно поковыряли, нашли глюки у оператора и всё стало ОК.

Николайс, я сам не сетевик, но что могу порекомендовать/спросить:

1. Представлена ошибки F5915 с Fraction incoming packets. Есть ли такая же ошибка с Fraction outcoming packets того же самого разговора? Т.е. траблы с передачей данных только в одну сторону или в обе???

2. Используют ли админы QoS на своих железках? Как показало изучение этого вопроса маркировка трафика на стороне АТС не соответствует рекомендациям маркировки трафика того же Cisco, потому тупое, в лоб, включение политики QoS на Cisco и тому подобных железках приводит к задержкам голосовых пакетов АТС.

3. Не понял фразу "поставил мониторинг на самые ответственные линии"? Это как? Если вы хотите получить более-менее честный мониторинг в том случае если вы по нулям о настройке вашей сети:
a. встаете ноутбуком на порт самого 1-го к вашему выносу коммутатора. Берёте IP-адрес из той же подсети где живёт вынос.
б. встаете другим ноутбуком на порт самого 1-го к вашей АТС коммутатора. Берёте IP-адрес из той же подсети где живёт АТС.
в. гоняете пинги и тому подобное например как подсказал Out.

Есть ещё вариант с зеркалированием портов на тех же самых коммутаторах, но тут уже надо плотнее поработать с админами.

4. Любопытства ради... не совсем понял что такое 1-18-7-37-1 = VoIP абонент. У меня они(абоненты с IP-телефонами) идут на выносе как 1-18-10-37 например. Что такое последнее 1 в PEN - не понял? Или это всё-таки внешнее направление?

5. Советы Зодиака по поводу релиза АТС и HG никто не отменял.

Добрый день, публикую полную распечатку F5915:

<STA-HISTA:SEARCH,2011-05-12/12:00,2011-05-12/12:29;
STA-HISTA:SEARCH,2011-05-12/12:00,2011-05-12/12:29;
H500: AMO HISTA STARTED
H1: 00007 ERROR MESSAGES FOUND

F5915 E8 N5108 NO ACT BPA LTUC PAYLOAD CONNECTION 11-05-12 12:04:43
ALARM CLASS:CENTRAL:033
** :LTG1 :LTU18:006: 00 : 0 Q2324-X NCUI4/1 BST:01 PLS:-13
FORMAT:43
REASON:00H IP BAD QUALITY
PARTY A (PEN): 1-18-7-37-1
PARTY B (PEN): LN: 1751 NOT VALID
SOURCE IP ADDRESS: 192.168.42.2
DESTINATION IP ADDRESS: 192.168.42.7
NPCI: 1234
00000000FFFFFFFF00000000FFFFFFFF 00000000FFFFFFFF0000000AFFFFFFFF

F5750 E8 N5109 NO ACT BPA BOARD PAYLOAD CONNECTION 11-05-12 12:04:53
ALARM CLASS:CENTRAL:033
P203:LTG1 :LTU2 :079: 00 : 0 Q2324-X500 STMI4/1 BST:01 PLS:-11
FORMAT:43
REASON:00H IP BAD QUALITY
PARTY A (PEN): 1-18-7-37-1
PARTY B (PEN): LN: 1751 NOT VALID
SOURCE IP ADDRESS: 192.168.42.7
DESTINATION IP ADDRESS: 192.168.42.2
NPCI: 1234
00000000FFFFFFFF0000000CFFFFFFFF 00000000FFFFFFFF00000000FFFFFFFF

F5915 E8 N5110 NO ACT BPA LTUC PAYLOAD CONNECTION 11-05-12 12:05:08
ALARM CLASS:CENTRAL:033
** :LTG1 :LTU18:006: 00 : 0 Q2324-X NCUI4/1 BST:01 PLS:-13
FORMAT:43
REASON:00H IP BAD QUALITY
PARTY A (PEN): 1-18-7-37-1
PARTY B (PEN): 1-2-25-1-12
SOURCE IP ADDRESS: 192.168.42.2
DESTINATION IP ADDRESS: 192.168.42.7
NPCI: 1232
00000000FFFFFFFF00000000FFFFFFFF 00000000FFFFFFFF0000000DFFFFFFFF

F5750 E8 N5111 NO ACT BPA BOARD PAYLOAD CONNECTION 11-05-12 12:05:13
ALARM CLASS:CENTRAL:033
P203:LTG1 :LTU2 :079: 00 : 0 Q2324-X500 STMI4/1 BST:01 PLS:-11
FORMAT:43
REASON:00H IP BAD QUALITY
PARTY A (PEN): 1-18-7-37-1
PARTY B (PEN): 1-2-25-1-12
SOURCE IP ADDRESS: 192.168.42.7
DESTINATION IP ADDRESS: 192.168.42.2
NPCI: 1232
00000000FFFFFFFF00000005FFFFFFFF 00000000FFFFFFFF00000000FFFFFFFF

F5750 E8 N5112 NO ACT BPA BOARD PAYLOAD CONNECTION 11-05-12 12:05:38
ALARM CLASS:CENTRAL:033
P203:LTG1 :LTU2 :079: 00 : 0 Q2324-X500 STMI4/1 BST:01 PLS:-11
FORMAT:43
REASON:00H IP BAD QUALITY
PARTY A (PEN): 1-18-7-37-1
PARTY B (PEN): 1-2-25-1-12
SOURCE IP ADDRESS: 192.168.42.7
DESTINATION IP ADDRESS: 192.168.42.2
NPCI: 1232
00000000FFFFFFFF00000026FFFFFFFF 00000000FFFFFFFF00000000FFFFFFFF

F5750 E8 N5113 NO ACT BPA BOARD PAYLOAD CONNECTION 11-05-12 12:07:27
ALARM CLASS:CENTRAL:033
P203:LTG1 :LTU2 :079: 00 : 0 Q2324-X500 STMI4/1 BST:01 PLS:-11
FORMAT:43
REASON:00H IP BAD QUALITY
PARTY A (PEN): 1-18-7-37-1
PARTY B (PEN): 1-1-25-1-16
SOURCE IP ADDRESS: 192.168.42.7
DESTINATION IP ADDRESS: 192.168.42.2
NPCI: 1233
00000000FFFFFFFF00000000FFFFFFFF 00000000FFFFFFFF0000000AFFFFFFFF

F5915 E8 N5114 NO ACT BPA LTUC PAYLOAD CONNECTION 11-05-12 12:07:32
ALARM CLASS:CENTRAL:033
** :LTG1 :LTU18:006: 00 : 0 Q2324-X NCUI4/1 BST:01 PLS:-13
FORMAT:43
REASON:00H IP BAD QUALITY
PARTY A (PEN): 1-18-7-37-1
PARTY B (PEN): 1-1-25-1-16
SOURCE IP ADDRESS: 192.168.42.2
DESTINATION IP ADDRESS: 192.168.42.7
NPCI: 1233
00000000FFFFFFFF0000000CFFFFFFFF 00000000FFFFFFFF00000000FFFFFFFF

AMO-HISTA-111 READ HTS HISTORY FILE
START COMPLETED;
<
1. Outgoing packets (Byte 09-12) также несут ошибку, но не одновременно с входящими.
2. QoS конечно влючён, но как он эффективен, я затрудняюсь определить, по Вашему совету прозондирую этот вопрос у админов, в чьих руках этот инструмент.
3. Мой мониторинг - круглосуточный пинг прогой Заббикс по всем испытуемым девайсам, как телефоны и шлюзы размером 1200 мсек.
Всюду идеальный график.
4. PEN на 18 полке такой же четырёхзначный. пятый разряд появляется только в распечатке ошибок, соединение для данного случая, действительно внешнее через карту DIUS2.

Спасибо за профессиональную поддержку, попытаюсь поработать с админами и обязательно покажу Ваши рекомендации.
Николай

Поправка для пинга:

размером 1200 Bytes

3. Мой мониторинг - круглосуточный пинг прогой Заббикс по всем испытуемым девайсам, как телефоны и шлюзы размером 1200 мсек.
Всюду идеальный график.


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

Можно пинговать пакетами хоть какого размера.....

не факт, что в то же самое время их связь между собой работает так же идеально.
---------------------------------------------------------------------
К сожалению, так оно и есть, но иного средства мониторинга пока не отыскал.
Вы мне здорово помогли уже тем, что подтвердили возможность сбоев хотя бы даже и с безупречным пингом. Я своим админам показал Ваши предположения. Они уже ищут решение в изменениии подключений между свичами. Карты STMI4 стоят на выносе, а NCUI4 в центральной серверной - на разных этажах и в противоположных углах огромного здания. Связаны 70 м куском локальной сети.
В распечатке ошибок высвечиваются IP адреса именно этих девайсов.
Напрашивается оптимизация структуры соединений.
Спасибо,
Николай