Прерывается голос, слышу эхо… Плохое качество связи ip-телефонии. Как можно решить самостоятельно?

[Dmitriy_Mironiuk]

Да. такой вариант пробовали. Но, как показала практика, с sip это неэффективно.

[MagicGTS]

Что-то мне подсказывает (а опыта у меня достаточно для этого), что вы не умеете его готовить.
Безусловно, выцепить SIP и RTP задача довольно хитрая, но я вполне её успешно решаю в своих проектах в mangle маркировке, и нет нужды знать расположение SIP и RTP серверов провайдера для QoS. Нужен в основном только SIP, чтобы прикрыть свою АТС от ботов.
Также тупо выдавать n мбит на телефонию — расточительно. Вполне можно посчитать, что 84*(число одновременных разговор) вполне достаточно для большинства случаев.

[Dmitriy_Mironiuk]

В своём методе я уверен на 100%, а в вашем нет.
Если вы уверены и можете подтвердить это на практике, как я, тогда напишите статью. Такую, которая будет понятна даже самым начинающим.
На своем пути неоднократно наблюдал и наблюдаю такую картину, что только 1 из 100 специалистов знают, что на качество голоса может влиять забивка канала. А как это диагностировать и поправить, кроме как расширить тариф, совсем редкость.
А как об этом люди узнают, если не рассказать и не показать. Пусть наш вклад «капля в море», но всё же.

[MagicGTS]

Прошу, читайте:
https://m.habr.com/en/post/331544/
И вообще, по теме QoS на habr.com много статей, моя тут не одна лежит годами, в то время как молодые авторы пишут что-то свое, не проверив, а стоит ли. Есть куча статей, которые нуждаются в работе сообщества, но молодые редко используют поиск или не умеют его использовать.

[Dmitriy_Mironiuk]

по теме QoS на habr.com много статей

но не слова о методах анализа голосового трафика и его фикса

[MagicGTS]

Вот об этом и надо писать.

[Dmitriy_Mironiuk]

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

[FAT_32]

Коль беретесь рекомендовать Mikrotik для VoIP, потрудитесь объяснить в статье, как отключить MNDP на прошивках 6.48.x, иначе могут появиться проблемы с качеством у владельцев аппаратов Gigaset. На всякий случай: IP — Neighbors — Discovery Settings — убрать галочку MNDP, либо в консоли:
/ip neighbor discovery-settings set protocol=cdp,lldp

[Dmitriy_Mironiuk]

Коль беретесь рекомендовать Mikrotik для VoIP

«Рекомендовать» это громко сказано. Я лишь показал какими инструментами пользуюсь для анализа voip трафика и настройки QoS.

потрудитесь объяснить в статье, как отключить MNDP

Подскажите, каким образом данный протокол оказывает влияние на качество голоса?
Ранее никогда не сталкивался с подобными проявлениями.

[FAT_32]

В прошивке 6.48 и 6.48.1 какой-то баг с MNDP, в итоге есть проблемы как с регистрацией аппаратов, так и с качеством голоса-большая потеря пакетов. Данная тема обсуждалась и на официальном форуме: forum.mikrotik.com/viewtopic.php?t=171035

[MagicGTS]

Сама по себе статья имеет место для существования, однако методы и подходы предложенные в ней не являются глубоко продумаными и обоснованными.

1. • за демонстрацию способов оценки качества связи
   
   
2. • из правильных данных сделано много неправильных выводов
   
   
3. • идея упрощённой настройки QoS для простых случаев, где не требуется развёрнутая приоритезация.
   
   
4. • реализация идеи плохая, что делать будете делать если VOIP провайдер разрешит прямой RTP трафик со своими партнёрами?
   
   
5. • плохая проработка первоисточников, применены топорные методы маркировки целевого трафика в связи с непониманием всех механизмов.
   
   

[the_vitas]

Вся фирма в гигасетах. И шлюз микрот 2011, никаких проблем нет.

[vviz]

Думается, высказывание «У меня на загрузку скорость 11Мб/с, на отдачу 14Мб/с. Хотя по договору должно быть 15М в обе стороны» не совсем корректно. По договору на Ваш канал выставлено ограничение в 15М — это все что пройдет сквозь канал. При измерении скорости «измеритель» покажет скорость с которой в канале идут ДАННЫЕ, служебный трафик и заголовки пакетов учтены не будут (если «измеритель» не накинет процент на ДАННЫЕ что бы все выглядело красиво). Поэтому, при измерении скорости канала полученное значение не может быть равно скорости по договору. ИМХО.

[alex_titov1]

Помимо оверхеда из заголовков, там ещё при замере используется TCP который зависит от TCP window size и задержек. [TCP Window Size in bits] / [Latency in seconds] = [Throughput in bits per second]

[Vvvyg]

Пара замечаний.
Захват пакетов, на мой вкус, удобнее делать в Wireshark с фильтром udp port 37008.
А анализировать дампы в меню Телефония -> RTP -> Потоки RTP. По графикам часто проблема весьма наглядно видна.
Но это всё — моё ИМХО :)