Комментарии 18
Что-то мне подсказывает (а опыта у меня достаточно для этого), что вы не умеете его готовить.
Безусловно, выцепить SIP и RTP задача довольно хитрая, но я вполне её успешно решаю в своих проектах в mangle маркировке, и нет нужды знать расположение SIP и RTP серверов провайдера для QoS. Нужен в основном только SIP, чтобы прикрыть свою АТС от ботов.
Также тупо выдавать n мбит на телефонию — расточительно. Вполне можно посчитать, что 84*(число одновременных разговор) вполне достаточно для большинства случаев.
Если вы уверены и можете подтвердить это на практике, как я, тогда напишите статью. Такую, которая будет понятна даже самым начинающим.
На своем пути неоднократно наблюдал и наблюдаю такую картину, что только 1 из 100 специалистов знают, что на качество голоса может влиять забивка канала. А как это диагностировать и поправить, кроме как расширить тариф, совсем редкость.
А как об этом люди узнают, если не рассказать и не показать. Пусть наш вклад «капля в море», но всё же.
Прошу, читайте:
https://m.habr.com/en/post/331544/
И вообще, по теме QoS на habr.com много статей, моя тут не одна лежит годами, в то время как молодые авторы пишут что-то свое, не проверив, а стоит ли. Есть куча статей, которые нуждаются в работе сообщества, но молодые редко используют поиск или не умеют его использовать.
/ip neighbor discovery-settings set protocol=cdp,lldpКоль беретесь рекомендовать Mikrotik для VoIP
«Рекомендовать» это громко сказано. Я лишь показал какими инструментами пользуюсь для анализа voip трафика и настройки QoS.
потрудитесь объяснить в статье, как отключить MNDP
Подскажите, каким образом данный протокол оказывает влияние на качество голоса?
Ранее никогда не сталкивался с подобными проявлениями.
Сама по себе статья имеет место для существования, однако методы и подходы предложенные в ней не являются глубоко продумаными и обоснованными.
- за демонстрацию способов оценки качества связи
- из правильных данных сделано много неправильных выводов
- идея упрощённой настройки QoS для простых случаев, где не требуется развёрнутая приоритезация.
- реализация идеи плохая, что делать будете делать если VOIP провайдер разрешит прямой RTP трафик со своими партнёрами?
- плохая проработка первоисточников, применены топорные методы маркировки целевого трафика в связи с непониманием всех механизмов.
Вся фирма в гигасетах. И шлюз микрот 2011, никаких проблем нет.
Захват пакетов, на мой вкус, удобнее делать в Wireshark с фильтром udp port 37008.
А анализировать дампы в меню Телефония -> RTP -> Потоки RTP. По графикам часто проблема весьма наглядно видна.
Но это всё — моё ИМХО :)
Прерывается голос, слышу эхо… Плохое качество связи ip-телефонии. Как можно решить самостоятельно?