VoIP sur relais de trames avec circuits virtuels permanents multipoints et hiérarchisation

Options de téléchargement

  • PDF     (252.8 KB)
    Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
  • ePub     (131.3 KB)
    Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
  • Mobi (Kindle)     (126.7 KB)
    Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils
Mis à jour:6 juillet 2007
ID du document:12162

Langage exempt de préjugés

Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.

À propos de cette traduction

Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.

Introduction

Ce document traite du formatage et de la hiérarchisation du trafic pour un réseau VoIP (Voice over IP) sur Frame Relay avec topologie en étoile et en étoile. La configuration du concentrateur est telle qu'il existe deux circuits virtuels permanents (PVC), un pour chaque rayon distant, et que les données et la voix sont envoyées sur les mêmes circuits virtuels permanents. Il est important de noter que la hiérarchisation et la fragmentation abordées dans ce document s'appliquent non seulement à ce scénario, mais également à un scénario où vous pouvez avoir un circuit virtuel permanent avec la voix et les données et un autre avec seulement les données. Les circuits virtuels permanents de données doivent être en forme de trafic, tout comme les circuits virtuels permanents de données et de voix. Ceci est dû au fait que lorsqu'un canal physique unique est partagé, dans ce cas au niveau du concentrateur, le délai de sérialisation affecte toutes les données.

Dans la topologie ci-dessous, New York représente le routeur central du concentrateur. Raleigh et San Jose représentent des routeurs distants connectés au concentrateur via un réseau Frame Relay. Deux circuits virtuels permanents se connectent au routeur New York. Dans ce cas, New York ne devrait jamais envoyer plus de 64 kbits/s à Raleigh et de même, elle ne devrait jamais envoyer plus de 192 kbits/s à San Jose, car cela dépasse le débit de données garanti (CIR) configuré sur la mapclass Frame Relay.

Dans la topologie illustrée dans ce document, les routeurs avec des configurations VoIP sont directement connectés à un nuage Frame Relay. Dans certaines topologies, cependant, les routeurs vocaux peuvent exister n'importe où sur le réseau, à l'exception du Cisco AS5300. Pour plus d'informations à ce sujet, reportez-vous à la note fournie. Les routeurs vocaux peuvent être connectés via une connectivité LAN à d'autres routeurs connectés au WAN. Il est important de le noter car si vos routeurs vocaux ne sont pas directement connectés à un service Frame Relay, toutes les commandes de configuration de connectivité WAN sont configurées sur les routeurs connectés au WAN et non sur les routeurs vocaux.

Remarque : les routeurs Cisco AS5300 avec interfaces série haut débit ne sont pas conçus pour prendre en charge la connexion de données à un WAN. Vous devez utiliser vos AS5300 Cisco comme routeurs LAN intermédiaires avec la fonctionnalité principale pour traiter les appels vocaux. Vous avez besoin de routeurs dédiés pour agir en tant que connexions directes au WAN.

Conditions préalables

Conditions requises

Avant de tenter cette configuration, assurez-vous de respecter les conditions requises suivantes :

Components Used

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

  • Trois routeurs Cisco 3640 avec le logiciel Cisco IOS® version 12.3(5) Enterprise Plus

  • Quatre téléphones analogiques connectés à des ports FXS (Foreign Exchange Station) sur des rayons

  • Un PBX connecté à un contrôleur T1 sur le routeur concentrateur

Les rayons peuvent également être une plate-forme Cisco 2600 ou 1750. Le concentrateur peut être une plate-forme Cisco 2600 ou 3600 dans le cas de la voix numérique, mais il peut également être une plate-forme Cisco 1750 si seule la voix analogique existe au niveau du concentrateur. Toutes les configurations et le formatage du trafic s'appliquent également à d'autres plates-formes.

Remarque : Bien que ce document ne se limite pas à des logiciels spécifiques, certaines des commandes utilisées ici ne sont pas disponibles avec toutes les versions du logiciel Cisco IOS. Par exemple, la commande frame-relay fragment est prise en charge avec IP Plus mais pas par une image IP.

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

Pour plus d'informations sur les conventions utilisées dans ce document, reportez-vous à Conventions relatives aux conseils techniques Cisco.

Configuration du formatage et de la hiérarchisation du trafic pour une VoIP sur Frame Relay

Lorsque vous exécutez la VoIP sur Frame Relay, il est important que le trafic envoyé sur la trame reste à un niveau inférieur ou égal au CIR Frame Relay. Le routeur n’envoie pas de trafic qui dépasse le débit de données garanti lorsqu’il est configuré avec le formatage du trafic Frame Relay (FRTS), comme indiqué. Si vous configurez le routeur pour qu'il fonctionne à une vitesse supérieure à celle du débit de données garanti , vous risquez de rencontrer des problèmes de qualité vocale et la qualité vocale n'est pas garantie lorsque vous exécutez des circuits virtuels permanents au-dessus du débit de données garanti.

Remarque : Il est possible de configurer le formatage adaptatif pour permettre à un routeur de réduire le débit de transmission à une valeur spécifiée si des paquets Frame Relay sont reçus avec le bit BECN (backward Explicit Congestion Notification). Cependant, vous êtes informé que les débits de trafic ne doivent pas dépasser le débit de données garanti du service Frame Relay lors de la transmission de paquets vocaux. Cela permet d'assurer une qualité et une livraison adéquates lorsque des paquets vocaux en temps réel sont envoyés sur le réseau. La configuration dans laquelle le débit de données garanti est dépassé n'est recommandée que pour les circuits virtuels permanents de données qui ne transportent pas de trafic vocal.

Remarque : Avant de configurer votre routeur pour qu'il utilise la VoIP, il est préférable de comprendre les fonctionnalités de qualité de service (QoS) du logiciel Cisco IOS. Pour en savoir plus sur les fonctionnalités QoS, référez-vous à Mise en file d'attente, Formatage du trafic, Filtrage et Fragmentation pour la voix.

Remarque : Utilisez l’outil de recherche de commandes (clients inscrits seulement) pour en savoir plus sur les commandes figurant dans le présent document.

Diagramme du réseau

Ce document utilise la configuration réseau présentée dans le schéma ci-dessous :

voip_fr_mp_1.gif

Configurations

Ce document utilise les configurations suivantes :

Routeur du concentrateur de New York 
Current configuration:
!
version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname newyork
!
logging buffered 50000 debugging
enable secret < password > [Choose a strong password with 
at least one capital letter, one number, and one special character.]
!
controller T1 2/0
framing esf
linecode b8zs
ds0-group 1 timeslots 1-4 type e&m-wink-start
!
!
interface Serial2/0
 no ip address
 encapsulation frame-relay
 no ip mroute-cache
 frame-relay traffic-shaping

!--- This CLI command enables traffic shaping for both PVCs.

!
interface Serial2/0.1 point-to-point
description Connection to Raleigh PVC
ip address 172.16.120.2 255.255.255.0
  frame-relay interface-dlci 100
  class class-raleigh
!
interface Serial2/0.2 point-to-point
description Connection to San Jose PVC
ip address 172.16.130.2 255.255.255.0
frame-relay interface-dlci 200
  class class-sanjose
!
ip classless
!
map-class frame-relay class-raleigh
 frame-relay cir 64000
 frame-relay bc 640
 frame-relay be 0
 frame-relay mincir 64000
 no frame-relay adaptive-shaping
 frame-relay fair-queue
 frame-relay fragment 80

!--- Recommended fragment size for 10ms delay when carrying voice !--- traffic based on the configured CIR 64000. !--- based on the configured CIR 64000 
 frame-relay ip rtp priority 16384 16383 48

!--- Two calls with g729, no CRTP, at 24 kbps/each. 
 !
map-class frame-relay class-sanjose
 frame-relay cir 192000
 frame-relay bc 1920
 frame-relay be 0
 frame-relay mincir 192000
 no frame-relay adaptive-shaping
 frame-relay fair-queue
 frame-relay fragment 240

!--- This is the recommended fragment size for 10ms delay when carrying voice traffic !--- based on the configured CIR 192000.

frame-relay ip rtp priority 16384 16383 48 

!--- Two calls with G729, no Compressed Real Time Protocol (cRTP), at 24kbpseach. 
!
!
voice-port 2/0:1
!
dial-peer cor custom
!
dial-peer voice 100 pots

!--- Calls to the Public Switched Telephone Network (PSTN). 
 destination-pattern 212.......
prefix 212
port 2/0:1
!
dial-peer voice 200 pots

!--- Calls to the corporate network-four digit extension forwarded. 
destination-pattern 567....
 port 2/0:1
!
dial-peer voice 110 voip

!--- Calls to Raleigh.

destination-pattern 919392....
session target ipv4:172.16.120.1
 ip qos dscp cs5 media
dtmf-relay h245-alphanumeric
!
dial-peer voice 210 voip    
!--- Calls to San Jose. 
destination-pattern 408527....
session target ipv4:172.16.130.1
 ip qos dscp cs5 media
dtmf-relay h245-alphanumeric
!
!
line con 0
 exec-timeout 0 0
 transport input none
line aux 0
line vty 0 4
 no login
!
end

La commande ip qos dscp a été introduite dans IOS version12.2(2)T pour remplacer la commande ip priority (dial-peer).

La commande frame-relay ip rtp priority réserve une file d'attente de priorité stricte pour un ensemble de flux de paquets RTP (Real-Time Protocol) qui appartient à une plage de ports de destination UDP (User Datagram Protocol).

Remarque : Étant donné que la commande frame-relay ip rtp priority donne la priorité absolue aux autres trafics, utilisez cette commande avec soin. En cas d'encombrement, si le trafic dépasse la bande passante configurée, tout le trafic excédentaire est abandonné.

Cisco 3640 Raleigh 
Current configuration:
!
version 12.2
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname raleigh3640a
!

logging buffered 50000 debugging
enable secret < password > [Choose a strong password with at 
least one capital letter, one number, and one special character.]
!
no ip subnet-zero
!
!
!
!
voice-port 1/0/0
!
voice-port 1/0/1
dial-peer voice 1 pots
 destination-pattern 9193924100
port 1/0/0
!
dial-peer voice 2 voip
 destination-pattern 2126789001
  ip qos dscp cs5 media
 dtmf-relay h245-alphanumeric
 session target ipv4: 172.16.120.2 
!

interface Loopback0
 ip address 172.16.125.1 255.255.255.255
 no ip directed-broadcast
!

interface Serial2/0
 no ip address
 encapsulation frame-relay
 frame-relay traffic-shaping
!
interface Serial2/0.1 point-to-point
description Connection to New York
 ip address 172.16.120.1 255.255.255.0

 frame-relay interface-dlci 100
  class fr_class_voip  
!
!
ip classless
no ip http server
!
!
map-class frame-relay fr_class_voip
 frame-relay cir 64000
 frame-relay bc 640
 frame-relay be 0
 frame-relay mincir 64000
 no frame-relay adaptive-shaping
 frame-relay fair-queue
 frame-relay fragment  80


!--- The recommended fragment size for 10ms delay when carrying voice traffic.


!--- based on the configured CIR 64000. 

  frame-relay ip rtp priority 16384 16383 48
!
!
line con 0
 exec-timeout 0 0
 transport input none
line aux 0
line vty 0 4
 no login
!
end

Vérification

Cette section fournit des informations que vous pouvez utiliser pour confirmer le fonctionnement de votre configuration.

Certaines commandes show sont prises en charge par l'Output Interpreter Tool (clients enregistrés uniquement), qui vous permet de voir une analyse de la sortie de la commande show.

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

  • show traffic-shape queue : 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 (VC). Cette commande permet de vérifier le fonctionnement de la priorité RTP IP 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 la file d'attente prioritaire. Reportez-vous à l'exemple de résultat fourni.

  • 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. Reportez-vous à l'exemple de résultat fourni ici et reportez-vous également au Guide complet de configuration et de dépannage de Frame Relay pour plus d'informations.

newyork#show frame-relay fragment

interface   dlci   frag-type   frag-size   in-frag   out-frag   dropped-frag
 
Serial1/0.1 100    end-to-end    80          16        20           0 

Serial1/0.2 200    end-to-end    240         12        10           0 

newyork#show traffic-shape  serial 2/0.1
Interface Se2/0.1

     Access    Target   Byte   Sustain   Excess   Interval    Increment    Adapt
VC   List      Rate     Limit  bits/int  bits/int (ms)        (bytes)      Active

100            64000    80     640       0         10          80          -
  
newyork#show traffic-shape queue
Traffic queued in shaping queue on Serial2/0.1 dlci 100
  Queueing strategy: weighted fair
  Queueing Stats: 0/600/64/0 (size/max total/threshold/drops)
     Conversations  0/1/16 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 16 kilobits/sec

Traffic queued in shaping queue on Serial2/0.2 dlci 200
  Queueing strategy: weighted fair
  Queueing Stats: 0/600/64/0 (size/max total/threshold/drops)
    Conversations  0/1/16 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
     Available Bandwidth 144 kilobits/sec

newyork#show frame-relay pvc 100

PVC Statistics for interface Serial2/0 (Frame Relay DCE)

DLCI = 100, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE, INTERFACE = Serial2/0.1


input pkts 1078          output pkts 1078         in bytes 157792
out bytes 172284         dropped pkts 0           in pkts dropped 0
out pkts dropped 0                out bytes dropped 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 28        out bcast bytes 8498
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
pvc create time 00:27:48, last time pvc status changed 00:27:48
Queueing strategy: weighted fair
Current fair queue configuration:
	Discard     Dynamic      Reserved
	threshold   queue count  queue count
		64          16           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  IF_CONG no
frags 2707      bytes 172284    frags delayed 2707      bytes delayed 172284
shaping inactive
traffic shaping drops 0
ip rtp priority parameters 16384 32767 48000

Dépannage

Cette section fournit des informations que vous pouvez utiliser pour dépanner votre configuration.

Procédure de dépannage

Voici les informations et instructions de dépannage relatives à cette configuration :

  1. Dépannez Frame Relay et QoS mis en oeuvre pour la voix et assurez-vous qu’ils fonctionnent correctement.

  2. Passez au dépannage des échecs d'appels vocaux si nécessaire.

    Remarque : Pour plus d'informations sur le dépannage, référez-vous à VoIP sur Frame Relay avec QoS (fragmentation, formatage du trafic, priorité LLQ / IP RTP).

Dépannage des commandes

L'Outil Interpréteur de sortie (clients enregistrés uniquement) (OIT) prend en charge certaines commandes show. Utilisez l'OIT pour afficher une analyse de la sortie de la commande show .

Remarque : Consulter les renseignements importants sur les commandes de débogage avant d’utiliser les commandes de débogage.

  • debug priority : affiche les événements de mise en file d'attente par priorité (PQ) et indique si une perte se produit 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.

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

    newyork#debug priority 
Priority output queueing debugging is on
newyork#ping 172.16.120.1
Type escape sequence to abort. 
Sending 5, 100-byte ICMP Echos to 172.16.120.1, timeout is 2 seconds: 
!!!!! 
Success rate is 100 percent (5/5), round-trip min/avg/max = 56/57/60 ms 
newyork# 
*Mar  1 05:11:24.746: PQ: Serial2/0 output (Pk size/Q 104/2)
*Mar  1 05:11:24.754: PQ: Serial2/0 output (Pk size/Q 104/2) 
*Mar  1 05:11:24.810: PQ: Serial2/0 output (Pk size/Q 104/2)
*Mar  1 05:11:24.818: PQ: Serial2/0 output (Pk size/Q 104/2) 
*Mar  1 05:11:24.874: PQ: Serial2/0 output (Pk size/Q 104/2) 
*Mar  1 05:11:24.882: PQ: Serial2/0 output (Pk size/Q 13/0) 

newyork#debug frame-relay fragment interface serial 2/0 100
This may severely impact network performance.
You are advised to enable no logging console debug. Continue?[confirm]
Frame Relay fragment/packet debugging is on
Displaying fragments/packets on interface Serial2/0 dlci 100 only

*Mar  1 20:58:32.838: Serial1/0.1(o): dlci 100, tx-seq-num 3645, 
B bit set, frag_hdr 03 B1 9C 3D
*Mar  1 20:58:32.846: Serial1/0.1(o): dlci 100, tx-seq-num 3646, 
E bit set, frag_hdr 03 B1 5C 3E
*Mar  1 20:58:32.890: Serial1/0.1(i): dlci 100, rx-seq-num 17, 
exp_seq-num 17,B bit set,
	 frag_hdr 03 B1 80 11
*Mar  1 20:58:32.894: Serial1/0.1(i): dlci 100, rx-seq-num 18, 
exp_seq-num 18,E bit set,
	 frag_hdr 03 B1 40 12

Informations connexes

Historique de révision

Révision Date de publication Commentaires
1.0
06-Jul-2007
Première publication

Ce document vous est-il utile?

FeedbackCommentaires

Contacter Cisco