Очень часто люди думают, что смогут получить идеальное качество VOIP по стандартным ADSL-соединениям с помощью какой-то магии в правилах QOS. Иногда это действительно возможно, но чаще всего — нет. Из-за перегрузки DSLAM, транспортной сети, провайдера, проблем со стабильностью DSL-соединения и качества трафика у провайдеров первого уровня итоговое качество (не всегда) хорошее, а иногда может быть очень плохим. Поэтому первое, что нужно проверить — это качество линии от конца до конца в течение недель или месяцев, лучше всего при помощи аппаратного тестера с EtherSAM, а если его нет — используйте более простые известные тестовые утилиты, доступные в Linux бесплатно. Если качество линии недостаточно хорошее для VOIP, тогда QOS не поможет. Первое, что нужно сделать — это исправить качество линии, сменив провайдера, используя лучшие медные линии, лучшие xDSL-модемы и, по возможности, никогда не отправлять трафик провайдерам первого уровня Интернета для связи с вашими центральными узлами. Всегда арендуйте частные оптоволоконные линии с SLA между дата-центрами и провайдерами. Это ключ к успеху. QOS поможет лишь в управлении совместным трафиком VOIP и DATA по одной линии, и в этом случае его нужно реализовать с обеих сторон канала для исходящего трафика. Попытки делать QOS на входящем трафике работают только для замедления TCP и работают плохо, потому что замедление требует времени, чтобы стать эффективным. Это значит, что полностью защитить входящий трафик от перегрузки нельзя без правил QOS на стороне отправителя. Чтобы эффективно управлять QOS на DSL-соединениях, вам нужно быть самим провайдером или, по крайней мере, иметь приватный роутер на стороне провайдера. Это единственный способ получить полноценный двунаправленный QOS. Есть и другие советы, например использовать максимально быстрые DSL-линии, которые только можно получить. Это облегчает планирование пакетов в планировщике QOS. Управлять IP QOS на линиях со скоростью 128 кбит/с невозможно из-за размера DATA-пакетов: 1500 байт. Когда DATA-пакет передаётся, что бы вы ни делали, нужно дождаться окончания передачи, прежде чем отправить VoIP-пакет, из-за чего на медленных линиях возникает сильный джиттер. Если вам нужен QOS для VoIP на таких медленных линиях, тогда стоит использовать QOS более низкого уровня — ATM, учитывая намного меньший размер ATM-клеток. IP QOS на медленных линиях никогда не сработает, неважно, какие правила QOS и настройки очереди вы применяете (Cisco имеет функцию автофрагментации, которая улучшает VoIP QOS на медленных линиях, но на Linux этого нет). Ещё вариант — использовать двойные ADSL-линии с двумя разными ATM VCI и ATM QOS, один для VoIP, другой для DATA. Но для этого нужны специальные ADSL-линии и модемы с поддержкой много VCI, а такие предложения обычно недоступны большинству пользователей в большинстве стран. Во Франции, например, есть triple play-линии (VoIP, DATA, TV), но только у крупных провайдеров и то в составе комплексных тарифов, а не для профессионального использования. Правила QOS довольно просто внедрять для управления исходящим трафиком с помощью фильтрации DSCP или по исходным адресам — по крайней мере, если настройка роутера простая, с парой интерфейсов. При более сложных конфигурациях с множеством интерфейсов и туннелей правила QOS становятся гораздо сложнее и требуют очень тщательного проектирования трафик-маркировки внутри mangle и Queue trees. Небольшие ошибки здесь могут полностью свести на нет преимущества от использования QOS. Одна из проблем при управлении QOS на нескольких туннелях в MT-роутерах — это невозможность классифицировать пакеты сразу с нескольких клиентских PPTP или L2TP интерфейсов, исходящих с одного роутера. Только GRE-туннели имеют DSCP-маркировку, которую можно использовать для QOS. Для остальных туннелей единственный выход — смотреть внутри туннельного интерфейса пакеты, чтобы классифицировать трафик внутри туннеля.
