Качество голоса по VoIP MOS=2 :(

Если возникает проблема переполнения JB, то какие есть пути решения проблемы?
На графиках видно (отмечено синим) что постоянно идет переполнение JB, а его заполнение идет скачкообразно (желтая линия) - отчего такое может быть?
Между оригинатором и терминатором 10 хопов из которых не гарантированы (Public Internet) 8, но при этом команды:
ping -s 1500 -i 0.3 X.X.X.X показывают стабильную задержку в диапазоне от 90 до 100 мс,
тоже самое показывает mtr -p 1500 -i 0.3 X.X.X.X - задержки стабильны и в пределах нормы.
Помогите пожалуйста разобраться с тем,что необходимо делать при таких симптомах - увеличивать объем JB или уменьшать, может увеличивать или уменьшать payload, может есть и другие инструменты борьбы с переполнением JB и его нелинейной загрузкой?

Вообще насколько я понимаю теорию, то нелинейное заполнение JB должно возникать при переменной задержке (то 50 мс, то 150 мс и т.д. постоянно меняется), но тут она стабильная -> происходит что то такое, чего я не понимаю :(

Заранее благодарен за ответы! :victory:

У нас есть несколько взаимозависимых врагов и параметров:
ВРАГИ:
- Задержка норма известная - в пределах 150 мс (в нашем случае от 90 до 100 мс.);
- Джиттер - это суровая реальность и с ней придется смириться и к ней пристраиваться - у нас от 5 до 10 мс.;
- Вероятность потерь пакетов - аналогично джиттеру - у нас менее 1%;

Чтобы пристроиться (приучить железо) работать в суровых условиях имеющейся в наличии СПД надо крутить параметры:
- размер пакета (он у нас статичен и регулировать его советуют только длиной семпла - у меня при длине семпла = 20мс на пакет в кодеке 729 длина пакета получается 74 байта)
- длинна семпла при кодеке G.729 (такой кодек мы юзаем в 90% случаев) в пакете;
- Объем Jitter-буфера.

Т.е. в итоге надо подкрутить пару ручек (длина семпла и объем JB), чтобы победить трех врагов (задержка, джиттер, потери) - только вот кто подскажет как выкручивать длину семпла и объем JB при тех или иных условиях?

P.S.: Наличие потерь вынуждает нас уменшать длину сэмпла, т.к. потеря короткого сэмпла менее критична, нежели чем длинного!
Чем менее стабильна задержка (больше Джиттер), тем большего объема необходим JB!

НО, от чего еще может JB заполняться с такой неравномерностью (как на СКРИН01 - желтая линия), если неравномерность задержки (Джиттер) в пределах 5-10 мс.? - вот в чем вопрос!

тут такая еще ручка есть - количество фреймов в пакете.
фреймы по 20мс укладываете в пакеты по 20 фреймов на пакет - почучается, что никакой пользы сокращение длительности во фрейме не принесло.
укладываете по 1 фрейму в пакет - теряете в payload. подбирайте "золотую середину".

voldemar писал(а):тут такая еще ручка есть - количество фреймов в пакете.
фреймы по 20мс укладываете в пакеты по 20 фреймов на пакет - получается, что никакой пользы от сокращения длительности во фрейме не принесло.
укладываете по 1 фрейму в пакет - теряете в payload. подбирайте "золотую середину".

Не до конца понял рассуждение :( Правильно я понимаю, что если payload=20, то их в пакет пихается столько, чтобы добить его размер до какого то определенного? А какой это размер? От чего зависит количество упаковываемых фреймов в пакет? Фрейм в Вашем понимании = семпл (длительность голосового сигнала на оцифровку)?

Фрейм - кадр. Кодек формирует кадр, с длительностью сэмпла 20мс.В один IP-пакет кладется 1 или несколько последовательных фреймов кодека. При испольщовании каналов с достаточной полосой пропускания с точки зрения устойчивости к потерям кадров и джиттеру оптимальной ситуацией будет доставка каждого фрейма в отдельном пакете, но объем информации в одном фрейме крайне небольшой и воплне сопоставим с размером заголовка. Соотвественно объем IP-трафика возрастает существенно. Но при доставке, скажем, 20 фреймов длительностью по 20мс в одном пакете - потеря одного пакета ведет к потере 20 последовательных кадров кодека или 400мс голоса. Ну и ждать фреймы в джиттер-буфере тоже вобщем-то надо до тех пор, пока их все один подзадержавшийся пакет не принесет. А что в вашей терминологии означает payload=20 я, к сожалению, не знаю. Возможно это как раз количество фреймов в пакете.

voldemar писал(а): А что в вашей терминологии означает payload=20 я, к сожалению, не знаю. Возможно это как раз количество фреймов в пакете.

Я формулировку payload=20 понимаю как раз длинну семпла кодируемую кодеком - т.е. в вашем понимании - это фрейм или кадр с 20-ю мс. оцифрованного и сжатого голоса.
Я вот так и не понял на основании чего устройство (напрмер тот же AddPac) принимает решение о том, сколько фреймов упаковать в пакет?
В доке на адпак нашел такой вот раздел:

Команда max-frame
Для установки максимальной длины аудио-фрейма в RTP-пакете и используется данная
команда.
В случае G.7231 значение по умолчанию - 1. Это означает, что аудио-фрейм генерируется и
RTP-пакет передается с интервалом 30ms. Значение по умолчанию – 2 в случае G.729. Это
означает, что аудио-фрейм генерируется с интервалом 10ms и передача RTP-пакета
происходит каждые 20ms.

Я так понимаю, что если я использую кодек G.729, то значение 2 означает, что формируемый к отправке пакет содержит два фрейма по 10 мс (итоговая длина пакета - смотрел в Wireshark = 74 байта). Вот что будет если я поставлю значение 3 - скорее всего фреймы так и будут по 10мс, а отправка будет каждые 30 мс -> формируемый к отправке пакет будет содержать три фрейма по 10 мс.?

очень похоже на то, судя по цитате из описания.
конкретно про аддпак был неплохой форум, вроде-бы на http://ap200.nm.ru
пробуйте, еще одна ручка нашлась, по крайней мере

Я предпочитаю voipinfo