Contenu

Introduction

Conditions préalables

Conditions requises

Components Used

Conventions

Directives de conception QoS pour les liaisons VoIP sur PPP

Priorité stricte pour le trafic vocal (priorité IP RTP ou LLQ)

Directives de configuration LLQ

Instructions de configuration de priorité IP RTP

Fragmentation et entrelacement de liaison (LFI) : Multilink PPP

Protocole en temps réel compressé (cRTP)

Autres conseils de réduction de la bande passante

Diagramme du réseau

Configurations

Commandes de vérification et de dépannage

Exemple de résultat show and debug

Informations connexes

Introduction

Cet exemple de configuration étudie un VoIP avec le protocole point à point (PPP) sur une configuration de ligne louée à faible bande passante. Ce document contient des informations techniques de base sur les fonctionnalités, les directives de conception et les stratégies de vérification et de dépannage de base.

Remarque : Il est important de noter que dans la configuration ci-dessous, les deux routeurs sont connectés dos à dos sur une ligne louée. Dans la plupart des topologies, cependant, les routeurs vocaux peuvent exister n’importe où. Généralement, les routeurs vocaux utilisent la connectivité LAN à d’autres routeurs connectés au WAN (en d’autres termes, une ligne louée PPP). Ceci est important car si vos routeurs vocaux ne sont pas directement connectés via PPP sur une ligne louée, toutes les commandes de configuration WAN doivent être configurées sur les routeurs connectés au WAN, et non sur les routeurs vocaux, comme indiqué dans les configurations ci-dessous.

Conditions préalables

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Components Used

Les configurations présentées dans ce document ont été testées avec cet équipement :

- Deux Cisco 3640 avec le logiciel Cisco IOS® version 12.2.6a (IP Plus)

- La priorité RTP IP a été introduite dans Cisco IOS version 12.0(5)T.

- LLQ a été introduit dans Cisco IOS version 12.0(7)T.

- LFI a été introduit dans Cisco IOS version 11.3.

- Les versions de Cisco IOS supérieures à 12.0.5T offrent des améliorations significatives en termes de performances pour cRTP.

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

Directives de conception QoS pour les liaisons VoIP sur PPP

Cette section fournit des directives de conception pour configurer les lignes louées VoIP sur PPP (en mettant l'accent sur les liaisons à faible débit). Deux conditions de base sont requises pour une bonne qualité vocale :

- Délai minimal de bout en bout et évitement de gigue (variation de délai).

- Besoins en bande passante de liaison optimisés et correctement conçus.

Pour garantir les exigences ci-dessus, il y a plusieurs lignes directrices importantes à suivre :

Ligne directrice

Description

Priorité stricte pour le trafic vocal (priorité IP RTP ou LLQ)

Méthode permettant d'accorder une priorité stricte au trafic vocal.

Fragmentation et entrelacement de liaison (LFI)

Peut être obligatoire pour les liaisons à faible vitesse.

Compression RTP

Pas nécessaire pour fournir une bonne qualité vocale, mais réduit la consommation de bande passante des appels. Le conseil général concernant la compression RTP est de l'appliquer après une configuration fonctionnelle avec une bonne qualité vocale (simplifie le dépannage).

Contrôle d'admission des appels (CAC)

Non traité dans ce document. CAC permet de contrôler le nombre d'appels pouvant être établis sur la liaison. Par exemple, si la liaison WAN entre les deux passerelles dispose de la bande passante nécessaire pour transporter seulement deux appels VoIP, l'admission d'un troisième appel peut affecter la qualité vocale des trois appels. Pour plus d'informations, consultez : Contrôle d'admission des appels VoIP .

Pour résumer, deux fonctions sont obligatoires pour la liaison PPP basse vitesse avec routeur/passerelles comme seules sources de trafic vocal :

1. Priorité stricte pour le trafic vocal

2. Fragmentation et entrelacement de liaison (LFI)

Priorité stricte pour le trafic vocal (priorité IP RTP ou LLQ)

Depuis la version 12.2 du logiciel Cisco IOS, il existe deux méthodes principales pour fournir une priorité stricte au trafic vocal :

- Priorité IP RTP (également appelée PQ/WFQ) : File d'attente prioritaire / Weighted Fair Queuing )

- Mise en file d'attente à faible latence (également appelée PQ/CBWFQ : File d'attente prioritaire / File d'attente pondérée basée sur les classes).

Priorité RTP IP

La priorité RTP IP crée une file d'attente de priorité stricte pour un ensemble de flux de paquets RTP appartenant à une plage de ports de destination UDP (User Datagram Protocol). Bien que les ports réels utilisés soient négociés dynamiquement entre les périphériques finaux ou les passerelles, tous les produits VoIP Cisco utilisent la même plage de ports UDP (16384-32767). Une fois que le routeur reconnaît le trafic VoIP, il le place dans la file d'attente de priorité stricte. Lorsque la file d'attente prioritaire est vide, les autres files d'attente sont traitées selon la mise en file d'attente pondérée standard (WFQ). La priorité RTP IP ne devient active qu’en cas d’encombrement dans l’interface. Cette image illustre le fonctionnement de la priorité RTP IP :

Remarque : la priorité RTP IP permet le découpage de la file d'attente prioritaire (PQ) lorsqu'il y a de la bande passante disponible sur la file d'attente par défaut (WFQ), mais applique strictement le contenu de la file d'attente prioritaire en cas d'encombrement sur l'interface.

Mise en file d'attente à faible latence

LLQ est une fonctionnalité qui fournit une file d'attente PQ stricte à CBWFQ (Class-Based Weighted Fair Queuing). LLQ active une PQ stricte unique au sein de CBWFQ au niveau de la classe. Avec LLQ, les données sensibles au délai (dans le PQ) sont retirées de la file d'attente et envoyées en premier. Dans une VoIP avec mise en oeuvre LLQ, le trafic vocal est placé dans la PQ stricte.

Le PQ est contrôlé pour s'assurer que les files d'attente équitables ne manquent pas de bande passante. Lorsque vous configurez le PQ, vous spécifiez en Kbits/s la bande passante maximale disponible pour le PQ. Lorsque l'interface est congestionnée, le PQ est traité jusqu'à ce que la charge atteigne la valeur Kbits/s configurée dans l'instruction priority. L'excès de trafic est alors supprimé pour éviter le problème lié à la fonctionnalité de groupe de priorités héritée de Cisco consistant à affamer les files d'attente de priorité inférieure.

Cette méthode est plus complexe et flexible que la priorité IP RTP. Le choix entre les méthodes doit être basé sur les modèles de trafic de votre réseau réel et vos besoins réels.

Priorité LLQ / IP RTP

Ce tableau récapitule les principales différences entre les priorités LLQ et IP RTP et fournit des indications sur le moment d'utiliser chaque méthode.

Mise en file d'attente à faible latence (LLQ)

Priorité RTP IP

Correspondance du trafic vocal selon :

- Listes d’accès (pour la plage de ports UDP, les adresses d’hôtes, les champs ToS d’en-tête IP : Priorité IP, DSCP, etc.)

- Plage de ports RTP IP

- Champs ToS IP (Type de service) : Priorité DCSP et/ou IP

- Protocoles et interfaces d'entrée

- Tous les critères de correspondance valides utilisés dans CBWFQ

Avantages :

- Plus de flexibilité sur la manière dont le trafic est adapté et dirigé vers les PQ et CBWFQ stricts

- Peut configurer des classes supplémentaires pour garantir la bande passante pour d'autres trafics, tels que : Signalisation et vidéo VoIP.

Inconvénients :

- Configuration complexe

Correspondance du trafic vocal selon :

- Basé sur la plage de ports UDP RTP : 16384-32767

Avantages :

- Configuration simple

Inconvénients :

- Trafic RTCP (VoIP Signaling) servi dans la file d'attente WFQ
Remarque : le protocole RTP utilise le protocole RTCP (Real Time Control Protocol) pour contrôler la livraison des paquets RTP. Alors que les ports RTP utilisent des nombres pairs, les ports RTCP utilisent des nombres impairs dans la plage 16384-32767. La priorité RTP IP place les ports RTP dans le PQ, tandis que les ports RTCP sont servis dans la file d'attente pondérée par défaut.

- Sert le trafic VoIP dans le PQ, mais tout autre trafic nécessitant un traitement préférentiel et une garantie de bande passante est servi dans le WFQ. Bien que WFQ puisse différencier les flux avec des poids (basés sur la priorité IP), il ne peut garantir la bande passante pour aucun flux.

Directives

- Le choix entre ces deux éléments doit être basé sur les modèles de trafic de votre réseau réel et vos besoins réels.

- Si vous devez accorder une priorité stricte à votre trafic vocal et que d'autres trafics peuvent être traités comme un seul type (données), alors la priorité RTP IP fait un bon travail pour votre réseau avec une configuration simple.

- Si vous prévoyez de hiérarchiser le trafic vocal en fonction de critères autres que les ports UDP (par exemple DiffServ PHB), LLQ est nécessaire.

Pour plus d'informations sur la corrélation et les différences des méthodes de mise en file d'attente, reportez-vous à la Vue d'ensemble de la gestion des encombrements.

Directives de configuration LLQ

Suivez les instructions suivantes pour configurer LLQ :

1. Créer une carte de classe pour le trafic VoIP et définir des critères de correspondance

Ces commandes expliquent comment effectuer cette tâche :

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.

Ces listes d'accès peuvent également être utilisées pour faire correspondre le trafic voix à la commande 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.

Voici d'autres méthodes de correspondance qui peuvent être utilisées à la place des groupes d'accès :

- À partir de la version 12.1.2.T de Cisco IOS, la fonctionnalité IP RTP Priority est mise en oeuvre pour LLQ. Cette fonctionnalité correspond au contenu de la classe de priorité en examinant les ports UDP configurés et est soumise à la limitation de servir uniquement les ports pairs dans le PQ.

class-map voice

match ip rtp 16384 16383

- Ces deux méthodes fonctionnent en supposant que les paquets VoIP sont marqués au niveau des hôtes d'origine, ou mis en correspondance et marqués dans le routeur avant d'appliquer l'opération LLQ sortante.

class-map voice

match ip precedence 5

ou

class-map voice

match ip dscp ef

Remarque : À partir de la version 12.2.2T de l'IOS, les terminaux de numérotation dial-peer VoIP peuvent marquer les paquets de transmission et de signalisation vocale avant le fonctionnement LLQ. Cela permet de marquer et de faire correspondre les paquets VoIP via des valeurs de code DSCP pour LLQ.

2. Créer une carte de classe pour la signalisation VoIP et définir des critères de correspondance (facultatif)

Ces commandes expliquent comment effectuer cette tâche :

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

Remarque : les appels VoIP peuvent être établis à l'aide de H.323, SIP, MGCP ou Skinny (protocole propriétaire utilisé par Cisco Call Manager). L'exemple ci-dessus supposait H.323 Fast Connect. Cette liste sert de référence pour les ports utilisés par les canaux de signalisation/contrôle VoIP :

- H.323/H.225 = TCP 1720

- H.323/H.245 = TCP 11xxx (connexion standard)

- H.323/H.245 = TCP 1720 (connexion rapide)

- 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 (configurable)

3. Créer une carte de stratégie et associer aux cartes de classe VoIP

L'objectif de la carte de stratégie est de définir comment les ressources de liaison sont partagées ou affectées aux différentes classes de carte. Ces commandes expliquent comment effectuer cette tâche :

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

Remarque : Bien qu'il soit possible de mettre en file d'attente différents types de trafic en temps réel vers le PQ, Cisco vous recommande d'y diriger uniquement le trafic vocal. Le trafic en temps réel, tel que la vidéo, peut introduire des variations de délai (le PQ est une file d'attente FIFO - First In First Out - First In First Out). Le trafic vocal nécessite que le délai ne soit pas variable afin d'éviter la gigue.

Remarque : La somme des valeurs des instructions de priorité et de bande passante doit être inférieure ou égale à 75 % de la bande passante de la liaison. Sinon, service-policy ne peut pas être affecté à la liaison (pour afficher les messages d'erreur, assurez-vous que logging console est activée pour l'accès à la console et terminal monitor est activé pour l'accès Telnet).

Remarque : lors de la configuration de la VoIP sur une liaison de 64 Kbits/s pour prendre en charge deux appels vocaux, il est courant d'allouer plus de 75 % (48 Kbits/s) de la bande passante de la liaison au PQ. Dans de tels cas, vous pouvez utiliser la commande max-reservation-bandwidth 80 pour augmenter la bande passante disponible à 80 % (51 Kbits/s).

Pour plus d'informations sur les commandes bandwidth et priority, référez-vous à Comparaison des commandes bandwidth et priority d'une stratégie de service QoS.

4. Activer LLQ : Appliquer la carte de stratégie à l'interface WAN sortante

Ces commandes expliquent comment effectuer cette tâche :

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.

Instructions de configuration de priorité IP RTP

Pour configurer la priorité IP RTP, procédez comme suit :

- Router(config-if)#ip rtp priority starting-rtp-port-#port-#-rangebandwidth

Commande

Description

starting-rtp-port-number

Liaison inférieure du port UDP. Numéro de port le plus bas auquel les paquets sont envoyés. Pour VoIP, définissez cette valeur sur 16384.

port-number-range

Plage de ports de destination UDP. Un nombre, ajouté au numéro de port de départ rtp, donne le numéro de port UDP le plus élevé. Pour VoIP, définissez cette valeur sur 16383 (32767 - 16384 = 16383)

bandwidth

Bande passante maximale autorisée (kbits/s) dans la file d'attente prioritaire. Définissez ce nombre en fonction du nombre d'appels simultanés pris en charge par le système.

Exemple de configuration :

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

Fragmentation et entrelacement de liaison (LFI) : Multilink PPP

Alors que 1 500 octets est une taille commune pour les paquets de données, un paquet VoIP type (transportant des trames vocales G.729) peut avoisiner 66 octets (charge utile vocale de 20 octets, en-tête de couche 2 de 6 octets, en-tête RTP et UDP de 20 octets et en-tête IP de 20 octets).

Maintenant, imaginez une liaison de ligne louée de 56 Kbits/s où coexistent le trafic voix et données. Si un paquet vocal est prêt à être sérialisé juste au moment où un paquet de données commence à être transmis sur la liaison, alors il y a un problème. Le paquet vocal sensible au délai doit attendre 214 ms avant d'être transmis (il faut 214 ms pour sérialiser un paquet de 1 500 octets sur une liaison de 56 Kbits/s).

Comme vous pouvez le voir, les paquets de données volumineux peuvent retarder la livraison des petits paquets voix, réduisant ainsi la qualité de la parole. La fragmentation de ces paquets de données volumineux en paquets plus petits et l'interposition de paquets de voix entre les fragments réduisent la gigue et le délai. La fonctionnalité LFI (Link Fragmentation and Interleave) de Cisco IOS permet de répondre aux exigences de livraison en temps réel de VoIP. Cette image illustre le fonctionnement de LFI :

Comme le montre le tableau 1, le délai de sérialisation (le temps nécessaire pour placer réellement les bits sur une interface) introduit sur les liaisons WAN à faible vitesse peut être significatif, étant donné que le délai cible d’un bout à l’autre ne doit pas dépasser 150 ms. (La recommandation ITU-T G.114 spécifie un maximum de 150 ms de bout en bout à sens unique.)

Tableau 1 . Délai de sérialisation pour différentes tailles de trame sur les liaisons à faible débit Délai de sérialisation = taille de trame (bits)/bande passante de liaison (bits/s)

1 octet

64 octets

128 octets

256 octets

512 octets

1024 octets

1500 Bytes

56 kbps

143 us

9 ms

18 ms

36 ms

72 ms

144 ms

214 ms

64 kbps

125 us

8 ms

16 ms

32 ms

64 ms

126 ms

187 ms

128 kbps

62,5 us

4 ms

8 ms

16 ms

32 ms

64 ms

93 ms

256 kbps

31 us

2 ms

4 ms

8 ms

16 ms

32 ms

46 ms

512 kbps

15,5 us

1 ms

2 ms

4 ms

8 ms

16 ms

32 ms

768 kbps

10 us

640 us

1.28 ms

2.56 ms

5.12 ms

10.24 ms

15 ms

1536 kbps

5

320 us

640 us

1.28 ms

2.56 ms

5.12 ms

7.5 ms

Remarque : pour les applications vocales, le délai de sérialisation recommandé (par saut) est de 10 ms et ne doit pas dépasser 20 ms.

La taille du fragment de liaison est configurable en millisecondes (ms) avec la commande ppp multilink fragment-delay. LFI nécessite que ppp multilink soit configuré sur l'interface avec ppp multilink interleave activé. Pour plus d'informations sur la configuration de LFI, reportez-vous à la section de ce document.

Remarque : dans les cas où vous avez plus d'une connexion T1 semi-dédiée (768 Kbits/s), vous n'avez pas besoin de fonction de fragmentation. (Cependant, vous avez toujours besoin d'un mécanisme QoS, tel que LLQ ou IP RTP Priority). La demi-T1 offre suffisamment de bande passante pour permettre aux paquets vocaux d'entrer et de quitter la file d'attente sans délai. En outre, il se peut que vous n'ayez pas besoin de Compression for Real-time Protocol (cRTP), ce qui permet de conserver la bande passante en compressant des en-têtes RTP IP, dans le cas d'une demi-T1.

Protocole en temps réel compressé (cRTP)

Remarque : cRTP n'est pas nécessaire pour garantir une bonne qualité vocale. Cette fonction réduit la consommation de bande passante. Configurez cRTP après que toutes les autres conditions sont remplies et que la qualité de la voix est bonne. Cette procédure permet d'économiser du temps de dépannage en isolant les problèmes potentiels liés au protocole cRTP.

Basée sur la RFC 2508, la fonctionnalité de compression d'en-tête RTP compresse l'en-tête IP/UDP/RTP de 40 octets à 2 ou 4 octets, réduisant ainsi la consommation inutile de bande passante. Il s'agit d'un système de compression saut par saut ; par conséquent, cRTP doit être configuré aux deux extrémités de la liaison (sauf si l'option passive est configurée). Pour configurer cRTP, utilisez cette commande au niveau de l'interface :

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

Comme le processus de compression peut être intensif en CPU, la compression d'en-tête RTP est implémentée dans les chemins de commutation Fast Switching et CEF comme version 12.0.0(7)T d'IOS. Parfois, ces implémentations sont interrompues, puis la seule manière qui fonctionne sera commutée. Cisco recommande uniquement l'utilisation de cRTP avec des liaisons inférieures à 768 Kbits/s, sauf si le routeur fonctionne à un faible taux d'utilisation du CPU. Surveillez l'utilisation du processeur du routeur et désactivez cRTP s'il dépasse 75 %.

Remarque : lorsque vous configurez la commande ip rtp header-compression, le routeur ajoute la commande ip tcp header-compression à la configuration par défaut. Il est utilisé pour compresser les paquets TCP/IP des en-têtes. La compression d’en-tête est particulièrement utile sur les réseaux avec un pourcentage important de petits paquets, tels que ceux qui prennent en charge de nombreuses connexions Telnet. La technique de compression d'en-tête TCP, décrite en détail dans la RFC 1144, est prise en charge sur les lignes série à l'aide de l'encapsulation HDLC ou PPP.

Pour compresser les en-têtes TCP sans activer cRTP, utilisez cette commande :

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

Pour plus d'informations: Protocole de transport en temps réel compressé

Autres conseils de réduction de la bande passante

- utiliser des codeurs/décodeurs à faible débit (codec) sur les segments d'appel VoIP ; G.729 (8 Kbits/s) est recommandé. (Codec par défaut sur les terminaux de numérotation dial-peer VoIP). Pour configurer différents codecs, utilisez la commande router(config-dial-peer)#codec sous le terminal de numérotation dial-peer voip souhaité.

- Bien que la multifréquence à deux tonalités (DTMF) soit généralement transportée avec précision lors de l'utilisation de codecs vocaux à haut débit tels que G.711, les codecs à faible débit (tels que G.729 et G.723.1) sont hautement optimisés pour les modèles de voix et ont tendance à déformer les tonalités DTMF. Cette approche peut entraîner des problèmes d'accès aux systèmes de réponse vocale interactive (IVR). La commande dtmf relay résout le problème de distorsion DTMF en transportant les tonalités DTMF hors bande ou séparées du flux vocal codé. Si des codecs à faible débit (G.729, G.723) sont utilisés, activez dtmf relay sous le terminal de numérotation dial-peer VoIP.

- Une conversation type peut contenir entre 35 et 50 % de silence. À l'aide de la détection d'activité vocale (VAD), les paquets de silence sont supprimés. Pour la planification de la bande passante VoIP, supposez que la technologie VAD réduit la bande passante de 35 %. Le VAD est configuré par défaut sous les terminaux de numérotation dial-peer VoIP. Pour activer ou désactiver VAD, utilisez les commandes router(config-dial-peer)#vad et router(config-dial-peer)# no vad sous les homologues de numérotation voip souhaités.

Diagramme du réseau

Configurations

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

Commandes de vérification et de dépannage

Avant d'essayer une commande debug, référez-vous à Informations importantes sur les commandes de débogage. Pour plus d'informations sur les commandes répertoriées ici, reportez-vous à la section Exemple de sortie show et débogage de ce document.

Commandes d'interface :

- show interface [serial | multilink] : utilisez cette commande pour vérifier l'état de l'interface série. Assurez-vous que l'interface série et multiliaison sont actives et ouvertes.

- Dépannage des lignes série

Commandes LFI :

- show ppp multilink : cette commande affiche les informations de lot pour les ensembles Multilink PPP.

- debug ppp multilink fragments - Cette commande debug affiche des informations sur les fragments multiliaison individuels et les événements d'entrelacement. Cette sortie de commande identifie également le numéro de séquence du paquet et les tailles de fragments.

Commandes de priorité LLQ/IP RTP :

- show policy-map interface multilink interface# - Cette commande est très utile pour voir l'opération LLQ et voir les pertes dans le PQ. Pour plus d'informations sur les différents champs de cette commande, référez-vous à Présentation des compteurs de paquets dans la sortie de show policy-map interface.

- show policy-map policy_map_name : cette commande affiche des informations sur la configuration policy-map.

- show queue interface-type interface-number - Cette commande répertorie la configuration et les statistiques de mise en file d'attente équitable pour une interface particulière.

- Debug priority - Cette commande de débogage affiche les événements de mise en file d'attente par priorité et indique si la suppression a lieu dans cette file d'attente. Référez-vous également à Dépannage des pertes de sortie avec mise en file d'attente prioritaire.

- show class-map class_name : cette commande affiche des informations sur la configuration class-map.

- show call active voice - Cette commande est utile pour vérifier la perte de paquets au niveau du DSP.

Autres commandes/références :

- show ip rtp header-compression - Cette commande affiche les statistiques de compression d'en-tête RTP.

- Dépannage et débogage des bases des appels VoIP

- Commandes de débogage VoIP

Problèmes connus :

- CSCds43465 : « LLQ, Policer, Shaper Doit Prendre des commentaires sur la compression CRTP » Pour consulter les notes de version, reportez-vous à Bug ToolKit (clients enregistrés uniquement).

Directives :

Voici quelques étapes de dépannage de base, une fois que la liaison ppp est opérationnelle (MLPPP, Fragmentation, Interleave) :

1. show call active voice : permet de vérifier les paquets perdus au niveau du DSP.

2. show interface : permet de vérifier les problèmes de ligne série générale ou d'interface. Les abandons sur l'interface ne signifient pas encore un problème, mais il est préférable de supprimer le paquet de la file d'attente de faible priorité avant qu'il atteigne la file d'attente de l'interface.

3. show policy-map interface : permet de vérifier les pertes LLQ et la configuration de la file d'attente. Ne doit pas signaler les pertes qui violent la politique.

4. show ip rtp header-compression : permet de vérifier les problèmes spécifiques à cRTP.

Exemple de résultat show and debug

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

Informations connexes

- Mise en file d'attente à faible latence (LLQ)

- Présentation de la gestion des encombrements

- Mise en oeuvre de la qualité de service (QoS)

- Voix sur IP - Consommation de bande passante par appel

- Qualité de service pour la voix sur IP

- Configuration de la voix sur IP

- Assistance technique concernant la technologie vocale

- Support produit pour Voix et Communications IP

- Dépannage des problèmes de téléphonie IP Cisco

- Support technique - Cisco Systems