стоит углубиться в терминологию джитта и откуда он вообще материализуются
как бы сказать по простому из основных вариантов:
1. потеря udp
2. опережение udp (хуже потере который вносит бардак в временных точках), пример для наглядности: из fs вышли udp1 udp2 udp3, а на другой fs пришло udp3 udp1 udp2

на всех хостах снимаем средствами tcpdump снимаем траффик и под лупой разглядываем, по пункту 1. маловероятно, но с пунктом 2. вполне ожидаемо

в виртуализации такой фокус «с опережением» выливается в проблему

fs при завершении звонка может складировать «мусор» (я так называю) в котором есть полезная инфа — счетчики, джиттер и т. д. . можно с этого начать путём сравнения полезной инфы на проблемном звонке по всей цепочке

Да, согласен с виртуалками могут быть нюансы. Попробую включить XML CDR - кажется всю расширенную информацию фс только туда кладёт кроме esl.

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

А как вы установили что потерь нет?

Усложним модель цепочки
fs1 (udp1 udp2 udp3) --> (udp3 udp1 udp2) fs2 (udp1 udp3 udp2) --> (udp1 udp3 udp2) fs3
искажение пришло на fs2, так как нет транскодинга всё что пришли udp должны и уйти дальше (буферизация тут тоже при делах), путём корректировки времени уже меняется порядок udp, но в изначальный порядок сложиться уже не получиться так как «временной интервал» пошатнулся, вот и начинает расти джиттер

возвращаемся обратно в среде виртуализации, у гостевого хоста есть vitr-nic через который смотрит в реальную сеть.  Vitr-nic рассчитан на относительно идеальные условия, но у нас тут суровая реальность «не совпадает checksum», вот тут и засада кроется — кто делает перетосовку udp, одно из трех - vitr-nic на  гостевого хоста, либо сам бридж  виртуализации, либо оба вместе вносят свой характер

как говориться — с чего начал к тому опять и пришли, только + немного облегченной теории и каши в голове наверное у некоторых :)))

А в цепочке нет какой-либо обработки медиа ? Если dialplan'ы один за одним посмотреть. Не транскодинга.

Есть - в двух местах запись, но она была добавлена именно для отладки этой проблемы. Мне приходило это  в голову, но с изменением медиа я это не связал

Каша ещё та 🙂
Ты лучше расскажи как это проверить? Не руками же чексуммы считать или скрупулёзно сверять номера пакетиков на выходе одного и входе другого?

По RTCP вестимо 🙂 Хотя выглядит эффект точь-в-точь как выпадения, есть и другие артефакты, но они не столь явны и фатальны. Есть более лучший метод?

Возьмите проблемный звонок и посмотрите его трафик вайршарком. "Выпадения" - это обычно plc

У вас какой то поток сознания - идеальные условия, пошатнувшийся интервал и бридж который перемешивает пакеты.

навскидку никаких PLC не видно, кстати что это, прям так и должно быть написано? В каком поле?
Стрим анализ тоже говорит потерь ноль

Plc это данные которые rtp стек вставляет в аудиопоток когда на вход пакет не пришел( потерялся или джиттербуффер не может компенсировать джиттер), а слать на другую ногу уже что-то нужно

А вы на всех серверах вашей цепочки проверили?

Честно говоря нет, но считайте на двух проверил ибо это один и тот же - петля. Зато на нескольких интерфейсах. И, как уже сказал ранее - даже при перекладивании из eth0 в eth1 (до и после фс) заметны различия. Последующий сервер тоже один за двух и часто даже на этом же физическом хосте

Возможно ваш фс не успевает читать пакеты из сокета, но я бы считал такое маловероятным если только там не большая какая то нагрузка

если на гольдштейн наложить cisco (имею ввиду доки) то кругозор расширяется

решение проблемы тут в поисковике «linux tcpdump bad udp cksum» , но это не гарантирует излечение так как есть ещё среда виртуализации с характером (хост виртуализации по cpu просто перегружен, fs не из ветки stable )

в моём случае на debian это решение помогло

Но у меня ни tcpdump, ни wireshark не жалуются. На графике ошибок сети тоже пусто(у меня снимаются и буфера и чексуммы).
Тебе что помогло, отключение офлоада? В моём домашнем маршрутизаторе около этой настройки написано “лучше не включать для udp” 🙂

Да нет, сервера не загружены настолько. В метриках чисто, единственно обнаружил что он своп пожрал заметно и за полчаса до проблемы дисковый IO и ЦПУ подскочили на пару минут

Вощем хрень какая-то, два с лишним месяца аналитики мозг компостируют 🙁 Самое интересное - а клиенты не жалуются 😵