Как настроить приоритет голоса в Asterisk и сети

Если голос хрипит только под нагрузкой, сначала найдите очередь, где копятся пакеты, и проверьте потери. Затем задайте метки RTP, сохраните их на доверенных портах и настройте очередь на перегруженном исходящем интерфейсе. QoS не ускорит канал: он даст голосу предсказуемое место в очереди. Эффект подтверждайте одинаковыми замерами до и после.

Почему голос портится именно в часы пик

Голосу нужно немного полосы, но он плохо переносит очереди и потери. Для одного вызова G.711 сам кодек передаёт 64 кбит/с в каждую сторону; вместе с RTP, UDP, IP и канальным уровнем расход получается выше и зависит от размера голосового кадра и инкапсуляции. При обычной пакетизации появляются регулярные небольшие пакеты. Один звонок редко забивает современный канал. Десятки звонков, видеосвязь и выгрузка файлов уже могут столкнуться на одном выходном интерфейсе. Если вы держите офисную АТС на ИТ-аутсорсинге, качество связи надо проверять под нагрузкой, а не по скорости тарифа на бумаге.

Я сначала отделяю симптомы сети от проблем кодека, телефона и самого Asterisk. Сравниваю счётчики интерфейсов, потери и задержки во время одинаковых тестовых звонков — без нагрузки и при контролируемой передаче данных. Если очередь не образуется, QoS ничего не изменит. Если она растёт на аплинке коммутатора, правила на интернет-роутере не помогут; если перегружен WAN, лечить нужно именно его очередь. Универсальной кнопки «сделать голос хорошим» нет, и это даже к лучшему: её обычно включают не там.

В офисе на 20–50 мест узким местом часто оказывается исходящий канал, но слово «часто» не заменяет проверку. Внутри сети могут упираться аплинк, Wi-Fi или интерфейс сервера. Я фиксирую место перегрузки до настройки, иначе после изменений легко приписать QoS чужое улучшение или, наоборот, обвинить его в проблеме на другом участке.

SIP и RTP: что именно размечать

SIP управляет вызовом: регистрацией, установлением и завершением соединения. RTP переносит аудио. Потеря SIP-сообщения может задержать операцию, но именно RTP обычно отвечает за слышимые провалы голоса во время разговора. Для RTP-телефонии распространённая метка — DSCP EF, кодовая точка 46. RFC 4594 рекомендует для SIP-сигнализации CS5. Встречается и CS3 из старых или вендорских профилей; смешивать значения без единого правила не надо. Сначала решите, какие классы поддерживает ваша сеть, затем проверьте маркировку и политику на каждом устройстве.

В Ethernet с VLAN-тегом есть отдельное поле приоритета 802.1p (PCP, значения 0–7). Это локальная метка канального уровня, а не замена DSCP: при маршрутизации VLAN-тег снимается, а DSCP остаётся в IP-пакете, если узел его не переписывает. Значение PCP 5 часто выбирают для голоса, но это локальная политика, а не обязательное правило для любой сети. На границах провайдера метку могут сохранить, изменить или игнорировать — заранее проверьте условия услуги и реальное поведение канала.

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

• RTP: EF (DSCP 46) как распространённый профиль
• SIP: CS5 по RFC 4594; сверить политику устройств
• 802.1p PCP: локальная настройка VLAN
• Видео: отдельный класс по возможностям оборудования
• Остальной трафик: базовый класс

Разметка на телефоне и в Asterisk

Метка полезна только тогда, когда проходит по всей цепочке и оборудование действительно использует её при планировании пакетов. Некоторые модели IP-телефонов умеют отдельно задавать DSCP аудио и сигнализации, но это надо проверять по документации конкретной прошивки. Если телефонов несколько, сохраняйте параметры в профиле автонастройки. Ручная настройка пяти аппаратов переживает смену специалиста хуже, чем один понятный шаблон. Если телефон снова получает заводские параметры, настройку нужно уметь восстановить, а не вспоминать по скриншоту.

В Asterisk с chan_pjsip параметры tos_audio и cos_audio указывают метки для RTP-аудио; tos_video и cos_video — для видео. Параметры tos и cos в секции transport задают TOS/CoS для SIP-сигнализации. Ниже короткий фрагмент: имена секций подставляйте из своей рабочей конфигурации. Документация Asterisk подтверждает эти параметры; изменение transport требует полного перезапуска Asterisk, простого reload недостаточно. Я не перезапускаю АТС вслепую днём: планирую окно и проверяю регистрацию после него. Подробности конфигурации PJSIP собраны в руководстве по PJSIP в Asterisk.

[transport-udp]
type=transport
protocol=udp
tos=cs5
cos=3

[office-phone]
type=endpoint
tos_audio=ef
cos_audio=5

Проверяйте не только текст конфигурации, но и пакет на интерфейсе. В tcpdump параметр -v показывает IP-поле TOS; EF обычно отображается как 0xb8, если биты ECN не меняют младшие биты. Значение на сервере подтверждает только то, что пакет вышел оттуда с такой маркировкой. Чтобы найти, где её переписали, сравните захваты на последовательных участках сети. Фильтр захвата ограничивайте портами, указанными в настройках вашей системы. Для краткой проверки ниже показан общий фильтр UDP.

tcpdump -ni any -v udp -c 10

Если меняете настройки телефонов централизованно, проверьте профиль и фактическую конфигурацию аппарата — полезный разбор есть в статье почему телефон не берёт автоконфигурацию.

Коммутатор: голосовой VLAN и граница доверия

Управляемый коммутатор даёт больше контроля над VLAN, очередями и доверенными метками, но само слово «управляемый» не гарантирует нужную функцию или достаточную производительность. Неуправляемое устройство иногда пересылает уже помеченный трафик, однако обычно не даёт администратору надёжно проверить и настроить поведение очередей. Сверьте документацию модели и посмотрите счётчики под нагрузкой, прежде чем менять оборудование. Покупать новый коммутатор только потому, что старый «не умеет QoS», без проверки — дорогой способ не найти причину.

Голосовой VLAN помогает разделить телефоны и компьютеры, если его поддерживают телефоны и коммутатор. Настройте VLAN на обоих концах и проверьте, что телефон действительно отправляет голосовой трафик в нужную сеть; одна запись в конфигурации коммутатора этого не доказывает. Отдельно задайте границу доверия: на порту телефона можно принять разрешённые метки, а на обычном пользовательском порту — сбрасывать или переписывать их согласно политике. RFC 4594 также рекомендует проверять маркировку недоверенных устройств на входе. Иначе любая станция, которой вы разрешили сама назначать высокий класс, может конкурировать за очередь голоса.

Проверьте аплинки между коммутаторами и загрузку интерфейса сервера в часы пик. Если несколько этажей делят один перегруженный линк, очередь может возникать до роутера. Тогда DSCP на выходе в интернет не решит локальную задержку. Я смотрю не только среднюю загрузку за сутки, но и короткие пики, ошибки интерфейса, отброшенные пакеты и состояние самого устройства. У среднего значения есть талант скрывать именно те секунды, когда разговор разваливается.

• Проверьте возможности модели коммутатора
• Разделите голосовой и пользовательский VLAN при необходимости
• Доверяйте меткам только от заданных устройств
• Снимите счётчики на перегруженных аплинках

Маршрутизатор: шейпинг и очередь на выходе

Для исходящего трафика очередь должна собираться на вашем управляемом устройстве, если оно способно передавать данные медленнее фактического узкого места и обслуживать классы по правилам. Номинальная скорость тарифа и скорость порта — не одно и то же; тариф может быть асимметричным, а реальная пропускная способность меняться. Поэтому я измеряю канал в рабочее время и настраиваю ограничение по результату и возможностям платформы. Фиксированное правило «поставить на 5–10 процентов ниже» не универсально: оно может зря съесть полосу или не перенести очередь к вашему роутеру.

В очереди выделяют класс для EF-аудио и задают ему ограничение или политику, чтобы один источник не занял весь канал. Для SIP-сигнализации, видеосвязи и остального трафика выбирают классы по возможностям устройства и ожидаемой нагрузке. На MikroTik используются механизмы очередей RouterOS, включая queue tree; конкретная классификация зависит от версии и схемы подключения. Сверяйте конфигурацию с руководством своей платформы. Приоритет не отменяет контроль полосы: если дать одному классу безлимитный строгий приоритет, другие потоки могут голодать.

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

Разбор: проектная группа «Акустический профиль»

Возьмём сценарий проектной группы «Акустический профиль»: 20 рабочих мест, локальный Asterisk, телефоны на столах, тариф с заявленной скоростью 100 Мбит/с. Во второй половине дня сотрудники отправляют крупные проектные файлы и проводят видеосовещания, а на звонках жалуются на хрип. Утром проблема не повторяется. Это описание задаёт гипотезу, а не диагноз: цифра тарифа не доказывает, что перегружен именно исходящий канал, и QoS-пресет на роутере сам по себе ничего не подтверждает.

Сначала сравниваем состояние сети на спокойном участке и во время повторяемой выгрузки. Проверяем счётчики интерфейсов, потери и задержки в активном разговоре, маркировку пакетов и статистику очередей на оборудовании. В Asterisk доступность и состав статистики зависят от версии и драйвера, поэтому сначала проверяем, что именно показывает установленная система, и не выдаём её данные за измерение всего пути. Если потери растут на WAN, а LAN чист, настраиваем исходящий шейпер и классы там; если проблема на аплинке, работаем с ним. Для каждого изменения записываем исходные значения.

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

Как доказать, что QoS работает

Ориентир ITU-T G.114 часто связывают с 150 мс односторонней задержки, но это не универсальная граница между «работает» и «не работает». Рекомендация обсуждает влияние сквозной задержки и отмечает, что интерактивная речь может страдать при меньших значениях; для общего сетевого планирования в действующей редакции приводится верхняя рекомендация не превышать 400 мс. В VoIP итог включает кодек, пакетизацию, буферы и весь маршрут, а не только локальный роутер. Поэтому я использую норматив как контекст, а не как индульгенцию для плохого звука.

Сравнивайте одинаковые звонки без нагрузки и под контролируемой нагрузкой до и после изменений. Смотрите задержку, джиттер и потери там, где доступна статистика, а затем сопоставьте её с интерфейсными и очередными счётчиками. Универсальная цифра потерь, подходящая всем кодекам, маршрутам и устройствам, здесь только запутает. Если Asterisk не показывает нужную метрику, измеряйте её подходящим сетевым инструментом или на конечных устройствах. Результат настройки — это повторяемое улучшение под той нагрузкой, которая действительно мешала работе.

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

• Одинаковая нагрузка до и после настройки
• Потери, задержка и джиттер по доступным метрикам
• Счётчики очередей и интерфейсов
• Проверка слышимости и обычного трафика

Частые вопросы