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

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

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

Содержание

Введение
Предварительные условия
      Требования
      Используемые компоненты
      Условные обозначения
Указания по проектированию QoS для каналов VoIP Over PPP
      Строгий приоритет для голосового трафика (IP RTP Priority или LLQ)
      Руководство по конфигурации LLQ
      Руководство по конфигурированию IP RTP Priority
      Фрагментация и чередование каналов (LFI): Multilink PPP
      Протокол cRTP
      Другие советы по уменьшению потребления пропускной способности
Сетевая диаграмма
Конфигурации
Команды для проверки и устранения неполадок
Примеры выходных данных команд show и debug
Связанные обсуждения сообщества поддержки Cisco
Дополнительные сведения

Введение

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

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

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

Требования

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

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

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

  • Два маршрутизатора Cisco 3640s с программным обеспечением Cisco IOS® версии 12.2.6a (IP Plus)

  • Метод IP RTP Priority был впервые введен в Cisco IOS версии 12.0(5)T.

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

  • Метод LFI был добавлен в Cisco IOS версии 11.3.

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

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

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

Указания по проектированию QoS для каналов VoIP Over PPP

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

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

Указание

Описание

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

Метод обеспечения строгого приоритета для голосового трафика.

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

Может быть обязательным требованием для низкоскоростных каналов.

Сжатие RTP

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

Контроль приема вызовов (CAC)

Не описывается в этом документе. CAC используется для контроля числа вызовов, устанавливаемых с использованием канала. Например, если канал WAN между двумя шлюзами имеет пропускную способность для двух каналов VoIP, принятие третьего вызова приведет к ухудшению качества для всех трех вызовов. Дополнительные сведения см. в: Контроль приема вызовов VoIP.

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

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

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

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

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

  • IP RTP Priority (другое название PQ/WFQ: Приоритетная очередь/Взвешенная справедливая очередность)

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

IP RTP Priority

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

pq-wfq.gif

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

Очередность с низкой задержкой (LLQ)

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

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

llq.gif

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

Сравнение LLQ и IP RTP Priority

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

Очередность с низкой задержкой (LLQ)

IP RTP Priority

Критерии сопоставления голосового трафика:

  • Списки доступа (для диапазона UDP-портов, адресов хостов и полей ToS заголовка IP: Приоритет IP, DSCP и др.)

  • Диапазон портов IP RTP

  • Поля IP ToS (Тип обслуживания): DCSP и/или приоритет IP

  • Протоколы и интерфейсы ввода

  • В CBWFQ используются все допустимые критерии сопоставления

Достоинства:

  • Большая гибкость при сопоставлении и направлении трафика в очередь строгого приоритета и очередь CBWFQ

  • Возможна настройка дополнительных классов для гарантии пропускной способности для других типов трафика, таких как: Сигнализация VoIP и видео.

Недостатки:

  • Сложная настройка

Критерии сопоставления:

  • Диапазоны UDP-портов для RTP: 16384-32767

Достоинства:

  • Простая настройка

Недостатки:

  • RTCP-трафик (сигнализация VoIP) обслуживался в очереди WFQ

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

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

Указания

  • Выбор между ними следует делать на основе моделей трафика в реальной сети и ваших фактических потребностей.

  • Если вы хотите предоставить строгий приоритет голосовому трафику, и другой трафик может обрабатываться как один тип (данные), метод IP RTP Priority будет эффективен в сети с простой конфигурацией.

  • Если вы планируете приоритизировать голосовой трафик на основе критериев, отличных от UDP-портов (например, DiffServ PHB), необходимо использовать LLQ.

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

Руководство по конфигурации 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 
    
    !--- Выберите описательное имя класса (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
    
    !--- В этом примере сопоставление групп доступа выбрано из-за своей 
    !--- гибкости (оно использует список доступа)
    
    
    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
    
    
    !--- Теперь для сопоставления карты классов и группы доступа необходимо создать список доступа:
    
    maui-voip-sj(config)#access-list 102 permit udp any any range 16384 32776
    
    
    !--- Самый простой и безопасный способ — сопоставление диапазону портов UDP 16384-32767
    !--- Продукты Cisco IOS H.323 используют этот диапазон для передачи 
    !--- VoIP-пакетов.
    
    

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

    access-list 102 permit udp any any precedence critical 
    
    !--- Этот список фильтрует трафик на основе поля "TOS: Precedence" IP-пакета.  
    !--- Примечание. Убедитесь, что другой, неголосовой трафик НЕ использует то же 
    !--- значение приоритетности.
    
                  
    
    access-list 102 permit udp any any dscp ef
    
    !-- Чтобы список работал, VoIP-пакеты должны быть помечены 
    !--- кодом dscp ef перед передачей в интерфейс LLQ WAN. 
    !--- Дополнительные сведения о DSCP см. в документе 
    !--- Внедрение политик QoS с помощью DSCP
    !--- Примечание. Если в соответствии с маркировкой пакетов терминалы не являются доверенными, можно
    !--- маркировать входящий трафик, применив политику обслуживания к входящему
    !--- интерфейсу. Эта процедура не описывается в данном документе.
    
    
        
    Access-list 102 permit udp host 192.10.1.1 host 192.20.1.1
    
    !--- Список доступа можно использовать в ситуациях, когда устройства VoIP не могут 
    !--- выполнить маркировку приоритетности или dscp и невозможно определить 
    !--- диапазон UDP-портов для VoIP. 
    
    

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

    • Начиная с версии 12.1.2.T ПО Cisco IOS, функция IP RTP Priority внедрена для LLQ. Эта функция сопоставляет приоритеты классов содержимого в зависимости от конфигурации UDP-портов, при этом в приоритетной очереди обслуживаются только четные порты.

      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. Это список используется в качестве справочника портов, используемых сигнальными и управляющими каналами VoIP:

    • H.323/H.225 = TCP 1720

    • H.323/H.245 = TCP 11xxx (Standard Connect)

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

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

    • Skinny = TCP 2000-2002 (CM Encore)

    • ICCP = TCP 8001-8002 (CM Encore)

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

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

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

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

    maui-voip-sj(config)#policy-map VOICE-POLICY
    
    !--- Выберите описательное имя карты политик (policy_map_name).
    
    
    maui-voip-sj(config-pmap)#class voice-traffic
    maui-voip-sj(config-pmap-c)#priority ?  
    <8-2000000>  Kilo Bits per second
    
    !--- Назначьте классу "voice-traffic" очередь строгого приоритета
    !--- (команда priority) и пропускную способность.
    
    
    maui-voip-sj(config-pmap)#class voice-signaling
    maui-voip-sj(config-pmap-c)#bandwidth 8
    
    !--- Назначьте классу "voice-signaling" пропускную способность 8 Кбит/с
    
    
    maui-voip-sj(config-pmap)#class class-default
    maui-voip-sj(config-pmap-c)#fair-queue 
    
    !--- Всему остальному трафику будет назначена очередь WFQ
    
    

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

    Примечание: Сумма значений для инструкций priority и bandwidth должна быть меньше или равна 75 % пропускной способности канала. В противном случае политика serive policy не может быть назначена каналу (для просмотра сообщений об ошибках, убедитесь, что параметр logging console для доступа из консоли включен, и параметр terminal monitor включен для доступа через telnet).

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

    Дополнительные сведения о командах bandwidth и priority см. в документе Сравнение команд bandwidth и priority политики службы QoS

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

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

    maui-voip-sj(config)#interface multilink 1
    maui-voip-sj(config-if)#service-policy output VOICE-POLICY
    
    !--- В этом сценарии (MLPPP LFI) политика обслуживания применяется к
    !--- интерфейсу Multilink.
    
    
    

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

При настройке 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
    
       !--- Часть выходных данных пропущена
    
       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 фрагментация и чередования каналов (LFI) помогает удовлетворить требования VoIP к доставке в реальном времени. Этот рисунок иллюстрирует принцип работы LFI:

lfi.gif

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

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

1 байт

64 байт

128 байт

256 байт

512 байт

1024 байт

1500 байт

56 кбит/c

143 мкс

9 мс

18 мс

36 мс

72 мс

144 мс

214 мс

64 кбит/c

125 мкс

8 мс

16 мс

32 мс

64 мс

126 мс

187 мс

128 кбит/c

62,5 мкс

4 мс

8 мс

16 мс

32 мс

64 мс

93 мс

256 кбит/c

31 мкс

2 мс

4 мс

8 мс

16 мс

32 мс

46 мс

512 кбит/c

15,5 мкс

1 мс

2 мс

4 мс

8 мс

16 мс

32 мс

768 кбит/c

10 мкс

640 мкс

1.28 мс

2,56 мс

5,12 мс

10.24 мс

15 мс

1536 кбит/c

5 мкс

320 мкс

640 мкс

1,28 мс

2,56 мс

5,12 мс

7,.5 мс

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

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

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

Протокол cRTP

Примечание:  Для обеспечения хорошего качества голоса протокол 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 Кбит/с, или если маршрутизатор работает с низкой нагрузкой на ЦП. Проконтролируйте нагрузку на ЦП маршрутизатора и отключите 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 кбит/c). (Это кодек по умолчанию для одноранговых телефонных соединений 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.

Сетевая диаграмма

mlppp.gif

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

maui-voip-sj (Cisco 3640)

version 12.2service timestamps debug datetime msec

!--- < Часть выходных данных пропущена >

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

!--- Определение голосовой сигнализации и карт классов трафика
!--- класс "voice-traffic" использует список доступа 102 в качестве критерия сопоставления.
!--- класс "voice-signaling" использует список доступа 103 в качестве критерия сопоставления.


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

!--- Карта политик определяет способ назначения ресурсов канала 
!--- различным классам карты. В этой конфигурации очередь строгого приоритета
!--- назначается классу "voice-traffic" (на основе ACL в 
!--- классе "voice") с максимальной пропускной способностью = 45 кбит/c. 

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

    !--- Назначает очередь, которая гарантирует пропускную способность 8 кбит/c, трафику "voice-signaling".
    !--- Обратите внимания, что эта команда не является обязательной. Она никак не влияет на качество 
    !--- голоса, но позволяет обеспечить надежную сигнализацию.

  class class-default
   fair-queue

!--- Класс "class-default" используется для классификации трафика, который 
    !--- не входит ни в один из заданных классов.
    !--- Команда fair-queue связывает класс "class-default" с очередностью WFQ.

!
call rsvp-sync
!

!--- Обратите внимание, что MLPPP строго относится к механизмам LFI. Он не выполняет следующие операции:
!--- объединение нескольких последовательных интерфейсов в один виртуальный интерфейс, в 
!--- соответствии с именем (Такое объединение поддерживается для данных, но НЕ рекомендуется 
!--- для голоса). Это может привести к появлению эффекта "дрожания" и отсутствию звука

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

  !--- LLQ — это внеполосная операция, которая применяется к внеполосным интерфейсам 
  !--- WAN.

 no cdp enable
 ppp multilink
 ppp multilink fragment-delay 10
  
!--- Заданное значение 10 устанавливает размер фрагмента, который обеспечивает 
  !--- максимальную задержку сериализации 10 мс для всех   все фрагментов.

 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

  !--- команда bandwidth должна иметь верное значение для 
  !--- расчета правильного размера фрагмента.

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

  !--- Эта команда привязывает multilink к физическому 
  !--- последовательному интерфейсу.

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

!--- список доступа 102 сопоставляет трафик VoIP, основываясь на диапазоне UDP-портов. 
!--- В приоритетную очередь помещаются как четные, так и нечетные порты.
!--- список 103 используется для сопоставления протокола сигнализации VoIP. В этом
!--- случае, используется H.323 V2 с функцией быстрого соединения.

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
!
сlass-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

 !--- Настраивайте cRTP после того, как будет готова рабочая конфигурация.
 !--- Это помогает изолировать потенциальные проблемы cRTP.

!
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 eq 1720 any
!
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- Эта команда отображает сведения о пакетах Multilink PPP.

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

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

  • show policy-map interface multilink interface#- Эта команда отображает работу LLQ и предоставляет сведения об элементах, отброшенных из приоритетной очереди. Дополнительные сведения о полях команды см. в разделе Общие сведения о счетчиках пакетов в выходных данных команды show policy-map interface.

  • show policy-map policy_map_name- Эта команда отображает данные о конфигурации карты политик.

  • show queue interface-type interface-number- Эта команда выводит конфигурацию и статистику справедливой очереди для определенного интерфейса.

  • Debug priority- Эта команда отладки отображает сведения о событиях приоритетной очередности и сообщает, происходило ли отбрасывание элементов из этой очереди. См. также раздел Устранение неполадок при сбросе выходных данных при формировании очередей по приоритету.

  • show class-map class_name- Эта команда отображает сведения о конфигурации карты классов.

  • show call active voice- Эта команда используется для определения потерянных пакетов на уровне DSP.

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

Известные проблемы:

Инструкции:

Ниже приводится описание некоторых основных действий по устранению неполадок, которые применяются, если канал 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.

Примеры выходных данных команд show и debug

 

!-----------------------------------------------
 !-----------------------------------------------
 !---- Для захвата разделов этих выходных данных, пропускная способность приоритетных очередей LLQ 
 !---- была снижена, кроме того, в канал был отправлен большой объем
 !---- трафика, чтобы вызвать отбрасывание пакетов.
 !-----------------------------------------------
 !-----------------------------------------------

 !---- Определение отброшенных пакетов (во время активного вызова)

 !--- Предположим, что канал ppp работает, первый этап 
 !--- выявления проблем качества звука — определение потерянных пакетов 
 !--- в DSP. Примечание: Используйте команду show call active voice, а 
 !--- НЕ show call active voice brief


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


 !--- Сообщает, что соединение установлено и обе ветви вызова активны


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

 !--- сообщает, что данный вызов является активным
 !--- (#define D_callActiveCallState_active 4).
          CallOrigin=2
          ChargedUnits=0
          InfoType=2
          TransmitPackets=365
          TransmitBytes=7300
          ReceivePackets=229
          ReceiveBytes=4580

 VOIP:

 !--- Для данного вызова это был оконечный шлюз.
 !--- В этом шлюзе вызов запустил ветвь VoIP.

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

 !--- сообщает, по какому IP-адресу был создан поток RTP.

          RemoteUDPPort=18778
          RemoteSignallingIPAddress=172.22.130.1

 !--- Сообщает, с какого IP-адреса приходят сообщения сигнализации.

          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 мсек
 HiWaterPlayoutDelay=70 мсек
 LoWaterPlayoutDelay=51 ms
 ReceiveDelay=51 ms
 LostPackets=90
 EarlyPackets=1
 LatePackets=0

 !--- Сообщает о наличии эффекта "дрожания, потерянных пакетов или 
 !--- поврежденных пакетов.

 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



 !----------------------------------------------------------
 !--- Проверка интерфейса

 !--- Убедитесь, что отображаются следующие значения:
 !--- LCP Open, multilink Open: Инструкция "Open" протокола LCP 
 !--- сообщает о том, что соединение установлено.
 !--- Open:IPCP. Сообщает, что IP-трафик можно передавать через канал PPP.


 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
----------------------------------------------------------------

!--- Примечание: Нет отбрасывания пакета на уровне интерфейса.
!--- Весь трафик, отброшенный в соответствии с политиками, 
!--- отбрасывается до того, как попадает в очередь интерфейса.


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



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

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

!--- Это класс трафика голосовой сигнализации.

         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)

!--- Это класс приоритетной очереди для голосового трафика.

         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)
!--- Обратите внимание, что пропускная способность приоритетной очереди была снижена, чтобы вызвать отбрасывание пакетов.
         (pkts matched/bytes matched) 458/29647
         (total drops/bytes drops) 91/5890
!--- Некоторые пакеты были отброшены. В качественно спроектированном канале
!--- не должно быть отброшенных пакетов для класса PQ (или их должно быть очень мало).

 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

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


!--- Поверьте конфигурацию карты классов

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


!--- Проверьте списки доступа в картах классов

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)


!--- Проверьте конфигурацию карты политик

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 обеспечивает мгновенную реакцию 
!--- при отбрасывании пакетов VoIP.
!--- В выходных данных ниже отображается сообщение об ошибке, которое появляется, когда пакеты VoIP 
!--- отбрасываются из очереди строгого приоритета. 

maui-voip-sj#debug priority

priority output queueing debugging is on
maui-voip-sj#
Mar 17 19:47:090,947: WFQ: dropping a packet from the priority queue 0
Mar 17 19:47:090,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

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



!--- Проверка фрагментации и чередования каналов (LFI)



maui-voip-sj#show ppp multilink

!--- Проверьте размер фрагмента и канал 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

  !--- Обратите внимание, что размер фрагмента равен 160 байт. Канал настроен с 
  !--- пропускной способностью 128 кбит/с и задержкой сериализации 10 мс. 
  !--- Размер фрагмента (в байтах) = пропускная способность * задержка сериализации.
  !--- Примечание: В одном байте 8 бит.


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


!--- Проверка фрагментации и чередования каналов (LFI) 

!--- Тестирование LFI для канала Multilink PPP
!--- В этих выходных данных отображаются сведения о фрагментации и чередовании в ситуации,
!--- когда в канал PPP 128 Кбит/с загружается большой объем данных и пакетов VoIP.

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
-------------------------------------------------------------------


!--- Пример вывода команды show ip rtp header-compression 

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

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


!--- Эта команда отображает сведения о команде voip dial-peers.

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.

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

!---Нагрузка на ЦП маршрутизатора не должна превышать 50-60 %
!--- для любого 5-минутного интервала.

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