Le Délai dans les réseaux Voix sur IP (VoIP)

Le Délai dans les réseauxVoix sur IP (VoIP)

Sommaire • Introduction • Flux voix • Comment fonctionne la compression voix • Standards pour la valeur limite des délais • Sources du Délai - Délai du codeur - Délai de paquétisation - Délai de sérialisation - Délai des files d'attente - Délai de commutation réseau - Délai compensation de gigue • Etablir le budget Délai - Connexion avec un seul saut - Connexion avec deux sauts, un réseau public et un routeur C7200 comme commutateur tandem - Connexion avec deux sauts sur réseau public avec un PABX comme commutateur tandem - Connexion avec deux sauts sur réseau privé avec un PABX comme commutateur tandem • Effets de compressions multiples • Prise en compte des connexions avec délai important

ConversionA/N MIC CompressionMIC en Paquet WAN Flux Flux ConversionA/N MIC CompressionMIC en Paquet WAN V Introduction Quand on conçoit des réseaux qui transportent de la voix avec des paquets ou desinfrastructures à base de cellules (ATM), il est très important de comprendre et deprendre en compte les composantes du délai dans un réseau. Prendre en compte de manière correcte tous les délais potentiels permet de s'assurer que la performanceglobale du réseau est acceptable. La qualité globale de la voix est fonction de plu-sieurs facteurs incluant l'algorithme de compression, les trames perdues ou erronées,l'annulation d'écho et le délai. Ce document explique les sources du délai quand onutilise des routeurs ou passerelles Cisco sur des réseaux avec des paquets. Bien queles exemples soient basés sur Frame Relay, les concepts sont applicables à la voixsur IP (VoIP) et à la voix sur ATM (VoATM). Flux voix de base Le circuit pour un flux voix compressée est illustré ci-dessous. Le signal analogique issu du téléphone est numérisé sous forme d'impulsions codées (MIC ou PCM) par le codeur/décodeur voix (Codec). Les échantillons MIC sont ensuite traités avec un algorithme qui compresse la voix et la met sous forme de paquets pour être trans- mise sur le réseau WAN. A l'extrémité distante du réseau les mêmes fonctions sont réalisées dans l'ordre inverse. ConversionMIC N/A DécompressionPaquet en MIC Flux voix de base Selon la configuration du réseau, le routeur/passerelle peut exécuter les fonctions codec et compression ou une seule des deux. Par exemple, si un système analogique est utilisé, le routeur/passerelle réalise les fonctions de codage et de compression comme le montre la figure ci-dessous. Routeur

Flux ConversionA/N MIC CompressionMIC en Paquet WAN Routeur PABX Voix -10ms 0ms 10ms 20ms 30ms 40ms 50ms Temps 10 ms 10 ms A B C T0 10 ms de collecte d'échantillons MIC T1 5 ms d'anticipation V Si un PABX numérique est utilisé, le PABX réalise les fonctions de Codec et le routeur traite les échantillons PCM pour les compresser et les mettre en paquetscomme le montre la figure ci-dessous. Comment fonctionne la compression voix Les algorithmes de compression complexes utilisés dans les routeurs/passerelles fonctionnent par analyse de blocs d'échantillons MIC délivrés par les Codecs. Ces blocs varient en longueur selon le codeur utilisé. Par exemple, la taille de base d'un bloc utilisé par l'algorithme G729 est de 10 ms en durée alors que l'algorithme G723.1 est de 30 ms. Le schéma ci-dessous montre comment la compression G729 fonctionne. Le flux voix analogique est numérisé en échantillons MIC qui sont traités avec un algorithme de compression par incréments de 10 ms. Le traitement anticipé est traité dans le chapitre délai de compression.

Standards pour les valeurs limites du délai L'UIT-T traite du délai du réseau pour les applications voix dans l'avis G.114. Cet avis définit trois intervalles pour le délai dans un sens de transmission. Note: Ces recommandations sont faites pour des connexions avec un controle adéquat de l'écho ce qui implique que des annulateurs d'écho sont utilisés. Les annulateurs d'écho sont requis quand le délai dans un sens excède 25 ms (G131). Ces recommandations sont orientées pour des utilisations de réseaux de télécommu- nications nationaux et sont par conséquent plus exigeantes que celles qui seraient appliquées dans les réseaux voix privés. Quand la localisation et les besoins écono- miques des utilisateurs sont bien connus de l'architecte réseau, des délais plus importants peuvent devenir acceptables. Pour les réseaux privés, un délai de 200 ms est un objectif raisonnable et 250 ms une limite, mais tous les réseaux doivent être conçus de telle sorte que le délai maximum attendu pour une connexion voix soit connu et maîtrisé.

Flux de paquets Routeur Routeur 64 kb/s 64 kb/s E1 E1 1 1 2 1 1 3 2 x1 4 3 2 1 V V Sources du délai Il y a deux types distincts de délai : • Le délai fixe - Les composantes du délai fixe s'ajoutent au délai total de la connexion • Les délais variables - Les délais variables proviennent des délais des files d'attente de sortie sur les interfaces série connectées au réseau WAN. Ces files d'attente (buffer) créent des délais variables, appelés gigues, dans le réseau. Les délais variables sont compensés par un buffer de compensation de gigue en réception sur le routeur ou la passerelle. La figure ci-dessous identifie toutes les sources de délais fixes ou variables dans le réseau. 1 :Délai fixe du codeurx1:Délai de paquétisation fixe1, 2: Délai de sérialisation fixe1, 2, 3 : Délai de commutation fixe1, 2, 3, 4 : Délai de files d'attente1: Délai fixe du buffer de compensation de gigue

Délai du Codeur Le délai du codeur est le temps mis par le processeur de signal (DSP) pour compresser un bloc d'échantillons MIC. Comme les codeurs fonctionnent différenment, ce délai varie avec le codeur voix utilisé et le processeur voix. Par exemple les algorithmes ACELP (Algebraic Code Excited Linear Prediction) fonctionne par analyse d'un bloc d'échantillons MIC de 10 ms pour ensuite le compresser. Le temps de compression pour le processus CS-ACELP ( Conjugate Structure Algebraic Code Excited Linear Prediction) varie de 2,5 ms à 10 ms selon la charge du processeur de signal. Si le DSP est à pleine charge, le délai sera de 10 ms pour quatre canaux voix. Si le DSP est chargé avec un seul canal voix, le délai du codeur sera de 2,5 ms. Pour des raisons de conception de réseau nous utilisons le délai le plus défavorable de 10 ms. Le temps de décompression est approximativement égal à 10% du temps de compression de chaque bloc. Cependant comme il peut y avoir plusieurs échantillons dans chaque trame ou paquet, le temps de décompression est proportionnel au nombre d'échantillons par trame. Par conséquent, le temps de décompression le plus long pour une trame avec trois échantillons est de 3 ms (3x1 ms). Généralement deux ou trois blocs G729 compressés sont mis dans une trame tandis qu'un seul échantillon G723.1 compressé est émis dans une seule trame. Délais du codeur:

(Temps de compression par blocle plus défavorable)+(Temps de décompression par bloc)x (nombre de blocs dans un paquet)+(Délai de l'algorithme) = Paramètre délai agrégé du Codeur Délai de l'algorithme L'algorithme de compression, qui est basé sur les caractéristiques connues de la voix pour traiter correctement le bloc d'échantillons N, doit avoir une connaissance du du bloc N+1 pour reproduire fidèlement le bloc d'échantillons N. Cette analyse anticipée qui est un délai additionnel appelé délai algorithmique accroît effectivement la longueur du bloc de compression. Ceci se produit de manières répétitive de telle façon que le bloc N+1 analyse en partie le bloc N+2 et ainsi de suite. L'effet est un délai additionnel de 5 ms sur le délai total de la liaison. Cela signifie que le temps total requis pour traiter un bloc d'échantillons est de 10 ms avec un facteur délai supplémentaire de 5 ms. • Délai algorithmique pour G726 = 0 ms • Délai algorithmique pour G729 = 5 ms • Délai algorithmique pour G723.1 = 7,5 ms Pour les exemples dans le reste de ce document, nous utiliserons une compression G729 avec une charge utile de 30 ms/30 octets. Dans le but de faciliter la conception et d'avoir une approche conventionnelle, les tables ci-dessous utiliseront le cas du délai le plus défavorable. De plus, pour plus de simplicité, nous agrègerons le délai du codeur, le délai de décompression et le délai de l'algorithme en un seul facteur que nous appellerons le délai du codeur. L'équation utilisée pour générer le paramètre agrégé du codeur est la suivante: Le délai agrégé du Codeur pour G.729 que nous allons utiliser dans le reste du document est: Cas de compression le plus défavorable : 10 ms Temps de décompression par bloc x 3 blocs : 3 ms Délai de l'algorithme : 5 ms Total : 18 ms

Délai de paquétisation Le délai de paquétisation est le temps mis pour remplir la charge utile de paquet avec la voix encodée/compressée. Ce délai est fonction de la taille d'échantillon requise par le vocodeur et du nombre de blocs placés dans le paquet ou la trame. Le délai de paquétisation est aussi appelé "Accumulation Delay" car les échantillons voix sont stockés dans un buffer. Comme règle générale vous devez vous efforcer d'obtenir un délai de paquétisation n'excédant pas 30 ms. Pour les routeurs Cisco, vous devez respecter les valeurs suivantes: Vous devez équilibrer le délai de paquétisation avec la charge de la CPU. Plus le délai est faible plus le débit de paquets est élevé et plus charge de la CPU est élevée.

A B C Le délai de "Pipelining" dans le processus de paquétisation Bien que les échantillons voix subissent le délai algorithmique et le délai de paquéti- sation, dans la réalité ces processus se recouvrent et il y a un bénéfice réel avec ce système de "pipelining". Considérons l'exemple ci-dessous: Voix -10ms 0ms 10ms 20ms 30ms 40ms 50ms Temps 10 ms 10 ms T0 10 ms de collecte d'échantillons MIC T1 T2 Compression du premier bloc de 10 ms (2,5 ms) T3 T4 T5 Compression du troisième bloc de 10 ms (2,5 ms) T6 Transmission d'un bloc de 30 ms de voix compressée La ligne du haut de la figure montre un échantillon de signal voix et la seconde ligne une échelle de temps d'unité 10 ms. A T0, l'algorithme CS-ACELP commence à collecter les échantillons MIC venant du Codec. A T1, l'algorithme a collecté son premier bloc d'échantillons et commence à le compresser. A T2, le premier bloc d'échantillons est compressé. Notez que dans cet exemple le temps de compression est de 2,5 ms. Le second et le troisième blocs sont collectés à T3 et T4. le troisième bloc est compressé à T5 et transmis en T6. De par le type pipe-line du processus de paquétisation, le délai entre le début du processus et le début de la transmission de la trame est T6-T0 ou 32,5ms. L'exemple ci-dessus représente le meilleur des cas. Si le pire des cas avait été pris, le délai aurait été de 40 ms, 10 ms pour le codeur et de 30 ms pour le délai de pa- quétisation. Notez que l'exemple ci-dessus n'inclut pas le délai algorithmique.

Délai de Sérialisation Le délai de sérialisation est le délai fixe requis pour transmettre un paquet voix ou de données sur l'interface réseau. Ce temps est directement lié à l'horloge de l'interface. Rappelez-vous que pour des liaisons bas débits et des trames de petites tailles, le fanion utilisé pour séparer les trames n'est pas négligeable. Le tableau suivant montre les délais de sérialisation requis pour différents débits. Cette table prend en compte la totalité de la trame pour les calculs. Extrait de la table, sur une ligne à 64 Kb/s une trame voix CS-ACELP avec une longueur de 38 octets a un délai de sérialisation de 4,75 ms.Note: Le délai de sérialisation pour une cellule ATM de 53 octets (E1 : 0,207 ms) est négligeable à cause du débit de la ligne et de la taille de la cellule.

Délai de file d'attente Après la construction de la charge utile voix, un en-tête est ajouté et la trame est mise en file d'attente pour la transmission sur le réseau. Comme la voix doit avoir une priorité absolue sur le routeur/passerelle, une trame voix doit attendre si une trame données est en cours d'émission ou si une trame voix est en tête de file d'attente. Le délai de file d'attente est un délai variable et dépendant du débit de la liaison et de l'état de la file. Clairement il y a des éléments aléatoires associés au délai de file d'attente. Par exemple, supposons que nous avons une liaison à 64 Kb/s et que la trame est mise en file derrière une trame de données (48 octets) et une trame voix (42 octets). Comme on ne sait pas combien d'octets de la trame de données ont déjà été émis, nous allons supposer que la moitié des octets ont déjà été émis. En utilisant les données de la table de sérialisation, le délai d'émission restant sera de 6ms x 0,5 = 3 ms. En ajoutant le temps d'une autre file d'attente (5,25 ms) le temps total du délai de sérialisation sera de 8,25 ms. Rappelez-vous qu'une autre trame voix à cause de sa priorité n'attendra pas un temps supérieur à l'émission d'une trame de données.Délai de commutation du réseau Le réseau public Frame Relay ou ATM interconnectant les extrémités est une source de délai non négligeable. Les délais de commutation du réseau sont difficiles à quan- tifier. Si la connexion WAN est assurée par un réseau privé, il est possible d'identifier les composantes individuelles du délai. En général, les composantes fixes sont les délais de propagation sur les lignes à l'intérieur du réseau et les délais variables sont ceux générés par le passage des trames dans les commutateurs intermédiaires. Pour estimer ce délai de propagation, une estimation de 10 µs par mile ou 6 µs par km (G.114) est communément utilisé bien que tous les différents équipements situés dans les réseaux de transport créent des exceptions. L'autre composante significative du délai est la gestion de files d'attente dans le réseau WAN. Dans un réseau privé, il est possible de mesurer ces délais ou d'estimer un budget par saut dans le réseau WAN. Le délai typique des réseaux Frame relay est de 65 ms dans le pire des cas. Pour simplifier, les exemples de calcul de budget délai sont basés sur un délai réseau de 40 ms. Certains opérateurs offrent des services de type premium avec un délai garanti de 50 ms.

Intervalle de travailnormal Paquetsissus du réseau vers le DSP V V V V V V V V V Débit de sortieconstant égalau débit duCodec Remplissage troprapide du buffer Remplissage troplent du buffer Point limitespécifié en ms Délai de compensation de gigue Parce que la voix est un service à débit constant, la gigue ou les variations de délai doivent être éliminés avant que le signal quitte le réseau. Dans les routeurs Cisco cela est réalisé par un buffer de compensation de gigue à l'extrémité réceptrice. Le buffer de compensation de gigue transforme le délai variable en délai fixe en gardant le premier échantillon reçu pendant une durée déterminée avant de le traiter. Ce laps de temps est connu comme le délai initial de sortie. Une gestion rigoureuse du buffer de compensation de gigue est critique. Si les échan- tillons sont gardés pendant un temps trop court, les variations de délai vont faire que le buffer va se vider trop vite et cela va causer des blancs dans la conversation. Si les paquets sont gardés pendant un temps trop long, il y aura élimination de paquets car le buffer sera saturé et le délai total sur la connexion peut devenir inacceptable. Le délai initial optimum pour la sortie de l'échantillon est égal au délai variable total de la connexion.Note: Les buffers de compensation de gigue peuvent être adaptifs mais le délai maximum est fixe.

V V Flux de paquets Routeur Routeur 64 kb/s 64 kb/s E1 E1 1 4 3 2 1 B=(1+ 2+ 3+ 4) 1= 1,5xB La valeur initiale du délai de sortie du buffer est configurable et la profondeur du buffer avant qu'il ne déborde est normalement fixée à 1,5 ou 2 fois le délai variable global. Si un délai délai nominal de 40 ms est utilisé, le premier échantillon voix reçu quand le buffer de compensation de gigue est vide sera conservé pendant 40 ms avant d'être sortie du buffer. Ceci implique que les paquets suivants reçus du réseau doivent être retardés de 40 ms au maximum sans perte de continuité dans la voix. Si le paquet suivant est retardé de plus de 40 ms, le buffer de compensation de gigue sera vide et le prochain paquet sera conservé pendant 40 ms avant d'être sorti du buffer. Ceci résultera dans un "blanc" dans le signal voix sorti après 40 ms. La contribution au délai du buffer de compensation de gigue correspond au délai initial de sortie du buffer plus le délai pendant lequel le paquet est bufférisé dans le réseau. Le pire des cas sera égal à deux fois le délai initial de sortie du buffer de compensation de gigue (en supposant que le premier paquet a subi un délai de bufferisation minimum. En pratique sur un réseau avec plusieurs commutateurs, il n'est pas forcément nécessaire d'utiliser le pire des cas. Les calculs dans les exemples qui suivent accroissent le délai initial de sortie du buffer par un facteur de1,5.Note: Dans le routeur/passerelle à la réception, il y a un délai de décompression, mais il a été pris en compte en l'agrégeant au délai de compression comme cela a été précisé dans les chapitres précédents.

Flux de paquets Routeur Routeur Réseau Frame Relay 64 kb/s 64 kb/s 1 1 1 x1 Composantes fixes et variables dudélai du réseau 1 V V Etablir le Budget Délai La limite de délai généralement admise pour une connexion voix de bonne qualité est de 200 ms dans un sens (250 ms comme limite max). Si les délais dépassent ces valeurs, les interlocuteurs ne pourront plus converser directement. Il y a recouvre- ments des "émetteurs" ou les deux attendent que l'autre parle. Ce phénomène est très souvent rencontré sur les liaisons satellite pour les liaisons internationales (le délai dans ce cas est 500 ms (250 ms aller, 250 ms retour). Les exemples suivants illustrent différentes configurations de réseaux et les délais que l'architecte réseau doit prendre en compte.Connexion avec un seul saut Une connexion typique avec un saut au travers d'un réseau réseau Frame Relay peut avoir le budget délai suivant: Note: Comme le délai de file d'attente et la composante variable du délai du réseausont déjà pris en compte dans le délai du buffer de compensation de gigue, le délaitotal effectif est égal à la somme des délais fixes. Dans ce cas le délai total sera de138 ms.

C7200 C2600 Réseau Frame Relay 64 kb/s E1 2 1 1 2 t1 x1 Composantes fixes et variables dudélai du réseau 64 kb/s 1 MC3810 t1 : Délai commutation tandem 1 V V V Connexion avec deux sauts, un réseau public et un routeur C7200 comme commutateur tandem Maintenant considérons une connexion de branche à branche dans une topologie en étoile dans laquelle le C7200 du site central relaie l'appel vers la branche destina- taire. Dans ce cas le signal reste dans son format compressé à travers le C7200, ce qui évite un délai trop important. Note : Comme le délai de file d'attente et la composante variable du délai du réseau sont déjà prises en compte dans les calculs du buffer de compensation de gigue, le délai total est effectivement égal à la somme des délais fixes. Dans ce cas le délai total sera de 209,1 ms

V V V Connexion avec deux sauts sur réseau public avec un PABX comme commutateur tandem C7200 PABX C2600 Réseau Frame Relay 64 kb/s E1 1 1 2 1 t1 x1 Composantes fixes et variables dudélai du réseau 64 kb/s 1 MC3810 t1 : Délai commutation tandem 2 Considérons une connexion de branche à branche dans une topologie en étoile dans laquelle le C7200 du site central passe l'appel vers le PABX pour la commutation. Dans ce cas le signal voix doit avoir subi la compensation de gigue puis décompres- sé et de nouveau compressé et la gigue de nouveau compensée. Le résultat est une augmentation du délai par rapport à l'exemple précédent. De plus, les deux compression CS-ACELP successives réduisent la qualité de la voix.

Note : Comme le délai de file d'attente et la composante variable du délai du réseau sont déjà prises en compte dans les calculs du buffer de compensation de gigue, le délai total est effectivement égal à la somme des délais fixes. Dans ce cas le délai total sera de 258,1 ms. L'utilisation de PABX comme commutateur au site central accroît le délai dans un sens de 206ms à 255 ms, ce qui est très proche de la limite UIT-T. Ce type de configuration requiert toute l'attention de l'ingénieur réseau pour obtenir un délai minimum. Notez que nous avons pris le pire des cas pour le délai variable et faire des hypothè- ses plus optimistes pour les délais variables peut améliorer la situation. Cependant avec des informations plus précises au sujet des délais variables et des délais fixes dans le réseau Frame relay de l'opérateur, le délai calculé serait certainement plus faible. Les connexions locales ont certainement de meilleures caractéristiques de délai, mais les opérateurs sont souvent réticents pour donner les valeurs limites des délais.

V V V Connexion avec deux sauts sur réseau privé avec un PABX comme commutateur tandem Réseau Frame Relay 1, 1 C7200 PABX 2, 2 C2600 64 kb/s E1 1 1 2 2, 2, 3 1 t1 x1 64 kb/s 1 MC3810 t1 : Délai commutation tandem 2 L'exemple précédent a montré qu'avec les délais maximum, il très difficile garder le délai global en dessous des 200 ms quand une connexion branche à branche inclut un PABX comme commutateur tandem et un réseau Frame relay public. Ceci est du au fait que les chiffres donnés par les opérateurs sont limités au pire des cas pour les délais de transmission et les files d'attente sur un réseau WAN, alors qu'il est beaucoup plus aisé d'établir des limites raisonnables dans un réseau privé. Le délai généralement admis pour le délai de propagation entre commutateurs est de l'ordre de 6 µs par Km. Selon l'équipement utilisé, le délai de commutation dans un réseau Frame relay doit être de l'ordre de 1ms à 5 ms max. Ces valeurs sont dépen- dantes de l'équipement et du trafic. Le délai pour les commutateurs Cisco WAN MGX est inférieur à 1 ms par commutateur si des liaisons E1/T1 sont utilisées. avec une distance de 800 Kms , un délai fixe de 1 ms et un délai variable de 5 ms pour chaque saut, le calcul des délais sera le suivant (page suivante):

Note : Comme le délai de file d'attente et la composante variable du délai du réseau sont déjà prises en compte dans les calculs du buffer de compensation de gigue, le délai total est effectivement égal à la somme des délais fixes. Dans ce cas le délai total sera de 191,1 ms. En utilisant un réseau Frame relay privé, il est clairement possible de réaliser des connexions branche à branche au travers d'un PABX au site central et de rester dans la limite des 200 ms.

Effets de compressions multiples Les algorithmes de compression CS-ACELP ne sont pas déterministes, ceci signifie que le flux de données compressé n'est restitué de manière exacte en sortie. Un faible taux de distorsion est introduit à chaque cycle de compression comme le montre la figure ci-dessous. Flux Entrée Sortie Un cycle decompressiondécompressionCS-ACELP Signal restitué+ faible distorsion Signal original Par conséquent, de multiples compressions CS-ACELP successives introduisent un niveau significatif de distorsion. Cette distorsion n'est pas aussi prononcée que celle des algorithmes ADPCM (Adaptive Differential Pulse Code Modulation). L'impact de cette caractéristiques est qu'en plus des délais, l'architecte réseau doit tenir compte du nombre de compression CS-ACELP présentes dans un chemin. La qualité de la voix est subjective mais la majorité des utilisateurs trouvent que deux compression CS-ACELP successives fournissent toujours une bonne qualité de voix. Une troisième compression résulte en une dégradation perceptible de la qualité qui peut être inacceptable pour certains utilisateurs. Comme règle, l'architecte réseau doit limiter le nombre de compression CS-ACELP dans un chemin à deux. Si le nombre de compression est supérieur faites d'abord un test de qualité avec des utilisateurs. Dans les exemples précédents, il est démontré que lorsqu'une connexion branche à branche est réalisée par un PABX commutateur tandem (format MIC) au site central, elle demande un délai plus important que pour une connexion avec un C7200 en commutateur tandem. Il est clair que lorsqu'un PABX est utilisé pour commuter, il y a deux cycles de compression CS-ACELP dans le chemin au lieu d'un cycle quand la voix paquétisée est commuté par le C7200. La qualité dela voix sera meilleure avec le C7200 en commutateur bien qu'il y ait d'autres raisons telles qu'un plan de numé- rotation qui nécessite d'inclure le PABX dans le chemin. Si une connexion branche à branche est faite au travers d'un PABX central et à partir de la seconde branche la communication passe à travers un réseau public vers un utilisateur téléphone cellulaire, il y aura trois compressions CS-ACELP dans le chemin ainsi qu'un délai très significatif. Dans ce scénario, la qualité de la voix sera notablement affectée. De nouveau l'architecte réseau devra considérer le pire des cas pour l'appel et décider si cela est acceptable selon les attentes des utilisateurs et des exigences économiques

Prise en compte des connexions avec délai important Comme cela a été montré précédemment, il est relativement aisé de construire des réseaux avec voix paquétisée qui excèdent la limite de 150 ms dans un sens définie par l'UIT-T. Lors de la création de réseaux avec voix paquétisée, l'ingénieur devra prendre en compte la fréquence d'utilisation d'une connexion, ce que demande l'utilisateur et quel type d'activité commerciale est concernée. Il n'est pas rare que des connexions avec délai élevé soient acceptables dans des conditions particulières. Comme cela a été noté précédemment, si les connexions Frame relay ne se font pas sur de longues distances, les performances de délai seront meilleures que celles données dans les exemples. Si le total engendré par connexion tandem avec routeur devient trop grand, l'alterna- tive est de configurer des circuits virtuels directs. Cela accroît le coût du réseau mais peut s'avérer absolument nécessaire dans certains cas.

Le Délai dans les réseaux Voix sur IP (VoIP)