VoIP sur relais de trame avec qualité de service (fragmentation, formatage du trafic, LLQ / IP RTP Priority)

Introduction

Ce document fournit un exemple de configuration de voix sur IP (VoIP) sur un réseau Frame Relay avec la Qualité de service (QoS). 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.

Il est important de noter que la configuration de ce document comporte deux routeurs vocaux connectés au réseau Frame Relay. Cependant, dans de nombreuses topologies, 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. Ceci est important car si vos routeurs vocaux ne sont pas directement connectés au réseau Frame Relay, 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 de ce document.

Conditions préalables

Conditions requises

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

Components Used

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• Routeur Cisco 3640 avec logiciel Cisco IOS® version 12.2.6a (Enterprise Plus)

• Routeur Cisco 2621 avec logiciel Cisco IOS Version 12.2.6a (Enterprise Plus)

• Mise en file d’attente à faible latence (LLQ) sur les circuits virtuels permanents (PVC) Frame Relay. Ceci est introduit dans le logiciel Cisco IOS Version 12.1.(2)T.

• Priorité RTP (Real-Time Transport Protocol) IP Frame Relay introduite dans le logiciel Cisco IOS Version 12.0(7)T.

• Frame Relay Forum (FRF).12 Fragmentation introduite dans le logiciel Cisco IOS Version 12.0(4)T.

• Les versions du logiciel Cisco IOS ultérieures à la version 12.0.5T contiennent des améliorations significatives des performances pour RTP compressé (cRTP).

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

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

Consignes de conception QoS pour VoIP sur Frame Relay

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 susmentionnées, utilisez les directives suivantes :

• Priorité stricte pour la priorité LLQ ou IP RTP du trafic vocal

• Formatage du trafic Frame Relay (FRTS) pour la voix

• Fragmentation FRF.12

• Réduction de la bande passante

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

Il existe deux méthodes principales pour fournir une priorité stricte au trafic vocal :

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

• LLQ (également appelée PQ / Class Based Weighted Fair Queuing (PQ/CBWFQ))

Priorité RTP IP

La priorité RTP IP Frame Relay crée une file d’attente de priorité stricte sur un circuit virtuel permanent Frame Relay pour un ensemble de flux de paquets RTP qui appartiennent à 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 le PQ strict. Lorsque le PQ est vide, les autres files d'attente sont traitées en fonction de la WFQ standard. 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 de découper le PQ lorsqu'il y a de la bande passante disponible sur la file d'attente par défaut (WFQ). Cependant, il applique strictement le contenu PQ en cas d'encombrement sur l'interface.

LLQ

LLQ est une fonctionnalité qui fournit un PQ strict à CBWFQ. 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é à l'ancienne fonction de groupe prioritaire de Cisco, qui consiste à affamer les pQ inférieurs.

Remarque : avec LLQ pour Frame Relay, les files d'attente sont configurées par circuit virtuel permanent. Chaque circuit virtuel permanent possède un PQ et un nombre attribué de files d’attente régulières.

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 dans votre réseau réel et vos besoins.

Priorité LLQ / IP RTP

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

FRTS pour voix

FRTS fournit des paramètres utiles pour gérer l'encombrement du trafic réseau. Le système FRTS élimine les goulots d’étranglement dans les réseaux Frame Relay grâce à des connexions à haut débit vers le site central et à des connexions à bas débit vers les sites des filiales. Vous pouvez configurer des valeurs d'application de débit pour limiter le débit auquel les données sont envoyées à partir du circuit virtuel (VC) sur le site central.

Ces définitions sont liées au FRTS :

• Débit d’informations garanti (CIR) : débit (bits par seconde) garanti par le fournisseur de relais de trames pour le transfert de données. Les valeurs CIR sont définies par le fournisseur de services Frame Relay et configurées par l’utilisateur sur le routeur.

  Remarque : le débit d'accès au port/à l'interface peut être supérieur au débit de données garanti. Le taux est calculé en moyenne sur une période de temps d'intervalle de mesure du taux engagé (Tc).

• Committed Burst (Bc) : nombre maximal de bits que le réseau Frame Relay s’engage à transférer sur un Tc. Tc = Bc / CIR.

• Excess Burst (Be) : nombre maximal de bits non validés que le commutateur Frame Relay tente de transférer au-delà du débit de données garanti (CIR) sur le Tc.

• Committed Rate Measurement Interval (Tc) : intervalle de temps au cours duquel les bits Bc ou Bc+ Be sont transmis. Tc est calculé comme Tc = Bc / CIR. La valeur Tc n'est pas directement configurée sur les routeurs Cisco. Il est calculé après la configuration des valeurs Bc et CIR. Tc ne peut pas dépasser 125 ms.

• BECN (Explicit Congestion Notification) : bit de l’en-tête de trame Frame Relay qui indique un encombrement dans le réseau. Lorsqu’un commutateur Frame Relay reconnaît l’encombrement, il définit le bit BECN sur les trames destinées au routeur source et demande au routeur de réduire le débit de transmission.

La configuration du FRTS pour le trafic vocal est différente de celle du formatage du trafic pour les données uniquement. Lors de la configuration de FRTS pour la qualité de la voix, des compromis sont faits avec les paramètres de trafic de données. Pour plus d'informations sur ces restrictions, reportez-vous à la section Fragmentation (FRF.12) de ce document.

Fragmentation (FRF.12)

L'intégration des données vocales pose un grand défi : contrôler le délai maximal d'un bout à l'autre du trafic sensible au temps, tel que la voix. Pour une bonne qualité vocale, ce délai doit être inférieur à 150 ms. Une partie importante de ce délai est le délai de sérialisation sur l'interface. Cisco recommande que ce délai soit de 10 ms et ne dépasse pas 20 ms. Le délai de sérialisation est le temps nécessaire pour placer les bits sur une interface.

Serialization Delay = frame size (bits) / link bandwidth (bps)

Par exemple, un paquet de 1 500 octets prend 214 ms pour laisser le routeur sur une liaison de 56 Kbits/s. Si un paquet de données non en temps réel de 1 500 octets est envoyé, les paquets de données en temps réel (voix) sont mis en file d'attente jusqu'à ce que le paquet de données volumineux soit transmis. Ce délai est inacceptable pour le trafic vocal. Si les paquets de données non en temps réel sont fragmentés en trames plus petites, ils sont entrelacés avec des trames en temps réel (voix). De cette manière, les trames voix et données peuvent être transportées ensemble sur des liaisons à faible vitesse sans provoquer un retard excessif sur le trafic vocal en temps réel.

Pour plus d'informations sur la fragmentation, référez-vous à Fragmentation Frame Relay pour la voix.

Remarque : Dans les cas où vous avez une connexion demi-T1 dédiée (768 kbits/s), vous n'avez probablement pas besoin d'une fonction de fragmentation. Cependant, vous avez toujours besoin d'un mécanisme QoS (priorité IP RTP ou LLQ, dans ce cas). Les demi-vitesses T1 ou supérieures offrent suffisamment de bande passante pour permettre aux paquets vocaux d'entrer dans la file d'attente et de la quitter dans la plage de délai de sérialisation recommandée (10 ms, au plus tard 20 ms). En outre, vous n'avez probablement pas besoin de cRTP, ce qui permet d'économiser de la bande passante en compressant des en-têtes RTP IP, dans le cas d'un T1 complet.

Réduction de la bande passante

cRTP

Basée sur RFC 2508 , la fonctionnalité cRTP compresse l'en-tête de paquet IP/UDP/RTP de 40 octets à 2 ou 4 octets. Cela réduit la consommation inutile de bande passante. Il s'agit d'un schéma 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.

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, car elle isole les problèmes potentiels liés au protocole cRTP.

Surveillez l'utilisation du processeur du routeur. Désactivez cRTP s'il dépasse 75 %. À des débits de liaison plus élevés, les économies de bande passante de cRTP peuvent être compensées par la charge CPU supplémentaire. 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.

Remarque : En l'absence de norme, cRTP pour Frame Relay a été développé sur l'encapsulation propriétaire Cisco. Par conséquent, il ne fonctionne pas avec l’encapsulation de Frame Relay par l’IETF (Internet Engineering Task Force). Récemment, FRF.20 a été finalisé pour rendre possible la compression d'en-tête RTP sur l'encapsulation IETF. Toutefois, à la dernière mise à jour de ce document (mai 2002), FRF.20 n'est pas pris en charge.

Pour plus d'informations, référez-vous à Protocole de transport en temps réel compressé .

Sélection du codeur/décodeur (codec)

Utilisez des codecs à faible débit sur les branches d'appel VoIP. G.729 (8 Kbits/s) est le codec par défaut du terminal de numérotation dial-peer VoIP.

Remarque : Bien que la multifréquence à deux tonalités (DTMF) soit généralement transportée avec précision lorsque des codecs vocaux à haut débit sont utilisés (G.711, par exemple), les codecs à faible débit (G.729 et G.723.1, par exemple) 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. Il transporte les tonalités DTMF hors bande ou séparément du flux vocal codé. Si vous utilisez des codecs à faible débit (G.729, G.723), activez la commande dtmf relay sous le terminal de numérotation dial-peer VoIP.

Activer la détection d'activité vocale (VAD)

Une conversation type peut contenir entre 35 et 50 % de silence. Les paquets silencieux sont supprimés lorsque VAD est utilisé. 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.

Configuration

Cette section vous fournit des informations pour configurer les fonctionnalités décrites dans ce document.

Remarque : Pour en savoir plus sur les commandes utilisées dans le présent document, utilisez l’outil de recherche de commandes (clients inscrits seulement).

LLQ

Utilisez cette procédure pour configurer LLQ :

1. Créez une carte de classe pour le trafic VoIP et définissez 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 
   
   
   !--- Create the access-list to match the class-map access-group:
   
   
   maui-voip-sj(config)#access-list 102 permit udp any any range 16384 32767
   
   !--- The 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 sont également 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 the other non-voice traffic does not use 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, !--- mark incoming traffic by applying an inbound service policy on an !--- inbound interface. This procedure is out of the scope !--- of this document. 
   
   
   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 commandes access-group :

   • Avec le logiciel Cisco IOS Version 12.1.2.T et ultérieure, la fonctionnalité IP RTP Priority est mise en oeuvre pour LLQ. Cette fonctionnalité correspond au contenu de la classe de priorité qui examine les ports UDP configurés. Il est soumis à la limitation de desservir uniquement les ports même 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 appariés et marqués dans le routeur avant l'application de l'opération LLQ sortante :

     class-map voice 
        match ip precedence 5
     

     OU

     class-map voice
        match ip dscp ef
     

     Remarque : Dans le logiciel Cisco IOS Version 12.2.2T et ultérieure, 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 des paquets VoIP par le biais de valeurs de code DSCP pour LLQ. Pour plus d'informations, référez-vous à Classification de la signalisation VoIP et des supports avec DSCP pour QoS.

     Router(config-dial-peer)#ip qos dscp ?
     

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

   Utilisez ces commandes pour 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 du protocole H.323, SIP (Session Initiation Protocol), MGCP (Media Gateway Control Protocol) ou SCCP (Skinny Call Control Protocol) - protocole propriétaire utilisé par Cisco Call Manager. L'exemple précédent suppose H.323 Fast Connect. Cette liste sert de référence pour les ports utilisés par les canaux de signalisation et de 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 = UDP 1718 (To GateKeeper)

   • SCCP = 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éez une carte de stratégie et associez-la 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. Utilisez ces commandes pour 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 PQ !--- (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 WFQ.
   
   

   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)). 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 à minCIR pour le circuit virtuel permanent. Sinon, la commande service-policy ne peut pas être affectée à la liaison. minCIR est la moitié du CIR par défaut. Pour afficher les messages d'erreur, assurez-vous que la commande logging console est activée pour l'accès à la console et que la commande terminal monitor est activée pour l'accès Telnet.

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

4. Activez LLQ en appliquant la carte de stratégie à l'interface WAN sortante.

   Utilisez ces commandes pour activer LLQ :

   maui-voip-sj(config)#map-class frame-relay VoIPovFR
   maui-voip-sj(config-if)#service-policy output VOICE-POLICY
   
   !--- The service-policy is applied to the PVC !--- indirectly by configuring !--- it under the map-class associated to the PVC.
   
   

Priorité RTP IP

Si vous n'utilisez pas LLQ, suivez les instructions suivantes :

Router(config-map-class)#frame-relay ip rtp priority starting-rtp-port  
port-range  bandwidth 

• start-rtp-port : numéro du port UDP de départ. Numéro de port le plus bas auquel les paquets sont envoyés. Pour VoIP, définissez cette valeur sur 16384.

• port-range : plage de ports de destination UDP. Le numéro, ajouté au port start-rtp, donne le numéro de port UDP le plus élevé. Pour VoIP, définissez cette valeur sur 16383.

• bandwidth : bande passante maximale autorisée en kbits/s pour la file d'attente prioritaire. Définissez ce nombre en fonction du nombre d'appels simultanés, en ajoutant la bande passante de chaque appel pris en charge par le système.

Exemple de configuration :

map-class frame-relay VoIPovFR  frame-relay cir 64000
 frame-relay BC 600
 no frame-relay adaptive-shaping
 frame-relay fair-queue
 frame-relay fragment 80
 frame-relay ip rtp priority 16384 16383 45

Formatage du trafic pour la voix

Utilisez ces instructions lorsque vous configurez le formatage du trafic pour la voix :

• Ne dépassez pas le débit de données garanti du circuit virtuel permanent.

• Désactivez le formatage adaptatif Frame Relay.

• Définissez la valeur Bc basse de sorte que Tc (intervalle de mise en forme) soit de 10 ms (Tc = Bc/CIR). Configurez la valeur Bc pour forcer la valeur Tc souhaitée.

• Définissez la valeur Be sur 0.

Pour plus d'informations sur ces directives, référez-vous à Formatage du trafic Frame Relay pour VoIP et VoFR.

Remarque : certains clients utilisent des circuits virtuels permanents distincts pour les données et la voix. Si vous avez deux circuits virtuels permanents distincts et que vous souhaitez découper dans le circuit virtuel permanent de données pendant que vous restez au débit de données garanti (CIR) ou en dessous pour le circuit virtuel permanent vocal, la qualité de la voix souffre toujours, car ces circuits virtuels permanents utilisent la même interface physique. Dans de tels cas, le fournisseur de relais de trames, ainsi que le routeur, doivent donner la priorité au circuit virtuel permanent vocal. Cette dernière opération peut être effectuée par PIPQ (PVC Interface Priority Queueing) disponible à partir de la version 12.1(1)T du logiciel Cisco IOS.

Fragmentation (FRF.12)

Activez la fragmentation pour les liaisons à faible vitesse (moins de 768 kbits/s). Définissez la taille du fragment de sorte que les paquets vocaux ne soient pas fragmentés et ne subissent pas de délai de sérialisation supérieur à 20 ms. Définissez la taille de fragmentation en fonction de la vitesse de port la plus basse entre les routeurs. Par exemple, s’il existe une topologie de relais de trames en étoile où le concentrateur a une vitesse T1 et que les routeurs distants ont des vitesses de port de 64 K, la taille de fragmentation doit être définie pour la vitesse de 64 K sur les deux routeurs. Tout autre circuit virtuel permanent qui partage la même interface physique doit configurer la fragmentation à la taille utilisée par le circuit virtuel permanent vocal. Utilisez ce graphique pour déterminer les valeurs de taille de fragmentation.

Exemple de configuration :

map-class frame-relay VoIPovFR 

!--- Some output is omitted.

 frame-relay fragment 80

Remarque : Pour 1 536 Kbits/s, aucune fragmentation n'est techniquement nécessaire. Cependant, la fragmentation est nécessaire pour permettre au système de mise en file d’attente FIFO double d’assurer la qualité de la voix. Une taille de fragment de 1600 octets active la double FIFO. Cependant, comme 1 600 octets sont supérieurs à l’unité de transmission maximale (MTU) de l’interface série classique, les paquets de données volumineux ne sont pas fragmentés.

Diagramme du réseau

Ce document utilise la configuration réseau indiquée dans le diagramme suivant :

Configurations

Ce document utilise les configurations indiquées ici:

• maui-voip-sj (Cisco 3640)

• maui-voip-austin (Cisco 3640)

version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname maui-voip-sj
!
logging buffered 10000 debugging
enable secret 5 $1$MYS3$TZ6bwrhWB25b2cVpEVgBo1
!
ip subnet-zero
!

!--- 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 PQ !--- is assigned to the voice-traffic class !--- with a maximum bandwidth of 45 Kbps.
 

policy-map VOICE-POLICY
  class voice-traffic
  priority 45
  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. Instead, it is 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.

!
interface Ethernet0/0
  ip address 172.22.113.3 255.255.255.0
  half-duplex
!
interface Serial0/0
 bandwidth 128
 no ip address
 encapsulation frame-relay
 no fair-queue
frame-relay traffic-shaping
 frame-relay ip rtp header-compression

!--- Turns on traffic shaping and cRTP. If traffic-shaping is not !--- enabled, then map-class does not start and FRF.12 and LLQ does !--- not work.

!
interface Serial0/0.1 point-to-point
 bandwidth 128
 ip address 192.168.10.2 255.255.255.252
 frame-relay interface-dlci 300
  class VOIPovFR

!--- This command links the subinterface to a VoIPovFR map-class. !--- See the map-class frame-relay VoIPovFR command here: !--- Note: The word VoIPovFR is selected by the user. !

ip classless
ip route 172.22.112.0 255.255.255.0 192.168.10.1
!
map-class frame-relay VOIPovFR
 no frame-relay adaptive-shaping

!--- Disable Frame Relay BECNS. Note also that Be equals 0 by default.

frame-relay cir 64000
 frame-relay bc 640

!--- Tc = BC/CIR. In this case Tc is forced to its minimal !--- configurable value of 10 ms.

frame-relay be 0
 frame-relay mincir 64000

!--- Although adaptive shaping is disabled, make CIR equal minCIR !--- as a double safety. By default minCIR is half of CIR.

service-policy output VOICE-POLICY

!--- Enables LLQ on the PVC.

frame-relay fragment 80

!--- Turns on FRF.12 fragmentation and sets the fragment size equal to 80 bytes. !--- This value is based on the port speed of the slowest path link. !--- This command also enables dual-FIFO.

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

!--- 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 matches VoIP signaling protocol. In this !--- case, H.323 V2 is uesd with the fast start feature.

!
voice-port 1/0/0
!
dial-peer voice 1 pots
 destination-pattern 5000
 port 1/0/0
!
dial-peer voice 2 voip
 destination-pattern 6000
 session target ipv4:192.168.10.1
 dtmf-relay cisco-rtp
 ip precedence 5

version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname maui-voip-austin
!
boot system flash slot1:c3640-is-mz.122-6a.bin
logging buffered 1000000 debugging
!
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 45
  class class-default
   fair-queue
!
interface Ethernet0/0
 ip address 172.22.112.3 255.255.255.0
 no keepalive
 half-duplex
!
interface Serial0/0
 bandwidth 64
 no ip address
 encapsulation frame-relay
 no ip mroute-cache 
 no fair-queue
 frame-relay traffic-shaping
 frame-relay ip rtp header-compression
!
interface Serial0/0.1 point-to-point
 bandwidth 64
 ip address 192.168.10.1 255.255.255.252
 frame-relay interface-dlci 400
  class VOIPovFR
!
ip classless
ip route 172.22.113.0 255.255.255.0 192.168.10.2
!
map-class frame-relay VOIPovFR
no frame-relay adaptive-shaping
 frame-relay cir 64000
 frame-relay bc 640
 frame-relay be 0
 frame-relay mincir 64000
 service-policy output voice-policy
 frame-relay fragment 80
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
!
dial-peer voice 1 pots
 destination-pattern 6000
 port 1/0/0
!
dial-peer voice 2 voip
 destination-pattern 5000
 session target ipv4:192.168.10.2
 dtmf-relay cisco-rtp
 ip precedence 5

Vérifiez et dépannez

Cette section fournit les informations pour confirmer que votre configuration fonctionne correctement.

Certaines commandes show sont prises en charge par l'outil Output Interpreter Tool (clients enregistrés seulement). Ceci vous permet d'afficher une analyse de la sortie de la commande show.

Commandes LLQ / IP RTP Priority

Ces commandes show et debug vous aident à vérifier vos configurations de priorité LLQ et IP RTP.

• show policy-map interface serial interface# - Cette commande est utile pour afficher l'opération LLQ et les pertes éventuelles 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 —Affiche des informations sur la configuration policy-map.

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

• debug priority : affiche les événements PQ et indique si la suppression a lieu dans cette file d'attente. Pour plus d'informations, référez-vous à Dépannage des pertes de sortie avec mise en file d'attente prioritaire.

• show class-map class_name —Affiche des informations sur la configuration class-map.

• show call active voice : recherche les paquets perdus au niveau du DSP.

• show frame-relay ip rtp header-compression - Affiche les statistiques de compression d'en-tête RTP.

Commandes de fragmentation

Utilisez ces commandes debug et show pour vérifier et dépanner les configurations de fragmentation.

• show frame-relay fragment : affiche des informations sur la fragmentation Frame Relay qui se produit dans le routeur Cisco.

• debug frame-relay fragment : affiche les messages d'événement ou d'erreur liés à la fragmentation Frame Relay. Elle est activée uniquement au niveau du circuit virtuel permanent sur l'interface sélectionnée.

Commandes Frame Relay / Interface

Utilisez ces commandes show pour vérifier et dépanner les configurations Frame Relay/Interface.

• show traffic-shape queue interface - Affiche des informations sur les éléments mis en file d'attente au niveau de l'identificateur de connexion de liaison de données (DLCI) du circuit virtuel. Utilisé pour vérifier le fonctionnement de la priorité IP RTP sur Frame Relay. Lorsque la liaison est encombrée, les flux vocaux sont identifiés avec un poids égal à zéro. Cela indique que le flux vocal utilise le PQ. Voir l'exemple de résultat ici.

• show traffic-shape - Affiche des informations telles que les valeurs configurées Tc, Bc, Be et CIR. Voir l'exemple de sortie.

• show frame-relay pvc dlci-# - Affiche des informations telles que les paramètres de formatage du trafic, les valeurs de fragmentation et les paquets abandonnés. Voir l'exemple de sortie. Référez-vous également à Dépannage de Frame Relay.

Problèmes identifiés

Un bogue a été identifié avec chaque VC LLQ où le PQ était strictement contrôlé même en l'absence de congestion sur l'interface. Ce bogue a été corrigé et maintenant les paquets vocaux non conformes ne sont abandonnés que si la congestion se produit sur le circuit virtuel. Cela rend le comportement de la LLQ par VC identique à celui des autres interfaces qui utilisent la LLQ. Ce comportement a été modifié avec le logiciel Cisco IOS Version 12.2(3) et ultérieure.

Exemple de sortie de commande show et debug

Voici un exemple de sortie de commande show et debug utilisé pour la vérification et le dépannage.

!--- To capture sections of this output, the LLQ PQ bandwidth !--- is lowered and large data traffic is placed !--- on the link to force packets drops. !--- Priority queue bandwidth is lowered to 10 Kbps to force drops from the PQ. !--- Note: To reset counters, use the clear counters command. 


maui-voip-sj#show policy-map inter ser 0/0.1
  Serial0/0.1: DLCI 300 -

  Service-policy output: VOICE-POLICY

Class-map: voice-traffic (match-all)
         26831 packets, 1737712 bytes
         5 minute offered rate 3000 bps, drop rate 2000 bps
         Match: access-group 102
         Weighted Fair Queueing
         Strict Priority
         Output Queue: Conversation 24
         Bandwidth 10 (kbps) Burst 250 (Bytes)
         (pkts matched/bytes matched) 26311/1704020
         (total drops/bytes drops) 439/28964

   Class-map: voice-signaling (match-all)
         80 packets, 6239 bytes
         5 minute offered rate 0 bps, drop rate 0 bps
         Match: access-group 103
         Weighted Fair Queueing
         Output Queue: Conversation 25
         Bandwidth 8 (kbps) Max Threshold 64 (packets)
         (pkts matched/bytes matched) 62/4897
         (depth/total drops/no-buffer drops) 0/0/0
    
   Class-map: class-default (match-any)
         14633 packets, 6174492 bytes
         5 minute offered rate 10000 bps, drop rate 0 bps
         Match: any
         Weighted Fair Queueing
         Flow Based Fair Queueing
         Maximum Number of Hashed Queues 16
         (total queued/total drops/no-buffer drops) 0/0/0

      

!--- These commands are useful to verify the LLQ 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 45 (kbps) Burst 1125 (Bytes)
   Class class-default
        Weighted Fair Queueing
           Flow based Fair Queueing Max Threshold 64 (packets)

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


!--- Frame Relay verification command output.


maui-voip-sj#show frame-relay fragment
interface         dlci  frag-type    frag-size  in-frag    out-frag   dropped-frag
Serial0/0.1       300   end-to-end      80         4          4          0

maui-voip-sj#show frame-relay pvc 300

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

DLCI = 300, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1

 input pkts 7 output pkts 7 in bytes 926
         out bytes 918 dropped pkts 0 in FECN pkts 0
         in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
         in DE pkts 0 out DE pkts 0
         out bcast pkts 2 out bcast bytes 598
         pvc create time 1w2d, last time pvc status changed 1w2d
      service policy VOICE-POLICY

 Service-policy output: VOICE-POLICY

 Class-map: voice-traffic (match-all)
         0 packets, 0 bytes
         5 minute offered rate 0 bps, drop rate 0 bps
      Match: access-group 102
         Weighted Fair Queueing
      Strict Priority
         Output Queue: Conversation 24
         Bandwidth 45 (kbps) Burst 250 (Bytes)
         (pkts matched/bytes matched) 0/0
         (total drops/bytes drops) 0/0

 Class-map: voice-signaling (match-all)
         0 packets, 0 bytes
         5 minute offered rate 0 bps, drop rate 0 bps
         Match: access-group 103
         Weighted Fair Queueing
         Output Queue: Conversation 25
         Bandwidth 8 (kbps) Max Threshold 64 (packets)
         (pkts matched/bytes matched) 0/0
         (depth/total drops/no-buffer drops) 0/0/0

 Class-map: class-default (match-any)
         7 packets, 918 bytes
         5 minute offered rate 0 bps, drop rate 0 bps
         Match: any
         Weighted Fair Queueing
         Flow Based Fair Queueing
         Maximum Number of Hashed Queues 16
         (total queued/total drops/no-buffer drops) 0/0/0


 Output queue size 0/max total 600/drops 0
 fragment type end-to-end fragment size 80
 cir 64000 bc 640 be 0 limit 80 interval 10
 mincir 64000 byte increment 80 BECN response no
 frags 13 bytes 962 frags delayed 8 bytes delayed 642
 
 shaping inactive
 traffic shaping drops 0


!--- In this Frame Relay verification command !--- output, the PQ bandwidth is lowered and heavy traffic !--- is placed on the interface to force drops. 

maui-voip-sj#show frame-relay pvc 300

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

DLCI = 300, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial0/0.1

 input pkts 483 output pkts 445 in bytes 122731
         out bytes 136833 dropped pkts 0 in FECN pkts 0
         in BECN pkts 0 out FECN pkts 0 out BECN pkts 0
         in DE pkts 0 out DE pkts 0
         out bcast pkts 4 out bcast bytes 1196
         pvc create time 1w2d, last time pvc status changed 1w2d
         service policy VOICE-POLICY

 Service-policy output: VOICE-POLICY

 Class-map: voice-traffic (match-all)
         352 packets, 22900 bytes
         5 minute offered rate 2000 bps, drop rate 2000 bps
         Match: access-group 102
         Weighted Fair Queueing
         Strict Priority
         Output Queue: Conversation 24
         Bandwidth 10 (kbps) Burst 250 (Bytes)
         (pkts matched/bytes matched) 352/22900
         (total drops/bytes drops) 169/11188

 Class-map: voice-signaling (match-all)
         7 packets, 789 bytes
         5 minute offered rate 0 bps, drop rate 0 bps
         Match: access-group 103
         Weighted Fair Queueing
         Output Queue: Conversation 25
         Bandwidth 8 (kbps) Max Threshold 64 (packets)
         (pkts matched/bytes matched) 7/789
         (depth/total drops/no-buffer drops) 0/0/0

 Class-map: class-default (match-any)
         79 packets, 102996 bytes
         5 minute offered rate 4000 bps, drop rate 0 bps
         Match: any
         Weighted Fair Queueing
         Flow Based Fair Queueing
         Maximum Number of Hashed Queues 16
         (total queued/total drops/no-buffer drops) 5/0/0
         Output queue size 5/max total 600/drops 169
         fragment type end-to-end fragment size 80
         cir 64000 bc 640 be 0 limit 80 interval 10
         mincir 64000 byte increment 80 BECN response no
         frags 2158 bytes 178145 frags delayed 1968 bytes delayed 166021

 shaping active
         traffic shaping drops 169


!--- Notice that the Tc interval equals 10 ms, !--- CIR equals 64000 BPS, and BC equals 640. 

     
maui-voip-sj#show traffic-shape
Interface  Se0/0.1
       Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
300           64000     80     640       0          10        80         -



!--- This output is captured on an isolated lab enviroment where !--- the routers are configured with IP RTP Priority instead of LLQ.
 

maui-voip-austin#show frame-relay PVC 100

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

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

  input pkts 336           output pkts 474          in bytes 61713
  out bytes 78960          dropped pkts 0           in FECN pkts 0
  in BECN pkts 0           out FECN pkts 0          out BECN pkts 0
  in DE pkts 0             out DE pkts 0
  out bcast pkts 0         out bcast bytes 0         
  PVC create time 1w0d, last time PVC status changed 1w0d
 Current fair queue configuration:   
   Discard      Dynamic       Reserved
   threshold    queue count   queue count
   64            16              2
 Output queue size 0/max total 600/drops 0 
  fragment type end-to-end        fragment size 80
  cir 64000     BC   640      be 0     limit 125    interval 10
  mincir 32000    byte increment 125   BECN response no
  frags 1091      bytes 82880     frags delayed 671      bytes delayed 56000
  shaping inactive
  traffic shaping drops 0
  ip rtp priority parameters 16384 32767 45000


!--- This command displays information of the VoIP dial-peers.
 
      
maui-voip-austin#show dial-peer voice 2
VoiceOverIpPeer2
        information type = voice,
        tag = 2, destination-pattern = `5000',
        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-target = `ipv4:192.168.10.2',  
        technology prefix:
     ip precedence = 5, UDP checksum = disabled,
         session-protocol = cisco, req-qos = best-effort, 
         acc-qos = best-effort, 
     dtmf-relay = cisco-rtp, 
        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 = 165830, Charged Units = 0,
        Successful Calls = 30, Failed Calls = 0,
        Accepted Calls = 30, Refused Calls = 0,
        Last Disconnect Cause is "10",
        Last Disconnect Text is "normal call clearing.",
        Last Setup Time = 69134010.

Informations connexes

• Mise en file d’attente à faible latence pour Frame Relay
• Classification de la signalisation VoIP et des supports avec DSCP pour QoS
• Commandes show pour le formatage du trafic Frame Relay
• Priorité RTP IP Frame Relay
• Configuration du formatage du trafic Frame Relay et Frame Relay
• Configuration et dépannage de Frame Relay
• Amélioration de la mise en file d'attente Voice over Frame Relay
• 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