Voix : Qualité vocale

VoIP sur liaisons PPP avec qualité de service (LLQ / IP RTP Priority, LFI, cRTP)

17 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


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 cela dans la configuration ci-dessous, les deux Routeurs sont dos à dos connecté au-dessus d'une ligne louée. Dans la plupart des topologies, cependant, les routeurs activés de Voix peuvent exister n'importe où. Habituellement, les Routeurs de Voix utilisent la Connectivité de RÉSEAU LOCAL à d'autres Routeurs qui sont connectés au WAN (en d'autres termes, une ligne louée de PPP). C'est important parce que si vos Routeurs de Voix ne sont pas directement connectés par l'intermédiaire du PPP au-dessus d'une ligne louée, toutes les commandes de configuration BLÊMES doivent être configurées sur ces Routeurs connectés au WAN, et pas sur les Routeurs de Voix, suivant les indications des configurations ci-dessous.

Conditions préalables

Conditions requises

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

Composants utilisés

Les configurations présentées dans ce document ont été testées avec ce matériel :

  • Deux Cisco 3640s avec la version de logiciel 12.2.6a de Cisco IOSÝ (IP Plus)

  • L'IP RTP Priority a été introduit dans la Cisco IOS version 12.0(5)T.

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

  • LFI a été introduit dans la Cisco IOS version 11.3.

  • Les releases de Cisco IOS au delà de 12.0.5T contiennent des améliorations significatives des performances pour le cRTP.

Conventions

Pour plus d'informations sur les conventions de documents, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Directives de conception de QoS pour le VoIP au-dessus des liens de PPP

Cette section fournit des directives de conception pour configurer le VoIP au-dessus des lignes louées de PPP (avec l'accent mis sur des liaisons à bas débit). Il y a deux exigences de base pour la bonne qualité vocale :

Pour garantir les conditions requises ci-dessus, il y a plusieurs importantes instructions qui devraient être suivies :

Instruction Description
Priorité stricte pour le trafic vocal (IP RTP Priority ou LLQ) Méthode pour fournir la priorité stricte pour le trafic vocal.
Fonction Link Fragmentation and Interleaving (LFI) Peut être une condition obligatoire pour des liaisons à bas débit.
Compactage de RTP Non requis pour fournir la bonne qualité vocale, mais réduit la consommation de bande passante d'appel. Le conseil général concernant le compactage de RTP est de l'appliquer ayant ensuite une configuration en cours avec la bonne qualité vocale (simplifie le dépannage).
Contrôle d'admission d'appel (CAC) Non couvert dans ce document. Le CAC est utilisé pour contrôler le nombre d'appels qui peuvent être établis au-dessus du lien. Par exemple, si le lien WAN entre les deux passerelles a la bande passante pour porter seulement deux appels VoIP, l'admission d'un troisième appel peut altérer la Qualité vocale de chacun des trois appels. Le pour en savoir plus se rapportent : Contrôle d'admission d'appel VoIP.

Pour récapituler, parce que la liaison PPP à faible vitesse avec le routeur/passerelles en tant que seulement sources de trafic vocal deux caractéristiques sont obligatoire :

  1. Priorité stricte pour le trafic vocal

  2. Fonction Link Fragmentation and Interleaving (LFI)

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

En date du Logiciel Cisco IOS version 12.2, il y a deux méthodes primaires pour fournir la priorité stricte pour le trafic vocal :

  • IP RTP Priority (également appelé le PQ/WFQ : File d'attente prioritaire/mise en file d'attente pondérée)

  • Basse Mise en file d'attente de latence (également appelée le PQ/CBWFQ : File d'attente prioritaire/mise en file d'attente pondérée basée par classe).

IP RTP Priority

L'IP RTP Priority crée une file d'attente prioritaire stricte pour un ensemble d'écoulements de paquet de RTP appartenant à une plage des destinations port de Protocole UDP (User Datagram Protocol). Tandis que les ports réels utilisés sont dynamiquement négociés entre les fin-périphériques ou les passerelles, tous les produits VoIP de Cisco utilisent la même chaîne de port UDP (16384-32767). Une fois que le routeur identifie le trafic VoIP, il le place dans la file d'attente prioritaire stricte. Quand la file d'attente prioritaire est vide, les autres files d'attente sont traitées selon le Mise en file d'attente pondérée (WFQ) standard. L'IP RTP Priority ne devient pas actif jusqu'à ce qu'il y ait d'encombrement dans l'interface. Cette image illustre le fonctionnement de la priorité IP RTP :

pq-wfq.gif

Remarque: L'IP RTP Priority permet éclater la file d'attente prioritaire (PQ) quand il y a bande passante disponible sur la file d'attente par défaut (WFQ), mais maintient l'ordre strictement le contenu de file d'attente prioritaire quand il y a d'encombrement sur l'interface.

Basse Mise en file d'attente de latence

LLQ est une caractéristique qui fournit un PQ strict à la mise en file d'attente pondérée basée sur classe (CBWFQ). LLQ active un PQ strict simple dans CBWFQ au niveau de classe. Avec LLQ, des données sensibles au délai (dans le PQ) sont retirées et envoyées de la file d'attente d'abord. Dans un VoIP avec l'implémentation LLQ, le trafic vocal est placé dans le PQ strict.

Le PQ est maintenu l'ordre pour s'assurer que les files d'attente équitables ne sont pas affamées de la bande passante. Quand vous configurez le PQ, vous spécifiez dans le Kbps la bande passante maximale disponible au PQ. Quand l'interface est congestionnée, le PQ est entretenu jusqu'à ce que le chargement atteigne la valeur configurée de Kbps dans la déclaration de priorité. Le trafic excédentaire est alors abandonné pour éviter le problème avec la configuration existante de la priority-group de Cisco de mourir de faim les files d'attente de faible priorité.

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

Cette méthode est plus complexe et flexible que l'IP RTP Priority. Le choix entre les méthodes devrait être basé sur les conformations du trafic dans votre réseau réel et vos besoins réels.

LLQ contre l'IP RTP Priority

Cette table récapitule les principales différences entre LLQ et IP RTP Priority et fournit quelques instructions de le moment où utiliser chaque méthode.

Fonction Low Latency Queuing (LLQ) IP RTP Priority
Le trafic vocal de correspondance basé en fonction :
  • Listes d'accès (pour la chaîne de port UDP, adresses de hôte, champs de tos d'en-tête IP : Priorité IP, DSCP, et plus)
  • Plage de port de RTP IP
  • Champs du tos IP (type de service) : DCSP et/ou Priorité IP
  • Protocoles et interfaces d'entrée
  • Tout le critère de correspondance valide utilisé dans CBWFQ
Avantages :
  • Plus de flexibilité sur la façon dont le trafic est apparié et dirigé vers le PQ et le CBWFQ stricts
  • Peut configurer les classes supplémentaires pour garantir la bande passante pour l'autre trafic comme : Signalisation et vidéo VoIP.
Inconvénients :
  • Configuration complexe
Le trafic vocal de correspondance basé en fonction :
  • Basé sur la chaîne de port UDP de RTP : 16384-32767
Avantages :
  • Configuration simple
Inconvénients :
  • Le trafic RTCP (signalisation VoIP) a servi dans la file d'attente WFQ

    Remarque: Le protocole de RTP emploie RTCP (Control Protocol en temps réel) pour contrôler la livraison des paquets de RTP. Tandis que les ports de RTP utilisent les chiffres pairs, les ports RTCP utilisent les nombres impairs de l'ordre de 16384-32767. L'IP RTP Priority place des ports de RTP dans le PQ, tandis que des ports RTCP sont servis dans la file d'attente par défaut de weighted fair.

  • Sert le trafic VoIP dans le PQ, mais n'importe quel autre trafic qui a besoin de la garantie de traitement préférentiel et de bande passante est servi dans WFQ. Tandis que WFQ peut différencier des écoulements avec des poids (basés sur la Priorité IP), il ne peut pas assurer la garantie de bande passante pour aucun écoulement.
Instructions
  • Le choix entre eux devrait être basé sur les conformations du trafic dans votre réseau réel et vos besoins réels.
  • Si vous devez fournir la priorité stricte à votre trafic vocal, et l'autre trafic peut être traité comme type simple (données), alors l'IP RTP Priority réalise un bon travail pour votre réseau avec une configuration simple.
  • Si vous prévoyez de donner la priorité au trafic vocal basé sur des critères autres que des 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, référez-vous à la vue d'ensemble de la gestion d'encombrement.

Instructions de configuration LLQ

Suivez ces instructions pour configurer LLQ :

  1. Créez un class map pour le trafic VoIP et définissez le critère de correspondance

    Ces commandes expliquent comment se terminer 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 apparier le trafic vocal avec l'ordre de 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. 
    
    

    Ce sont d'autres méthodes assorties qui peuvent être utilisées au lieu des access-group :

    • Commençant par la Cisco IOS version 12.1.2.T, la fonctionnalité d'IP RTP Priority est mise en application pour LLQ. Cette caractéristique apparie le contenu de classe prioritaire regardant les ports UDP configurés et est sujette à la limite de servir seulement les ports égaux dans le PQ.

      class-map voice 
        match ip rtp 16384 16383 
      
      
    • Ces deux méthodes fonctionnent dans la supposition que des paquets VoIP sont marqués aux hôtes de commencement, ou appariés et marqués dans le routeur avant d'appliquer l'exécution sortante LLQ.

      class-map voice 
        match ip precedence 5 
      

      ou

      class-map voice 
        match ip dscp ef 
      

      Remarque: Commençant par la release 12.2.2T IOS, les homologues de numérotation VoIP peuvent marquer le support et les paquets de signalisation de Voix avant l'exécution LLQ. Ceci permet une manière extensible des paquets de marquage et de apparier de VoIP par l'intermédiaire des éléments de code de DSCP pour LLQ.

  2. Créez un class map pour la signalisation VoIP et définissez le critère de correspondance (facultatif)

    Ces commandes expliquent comment se terminer 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: Des appels VoIP peuvent être établis utilisant H.323, SIP, MGCP ou maigre (protocole propriétaire utilisé par le Cisco Call manager). H.323 le rapide assumé par exemple ci-dessus se connectent. Cette liste sert de référence aux ports utilisés par la signalisation VoIP/canaux de contrôle :

    • H.323/H.225 = TCP 1720

    • H.323/H.245 = TCP 11xxx (la norme se connectent)

    • H.323/H.245 = TCP 1720 (rapide connectez)

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

    • Maigre = TCP 2000-2002 (bis cm)

    • ICCP = TCP 8001-8002 (bis cm)

    • MGCP = UDP 2427, TCP 2428 (bis cm)

    • UDP 5060 SIP=, TCP 5060 (configurable)

  3. Créez une carte de stratégie et associez-vous aux class-map VoIP

    Le but de la carte de stratégie est de définir comment les ressources en lien sont partagées ou assignées aux différentes classes de carte. Ces commandes expliquent comment se terminer 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 d'aligner de divers types de trafic en temps réel au PQ, Cisco recommande que vous dirigiez seulement le trafic vocal vers lui. Le trafic en temps réel, tel que le vidéo, pourrait introduire la variation du retard (le PQ est un FIFO - premier à système premier entré, premier sorti - file d'attente). Le trafic vocal exige que le retard soit nonvariable afin d'éviter le jitter.

    Remarque: La somme des valeurs pour la priorité et les instructions de bande passante doit être d'inférieur ou égal à 75 pour cent de la bande passante de lien. Autrement la service-stratégie ne peut pas être assignée au lien (pour voir les messages d'erreur, assurez-vous que le logging console est activé pour l'accès de console et le terminal monitor est activé pour l'accès de telnet).

    Remarque: En configurant le VoIP au-dessus de l'les 64 Kbits/s joignent pour prendre en charge deux communications voix, il est commun pour allouer plus de 75 pour cent (48Kbps) de la bande passante de lien au PQ. En pareil cas, vous pouvez employer le max-reserved-bandwidth 80 de commande pour soulever la bande passante disponible à 80 pour cent (51 Kbps).

    Pour plus d'informations sur les commandes de bande passante et prioritaires, référez-vous à comparer les commandes de bande passante et prioritaires d'une stratégie de service QoS.

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

    Ces commandes expliquent comment se terminer 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 d'IP RTP Priority

Pour configurer l'utilisation d'IP RTP Priority ces instructions :

  • Router(config-if)#ip rtp priority starting-rtp-port-#port-#-rangebandwidth
    
    
    Commande Description
    starting-rtp-port-number
    
    Limite inférieure de port UDP. Le plus bas numéro de port auquel les paquets sont envoyés. Pour le VoIP, placez cette valeur à 16384.
    port-number-range
    
    La plage des destinations port d'UDP. Un nombre, qui a ajouté au démarrer-rtp-port-nombre, rapporte le numéro de port UDP le plus élevé. Pour le VoIP, placez cette valeur à 16383 (32767 - 16384 = 16383)
    bandwidth
    
    Bande passante de maximum autorisé (Kbps) dans la file d'attente prioritaire. Placez ce nombre selon le nombre de simultané appelle les assistances techniques.

    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
    

Fonction Link Fragmentation and Interleaving (LFI) : Multilink PPP

Tandis que 1500 octets est une taille commune pour des paquets de données, un paquet typique VoIP (portant G.729 des trames voix) peut être environ 66 octets (charge utile voix de 20 octets, 6 en-tête d'octets layer-2, en-tête de 20 RTP d'octets et d'UDP, et 20 en-têtes IP d'octets).

Maintenant, imaginez une liaison dédiée 56Kbps où le trafic voix et de données coexistent. Si un paquet vocal est prêt à être sérialisé au moment même où un paquet de données commence l'transmission au-dessus du lien, alors il y a un problème. Le paquet vocal sensible au retard doit attendre 214 millisecondes avant d'être transmise (cela prend 214 millisecondes pour sérialiser un paquet de 1500 octets au-dessus d'un lien 56Kbps).

Comme vous pouvez voir, les grands paquets de données peuvent défavorablement retarder la livraison de petits paquets vocaux, réduisant la qualité de la parole. Fragmenter ces grands paquets de données dans les plus petits et intercaler des paquets vocaux parmi les fragments réduit le jitter et le retard. Les aides de caractéristique de Fonction Link Fragmentation and Interleaving (LFI) de Cisco IOS répondent aux exigences en temps réel de la livraison du VoIP. Cette image illustre l'exécution de LFI :

lfi.gif

Suivant les indications du tableau 1, la quantité de retard de fabrication en série (le temps où elle prend pour placer réellement les bits sur une interface) introduite sur les liens WAN à vitesse réduite peut être significative, considérant que le retard à sens unique de bout en bout de cible ne devrait pas dépasser 150ms. (Recommandation ITU-T G.114 spécifie 150 de bout en bout à sens unique maximum de ms.)

Retard de fabrication en série du tableau 1. pour différentes tailles de trame sur le retard de fabrication en série de liaisons à bas débit = la bande passante de taille de trame (bits) /link (bps)

1 octet 64 octets 128 octets 256 octets 512 octets 1024 octets 1500 bytes
56 Kbps 143 nous 9 ms 18 ms 36 ms 72 ms 144 ms 214 ms
64 Kbits/s 125 nous 8 ms 16 ms 32 ms 64 ms 126 ms 187 ms
128 Kbps 62.5 nous 4 ms 8 ms 16 ms 32 ms 64 ms 93 ms
256 Kbps 31 nous 2 ms 4 ms 8 ms 16 ms 32 ms 46 ms
512 Kbps 15.5 nous 1 ms 2 ms 4 ms 8 ms 16 ms 32 ms
768 Kbps 10 nous 640 nous 1.28 ms 2.56 ms 5.12 ms 10.24 ms 15 ms
1536 Kbps 5 nous 320 nous 640 nous 1.28 ms 2.56 ms 5.12 ms 7.5 ms

Remarque: Pour des Applications voix, le retard de sérialisation recommandé (par base de saut) est 10 ms et ne devrait pas dépasser 20 ms.

La taille de fragment de lien est configurable dans des mesures horaires de la milliseconde (milliseconde) avec le ppp multilink fragment delay de commande. LFI exige que le ppp multilink soit configuré sur l'interface avec le ppp multilink interleave activé. Pour plus d'informations sur configurer LFI, référez-vous à la section de ce document.

Remarque: Dans les cas où vous avez plus qu'une demi connexion dédiée de t1 (768 Kbps), vous n'avez pas besoin d'une fonctionnalité de fragmentation. (Vous, cependant, avez besoin toujours d'un mécanisme de QoS, tel que LLQ ou IP RTP Priority). Le demi t1 offre l'assez de bande passante pour permettre à des paquets vocaux pour écrire et laisser les questions de file d'attente sans tarder. En outre, vous ne pouvez pas avoir besoin du compactage pour Protocol en temps réel (cRTP), que les aides économisent la bande passante en compressant des en-têtes de RTP IP, dans le cas d'un demi t1.

Protocole CRTP (Compressed Real-Time Protocol)

Remarque: le cRTP n'est pas exigé pour assurer la bonne qualité vocale. C'est une caractéristique qui réduit la consommation de bande passante. Configurez le cRTP après tout que d'autres conditions sont remplies et la Qualité vocale est bonne. Cette procédure peut épargner le temps de panne en isolant les questions potentielles de cRTP.

Basé sur RFC 2508, la caractéristique de Compression d'en-tête RTP compresse l'en-tête IP/UDP/RTP de 40 octets à 2 ou 4 octets, réduisant la consommation de bande passante inutile. C'est un modèle de compression de saut par saut ; donc, le cRTP doit être configuré sur les deux fins du lien (à moins que l'option passive est configurée). Pour configurer le cRTP, utilisez cette commande au niveau d'interface :

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

Puisque le processus de compactage peut être CPU-intensif, la Compression d'en-tête RTP est mise en application dans la commutation rapide et les chemins de commutation de CEF pendant que la release 12.0.(7)T de l'IOS. Parfois ces réalisations sont cassées, et alors la seule manière que des travaux seront traités a commuté. Cisco recommande seulement utilisant le cRTP avec Kbps inférieur de liens des que 768, à moins que le routeur s'exécute à un bas débit d'utilisation du processeur. Surveillez l'utilisation du processeur du routeur et désactivez le cRTP s'il est au-dessus de 75 pour cent.

Remarque: Quand vous configurez l'ip rtp header-compression de commande, le routeur ajoute l'ip tcp header-compression de commande à la configuration par défaut. Ceci est utilisé pour compresser les paquets TCP/IP des en-têtes. La compression d'en-tête est particulièrement utile sur des réseaux avec un grand pourcentage de petits paquets, comme ceux qui prennent en charge beaucoup de connexions de telnet. La technique de Compression d'en-tête TCP, décrite amplement dans RFC 1144, est prise en charge sur des lignes série utilisant le HDLC ou l'encapsulation PPP.

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

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

Pour en savoir plus : Protocole de transport en temps réel comprimé

D'autres conseils de réduction de bande passante

  • Codeur de faible débit d'utilisation/décodeurs (codecs) sur les tronçons d'appel VoIP ; G.729 (8 Kbps) est recommandé. (C'est le codec par défaut sur les homologues de numérotation VoIP). Pour configurer différents codecs utilisez la commande de #codec de routeur (config-cadran-pair) sous le cadran-pair désiré de voip.

  • Bien que la double tonalité multifréquence (DTMF) soit habituellement transportée exactement en utilisant des codecs de Voix de haute-bit-débit tels que G.711, des codecs de faible débit (tels que G.729 et G.723.1) soient fortement optimisées pour des modèles de Voix et tendez à tordre des tonalités DTMF. Cette approche peut avoir comme conséquence les problèmes accédant à des systèmes de la réponse vocale interactive (RVI). La commande de relais de DTMF résout le problème de distorsion de DTMF en transportant DTMF modifie la tonalité « hors de la bande » ou séparé du flux voix encodé. Si des codecs de faible débit (G.729, G.723) sont utilisés, activez le relais de DTMF sous l'homologue de numérotation VoIP.

  • Une conversation typique peut contenir 35-50 pour cent de silence. Utilisant la détection d'activité vocale (VAD), des paquets de silence sont supprimés. Pour la planification de bande passante VoIP, supposez que VAD réduit la bande passante par 35 pour cent. VAD est configuré par défaut sous les homologues de numérotation VoIP. Pour activer ou désactiver VAD, utilisez le #vad de routeur (config-cadran-pair) et le routeur (config-cadran-pair) # aucune commandes de vad sous les cadran-pairs désirés de voip.

Diagramme du réseau

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

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

Vérification et commandes de dépannage

Avant de tenter toutes les commandes de débogage, référez-vous aux informations importantes sur des commandes de debug. Pour plus d'informations sur les commandes répertoriées ici, voir l'échantillon afficher et la section de sortie de débogage de ce document.

Commandes d'interface :

  • affichez l'interface [interface série | multilink] — utilisez cette commande de vérifier ce statut de l'interface série. Assurez-vous que l'interface série et l'interface multiliaison sont en hausse et ouvertes.

  • Dépannage des lignes série

Commandes LFI :

  • show ppp multilink — Cette commande affiche les informations d'ensemble pour les ensembles Multilink PPP.

  • fragments de multilink de debug ppp — Cette affiche des informations de commande de débogage au sujet de différents fragments de multilink et événements d'interfoliage. Cette sortie de commande identifie également le numéro de séquence du paquet et des tailles de fragment.

Commandes prioritaires de RTP LLQ/IP :

  • interface# de multilink de show policy-map interface — Cette commande est très utile pour voir l'exécution LLQ et pour voir toutes les baisses dans le PQ. Pour plus d'informations sur les divers champs de cette commande, référez-vous compréhension derrière des compteurs de paquet dans la sortie de show policy-map interface.

  • policy_map_name de show policy-map — Cette affiche des informations de commande au sujet de la configuration de la carte de stratégie.

  • interface-nombre d'interface-type de show queue — Listes de ces commandes configuration de mise en file d'attente équitable et statistiques pour une interface spécifique.

  • Debug priority — Cette commande de débogage affiche des événements de file d'attente à priorité déterminée et affiche si la baisse se produit dans cette file d'attente. Référez-vous également aux suppressions de sortie de dépannage avec la file d'attente à priorité déterminée.

  • class_name de show class-map — Cette affiche des informations de commande au sujet du configuration de class-map.

  • show call active voice — Cette commande est utile pour vérifier les paquets perdus au niveau DSP.

D'autres commandes/références :

Problèmes connus :

  • CSCds43465 : « LLQ, régulateur, modélisateur devrait prendre le feedback de compactage CRTP » pour visualiser des notes de mise à jour, se rapporte au Bug Toolkit (clients enregistrés seulement).

Instructions :

Voici quelques étapes de dépannage de base, une fois que le lien de ppp est en service (MLPPP, fragmentation, intercalant) :

  1. show call active voice — Utilisation de vérifier les paquets perdus au niveau DSP.

  2. interface d'exposition — Utilisation de vérifier les problèmes généraux de ligne série ou d'interface. Les baisses sur l'interface ne signifie pas un problème encore, mais il est préférable de relâcher la forme de paquet la file d'attente à basse priorité avant qu'il portée la file d'attente d'interface.

  3. show policy-map interface — Utilisation de vérifier les baisses et la configuration de mise en file d'attente LLQ. Ne devrait signaler aucune baisses qui violent la stratégie.

  4. show ip rtp header-compression — Utilisation de vérifier les problèmes de particularité de 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


Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Informations connexes


Document ID: 7111