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

Понятие дрожания (дребезга) в сетях речевых пакетов (платформы Cisco IOS)

20 октября 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Перевод, выполненный профессиональным переводчиком (14 мая 2010) | Английский (22 августа 2015) | Отзыв


Содержание


Введение

Данный документ описывает динамическую составляющую задержки, способы её измерения и компенсации.

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

Требования

Читатели данного документа должны обладать знаниями по следующим темам:

  • Основная Cisco конфигурация речевых данных IOS�

  • Общие сведения о качестве обслуживания (QoS)

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

Информация в данном документе применима к голосовым шлюзам и маршрутизаторам Cisco IOS.

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

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

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

Колебания задержки в сетях для передачи речевых пакетов

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

На этой схеме показана обработка постоянного равномерного потока пакетов.

/image/gif/paws/18902/18902_Fg1.gif

Когда маршрутизатор принимает аудиопоток транспортного протокола реального времени (RTP) для передачи голосового трафика по IP-сетям (VoIP), он должен компенсировать обнаруживаемые колебания задержки. Механизмом, выполняющим эту функцию, является буфер задержки передачи. Буфер задержки воспроизведения должен буферизовать эти пакеты, а затем передавать их постоянным равномерным потоком цифровому сигнальному процессору (DSP) для обратного преобразования в аналоговый аудиопоток. Буфер задержки передачи также иногда называют буфером для устранения "дрожания".

Следующая схема иллюстрирует обработку колебаний задержки.

/image/gif/paws/18902/18902_Fg2.gif

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

На этом графике показано, как обрабатываются чрезмерные колебания задержки.

/image/gif/paws/18902/18902_Fg3.gif

Определение значимости колебаний задержки

Наличие чрезмерных колебаний задержки можно подтвердить с помощью ПО Cisco IOS, выполнив следующие действия.

  1. Как только вызов станет активным и возникнет подозрение о наличии колебаний задержки, установите соединение по протоколу Telnet с одним из задействованных шлюзов.

  2. Включите монитор терминала Terminal Monitor, чтобы наблюдать сообщения консоли во время сеанса Telnet.

    Примечание: Данное действие не является обязательным в случае соединения с портом консоли.

  3. Введите команду show voice call summary . Результат выполнения команды аналогичен этому:

    PORT         CODEC    VAD VTSP STATE            VPM STATE
    	============ ======== === ==================== ======================
    	1/0/0         -         -  -                     FXSLS_ONHOOK             
    	1/0/1         g729r8    y  S_CONNECT             FXSLS_CONNECT     

    Выберите вызов, при котором возникают колебания задержки. В этом примере: 1/0/1.

  4. Введите команду show voice call, чтобы получить подробные данные об отдельном вызове.

    Для этого примера: show voice call 1/0/1. Выходные данные поступают от DSP, который обрабатывает вызов, и похожи на следующие:

    1/0/1 vtsp level 0 state = S_CONNECT
    	vpm level 1 state = FXSLS_CONNECT
    	vpm level 0 state = S_UP
    
    	MS-2621-3B#     ***DSP VOICE VP_DELAY STATISTICS***
    	Clk Offset(ms): 0, Rx Delay Est(ms): 50
      	Rx Delay Lo Water Mark(ms): 50, Rx Delay Hi Water Mark(ms): 7 
    
    		***DSP VOICE VP_ERROR STATISTICS***
    	Predict Conceal(ms): 0, Interpolate Conceal(ms): 0
    	Silence Conceal(ms): 0, Retroact Mem Update(ms): 0
    	Buf Overflow Discard(ms): 0, Talkspurt Endpoint Detect Err: 0
            						
    		***DSP VOICE RX STATISTICS***
    	Rx Vox/Fax Pkts: 1187, Rx Signal Pkts: 0, Rx Comfort Pkts: 0
    	Rx Dur(ms): 150200, Rx Vox Dur(ms): 23740, Rx Fax Dur(ms): 0
    	Rx Non-seq Pkts: 0, Rx Bad Hdr Pkts: 0
    	Rx Early Pkts: 0, Rx Late Pkts: 0
            ***DSP VOICE TX STATISTICS***
    	Tx Vox/Fax Pkts: 7129, Tx Sig Pkts: 0, Tx Comfort Pkts: 0
    	Tx Dur(ms): 150200, Tx Vox Dur(ms): 14259, Tx Fax Dur(ms): 0
            ***DSP VOICE ERROR STATISTICS***
    	Rx Pkt Drops(Invalid Header): 0, Tx Pkt Drops(HPI SAM Overflow): 0
            ***DSP LEVELS***
    	TDM Bus Levels(dBm0): Rx -54.5 from PBX/Phone, Tx -64.7 to PBX/Phone
    	TDM ACOM Levels(dBm0): +2.0, TDM ERL Level(dBm0): +9.9
    	TDM Bgd Levels(dBm0): -49.4, with activity being voice
  5. Обратите внимание на раздел ***DSP VOICE VP_ERROR STATISTICS*** выходных данных.

    В данном разделе следует рассмотреть несколько параметров. Главным параметром является отображаемое число Buf Overflow Discard (ms). Это число (отброшенных) пакетов, оказавшихся за пределами буфера задержки передачи. Может содержать значение при условии, что оно не увеличивается постоянно. Допускаются некоторые переполнения при первом инициировании вызова, но это значение не должно увеличиваться при многократном выполнении команды show voice call X/X/X. Это число является прямым индикатором избыточных колебаний задержки.

    По умолчанию этот буфер функционирует в адаптивном режиме и динамически подстраивается под величину имеющихся колебаний задержки. Настройте команду playout-delay, чтобы изменить настройки по умолчанию для динамического режима работы буфера для устранения "дрожания". Этот буфер также можно настроить для работы в фиксированном режиме. Это может устранить некоторые неполадки из-за колебаний задержки. Дополнительную информацию см. в Усовершенствования задержки передачи для передачи голосового трафика по IP-сетям (VoIP).

Причины колебаний задержки?

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

Вопросы инкапсуляции

Самый простой и удобный участок для начала поиска причины колебаний задержки — это интерфейсы маршрутизатора, поскольку над этим участком канала имеется прямой контроль. Отслеживание источника колебаний задержки сильно зависит от инкапсуляции и типа канала передачи данных, где возникают колебания задержки. Обычно при правильной настройке в ATM-каналов не возникают колебания задержки благодаря использованию постоянной скорости передачи ячеек. Это обеспечивает очень стабильную задержку. Если колебания задержки наблюдаются в АТМ-среде, необходимо проверить конфигурацию АТМ. Если ATM работает правильно (нет удаленных ячеек), можно считать колебания задержки несущественными. В инкапсуляции протокола "точка-точка" (PPP) колебания задержки почти всегда обусловлены задержкой сериализации. Это можно легко исправить при помощи чередования и фрагментации канала на канале PPP. Принцип PPP в том, что оконечные устройства РРР обмениваются данными напрямую одно с другим без системы маршрутизаторов между ними. Вследствие этого администратор сети имеет контроль над всеми задействованными интерфейсами.

Колебания задержки в среде с ретрансляцией кадров

Для обнаружения колебаний задержки в среде Frame Relay необходимо знать три параметра:

Примеры конфигураций и сведения о конфигурировании см. в VoIP в сетях Frame Relay с Quality of Service.

Формирование трафика

Необходимо убедиться в том, что исходящий трафик маршрутизатора формируется в соответствии с фактической согласованной скоростью передачи (CIR), предоставляемой оператором. Для проверки обратитесь к статистике Frame Relay и оператору. В первую очередь следует просмотреть статистику Frame Relay. Используйте команду show frame-relay pvc xx, где xx – это номер идентификатора канала передачи данных (DLCI). Выходные данные должны быть подобны следующим:

PVC Statistics for interface Serial0/1 (Frame Relay DTE)

DLCI = 16, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/1.1

 input pkts 103611    output pkts 120054    in bytes 9909818
 out bytes 10962348    dropped pkts 0      in FECN pkts 0
 in BECN pkts 0       out FECN pkts 0     out BECN pkts 0
 in DE pkts 0        out DE pkts 0
 out bcast pkts 1366    out bcast bytes 448048
 5 minute input rate 0 bits/sec, 0 packets/sec
 5 minute output rate 0 bits/sec, 0 packets/sec
 pvc create time 22:45:57, last time pvc status changed 22:45:57
 Queueing strategy: weighted fair
 Current fair queue configuration:
  Discard Dynamic Reserved
  threshold queue count queue count
  64   16   0
 Output queue size 0/max total 600/drops 18303
 fragment type end-to-end fragment size 1600
 cir 20000 bc 1000 be 0 limit 125 interval 50
 mincir 20000 byte increment 125 BECN response no IF_CONG no
 frags 103356 bytes 9807006 frags delayed 67241 bytes delayed 7127120
 shaping active
 traffic shaping drops 18303

Полное описание всех полей см. в описании команды show frame-relay pvc.

Что нужно проверить

В выходных данных команды следует проанализировать значения, позволяющие сделать вывод о наличии или отсутствии перегрузки в сети с ретрансляцией кадров. Этими значениями являются: прямое явное уведомление о перегрузке (FECN), обратное явное уведомление о перегрузке (BECN) и параметры пригодности для отбрасывания кадра (DE). Необходимо рассматривать только входящие пакеты, поскольку устройства Cisco не отправляют ни одно из этих значений. Возможно, будет заметно увеличение одного или нескольких из этих значений. Это зависит от типа и конфигурации коммутаторов для сетей с ретрансляцией кадров, используемых поставщиком. В общих чертах, в случае формирования трафика Frame Relay, настроенного для той же CIR, что и канал, эти значения не должны увеличиваться. Тем не менее, если всё-таки наблюдается увеличение этих значений при соответствии фактической CIR канала, значит неверно настроена сеть поставщика с ретрансляцией кадров.

Хороший пример: вы приобрели канал с нулевым значением CIR, однако в нем имеют место пиковые значения. Некоторые поставщики продают постоянные виртуальные каналы (PVC) с нулевой CIR. Данные по нему передаются отлично, но при передаче речевых данных возникают проблемы с качеством звука. Если посмотреть на выходные данные команды для канала с нулевой CIR, число пакетов DE или FECN эквивалентно числу входящих пакетов. Дальше, если имеется канал PVC, предоставленный оператором, со скоростью 128 Кбит/с, а CIR маршрутизатора задано 512 Кбит/с, будет наблюдаться увеличение этих значений (при более медленной скорости). Помните, что учитывать нужно только пакеты, входящие в интерфейс маршрутизатора, и эта скорость контролируется параметрами формирования трафика, настроенными на маршрутизаторе на противоположном конце канала PVC. С другой стороны, вы контролируете входящие данные в другой маршрутизатор, который определяет параметры формирования трафика на локальном конце канала.

Очень важно не превысить CIR для канала PVC, предоставленного оператором. При скорости ниже этой CIR не возникает никаких проблем. Однако в случае её превышения возникнет перегрузка.

В этой ситуации перегрузка возникнет по той причине, что CIR, настроенная для определенного канала PVC на коммутаторе для сети с ретрансляцией кадров, определяет скорость передачи трафика этим коммутатором (для этого PVC). Если фактическая скорость, с которой коммутатор сети с ретрансляцией кадров получает данные, превышает заданную для него CIR, то кадры, превышающие CIR, будут размещаться в буфере до тех пор, пока не появится возможность для передачи находящихся в буфере пакетов. Любому пакету, помещённому в буфер, добавляется бит DE или FECN, определяемый коммутатором сети с ретрансляцией кадров.

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

Как это связано с возникновением колебаний задержки? Некоторые пакеты требуется помещать в буфер в сети с ретрансляцией кадров, поэтому они поступают в удалённый маршрутизатор с большей задержкой. Однако в отсутствие перегрузки они поступают в маршрутизатор с ожидаемой задержкой. Это ведет к изменению дельты времени получения пакетов удалённым маршрутизатором. Следовательно, к колебаниям задержки.

Фрагментация

Фрагментация больше связана с задержкой сериализации, чем с колебаниями задержки. Однако в определённых условиях она может быть вызвана колебаниями задержки. Фрагментацию необходимо обязательно настроить в классе сопоставлений Frame Relay при передаче речевых пакетов. Настройка этого параметра имеет два воздействия на интерфейс. Первый эффект состоит в том, что все пакеты, размер которых больше заданного, фрагментируются. Второй эффект менее заметен, но не менее важен. Если взглянуть на статистику для интерфейса, на котором настроена фрагментация, можно увидеть воздействие этой команды. Без фрагментации стратегия организации очереди, отображённая в выходных данных команды show interface x, показывает, что используется организация очереди по принципу "первым пришел — первым обслужен" (FIFO), т.е. простая очередь. После применения фрагментации к классу сопоставления Frame Relay выходные данные этой команды указывают на организацию очереди по принципу dual-FIFO. Эта стратегия создаёт очередь по приоритету, которая используется только для речевого трафика на интерфейсе. Настоятельно рекомендуется задавать значение фрагментации, соответствующее одному из значений, рекомендуемых в разделе Фрагментация документа VoIP в сетях Frame Relay с Quality of Service. Если колебания задержки по-прежнему возникают и создают проблемы при рекомендованном значении, уменьшайте пошагово значение фрагментации, пока качество звука не станет приемлемым.

Организация очереди

В среде этого типа используется два приемлемых в общем случае способа организации очередей для передачи трафика VoIP:

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

Заключение

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


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


Document ID: 18902