Голосовая связь : Качество голосовой связи

Устранение проблем QoS прерывистых речевых данных

5 апреля 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (22 августа 2015) | Отзыв


Содержание

VAD

Введение

Пакетная голосовая связь может претендовать на замену телефонных сетей общего пользования (ТфОП) только в том случае, если качество приема речи будет сопоставимым с обычной телефонной связью. Из этого вытекает необходимость стабильно высокого качества голосовой связи. Как и другие приложения реального времени, пакетная голосовая связь создает высокую нагрузку на пропускную способность и является чувствительной к задержкам. Чтобы речь была понятна абоненту на другой стороне (без треска и обрывов), голосовые пакеты не должны отбрасываться, чрезмерно запаздывать или иметь переменную задержку (последнее явление известно также как дрожание или колебание задержки). В этом документе описываются различные рекомендации для службы качества обслуживания (QoS), которые могут помочь устранить проблему прерывистого воспроизведения голосовых данных. Основной причиной проблем прерывистой передачи голосового сигнала является потеря или задержка голосовых пакетов.

Предварительные условия

Требования

Читатели данной документации должны быть хорошо осведомлены относительно них:

  • Базовая конфигурация Пакета речевых сигналов (VoIP, передача голоса по Frame Relay (VoFR) или Передача голоса по ATM (VoATM) согласно их требованию).

  • Основные понятия назначения приоритетов голосовых данных, фрагментирования, различных кодеков и их требований к пропускной способности.

Используемые компоненты

Сведения в этом документе применяются ко всем версиям программного и аппаратного обеспечения Голосовых шлюзов Cisco.

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

Условные обозначения

Дополнительные сведения об условных обозначениях см. в документе Технические рекомендации Cisco. Условные обозначения.

Причины прерывистого голоса

Причина прерывистого голоса в том, что голосовые пакеты либо по разному задерживаются, либо теряются в сети. При задержке получения пакета голосовых сигналов, шлюз назначения теряет данные, поступающие в реальном времени. В этом случае шлюз назначения должен предсказать, каково содержание пропущенного пакета может возможно быть. Прогноз приводит к полученному голосу, не имеющему те же характеристики как переданный голос. Это приводит к полученному голосу, который звучит автоматизированным. Если задержка голосового пакета превышает возможности прогнозирования принимающего шлюза, то шлюз оставляет интервал реального времени пустым. Ни с чем для заполнения того разрыва в принимающей стороне потеряна часть переданной речи. Это приводит к прерывистому голосу. Многие вопросы прерывистого голоса решены путем проверки, что голосовые пакеты не очень задержаны (и больше, чем это, не непостоянно задержаны). Иногда, обнаружение активности речи (VAD) добавляет ограничение внешнего интерфейса к речевому диалогу. Это - другая причина изменчивых (или отсеченный) голос.

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

Требования к полосе пропускания

Прежде чем вы будете полагать, что применение любых мер для уменьшения дрожания, условие достаточная пропускная способность сети поддерживает голосовой трафик в реальном времени. Например, вызов VoIP G.711 на 80 кбит/с (информационное наполнение на 64 кбит/с + заголовок на 16 кбит/с) звучит плохим по 64 связям со скоростью 64 кбит/с, потому что отброшены по крайней мере 16 кбит/с пакетов (который составляет 20 процентов). Требования пропускной способности варьируются на основе кодека, используемого для сжатия. Различные кодеки имеют различные величины полезной нагрузки и требования к заголовку. Использование VAD также влияет на требования пропускной способности. Если сжатие заголовка Протокола RTP (cRTP) используется, это может далее понизить требования пропускной способности.

Например, пропускная способность, требуемая для голосового вызова с помощью кодека G.729 (по умолчанию 20 байтов полезной нагрузки) с cRTP, походит на это:

  • Речевые данные + сжатый (заголовок RTP + заголовок Протокола UDP + IP - заголовок) заголовок +Layer 2

Это эквивалентно:

  • 20 байт + сжатые (12 байт + 8 байт + 20 байт) + 4 байт

Это равняется:

  • 28 байтов, так как сжатие заголовка уменьшает Заголовок IP RTP максимум до 4 байтов. Это дает 11.2 кбит/сек при скорости кодека 8 кбит/сек (50 пакетов в секунду).

Дополнительные сведения см. в разделе "IP-телефония: использование полосы пропускания для каждого вызова".

Приоритет речевого трафика

Существует два важных компонента в расположении по приоритетам голоса. Первое классифицирует и отмечает содержательный голосовой трафик. Второе располагает по приоритетам отмеченный содержательный голосовой трафик. Эти два подраздела здесь обсуждают различные подходы к классификации, маркировке и расположению по приоритетам голоса.

Классификация и маркировка

Для гарантии пропускной способности для Пакетов VoIP сетевое устройство должно быть в состоянии определить пакеты во всем IP - трафике, который течет через него. Для идентификации пакетов VoIP сетевые устройства используют IP-адрес пункта назначения и IP-заголовок или номера портов UDP в UDP-заголовке. Эту идентификацию и группирующий процесс называют классификацией. Это - основание для обеспечения любого QoS.

Классификация пакетов может быть сом интенсивной загрузкой процессора. Поэтому классификация должна быть сделана максимально далеко к краю сети. Поскольку на каждом участке нужно определять способ обработки полученного пакета, необходим более простой и эффективный метод классификации в самой сети. Эта более простая классификация осуществляется маркировкой или установлением байта типа службы (ToS) в IP-заголовке. Три Most Significant Bits байта ToS называют Двоичными значениями приоритета IP-трафика. Большинство приложений и поставщиков поддерживают настройку и распознавание этих трех битов. Методы маркировки развивается, поэтому теперь могут использоваться шесть наиболее значимых битов байта ToS, которые называются кодовой точкой дифференцированных сервисов (DSCP). Обратитесь к запросу RFC.

Дифференцированные сервисы (дифференцированные услуги (DiffServ)) являются новой моделью, в которой трафик обработан промежуточными системами с относительными приоритетами на основе поля ToS. Описание модели DiffServ, которая заменяет исходные спецификации для определения приоритетности пакета (см. стандарт RFC 791 ), содержится в стандартах RFC 2474 и RFC 2475 leavingcisco.com. leavingcisco.com leavingcisco.com DiffServ увеличивает количество определимых уровней приоритета путем перераспределения битов IP-пакета, используемых для маркировки приоритета. Архитектура дифференцированных услуг (DiffServ) определяет поле DiffServ. Это заменяет байт ToS в IP V4 для принятия решений Поведения при переходе (PHB) относительно классификации пакетов и функций согласования трафика, таких как измерение, маркировка, формирование и применение политик. В дополнение к ранее упомянутым RFC RFC 2597 leavingcisco.com определяет классы Гарантированной доставки (AF). Это - отказ полей DSCP. Дополнительную информацию по DSCP см. в разделе "Внедрение политик контроля качества обслуживания с DSCP".

Байт ToS - P2 P1 P0 T3 T2 T1 T0 CU

Протокол IP Precedence: три бита (P2-P0), ToS: четыре разряда (T3-T0), CU: один бит

Поле дифференцированных услуг (DiffServ) - DS5 DS4 DS3 DS2 DS1 DS0 ECN ECN

DSCP: шесть битов (DS5-DS0), ECN: два бита

Биты XXX00000 0, 1, 2 (DS5, DS4, DS3) являются битами приоритета, где:

  • 111 = Управление сетью = приоритеты 7

  • 110 = Межсетевой контроль = приоритеты 6

  • 101 = CRITIC/ECP = Приоритеты 5

  • 100 = Высший приоритет = приоритеты 4

  • 011 = Флэш = приоритеты 3

  • 010 = Непосредственный = приоритеты 2

  • 001 = Приоритет = приоритеты 1

  • 000 = Подпрограмма = приоритеты 0

Биты 000XXX00 3, 4, 5 (DS2, DS1, DS0) являются Задержкой, Пропускной способностью и битами Надежности.

  • Укусил 3 = задержка [D] (0 = обычный; 1 = низко)

  • Укусил 4 = пропускная способность [T] (0 = обычный; 1 = высокий)

  • Укусил 5 = Reliability[R] (0 = обычный; 1 = высокий)

Биты 000000XX 6, 7: ECN

Эти два раздела обсуждают два пути, которой классификацией и маркировкой сделаны.

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

С VOIP - шлюзами Cisco вы обычно используете речевые точки вызова, чтобы классифицировать Пакеты VoIP и отметить Двоичные значения приоритета IP-трафика. Эта конфигурация показывает, как отметить Двоичные значения приоритета IP-трафика:

dial-peer voice 100 voip
destination-pattern 100
session target ipv4:10.10.10.2
ip precedence 5

В приведенном выше примере любой вызов VoIP, который совпадает с командой dial-peer voice 100 voip, имеет весь свой пакетный набор речевых данных с IP Precedence 5. Это означает, что три Most Significant Bits байта ToS IP установлены в 101.

dial-peer voice 100 voip
destination-pattern 100
session target ipv4:10.10.10.2
ip qos dscp ef media
ip qos dscp af31 signaling

В приведенном выше примере любой вызов VoIP, который совпадает с командой dial-peer voice 100 voip, имеет все свои пакеты полезной нагрузки сред (голосовые пакеты) набор с битовым шаблоном Ускоренной пересылки (EF) 101110. Все пакеты сигнализации установлены с битовым шаблоном AF 011010.

Примечание: Команда ip qos dscp поддерживается начиная с Cisco Выпуск ПО IOS� 12.2 (2) T. IP Precedence больше не доступен в Cisco IOS Software Release 12.2T. Однако то же достигнуто командой ip qos dscp. IP precedence 5 (101) карты с IP DSCP 101000. За более подробной информацией обратитесь к Классификации передачи сигналов и средств связи протокола VoIP с DSCP для QoS.

Модульный QoS CLI для классификации и пометки пакетов

Классификация и метод маркировки, рекомендуемые для использования в модульном QoS CLI. Это - метод задания конфигурации на основе шаблона, который разделяет классификацию от политики. Это позволяет множественным Характеристикам QoS быть настроенными вместе для множественных классов. Используйте команду class-map для классификации трафика на основе различных условий соответствия и команды policy-map для определения что потребности произойти с каждым классом. Примените политику к входящему или исходящему трафику на интерфейсе путем запуска команды service-policy. Этот пример конфигурации показывает, как использовать Modular QoS CLI, чтобы классифицировать и отметить пакеты:

access-list 100 permit udp any any range 16384 32767
access-list 101 permit tcp any any eq 1720
!
class-map match-all voip
match access-group 100
class-map match-all control
match access-group 101
!
policy-map mqc
class voip
set ip precedence 5
class control
set ip precedence 5
class class-default
set ip precedence 0
!
interface Ethernet0/0
service-policy input mqc

В этом примере конфигурации любой трафик, который совпадает со Списком контроля доступа (ACL) 100, классифицирован как "voip класса" и установлен с IP Precedence 5. Это означает, что три Most Significant Bits байта ToS IP установлены в 101. ACL 100 совпадает с общими UDP-портами, используемыми VoIP. Так же ACL 101 совпадает с трафиком сигнализации H.323 (порт Протокола TCP 1720). Прочие виды трафика настраиваются со значением 0 в битах IP Precedence. Политику называют "mqc". Это применено к входящему трафику на Ethernet 0/0.

Расположение по приоритетам

После того, как каждый переход в сети в состоянии классифицировать и определить Пакеты VoIP (или через порт/адресную информацию или через байт ToS), те переходы тогда предоставляют каждый Пакет VoIP требуемым QoS. В той точке настройте специальные методы для предоставления приоритет, помещая в очередь, чтобы удостовериться, что большие пакеты данных не вмешиваются в передачу речевых данных. Это обычно требуется на более медленных каналах WAN, где существует высокая вероятность перегрузки. Как только весь представляющий интерес трафик размещен в классы QoS на основе их требований QoS, предоставьте гарантированные пропускные способности и приоритетное обслуживание через интеллектуальный механизм формирования очереди вывода. Для VoIP требуется очередь с приоритетами.

Примечание: Используйте любой механизм организации очередей, который эффективно дает высокий приоритет VoIP. Однако Организация очереди с малой задержкой (LLQ) рекомендуется, потому что это гибко и просто настроить.

LLQ использует метод задания конфигурации Modular QoS CLI, чтобы предоставить приоритет к определенным, некоторый классам и предоставить гарантированную минимальную пропускную способность для других классов. Во время периодов перегрузки очередь с приоритетами охраняется в настроенной скорости так, чтобы приоритетный трафик не израсходовал всю доступную пропускную способность. (Если приоритетный трафик монополизирует пропускную способность, он предотвращает гарантированные пропускные способности для других классов от того, чтобы быть встреченным.) При инициализации LLQ правильно трафик, который входит в очередь с приоритетами, никогда не должен превышать настроенную скорость.

LLQ также позволяет глубинам очереди быть заданными для определения, когда маршрутизатор должен отбросить пакеты, если существует слишком много пакетов, которые ждут в любой очереди отдельного класса. Существует также команда class-default, которая используется для определения обработки всего трафика, не классифицированного настроенным классом. Class-default настроен с командой fair-queue. Это означает, что каждому несекретному потоку дают приблизительно равную долю остатка полосы пропускания.

Данный пример показывает, как настроить LLQ. Для получения дополнительной информации обратитесь к Организации очереди с малой задержкой:

access-list 100 permit udp any any range 16384 32000
access-list 101 permit tcp any any eq 1720
access-list 102 permit tcp any any eq 80
access-list 103 permit tcp any any eq 23
!
class-map match-all voip
match access-group 100
class-map match-all voip-control
natch access-group 101
class-map match-all data1
match access-group 102
class-map match-all data2
match access-group 103
!
policy-map llq
class voip
priority 32
class voip-control
bandwidth 8
class data1
bandwidth 64
class data2
bandwidth 32
class class-default
fair-queue
!
interface Serial1/0
bandwidth 256
service-policy output llq

В данном примере любой трафик, который совпадает с ACL 100, классифицирован как "voip класса" (значение голосового трафика). Этому дают высокий приоритет до 32 кбит/с. ACL 100 совпадает с общими UDP-портами, используемыми VoIP. Access-list 101 совпадает с трафиком сигнализации H.323 (порт TCP 1720). Класс data1 совпадает с вебом - трафиком (порт TCP 80, как замечено в Списке доступа 102) и гарантии 64 кбит/с. Класс data2 совпадает с трафиком Telnet (порт TCP 23, как замечено в ACL 103) и гарантирует 32 кбит/с. Класс по умолчанию настроен так, чтобы поровну разделить оставшуюся пропускную способность между неклассифицированными потоками. Политику называют "llq". Это применено к исходящему потоку данных на Serial1/0, который имеет общую пропускную способность 256 кбит/с.

Примечание: По умолчанию общая гарантированная пропускная способность и приоритетная полоса пропускания для всех классов должны составить меньше чем 75 процентов полосы пропускания интерфейса. Модифицируйте этот процент путем запуска команды max-reserved bandwidth interface.

Эта таблица сравнивает другие механизмы организации очередей программного обеспечения с их соответствующими преимуществами и ограничениями.

Механизм организации очередей программного обеспечения Описание Преимущества Ограничения
First-In-First-Out (FIFO) Пакеты покидают очередь в порядке поступления. Простая настройка и быстрая работа. Невозможно гарантировать приоритетное обслуживание или полосу пропускания.1
Взвешенная справедливая очередизация (WFQ) Алгоритм хеширования, который течет в отдельные очереди, где веса используются для определения, сколько пакетов обслуживается за один раз. Вес определяется путем установки битов IP Precedence и значений DSCP. Простая конфигурация. Используется по умолчанию для каналов менее 2 Мбит/с. Невозможно гарантировать приоритетное обслуживание или полосу пропускания.1
Настраиваемая очередь (CQ) Трафик классифицируется по нескольким очередям с настраиваемым максимальным размером очереди. Максимальный размер очереди вычисляется на основе среднего размера пакета, максимальной единицы передачи данных (MTU) и процентной доли выделенной полосы пропускания. Предельные размеры очереди (в количестве байтов) исключены из очереди для каждой очереди. Поэтому это предоставляет выделенную полосу статистически. Было доступно в течение нескольких лет. Это позволяет приблизительное распределение пропускной способности для других очередей. Приоритетное обслуживание невозможно. Гарантированные пропускные способности приблизительны. Существует ограниченное число очередей. Относительно сложная конфигурация.1
Организация очереди приоритетов (PQ) Трафик распределяется по очередям с высоким, средним, обычным и низким приоритетом. Сначала обслуживает трафик с высоким приоритетом, затем трафик со средним, обычным и низким приоритетами. Было доступно в течение нескольких лет. Это предоставляет приоритет, обслуживая. Трафик более высокого приоритета исчерпал ресурсы очереди с более низким приоритетом пропускной способности. Невозможно гарантировать полосу пропускания. 2
Взвешенная организация очереди на основе классов (CBWFQ) Для классификации трафика используется модульный интерфейс командной строки QoS. Классифицированный трафик помещается в резервированные очереди полосы пропускания или же, по умолчанию, в нерезервированные очереди. Планировщик обслуживает очереди на основе весов с учетом гарантированного выделения полосы пропускания. Похожий механизм используется в LLQ, за исключением того, что в нем не существует приоритетной очереди. Простая конфигурация и возможность обеспечить гарантированную полосу пропускания. Приоритетное обслуживание невозможно. 3
Обслуживание очередей на основе равнодоступности Очереди с приоритетами (PQ-WFQ), также названный IP RTP Priority Для предоставления приоритетного обслуживания всем пакетам UDP, направляемым на четные номера портов в указанном диапазоне, необходима всего одна команда. Простая настройка, вызов одной командой. Предоставляет приоритетное обслуживание для пакетов RTP. Прочие виды трафика обслуживаются при помощи механизма WFQ. Для трафика протокола RTCP не указаны приоритеты. Пропускная способность не гарантируется.4
LLQ, ранее называемая Priority Queue Class-Based Weighted Fair Queuing (PQCBWFQ) Modular QoS CLI с очередью с приоритетами используется для классификации трафика. Классифицированный трафик помещается в очередь с приоритетами, очередь с зарезервированной полосой пропускания или, по умолчанию, в незарезервированную очередь. Планировщик обслуживает очереди на основе весовых значений, таким образом, приоритетный трафик отправляется первым (в периоды перегрузки сети — в пределах заданного максимального значения), и выполняются требования по выделению гарантированной полосы пропускания. Простая конфигурация. Возможность предоставлять приоритеты разнообразным классам трафика и задавать верхние границы приоритетного использования полосы пропускания. Можно также настраивать классы гарантированной полосы пропускания и класс по умолчанию. Никакой механизм для обеспечения составных уровней приоритета все же весь приоритетный трафик передается через ту же очередь с приоритетами. Отдельные классы приоритета могут иметь отдельные верхние границы приоритетной полосы пропускания во время перегрузки. Однако совместное использование очереди с приоритетами между приложениями может потенциально представить дрожание 4

  1. Не подходящий для голоса.

  2. Пропускная способность потребностей гарантирована для голоса.

  3. Задержка потребностей, которая будет заботиться о.

  4. Достаточный для голоса.

Задержка сериализации

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

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

  • Задержка сериализации на 64 связях со скоростью 64 кбит/с из-за байтового пакета 1500 года = 1500*8/64000 = 187.5 мс.

  • Задержка сериализации на 64 связях со скоростью 64 кбит/с из-за 80-байтового пакета = 80*8/64000 = 10 мс.

Поэтому голосовой пакет потенциально должен дождаться к 187.5 мс, прежде чем он будет передан, если он застревает позади одиночного 1500 пакетов в 1 байт на 64 связях со скоростью 64 кбит/с. С другой стороны, другой голосовой пакет должен ждать только 10 мс в шлюзе назначения. Это приводит к огромному отклонению, которое происходит из-за разницы задержки между пакетами. На исходном шлюзе голосовые пакеты обычно передаются каждые 20 мс. При сквозном балансе задержек 150 мс и строгих требованиях к флуктуациям сигнала интервал более 180 мс недопустим.

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

  • Размер фрагмента = (0,01 с * 64000 бит/с) / (8 бит/байт) = 80 байт

Требуется 10 мс для отправки 80-байтового пакета или фрагмента по каналу 64 кбит/с.

В случае существования ATM или постоянных виртуальных каналов Frame Relay (PVC) на одном физическом интерфейсе, настройте значения фрагментации (на всех PVC) согласно PVC с наименьшей пропускной способностью., Например, если существует три PVCs, которые имеют гарантированную пропускную способность 512 кбит/с, 128 кбит/с, и 256 кбит/с, затем настраивают все три PVCs с размером фрагмента 160 байтов (самая низкая скорость составляет 128 кбит/с, который требует 160-байтового размера фрагмента). Эти значения рекомендуются для других скоростей связи:

Link Speed (kbps)         Fragmentation Size (bytes) 
56                                  70 
64                                  80 
128                                 160 
256                                 320 
512                                 640 
768                                 960 
1024                                1280 
1536                                1920

Примечание: Фрагментация не требуется, если размер фрагмента больше размера MTU канала. Например, для канала T1, где MTU=1500 байт, размер фрагмента равен 1920 байтам, поэтому фрагментация не нужна). Размер фрагментации пакета никогда не должен быть ниже, чем размер Пакета VoIP. Не фрагментируйте Пакеты VoIP. Фрагментация этих пакетов вызывает многочисленные проблемы с установлением соединения и качеством.

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

Механизм фрагментации и чередования данных в канале (LFI) Описание Преимущества Ограничения
Фрагментация MTU с помощью механизма WFQ Команды изменения размера MTU или IP MTU, применяемые на уровне интерфейса. Используется для фрагментации больших IP-пакетов до указанного размера MTU. LFI использует WFQ для чередования пакетов реального времени и фрагментов. Простая конфигурация. Фрагменты, повторно собираются только приложением получения. Поэтому неэффективное использование сети. Только пакеты IP с не Фрагментируют "not set" бита (DF), может обработать фрагментацию хорошо. Создает высокую нагрузку на процессор. Не рекомендуется.
LFI многоканального протокола двухточечного соединения (MLPPP) На последовательных двухточечных каналах MLPPP должен сначала быть настроен, тогда размер фрагментации должен быть установлен в мс. Также должно быть включено чередование для многоканального интерфейса. Пакеты фрагментируются на одном конце канала связи и повторно собираются на другом. Можно объединить несколько каналов, чтобы они действовали как большой виртуальный канал. Доступно только на каналах, настроенных для PPP. Решения для PPP over Frame Relay или PPP over ATM также поддерживаются в программном обеспечении Cisco IOS версии 12.1(5)T или позже.
Фрагментация в протоколе Frame Relay (FRF.12) Для каналов Frame Relay PVC необходимо включить команду frame-relay traffic-shaping и установить параметр fragmentation size в разделе map-class. Пакеты фрагментируются на одном конце постоянного виртуального канала и снова собираются на другом. Доступные только для Frame Relay PVC с включенной командой frame-relay traffic-shaping.

VAD

Обычный речевой диалог включает паузы. Обычный голосовой разговор состоит из 40 - 50 процентов тишины. Поскольку никакой звук не передается через сеть в течение 40% времени голосового вызова, часть пропускной способности в результате развертывания VAD можно сэкономить. С VAD шлюз высматривает разрывы в речи. Это заменяет те разрывы комфортным шумом (фоновый шум). Таким образом сумма пропускной способности сохранена. Однако существует другой способ. Существует маленькое время (в порядке миллисекунд), прежде чем кодеки обнаружат речевую активность, придерживавшуюся периодом тишины. Такое малое время приводит к обрезке получаемого голоса на входе. Чтобы избежать активации во время очень коротких пауз и компенсировать отсечение, VAD ждет приблизительно 200 мс после того, как речь останавливается, прежде чем это остановит передачу. После перезапуска передачи это включает предыдущие 5 мс речи вместе с текущей речью. VAD автоматически отключается при вызове, если фоновый шум не позволяет отличить речь от фоновых шумов. Однако, если пропускная способность не является проблемой, выключите VAD.

Параметры настройки VAD

Существует два параметра, которые диктуют функционирование VAD. Это команды music-threshold и voice vad-time.

music-threshold

Начальный порог решен, который управляет, когда VAD должен стать активным. Это управляется путем определения music-threshold threshold_value команда на голосовом порту, как показано в данном примере. Диапазон для этого от-70 децибел на милливатт (дБм) к-30 дБмам. Значение по умолчанию для этого является-38 дБмами. Настройка более низкого значения (около -70 дБм) приводит к тому, что VAD активизируется при более низком уровне сигнала (громкость должна сильно уменьшиться, чтобы считаться тишиной). Настройка более высокое значение (ближе к-30 дБмам) приводит к VAD, становящемуся активной для даже маленького понижения силы голосового сигнала. Это заставляет воспроизведение играть пакеты комфортного шума чаще. Однако это иногда приводит к незначительному отсечению аудио.

3640-6#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
3640-6(config)#voice-port 3/0/0
3640-6(config-voiceport)#music-threshold ?
WORD Enter a number b/w (-70 to -30)
3640-6(config-voiceport)#music-threshold -50
3640-6(config-voiceport)#end
3640-6#
3640-6#show run | be voice-portvoice-port 3/0/0 music-threshold -50

voice vad-time

Как только VAD становится активным, компонент фонового шума и комфортного шума управляется путем настройки voice vad-time timer_value команда под глобальной конфигурацией, как показано в данном примере. Эта задержка времени в миллисекундах для обнаружения паузы и приостановки передачи голосового пакета. Стандартное значение времени запоминания - 250 мс. Это означает, что в течение 250 мс, начинается комфортный шум. Диапазон этого таймера – от 250 до 65536 мсек. Если максимальное значение настроено для этого, комфортный шум играет роль намного позже (фоновый шум продолжает играться). Если он настроен на 65536 мсек, то успокаивающий шум отключен. Более высокое значение таймера предназначено для более плавного перехода от фонового шума к комфортному шуму. Нижняя сторона к настройке команды voice vad-time к высокому уровню - то, что это не достигает требуемого 30-процентного снижения нагрузки для полосы пропускания.

3640-6#
3640-6#
3640-6#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
3640-6(config)#voice vad-time ?
<250-65536> milliseconds
3640-6(config)#voice vad-time 750
3640-6(config)#end
3640-6#
3640-6#
3640-6#
3640-6#show run | be vad-time voice vad-time 750

Примеры типичной конфигурации для QoS

Типичный сценарий для того, чтобы установить вызовы VoIP или по ссылке frame-relay или по Каналу "PPP". Это примеры конфигурации для этих сценариев.

VoIPoFR - Пример конфигурации QoS

В данном примере (который содержит только соответствующие разделы конфигурации), предполагается что скорость канала frame-relay составляет 256 кбит/с. Гарантированная согласованная скорость передачи данных (CIR) на PVC 100 равна 64 Кбит/c, а на PVC 200 – 192 Кбит/c. PVC 100 используется для переноса и данных и голоса. PVC 200 используется только для переноса данных. Максимум четырех одновременных голосовых вызовов существует в любое заданное время. Настройте фрагментацию на обоих PVCs на основе CIR lowest-bandwidth-voice-PVC (голос переноса PVC). На основе примеров в этом документе, который означает, размер фрагментации решен на основе PVC 100 CIR (который составляет 64 кбит/с). Как показано в таблице раздела Задержки сериализации, для 64 связей со скоростью 64 кбит/с, размер фрагментации 80 байтов требуется. Необходимо установить тот же размер фрагментации для PVC 200.

Для получения дальнейшей информации о конфигурации VoIP over Frame Relay, обратитесь к VoIP over Frame Relay с Качеством обслуживания (Фрагментация, Формирование трафика, LLQ / IP RTP Priority).

3660-1#show run
Building configuration...
!
class-map match-any voip
match ip rtp 16384 16383
match ip dscp 26 46
class-map match-all voip-control
match access-group 101
!
!
policy-map VoIPoFR
class voip
priority 48
class voip-control
bandwidth 8
class class-default
fair-queue
!
voice call send-alert
voice rtp send-recv
!
!
interface Serial4/0:0
bandwidth 256
no ip address
encapsulation frame-relay
frame-relay traffic-shaping
!
interface Serial4/0:0.1 point-to-point
bandwidth 64
ip address 10.10.10.10 255.255.255.0
frame-relay ip rtp header-compression
frame-relay interface-dlci 100
 class voice
!
interface Serial4/0:0.2 point-to-point
bandwidth 192
ip address 20.20.20.20 255.255.255.0
frame-relay interface-dlci 200
class data
!
map-class frame-relay data
frame-relay fragment 80
frame-relay adaptive-shaping becn
frame-relay cir 256000
frame-relay bc 32000
frame-relay be 0
frame-relay mincir 192000
frame-relay fair-queue
!
map-class frame-relay voice
frame-relay fragment 80
no frame-relay adaptive-shaping
frame-relay cir 64000
frame-relay bc 640
frame-relay be 0
frame-relay mincir 64000
service-policy output VoIPoFR
!
!
access-list 101 permit tcp any any eq 1720
!
!
voice-port 3/1/0
!
voice-port 3/1/1
!
!
dial-peer voice 10 voip
incoming called-number .
destination-pattern 1408.......
session target ipv4:10.10.10.11
dtmf-relay h245-signal h245-alphanumeric
no vad
!
dial-peer voice 20 pots
destination-pattern 1234
port 3/1/0
!
dial-peer voice 21 pots
destination-pattern 5678
port 3/1/1

VoIP по PPP - пример конфигурации QoS

В данном примере (который содержит только соответствующие разделы конфигурации), предполагается что QoS должно быть настроено для контроллера частичного T1 "точка-точка" (который имеет двенадцать каналов). Максимум четырех одновременных голосовых вызовов существует в любое заданное время. Задача конфигурации связала настройку этого последовательного интерфейса с инкапсуляцией PPP, созданием его часть многоканальной группы, создание многоканального интерфейса (который принадлежит той же многоканальной группе), и настраивающий все QoS на многоканальном интерфейсе. Для получения дальнейшей информации о конфигурации VoIP по PPP, обратитесь к VoIP по Каналам "PPP" с Качеством обслуживания (LLQ / IP RTP Priority, LFI, cRTP).

3660-1#show run
Building configuration...
!
class-map match-any voip
match ip rtp 16384 16383
match ip dscp 26 46
class-map match-all voip-control
match access-group 101
!
!
policy-map VoIPoPPP
class voip
priority 48
class voip-control
bandwidth 8
class class-default
fair-queue
!
voice call send-alert
voice rtp send-recv
!
!
interface Multilink7
bandwidth 768
ip address 10.10.10.10 255.255.255.0
ip tcp header-compression iphc-format
service-policy output VoIPoPPP
no cdp enable
ppp multilink
ppp multilink fragment-delay 10
ppp multilink interleave
multilink-group 7
ip rtp header-compression iphc-format
!
!
interface Serial4/0:0
bandwidth 768
no ip address
encapsulation ppp
no fair-queue
ppp multilink
multilink-group 7
!
!
access-list 101 permit tcp any any eq 1720
!
voice-port 3/1/0
!
voice-port 3/1/1
!
!
dial-peer voice 10 voip
incoming called-number .
destination-pattern 1408.......
session target ipv4:10.10.10.11
dtmf-relay h245-signal h245-alphanumeric
no vad
!
dial-peer voice 20 pots
destination-pattern 1234
port 3/1/0
!
dial-peer voice 21 pots
destination-pattern 5678
port 3/1/1
!

Механизм воспроизведения и колебаний

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

Механизм воспроизведения

Буфер дрожания является буфером времени. Это предоставлено конечным шлюзом для создания механизма воспроизведения более эффективным. Это - функциональная схема механизма воспроизведения:

/image/gif/paws/20371/troubleshoot_qos_voice1.gif

Когда модуль контроля передачи звука получает голосовой пакет, он анализирует штамп времени RTP. Если голосовой пакет задержан вне емкости буфера дрожания, то пакет сразу отброшен. Если пакет находится в пределах возможностей буферизации, он помещается в буфер задержки прихода пакетов. Расположение этого пакета в буфере отклонения зависит от временной отметки (штампа) RTP, рассчитанного для этого пакета. В конечном счете нет никакого доступного голосового пакета, модуль контроля передачи звука пытается скрыть его (предсказывает пропущенный пакет). Если VAD включен, комфортный шум играется.

Сфера действия функции контроля за воспроизведением - обработка событий потери, дублирования, повреждения и несвоевременной доставки пакетов. Эти события обрабатываются временем, выравнивая дрожавшие голосовые пакеты, играя комфортный шум (если VAD настроен), или даже регенерация двухтонального многочастотного набора (DTMF) тоны, которые будут закончены к хосту.

Маскировка голосового пакета выполняется методами прогнозируемой маскировки или маскировки пауз. Маскирование прогноза основано на предыдущем пакете и следующем пакете (если он доступен). Это работает лучше всего с низкоскоростными кодеками (5 кбит/с к 16 кбит/с). Потеря голосовых пакетов для высокоскоростного кодека (32 кбит/с к 64 кбит/с) может потенциально привести к плохой прогнозируемой маскировке. Когда существуют низкие и нечастые задержки или меньшее количество потери пакета, прогнозируемая маскировка запускается. При слишком активной маскировке предсказания голос может приобрести сходство с роботом. Маскирование пауз представляет собой самую неблагоприятную форму маскирования прогнозов. Она начинает работать, когда не осталось информации для предсказания. Это лишь фоновая маскировка. Когда существуют высокие задержки и больше количества потери пакета, это запускается. Слишком много укрывательства тишины приводит к прерывистому звуку. Прогнозируемая маскировка эффективна для 30 мс, после чего в игру вступает тихая маскировка.

Буфер отклонения

Буфер дрожания ограничен верхним и нижним пределами. Метка верхнего порога – верхняя граница временного интервала, в течение которого ожидается, что пакет придет за один сеанс вещания. Пакеты, прибывшие после верхнего водяного знака помечаются как опоздавшие пакеты или потерянные пакеты. Íèæíèé ïðåäåë (low water mark) - ìèíèìàëüíîå âðåìÿ, çà êîòîðîå ïàêåò äîëæåí áûòü ïåðåäàí äëÿ ñâîåâðåìåííîãî âîñïðîèçâåäåíèÿ. Пакеты, которые поступают перед нижним порогом, считают ранними пакетами (он может все еще быть закончен вовремя).

Если конечный шлюз продолжает видеть инкремент в прибытии последних пакетов, это увеличивает верхний порог. Это значение для верхнего порога остается тем же всюду по продолжительности вызова. Это увеличено до максимума, определенного в конфигурации. Подобным образом конечный шлюз наблюдает количество ранних полученных пакетов. Если эти пакеты начинают часто посещать шлюз, он уменьшает нижний порог. Это значение остается тем же всюду по продолжительности вызова. Этот режим буфера дрожания упоминается как "адаптивный режим", где конечный шлюз адаптирует свой буфер дрожания на основе структуры трафика. Другой режим называется "фиксированным"." В фиксированном режиме существует одно начальное значение для нижнего порога и верхнего порога. Это значение основывается на приблизительном времени задержки при приеме (см. show voice call <port-number> раздел этого документа).

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

Определите задержку и дрожание

В этом разделе описывается определить дрожание в сети.

show call active voice

Команда show call active voice brief дает большую информацию о продолжающемся разговоре. Эти выходные данные отображают некоторые важные моменты, которые изучены из этой команды:

11E4 : 2170927hs.1 +600 pid:10 Answer 1000 active
dur 00:08:43 tx:26157/522967 rx:7044/139565
Tele 3/0/0:9: tx:151310/755/0ms g729r8 noise:-62 acom:0 i/0:-56/-48 dBm
11E4 : 2171198hs.1 +329 pid:20 Originate 2000 active
dur 00:08:43 tx:7044/139565 rx:26165/523127
IP 30.30.30.29:18682 rtt:51ms pl:148590/290ms lost:0/0/15 delay:65/60/132ms g729r8

От выходных данных команды show call active voice brief вы видите, что независимо от того, что получено на Телефонном участке (rx:7044) передан к участку IP (tx:7044). То же истинно для пакетов, полученных на участках IP (26165), которые переданы Телефонному участку (26157). Различие в количестве пакетов, полученных на участке IP по сравнению с количеством пакетов, переданных на Телефонном участке, внесено последним пакетам, которые не делают его своевременно.

Эти выходные данные команды show call active voice (без "краткого" ключевого слова), точки к более подробной информации о параметрах, которые непосредственно определяют дрожание.

GapFillWithSilence=850 ms
GapFillWithPrediction=9230 ms
GapFillWithInterpolation=0 ms
GapFillWithRedundancy=0 ms

show voice call <port-number>

Команда show voice call port-number предоставляет полезную информацию. Удостоверьтесь, что были или подключены с консоли в шлюзе, или если вы - Telneted в шлюз, удостоверьтесь, что вы выполнили команду terminal monitor от уровня exec.

Примечание: Эта команда недоступна на платформах AS5x00/AS5x50.

В этих выходных данных значение для Оценки Задержки Rx (мс) равняется 71. Это - текущее значение буфера дрожания. Значение для верхнего порога и нижнего порога выведено на этом. Среднее исходное значение верхнего предела – 70 микросекунд, а нижнего – 60 микросекунд. После установки начального значения шлюз хранит маршрут всех ранних или поздних пакетов, которые были получены. Как замечен в выходных данных здесь, отбрасывания прогнозируемой маскировки близко к 250 мс, в то время как укрывательство тишины составляет 30 мс. Всегда существует более высокое значение для прогнозируемой маскировки, так как укрывательство тишины является только худшим случаем Прогнозируемой маскировки. Для каждого удаления сокрытия прогнозирования существует увеличение сброса избытка буфера.

Если вы видите буферный сброс, это не обязательно означает наблюдение увеличения верхнего порога. Верхний порог является верхним пределом буфера дрожания. Это изменяется, только если наблюдается тенденция. Другими словами, должен быть непрерывный поток последних пакетов. Это приводит к увеличению буфера дрожания. В выходных данных здесь, присутствует такая тенденция. Поэтому верхний порог увеличен от 70 мс до 161 мс. Если это значение не изменено (и если вы все еще видите 14 последних пакетов), оно подразумевает, что это спорадические последние пакеты, не формируя тенденцию.

От выходных данных команды show call active voice высматривайте потерянные пакеты. Для каждого потерянного пакета вы видите два пакета, которые испытывают недостаток последовательности. Это замечено на выходных данных Rx Non-Seq Pkts. Так как это не положительное значение, приходят к заключению, что не было никаких потерь пакета также.

3640-6# ***DSP VOICE TX STATISTICS***
Tx Vox/Fax Pkts: 195, Tx Sig Pkts: 0, Tx Comfort Pkts: 10
Tx Dur(ms): 192070, Tx Vox Dur(ms): 388, Tx Fax Dur(ms): 0
***DSP VOICE RX STATISTICS***
Rx Vox/Fax Pkts: 9604, Rx Signal Pkts: 0, Rx Comfort Pkts: 0
Rx Dur(ms): 192070, Rx Vox Dur(ms): 191560, Rx Fax Dur(ms): 0
Rx Non-seq Pkts: 0, Rx Bad Hdr Pkts: 0
Rx Early Pkts: 0, Rx Late Pkts: 14
***DSP VOICE VP_DELAY STATISTICS***
Clk Offset(ms): 0, Rx Delay Est(ms): 71
Rx Delay Lo Water Mark(ms): 60, Rx Delay Hi Water Mark(ms): 161
***DSP VOICE VP_ERROR STATISTICS***
Predict Conceal(ms): 250, Interpolate Conceal(ms): 0
Silence Conceal(ms): 30, Retroact Mem Update(ms): 0
Buf Overflow Discard(ms): 500, Talkspurt Endpoint Detect Err: 0
***DSP LEVELS***
TDM Bus Levels(dBm0): Rx -49.9 from PBX/Phone, Tx -41.7 to PBX/Phone
TDM ACOM Levels(dBm0): +2.0, TDM ERL Level(dBm0): +11.1
TDM Bgd Levels(dBm0): -58.9, with activity being voice
***DSP VOICE ERROR STATISTICS***
Rx Pkt Drops(Invalid Header): 0, Tx Pkt Drops(HPI SAM Overflow): 0

Наблюдать за значениями Tx Comfort Pkts и Rx Comfort Pkts. Как от примеров выходных данных, приходят к заключению, что телефон, связанный с этим маршрутизатором главным образом, сохраняет спокойствие, так как у вас есть много Pkt Комфорта Tx. В то же время у вас есть нулевые Pkt Комфорта Rx, что означает, что постоянно говорит другой конец.

Сравните выходные данные здесь с предыдущими выходными данными command. Существует увеличенное количество Rx Последние Pkt (от 14 до 26). Однако в значении верхнего порога нет никакого инкремента. Это указывает, что спорадически задержаны эти 12 пакетов. Сброс переполнения буфера увеличен до 910 мсек. Однако с тех пор нет никакой наблюдаемой тенденции, верхний порог не увеличен.

В выходных данных здесь, у вас есть Rx Ранние Pkt:3. это означает, что пакет поступает очень, прежде чем он будет ожидаться. Как замечено по выходным данным здесь, буфер Дрожания расширил себя для размещения для больше ранних пакетов путем сокращения нижнего порога от 60 до 51.

3640-6# ***DSP VOICE TX STATISTICS***
Tx Vox/Fax Pkts: 209, Tx Sig Pkts: 0, Tx Comfort Pkts: 11
Tx Dur(ms): 337420, Tx Vox Dur(ms): 416, Tx Fax Dur(ms): 0
***DSP VOICE RX STATISTICS***
Rx Vox/Fax Pkts: 16843, Rx Signal Pkts: 0, Rx Comfort Pkts: 1
Rx Dur(ms): 337420, Rx Vox Dur(ms): 335920, Rx Fax Dur(ms): 0
Rx Non-seq Pkts: 0, Rx Bad Hdr Pkts: 0
Rx Early Pkts: 3, Rx Late Pkts: 26
***DSP VOICE VP_DELAY STATISTICS***
Clk Offset(ms): 0, Rx Delay Est(ms): 72
Rx Delay Lo Water Mark(ms): 51, Rx Delay Hi Water Mark(ms): 161
***DSP VOICE VP_ERROR STATISTICS***
Predict Conceal(ms): 510, Interpolate Conceal(ms): 0
Silence Conceal(ms): 70, Retroact Mem Update(ms): 0
Buf Overflow Discard(ms): 910, Talkspurt Endpoint Detect Err: 0
***DSP LEVELS***
TDM Bus Levels(dBm0): Rx -51.5 from PBX/Phone, Tx -44.1 to PBX/Phone
TDM ACOM Levels(dBm0): +2.0, TDM ERL Level(dBm0): +11.9
TDM Bgd Levels(dBm0): -61.3, with activity being voice
***DSP VOICE ERROR STATISTICS***
Rx Pkt Drops(Invalid Header): 0, Tx Pkt Drops(HPI SAM Overflow): 0

Настройте буфер дрожания на шлюзе

Руководства по QoS, крытые в этот документ, заботятся об изменчивой или ухудшенной проблеме качества голосовой связи. Конфигурация буфера playout-delay является обходной путем для неправильной реализации QoS в сети. Только используйте, это как временная замена исправляет или как программное средство для устранения проблем и сужения проблем колебаний, представленных в сети.

Контроль вещания - режим задержки

Буфер дрожания настроен или для фиксированного режима или для адаптивного режима. В адаптивном режиме шлюз позволяет настраивать минимальное значение для буфера отклонения, максимальное значение и номинальное значение. Буфер дрожания ожидает, что пакеты поступят в диапазоне номинальных значений. Номинальное значение должно быть больше либо равно минимуму и меньше либо равно максимуму. Буфер расширяется до настроенного максимального значения. Это может расширить до 1700 мс. При настройке большого максимального значения следует обратить внимание на появление сквозной задержки. Выберите значение максимального playout-delay так, что, это не представляет нежелательную задержку сети. Эти выходные данные являются примером буфера дрожания, настроенного для адаптивного режима:

3640-6#
3640-6#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
3640-6(config)#voice-port 3/0/0
3640-6(config-voiceport)#playout-delay mode adaptive
3640-6(config-voiceport)#playout-delay maximum 400
3640-6(config-voiceport)#playout-delay nominal 70
3640-6(config-voiceport)#playout-delay minimum low
3640-6(config-voiceport)#^Z
3640-6#
3640-6#
3640-6#show run | begin 3/0/0
voice-port 3/0/0
playout-delay maximum 400
playout-delay nominal 70
playout-delay minimum low
playout-delay mode adaptive
!

В фиксированном режиме шлюз использует настроенное значение в качестве номинала. Несмотря на то, что это позволяет вам настраивать минимум и максимальное значение для playout-delay, это проигнорировано, когда настроено для фиксированного режима. Когда в фиксированном режиме, значении верхнего порога или значении нижнего порога всегда остается постоянным. Он основан на номинальном значении и на значении Rx Delay Est (мс)., Таким образом, возможно, что под фиксированным режимом, вы настраиваете значение как 200 мс. Однако, если приблизительное время задержки при приеме близко к 100 мс, в именно это установлены верхний порог и нижний порог на все время вызова.

3640-6#
3640-6#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
3640-6(config)#voice-port 3/0/0
3640-6(config-voiceport)#playout-delay mode fixed
3640-6(config-voiceport)#playout-delay nominal 70
3640-6(config-voiceport)#^Z
3640-6#
3640-6#
3640-6#show run | begin 3/0/0
voice-port 3/0/0
playout-delay mode fixed
playout-delay nominal 70
!

Дополнительные сведения по настройке задержки воспроизведения см. в документе "усовершенствование задержки воспроизведения для голосовых вызовов через IP".

Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.


Дополнительные сведения


Document ID: 20371