Две LDK60 разрываеться связь, соеденены по IP при переадресации разрываеться связь Опции

[harris]

Было FSK, выставил в офф не помогло


А по теме того что нас не слышно на второй станции, то проблемма была в том что разные прошивки были у станций

1) Прошу пардону, значит мое первое предложение по поводу возможного наличия бага из-за режима автоматического запроса АОНа не подвердилось.

2)Но все-таки баг есть, но другой.
Вообщем так.... Я провел изыскания на своей станции и нашел причину проблемы...Выяснилось, соединение рвется по таймеру Transfer Recall Timer - ПГМ180/7.
У Вас там стоит значение по умолчанию = 30 сек. Вот вызов и обрывается после 30 сек с момента посылки Setup.
Это, конечно, ошибка в ПО, поскольку на вызов получен ответ. Причем эта же ошибка присутствует не только на ipLDK-60, но и на остальных моделях ipLDK (я проверял на 300-ке).
К сожалению, я смогу написать запрос в Корею на исправление этого бага только после 13 июня (если это нужно...)
Можете, конечно, просто увеличить значение этого таймера, но лучше воспользоваться другим вариантом настройки станции:
- создать Hunt-группу типа NET VM Grp (ПГМ190), в качестве агента группы указать требуемый номер сетевого абонента (206)
- в ПГМ144 прописать назначение для режима Lunch на номер этой созданной NET VM группы.
И все должно заработать нормально без разрыва соединения.

[stasmar]

Каким боком тут перевод звонков приплелся?
У автора, устанавливается вроде соединение, а затем рвется.

1) Прошу пардону, значит мое первое предложение по поводу возможного наличия бага из-за режима автоматического запроса АОНа не подвердилось.
2)Но все-таки баг есть, но другой.
Вообщем так.... Я провел изыскания на своей станции и нашел причину проблемы...Выяснилось, соединение рвется по таймеру Transfer Recall Timer - ПГМ180/7.

И все таки я оказался ближе к правде, чем ув. ИгорьS

[ИгорьS]

И все таки я оказался ближе к правде, чем ув. ИгорьS

Мои предположения касательно did\disa таймера, складывались из того, что станция не видит ответа, и затем отправляет на значение did\disa no ansfer(у автора там tone).
О том что станция считает net вызов - переведенным, и смотреть надо в строну recall, ну чтож- сильно не бейте

[stasmar]

Мои предположения касательно did\disa таймера, складывались из того, что станция не видит ответа, и затем отправляет на значение did\disa no ansfer(у автора там tone).
О том что станция считает net вызов - переведенным, и смотреть надо в строну recall, ну чтож- сильно не бейте

Нет, Игорь - здесь всю ответственность за теракт взяли на себя программисты LG-E. Ты как раз был бы прав, если бы не баг.
Тебе +1, выздоравливай!

[Dron]

И все таки я оказался ближе к правде, чем ув. ИгорьS

И чем же ты ближе к правде то?

[Dron]

О том что станция считает net вызов - переведенным, и смотреть надо в строну recall, ну чтож- сильно не бейте

И кто бы мог сразу на такое подумать? Логики то нет! Баг, он и есть баг!

[stasmar]

И чем же ты ближе к правде то?

Во первых - я пошутил..

И кто бы мог сразу на такое подумать? Логики то нет! Баг, он и есть баг!

Во вторых - я пошутил в сторону программистов LG..

В третьих: скучно жить когда все принимают буквально - начинаются вот такие значки:
А значки должны быть типа таких:

В четвертых: я бы мог быть ближе к правде по нелогичности своих предположений

Логики то нет!

[harris]

Во первых - я пошутил..

Во вторых - я пошутил в сторону программистов LG..

В третьих: скучно жить когда все принимают буквально - начинаются вот такие значки:
А значки должны быть типа таких:

Ооо, опять признаки синдрома пятницы...???

[Dron]

Ооо, опять признаки синдрома пятницы...???

А человек только из отпуска...

[stasmar]

Ооо, опять признаки синдрома пятницы...???

Это еще не весь синдром вы увидели - сайт ругнулся на превышение количества смайлов, я их там больше пытался поставить..
У меня неделя черная после отпуска - зато пятница супербелая..

[ЛыЖник]

Это еще не весь синдром вы увидели - сайт ругнулся на превышение количества смайлов, я их там больше пытался поставить..
У меня неделя черная после отпуска - зато пятница супербелая..

А вот у меня отпуск с понедельника. При этом надо сегодня решить с подрядчиками вопрос о прокалдке оптики и ТПП 20 по неисправной канализации ВолгаТелекома и впарить на оплату счет на LDK-300. Стимул, согласитесь. Грустить некогда, нужно быть в тонусе. Следовательно пиво должно быть в тебе

[stasmar]

А вот у меня отпуск с понедельника. При этом надо сегодня решить с подрядчиками вопрос о прокалдке оптики и ТПП 20 по неисправной канализации ВолгаТелекома и впарить на оплату счет на LDK-300. Стимул, согласитесь. Грустить некогда, нужно быть в тонусе. Следовательно пиво должно быть в тебе

И суперпятница перед отпуском и канализация и пиво - яркая жизнь

[diver_ser]

Можете, конечно, просто увеличить значение этого таймера, но лучше воспользоваться другим вариантом настройки станции:
- создать Hunt-группу типа NET VM Grp (ПГМ190), в качестве агента группы указать требуемый номер сетевого абонента (206)
- в ПГМ144 прописать назначение для режима Lunch на номер этой созданной NET VM группы.
И все должно заработать нормально без разрыва соединения.

Проделал всё как описано выше всё работает НЕ срывается, спасибо ОГРОМНОЕ!!!!

К сожалению, я смогу написать запрос в Корею на исправление этого бага только после 13 июня (если это нужно...)

Честно говоря даже не знаю нужно это или нет, но сейчас всё прекрасно работает

Ещё раз спасибо

[morfius]

Решил описать свою проблемку в этой теме.
Значиться такая вот ситуация. ЛДК300Е и ЛДК 100 связываются по VOIP. Всё работает нормально, но иногда бывает, что при звонке, пропадают целый слова, и речь постоянно идет рывками. Канал 1 Мбит/с, подят QoS, под телефонию 384 Мбит/с. Ведутся логи, вижу конкретно, что в момент прерывания и обрывков голоса идет только 1 телефонный разговор по VOIP. Посадили wireshark, начали мониторить звонки, во время проблемного звонка никакх ошибок в пакатах не было, всё замечательно, вот только была задержка 500 мс и выше, отсюда и такая связь, но проблема в том, что канал был абсолютно не нагружен. Может кто-то поделиться соображениями, как найти участок на котором могут быть задержки ?
Если непонятно описал, спрашивайте буду отвечать.

[stasmar]

Решил описать свою проблемку в этой теме.
Значиться такая вот ситуация. ЛДК300Е и ЛДК 100 связываются по VOIP. Всё работает нормально, но иногда бывает, что при звонке, пропадают целый слова, и речь постоянно идет рывками. Канал 1 Мбит/с, подят QoS, под телефонию 384 Мбит/с. Ведутся логи, вижу конкретно, что в момент прерывания и обрывков голоса идет только 1 телефонный разговор по VOIP. Посадили wireshark, начали мониторить звонки, во время проблемного звонка никакх ошибок в пакатах не было, всё замечательно, вот только была задержка 500 мс и выше, отсюда и такая связь, но проблема в том, что канал был абсолютно не нагружен. Может кто-то поделиться соображениями, как найти участок на котором могут быть задержки ?
Если непонятно описал, спрашивайте буду отвечать.

Цитата из форума:
«Хорошее качество звука достижимо при времени ожидания и задержке пакета не более 80 мсек. С увеличением этого времени качество падает, но все еще остается в приемлемых пределах до 180 мсек. Некоторые системы пытаются преодолеть это узкое место при помощи распределения трафика по приоритетам (DiffServ, 802.1 p/q, IP ToS), но это имеет смысл только до определенной степени: от повышения приоритета пропускная способность канала не увеличивается. Требуется собственная выделенная полоса с интеллектуальным управлением, по которой будет двигаться только VoIP-трафик, разложенный по приоритету.

Если случайные задержки пакетов будут последовательно превышать 20-30 мсек или потери превысят 3%, качество звука может серьезно ухудшиться. При помощи инструментов управления полосой пропускания и QoS можно добиться оптимальной работы VoIP без дорогостоящих модернизаций пропускной способности канала.»

729 менее критичен к задержкам, чем 723.

[morfius]

Цитата из форума:
«Хорошее качество звука достижимо при времени ожидания и задержке пакета не более 80 мсек. С увеличением этого времени качество падает, но все еще остается в приемлемых пределах до 180 мсек. Некоторые системы пытаются преодолеть это узкое место при помощи распределения трафика по приоритетам (DiffServ, 802.1 p/q, IP ToS), но это имеет смысл только до определенной степени: от повышения приоритета пропускная способность канала не увеличивается. Требуется собственная выделенная полоса с интеллектуальным управлением, по которой будет двигаться только VoIP-трафик, разложенный по приоритету.

Если случайные задержки пакетов будут последовательно превышать 20-30 мсек или потери превысят 3%, качество звука может серьезно ухудшиться. При помощи инструментов управления полосой пропускания и QoS можно добиться оптимальной работы VoIP без дорогостоящих модернизаций пропускной способности канала.»

729 менее критичен к задержкам, чем 723.

У меня везде стоит 711, мне просто непонятно откуда могут взяться задержки если канал полностью свободен ?
QoS есть, но опять же всё свободно...

[vldmr]

В процессе разговора команда tracert с компа поможет найти узкое место в канале

[DaGash]

По потерям поможет pathping

[stasmar]

У меня везде стоит 711, мне просто непонятно откуда могут взяться задержки если канал полностью свободен ?
QoS есть, но опять же всё свободно...

Попробуйте поставить 729, вам же сказано, что он менее чувствителен к задержкам.
711 - без сжатия
Если задержка - 500, а 729 раз в 8 сжат - значит 500 делим на 8 - получается 62,5 - в приемлимых пределах..

[stasmar]

Представьте себе песочные часы. Вы убавили количество песка в 8 раз. Во сколько раз уменьшится задержка падения последней песчинки?