Доброго времени суток, уважаемые коллеги!

Между удаленными офисами настроен IPSec тоннель. На одном конце DFL860e, на другом - DFL260e. Интернет-канал на одном конце - 60 Мбит/с, на другом - 20 Мбит/с.
На обоих фаерволлах настроены правила Allow all services для свободного хождения траффика между офисами (то есть, удаленные офисы как бы в одной локалке, только в разных подсетях).
В офисах установлена система видеоконференцсвязи AVer, связь происходит по протоколу H.323 напрямую, без gatekeeper и проч. Используемый кодек видео - H264P, аудио - G.722.1.c. Video/audio rate - 2000 kbps/48 kbps, разрешение видео - 1080p.
Недавно во время сеанса видеоконференцсвязи картинка начала время от времени "сыпаться". Незначительно, но часто и напрягающе (ранее такого не было). Встроенными средствами AVer были обнаружены незначительные потери пакетов как при приеме, так и при передаче (около 100 пакетов в минуту). При соединении устройств AVer в пределах одного офиса - все нормально, проблема возникает только при связи через VPN IPSec.
Пробовал резко снижать нагрузку на DFL (отключал траффик видеонаблюдения), уменьшать качество звонка по умолчанию, а также менял значение MTU в настройках IPSec с обеих сторон с 1420 на 2000 - изменений не заметил.

В чем может быть проблема?

Сегодня попробовал по официальному мануалу настроить Traffic Shaping и выставить для траффика видеоконференцсвязи наиболее высокий приоритет. Вроде как все заработало, но потери пакетов все равно идут.
Активация опции "Enable QoS" на оборудовании AVer тоже ничего не даёт.

Как именно шейпинг/приоритезация сделаны? Через ширину или precedence ?

Через ширину, по разделу "Сценарий VPN" официального мануала по NetDefend OS.

предлагаю "пощупать" precedence
притом взять и тупо задать это для подсеток, а не сервисов

если проблемы не кроются в реальных обрывах, то это должно хорошо помочь

Большое спасибо за совет, а вы можете подробнее об этом рассказать?

Если совсем образно - это как "работники профсоюза обслуживаются вне очереди"

Соответственно если вдруг где-то образуется очередь - пакеты с более высоким приоритетом (precedence) пройдут раньше.
Для каналов с плавающей (переменной) скоростью - других вариантов собственно нет.
Ну и практика показала, что на 3g/4g свистках, когда скорость пляшет от нуля до скольки-нибудь вариант приоритетов исключает "кваканье" практически полностью (пока канал совсем не останавливается).

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

Polices - Traffic management - Pipe rules - Traffic shaping (Precedence: use fixed)