QoS для голоса и видеосвязи: настройка и проверка в сети

Что ломается в звонках и видеовстречах и почему

Самые частые жалобы в голосе и видео звучат похоже: «собеседник как робот», «пропадают слова», «эхо», «видео рассыпается на квадраты», «картинка замирает», «то слышно, то нет», «созвон обрывается при включении демонстрации экрана». При этом тест скорости может показывать хорошие цифры, а проблема все равно остается.

Чаще всего дело не в «маленьком канале», а в том, как трафик проходит очереди в сетевом оборудовании. Когда где-то возникает перегрузка (на WAN, на uplink коммутатора, на Wi-Fi, на VPN-шлюзе), пакеты начинают копиться. Голосу и видео важна предсказуемость, а не рекордная пропускная способность.

Есть три вещи, которые важно различать:

• Задержка: сколько времени пакет идет от вас до собеседника.
• Джиттер: насколько «плавает» эта задержка от пакета к пакету.
• Потери: сколько пакетов не дошло вовсе.

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

Без приоритета голос и видео конкурируют с любым «толстым» трафиком: загрузками файлов, обновлениями, резервным копированием, синхронизацией облака. Пример: в бухгалтерии запускается бэкап на сетевое хранилище, uplink коммутатора забивается, очередь растет, и звонок руководителя превращается в набор обрывков.

QoS для голоса и видеосвязи решает проблему не «ускорением интернета», а правилами: что считать важным, как пометить трафик и в какую очередь его поставить, чтобы при перегрузке первыми проходили пакеты разговора, а не большие передачи данных.

Какие показатели считать нормой и что измерять

Чтобы очереди и приоритезация трафика реально работали, заранее договоритесь, какие цифры вы считаете «хорошо» и как вы их меряете. Иначе вы настроите правила, а потом не сможете доказать, что стало лучше.

Главные метрики для голоса и видео

Для качества разговоров и встреч почти всегда важны задержка, джиттер и потери. Они напрямую превращаются в «роботизированный» звук, обрывы фраз и рассыпание картинки.

Ориентиры без привязки к вендору:

• Задержка (one-way): для голоса желательно до 150 мс, для видео часто терпимо до 200 мс.
• Джиттер: для голоса лучше до 20-30 мс, для видео до 30-50 мс.
• Потери: для голоса стремитесь к 0-1%, для видео заметно уже около 1% (особенно при всплесках).

Полезные дополнительные индикаторы: повторные передачи (где доступны) и короткие пики по очередям. Часто именно очередь на выходе интерфейса становится главным источником проблем.

Эти значения не «магические». Важнее, чтобы они держались ровно и не срывались в пики.

Почему важна стабильность, а не среднее

Средняя задержка 30 мс выглядит идеально, но если раз в минуту случается пик до 300 мс, люди все равно будут перебивать друг друга и переспрашивать. Поэтому смотрите не только average, но и 95-й перцентиль, максимум и частоту всплесков.

Типичный случай: при копировании больших файлов средняя потеря почти нулевая, но каждые 10-20 секунд появляется короткий всплеск потерь и джиттера. Пользователи жалуются именно в эти моменты, хотя «в среднем все нормально».

Какие 2-3 метрики отслеживать постоянно

Чтобы не утонуть в графиках, держите минимум, который дает ясную картину:

• джиттер и потери для голосового трафика;
• задержка (и p95) на ключевом WAN-интерфейсе или на стыке в интернет;
• длина очереди и drops на выходных интерфейсах, где чаще всего возникает перегруз.

Так проще понять, стало ли лучше после приоритезации, и где именно качество «ломается».

Инвентаризация: где в сети проходит голос и видео

Перед настройкой разложите трафик по маршрутам: где он появляется и через какие устройства реально проходит. Иначе вы настроите QoS «в целом по сети», а проблема останется на одном перегруженном коммутаторе, на WAN-канале или в Wi-Fi.

Начните с источников. Голос и видео дают не только IP-телефоны: это софтфоны на ноутбуках, переговорные системы, мобильные клиенты в корпоративном Wi-Fi, иногда серверные компоненты (шлюзы, SBC, запись разговоров, VDI). Для каждого источника важно знать тип подключения (провод, Wi-Fi, VPN) и «первый прыжок» (access-коммутатор, контроллер Wi-Fi, VPN-шлюз).

Затем зафиксируйте направления: внутри офиса, между филиалами, в ЦОД, в облако, в интернет. Один и тот же пользователь может созваниваться то с коллегой в соседнем кабинете, то с партнером снаружи, и эти пути нагружают сеть по-разному.

Быструю карту путей и узких мест часто реально собрать за 1-2 часа:

• отметьте критичные зоны (колл-центр, переговорные, приемная, учебные классы);
• найдите на коммутаторах порты, где сидят телефоны и переговорные системы (MAC/LLDP, описания портов);
• выпишите точки, где скорость может «просесть»: аплинки 1G, перегруженные межVLAN-интерфейсы, WAN, VPN, Wi-Fi;
• снимите текущую загрузку и ошибки на этих интерфейсах (пики, drops, очереди);
• опишите 2-3 типовых сценария звонков и видеовстреч и их маршрут.

Отдельно разделяйте потоки. Для качества важнее всего медиа (RTP/SRTP): оно чувствительно к задержке и потерям. Сигнализация (SIP, HTTPS у облачных сервисов) обычно легче по объему, но ее сбои выглядят как «не дозванивается».

Практичный пример: видеовстречи между филиалом и ЦОД идут через VPN, а звонки с IP-телефонов - напрямую по MPLS. Если вы смотрите только «IP-телефонию», легко пропустить узкое место на VPN-шлюзе, где видео теряет приоритет и начинает сыпаться при вечерних бэкапах.

Маркировка трафика: DSCP и 802.1p без путаницы

Маркировка DSCP и 802.1p - это способ «пометить» пакеты, чтобы коммутаторы и маршрутизаторы понимали, что пропускать первым, а что может подождать. Обычно используют DSCP в IP-заголовке (уровень 3) и 802.1p/CoS в VLAN-теге (уровень 2). Важно не просто выбрать «правильные цифры», а добиться трех вещей: метки ставятся в одном месте, сохраняются по пути и одинаково трактуются всеми узлами.

Удобно договориться о коротком наборе классов и закрепить его на endpoints, точках доступа, коммутаторах и шлюзах. Типовой минимум:

• голос (RTP): DSCP EF (46), CoS 5
• видео (встречи/видео RTP): DSCP AF41 (34), CoS 4
• сигнализация (SIP/H.323): DSCP CS3 (24), CoS 3
• «остальное»: DSCP 0, CoS 0

Где ставить метки

Идеальный вариант - когда метку ставит источник: IP-телефон или приложение видеосвязи, если оно умеет. Но часть клиентов ошибается или намеренно завышает приоритет. Поэтому на практике метку часто ставят или исправляют на порту доступа (edge): коммутатор или Wi-Fi-контроллер классифицирует поток по VLAN, порту, ACL, NBAR и затем проставляет DSCP/CoS.

На WAN-шлюзе (или пограничном маршрутизаторе) маркировку обычно проверяют и при необходимости перемаркируют перед выходом в канал. Именно там начинаются очереди и ограничения полосы.

Граница доверия (trust boundary)

Trust boundary - это место, после которого вы «верите» метке и перестаете ее менять. Хорошее правило: доверяйте только управляемым устройствам (IP-телефонам, корпоративным видеотерминалам), а все остальное перемаркируйте на входе.

Чтобы метки не терялись по пути, помогает простая логика:

• на портах к телефонам - trust для телефона, но не для ПК за телефоном (PC-port);
• на пользовательских портах - не trust, классификация и маркировка на коммутаторе;
• на транках - сохранять CoS и при необходимости маппить CoS <-> DSCP;
• на Wi-Fi/VPN - проверить, что DSCP не «обнуляется» при инкапсуляции;
• на WAN-границе - единая таблица классов и одинаковые значения DSCP в обе стороны.

Пример: если видеоклиент на ноутбуке шлет DSCP 46 «как голос», не доверяйте этому. Перемаркируйте на доступе до AF41 и дайте приоритет, но не такой, который может вытеснить речь.

Очереди и планировщики: как реально дать приоритет

Очереди QoS почти всегда дают эффект на выходе интерфейса, а не на входе. На выходе устройство решает, что отправить в линию прямо сейчас, и может выстроить пакеты по порядку. На входе пакеты уже прилетели, и если порт перегружен, остается только ограничивать, буферизовать или выбрасывать.

Логика простая: голосу нужен минимальный джиттер, видео важнее «не терять», а остальному трафику обычно можно подождать чуть дольше. В типовой схеме используют два подхода вместе: приоритетную очередь для самого чувствительного трафика и очереди по весам для остального.

Базовая схема очередей, которая обычно работает

Это не «единственно правильные цифры», а понятный старт:

• приоритетная очередь (LLQ) для голоса - обслуживается первой, но с жестким ограничением по полосе;
• отдельная очередь для видео - гарантированная доля плюс верхний предел;
• очередь для критичных бизнес-приложений - весовая, без абсолютного приоритета;
• «все остальное» - самая низкая, но не нулевая.

Не выделяйте «полосу под голос и видео» вслепую. Если дать видео слишком много, оно начнет давить приложения. Если дать голосу приоритет без лимита, любой трафик при ошибочной маркировке сможет «притвориться» голосом и вытеснить все.

Как пережить burst-трафик простыми методами

Burst появляется, когда трафик идет рывками (обновления, бэкапы, большие вложения). Два базовых инструмента чаще всего дают быстрый эффект:

• Шейпинг: сглаживает рывки, растягивая отправку по времени. Полезен на WAN, когда порт быстрее реального канала.
• Полисинг: жестко ограничивает поток. Нужнее на входе, где «планировщик» не поможет.

WRED можно понимать как «раннее умное сбрасывание»: когда очередь заполняется, устройство заранее выбрасывает часть менее важного трафика, чтобы не довести до полной пробки и массовых потерь. Это помогает фоновым потокам замедлиться и оставляет место для голоса и видео.

WAN и интернет-каналы: шейпинг и полисинг

В LAN узким местом чаще бывают очереди на портах коммутаторов, и там приоритезация обычно работает предсказуемо. На WAN все сложнее: канал ограничен по скорости, а провайдер часто применяет свои правила. Именно на стыке с интернетом или MPLS обычно и появляются задержка, джиттер и потери.

Главная идея: лучше, чтобы очередь и отбрасывание пакетов происходили у вас на роутере (где вы управляете приоритетами), а не у провайдера (где голос и видео для него просто «обычный трафик»). Для этого на выходе в WAN обычно делают шейпинг - ограничивают скорость чуть ниже реальной пропускной способности канала.

Практика настройки скорости:

• узнайте реальную скорость по договору и по факту (в разное время суток);
• выставьте шейпер на 90-95% от гарантированной скорости, чтобы не попадать под полисинг провайдера;
• примените очереди и приоритеты до шейпера, чтобы голос/видео уходили первыми при перегрузке;
• проверьте настройки отдельно для upload и download (часто «болит» именно upload).

Жесткий полисинг (особенно с мгновенным cut) опасен для голоса и видео. Он часто отбрасывает пакеты рывками, а не равномерно. В результате растет джиттер, появляются «роботы» в голосе и квадраты в картинке. Если полисинг нужен (например, чтобы ограничить гостей или прожорливые бэкапы), применяйте его к неважным классам, а критичный трафик оставляйте под шейпингом.

Отдельная ловушка - накладные расходы инкапсуляции. PPPoE, VLAN-теги, GRE/IPsec, L2TP и другие туннели уменьшают полезную полосу и меняют размер кадров. Если считать скорость «впритык», шейпер окажется выше реальной линии, и потери начнутся у провайдера. Обычно помогает запас 5-10% и проверка реального MTU/MSS при активных VPN.

Пример: филиал подключен по 50 Мбит/с, но весь трафик идет через IPsec. Если выставить шейпинг ровно 50, то при нагрузке провайдер начнет резать пакеты, и видеозвонки первыми почувствуют джиттер. Шейпинг 45-47 Мбит/с плюс приоритетные очереди обычно дает более ровное качество.

Wi-Fi и VPN: как не потерять приоритет на последней миле

Даже если очереди настроены на коммутаторах и WAN, качество часто «сыпется» на последней миле: в Wi-Fi и в VPN. Там приоритет легко теряется, а задержка и джиттер растут рывками.

В Wi-Fi критична поддержка WMM (Wi-Fi Multimedia) - это механизм очередей и приоритета на стороне беспроводного доступа. Если WMM отключен или работает некорректно, голос и видео начинают конкурировать с обычными загрузками на равных: одному ноутбуку достаточно начать скачивание, и в звонке появятся паузы, «робот» и смазанная картинка.

Wi-Fi: роуминг и перегрузка точки доступа

Джиттер дает не только канал, но и радиосреда. Роуминг между точками доступа может занимать заметное время, а при высокой нагрузке на одну точку очередь растет, пакеты ждут и приходят «кучками». Типичная ситуация: переговорная, 15 человек в видеовстрече, плюс пара гостей с обновлениями в фоне.

Что посмотреть на контроллере или точке доступа:

• включен ли WMM на SSID, где сидят пользователи звонков;
• сколько клиентов на одной точке и какой реальный airtime/utilization;
• нет ли частых перескоков между точками во время звонка;
• нет ли сильных повторных передач (retries) из-за помех или слабого сигнала.

VPN: где пропадает DSCP и как это проверить

В VPN приоритет часто «смывается» в двух местах: при шифровании (когда внешний заголовок не несет нужной маркировки) и на границе сети (когда провайдер или оборудование обнуляет DSCP). Бывает и проще: внутри туннеля метки есть, а снаружи они не выставляются, и дальше все идет как best effort.

Проверка без сложной лаборатории: запускаете тестовый звонок, параллельно создаете фоновую загрузку и снимаете захват трафика до входа в VPN и после выхода. Сравните DSCP в пакетах RTP/видеопотока и во внешнем заголовке туннеля. Если метки исчезают, настраивайте копирование/перемаркировку на VPN-шлюзе и очереди на исходящем интерфейсе.

Для удаленных пользователей важно понимать границы контроля. На вашей стороне - VPN-шлюз, корпоративный Wi-Fi и политики на пограничных маршрутизаторах. Домашний роутер сотрудника вы не исправите, но можете снизить риск: дать рекомендации по подключению к 5 ГГц, ограничить фоновый трафик в корпоративном VPN и проверить, что рабочие ПК и тонкие клиенты корректно ставят маркировку на исходящем трафике.

Пошаговый план внедрения QoS в реальной сети

Как идти шаг за шагом

QoS для голоса и видеосвязи должен держать качество в часы пик, когда сеть действительно загружена. Поэтому план строится вокруг узких мест, а не вокруг идеи «настроим по чуть-чуть везде».

1. Определите классы трафика. Обычно хватает 3-4 классов: голос, видео, важные бизнес-приложения, «все остальное». Классификацию делайте по тому, что у вас стабильно доступно: VLAN/подсеть телефонии, IP-адреса медиа-серверов, сигнальные порты или метки от UC-клиента.

2. Опишите границы доверия. На доступе не стоит верить любому DSCP от пользовательского ПК. Типичный вариант: доверять IP-телефонам и видеотерминалам, а трафик с ПК перемаркировать по вашим правилам на первом коммутаторе или на edge-роутере.

3. Дайте приоритет там, где образуется очередь. В большинстве сетей это выход в WAN/интернет и межсегментные uplink-каналы. На этих интерфейсах включают очереди: голосу дают строгий приоритет с ограничением, видео помещают в гарантированную очередь, остальному оставляют остаточную полосу.

4. Удержите фон под контролем. Обновления, бэкапы и синхронизации лучше ограничивать по времени и скорости в рабочие часы, особенно на WAN.

Порядок работ, который обычно не растягивается на месяцы:

• зафиксировать классы и правила, по которым вы узнаете голос и видео;
• настроить маркировку и trust boundary от доступа до WAN;
• включить очереди на самых загруженных выходах и проверить, что приоритет не «съедает» весь канал;
• ограничить фоновые передачи в часы работы;
• включить мониторинг счетчиков QoS и начать с пилота (один офис или один этаж).

После пилота сравните качество на тех же сценариях: 2-3 параллельных звонка, видеовстреча и одновременная фоновая загрузка. Если счетчики показывают рост трафика в приоритетных очередях, а жалобы уходят, масштабируйте настройки по шаблону на остальные площадки.

Методика измерений до и после: как доказать эффект

Польза от QoS лучше всего видна в цифрах. Сначала снимите базовую линию: одинаковые метрики, одинаковые точки измерения, одинаковые условия.

Базовая линия: как мерить «до»

Снимайте данные серией, а не один раз. Иначе вы сравните «удачный день» с «плохим».

• Выберите 2-3 типичных периода: утренний пик, дневная нагрузка, поздний час.
• Собирайте 3-5 рабочих дней подряд, чтобы увидеть повторяемость.
• Фиксируйте загрузку WAN, потери на стыке, число активных звонков.
• Запишите текущие политики: есть ли маркировка, очереди, шейпинг, где именно.
• Определите точки: коммутатор доступа, WAN-край, Wi-Fi-контроллер (если есть).

Дальше сделайте активные тесты: в одно и то же время запускаете видеозвонок на 10 минут и параллельно создаете контролируемую фоновую нагрузку (например, копирование большого файла). Повторите сценарий несколько раз, чтобы увидеть, когда начинается деградация.

Пассивные данные берите из отчетов UC-систем (MOS/качество, джиттер, потери), а также из сетевой статистики: drops на интерфейсах, заполнение очередей, счетчики policy-map/class-map (или аналогов).

Сравнение «до/после» без самообмана

В отчете лучше всего работают простые, сопоставимые артефакты:

• график задержки, джиттера и потерь по часам;
• таблица p95/p99 (не только среднее) до и после;
• выгрузка: доля drops по классам и заполнение очередей;
• сопоставление с загрузкой канала, чтобы было видно, что улучшение не из-за того, что «просто стало свободнее».

Чтобы отделить эффект приоритезации от других изменений, не меняйте маршрутизацию и пропускную способность параллельно, фиксируйте путь трафика и держите одинаковый тестовый сценарий. Если изменения неизбежны, отметьте их в журнале работ и сравнивайте только одинаковые интервалы нагрузки.

Типовые ошибки QoS и как быстро их найти

Частая ситуация: вы разметили трафик, но качество не улучшилось. Обычно проблема не в самой маркировке DSCP и 802.1p, а в том, что метка нигде не превращается в реальный приоритет в очередях на выходе.

Метки есть, а приоритета нет

DSCP или 802.1p выставлены правильно, но на пограничном роутере или коммутаторе нет привязки «класс -> очередь». Тогда голос и видео едут в общей очереди вместе с загрузками и обновлениями.

Быстрая проверка: посмотрите счетчики классов на egress-интерфейсе. Если классы «голос/видео» не растут или попадают в ту же очередь, что Best Effort, значит приоритета фактически нет.

Неверная граница доверия (trust boundary)

Если доверять меткам на пользовательских портах, любой ПК может «назначить» себе приоритет и вытеснить звонки. В реальной сети trust ставят ближе к источнику голоса (IP-телефон, SBC, MCU) или на порту, где телефон стоит перед ПК и коммутатор умеет различать их трафик.

Приоритетная очередь настроена неправильно

Ошибка бывает в обе стороны: приоритетная очередь слишком маленькая (голос теряет пакеты при нагрузке) или слишком большая (голос «съедает» канал и ломает остальное). Признак: даже при умеренной нагрузке растут drops в приоритетном классе или, наоборот, остальные классы постоянно «голодают».

Небольшой пример: видеовстречи «сыпятся» только когда кто-то качает файл в филиал. Оказалось, видео размечено, но на WAN-выходе нет очереди под этот класс, а приоритет отдан только голосу.

Качество падает только в одном направлении

Иногда QoS настроили почти везде, но забыли egress на одном стыке (например, на одном коммутаторе доступа или на одном из WAN-роутеров). Тогда «туда» звук нормальный, «обратно» - с обрывами.

Короткий набор проверок, который часто находит проблему за 15 минут:

• сравнить политику QoS и счетчики на обоих концах проблемного линка;
• проверить, что нужный класс применен именно на выход (egress), а не только на вход;
• посмотреть drops по очередям и наличие микроберстов (если поддерживается).

Полисинг режет RTP

Полисинг на WAN может резать короткие всплески RTP/видео и давать потери даже при «незаполненном» канале по среднему. Признак: потери растут в конкретном классе, но общая загрузка линка ниже порога. Обычно помогает более мягкий шейпинг, корректные burst-параметры и выравнивание скорости под реальную полосу провайдера.

В большой организации полезно вести «карту» QoS: где доверяем меткам, где включены очереди, где стоит шейпинг. Так быстрее найти один узел, который выбивается из общей схемы.

Быстрый чек-лист и следующие шаги

Если после настройки качество стало лучше, закрепите результат и проверьте, где еще остались слабые места. Этот короткий чек-лист удобно прогонять за 30-60 минут после любых изменений в сети.

Быстрый чек-лист

Проверьте по реальному звонку или тестовому видеосеансу в час пик:

• метки на месте: голос и видео выходят из endpoints с нужным DSCP, а на коммутаторах виден корректный 802.1p (если используете);
• очереди активны: на WAN-устройстве и ключевых коммутаторах приоритетная очередь обслуживается первой, без голодания остальных;
• нет «дропа приоритета»: трафик не уходит в общий класс из-за неверного match или перезаписи;
• буферы под контролем: нет постоянной перегрузки очередей, особенно на узких каналах и аплинках;
• результат в цифрах: задержка, джиттер и потери для голоса и видео лучше, чем «до», и держатся стабильно.

Если что-то не сходится, проверяйте маршрут последовательно: телефон или ПК, затем access-коммутатор, дальше ядро, затем пограничный маршрутизатор и провайдерский стык. Чаще всего метки теряются на границе доменов (между офисом и филиалом, перед VPN, в Wi-Fi), а очередь «копится» на самом узком месте, где нет шейпинга.

Как оформить результат

Чтобы согласовать изменения и не потерять настройки, оформите короткий отчет:

• «до/после»: 3-5 измерений в одинаковых условиях (час пик, один и тот же маршрут);
• снимки ключевых счетчиков: очереди, drops, utilization на узких линках;
• что именно настроено: классы, политики, где ставятся и где доверяются метки.

Дальше обычно ясно, что делать: вынести профиль QoS в стандарт (шаблоны для коммутаторов, Wi-Fi, WAN), расширить на филиалы и закрепить правило «не трогаем маркировку на транзите без причины».

Если нужна помощь с аудитом, внедрением и поддержкой, имеет смысл подключать системного интегратора. Например, GSE.kz как производитель и интегратор помогает выстраивать инфраструктуру под UC и видеосвязь: от сетевой части до подбора серверов и рабочих станций под нагрузку, с дальнейшим сопровождением.