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

Каналы VoIP over PPP с поддержкой средств QoS (LLQ / IP RTP Priority, LFI, cRTP)

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


Содержание


Введение

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

Примечание: Важно отметить, что в конфигурации внизу два маршрутизатора соединены через арендованную линию с подтверждением приема. Тем не менее, в большинстве топологий маршрутизаторы с поддержкой передачи голоса могут быть установлены в любой зоне сети. Обычно голосовые маршрутизаторы используют подключение по локальной сети к другим маршрутизатором, подключенным к глобальной сети (иными словами, выделенный канал PPP). Это важно, потому что если голосовые маршрутизаторы не подключаются напрямую через PPP по выделенной линии, все команды конфигурации WAN должны быть настроены на маршрутизаторах, подключенных к WAN, а не на голосовых маршрутизаторах, как показано в примере ниже.

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

Требования

Для этого документа отсутствуют особые требования.

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

Конфигурации, представленные в этом документе, были протестированы с этим оборудованием:

  • Два 3640 Cisco с Cisco выпуск ПО IOS� 12.2.6a (IP Plus)

  • IP RTP Priority был введен в Cisco IOS Release 12.0(5)T.

  • Метод LLQ был впервые введен в Cisco IOS Release 12.0(7)T.

  • Метод LFI был впервые введен в Cisco IOS Release 11.3.

  • Версия Cisco IOS 12.0.5T и более новые версии предлагают значительные улучшения производительности протокола cRTP.

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

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

Руководство по проектированию QoS для VoIP через связи PPP

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

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

Рекомендация Описание
Строгий приоритет для голосового трафика (приоритет IP RTP или LLQ) Способ предоставления жесткого приоритета для голосового трафика.
Фрагментация и чередование трафика канала (LFI) Может быть обязательным требованием для низкоскоростных каналов.
Сжатие RTP Не требуется для обеспечения хорошего качества голосовых данных, но сокращает загрузку полосы пропускания для вызова. Общий совет по использованию сжатия RTP — включайте его в исправных конфигурациях с хорошим качеством голоса (это упрощает устранение неполадок).
Контроль доступности вызовов (CAC) Не рассмотрено в этом документе. CAC используется для контроля числа вызовов, устанавливаемых по каналу. Например, если канал WAN между двумя шлюзами имеет пропускную способность для двух каналов VoIP, принятие третьего вызова приведет к ухудшению качества для всех трех вызовов. Дополнительные сведения см. в: Контроль приема вызовов VoIP.

Подводя итог, для низкоскоростного канала PPP, в котором источниками голосового сигнала выступают только шлюзы/маршрутизаторы, эти две функции являются обязательными:

  1. Строгий приоритет для голосового трафика

  2. Фрагментация и чередование трафика канала (LFI)

Строгий приоритет для голосового трафика (приоритет IP RTP или LLQ)

Начиная с ПО Cisco IOS версии 12.2, доступно два основных метода обеспечения строгого приоритета для голосового трафика:

  • Приоритет IP RTP (также называемый PQ/WFQ:): Очередь с приоритетами / Обслуживание очередей на основе равнодоступности)

  • Организация очереди с малой задержкой (также названный PQ/CBWFQ: Приоритетная очередь/ Основанная на классах взвешенная справедливая очередность).

IP: приоритет обработки данных в реальном времени (RTP)

IP RTP Priority создает очередь строго по приоритету для ряда потоков пакета RTP, принадлежащих диапазону протокола датаграмм пользователя (UDP) (UDP) порты назначения. В то время как фактические порты используют динамическое согласование между конечными устройствами и шлюзами, все продукты Cisco VoIP используют данную функцию через диапазон UDP-портов (16384-32767). Как только маршрутизатор определяет VoIP трафик, он помещает его в очередь строгого приоритета. Когда приоритетная очередь пуста, другие очереди обрабатываются в соответствии со стандартным механизмом взвешенной справедливой очередности (WFQ). Механизм IP RTP Priority активизируется только при возникновении перегрузок в интерфейсе. На рисунке представлен механизм работы приоритета IP RTP:

pq-wfq.gif

Примечание: IP RTP Priority позволяет разрывать очередь приоритетов (PQ), когда существует доступная пропускная способность на очереди по умолчанию (WFQ), но строго определяет политику содержание очереди с приоритетами, когда существует перегрузка на интерфейсе.

Формирование очереди с низким временем задержки

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

Алгоритм приоритетной очередности (PQ) реализован так, чтобы справедливые очереди не испытывали недостатка пропускной способности. При настройке PQ следует указать в Кбитах максимальную ширину канала, доступную PQ. Когда интерфейс перегружен, организация очередей с приоритетами (PQ) обслуживается до тех пор, пока нагрузка не достигает установленного значения скорости в Кбит/с в приоритете оператора. Лишний трафик отбрасывается во избежание проблем с функцией приоритетных групп Cisco, которая служит для обслуживания очередей по приоритету.

/image/gif/paws/7111/llq.gif

Этот метод более комплексный и гибкий чем метод приоритета IP протокола реального времени (RTP). Выбор метода должен основываться на видах трафика в реальной сети и актуальными потребностями.

Сравнение приоритета IP RTP и LLQ

Эта таблица суммирует основные различия между LLQ и IP RTP Priority и предоставляет некоторые рекомендации того, когда использовать каждый метод.

Low Latency Queuing (LLQ) IP: приоритет обработки данных в реальном времени (RTP)
Сопоставлять речевой трафик на основании:
  • Списки доступа (для диапазона портов UDP, адресов узлов, полей ToS заголовка IP: IP-последовательность, DSCP, и более
  • Диапазон портов IP RTP
  • Поля IP ToS (Тип обслуживания): Приоритет DCSP и/или IP
  • Протоколы и входные интерфейсы
  • Все допустимые критерии сопоставления, используемые в CBWFQ
Преимущества:
  • Больше гибкости в процессе сопоставления потока данных и направления его на определенные PQ и CBWFQ
  • Можно настроить дополнительные классы для гарантированной пропускной способности для другого трафика, такого как сигналы VoIP и видео.
Недостатки:
  • Комплексная конфигурация
Сопоставлять речевой трафик на основании:
  • Исходя из диапазона портов RTP/UDP: 16384-32767
Преимущества:
  • Простая конфигурация
Недостатки:
  • RTCP-трафик (сигнализация VoIP) использовался в очереди WFQ

    Примечание: Протокол RTP использует RTCP (Протокол управления реального времени) для управления доставкой пакетов RTP. Для RTP-портов используются четные номера, для RTCP-портов используются нечетные номера из диапазона 16384-32767. Метод IP RTP Priority помещает RTP-порты в приоритетную очередь, в то время как RTCP-порты обслуживаются во взвешенной справедливой очереди (WFQ) по умолчанию.

  • Обслуживает VoIP-трафик в приоритетной очереди, но любой другой трафик, нуждающийся в приоритетном управлении и гарантированной пропускной способности, обслуживаются в очереди WFQ. WFQ позволяет различать потоки по весу (на основе приоритета IP-адреса), но не обеспечивает гарантированной полосы пропускания для любого потока.
Рекомендации

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

Руководства по конфигурации LLQ

Придерживайтесь этих рекомендаций для настройки LLQ:

  1. Создайте карту классов для трафика VoIP и определите критерии совпадения

    Эти команды объясняют, как выполнить задание:

    maui-voip-sj(config)#class-map ?
           WORD 		class-map name
           match-all 	Logical-AND all matching statements under this classmap
           match-any 	Logical-OR all matching statements under this classmap
    maui-voip-sj(config)#class-map match-all voice-traffic 
    
    !-- Choose a descriptive class_name. 
    
    
    maui-voip-sj(config-cmap)#match ?  
    access-group         Access group  
    any                  Any packets  
    class-map            Class map  
    cos                  IEEE 802.1Q/ISL class of service/user priority values  
    destination-address  Destination address  
    input-interface      Select an input interface to match  
    ip                   IP specific values  
    mpls                 Multi Protocol Label Switching specific values  
    not                  Negate this match result  
    protocol             Protocol 
    qos-group            Qos-group  
    source-address       Source address
    
    !-- In this example, the access-group matching option is used for its 
    !-- flexibility (it uses an access-list)
    
    
    maui-voip-sj(config-cmap)#match access-group ?
      <1-2699>  Access list index  name      Named Access List
    maui-voip-sj(config-cmap)#match access-group 102
    
    
    !-- Now, create the access-list to match the class-map access-group:
    
    maui-voip-sj(config)#access-list 102 permit udp any any range 16384 32776
    
    
    !-- Safest and easiest way is to match with UDP port range 16384-32767
    !-- This is the port range Cisco IOS H.323 products utilize to transmit 
    !-- VoIP packets.
    
    

    Эти списки доступа также можно использовать для сопоставления голосового трафика с помощью команды match access-group:

    access-list 102 permit udp any any precedence critical 
    !-- This list filters traffic based on the IP packet TOS: Precedence field.  
    !-- Note: Ensure that other non-voice traffic does NOT uses the 
    !-- same precedence value.              
    
    access-list 102 permit udp any any dscp ef
    !-- In order for this list to work, ensure that VoIP packets are tagged with 
    !-- the dscp ef code before they exit on the LLQ WAN interface. 
    !-- For more information on DSCP refer to: 
    !-- Implementing Quality of Service Policies with DSCP
    !-- Note: If endpoints are not trusted on their packet marking, you can mark
    !-- incoming traffic by applying an inbound service policy on an inbound
    !-- interface. This procedure is out of the scope of this doc. 
        
    Access-list 102 permit udp host 192.10.1.1 host 192.20.1.1
    
    !-- This access-list can be used in cases where the VoIP devices cannot 
    !-- do precedence or dscp marking and you cannot determine the 
    !-- VoIP UDP port range. 
    
    

    Существуют другие методы сопоставления, которые можно использовать вместо групп доступа:

    • Начиная с Cisco IOS Release 12.1.2.T, функция IP RTP Priority внедрена для LLQ. Данная функция сопоставляет приоритеты классов содержимого в зависимости от конфигурации UDP-портов и является ограничением обслуживания только для нечетных портов в PQ.

      class-map voice 
        match ip rtp 16384 16383 
      
      
    • Эти два метода работают в предположении, что пакеты VoIP маркированы в исходных хостах или сопоставлены и маркированы в маршрутизаторе перед применением исходящей операции LLQ.

      class-map voice 
        match ip precedence 5 
      

      или

      class-map voice 
        match ip dscp ef 
      

      Примечание: Начиная с IOS версии 12.2.2T, VoIP адресуемые точки вызова могут помечать голосовой однонаправленный канал и сигнальные пакеты до срабатывания LLQ. Это позволяет сделать масштабируемыми маркирование и установку соответствий VoIP-пакетов с помощью значений кодов DSCP для LLQ.

  2. Создайте схему классов для VoIP-сигнализации и определите критерии сопоставления (необязательно)

    Эти команды объясняют, как выполнить задание:

     class-map voice-signaling
      match access-group 103
     !
     access-list 103 permit tcp any eq 1720 any 
     access-list 103 permit tcp any any eq 1720
    

    Примечание: Вызовы VoIP можно устанавливать с помощью протоколов H.323, SIP, MGCP и Skinny (это патентованный протокол, используемый в Cisco Call Manager). Приведенный выше пример предполагает наличие H.323 Fast Connect. Это список используется в качестве справочника портов, используемых сигнальными и управляющими каналами VoIP:

    • H.323/H.225 = TCP 1720

    • H.323/H.245 = TCP 11xxx (стандартное соединение)

    • H.323/H.245 = TCP 1720 (быстрое соединение)

    • H.323/H.225 RAS = TCP 1719

    • Skinny = TCP 2000-2002 (CM Encore)

    • ICCP = TCP 8001-8002 (кабельный модем Encore)

    • MGCP = UDP 2427, TCP 2428 (CM Encore)

    • SIP= UDP 5060, TCP 5060 (настраиваемый)

  3. Создайте карту политик и свяжите ее с картами классов VoIP

    Цель схемы политик - определить, как ресурсы линии распределяются или приписываются различным классам сопоставления. Эти команды объясняют, как выполнить задание:

    maui-voip-sj(config)#policy-map VOICE-POLICY
    
    !-- Choose a descriptive policy_map_name.
    
    
    maui-voip-sj(config-pmap)#class voice-traffic
    maui-voip-sj(config-pmap-c)#priority ?  
    <8-2000000>  Kilo Bits per second
    
    !-- Configure the voice-traffic class to the strict priority
    !-- Queue (priority command) and assign the bandwidth.
    
    
    maui-voip-sj(config-pmap)#class voice-signaling
    maui-voip-sj(config-pmap-c)#bandwidth 8
    
    !-- Assign 8 Kbps to the voice-signaling class
    
    
    maui-voip-sj(config-pmap)#class class-default
    maui-voip-sj(config-pmap-c)#fair-queue 
    
    !-- The remaining data traffic is treated as Weighted Fair Queue
    
    

    Примечание: Несмотря на то, что возможно поместить различные типы в очередь трафика в реальном времени к PQ, Cisco рекомендует направить только голосовой трафик к нему. Трафик реального времени, например видео, может вызвать переменную задержку (приоритетная очередь работает по принципу FIFO — первым вошел, первым вышел). Голосовой трафик требует, чтобы задержки не были переменными, чтобы избежать "дрожания".

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

    Примечание: При настройке VoIP через 64 Связи со скоростью 64 кбит/с для поддержки двух голосовых вызовов распространено выделить больше чем 75 процентов (48 Кбит/с) пропускной способности соединения к PQ. В таких случаях можно использовать команду max-reserved-bandwidth 80, чтобы увеличить доступную пропускную способность до 80 % (51 Кбит/с).

    Для получения более подробной информации по пропускной способности и приоритетных командах перейдите к сравнению пропускной способности и приоритетных команд политики качества обслуживания (QoS) и класса предоставляемых услуг передачи данных.

  4. Включение LLQ: Примените карту политик к исходящему интерфейсу WAN

    Эти команды объясняют, как выполнить задание:

    maui-voip-sj(config)#interface multilink 1
    maui-voip-sj(config-if)#service-policy output VOICE-POLICY
    
    !-- In this scenario (MLPPP LFI), the service policy is applied to
    !-- the Multilink interface.
    
    
    

Руководство по конфигурации приоритета в RTP IP

Для настройки IP RTP Priority используют эти рекомендации:

  • Router(config-if)#ip rtp priority starting-rtp-port-#port-#-rangebandwidth
    
    
    Команда Описание
    starting-rtp-port-number
    
    Нижняя граница порта UDP. Самый низкий номер порта, на который отправляются пакеты. Для VoIP задайте номер 16384.
    port-number-range
    
    Диапазон UDP-портов назначения. Число, введенное в команде starting-rtp-port-number, обозначает самый высокий номер UDP-порта. Для VoIP укажите значение 16383 (32767 - 16384 = 16383)
    bandwidth
    
    Максимально допустимая пропускная способность (кбит/с) в очереди приоритетов. Установите это число в соответствии с числом одновременных вызовов, поддерживаемым системой.

    Пример конфигурации:

    interface Multilink1
    
       !--- Some output omitted
    
       bandwidth 64
       ip address 172.22.130.2 255.255.255.252
       ip tcp header-compression
       fair-queue
       no cdp enable
       ppp multilink
       ppp multilink fragment-delay 10
       ppp multilink interleave
       multilink-group 1
       ip rtp header-compression iphc-format
       ip rtp priority 16384 16383 45
    

Фрагментация и чередование трафика канала (LFI): Multilink PPP

В то время как 1500 байт - обычный размер пакетов данных, размер типичного пакета VoIP (содержащего голосовые кадры G.729) может составлять около 66 байт (20 байт полезной части голосового пакета, 6 байт заголовка уровня 2, 20 байт заголовка RTP и UDP, 20 байт заголовка IP).

Представьте выделенную линию на 56Кбит/с, по которой осуществляется передача данных и голоса. Если голосовой пакет готов к преобразованию в последовательную форму, лишь когда по каналу начинается передача пакета данных, это приводит к проблеме. Чувствительный к задержке голосовой пакет должен ждать передачи в течении 214 мс (сериализация пакета размером 1500 байт в канале 56 Кбит/с занимает 214 мс).

Можно убедиться, что большие пакеты данных могут значительно замедлить доставку небольших голосовых пакетов, снижая качество речевого сигнала. Фрагментация этих больших пакетов на более мелкие и чередование голосовых пакетов и фрагментов пакетов данных позволяет уменьшить эффект "дрожания". Функция фрагментации канала Cisco IOS и функция Interleaving (LFI) помогают выполнить требования VoIP доставки в реальном времени. Этот рисунок иллюстрирует принцип работы LFI:

lfi.gif

Как показано в таблице 1, задержка сериализации (время, необходимое для размещения разрядов в интерфейсе), появившаяся в низкоскоростных каналах WAN, может быть значительной, если считать, что задержка из конца в конец в одну сторону не должна превышать 150 мс. (Максимальная сквозная задержка в одну сторону, равная 150 мс, указывается в рекомендации ITU-T G.114.).)

Таблица 1. Задержка сериализации для Различных Размеров фрейма на Задержке сериализации Низкоскоростных соединений = размер фрейма (биты) / пропускная способность соединения (бит в секунду)

1 байт 64 байт 128 байтов 256 байтов 512 байт 1024 байт 1500 байтов
56 Кбит/с 143 мксек 9 мс 18 мс 36 мс 72 мс 144 мс 214 мс
64 кбит/сек 125 us 8 мс 16 мс 32 мс 64 мсек 126 мс 187 мс
128 Кбит/с 62,5 us 4 мс 8 мс 16 мс 32 мс 64 мсек 93 мс
256 кбит/с 31 us 2 мс 4 мс 8 мс 16 мс 32 мс 46 мс
512 кбит/с 15.5 нас 1 мс 2 мс 4 мс 8 мс 16 мс 32 мс
768 кбит/с 10 us 640 us 1,28 мс 2,56 мс 5,12 мс 10,24 мс 15 мс
1536 кбит/сек 5 нас 320 us 640 us 1,28 мс 2,56 мс 5,12 мс 7,5 мс

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

Размер фрагмента канала указывается в миллисекундах (мсек) с помощью команды ppp multilink fragment-delay. LFI требует конфигурирования PPP Multilink для интерфейса с включенным чередованием ppp multilink. Дополнительные сведения о настройке LFI см. в соответствующем разделе этого документа.

Примечание: Если у вас больше, чем специализированное соединение T1 (768 Кб/с), вам не нужна функция фрагментации. (Однако, вам все еще необходимо использовать механизм QoS, например LLQ или IP RTP Priority). У половины канала T1 достаточно пропускной способности для того, чтобы голосовые пакеты попадали и покидали очередь без проблем с задержкой. Кроме того, в случае половинного соединения T1 можно обойтись без протокола сжатия в реальном времени (cRTP), который обеспечивает экономию полосы пропускания за счет сжатия заголовков IP RTP.

Сжатый протокол реального времени RTP

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

В соответствии со стандартом RFC 2508, функция сжатия заголовков RTP сжимает заголовки IP/UDP/RTP с 40 байт до 2 или 4 байт, сокращая ненужное потребление пропускной способности. Эта схема сжатия действует на уровне переходов, поэтому протокол cRTP необходимо настроить на обоих концах канала (если не настроен параметр passive. Для настройки cRTP используйте следующую команду на уровне интерфейса:

  • Router(config-if)#ip rtp header-compression [passive]

Так как процесс сжатия может вызывать сильную нагрузку на CPU, сжатие заголовка RTP производится на путях быстрой коммутации и коммутируемых путях CEF с выпуском 12.0.(7)T Cisco IOS. Иногда такие среды становятся неисправными, в этом случае можно будет использовать только пакеты Processed switched. Рекомендуется использовать cRTP только в каналах со скоростью ниже 768 Кбит/с, пока маршрутизатор работает с низким коэффициентом загруженности CPU. Проконтролируйте использование CPU маршрутизатора и отключите cRTP, если нагрузка превышает 75%.

Примечание: При настройке команды ip rtp header-compression маршрутизатор добавляет команду ip tcp header-compression к конфигурации по умолчанию. Это необходимо для сжатия заголовков пакетов TCP/IP. Сжатие заголовков будет особенно полезно в сетях с высокой долей малых пакетов, таких как пакеты Telnet-подключений. Методика сжатия заголовков TCP, подробно описанная в стандарте RFC 1144, поддерживается на последовательных каналах, использующих инкапсуляцию HDLC или PPP.

Для сжатия заголовков TCP без использования протокола cRTP, используйте следующую команду:

  • Router(config-if)#ip tcp header-compression [passive] 

Дополнительные сведения: Протокол cRTP

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

  • Используйте низкоскоростной кодер/декодеры (кодек) на ветвях вызова VoIP; G.729 (8 кбит/с) рекомендуется. (Это кодек по умолчанию для одноранговых телефонных соединений VoIP). Для настройки других кодеков используйте команду router(config-dial-peer)#codec для нужного однорангового коммутируемого соединения VoIP.

  • Несмотря на то что двухтоновые многочастотные (DTMF) сигналы обычно точно передаются при использовании высокоскоростных голосовых кодеков, например G.711, низкоскоростные кодеки (например G.729 и G.723.1) оптимизированы на голосовые шаблоны и искажают DTMF-тоны. Этот подход может вызвать проблемы доступа к системам интерактивного голосового ответа (IVR). Команда dtmf relay решает проблему искажения DTMF путем передачи тональных сигналов DTMF вне полосы или отдельно от кодированного голосового потока. Если используется кодек с низким битрейтом (G.729, G.723) включите параметр dtmf relay для однорангового телефонного соединения VoIP.

  • Типовой разговор содержит 35-50 % пауз. При использовании функции определения активности речи (VAD) пакеты молчания подавляются. При планировании VoIP функция VAD уменьшает пропускную способность на 35 %. Опознавание активности речи (VAD) сконфигурировано по умолчанию в VoIP для равноправного коммутируемого элемента. Чтобы включить и отключить VAD используйте команды router(config-dial-peer)#vad и router(config-dial-peer)# no vad для нужных одноранговых телефонных соединений VoIP.

Схема сети

/image/gif/paws/7111/mlppp.gif

Конфигурации

maui-voip-sj (Cisco 3640)
version 12.2service timestamps debug datetime msec

!-- < Some output omitted >

!
hostname maui-voip-sj
!
ip subnet-zero
!
no ip domain-lookup
!

!-- Definition of the voice signaling and traffic class maps
!-- "voice-traffic" class uses access-list 102 for its matching criteria.
!-- "voice-signaling" class uses access-list 103 for its matching criteria.


Class-map match-all voice-signaling
  match access-group 103
class-map match-all voice-traffic
  match access-group 102
!

!-- The policy-map defines how the link resources are assigned 
!-- to the different map classes. In this configuration, strict priority
!-- queue is assigned to "voice-traffic" class with (based on ACL in 
!-- class voice) with max bandwidth = 45 Kbps. 

policy-map VOICE-POLICY
  class voice-traffic
    priority 48
 class voice-signaling
   bandwidth 8

    !-- Assigns a queue for "voice-signaling" traffic that ensures 8 Kbps.
    !-- Note that this is optional and has nothing to do with good voice 
    !-- quality, but rather a way to secure signaling.

  class class-default
   fair-queue

!-- The class-default class is used to classify traffic that does 
    !-- not fall into one of the defined classes.
    !-- The fair-queue command associates the default class WFQ queueing.

!
call rsvp-sync
!

!-- Note that MLPPP is strictly an LFI mechanism. It does not
!-- bundle multiple serial interfaces to the same virtual interface as 
!-- the name stands (This bundling is done for data and NOT recommended 
!-- for voice). The end result may manifest itself as jitter and no audio.

interface Multilink1
 ip address 172.22.130.1 255.255.255.252
 ip tcp header-compression iphc-format
 service-policy output VOICE-POLICY

  !-- LLQ is an outbound operation and applied to the outbound WAN 
  !-- interface.

 no cdp enable
 ppp multilink
 ppp multilink fragment-delay 10
  
!-- The configured value of 10 sets the fragment size such that 
  !-- all fragments have a 10 ms maximum serialization delay.

 ppp multilink interleave
 multilink-group 1
  ip rtp header-compression iphc-format
!
interface Ethernet0/0
 ip address 172.22.113.3 255.255.255.0
 no keepalive
 half-duplex
!
interface Serial0/0
 bandwidth 128

  !-- the bandwidth command needs to be set correctly for the 
  !-- right fragment size to be calculated.

 no ip address
 encapsulation ppp
 clockrate 128000
 ppp multilink
 multilink-group 1

  !-- This command links the multilink interface to the physical 
  !-- serial interface.

!
router eigrp 69 
 network 172.22.0.0
 auto-summary
 no eigrp log-neighbor-changes
!

!-- access-list 102 matches VoIP traffic based on the UDP port range. 
!-- Both odd and even ports are put into the PQ.
!-- access-list 103 is used to match VoIP signaling protocol. In this
!-- case, H.323 V2 with fast start feature is used.

access-list 102 permit udp any any range 16384 32767
access-list 103 permit tcp any eq 1720 any
access-list 103 permit tcp any any eq 1720
!
voice-port 1/0/0
!
voice-port 1/0/1
!
voice-port 1/1/0
!
voice-port 1/1/1
!
dial-peer cor custom
!
dial-peer voice 1 pots
 destination-pattern 5000
 port 1/0/0
!
dial-peer voice 2 voip
 destination-pattern 6000
 session target ipv4:172.22.130.2

maui-voip-austin (Cisco 3640)
version 12.2
service timestamps debug datetime msec
!
hostname maui-voip-austin
!
boot system flash slot1:c3640-is-mz.122-6a.bin
!
ip subnet-zero
!
class-map match-all voice-signaling
  match access-group 103
class-map match-all voice-traffic
  match access-group 102
!
policy-map voice-policy
  class voice-signaling
   bandwidth 8
  class voice-traffic
    priority 48
  class class-default
   fair-queue
!
interface Multilink1
 bandwidth 128
 ip address 172.22.130.2 255.255.255.252
 ip tcp header-compression iphc-format
 service-policy output voice-policy
 no cdp enable
 ppp multilink
 ppp multilink fragment-delay 10
 ppp multilink interleave
 multilink-group 1
 ip rtp header-compression iphc-format

 !-- Configure cRTP after you have a working configuration.
 !-- This helps isolate potential cRTP issues.

!
Interface Ethernet0/0
 ip address 172.22.112.3 255.255.255.0
 no keepalive
 half-duplex
!
interface Serial0/0
 bandwidth 128
 no ip address
 encapsulation ppp
 no ip mroute-cache
 ppp multilink
 multilink-group 1
!
router eigrp 69
 network 172.22.0.0
 auto-summary
 no eigrp log-neighbor-changes
!
access-list 102 permit udp any any range 16384 32767
access-list 103 permit tcp any eq 1720 any
access-list 103 permit tcp any any eq 1720
!
voice-port 1/0/0
!
voice-port 1/0/1
!
voice-port 1/1/0
!
voice-port 1/1/1
!
dial-peer cor custom
!
dial-peer voice 1 pots
 destination-pattern 6000
 port 1/0/0
!
dial-peer voice 2 voip
 destination-pattern 5000
 session target ipv4:172.22.130.1

Команды для проверки и устранения неполадок

Прежде чем применять команды отладки, ознакомьтесь с разделом Важные сведения о командах отладки. Дополнительные сведения командах, перечисленных ниже, см. в разделе Примеры выходных данных команд show и debug.

Команды интерфейса:

Команды LFI:

  • show ppp multilink — Эта команда отображает пакетные данные для многоканальных пакетов PPP.

  • debug ppp multilink fragments – с помощью данной команды отладки отображается информация об отдельных фрагментах многоканального соединения и чередующихся событиях. Выходные данные этой команды также содержат порядковый номер пакета и размеры фрагмента.

Команды LLQ / IP RTP Priority:

Другие команды/ссылки:

Типичные ошибки:

Рекомендации:

Ниже приводится описание некоторых основных действий по устранению неполадок, которые применяются, если канал ppp работает (MLPPP, фрагментация, Interleaving):

  1. show call active voice для проверки для потерянных пакетов на уровне DSP.

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

  3. show policy-map interface для проверки для отбрасываний LLQ и настройки организации очереди. Не должны сообщать никакие отбрасывания, которые нарушают политику.

  4. show ip rtp header-compression — Используйте для проверки для cRTP определенных проблем.

Показ образца и данные отладки

 

!-----------------------------------------------
 !-----------------------------------------------
 !---- To capture sections of this output, the LLQ PQ bandwidth 
 !---- was lowered and large data traffic was placed
 !---- on the link to force some packets drops.
 !-----------------------------------------------
 !-----------------------------------------------

 !---- Packet Drop Verification (During an Active Call)

 !--- Assuming your ppp link is up and running, the first step of voice 
 !--- quality problems verification is to check for lost packets 
 !--- at the DSP. Note: Use the show call active voice command 
 !--- NOT show call active voice brief


 maui-voip-austin#show call active voice
 Total call-legs: 2


 !--- Indicates that the connection is established and both legs exist


 GENERIC:
          SetupTime=155218260 ms
          Index=1
          PeerAddress=5000
          PeerSubAddress=
          PeerId=2
          PeerIfIndex=13
          LogicalIfIndex=0
          ConnectTime=155218364
          CallDuration=00:00:27
          CallState=4

 !--- indicates that it is the active call
 !--- (#define D_callActiveCallState_active 4).
          CallOrigin=2
          ChargedUnits=0
          InfoType=2
          TransmitPackets=365
          TransmitBytes=7300
          ReceivePackets=229
          ReceiveBytes=4580

 VOIP:

 !--- For this call, this was the terminating gateway.
 !--- At this gateway, the call started at the VoIP leg.

          ConnectionId[0x18872BEB 0x1A8911CC 0x808CBE60 0x6D946FC6]
          IncomingConnectionId[0x18872BEB 0x1A8911CC 0x808CBE60 0x6D946FC6]
          RemoteIPAddress=172.22.130.1

 !--- Indicates from which IP address the RTP stream is originating.

          RemoteUDPPort=18778
          RemoteSignallingIPAddress=172.22.130.1

 !--- Indicates from which IP address signaling messages are coming.

          RemoteSignallingPort=11010
          RemoteMediaIPAddress=172.22.130.1
          RemoteMediaPort=18778
          RoundTripDelay=50 ms
          SelectedQoS=best-effort
          tx_DtmfRelay=inband-voice
          FastConnect=TRUE

 Separate H245 Connection=FALSE

 H245 Tunneling=FALSE

 SessionProtocol=cisco
 SessionTarget=
 OnTimeRvPlayout=4570
 GapFillWithSilence=20 ms
 GapFillWithPrediction=1840 ms
 GapFillWithInterpolation=0 ms
 GapFillWithRedundancy=0 ms
 HiWaterPlayoutDelay=70 ms
 LoWaterPlayoutDelay=51 ms
 ReceiveDelay=51 ms
 LostPackets=90
 EarlyPackets=1
 LatePackets=0

 !--- Indicates the precense of jitter, lost packets, or 
 !--- corrupted packets.

 VAD = enabled
 CoderTypeRate=g729r8
 CodecBytes=20

 GENERIC:
          SetupTime=155218260 ms
          Index=2
          PeerAddress=6000
          PeerSubAddress=
          PeerId=1
          PeerIfIndex=12
          LogicalIfIndex=6
          ConnectTime=155218364
          CallDuration=00:00:34
          CallState=4
          CallOrigin=1
          ChargedUnits=0
          InfoType=2
          TransmitPackets=229
          TransmitBytes=4580
          ReceivePackets=365
          ReceiveBytes=7300
 TELE:
          ConnectionId=[0x18872BEB 0x1A8911CC 0x808CBE60 0x6D946FC6]
          IncomingConnectionId=[0x18872BEB 0x1A8911CC 0x808CBE60 0x6D946FC6]
          TxDuration=35360 ms
          VoiceTxDuration=730 ms
          FaxTxDuration=0 ms
          CoderTypeRate=g729r8
          NoiseLevel=-46
          ACOMLevel=2
          OutSignalLevel=-58
          InSignalLevel=-42
          InfoActivity=2
          ERLLevel=7
          SessionTarget=
          ImgPages=0Total call-legs: 2



 !----------------------------------------------------------
 !--- Interface Verification

 !--- Make sure you see this:
 !--- LCP Open, multilink Open: Link control protocol (LCP) open statement 
 !--- indicates that the connection is establish.
 !--- Open:IPCP. Indicates that IP traffic can be transmitted via the PPP link.


 maui-voip-sj#show interface multilink 1

 Multilink1 is up, line protocol is up
   Hardware is multilink group interface
   Internet address is 172.22.130.1/30
   MTU 1500 bytes, BW 128 Kbit, DLY 100000 usec,
      reliability 255/255, txload 1/255, rxload 1/255
   Encapsulation PPP, loopback not set
   Keepalive set (10 sec)
   DTR is pulsed for 2 seconds on reset
   LCP Open, multilink Open
   Open: IPCP
   Last input 00:00:01, output never, output hang never
   Last clearing of "show interface" counters 00:25:20
   Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 91
   Queueing strategy: weighted fair
   Output queue: 0/1000/64/37/383 (size/max total/threshold/drops/interleaves)
      Conversations  0/3/32 (active/max active/max total)
      Reserved Conversations 1/1 (allocated/max allocated)
      Available Bandwidth 38 kilobits/sec
   5 minute input rate 0 bits/sec, 0 packets/sec
   5 minute output rate 0 bits/sec, 0 packets/sec
      8217 packets input, 967680 bytes, 0 no buffer
      Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
      13091 packets output, 1254194 bytes, 0 underruns
      0 output errors, 0 collisions, 0 interface resets
      0 output buffer failures, 0 output buffers swapped out
      0 carrier transitions
----------------------------------------------------------------

!-- Note: There are no drops at the interface level.
!-- All traffic that is dropped due to policing, is 
!-- dropped before it gets to the interface queue.


maui-voip-austin#show interface
 serial 0/0Serial0/0 is up, line protocol is up
  Hardware is QUICC Serial
  MTU 1500 bytes, BW 128 Kbit, DLY 20000 usec,
     reliability 255/255, txload 49/255, rxload 47/255
  Encapsulation PPP, loopback not set
  Keepalive set (10 sec)
  LCP Open, multilink Open
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters 00:22:08
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: weighted fair  [suspended, using FIFO]
  FIFO output queue 0/40, 0 drops
  5 minute input rate 24000 bits/sec, 20 packets/sec
  5 minute output rate 25000 bits/sec, 20 packets/sec     4851 packets input, 668983 bytes, 0 no buffer
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     4586 packets output, 657902 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up


!-----------------------------------
!--- LLQ Verification



maui-voip-austin#show policy-map int multilink 1
 Multilink1
 Service-policy output: voice-policy

 Class-map: voice-signaling (match-all)

!--- This is the class for the voice signaling traffic.

         10 packets, 744 bytes
         5 minute offered rate 0 BPS, drop rate 0 BPS
         Match: access-group 103
         Weighted Fair Queueing
         Output Queue: Conversation 42
         Bandwidth 8 (kbps) Max Threshold 64 (packets)
         (pkts matched/bytes matched) 10/744
         (depth/total drops/no-buffer drops) 0/0/0

 Class-map: voice-traffic (match-all)

!--- This is PQ class for the voice traffic.

         458 packets, 32064 bytes
         5 minute offered rate 0 BPS, drop rate 0 BPS
         Match: access-group 102
         Weighted Fair Queueing
         Strict Priority
         Output Queue: Conversation 40
         Bandwidth 15 (kbps) Burst 375 (Bytes)
!--- Notice that the PQ bandwidth was lowered to force packet drops.
         (pkts matched/bytes matched) 458/29647
         (total drops/bytes drops) 91/5890
!--- Some packets were dropped. In a well designed link,
!--- there should be no (or few) drops of the PQ class.

 Class-map: class-default (match-any)
         814 packets, 731341 bytes
         5 minute offered rate 27000 BPS, drop rate 0 BPSMatch: any
         Weighted Fair Queueing
         Flow Based Fair Queueing
         Maximum Number of Hashed Queues 32
         (total queued/total drops/no-buffer drops) 0/0/0

!---------------------------------------------


!--- Verify the class-map configuration

maui-voip-austin#show class-map
 Class Map match-all voice-signaling (id 2)
   Match access-group  103
 Class Map match-any class-default (id 0)
         Match any
 Class Map match-all voice-traffic(id 3)
         Match access-group 102


!--- Verify the access-lists of the class-maps

maui-voip-austin#show access-lists
Extended IP access list 102
    permit udp any any range 16384 32767 (34947 matches)
Extended IP access list 103
    permit tcp any eq 1720 any (187 matches)
    permit tcp any any eq 1720 (86 matches)


!--- Verify the policy-pap configuration

maui-voip-austin#show policy-map voice-policy
  Policy Map voice-policy
    Class voice-signaling
      Weighted Fair Queueing
            Bandwidth 8 (kbps) Max Threshold 64 (packets)
    Class voice-traffic
      Weighted Fair Queueing
            Strict Priority
            Bandwidth 50 (kbps) Burst 1250 (Bytes)
    Class class-default
      Weighted Fair Queueing
            Flow based Fair Queueing Max Threshold 64 (packets)
---------------------------

!--- Debug priority command provides immediate feedback in case 
!--- of VoIP packet drops.
!--- The output below shows the error message when VoIP packets 
!--- are being dropped from the strict priority queue. 

maui-voip-sj#debug priority

priority output queueing debugging is on
maui-voip-sj#
Mar 17 19:47:09.947: WFQ: dropping a packet from the priority queue 0
Mar 17 19:47:09.967: WFQ: dropping a packet from the priority queue 0
Mar 17 19:47:09.987: WFQ: dropping a packet from the priority queue 0

-------------------------------------------------------------------



!--- Link Fragmentation and Interleaving (LFI) Verification



maui-voip-sj#show ppp multilink

!--- Verify the fragmentation size and multilink

Multilink1, bundle name is maui-voip-austin
         Bundle up for 00:08:04
         0 lost fragments, 0 reordered, 0 unassigned
         0 discarded, 0 lost received, 1/255 load
         0x6D received sequence, 0x6E sent sequence
         Member links: 1 active, 0 inactive (max not set, min not set)
         Serial0/0, since 00:08:09, last rcvd seq 00006C 160 weight

  !--- Notice the fragmentation size is 160 Bytes. The link is configured with a 
  !--- bandwidth of 128 kbps and a serialization delay of 10 msec. 
  !--- Fragment Size (in bits) = bandwidth * serialization delay.
  !--- Note: There are 8 bits in one byte.


-------------------------------------------------------


!--- Link Fragmentation and Interleaving (LFI) Verification 

!--- Testing Multilink PPP Link LFI
!--- This output displays fragmentation and interleaving information
!--- when the the 128kbps PPP link is loaded with big data and VoIP packets.

maui-voip-sj#debug ppp multilink fragments
Multilink fragments debugging is on

1w3d: Se0/0 MLP: O frag 800004CF size 160
1w3d: Se0/0 MLP: O frag 000004D0 size 160
1w3d: Se0/0 MLP: I ppp IP (0021) size 64 direct
1w3d: Mu1 MLP: Packet interleaved from queue 40
1w3d: Se0/0 MLP: O ppp IP (0021) size 64
1w3d: Se0/0 MLP: I ppp IP (0021) size 64 direct
1w3d: Se0/0 MLP: O frag 400004D1 size 106
1w3d: Se0/0 MLP: O ppp IP (0021) size 64
1w3d: Se0/0 MLP: I ppp IP (0021) size 64 direct
1w3d: Se0/0 MLP: O ppp IP (0021) size 64 direct
1w3d: Se0/0 MLP: I frag 800004E0 size 160 direct
1w3d: Se0/0 MLP: I frag 000004E1 size 160 direct
1w3d: Se0/0 MLP: I ppp IP (0021) size 64 direct
-------------------------------------------------------------------


!--- Sample output of show ip rtp header-compression command

maui-voip-sj#show ip tcp header-compression
TCP/IP header compression statistics:  Interface Multilink1:
    Rcvd:    10 total, 6 compressed, 0 errors
             0 dropped, 0 buffer copies, 0 buffer failures
    Sent:    10 total, 7 compressed,
             230 bytes saved, 99 bytes sent
             3.32 efficiency improvement factor
    Connect: 16 rx slots, 16 tx slots,
             2 long searches, 1 misses 0 collisions, 0 negative cache hits
             90% hit ratio, five minute miss rate 0 misses/sec, 0 max

----------------------------------------------------------------------


!--- This command displays information of the voip dial-peers command.

maui-voip-sj#show dial-peer voice 2
VoiceOverIpPeer2
        information type = voice,
        tag = 2, destination-pattern = `6000',
        answer-address = `', preference=0,
        group = 2, Admin state is up, Operation state is up,
        incoming called-number = `', connections/maximum = 0/unlimited,
        application associated:
        type = voip, session-tMarget = `ipv4:172.22.130.2',
        technology prefix:
        ip precedence = 0, UDP checksum = disabled,
        session-protocol = cisco, req-qos = best-effort,
        acc-qos = best-effort,
        fax-rate = voice,   payload size =  20 bytes
        codec = g729r8,   payload size =  20 bytes,
        Expect factor = 10, Icpif = 30,signaling-type = cas,
        VAD = enabled, Poor QOV Trap = disabled,
        Connect Time = 283, Charged Units = 0,
        Successful Calls = 1, Failed Calls = 0,
        Accepted Calls = 1, Refused Calls = 0,
        Last Disconnect Cause is "10  ",
        Last Disconnect Text is "normal call clearing.",
        Last Setup Time = 93793451.

-------------------------------------------------------------------------

!---The CPU utilization of the router should not exceed the 50-60 percent
!--- during any five-minute interval.

maui-voip-austin#show processes cpu
CPU utilization for five seconds: 12%/8%; one minute: 11%; five minutes: 9%
 PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process
   1         148    310794          0  0.00%  0.00%  0.00%   0 Load Meter
   2          76        23       3304  0.81%  0.07%  0.01%   0 Exec


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

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


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


Document ID: 7111