Plic Plouc

1. LA VoIP
1.1. VoIP VS Téléphonie classique

La VoIP devient de nos jours un outil de plus en plus utilisés, c’est un outil de communication qui s’est beaucoup démocratisé ces dernières années. Cette technologie de communication se développe en parallèle avec d’autres, comme la vidéo, ou le trafic de données. Toutes les 3 (voix, vidéo, données) forme ce qu’on appelle le « triple play » et fait partie des enjeux principaux des acteurs de télécommunication de nos jours.
De nos jours, si l’on compare le trafic IP à celui du réseau voix ( commutation de circuits) dans les entreprises, on se rend compte que le trafic du réseau IP surpasse complètement celui de la voix, ce qui a, bien entendu amené les opérateurs, entreprises, fournisseurs a se pencher sur cette technologie pour bénéficier de l’avantage de transport unique IP, introduire de nouveaux services voix et vidéo. Ce fût en 1996 la naissance de la première version voix sur IP appelée H323. Issu de l'organisation de standardisation européenne ITU-T sur la base de la signalisation voix RNIS (Q931), ce standard a maintenant donné suite à de nombreuses évolutions, quelques nouveaux standards prenant d'autres orientations technologiques.

Pour être plus précis et néanmoins schématique, le signal numérique obtenu par numérisation de la voix est découpé en paquets qui sont transmis sur un réseau IP vers une application qui se chargera de la transformation inverse (des paquets vers la voix). Au lieu de disposer à la fois d'un réseau informatique et d'un réseau téléphonique commuté (RTC), l'entreprise peut donc, grâce à la VoIP, tout fusionner sur un même réseau. Les nouvelles capacités des réseaux à haut débit devraient permettre de transférer de manière fiable des données en temps réel. Ainsi, les applications de vidéo ou audioconférence ou de téléphonie vont envahir le monde IP qui, jusqu'alors, ne pouvait raisonnablement pas supporter ce genre d'applications (temps de réponse important, jigue-jitter, Cos-Qos,...). Jusque vers le milieu des années 90, les organismes de normalisation ont tenté de transmettre les données de manière toujours plus efficace sur des réseaux conçus pour la téléphonie. A partir de cette date, il y a eu changement. C'est sur les réseaux de données, que l'on s'est évertué à convoyer la parole. Il a donc fallu développer des algorithmes de codage audio plus tolérants et introduire des mécanismes de contrôle de la qualité de service dans les réseaux de données. Faire basculer différents types de données sur un même réseau permet en plus, de simplifier son administration.

Comme toute innovation technologique qui se respecte, la VoIP doit non seulement simplifier le travail mais aussi faire économiser de l'argent. Les entreprises dépensent énormément en communications téléphoniques, or le prix des communications de la ToIP est dérisoire en comparaison. En particulier, plus les interlocuteurs sont éloignés, plus la différence de prix est intéressante. De plus, la téléphonie sur IP utilise jusqu'à dix fois moins de bande passante que la téléphonie traditionnelle. Ceci apportant de grand intérêt pour la voix sur réseau privée. Il semblerait que les entreprises après avoir émis un certain nombre de doutes sur la qualité de services soient désormais convaincues de la plus grande maturité technologique des solutions proposées sur le marché.

Les premières technologies de VoIP imaginées étaient propriétaires et donc très différentes les unes des autres. Pourtant, un système qui est censé mettre des gens et des systèmes en relation exige une certaine dose de standardisation. C'est pourquoi sont apparus des protocoles standards, comme H323 ou SIP.



1.2. Implémenter de la voix dans un inter réseau d’IP

1.2.1. La voix en temps réel dans un inter-réseau IP

Le réseau traditionnel de téléphonie a été initialement conçu pour porter la voix. La conception d’un réseau téléphonique garanti l'accès et un seuil de retard (delay) entre la source et la destination. Le réseau IP a été initialement conçu pour transporter un trafic de données, mais n’a pas été conçu pour le trafic de voix. Bien que le trafic de données soit le plus rapide et puisse résister à une certaine quantité de delay, jitter (instabilité), et perte, le traffic de voix doit se faire ne temps réel, on doit donc implémenter de la qualité de service (QoS). En l'absence de paramètres spéciaux de QoS, un paquet de voix est traité comme tout autre paquet de données.





Inter-réseau IP

L'IP fournit les voies d'accès multiples de la source à la destination.

Dans le réseau représenté sur la figure, les paquets de voix entrent le réseau à une cadence constante et peuvent atteindre la destination par un certain nombre d'itinéraires. Puisque chacun de ces itinéraires peut avoir un temps de trajets différents, la cadence des arrivées des paquets peut changer. Cette condition s'appelle jitter.

Un autre effet des itinéraires multiples est que les paquets de voix peuvent arriver dans le désordre. Le routeur de bordure qui a le service voix activé ou la passerelle doit remanier les paquets dans l’ordre pour assurer la bonne qualité de la communication.
La transmission réseau ajoute des effets négatifs comme le bruit, le delay, l’écho, jitter, et perte de paquet au signal sonore. La VoIP est sensible à ses problèmes réseau, qui peuvent dégrader la qualité de la voix.

Pour qu’un réseau de VoIP fournisse la même qualité que les utilisateurs de la téléphonie traditionnelle, le réseau doit s'assurer que le délai de transmission d’un paquet de voix à travers le réseau, et le jitter, n'excède pas les seuils spécifiques.

1.2.2. Perte de paquets, délai et jitter

Dans les réseaux de téléphonie traditionnels, le trafic voix a une bande passante garantie à travers le réseau. La configuration de la voix dans un environnement de réseau informatique exige des services de réseau avec peu de délai, un jitter minimal, et peu de perte de paquets.
Sur le long terme, la perte de paquet, le délai, et jitter affectera la qualité de voix,

Comme suit :

• Perte de paquet : Le réseau d'IP peut relâcher des paquets de voix si la qualité de réseau est pauvre, si le réseau est encombré, ou s'il y a trop variable retardent dans le réseau. Les algorithmes des codecs peuvent corriger un peu de perte, mais trop de perte peut causer du découpage et des sauts de voix. La cause principale de la perte de paquet est l’encombrement du réseau.

• Délai : C’est le temps qu'on prend pour envoyer un paquet d’un bout à l’autre du réseau.

• Jitter : C’est la variation entre l'arrivée prévue d'un paquet et quand elle est reçue réellement. Pour compenser cette variation de délai entre les paquets de voix dans une conversation, les extrémités des réseaux VoIP emploient des mémoires tampons pour transformer les variations de délai en valeur constante de sorte que la voix puisse être jouée dehors sans à-coup. Les mémoires tampons peuvent se remplir instantanément, parce que l'encombrement du réseau peut se produire à tout moment dans un réseau. Cette utilisation instantanée de mémoire tampon peut mener à une différence dans le délai entre les paquets dans le même flux de voix.

Exemple : Perte de paquet, délai, et problème de type jitter.

L'effet de la perte de paquet, du délai, et du jitter peut être défini comme suit :
• La partie appelante indique, "bonjour, comment allez vous?"
• Avec le délai de bout en bout, la partie appelée entend, "...... bonjour, comment allez vous?"
• Avec le jitter, la partie appelée entend, "...... bonjour, comment...... allez vous?"
• Avec la perte de paquet, la partie appelée entend, "bon..ur, Q.. etes vous?"

1.2.3. Les passerelles : fonctions & utilisations

Analog versus Digital


Une passerelle est un dispositif qui traduit un type de signal en différent type de signal.
Il y a différents types de passerelle, y compris des passerelles de voix.
Une passerelle voix est un routeur ou un commutateur qui converti des paquets de VoIP en signaux numériques ou analogues, qui sont compris par des trunks TDM ou des stations de travail. Des passerelles sont utilisés dans plusieurs situations ; par exemple, pour relier le PSTN, un PBX, ou un système clef du réseau VoIP.

Dans la figure, le routeur voix-permis examine le paquet entrant d'IP pour déterminer si c'est un paquet de voix et où il se dirige. Basé sur l'information à l'intérieur du paquet de voix, le routeur traduit le signal ou la voix digitalisé en signal numérique analogue ou approprié d'être envoyé au PSTN. Pour un appel venant du PSTN, le passage interprète les chiffres composés et détermine la destination d'IP pour cet appel.

Exemple : Passerelles analogues et digital

Dans la figure ci-dessus, le routeur voix examine le paquet entrant d'IP pour déterminer si c'est un paquet de voix et où il se dirige. Basé sur l'information à l'intérieur du paquet de voix, le routeur traduit le signal digital ou la voix, en signal numérique ou analogique pour être envoyé au PSTN. Pour un appel venant du PSTN, la passerelle interprète les digits composés et détermine la destination IP pour cet appel.


1.3. Les challenges de la VoIP

Les réseaux de téléphonie traditionnelle s’attachent à être opérationnel 99,99% du temps. Cela correspond à seulement 5,25 minutes de mise hors service par an. Beaucoup de réseaux de données ont du mal à avoir de telles performances. Ce document va décrire les méthodes que vous pouvez utiliser pour améliorer la disponibilité et la fiabilité de votre réseau de données.



Pour fournir aux utilisateurs de VoIP les mêmes (ou à peux prés les mêmes) niveaux de service qu’ils ont rencontrés sur les réseaux de téléphonie classiques, une importance croissante est accordée à la fiabilité et la disponibilité du réseau de données. Quand le réseau de données tombe, il ne peut pas redémarrer avant quelques minutes voir quelques heures. Ce délai est inacceptable pour les utilisateurs de VoIP. Les utilisateurs locaux, avec du matériel réseau tel que des routeurs avec fonction VoIP activé, passerelle ou switch pour IP Phones, peuvent maintenant savoir si leur connexion est interrompue.

Les administrateurs doivent, par conséquent, fournir une alimentation électrique ininterrompue (grâce aux onduleurs) à ces matériels pour maintenir la disponibilité. Précédemment, en fonction du type de connexion de l’utilisateur, l’alimentation était fournie par la compagnie de téléphone ou par un onduleur qui est connecté aux switchs ou au PBX dans le cas d’une alimentation extérieure. Maintenant le matériel réseau doit avoir une alimentation protégée pour continuer de fonctionner et fournir une alimentation au matériel réseau final. La fiabilité des réseaux vient de la redondance intégrée dans le design des réseaux.

Dans la téléphonie traditionnelle, les switchs ont de multiples liens redondants vers les autres switchs. Si un lien ou un switchs devient inaccessible, la compagnie de téléphone peut router les appels vers d’autres liens. C’est pourquoi les compagnies de téléphone peuvent mettre en avant un fort pourcentage de disponibilité.

La haute disponibilité englobe beaucoup de domaines du réseau. Dans un réseau totalement redondant, les composants suivant doivent être redondant:
• Les serveurs et call managers.
• Les matériels de couche d’accès, tels que les switchs.
• Les matériels de la couche distribution, tels que routeurs ou switchs MPLS.
• Les matériels de cœur de réseau, tels que switchs MPLS.
• Les interconnections, tells que les liens WAN, même avec des liens chez différent fournisseurs.
• Les alimentations et les onduleurs.
Dans quelques réseaux de données, un haut niveau de disponibilité et de fiabilité n’est pas suffisamment important pour assurer le financement de matériel ou de liens pour faire de la redondance complète. Si de la VoIP est superposé au réseau, le matériel nécessaire doit être acheté.

Avec la technologie Cisco Architecture for Voice, Video and Integrated Data (AVVID), l’utilisation de clusters Cisco Call Manager fourni les outils nécessaires pour un design avec du matériel redondant en cas de disfonctionnement du Cisco Call Manager. Quand vous allez utiliser la passerelle, vous pourrez configurer une deuxième passerelle de secours en tant que deuxième passerelle au cas où la première tomberait. Vous devez aussi réviser l’infrastructure du réseau. Le matériel redondant et les services fournis par l’IOS Cisco, tel que la mise en attente Le matériel redondant et les services IOS, tels que le Hot Standby Router Protocol (HSRP), peuvent fournir une haute disponibilité. Pour une gestion de réseau dynamique (monitoring et report d’erreur), une plateforme de gestion de réseau tel que CiscoWorks2000 fourni un haut degré de réactivité suite à un défaut sur le réseau.


1.3.1. La bande passante requise pour la VoIP

Ce sujet va décrire chaque codec utilisé en VoIP ainsi que la bande passante requise et l’impact sur la bande passante totale.



Un des facteurs les plus importants pour un administrateur réseau est de prendre en considération, quand il construit un réseau VoIP, la planification des services appropriés. Les administrateurs doivent comprendre le cout en bande passante pour chaque appel VoIP. Avec une compréhension exhaustive des bandes passantes VoIP, l’administrateur réseau peut appliquer les outils de panification.

Voici une liste de codecs avec la bande passante qui leurs est associé :

• Le G.711 “pulse code modulation” (PCM), ce codec utilise le maximum de bande passante. Il échantillonne 8000 fois par seconde, chaque échantillon fait 8bits, pour un total de 64000bps.
• Le G.726 “adaptive differential pulse code modulation” (ADPCM), ce codec utilise légèrement moins de bande passante. Quand tous les codecs échantillonnent 8000 fois par seconde comme le PCM, ce dernier utilise 4, 3, ou 2 bits pour chaque échantillon. Ces 4, 3, ou 2 bits pour chaque échantillon font que ce codec utilise une bande passante totale de 32000, 24000, ou 16000 bps.
• Le G.728 “low delay-code excited linear prediction” (LD-CELP), ce codec compresse les échantillons PCM en utilisant une compression par dictionnaire. Ce codec utilise une bande passante totale de 16000 bps.
• Le G.729 et le G.729a “Conjugate Structure Algebraic Code Excited Linear Prediction” (CS-ACELP), Ces codecs compressent aussi les PCM en utilisant une compression par dictionnaire plus évoluée. Ce codec utilise un total de bande passante de 8000 bps.
• Le G.723 et le G.723a “multipulse maximum likelihood quantization” (MPMLQ), ce codec utilise une compression par algorithme. En utilisant une telle compression on arrive à une bande passante de 6300 ou 5300 bps.
Un administrateur réseau doit choisir entre la qualité de la VoIP et le cout en bande passante lorsqu’il choisi le codec utilisé. Plus la bande passante du codec est importante, plus le coût de chaque appel à travers le réseau est important.

2. Présentation des IP phones

2.1. Les modèles CISCO IP Phones

Il existe plusieurs gammes d’IP Phones, allant du modèle de base 7906G jusqu’à la station de conférence 7936G. Certains téléphones tel que l’IP Phone 7961G-GE intègrent une interface Gigabit Ethernet (GE), et d’autres supportent la technologie Wireless.


Cisco Unified IP Phone 7985G

Modèle haut de gamme, incluant une webcam pour la visioconférence en plus des services de téléphonie IP proposés par les autres modèles de Cisco IP Phones.


7936G


Cisco Unified IP Phone 7970G–GE, 7971G–GE

Les modèles 7971 et 7970 peuvent implémenter une interface Gigabit Ethernet en version GE. Ils possèdent également un écran couleur tactile, d’une dimension de 320 x 223. Par ailleurs ces modèles peuvent être équipés de deux boîtiers additionnels 7914 pour augmenter le nombre de touches à disposition. L’injection de courant électrique par câblage Ethernet est possible (PoE).


7971G-GE


Cisco Unified IP Phone 7961G-GE, 7960G, 7941G-GE et 7940G

Ces modèles appartiennent à la gamme moyenne d’IP Phones, contrairement aux modèles supérieurs l’écran est noir et blanc non tactile. Ils possèdent les fonctions de base de la téléphonie sur IP, cependant il est possible d’implémenter deux modules complémentaires 7914 sur les versions 7961 et 7960. L’auto alimentation par PoE est intégrée aux IP Phones.


Cisco Unified IP Phone 7931G, 7911G et 7906G

Les IP-Phones 7931, 7911 et 7906 constituent les modèles d’entrée de gamme équipés d’écrans noir et blanc et pour certains de boutons programmables.


7911G


Cisco Unified IP Phone Expansion Module 7914

Les IP Phones modèles 796X et 797X ont la possibilité d’implémenter deux modules d’extension 7914 pour porter à 34 le nombre de boutons programmables. Le module présente un affichage LCD et 14 boutons.


Module d’extension 7914


Cisco Unified IP Conference Station 7936

Cette station diffère des téléphones IP car elle ne possède pas de combiné et un affichage restreint. Très utile avec ses multiples microphones et haut-parleurs, la station 7936 sera essentiellement employée en salle de réunion, ou de conférence.


Station 7936




Cisco Unified IP Phone Power Injector

Certains modèles d’IP Phones peuvent être alimentés avec leur propre câble UTP, pour cela un équipement Ip Phone Power Injector sera installé sur la ligne, entre le commutateur et le téléphone IP.


IP Phone Power Injector


Cisco Unified Wireless IP Phone 7920 et 7921G

Cisco présente deux modèles de téléphones IP sans fils, le 7921G avec écran couleur et le 7920 noir et blanc. Le support de la norme 802.11g n’est accessible que sur l’IP Phone 7921G, contrairement au 7920 qui ne gère que 802.11b.


7921G

⇨ Un modèle 7920 Multi-Charger offre la possibilité de recharger jusque 6 Ip Phones 7920 simultanément.


2.2. Connexion des IP phones au réseau

Plusieurs types de branchements sont autorisés sur les réseaux contenant de la VOIP comme il est possible de le voir sur le schéma ci-dessous.



Nous allons voir dans les sous-chapitres suivants quels sont les avantages et les inconvénients de chaque type d’architecture.
Dans tout les cas les téléphones se connectent soit avec une alimentation séparé soit en utilisant la PoE (Power Over Ethernet).

Plusieurs serveurs peuvent venir se greffer sur les architectures précédentes afin de gérer l’authentification, la gestion de présence comme nous pouvons le voir dans le schéma ci-dessous.



2.2.1. Installation avec un seul câble



Beaucoup d’entreprises utilisent ce type d’architecture car elle n’impose pas le passage de câbles supplémentaires et donc moins de frais (passage de câbles, achat de Switch supplémentaires et armoires de câblage) pour les entreprises dont le réseau et déjà installé et fonctionnel

2.2.2. Installation avec plusieurs câbles



Ce type d’architecture utilise des câbles séparés qui relient les PC et les IP phones. Cette infrastructure permet de gérer plus facilement les priorités en appliquant par exemple un seuil d’utilisation pour la partie data et ainsi améliorer la QoS.



2.2.3. Installation avec plusieurs Switch



Dans ce modèle plusieurs câbles relient les Switch et les PC à des Switch différents. Les réseaux de voix et de données sont ainsi séparés physiquement, il est donc possible de considérer les deux réseaux comme indépendants et de prévoir des budgets pour chaque réseau. De même au niveau sécurité cela permet de simplifier les diverses configurations.

2.2.4. Gestion du réseau et des protocoles

Contrairement aux données où seul le débit global compte, il faut garantir pour la voix un flux le plus régulier possible. Cela peut se faire de différentes façons :

En utilisant des protocoles de transport simplifiés pour ne pas ralentir le trafic, quitte à ne pas prendre en compte la gestion des erreurs (la voix est peu sensible à quelques erreurs contrairement aux données mais la qualité perçue est très dépendante des fluctuations de délais dues aux congestions dans le réseau).
Ainsi, le protocole UDP est plus adapté pour le transport de la voix que TCP. A terme, le nouveau protocole DCCP (Datagram Congestion Control Protocol), très simplifié et adapté au trafic point à point pourrait remplacer UDP.

L’arrivée d’IPv6 devrait résoudre le manque d’adresses IP actuelles tout en intégrant des mécanismes de sécurité pour protéger les terminaux des attaques directes.

Enfin, si la téléphonie IP est appelée à remplacer complètement le Réseau Téléphonique Commuté, il est important qu’elle reprenne à l’identique dès le début, les services offerts par le réseau traditionnel. Il faut par exemple, garantir les services d’urgence, en particulier ceux nécessitant une information de localisation (15 en France ou 911 aux Etats Unis qui appellent le Samu le plus proche) ou les numéros en 08XX qui peuvent rediriger vers divers centres de traitement suivant le lieu d’où on appelle.

2.3. Cisco IP communicator : un IP Phone logiciel



La gamme Cisco comprend des IP Phones matériels mais également un équipement logiciel, le soft phone Cisco IP Communicator. Cet outil s’installe sur une plateforme Windows, et permet de simuler un IP Phone de type 7970.

L’IP Communicator possède les fonctionnalités du haut de gamme Cisco 7970 pour le prix d’un IP Phone entrée de gamme. L’emploi d’un micro casque est recommandé, mais il fonctionne également avec un micro et hauts parleurs intégrés à l’ordinateur. Une série de boutons programmables sont mis à disposition de l’utilisateur en plus des fonctionnalités standard.
3. Installation du Soft phone Cisco

3.1. Prés requis et installation de Cisco IP Communicator

3.1.1. Pré requis d’installation du soft phone

Le logiciel Cisco IP Communicator requiert un système d’exploitation Windows pour son fonctionnement. Selon l’OS, les prés requis peuvent varier :

Configuration minimale :

• Windows 2000 Pro avec SP3.0
• PIII 450 Mhz 128 Mo RAM
• 100 Mo d’espace disque
• Une carte son non-IS en duplex intégral
• Une carte réseau Ethernet 10/100Mbits

ou

• Win XP avec SP1.0
• PIII 450 Mhz 256 Mo RAM
• 100 Mo d’espace disque
• Une carte son non-IS en duplex intégral
• Une carte réseau Ethernet 10/100Mbits

3.1.2. Installation de Cisco IP Communicator


Le logiciel Cisco IP Communicator s’installe à partir de l’exécutable Windows sur une station en Windows 2000 minimum ou Windows XP.





⇨ Plusieurs langues sont disponibles à l’installation, le français, l’anglais, etc…

Une fois l’installation terminée l’assistant de configuration des paramètres sonores va s’exécuter.



Ne pas oublier de tester le volume sonore des hauts parleurs et du micro avant de continuer la configuration.

Lorsque les paramètres sonores auront été configurés, l’étape suivante consiste à indiquer les paramètres de connexion, à savoir nom d’utilisateur, adresse TFTP, et autres.

3.2. Configuration de Cisco IP Communicator

L’outil de paramétrage s’ouvrira automatiquement au premier démarrage du logiciel. Les champs à remplir absolument sont le nom d’utilisateur et le mot de passe.



• 1 : Le champ Utilisateur contient le nom d’utilisateur fournit par l’administrateur système ainsi que le mot de passe.

• 2 : L’activation journalière permet à l’administrateur de récupérer les journaux détaillés à la fin d’un dépannage.

• 3 : L’option masquer en version réduite fait disparaître de la barre d’outils le bouton du logiciel Cisco IP Communicator et crée une icône dans la barre d’état.
• 4 : Lorsque cette option est activée, l’application s’affiche en premier plan lors d’un appel, si elle est désactivée seule la sonnerie et une fenêtre de notification permettront d’indiquer l’arrivée d’un appel.

• 5 : En activant cette case, la fenêtre de notification ne s’ouvrira pas lors de la réception d’un appel.


Le second onglet permet d’indiquer la carte réseau ainsi que l’adresse du serveur TFTP. Par défaut la carte filaire est employée. Le DHCP va envoyer l’option 150 qui contient l’adresse IP du serveur TFTP aux clients, néanmoins il est possible de le paramétrer manuellement. L’adresse TFTP correspond à l’adresse IP du routeur CME.



• 1 : Spécifie le périphérique réseau à employer (de préférence une connexion filaire ininterrompue).

• 2 : Indique le nom du périphérique afin de s’identifier sur le réseau.

• 3 : Ce champ permet de définir les serveurs TFTP spécifiques à joindre, ou de laisser la configuration DHCP le gérer automatiquement.


L’onglet audio spécifie les périphériques audio employés, et offre deux options de configuration : l’adresse IP et le port pour Cisco IP Communicator pour le premier bouton, et la qualité d’échantillonnage du son dans un second bouton.




• 1 : En fonction des périphériques connectés à l’ordinateur, divers modes sont disponibles : combiné, haut parleur et casque USB.

• 2 : Spécifie le périphérique à employer pour la sonnerie de Cisco IP Communicator.

• 3 : Ouvre la fenêtre des Paramètres audio réseau.

• 4 : Ouvre la fenêtre des Paramètres audio avancés.

• 5 : Cette case s’active lorsqu’on travaille depuis un accès VPN pour éviter le son robotisé ou lorsque la bande passante est restreinte.


La fenêtre des paramètres audio réseau :



• 1 : La zone supérieure indique l’adresse IP ou l’interface à employer

• 2 : Les ports employés pour la communication peuvent être modifiés en indiquant la plage de ports.





Les paramètres audio avancés :



• 1 : Défini à quel mode audio appliquer un filtre (combiné, haut parleur, casque USB).

• 2 : Applique un filtre de conversation qui améliore la voix de l’IP Communicator ou applique un filtre d’écoute à un interlocuteur distant qui va également modifier sa voix.

• 3 : Case à cocher si le volume des appels provenant de l’extérieur de CME est plus élevé que le volume des appels locaux.

• 4 : Bouton OK qui permet d’appliquer les filtres pour le mode audio spécifié.

• 5 : Bouton appliquer à tous, qui va appliquer les paramètres de filtrage à l’ensemble des modes.

• 6 : Supprime les silences.

• 7 : Pour déterminer la plus faible latence il faudra tester les périphériques audio en appel avec chaque paramètre de la liste déroulante : supérieures, très bonnes, bonnes.


Les paramètres de répertoire :



Si la fonction de recherche rapide ne fonctionne pas nativement, il faudra entrer un nom d’utilisateur et le mot de passe associé pour avoir l’accès à la recherche de contacts. Tester la fonction recherche rapide avant d’entrer les paramètres de comptes dans l’onglet répertoire.
4. Interface de Cisco IP Communicator

Dans les parties suivantes nous verrons les différentes fonctionnalités de l’IP phones ainsi qu’une description des divers boutons.

4.1. Fonctionnalités d’appel

De nombreuses fonctionnalités sont déjà présentes dans le Cisco IP communicator. Mais cela ne s’arrête pas là, le fait de pouvoir mettre à jour le firmware permet de rajouter les nouvelles fonctions disponibles.

• la numérotation rapide configurable : Permet d’enregistrer sur les touches d’accès rapide les numéros de téléphone les plus utilisés (point 3 sur le schéma ci-dessous).



• l’affichage du nom et du numéro de l’appelant : Permet d’afficher sur l’écran le nom et/ou l’identifiant de l’appelant ainsi que son numéro de téléphone.

• le signal d'appel : Permet une meilleure gestion des appels. En effet lors d’un appel si une deuxième personne essaie de vous joindre un signal sonore ce fera entendre pour que vous puissiez choisir entre continuer votre conversation ou la mettre en attente pour prendre l’appel.

• le renvoi automatique : Permet lors d’un déplacement de faire suivre les appels. Lors de l’activation de cette fonction il est possible de choisir un numéro vers lequel transférer tous les appels entrants.

• le transfert d'appel : Permet de rediriger un appel entrant vers un autre numéro. A la différence du renvoi automatique vous pouvez choisir de prendre l’appel et d’effectuer le transfert en cour de conversation (par exemple une standardiste peut prendre un appel entrant, présenter l’entreprise et ensuite rediriger l’appel vers la personne désirée)
.
• l’appel à trois (conférence téléphonique) : Comme son nom l’indique cette fonction permet de faire des conférences téléphoniques à trois personnes.

• la mise en garde : Permet de mettre en attente une conversation avec la possibilité pour n’importe quel utilisateur de reprendre la communication.

• la numérotation du dernier appel composé : Permet de gérer un historique d’appel afin d’avoir la possibilité de rappeler un numéro composé régulièrement.

• la mise en attente : Permet de mettre en attente une conversation avec possibilité de reprise de la communication uniquement par la personne qui a mis en attente

4.2. Description de l’interface de l’IP phone



1) Affichage principal avec sur certains modèles un écran tactile : Permet d'afficher l'état des appels et les menus de fonctions et d'activer des rubriques de menu.

2) Bouton de contrôle de la fenêtre : Permettent d'afficher le menu, de masquer l'interface de Cisco IP Communicator, de passer d'une apparence à l'autre ou de quitter l'application.

3) Boutons de lignes et boutons de numérotation abrégée : Chaque bouton permet d'ouvrir ou de fermer une ligne ou de composer un numéro abrégé. Raccourcis clavier : appuyez sur les touches Ctrl + 1 à 8 du clavier. Les boutons de ligne indiquent l'état des lignes :

Lumière verte fixe : appel actif sur cette ligne ou Lumière verte clignotante : appel mis en attente sur cette ligne.

Lumière orange clignotante : appel entrant en sonnerie sur cette ligne.

Lumière rouge : ligne partagée en cours d'utilisation.

Aucune couleur : aucune activité d'appel sur cette ligne (téléphone raccroché).

Vous pouvez transformer les boutons de ligne supplémentaires en boutons de numérotation abrégée.

4) Bouton messages : Compose généralement le numéro de votre service de messagerie vocale automatiquement (varie selon les services). Raccourci clavier : Ctrl + M.

5) Bouton répertoires : Ouvre ou ferme le menu Répertoires. Permet d'afficher les journaux d'appels et un répertoire d'entreprise, et de composer des numéros à partir de ceux-ci. Raccourci clavier : Ctrl + D. Vous pouvez également utiliser la fonction Recherche rapide (Alt + K) pour effectuer une recherche dans des répertoires.

6) Bouton d’aide : Active le menu Aide. Raccourci clavier : Ctrl + I.

7) Bouton paramètres : Ouvre ou ferme le menu Paramètres. Permet de définir l'apparence de l'écran du téléphone et les sonneries. Raccourci clavier : Ctrl + S.

8) Bouton services : Ouvre ou ferme le menu Services. Raccourci clavier : Ctrl + R.

9) Bouton volume : Permet de définir le volume des modes audio et d'autres paramètres. Raccourci clavier : Page préc./Page suiv.

10) Bouton haut-parleur : Permet d'activer/de désactiver le mode Haut-parleur. Raccourci clavier : Ctrl + P

11) Bouton secret : Active/Désactive la fonction Secret. Raccourci clavier : Ctrl + T.

12) Bouton casque : Permet d'activer/de désactiver le mode Casque. Raccourci clavier : Ctrl + H.

13) Bouton navigation : Permet de faire défiler les menus et de mettre les rubriques de menu en surbrillance. À utiliser avec les touches dynamiques pour activer les rubriques mises en surbrillance. Par ailleurs, lorsque Cisco IP Communicator est raccroché, cliquez sur le bouton Navigation pour accéder aux numéros de téléphone figurant dans votre journal des appels composés.

14) Bouton lancer vidéo : Permet de lancer Cisco Unified Video Advantage. Vous devez exécuter Cisco Unified Video Advantage version 2.0 et Cisco IP Communicator version 2.0 sur le même PC pour utiliser cette fonctionnalité.

15) Clavier de numérotation : Permet d'entrer des chiffres et des lettres et de sélectionner des rubriques de menu. Non disponible avec l'apparence compacte. Vous pouvez également utiliser le clavier de l'ordinateur.

16) Boutons de touche dynamique : Chaque bouton permet d'activer une touche dynamique. Vous pouvez également cliquer sur les libellés de touche dynamique (au lieu des boutons). Raccourcis clavier : F2 - F6.

Indicateur de message vocal et de sonnerie : Indique un appel entrant et un nouveau message vocal.








4.3. Etablissement d’un appel

4.3.1. Quelles sont les étapes ?





















Les étapes décrivent de façon logique la connexion entre deux terminaux ; comme des passerelles, des routeurs, Cisco CallManagers, ou des téléphones.
Les appels sont centralisés autour des routeurs. Quand un appel entrant arrive sur un routeur, il est traité séparément jusqu'à ce que la destination ne soit décidée. Dès que la destination est connue, un appel sortant est établie et l'appel entrant d’origine est commutée vers le bon port de voix sortant.


4.3.2. Appel point à point



Un appel est segmenté en partie d'appel et les routeurs associent chaque partie entre elles. Voici le processus d’établissement d’un appel :

1. Un appel provenant du service téléphonique traditionnel (RTC) arrive sur R1, une correspondance d’appel entrant depuis le RTC est détectée sur un port d’entrée.

2. Après l'association de l'appel entrant avec la correspondance sur R1, une connexion entrante est crée ; on lui assigne un ID d’appel (Call Leg 1).


3. R1 utilise le numéro composée pour trouver un port sortie sur un réseau de voix sortant. (Similaire à une table de routage).

4. Après l'association du numéro composée avec un réseau de voix sortant, R1 crée une connexion sortante et assigne un ID d’appel (Call Leg 2).


5. La demande d'appel parvient à R2 et une correspondance entrante est détectée pour cette destination.

6. Après l’association entre l’appel entrant et la correspondance sur R2, le routeur crée la connexion entre ces deux parties (Call Leg 3). À ce stade, R1 et R2 négocient les paramètres et les options du réseau de voix, si nécessaire.


7. R2 utilise le numéro composée pour trouver une correspondre sortante sur le réseau de téléphonique classique (RTC).

8. Après la correspondre sortante trouvée, R2 crée une connexion sortante sur le RTC, assigne un ID d’appel et termine l'appel (Call Leg 4).



4.4. Plan de numérotation (Dial plan)

4.4.1. Dial plan évolutif


Au quotidien, beaucoup de personnes utilisent des plans de numérotations sans vraiment le savoir. Sur le réseau public de téléphone (RTC), nous utilisons des règles et des modèles de numérotation lorsqu’on veut atteindre un correspond.

Beaucoup d’information sont présentes dans les numéros, nous pouvoir les déduire simplement en les analysants :

01 53 35 97 00 Téléphone fixe, situé en Ile de France
+ 33 6 00 00 00 00 Téléphone portable, situé en France
00 1 514 207 0000 Téléphone portable, dans la région de Montréal (http://www.cnac.ca)


Un plan numérotation est un ensemble de règles qui vont régir la commutation des appels. Pour chaque formats de numéro, les appels emprunteront des chemins que nous avons définit.

Réalisez un plan de numérotation exigent la connaissance complète de la topologie et des besoins d’un client : les numéros actuellement utilisés, les opérateurs utilisés pour chaque destinations, pour chaque services, les accès interne, externe, …
Si l’entreprise utilise un plan pour un réseau de voix interne privé qui n’est pas connecté à un réseau externe, les numéros peuvent alors être de n’importe quelle forme.

Grâce au plan de numérotation, nous pouvons rediriger les appels internes directement vers la destination, les appels nationaux vers un opérateur VoIP, les appels internationaux vers un autre opérateur. Typiquement les sociétés qui mettent en œuvre des réseaux VoIP dirigent le trafic de voix vers les opérateurs les moins chers. L'exécution de ce type de système implique que des appels commutent par des réseaux IP, des routes privées ou le RTC. Il faut donc veiller à toujours respecter les bons formats de numéro

Un plan doit être évolutif, facilement compréhensible par l’utilisateur, et transposable sur tous les équipements du système. L’utilisation de chemins alternatifs doit être pensée lors de la conception. Si nous utilisons les services d’opérateurs publics, nous devons respecter leurs normes et leurs formats de numéros. En France, c’est l’ARCEP qui définit ces règles de numérotation et c’est UIT-T pour les règles internationales.

4.4.2. Un plan de numérotation dans les règles de l’art

En concevant un plan de numérotation à grande échelle, vous devez respecter les cinq règles suivantes :

• Répartition logique : Une bonne architecture de plan compte sur une répartition logique et efficace des divers composants. Les dispositifs dédiés à une partie spécifique du plan contribuent à réduire la complexité de la configuration. Chaque composant se concentre sur une tâche spécifique. Généralement, le commutateur local ou la passerelle traitent les détails qui sont spécifiques au point local de présence (POP). Le niveau supérieur acheminant des décisions est composé de relais (gatekeepers) et de PBX. Un réseau bien conçu place la majorité de la logique du plan sur les relais (gatekeepers).

• Conception hiérarchique (adaptabilité) : Vous devez vous efforcer de garder la majorité de la logique du plan sur le composant le plus haut. Le maintien d'une conception hiérarchique rend l'ajout et la suppression de blocs de numéros plus facile. L’évolution du réseau est beaucoup plus simple à réaliser quand les changements de configuration ne sont à faire que sur un seul composant.

• Simplicité : Gardez le plan simple et symétrique lors de conception d’un réseau. Essayer de garder cohérent le plan de numérotation du réseau en utilisant des règles de traduction pour convertir les numéros interne vers les modèles de numérotation publiques. Ces modèles publiques étaient normalisées bien avant que la VoIP n'entre dans les entreprises. La mise en forme des numéros dans un format standard simplifie la gestion et la connexion avec les opérateurs.

• Limiter la latence d’appel : Il ne faut pas négliger la latence d’appel dans un réseau lorsqu’on utilise un plan de numérotation à grande échelle. La latence d’appel, c’est le délai d’attente entre le dernier chiffre composé et le moment où le téléphone à destination sonne. Avec le RTC, les personnes sont habituées à avoir la tonalité d’appel dans la seconde qui suit le dernier numéro composé. Plus il y aura de changements de format de numéro et d’équipements interrogés, plus le délai sera long. La grandeur du réseau, les règles de traduction et les chemins alternatifs affectent la latence. Vous devez vous efforcer d'utiliser ces paramètres pour réduire ce délai.

• Disponibilité et tolérance aux pannes : La disponibilité du réseau et le taux de réussites d'appel ne doit jamais être négligé quand vous concevez un plan de numérotation. La tolérance aux pannes et la redondance dans des réseaux VoIP sont extrêmement importants. En utilisant un chemin alternatif à la voix vous aidez à fournir la redondance et la tolérance aux pannes.



4.4.3. Plans de numérotation hiérarchiques


Des réseaux de téléphonie évolutifs exigent des plans de numérotations hiérarchiques. Une conception hiérarchique a les avantages suivants :

• Gestion des numéros simplifiée : Fournit la capacité d’ajouter facilement de nouveaux groupes de numéros et modifier des groupes existants
• Routage voix simplifié : Garde les communications internes local et utilise une clef de numéro (un préfixe, un indicatif) pour des appels longue distance. Il faut souvent faire le « 0 » pour sortir dans une entreprise, le reste des communications sont considérées comme locales.
• Résumé de numéro : Regroupe les numéros par secteur géographique spécifique. En France, on utilise les « 01 » pour l’Ile De France, le « 02 » pour le nord-ouest et ainsi de suite. Les résumés peuvent aussi ce faire par groupe fonctionnel, par exemple les 118 xxx pour représente les services d’annuaire.
• Evolutivité : Ajoute l'adaptabilité au plan de numérotation en ajoutant des groupes de numéro supplémentaires de haut niveau. « 0033 » représente la France pour le monde entier, l’ARCEP peut changer le plan de numérotation interne à la France comme elle le souhaite sans impacter les routages des autres pays, et inversement.
• Administration : La gestion des numéros et des groupes se fait via un point d’administration unique dans le cas d’une conception hiérarchique

Il n'est pas facile de concevoir un plan de numérotation hiérarchique. En prenant en compte l’existant dans le réseau (comme les PBX de marque déposée ou des services de téléphonie comme Centrex) et la nécessité de se conformer au format publique dès qu’on souhaite sortir, tour cela contribue à la complexité de la conception. Trouver le compromis entre ces systèmes est une tâche difficile. Si possible, évitez de changer les habitudes des utilisateurs, ils sont habitués à utiliser des plans de numérations. Le but est de concevoir un plan de numérotage qui a les attributs suivants :
• Impact minimal sur les systèmes existants
• Impact minimal sur les utilisateurs
• Eviter au maximum les translations de numéro (Changement de format)
• Prévoir une évolutivité
• Se conformer aux normes publiques


4.4.4. Intégration d’une numérotation interne et publique dans le plan

Les plans de numérotation varient énormément dans le monde entier. Des pays utilisent des longueurs de numéro différentes dans leurs frontières. Les fabricants d'équipement de téléphonie et des prestataires de services utilisent des numérotations non conformes à la norme. Dans une tentative de standardiser les plans de numérotation, l’UIT-T a développée l'E.164 qui définit les préfixes pour le monde entier.

L'intégration d’un plan de numérotation d'un système interne comme la VoIP en adéquation avec un système public exige une prudence. La structure hiérarchique du plan public et les problèmes associés aux longueurs de numéro dans des systèmes différents fait la complexité de l'intégration. Les défis de l'intégration de plan de numérotation incluent les choses suivantes :


Longueur variable des numéros : Lorsque que l’on sort de notre plan de numérotation (Lorsque l’on passe par un opérateur), vous devez manipuler les numéros pour les rendre conforme au format attendu.

Services spécialisés : Les services comme Centrex et leurs équivalents ont typiquement 4 ou 5 chiffres. La numérotation depuis le RTC vers un réseau VoIP privé ou vers un Centrex requière aussi une adaptation des numéros.

Messagerie vocale : Quand un appel n’abouti pas, le réseau devrait faire suivre l'appel vers la messagerie vocale. Puisque le système de messagerie vocale peut exiger un plan de numérotation complètement différent, la traduction peut être nécessaire.

Nécessité de préfixes ou indicatifs : Il peut être nécessaire d’enlever ou d’ajouter des indicatifs, préfixes. Les opérateurs français remplacent le premier « 0 » de nos numéros par « 0033 » lors des appels vers l’international.

Numérotation Internationale : Les codes de pays et des plans de numération varient dans selon les pays. La numérotation par un réseau IP à un autre pays exige une attention particulière pour la conception d’un plan.



Voici un exemple d’appel depuis le réseau public (RTC) destiné au 1-703-555-0123. La passerelle doit trouver la bonne destination, mais tous les terminaux finissent avec les mêmes chiffres. La passerelle doit-elle retirer les 5 premiers chiffres ? Les 6 ? Ou les 7 premiers ? C’est le plan de numérotation qui définira la règle.
Les variations de longueur représentent un vrai défi quand des plans privés se mêlent avec des plans de numéro publics. Les questions surgissent aussi quand personne ne répond à un numéro et est que l’appel est réexpédié vers un système de messagerie vocale.



4.5. Les classes de restriction (COR)


4.5.1. Introduction


Les classes de restriction (Class Of Restriction - COR) fournissent la capacité à la passerelle VoIP de filtrer les appels selon l’appelant ou l’appelé.
Les COR sont utilisés pour spécifier les autorisations entre les appels entrant et sortant au niveau de la passerelle VoIP. Cette fonction nous permet une souplesse dans le design d’un réseau de VoIP. Par exemple, nous pouvons interdire à une catégorie de personne les appels internationaux, ou les appels vers les téléphones portables ou simplement les appels extérieurs.

Les classes entrantes sont utilisées pour contrôler l’initiation des appels. Les classes sortantes décrivent les conditions pour un appel entrant à atteindre sa destination.
Si la restriction appliquée sur le port d’entré de la passerelle VoIP est supérieur ou égal à la restriction qui est appliquée en sortie, l’appel passera. Les classes entrantes sont prioritaires par rapport aux classes sortantes sur une même passerelle.

Les règles d’une classe de restriction entrante sont équivalentes à des clefs. Ces clefs seront utilisées pour ouvrir les classes qui sont appliquées pour le format de numéro composé. Pour filtrer des destinations avec une classe sortante, la classe de restriction entrante doit posséder autant de règles (les clefs) que la classe sortante a de restriction (les verrous).
Si aucune classe entrante n’est configurée sur un port, les appels depuis ce port ne seront jamais filtrés, même si une classe sortante est configurée. Cela revient à avoir une clé pour toutes les serrures. Le manque d'une classe sortante sur un port permet à n'importe quel utilisateur d’atteindre ce port.


COR entrante COR sortante Résultat Raison
Aucune Aucune Appel réussit Aucune restriction appliquée
Aucune Classe sortante appliquée Appel réussit Le manque de la classe entrante donne toutes les « clés » pour la classe sortante
Classe entrante appliquée Aucune Appel réussit La classe entrante permet de passer la classe sortante car elle est inexistante
Classe entrante en accord avec la classe sortante Classe sortante appliquée Appel réussit La classe entrante permet de passer la classe sortante car elles sont concordantes
Class entrante sans rapport avec la classe sortante Classe sortante appliquée Echec La classe entrante ne permet pas de passer car elle ne donne pas les bonnes « clés »

Par défaut, la classe entrante a la priorité COR la plus haute et la sortante a la priorité la plus basse. Cela signifie que s'il n'y a aucune configuration COR entrante sur un port, vous pouvez passer un appel via ce port sans restrictions et sans tenir compte de la configuration COR sur le port sortant.

4.5.2. Configuration

La configuration des classes de restriction se fait en 5 étapes

4.5.2.1. Etape 1 : Déclaration des noms de classes


RouterCEM#(config)#dial-peer cor custom
Utiliser pour entrer dans le mode de déclaration des noms des classes de restriction. La déclaration des noms est obligatoire. Nous ne pouvons déclarer et donc utiliser qu’au maximum 64 noms de classes.

RouterCEM#(config-dp-cor)#name Nom-de-la-classe
Déclaration des noms. Pour chaque classe déclarée, le routeur va créer un verrou et sa clé qui va avec. La clé et le verrou seront accessibles par le nom de la classe.


Exemple :

RouterCEM#(config)#dial-peer cor custom
RouterCEM#(config-dp-cor)#name 112
RouterCEM#(config-dp-cor)#name local
RouterCEM#(config-dp-cor)#name long_distance
RouterCEM#(config-dp-cor)#name international


4.5.2.2. Etape 2 : Création des listes de classes entrantes

C’est à cette étape que nous regroupons les clés par listes de restrictions. C’est ces listes que nous appliquerons sur les ports où sont les téléphones. Chaque appel qui passera par ces ports obtiendra les clés. Ces clés lui permettront de passer les listes de restrictions de sortie, ou pas.

RouterCEM#(config)#dial-peer cor liste Nom-de-la-liste
Création de la liste qui contiendra les clés

RouterCEM#(config-dp-cor)#member Nom-de-la-classe
On ajoute les clés en donnant le nom de la classe.

Exemple :

RouterCEM#(config)#dial-peer cor list Lobby
RouterCEM#(config-dp-cor)#member 911
RouterCEM#(config)#dial-peer cor list Employee
RouterCEM#(config-dp-cor)#member 911
RouterCEM#(config-dp-cor)#member local
RouterCEM#(config)#dial-peer cor list Sales
RouterCEM#(config-dp-cor)#member 911
RouterCEM#(config-dp-cor)#member local
RouterCEM#(config-dp-cor)#member long_distance
RouterCEM#(config)#dial-peer cor list Executive
RouterCEM#(config-dp-cor)#member 911
RouterCEM#(config-dp-cor)#member local
RouterCEM#(config-dp-cor)#member long_distance
RouterCEM#(config-dp-cor)#member international

La liste « Lobby », n’obtient que la clé pour les urgences alors que la liste « Executive » obtient toutes les clés.

4.5.2.3. Etape 3 : Création des listes de classes sortantes

Nous allons ici créer les listes contenant les verrous. Pour passer, il faudra avoir la clé.
Les commandes sont qu’a l’étape précédente.

Exemple :

RouterCEM#(config)#dial-peer cor list call911
RouterCEM#(config-dp-cor)#member 911
RouterCEM#(config)#dial-peer cor list callLocal
RouterCEM#(config-dp-cor)#member local
RouterCEM#(config)#dial-peer cor list callLD
RouterCEM#(config-dp-cor)#member long_distance
RouterCEM#(config)#dial-peer cor list callInt
RouterCEM#(config-dp-cor)#member international

4.5.2.4. Etape 4 : Application des listes de classes entrantes

Selon l’appelant, nous allons lui assigner une liste qui contiendra toutes ces clés. Nous identifions l’appelant via son numéro.


CMERouter(config)#ephone-dn ID

Entre dans le mode de configuration d’un ephone

CMERouter(config-ephone-dn)#number Numéro

Spécifie l’extension de l’ephone sur lequel la règle s’applique

CMERouter(config-ephone-dn)#cor incoming Nom-de-la-liste

Applique la liste de classe entrante (Les clés) sur cette ephone.

Exemple :

CMERouter(config)#ephone-dn 1
CMERouter(config-ephone-dn)#number 1001
CMERouter(config-ephone-dn)#cor incoming Lobby
CMERouter(config)#ephone-dn 2
CMERouter(config-ephone-dn)#number 1002
CMERouter(config-ephone-dn)#cor incoming Employee
CMERouter(config)#ephone-dn 3
CMERouter(config-ephone-dn)#number 1003
CMERouter(config-ephone-dn)#cor incoming Sales
CMERouter(config)#ephone-dn 4
CMERouter(config-ephone-dn)#number 1004
CMERouter(config-ephone-dn)#cor incoming Executive


4.5.2.5. Etape 5 : Application des listes de classes sortantes

Cette dernière étape nous permet d’appliquer les verrous selon les destinations. Nous utilisons le numéro composé pour trouver la destination.

CMERouter(config)#dial-peer voice ID pots

Entre dans le mode de configuration

CMERouter(config-dial-peer)#destination-pattern Numéro

Définit pour quel numéro de destination les verrous s’appliquer

CMERouter(config-dial-peer)#port Port-de-sortie

Définit pour que port de sortie les verrous d’applique

CMERouter(config-dial-peer)#corlistoutgoing Nom-de-la-liste

Applique la liste des restrictions (Les verrous)

Exemple :

CMERouter(config)#CMERouter(config)#dial-peer voice 1 pots
CMERouter(config-dial-peer)#destination-pattern 911
CMERouter(config-dial-peer)#port 1/0/0
CMERouter(config-dial-peer)#corlistoutgoing call911
CMERouter(config)#CMERouter(config)#dial-peer voice 2 pots
CMERouter(config-dial-peer)#destination-pattern 1[2-9]..[2-9]..
CMERouter(config-dial-peer)#port 1/0/0
CMERouter(config-dial-peer)#corlistoutgoing callLD
CMERouter(config)#CMERouter(config)#dial-peer voice 3 pots
CMERouter(config-dial-peer)#destination-pattern [2-9]..
CMERouter(config-dial-peer)#port 1/0/0
CMERouter(config-dial-peer)#corlistoutgoing callLocal
CMERouter(config)#CMERouter(config)#dial-peer voice 5 pots
CMERouter(config-dial-peer)#destination-pattern 1011T
CMERouter(config-dial-peer)#port 1/0/0
CMERouter(config-dial-peer)# corlistoutgoing callInt

5. Configuration de Cisco CallManager Express


5.1. CME, Options, Fonctionnements et Paramètres

5.1.1. Généralités

Cisco CallManager Express (CME) est une solution de gestion d’appels basée sur des routeurs Cisco qui offrent des services téléphoniques pour environ 300 utilisateurs.

Cisco CME constitue une partie de la solution de communication IP de Cisco et fonctionne conjointement avec les produits Cisco Systems, incluant des routeurs, des commutateurs, passerelles (gateways), des portails (gatekeepers) qui traduisent un numéro de téléphone en une adresse IP dans une solution H.323, un service de messagerie (Cisco Unity voice mail), des adaptateurs ATA (Analog Terminal Adapters), ainsi qu’un accès au réseau téléphonie publique commuté (PSTN : Public Telephone Switched Network).

Cisco CME supporte jusqu’à 120 téléphones IP, et offre de nombreux services et avantages de la téléphonie IP sans les coûts élevés et la complexité de déploiement d’une solution basée sur des serveurs. Cette solution se base sur un logiciel Cisco CME utilisant l’IOS Cisco installé sur les routeurs.

Les routeurs devront être préalablement équipés d’un IOS 12.3(7)T IP-Voice au minimum afin de pouvoir gérer l’application CME présente sous forme d’un package à télécharger sur la mémoire flash du routeur. Le package comporte entre autre le logiciel CME, des firmwares pour les Ip Phone, ainsi que d’autres fichiers.








5.1.2. Mode de fonctionnement de CME

Le système Cisco CME offre des fonctionnalités de PBX (autocommutateur) ainsi que d’autres fonctionnalités propres aux téléphones IP. Tout est centralisé sur un routeur Cisco CME, qui contrôle l’ensemble des appels émis et reçus.

Les téléphones IP vont s’enregistrer auprès du Cisco CME au démarrage, afin de pouvoir commencer à recevoir ou émettre des appels. Les téléphones IP et le CME communiquent entre eux à l’aide du protocole SCCP (Skinny Client Control Protocol).

Lorsqu’un appel est émis d’un téléphone IP à un autre, il passe obligatoirement par une phase de contrôle de CME, le protocole SCCP est alors employé. Le protocole SCCP n’effectue pas la transmission d’un téléphone à un autre directement, mais entre un téléphone IP et le système CME. Une fois l’appel accepté, le protocole RTP (Realtime Transport Procotol) prend le relais et transmets la voix dans les paquets IP en UDP.





Si le système Cisco CME a besoin d’effectuer un appel vers un IP Phone géré par un autre CME, le protocole H.323 interviendra pour faire la liaison entre les deux CME.

La fonction de passerelle PSTN (Public Switched Telephone Network) peut être activée sur le routeur CME, ou sur des passerelles distinctes, dans ce cas, la fonction IP-to-IP devra être activée afin de permettre la translation entre le protocole H.323 et SIP.



5.1.3. Les protocoles de communication




CME utilise les protocoles SCCP et H.323 pour contrôler les téléphones analogiques et IP, ainsi que les fax.


5.1.3.1. Le protocole SCCP (Skinny Client Control Protocol)

SCCP est un protocole propriétaire Cisco employé pour les communications en temps réel ainsi que les conférences.
Les avantages du protocole SCCP reposent sur ses faibles besoins en mémoire et charge processeur. Le protocole peut être employé dans le cadre d’un LAN sécurisé, avec une qualité de bande passante suffisante.

Un des inconvénients de SCCP est la gestion de la QoS ainsi que celle de la bande passante qui ne sont pas prises en compte par le protocole. De même, le protocole CRTP (Compressed Real-time Transport Protocol) n’est pas supporté. SCCP a ses limites et ne permet pas non plus d’authentifier des utilisateurs distants, hors du LAN de CME.



Malgré l’emploi d’une connexion VPN, le protocole SCCP reste incapable de gérer les utilisateurs distants. Chaque site doit posséder un routeur Cisco CME pour authentifier localement les téléphones IP. Le fonctionnement au travers du WAN entre plusieurs routeurs CME s’effectue alors par le biais du protocole H.323.



5.1.3.2. Le protocole H.323

Le protocole H.323 est employé pour la transmission de flux audio, vidéo et data sur un réseau IP. Ce protocole est une extension du protocole ITU H.320.



L’adaptateur ATA doit être configuré avec H.323 lorsque les fax sont connectés au port analogique, ou lorsque deux CME communiquent entre eux.


Le système CME peut être configuré pour authentifier les utilisateurs avec un gatekeeper H.323. Les IP Phones doivent avoir défini un numéro d’extension ou E.164 (à 10 chiffres), et un de ces deux numéros doit être enregistré auprès du gatekeeper H.323. Celui-ci sera obligatoirement un routeur distinct des routeurs implémentant CME.





5.1.3.3. Le protocole SIP

SIP a été crée en tant que protocole multimédia pour des visioconférences et des applications de messagerie instantanée, et tire avantage de l’architecture des messages envoyés par les applications Internet. C’est un des protocoles VoIP émergeant, qui se base sur des URL pour l’adressage, mais utilise également les serveurs DNS, et TRIP (Telephony Routing over IP) pour la gestion de services et le routage d’appels.



SIP permet une communication entre deux systèmes CME mais l’inter opérabilité du système peut être remise en cause en raison de problèmes compatibilité entre les différents constructeurs, c’est pourquoi H.323 reste encore une référence actuellement sur les routeurs Cisco CME.


5.1.4. Les VLAN dans CME

5.1.4.1. La séparation des flux

Un des principes de base en VoIP est le transport de la voix et des données sur un même média, la séparation des flux va donc s’effectuer au niveau des VLANs : un VLAN VOICE pour la voix, et un VLAN DATA pour les données. A noter que le VLAN 1 est présent de base en tant que VLAN d’administration. Il faudra donc créer sur notre routeur 2 VLANs.

Les Cisco IP Phones peuvent être considérés comme des commutateurs 3 ports, et tout comme les commutateurs ils supportent le trunking entre l’IP Phone et un autre commutateur. Cette fonction permet de faire passer plusieurs VLAN entre le commutateur et l’IP Phone.

Les trois ports de l’IP Phone permettent une connexion en 10/100 Ethernet vers le commutateur, une connexion 10/100 Ethernet vers un ordinateur, et un port interne par lequel transite le flux audio.
Le port 10/100 Ethernet relié au commutateur emploi le protocole 802.1Q (trunking) afin de relier l’IP Phone au VLAN voix (également appelé auxiliary VLAN), et de l’autre côté le VLAN data qui ressort vers l’ordinateur.



Le schéma 1 représente un téléphone IP relié d’un côté à un commutateur LAN, de l’autre à un ordinateur, les adresses IP du téléphone IP et de l’ordinateur sont sur le même sous-réseau.
Le schéma 2 montre un téléphone IP sur un sous-réseau différent de l’ordinateur, cette configuration est préférable afin d’appliquer sur le VLAN voix des procédures de QoS VoIP, différentes d’un réseau LAN classique.

Une autre architecture est également possible, mais nécessite le double de prise sur le commutateur LAN pour un ordinateur de bureau et son téléphone IP. La solution précédente sera donc préférable, étant donné que l’IP Phone dispose de deux ports sur son boitier.




Les paquets provenant des IP Phones transitent donc sur un VLAN différent des paquets data. Cette séparation permet de simplifier le processus de déploiement des IP Phones, qui vont démarrer et être affectés automatiquement au VLAN auxiliaire. Les IP Phones vont communiquer avec le commutateur via le protocole CDP au démarrage, qui va leur fournir une configuration de VLAN ID appelée Voice VLAN ID (VVID). De même, le PVID (Port VLAN ID) va déterminer le VLAN data.



Un port correspond à deux VLAN : Voice pour l’IP Phone et Native pour le PC


5.1.4.2. Configuration de VLAN

Deux VLAN seront nécessaire pour le fonctionnement de l’IP Phone et de l’ordinateur qui lui est relié, un VLAN VOICE et un VLAN DATA. Le trunking sera donc obligatoire, pour permettre la circulation des informations de ces deux VLAN entre l’IP Phone et le commutateur.

Les commandes sont identiques à celles d’une configuration classique de VLAN d’un commutateur Catalyst, à l’exception de la création d’un VLAN VOICE.

• Switch(config-if)#switchport voice vlan {number}
o Mode de configuration d’interface
o Permet d’assigner le port au VLAN pour le flux voix



L’access VLAN est employé entre l’ordinateur et le réseau, et le voice VLAN est utilisé par l’IP Phone pour communiquer un flux audio. Ne pas oublier le VLAN natif, qui par défaut est VLAN 1, où se trouvent les postes qui n’ont pas reçu de VLAN spécifique.



Le routage inter-VLAN s’effectue au niveau de la couche 3, et nécessite donc un routeur pour faire la liaison. Les IP-Phones se retrouvent dans un VLAN Voice, et les ordinateurs dans un VLAN Data. Le routeur aura une sous-interface par VLAN, et le mode trunking sera appliqué au port le reliant au commutateur.

5.1.5. Configuration des paramètres DHCP Spécifiques


• Router(dhcp-config)# option {option-number} ip {IP-address}
o Mode de configuration DHCP
o Défini la valeur d’une option spécifique de DHCP



L’option 150 correspond à l’adresse IP du serveur TFTP, en l’occurrence dans le cas de CME, à l’adresse IP de l’interface du routeur Cisco implémentant CME. Ne pas oublier d’exclure de la plage DHCP l’adresse IP de l’interface du routeur (dhcp excluded-address), d’indiquer une passerelle par défaut (default-router) ainsi qu’un serveur dns (dns-server) au minimum.


5.1.6. Restriction

Call manager ne gère que les utilisateurs appartenants au LAN de CME, il est donc impossible pour des clients SCCP de liens WAN de se connecter au CME pour s’authentifier. De plus, les codecs supportés sont G.711 et G.729, sachant que les conférences téléphoniques ne gèrent que le codec 711.

6. Enregistrement d’un téléphone IP sur CME


6.1. Généralités

La procédure de mise en place d’un téléphone IP est complètement différente d’un téléphone classique, le téléphone IP se comporte comme un ordinateur qui se connecte à un réseau IP.

L’équipement peut être alimenté à l’aide de la technologie Power over Ethernet (PoE) qui permet d’envoyer dans un câble réseau un courant suffisant pour le bon fonctionnement du téléphone.

Lorsque le téléphone IP est alimenté en courant, il va effectuer une demande DHCP afin de recevoir les options de connexion comme n’importe quel ordinateur. Parmi les informations DHCP, une ligne concerne l’adresse du serveur TFTP. Le routeur Cisco CME servira de serveur TFTP pour mettre à disposition les divers firmwares des téléphones IP, contenus dans la mémoire flash du routeur, à l’aide de la commande tftp-server flash:[firmware-file-name].

6.2. Procédure d’enregistrement

Le processus se découpe en plusieurs étapes :

Etape 1 : Le commutateur envoi une tonalité spéciale appelée “Fast Link Pulse” (FLP) depuis son interface. Ce FLP sera transmit au Powered Device (PD) représenté en l’occurrence par un téléphone IP.

Etape 2 : Lorsque le Powered Device n’est pas alimenté, il crée un lien entre son interface d’entrée et de sortie, créant ainsi une boucle et permet de renvoyer le FLP vers le commutateur, ce qui n’arriverait pas si un autre équipement qu’un Powered Device était connecté au commutateur, tel qu’un PC par exemple. Au final, si le FLP ne revient pas vers le commutateur aucun courant ne sera envoyé sur cette interface.

Etape 3 : Après retour du FLP, le commutateur va donc envoyer le courant à la ligne.

Etape 4 : La ligne s’active en 5 secondes « link up ».

Etape 5 : Le téléphone IP démarre.

Etape 6 : A l’aide du protocole Cisco Discovery Protocol (CDP), le téléphone IP annonce au commutateur la quantité de courant dont il a besoin.

Etape 7 : En utilisant CDP toujours, le commutateur va informer le téléphone IP des VLAN dédiés à la voix disponibles « auxiliary VLAN ».

Etape 8 : Le téléphone IP s’enregistre auprès d’un serveur DHCP à l’aide d’une requête DHCP-Discover en broadcast afin d’obtenir une adresse IP dans les VLANs de voix.

Etape 9 : Le serveur DHCP attribue les paramètres IP au téléphone, dont l’adresse du serveur TFTP (correspondant au routeur CallManager Express) par une requête DHCP-Offer.

Etape 10 : Le téléphone applique la configuration.

Etape 11 : Le téléphone se connecte au serveur TFTP et télécharge un fichier XML de configuration « SEP00112FD21239.cnf.xml » (00112FD21239 représente l’adresse MAC du téléphone IP). Ce fichier contient les informations pour l’enregistrement sur le Cisco CME, comme l’adresse IP, le port, la langue, et le firmware à charger sur le téléphone. Si le téléphone possède déjà le bon firmware, il sera enregistré et recevra la configuration.

A noter que le fichier SEP XML ne contient pas les numéros d’extension.

Etape 12 : Si le firmware est obsolète ou différent de celui spécifié, le téléphone va télécharger la bonne version depuis le serveur TFTP.

Etape 13 : Le téléphone IP va redémarrer après avoir téléchargé le firmware.

Etape 14 : S’il n’existe pas de fichier SEP XML avec l’adresse MAC de l’équipement, c’est qu’il s’agit d’un nouveau téléphone ajouté. Le téléphone ira télécharger depuis le serveur TFTP un fichier nommé XMLDefault.cnf.xml qui indique l’adresse IP, le numéro de port, et le firmware à utiliser par le téléphone. La procédure est ensuite identique à celle qui précède : téléchargement du firmware si besoin, puis redémarrage.

Etape 15 : Le téléphone s’enregistre avec le système Cisco CME en utilisant des messages de type SCCP. Si l’option « auto assign » est activée, le téléphone IP recevra automatiquement une extension par le système Cisco CME. Si « auto assign » n’est pas actif, le téléphone n’aura pas d’extension et sera incapable de recevoir ou d’envoyer des appels.

7. Ephone & ephone-dn


7.1. Généralités

Ephone : il s’agit d’un composant logiciel de configuration qui représente un téléphone IP physique. L’Ephone correspond dans le système CME à un port physique qui connecte un téléphone au système Cisco CME. L’Ephone permet de configurer le téléphone IP en utilisant l’IOS Cisco. Chaque Ephone peut avoir plusieurs numéros d’extension, ou numéros de téléphone (également appelés Ephone-dn). Le nombre maximum d’Ephone dans un système Cisco CME correspond au maximum d’interfaces physiques qui peuvent être connectées au système CME.

Ephone-dn : l’Ephone-dn représente la ligne qui connecte un canal voix vers un téléphone sur lequel un utilisateur peut recevoir et émettre des appels. Un Ephone-dn possède une ou plusieurs extensions ou numéro de téléphone associés. Un Ephone-dn représente un port voix virtuel dans le système Cisco CME, ainsi le nombre maximum d’Ephone-dn dans un système Cisco CME est le nombre maximum de connexion simultanées possibles (à noter que ce concept est différent du nombre maximum de lignes physiques dans un système de téléphonie classique, le nombre maximum de numéro téléphone ou d’extension qui peuvent être attribués ne dépend donc plus des lignes).

Exemple : sur une plateforme Cisco 2600XM le nombre maximum d’IP phone est de 36, et le nombre maximum d’Ephone-dn (ou port virtuels) est de 144. Pour comparaison, sur le modèle haut de gamme Cisco 3745 il peut y avoir jusque 120 IP phone connectés et 288 Ephone-dn. (http://www.cisco.com/univercd/cc/td/doc/product/access/ip_ph/ip_ks/cme31/cme31spc.htm)



L’Ephone peut être assimilé au poste téléphonique en lui-même, et l’Ephone-dn aux communications (ou boutons).

Les systèmes de téléphonie classique sont basés sur des connexions physiques et sont donc limités aux types de services téléphoniques qu’ils peuvent offrir. Etant donné que les Ephone et Ephone-dn sont des implémentations logicielles, et comme le flux voix est encapsulé dans des paquets transitant sur le réseau IP, le nombre de combinaisons de numéros et de lignes téléphoniques est presque infini.

Le système Cisco CME peut être architecturé de diverses manières, l’essentiel est de déterminer combien d’appels simultanés pourront être gérés sur le site, et sur chaque téléphone du site, ainsi que de connaître le nombre de numéros différents et le nombre de téléphones. Dans le cadre du design de réseau VoIP, divers critères sont à prendre en compte :

• Le nombre maximum d’Ephone-dns (correspond au nombre maximum d’appels simultanés qui peuvent être gérés)

• Le nombre maximum de numéros de téléphone

Le nombre maximum de boutons par téléphone (exemple, vous avez deux personnes avec des téléphones 6 boutons pour répondre à plus de 20 différents numéros de téléphone).

7.2. Ephone

7.2.1. Généralités

Un Ephone, ou Ethernet Phone est une représentation logicielle du support physique (téléphone IP) avec lequel un client peut recevoir ou émettre des appels dans un système Cisco CME.

L’Ephone physique est soit un Cisco IP Phone, soit un téléphone analogique équipé d’un adaptateur ATA (Analog Telephone Adaptator).

Chaque Ephone possède un « phone-tag » unique, ou un numéro de séquence pour être identifié. Le type de téléphone devra également être défini s’il existe un ou deux modules supplémentaires 7914, ou s’il s’agit d’adaptateur ATA 186 ou 188. Tous les autres types de téléphones seront détectés automatiquement par le système Cisco CME.

Les Ephone sont gérés par des Ephone-dn, et associent les adresses MAC des téléphones physiques aux numéros de téléphones ou d’extension correspondants aux Ephone-dn.


Extension 7914 pour IP-Phone.

7.2.2. Configuration

• Router(config)# ephone {phone-tag}
o Mode de configuration globale
o Crée une instance ephone et entre en mode de configuration.d’ephone

• Router(config-ephone)# mac-adress {mac-adress}
o Mode de configuration d’ephone
o Associe une adresse MAC à l’ephone

• Router(config-ephone)# button {button-number} {separator} {dn-tag}
o Mode de configuration d’ephone
o Assigne un numéro d’appel ephone-dn à un bouton de l’ephone
o Le {separator} correspond à un caractère unique qui défini les proriétés du bouton et du numéro d’extension :
• « : » : Sonnerie normale
• « b » : La sonnerie est coupée, mais le bip de call waiting est autorisé
• « f » : Sonnerie spéciale, pour différencier les appels d’une ligne par rapport à une autre. La sonnerie spéciale correspond à trois impulsions au lieu d’une impulsion pour les appels internes et de deux pour les appels externes
• « m » : Mode moniteur pour la shared-line qui indique quelles lignes sont utilisées ou non
• « o » : Plusieurs lignes Ephone-dn se partagent un bouton (10 lignes au maximum). Le champ dn-tag contient les dn-tag séparés par des virgules
• « s » : Sonnerie silencieuse, seul l’icône ((<>

Rock
Rock.raw


Macarena
Macarena.raw



Le champ DisplayName défini le nom de la sonnerie qui sera affiché sur l’IP Phone pour le fichier PCM associé.

Le champ FileName spécifie le nom du fichier audio PCM présent sur la mémoire flash du routeur.


10.4.5. Musique d’attente

La musique d’attente est un flux audio joué aux utilisateurs PSTN ou IP Phone qui sont placés en attente, afin de confirmer que la communication est toujours ouverte, mais placée en attente.

La musique de mise en attente n’est pas jouée aux utilisateurs locaux du système CME, qui auront eux une tonalité périodique leur indiquant que la communication est mise en attente.

Le flux audio de mise en attente provient de deux sources : un fichier audio ou une source en directe. Si les deux sont configurés le routeur va préférer la source en direct.

Le fichier audio de mise en attente est au format .au ou .wav dans la mémoire flash du routeur. Le flux en direct est généralement une ligne vers un jukebox CD. Un seul flux direct est supporté par routeur CME.

Le fichier de mise en attente présent dans la mémoire flash est configuré pour utiliser une adresse multicast de transmission.



• Router(config-telephony-service)# moh {filename}
o En mode de configuration de service téléphonie
o Spécifie le fichier audio de mise en attente à utiliser dans la flash

• Router(config-telephony-service)# multicast moh {ip-address} port {port-number} [route ip-address-list]
o Spécifie l’adresse ip multicast
o Le port à utiliser se situe dans une plage de 2000 à 65535. Le port 2000 est utilisé par défaut pour RTP et donc recommandé pour le flux audio multicast.
o L’option route indique les adresses des interfaces du routeur sur lesquelles les packets multicast vont transiter. Au total quatre adresses IP peuvent être listées séparées par un espace.

10.4.6. Affichage de l’IP Phone

L’écran de l’IP Phone permet d’afficher un certain nombre de zones de textes personnalisables.



• Router(config-ephone-dn)# description {display-text}
o En mode de configuration d’Ephone-dn
o Modifie l’affichage de la barre d’en-tête (Header Bar) de l’IP Phone

• Router(config-ephone-dn)# label {string}
o En mode de configuration d’Ephone-dn
o Configure un affichage de texte au lieu du numéro de la ligne téléphonique (label)

La zone de texte System Display Message permet de diffuser sur l’ensemble des IP Phones du système CME un message. Ce message est en caractères alphanumériques et contient uniquement du texte. Sa longueur varie suivant le modèle de l’IP Phone mais correspond approximativement à une trentaine de caractères. De manière générale c’est le nom de l’entreprise qui est affiché sur l’ensemble des IP Phones.

• Router(config-telephony-service)# system message {text-message}
o En mode de configuration des services de téléphonie
o Affiche un message sur l’ensemble des IP Phones

11. Qualité de Services (QOS)

11.1. Introduction : Qu’est ce que la Qualité de services

La qualité de service (Quality of service, QoS) n’a pas été réellement prise en compte lors de la conception initiale des réseaux IP. Le protocole IP, comme la majorité des autres technologies de transport de données en mode paquet, a été construit et optimisé pour transporter des fichiers de données, et non pas la voix ou la vidéo. Dans ce contexte, la seule « qualité de service » pertinente est de ne pas perdre ou corrompre les données transportées. Aujourd’hui les avancées spectaculaires des technologies réseaux rendant cependant possible le transport de données temps réel comme la voix ou la vidéo en utilisant le protocole IP. Il devient donc important de savoir contrôler et caractériser la qualité de service d’un réseau IP.

Principaux paramètres qui caractérisent la qualité de service d’un réseau de transport de données en mode paquet :
• la capacité disponible, aussi appelée « bande passante » (en pointe et en continue)
• le délai de transmission de bout en bout (latence), et la variation de ce délai (gigue)
• le taux de perte de paquet et le taux déséquencement (paquet plus ancien arrivant en premier)

A première vue, la bande passante est un sujet simple… Il suffit de prévoir assez de capacité pour qu’il n’y ait plus de problèmes ! En fait, il ne suffit pas de fournir une bande passante globale : un fournisseur de services doit également s’assurer qu’elle est répartie équitablement entre les utilisateurs du réseau. Ce n’est que très récemment que des techniques de partage « équitable ont été étudiées.

La latence est de loin le problème le plus difficile. On en tend d’ailleurs couvent que le protocole IP ne convient tout simplement pas au transport de données avec un délai de bout en bout contrôlé. Ce n’est pas vrai. Parekh et Gallager ont inventé en 1993 un e approche théorique très fructueuse, qui a conduit à la mise au point d’une série d’algorithmes de gestion de files d’attente pour assurer un partage équitable de la capacité, connus sous le nom générique de Weighted Fair Queuing (WFQ). Ces algorithmes, bien qu’ils soient difficiles à implémenter en pratique, permettent de garantir une borne supérieure au délai de transport de bout en bout de certains flux, et permettent aux réseaux IP d’offrir le même type de qualité de service que les réseaux de type ATM.

Le contrôle de la gigue est important principalement pour les applications temps réel qui nécessitent l’utilisation de mémoires tampons afin de restituer de manière irrégulière. Plus il y a de gigue, plus ces mémoires tampons doivent être importantes, et par conséquent plus elles introduisent des délais supplémentaires dans le flux d’information de bout en bout.

Le problème de perte de paquets est très lié au problème de la bande passante, ainsi qu’à l’utilisation appropriée d’algorithmes de contrôle de la congestion en bordure et dans le cœur de réseau. La perte d’un paquet se produit en effet généralement lorsqu’il y a une congestion sur un lien de transmission, qui provoque un débordement des mémoires tampons d’un routeur. Sur les connexions TCP, l’algorithme de Van Jacobson fait que toute perte de paquet réduit considérablement le débit de la connexion. La perte de plusieurs paquets consécutifs peut remettre la connexion TCP en mode de démarrage lent, ce qui réduira le débit de la connexion longtemps après l’arrêt de la congestion effective. Pour les connexions utilisant le protocole UDP, les pertes de paquets peuvent également causer des délais dans l’acheminement de l’information (au cas où un schéma d’acquittement et de retransmission a été mis en place, ou si une méthode de correction d’erreurs est utilisée), ou une dégradation de la qualité des flux média dans les applications pour lesquelles les pertes de paquets ne peuvent as être récupérées à cause des contraintes se délai de bout en bout.


Le dé encaissement des paquets est principalement influencé par la stabilité des routes du réseau et la qualité des algorithmes de gestion des files d’attente des routeurs lorsque plusieurs interfaces sont disponibles pour une même destination. Pour la plupart des applications, le déséquencement n’est pas un problème en soi car elles savent réordonner les paquets : il cause donc le même type de problème que la gigue.

La téléphonie n’est pas la seule application que pose de sévères contraintes à la qualité de service du réseau : les applications transactionnelles, interactives (comme les simulations et les jeux), et certaines encapsulations de protocoles (comme SNA dans IP) y sont très sensible également.


11.2. Principes de la QOS

La gestion de la QoS dans les matériels récents est une subtile combinaison de fonctions appliquées sur les paquets transitant dans ces matériels. Ces fonctions opèrent des changements de priorité, bloquent ou laissent passer certains paquets ou encore ordonnancent les paquets en sortie dans un ordre différent que celui d’entrée. Les fonctions que l’on retrouve communément sont synthétisées sur la Figure 1. L’ordre d’application de ces fonctions peut être divers.

Exemple :

• Classifier des paquets, puis leur appliquer une fonction de policing pour enfin les faire passer dans des files WFQ,

• Ou alors utiliser une fonction de policing pour marquer des paquets, les re-classifier selon des critères applicatifs, puis les faire passer dans un traffic shaper.




Figure1 Fonctions de QoS


L’implémentation de ces fonctions peut différer selon les constructeurs. Il est donc très important lors de la mise en place de QoS sur un type de matériel donné, de bien étudier et de bien comprendre le fonctionnement interne des fonctions proposées.

Le but de cet article n’est pas de faire une étude exhaustive de l’implémentation de QoS de chaque constructeur, et nous nous attacherons donc à ne présenter que l’implémentation Cisco. Cette approche peut en effet donner quelques points de référence sur ce qu’il est possible ou non de faire en terme d’implémentation de QoS (avec Cisco ou avec les autres constructeurs).

Par ailleurs, il ne serait pas raisonnable de rentrer dans les détails de chaque fonction, d’autant plus que certaines sont déjà connues (certains administrateurs ne soupçonnent pas qu’ils savent déjà faire de la QoS !) alors que d’autres sont plus secondaires.

En effet, reprenons chaque fonction :

• "Classifier" : rien de très nouveau ici, ce n'est ni plus ni moins que des listes de contrôle d'accès (ACL) et filtres plus ou moins évolués,"analyser et gérer la bande passante" : ce qu'il faut comprendre ici est le fonctionnement des algorithmes "du seau percé", du "marquage à trois couleurs et un débit" (Single rate three color marker, RFC26971), du "marquage à trois couleurs et deux débits" (Two rate three color marker, RFC26982) ainsi que le principe d'utilisation des champs TOS (Type Of Service) et DSCP (Differentiated Services Code Point). Tout ceci est assez aisé à appréhender.

• "Analyser et adapter la bande passante" : le point le plus important ici est le fonctionnement d'un traffic shaper et sa différence avec un policer. Une fois cette différence comprise, il n'y a plus de réelle difficulté.

• "Éviter la congestion" : le fonctionnement des algorithmes RED (Random Early Detection) et WRED (Weighted Random Early Detection) n'est pas forcément évident à comprendre, cependant l'intérêt de ces mécanismes peut paraître quelquefois secondaire au regard d'autres fonctions dont les résultats sont plus notables. Attention, nous ne dénigrons nullement ici l'intérêt de RED et WRED, nous disons juste qu'avant de les employer il y a certainement d'autres mécanismes à enclencher pour résoudre les problèmes de QoS posés, et c'est pourquoi nous les considérons comme "secondaires".

• "Gérer la congestion" : c'est là qu'est le vrai problème! Que doit-on faire quand un point de congestion apparaît ?
Quels mécanismes doivent être employés ? Quel est le fonctionnement de ce qui sera implémenté ? La gestion de la congestion se fait typiquement au travers de files d'attente dont l'utilisation suit un algorithme particulier (PQ, CQ, WFQ...). Malheureusement, l'étude et la comparaison de ces différents algorithmes ne sont pas souvent aisées, d'une part par le manque de documentation et de standard et d'autre part par le fait de la disponibilité assez récente de ces mécanismes.

Aussi nous nous attacherons dans les points suivants à détailler la "gestion de la congestion" au travers des différents algorithmes de gestion de files mis en œuvre dans les matériels Cisco. Nous commencerons par les mécanismes les plus anciens (et sans doute les moins performants) tels que PQ et CQ pour terminer avec les mécanismes les plus récents qui apportent un maximum de valeur ajoutée tels que WFQ, CBWFQ et CBWFQ+LLQ.

Un point très important à retenir tout au long de la lecture de cet article est que ces mécanismes ne sont enclenchés (si configurés par l'administrateur) par le matériel que lorsqu'il y a congestion. Ainsi, lorsqu'il n'y a pas de congestion, le matériel fonctionne dans un mode "normal" de gestion de files FIFO (First In/First Out). La détection de la congestion est donc un problème très important qui fait partie intégrante de la mise en place de QoS.

Dans la suite des points traitant de la gestion des files nous utiliserons le schéma suivant :


Figure 2 - Fonctionnement interne routeur

Nous distinguerons les buffers hardware d'entrée / sortie (rx-ring et tx-ring) des files gérées logiciellement par le système d'exploitation du routeur, ici l'IOS Cisco. D'autre part, l'ordonnancement des paquets vers où depuis les files peut être statique ou dynamique suivant les configurations et les algorithmes utilisés.


11.3. Mécanismes de la QOS

11.3.1. Gestion des files en mode QOS

La gestion des files en mode FIFO (First In/First Out) est illustrée par la Figure 3.

Dans ce mode de gestion, il n'existe qu'une seule file par interface de sortie. L'ordonnancement de cette file est de type FIFO (First In/First Out – premier arrivé, premier servi). A noter que si aucune QoS n'a été configurée sur le routeur, le mode FIFO est le fonctionnement par défaut de tout type d'interface, sauf pour les interfaces série (Serial).






Figure 3 : Gestion de files en mode FIFO


Les avantages sont les suivants :
• Simplicité, rapidité et faible coût au niveau de l'OS du routeur.

Par contre, il subsiste quelques inconvénients :
• Il n'existe qu'une seul priorité (puisqu'une seule file) qui, de plus, est statique.

• On ne peut pas dire qu'il y ait vraiment de priorités appliquées aux paquets dans ce mode, le mode FIFO ne fait pas de QoS !

• Point très important : le mode FIFO ne règle pas le problème des trains de paquets.

Ce dernier point est très important, et nous l'utiliserons systématiquement pour comparer les différentes solutions. Prenons l'exemple de deux trafics : un trafic FTP et un trafic telnet dont les caractéristiques respectives sont les suivantes :
• FTP : trafic continu (considéré comme intense/stressant), paquets de grande taille (≈ 1500),
• telnet : trafic transactionnel (avec des pauses), paquets de petite taille (≈ 64).

Dans ce cas de figure, on peut facilement imaginer que les paquets FTP vont monopoliser la file FIFO par rapport aux paquets telnet puisqu'il faudra transférer un ou plusieurs paquets FTP avant de pouvoir transférer un paquet telnet. Le résultat de ce scénario est un ralentissement significatif du transfert telnet et une perte totale de l'interactivité (qui n'a jamais ressenti cette sensation détestable d'un telnet "qui n'avance pas" ?). On peut dire que le train des paquets FTP "écrase" les paquets telnet et que la gestion FIFO ne permet pas d'intercaler (de réordonner par rapport à l'ordre d'arrivée) des paquets telnet au milieu de paquets FTP.





11.3.2. Gestion des files en mode PQ

La gestion des files en mode PQ (Priority Queuing) est illustrée par la Figure 4.



Figure 4 - Gestion de files en mode PQ


Dans ce mode de gestion, chaque interface de sortie a 4 files pour ordonnancer les paquets. Ces 4 files sont :

• Ordonnancées statiquement : c'est à l'administrateur de classifier les paquets en entrée du routeur pour les aiguiller dans une file donnée.

• Ordonnancées statiquement avec priorités absolues : les priorités sont dites "absolues" car la file 1 est moins prioritaire que la file 2, qui elle-même est moins prioritaire que la file 3 ... de plus l'algorithme exécuté pour servir les différentes files est le suivant :

• Tant qu'il y a des paquets dans la file "high" alors router le paquet, sinon passer à la file inférieure.
• Tant qu'il y a des paquets dans la file "medium" alors router le paquet, sinon passer à la file inférieure.
• Tant qu'il y a des paquets dans la file "normal" alors router le paquet, sinon passer à la file inférieure.

• Router le paquet dans la file "low", puis réitérer.

Avec le Priority Queuing on commence à avoir des possibilités de QoS intéressantes, avec les avantages suivants :
• Simplicité, rapidité et faible coût au niveau de l'OS du routeur.

• Les priorités absolues permettent de privilégier de manière absolue un trafic par rapport à un autre.

D'un autre côté on peut énumérer les inconvénients suivants :
• L'ordonnancement statique (classifier les paquets en entrée) n'est pas toujours facile à faire (quels trafics dans quelles files ?).

• Les priorités absolues et l'algorithme décrit ci-dessus peuvent causer des congestions artificielles dues à des problèmes de "famine" (ie. trop de paquets à ordonnancer dans la file "high").

• Il n'y a seulement que 4 niveaux de priorité, comment faire alors pour classifier plus de 4 classes de trafic ?

Le problème de famine cité ci-dessus mérite d'être expliqué plus en détail. Il se pose lorsque l'ordonnancement statique effectué par l'administrateur va aiguiller trop de paquets dans la file "high" (la priorité la plus grande) par rapport aux autres files. Dans ce cas, le routeur ne routera que les paquets de la file "high" en délaissant ceux des autres files, d'où la "famine" pour les autres files. Il faudra donc s'assurer de ne pas "faire trop passer" de paquets dans la file "high".

A noter qu'avec le Priority Queuing on peut résoudre notre précédent problème de trafic FTP / trafic telnet. Il suffit en effet de faire passer tout le trafic telnet dans une file plus prioritaire que le trafic FTP. Malheureusement cette solution pourra poser des problèmes si le trafic telnet devient trop important : en effet le trafic FTP risquerait de ne plus être servi... la solution n'est donc pas idéale.



11.3.3. Gestion des files en mode CQ


La gestion des files en mode CQ (Custom Queuing) est illustrée par la Figure 5.


Figure 5 - Gestion de files en mode CQ


L'intérêt majeur du Custom Queuing est la prise en compte de priorités en fonction d'une demande de bande passante garantie, de plus ce mode de fonctionnement reste simple et rapide.

Cependant le Custom Queuing hérite des inconvénients connus dans les précédents mécanismes, et en pose de nouveaux :

• L’ordonnancement statique (classifier les paquets en entrée) n'est pas toujours facile à faire : quels trafics dans quelles files ?

• Avec 16 files, comment faire pour bien répartir les trafics dans chaque file et comment répartir la bande passante ?

• La configuration nécessite de spécifier la taille en octet des files, résultant d'un calcul à partir de la taille moyenne des paquets passant dans une file et de la demande de bande passante pour cette file. Cette connaissance de la taille moyenne de paquets pour une file donnée n'est pas du tout évidente à obtenir dans certains contextes.

• Certains critiqueront la limitation de 16 files, mais n'est-ce déjà pas suffisant ? En fait ce qu'il faudrait plutôt critiquer c'est l'ordonnancement statique en entrée dans un nombre de files limité, alors que tout cela pourrait être dynamique.

• Pour finir, ce mode de fonctionnement commence à être coûteux au niveau de l'OS du routeur.

Reprenons notre problème de trafic FTP / trafic telnet. Contrairement au Priority Queuing, on peut configurer à l'aide du Custom Queuing deux files limitées en bande passante : une pour le trafic FTP et une pour le trafic telnet. Le problème étant de réussir à évaluer la bande passante à allouer à chaque trafic, tout en sachant que si le trafic change (taille moyenne des paquets), la configuration risque de ne plus être valable... la solution est un peu meilleur que précédemment mais n'est pas encore idéale car insuffisamment dynamique.




11.3.4. Gestion des files en mode WFQ


La gestion des files en mode WFQ (Weighted Fair Queuing ou Per-Flow Weighted Fair Queuing) est illustrée par la Figure 6.


Figure 6 - Gestion de files en mode WFQ


Le mode de gestion WFQ propose n+8 files d'attente sur chaque interface de sortie. Le paramètre n est fonction de la bande passante de l'interface et les 8 autres files sont réservées par Cisco pour ne pas mettre en concurrence certains flux avec ceux utilisateurs (nous reviendrons sur cette notion plus tard). A noter que le mode gestion WFQ est le fonctionnement par défaut des interfaces série (Serial).

L'ordonnancement des paquets dans les files est dit "fair" et "weighted" :

• « Fair » car il y a un ordonnancement "juste" des paquets en entrée en fonction des flux détectés. Le principe est assez simple : le routeur va créer dynamiquement une file par flux détecté (limité à n files). On entend ici par flux le n- uplet [@IP source, @IP destination, protocole, port source, port destination, champ TOS]. Ainsi tous les paquets d'une même session seront en attente dans une même file. L'ordonnanceur en sortie consulte les différentes files les une après les autres avançant octet par octet et dès qu'un paquet entier peut être transféré il le fait. L'algorithme exécuté recalcule en quelque sorte les priorités de chaque file à chaque octet.

• « Weighted » car l'ordonnanceur en sortie est sensible au champ TOS ou DSCP. En effet, pour un même flux entre deux machines, des paquets marqués avec une IP precedence à 5 seront servis plus rapidement que des paquets marqués à 0. Ceci se fait en ajoutant une pondération à chaque file en fonction de la priorité du marquage détecté.

Les 8 files réservées par Cisco sont conçues pour ne pas mettre en concurrence certains trafics considérés comme "critiques" avec le reste des autres sessions (les n autres files). Ainsi seront ordonnancés dans ces 8 files, entre autres, les paquets du protocole CDP (Cisco Discovery Protocol), les paquets des protocoles de routages et autres paquets marqués avec une "très haute priorité interne". Nous ne pouvons malheureusement pas en dire beaucoup plus à ce jour sur ces 8 files réservées par le manque d'information les concernant...

A noté que la notion de création dynamique de files sur détection de flux explique également le nom qui peut être employé pour cette approche : Per-Flow Weighted Fair Queuing.

Weighted Fair Queuing est un apport significatif en termes de mécanisme de QoS par rapport aux approches étudiées précédemment. En effet, son aspect dynamique tant au niveau de l'ordonnancement des flux en entrée que du service des files en sortie rend ce mécanisme très performant pour un minimum de configuration : seule une ligne de configuration sur une interface est nécessaire (fair-queue) !

Les avantages de cette approche sont donc :
• L'ordonnancement juste et pondéré (weighted and fair) des paquets en entrée.
• Les priorités dynamiques de chaque file en fonction des paquets qui y sont en attente.

Malgré ces avantages plutôt intéressants, on pourra noter :
• Le coût élevé au niveau de l'OS du routeur (ordonnancement + calcul des priorités dynamiques).
• Le manque de priorités utilisateurs (comment l'administrateur fait-il pour ordonnancer lui-même un trafic donné dans une file donnée ?) et le manque de priorité absolue (comment faire pour rendre un trafic "ultra prioritaire" et ne pas le laisser entrer en concurrence avec les autres flux ?).

Dans ce mode de fonctionnement, il ne sera pas difficile de comprendre que notre problème trafic FTP / trafic telnet trouve ici sa solution. En effet, le routeur se chargera d'aiguiller les deux trafics dans des files différentes (puisque ce sont des flux différents) et servira ces deux files en transférant k fois plus de paquets telnet pour 1 seul paquet FTP (par exemple, on transmettra 8 paquets telnet de 64 octets pour 1 paquet FTP de 512 octets). Ainsi, en sortie du routeur, les paquets telnet se voient intercalés entre 2 paquets FTP, ce qui apporte une meilleure fluidité du trafic telnet par rapport au trafic FTP.


11.3.5. Gestion des files en mode CBWFQ + LLQ


La gestion des files en mode CBWFQ + LLQ (Class-Based Weighted Fair Queuing + Low Latency Queuing) est illustrée par la Figure 7.


Figure 7 - Gestion de files en mode CBWFQ + LLQ


L'approche CBWFQ+LLQ propose, en plus des files déjà présentées dans le point 2.5 (n files dynamiques + 8 files réservées), une file dite "LLQ" (Low Latency Queuing) et nq-n+10 files utilisateurs. Les paramètres n et nq étant toujours fonction de la bande passante de l'interface physique concernée. L'ordonnancement des paquets dans les files est dit "fair" +
"weighted" + "class-based" + "low latenced" :

• Nous ne revenons pas sur les notions de fair et weighted dont les caractéristiques sont identiques au point III.4.

• Class-based : l'administrateur a la possibilité d'ordonnancer lui-même en entrée un trafic donné dans une file "utilisateur". Puis par configuration, il pourra spécifier la bande passante allouée à chaque file utilisateur et ainsi assurer une bande passante minimum garantie à ces flux utilisateurs.

• Low latenced : la présence d'une nouvelle file dite "low latency" propose une priorité absolue pour les trafics qui y seront orientés. Ce qui veut dire que les paquets en entrée qui seront aiguillés dans cette file se verront attribuer une priorité absolue et seront donc servis les premiers en sortie sans mise en concurrence avec les autres files (c'est la file "ultra-prioritaire").

Il ne sera pas difficile de comprendre que l'approche CBWFQ+LLQ apporte les solutions aux inconvénients du WFQ "simple". En effet, maintenant avec le CBWFQ+LLQ, on citera comme avantages :

• les mêmes que ceux du WFQ (ordonnancement juste et pondéré, priorités dynamiques).

• l'ajout de priorités utilisateurs avec la possibilité de configuration d'une bande passante garantie pour certaines classes d'applications (classification et configuration de la bande passante effectuées par l'administrateur).

• l'apparition d'une file avec priorité absolue permettant de privilégier totalement un trafic par rapport aux autres (très utile dans les domaines de la VoIP et ToIP).

Malheureusement la complexité interne de cette approche dénote :
• un coût très élevé au niveau de l'OS du routeur : certainement l'un des process les plus coûteux!

• une configuration pas très facile à ajuster (répartition de la bande passante, ordonnancement dans la file LLQ).

• un mode de fonctionnement pas très facile à vérifier (recalcul des priorités à chaque octet!).

Cette approche est celle qui apporte le plus de possibilités au niveau de la configuration et les meilleures performances pour une configuration qui reste assez simple et assez intuitive.

Tout comme dans l'exemple avec WFQ, le problème trafic FTP / trafic telnet trouve également ici une solution, car on peut faire avec CBWFQ+LLQ ce que l'on faisait avec WFQ "simple", avec quelques possibilités supplémentaires. On pourrait par exemple :

• faire passer le trafic telnet dans la file LLQ pour assurer une priorité absolue à ce trafic.

• configurer un bande passante minimum aux trafics FTP et telnet…

Une dernière remarque sur cette approche notamment au niveau de la queue LLQ : il faut éviter de faire "passer trop de trafic" dans cette file car sinon on pourrait générer des problèmes de famine identiques à ceux présentés dans le point 11.3.2

La file LLQ étant servie en priorité, si trop de paquets y sont placés son service risquerait de "bloquer" le service des autres files en sortie.



11.3.6. Détection de la congestion

Comme nous l'avons déjà dit en introduction, tous les mécanismes précédents ne s'enclencheront automatiquement (s'ils sont configurés par l'administrateur) que lorsqu'il y a congestion, sinon les paquets sont servis en sortie dans un mode classique FIFO.
Il est donc primordial de bien comprendre ce qu'est la congestion, comment elle est détectée en interne dans le matériel et quel est son rôle dans l'enclenchement de la QoS. Pour faire un bref rappel, la Figure 8 illustre les deux cas typiques qui peuvent amener à un point de congestion sur le réseau.


Figure 8 - Cas typiques de points de congestion sur le réseau

La gestion de la QoS se passe à deux niveaux :
• Dans les files d'attente de niveau 3 gérées par l'OS du routeur (ce que nous venons d'étudier), avec un comportement dépendant du mécanisme choisi (FIFO, PQ, CQ, WFQ...).

• Dans les buffers de transmission gérés par le hardware : tx-ring.

Le buffer tx-ring est configurable au travers du paramètre tx-ring-limit qui en exprime la taille. Ce buffer est géré en mode FIFO et c'est lui qui indiquera à l'OS du routeur qu'il y a congestion en cas de débordement (cet événement s'appelle "Back pressure to Level 3 processor system (IOS)").

Selon le mode de fonctionnement présenté à l'instant, il est clair que la configuration du tx-ring-limit est primordiale pour l'activation de la QoS : un mauvais paramétrage pourrait rendre inutile la mise en place de la QoS (QoS jamais enclenchée) ou encore nuire aux performances du routeur (trop de basculement FIFO / QoS). Alors qu'un paramétrage au plus juste permettra de traiter au mieux ces périodes de congestion et donc de rendre un service de qualité. Malheureusement, les recommandations concernant le paramétrage de ce tx-ring-limit sont assez floues et les impacts peu documentés. Cela dit, nous pouvons énumérer quelques règles de base, qui avec l'expérience, se sont avérées tout à fait pertinentes :

• Un tx-ring-limit configuré avec une grande valeur entraînera un enclenchement de la QoS le plus tard possible, ceci est recommandé pour les trafics de type donné et non recommandé pour les trafics de type voix, car il y a alors création de délais de transit et gigue

• un tx-ring-limit configuré avec une petite valeur entraînera un enclenchement de la QoS le plus tôt possible, ceci est recommandé pour les trafics de type voix mais non recommandé pour les liens à très hauts débits. A noter également la possible augmentation significative de la charge de la CPU du matériel.