Mémoire présenté pour l obtention du diplôme d Ingénieur Diplômé Par l Etat (FR) I.D.P.E. Par Pascal KOTTÉ

Transcription

1 Mémoire présenté pour l obtention du diplôme d Ingénieur Diplômé Par l Etat (FR) I.D.P.E. Par Pascal KOTTÉ «Phone 2000» Modernisation de l infrastructure téléphonique d une entreprise de 150 personnes Session 2005 A l ESSI Ecole Supérieure en Sciences Informatiques (Sophia-Antipolis, FR) Destinataires Jean-Louis FARAUT (Président du Jury) Spécialisation INFORMATIQUE Date jeudi 17 Novembre 2005 Version Version 1.02

2 < i > «PHONE 2000» Par Pascal KOTTÉ Mémoire I.D.P.E. Session 2005 Lieu ESSI, Sophia-Antipolis, France. Spécialité INFORMATIQUE Directeur du jury Jean-Louis FARAUT Jury particulier (patronymes non communiqués au candidat) RESUME Résumé en Français La société NEWRE se trouvait confrontée à des problèmes de redondance et de capacité au niveau de son réseau local Ethernet. Parallèlement, elle devait également résoudre : Un manque de prises réseaux pour relier les nouveaux postes de travail et les nouveaux téléphones. Le renouvellement du central téléphonique existant qui approchait de la fin de son cycle de vie. L extension de nouveaux bureaux dans un autre bâtiment de Genève. Face à ce défi, la NEWRE a opté pour une solution de téléphonie IP Cisco. La mise en place de cette solution s est faîte par étapes prudentes : 1. Un pilote sur 10 postes et un appel d offre ; pour vérifier la validité technique et économique. 2. Un déploiement en production mais limité à 35 postes, qui a permis d équiper le nouveau bâtiment. 3. Un déploiement global sur les 120 postes restants. Le résultat est une réussite grâce à un travail d équipes et une bonne organisation. Mots-clefs : IP, VoIP, ToIP, Téléphonie, Cisco, Convergence, voix, PBX.

3 < ii > English abstract NEWRE was facing capacity and redundancy problems in its LAN. At the same time NEWRE had to resolve: A cabling crisis there were not enough cables for all new workstations and phones. The ten-year-old PBX system was also at the end of its lifecycle. A new building in the same town has to be provided with IT and Telephony. NEWRE decided to implement Cisco IP Telephony. The installation was done using careful steps: 1. A 10 client s pilot and a Request for Proposal just for technical and financial validations. 2. A 35 client s limited deployment just to be sure and to provide telephony for the new building. 3. All the rest 120 clients. It was successfully because of a very good team work and organization. Keywords: IP, VoIP, Telephony, IPTel, Cisco, Voice, Convergence, PBX.

4 < iii > TABLE DES MATIÈRES Sections Contenu Pages Avant-propos Couverture, Résumé, Sommaire. i iv Le mémoire 1 50 Prologue Introduction 1 Chapitre 1 Existant 2 Chapitre 2 Objectifs 6 Chapitre 3 Réalisations 12 Epilogue Conclusions 39 Annexes Techniques A.1 A.14 Copie du RFP A.15 A.35 Glossaire Bibliographie & références a e e h RESUME... i Résumé en Français... i English Resume... ii TABLE DES MATIÈRES... iii Remarques... iv Conventions... iv TABLE DES ILLUSTRATIONS... v Introduction... 1 La situation existante... 2 Présentation des entreprises... 2 L infrastructure initiale de la NEWRE... 2 Les évolutions prévues en 2000 et Les demandes et les attentes de la NEWRE... 6 Les objectifs... 6 Les contraintes... 6 Les projets connexes (contexte)... 8 Les besoins La réalisation La démarche Le concept Planification Le pilote d essai Le RFP (Appel d Offres) La mise en œuvre pour Leschot La mise en œuvre pour l Athénée Conclusions Bilan en Rétrospective en Conclusions personnelles... 46

5 < iv > Annexes Techniques Architecture VoIP La mise en place d une fibre optique «noire» Conception initiale : architecture VoIP pour la NEWRE Les passerelles Voix sur IP Echo et «VoIP» Architecture LAN intermédiaire (Disaster II), niveau 2 de l OSI Architecture réseau TCP/IP (niveau 3 de l OSI) Planches techniques détaillées Prémaquette Adventis QoS : Une question de ToS et de CoS Adresses Internet Organismes de normalisation Plaquette commerciale réalisée par Cisco «Case Study» Copie du RFP Glossaire... a BIBLIOGRAPHIE...e 24 Documents de références, 4 Nouvelles, 9 Liens....e Remerciements... h A propos de l auteur... h Remarques Je vous remercie de me faire part de vos remarques et «feedback» par émail : pascal@kotte.net Le lecteur est supposé comprendre les notions fondamentales d informatique et de réseaux. Merci de vous reporter au glossaire et aux annexes pour un complément d information. Confidentialité : Les parties techniques détaillées et plus confidentielles de la NEWRE n ont pas pu être ajoutées à ce mémoire. Seuls les documents suffisamment génériques étaient disponibles. Conventions Certains termes utilisés dans ce document sont directement repris dans leur forme anglaise. Ils seront introduits dans le texte français entre guillemets. Vous en trouverez une explication dans le glossaire en fin de document.

6 < v > TABLE DES ILLUSTRATIONS Numéro Figure 1 - Etat historique du LAN, Niveau 2 Ethernet (1999)... 3 Figure 2 - La vision du nouveau LAN (Disaster II)... 5 Figure 3 - l impact du projet "Phone 2000" sur le projet "Disaster II"... 9 Figure 4 - Une démarche par étapes prudentes et professionnelles Figure 5 - Architecture VoIP finale envisagée au départ du projet Figure 6 - Installation en mode Mixte, Fax migrés, IP-PBX en cluster Figure 7 - Installation en mode full IP-PBX, en cluster avec double accès voix Figure 8 - Architecture du pilote (Bleu : existant, Rouge : ajouté) Figure 9 - Récapitulatif des coûts (SFr HT) des offres proposées Figure 10 - Migration : La cohabitation PBX et IP-PBX, Fax existants Figure 11 - Enquête de satisfaction auprès des utilisateurs LESCHOT (NEWRE) Figure 12 - Enquête de satisfaction détaillée globale (NEWRE 2001) Figure 13 Jan.2002, Zurich - Présentation des travaux NEWRE à la conférence "Cisco Converged voice", (Source : NEWRE) Figure 14 - Schéma des installations en Figure 15 - Gartner VoIP "Magic quadrant" Téléphonie / Communications globales intégrées Figure 16 -Indicateurs de convergence voix données Annexes Figure 17 - Architecture AVVID Cisco (exemple pour 100 postes, source Cisco)... 1 Figure 18 - Budget optique Monomode prévisionnel pour la liaison Leschot (P. Kotté)... 2 Figure 19 - Concept initial NEWRE : L'architecture Voix sur IP... 3 Figure 20 - Principale source d'écho - Les lignes analogiques (source : Cisco)... 5 Figure 21 Disaster II, étape 1 : Architecture Double Backbone Ethernet Gb... 6 Figure 22 - La nouvelle architecture IP de la NEWRE... 7 Figure 23 - Exemple : Schéma d'armoire de distribution... 7 Figure 24 - Maquette préliminaire chez Adventis... 8 Figure 25 - QoS = ToS+CoS (Source : Cisco)... 9 Numéro Tableau 1 - Projets et planifications initiales (avant remaniement)... 8 Tableau 2 - Coût du port réseau avec/sans PoE... 9 Tableau 3 - Partenariat entre Adventis, Cisco et NEWRE Tableau 4 Remaniement de la planification des projets NEWRE Tableau 5 - Plan simplifié du projet "Phone 2000" Tableau 6 - Fonctionnalités principales perdues et gagnées avec Cisco Call Manager v 3.0 (NEWRE) Tableau 7 - changement de la fonction "numéros abrégés" Tableau 8 - Grille de tests Annexes Tableau 9 -Types d interfaces rencontrées dans le monde de la voix (PSTN)... 4 Tableau 10 - Codec de numérisation de la voix... 4 Tableau 11 - Classes de service (sources Cisco)... 9 Tableau 12 - Organismes de normalisation Tableau 13 -Les standards suivants ont été mis en œuvre dans les projets NEWRE (2000) :... f Page Page

7 < 1 > P r o l o g u e INTRODUCTION En Mars 2000, la NEWRE a besoin de moderniser l infrastructure de son réseau local et de sa téléphonie. Une double mission est confiée à Adventis, sous ma conduite : Faire évoluer le réseau local. Evaluer l'opportunité d'utiliser ou non la Voix sur IP. Responsable technique de plusieurs clients ainsi que de l'infrastructure IT d'adventis, j'étais en charge de supporter l'infrastructure réseaux et systèmes de la NEWRE. Mon rôle initial d'expert réseaux et systèmes s est complété avec la conception et la conduite de projets. J ai organisé et structuré la mise en œuvre globale de l ensemble de ces projets, en supervisant les équipes internes NEWRE ainsi qu un jeune ingénieur d Adventis. Il était délégué partiellement pour le projet téléphonie et sur la partie «Voic ». La NEWRE décida de séparer et de créer les trois projets suivants : 1. «Disaster II» (Nouveau «LAN a») doit permettre d'augmenter le débit et la disponibilité du réseau local, sur le double bâtiment existant à l Athénée. 2. «Phone 2000» doit permettre le remplacement du central téléphonique vieillissant et en fin de maintenance. 3. «Leschot» : Un troisième sous projet NEWRE m'est aussi confié en Octobre Il concerne le raccordement IT et télécoms de nouveaux bureaux aménagés dans un autre bâtiment à Genève. Les délais étaient courts. «Disaster II» devait être opérationnel pour Décembre 2000 et «Leschot» pour Février «Phone 2000» était alors initialement repoussé à Le sujet de ce mémoire concerne la solution de Voix sur IP mise en œuvre à l'occasion de ce projet «phone 2000», dans le contexte des projets «Leschot» et «Disaster II». La création d'une synergie entre plusieurs projets, m'a permis de construire une infrastructure complète et cohérente, qui est devenu un site de référence utilisé par le constructeur Cisco. a Local Area Network (Réseau Local)

8 < 2 > C h a p i t r e 1 LA SITUATION EXISTANTE Présentation des entreprises La NEWRE : Nouvelle Compagnie de Réassurance (New Reinsurance Company) La «Nouvelle Ré» se présente comme un réassureur professionnel indépendant, de moyenne importance, bénéficiant d'une situation géographique privilégiée à Genève. Elle fait partie du plus grand groupe de réassurance mondial ; la MunichRe. Le site principal à Genève («Athénée») comprenait deux bâtiments reliés par un sous-sol aménagé. Il était partagé avec des locataires. Il existait un site satellite à Singapour et la NEWRE envisageait des extensions ; à Zurich et à «Leschot» (sur Genève). En 2000, la NEWRE employait environ 130 personnes fixes et quelques 10 à 20 consultants variables. Filiale du groupe «MunichRe», elle disposait d une indépendance informatique importante et opérait elle-même ses propres serveurs et bases de données. La société Adventis Communication Engineering SA La société est composée essentiellement d Ingénieurs et de Docteurs. J y ai débuté en Mars Grâce à mon expérience, je fus admis parmi les ingénieurs comme consultant. A la suite de différents projets dont principalement ceux de la NEWRE, je suis devenu en 2005 un consultant Senior. En 2000, la société assure la gestion de projets réseaux et télécoms, dans un contexte plus informatique que téléphonique. Elle est spécialisée dans la gestion, les migrations et l organisation de réseaux IP étendus. Les solutions Voix sur IP sont exploitées depuis plusieurs années sur le WAN, mais pas encore au niveau du téléphone des utilisateurs. La téléphonie sur IP était annoncée par plusieurs analystes comme une solution d avenir. Adventis était prête à relever le défi avec son partenariat Cisco et rejoignait la vision de la NEWRE dans ce domaine. L infrastructure initiale de la NEWRE L infrastructure téléphonique existante La NEWRE était équipée d un ancien «PABX» Siemens de modèle Hicom 300. Les combinés téléphoniques (T8 et T25) supportés par ce central n étaient plus disponibles chez le fournisseur. La maintenance n était plus garantie car les pièces détachées devenaient difficiles à trouver. Le département SG (Services Généraux de la NEWRE) assurait la gestion du central au niveau administratif et financier. Les interventions techniques étaient déjà prises en charge par une personne du département IT ("Information Technology"). Les postes informatiques et téléphoniques se partageaient les mêmes prises murales grâce à un câblage capillaire universel de type «UTP RJ45» (Paire Torsadée Universelle). (Voir plus de détails en annexe 14 ci-dessous : page 7 et 8 du RFP)

9 < 3 > L infrastructure de câblage de l Athénée (OSI 1) a En 1991, la NEWRE entamait d importants travaux de rénovation et de réhabilitation des anciennes caves du bâtiment de l Athénée. Le bâtiment est classé monument historique. Les perforations murales étaient limitées à l existant. Afin de permettre l installation d un câblage universel dans cet espace restreint, l architecte a fait poser un câblage sur 2 paires par prise, au lieu de 4 paires. La densité du nombre de postes de travail s est accrue en 2000, en conséquence : Le nombre de postes ne pouvait plus être étendu dans certains bureaux, Des «Hubs» et Micro «switchs» ont dû être installés, avec des raccordements mixtes contre performants (Imprimantes 10Mb et PC 100Mb). Des pertes fréquentes de connexions étaient liées à la rupture : D un câble RJ45 volant, Ou de l alimentation du HUB local. L infrastructure Ethernet de l Athénée (OSI 2) b L infrastructure LAN existante datant de 1994 était initialement composée d un «switch 100BT c» central avec des switchs et «Hub» de distribution «10BT». J ai pu mettre en évidence de fortes congestions sur certains segments du réseau Ethernet. Figure 1 - Etat historique du LAN, Niveau 2 Ethernet (1999) (Les 3 étoiles indiquent les zones principales de congestion réseau) a OSI Layer 1 : Couche physique du modèle OSI (Voir Glossaire en fin de document) b OSI Layer 2 : Couche «Liaison» : Niveau Ethernet/ adresses MAC (Voir Glossaire en fin de document). c 100BT : switch Ethernet 100 Base T (Voir Glossaire en fin de document)

10 < 4 > L infrastructure IP de la NEWRE (OSI 3) a Il existait un seul «subnet» IP avec un réseau unique pour les serveurs et les stations. Pour des raisons de surcharge de la classe C b utilisée, un «subnet c» IP additionnel a été créé pour les imprimantes sur le même segment Ethernet (domaine de «Broadcast»). Un petit routeur Cisco assurait le routage entre ces deux subnets. Un accès sécurisé à Internet était fourni à travers la liaison WAN d interne avec le groupe MunichRe. Il restait aussi quelques protocoles non IP en fin de vie (Netbios, IPX). La politique et les directives du groupe MunichRe suivaient le schéma directeur de Microsoft. La messagerie du groupe était basée sur Exchange et le protocole unique supporté était «TCP/IP». L infrastructure systèmes Les systèmes informatiques de la NEWRE étaient composés en 2000 de : Plus de 120 postes de travail Windows NT4 PRO, Un serveur de messagerie Exchange 5.5 (sous NT4), Une douzaine de serveurs Windows NT4. Les évolutions prévues en 2000 et 2001 Le projet «Disaster II» Contrairement à ce que laisserait supposer son nom, ce projet était en réalité une évolution du LAN. Il faisait suite au projet «Disaster» (1998) concernant les sauvegardes avec la capacité de restaurer les données et les serveurs à partir de bandes magnétiques. «Disaster II» a démarré en mars 2000, pour se terminer au premier trimestre Ce projet a réalisé, sous ma direction, une modernisation du LAN qui a permis d améliorer la disponibilité et les performances. Il était prévu de mettre en place : Deux «Backbone» switchs routeurs Gigabit en redondance («Layer 3 switch») Une capacité «QoS e» au niveau de ces deux switchs «Backbone», mais aussi au niveau des switchs de distribution (d étages). Une gestion des VLAN f (802.1Q g ). a OSI Layer 3 : Couche «réseau» (IP) b Un réseau de classe C en TCP/IP peut comprendre un maximum de 254 nœuds IP (PC, Imprimantes, badgeuses, routeurs, etc. ) c Terme couramment utilisé et plus explicite pour désigner un sous réseau IP. d WAN = Wild Area Network (Voir Glossaire en fin de document) e QoS = Qualité de Services (Voir en annexe 10) f VLAN = Virtual LAN (802.1Q, Voir Bibliographie IEEE en fin de document) g Voir Bibliographie IEEE en fin de document

11 < 5 > Figure 2 - La vision du nouveau LAN (Disaster II) Dans un premier temps, la redondance du «Backbone» est gérée au niveau 2 de l OSI a. Au niveau 3 : Les deux «switchs» routeurs se partagent le routage IP des «VLANs» en utilisant le protocole Cisco «HSRP b» pour la redondance des passerelle IP par défaut («Default IP Gateway c»). Cette architecture résiliente présente l avantage de pouvoir évoluer vers un routage dynamique. Le projet incluait la création d un nouveau plan d adressage IP et VLAN (Voir en annexe 7). En conformité avec le plan IP global du groupe MunichRe, l ancien «subnet» privé de classe C devait être supprimé au profit d une classe B. Le projet «Leschot» En Septembre 2000, il était annoncé le projet d aménager des bureaux supplémentaires sur un bâtiment proche à Genève pour la fin du premier trimestre Les 25 à 30 personnes déplacées sur Leschot devaient pouvoir disposer de postes informatiques et téléphoniques avec le même confort qu en étant à l Athénée. A terme, ils devaient pouvoir facilement revenir à l Athénée dès le départ des locataires existants, 3 à 4 ans plus tard. Le bâtiment de Leschot se situe environ à 700 mètres de l Athénée. Ce projet devait s inscrire dans le concept «Disaster II» (Voir la Figure 2). Le projet «Phone 2000» La nouvelle téléphonie allait basculer sous la responsabilité du département IT (Informatique). L ancienne dépendait des "services généraux" de la NEWRE. a STP : «Spanning Tree Protocol», IEEE 802.1d, voir le Tableau 13 en fin de document. b HSRP = Hot Standby Routing Protocol (Redondance par la création d une adresse IP virtuelle, présente sur deux ou plusieurs équipements, cette solution Cisco à l origine, a été rendue publique par l IETF RFC 2281) c Default Gateway : Le Routeur IP par défaut est une adresse IP unique pour la plupart des clients IP. La mise en place d une adresse IP virtuelle HSRP permet d assurer une redondance dans le routage IP.

12 < 6 > C h a p i t r e 2 LES DEMANDES ET LES ATTENTES DE LA NEWRE Les objectifs Objectifs Business a Les demandes émanant du «Business» amalgament les différents projets. Il me revenait de les traduire correctement : Déménager 25 collaborateurs de l avenue de l Athénée à la rue Leschot de façon la plus transparente possible concernant leur poste de travail b à la nouvelle adresse, pour février Assurer un fonctionnement optimal et fiable des principales infrastructures réseaux et de télécommunications, sur les deux bâtiments de l Athénée, et celui de Leschot. Renouveler le central téléphonique de l Athénée qui était arrivé en fin de vie. Optimiser les coûts. Objectifs IT Faciliter l intégration de la téléphonie par l équipe IT existante. les SG assuraient l exploitation de la téléphonie avec un contrat d exploitation externe auprès de Swisscom c. Pour l Athénée : Optimiser la réutilisation du système de câblage existant pour faciliter la suppression des micros switchs Ethernet installés dans les bureaux, et libérer des prises. Standardiser la création de sites satellites en améliorant la facilité de leurs intégrations avec le siège central de l Athénée. Améliorer l exploitation des communications téléphoniques : Fournir des fonctionnalités additionnelles aux usagers (dont une messagerie vocale) Faciliter l analyse des communications et en optimiser les coûts. Les contraintes Le contexte économique La NEWRE essuyait des pertes financières («Lothar» et autres catastrophes naturelles ont eu des conséquences sur le réassureur). La présence du géant «MunichRe» en tant qu actionnaire majoritaire permettait à la NEWRE d y survivre, mais les budgets d infrastructures étaient limités. a «Business» (anglais) Partie productive de l entreprise, organe de décision en adéquation avec le métier corps de l entreprise. b PC et Téléphone c Swisscom : Opérateur télécoms Suisse

13 < 7 > Le câblage Bâtiment classé monument historique. Le bâtiment ne supporte aucun chantier sans des procédures d aménagements draconiennes. La NEWRE a déjà réhabilité les locaux en 1991 en intégrant un pré câblage «UTP», et ne souhaite pas recommencer l opération. Le câblage existant sur 2 paires seulement. Le câble en place est de catégorie 5 a et supporte un débit de 100Mb Ethernet. Chaque prise n a été alimentée qu avec 4 fils. Il n est donc pas possible de faire cohabiter un raccordement téléphonique sur la même prise qu un ordinateur. Les prises de distribution ont été intégrées dans les meubles de bureaux avec un raccordement intermédiaire dans une trappe sous plancher. La plupart de ces trappes de distribution sont très peu accessibles (sous les meubles). Qualité J ai dû clarifier un certain nombre de conditions implicites. Par rapport à l existant, la nouvelle téléphonie devait maintenir ou augmenter la qualité : Sur les communications (l audition). Sur les opérations possibles (fonctionnalités). Sur la facilité d utilisation (ergonomie). Gestion facilitée et ouverture La nouvelle téléphonie devait faciliter l administration des postes et des systèmes. Des nouvelles fonctionnalités étendues devraient pouvoir s ajouter facilement : Comme la messagerie vocale («Voic »), les conférences, les communications vidéo, l interfaçage avec des bases et répertoires existants... Disponibilité et fiabilité Les nouveaux téléphones devaient fonctionner avec un très haut niveau de fiabilité : Le dimensionnement des systèmes devait être adapté aux besoins. Les coupures électriques ne devaient pas impacter la téléphonie. La défaillance de l opérateur n était pas couverte dans la solution en place, pourrait-elle le devenir? La défaillance du central téléphonique? (redondance) Numérotation au «clic» (activation d un appel à partir d un annuaire sur le téléphone et/ou sur l ordinateur) Etc. a Catégorie 5 (TIA TSB95, remplacé par la catégorie 5E en 1995, actuellement la catégorie 7 est utilisée sous la norme ISO Class F)

14 Les projets connexes (contexte) < 8 > Leschot «Leschot» a été l élément accélérateur. Le projet «Phone 2000» a été remis en route en Octobre 2000 (voir le Tableau 4) alors que la planification initiale des projets était la suivante : Tableau 1 - Projets et planifications initiales (avant remaniement) Projets Oct Déc Fév Mars 2001 Disaster II Backbone switchs d étages Leschot Préparatifs Déménagement Phone 2000 Etude Pourquoi changer ce calendrier? Leschot requiert au minimum une liaison 100Mb Ethernet, ou mieux, une ligne FO a (Gb b Ethernet). C est le seul moyen de garantir une connectivité sur les serveurs de l Athénée avec des performances équivalentes aux clients locaux. Leschot requiert la création d une installation téléphonique transparente avec l existant à l Athénée. Pourquoi, dès lors qu un projet «Phone 2000» était déjà prévu, ne pas intégrer la mise en place d une solution téléphonique à Leschot, qui puisse être compatible et cohérente avec ce projet? D autant qu une évaluation théorique favorable de la solution «VoIP c» avait déjà été réalisée. Il fallait toutefois conserver la possibilité de mettre en place une solution de téléphones traditionnels à Leschot, si le projet «Phone 2000» n était finalement pas possible dans les délais imposés. a FO = Fibre Optique b Gb = Gigabit (1 000 Mb, 1'000'000 kb) c Voice over IP = Voix sur IP (voir le glossaire en fin de document)

15 < 9 > Disaster II (New LAN design) L éventualité d une solution «VoIP» avait un impact immédiat sur le choix d équipement des switchs d étages (Distribution dans les bureaux) : Figure 3 - l impact du projet "Phone 2000" sur le projet "Disaster II" La bande passante requise pour transporter la voix est négligeable sur un LAN. Mais une éventuelle congestion Ethernet au niveau du LAN ne devait impérativement pas impacter les communications téléphoniques. Les questions principales posées par l évolutivité vers «IPTel a» sur le LAN étaient : 1. Le support de la qualité de service (Voir en fin de document : «QoS», IEEE 802.1p). 2. Le support d un routage performant de multiples VLAN (requis pour «QoS»). 3. La capacité d alimenter électriquement des téléphones IP («PoE», option PWR Cisco). La décision, VoIP ou non, impactait sur les choix d équipements du réseau. Un premier «RFI b» a permis de mettre en évidence les budgets suivants pour les équipements actifs du LAN : Tableau 2 - Coût du port réseau avec/sans PoE La conversion en Euro se fait environ à 1,5 SFr c pour 1. Les coûts du port 100Mb ci-dessus intègrent les coûts du double Backbone gigabit. Les coûts totaux concernent 216 ports 100 Mb (incluant de 8 à 16 ports Gb Ethernet avec FO). a Abréviation anglaise pour la téléphonie sur IP, parfois abréviée ToIP. Ce terme est ambiguë (Voir le glossaire) b Request for Information: Demande d évaluation budgétaire. c SFr = Franc Suisse. (On le retrouve aussi sous le terme CHF)

16 < 10 > Pour éviter des dépenses inutiles, même si la différence de budget était relativement faible, un changement de la planification des projets a été proposé (voir en page 14). Le «Backbone» Ethernet Gb a pouvait être mis en œuvre immédiatement. Les clients actuels pouvaient être maintenus un trimestre de plus avec les équipements existants à 10Mb (voir en annexe 6). Approvisionnement Télécoms La NEWRE avait choisi de migrer sa ligne téléphonique principale Swisscom vers l opérateur Multilink (devenue «T-System» filiale de «Deutch Telekom»). Cette ligne PRI b serait ajoutée à l Athénée, en plus de la ligne existante, afin d en permettre la migration. La téléphonie des locataires Le PBX c existant comprenait aussi un PRI et des raccordements dédiés aux locataires de l Athénée. Ce service n allait plus être disponible par la suite. Pour des raisons de sécurité et de confidentialité, ni les locataires, ni la NEWRE ne souhaitaient partager le même central téléphonique. J ai planifié et coordonné le déplacement des lignes correspondantes. Messagerie vocale, communication unifiée. La NEWRE avait prévu d ajouter une messagerie vocale intégrée avec la messagerie Exchange. Cette solution serait ultérieurement complétée avec un FAX logiciel interfacé avec Exchange. J ai coordonné l installation de la messagerie vocale avec la nouvelle téléphonie. La messagerie vocale ne fait pas parti de ce mémoire. a Gb = Gigabit, soit 1000 Mb (mégabits par secondes) b PRI = Accès Primaire ISDN (Voir Glossaire) c PBX = Concentrateur téléphonique privé (Voir le glossaire en fin de document)

17 < 11 > Les besoins L analyse des objectifs «Business», des objectifs «IT», des contraintes et du contexte de ce projet «Phone 2000» m a permis de mettre en lumière des besoins avec des impacts dans les différents projets, exemples : Projets Besoins Phone 2000 Disaster II Leschot Mettre en place un MAN avec Leschot L existence d un lien IP performant est une donnée importante du projet, en faveur d une solution VoIP (pas obligatoire «IPTel») Un lien FO permet de considérer Leschot comme un 3 bâtiment "local". Pour des raison de confidentialité et performances, une solution FO «noire a» sera retenue (Voir en annexe 2). Augmenter la disponibilité et les performances de la connexion des postes informatiques sur leurs serveurs La présence d un LAN performant et moderne est un facteur clef, en faveur d une solution VoIP. C est la motivation du projet Disaster II. Double Backbone Gb. «Full Switching 100Mb» C est la motivation du MAN ci-dessus. 2 paires de FO doublent l accès IP. Assurer la disponibilité des communications téléphoniques Double accès opérateur téléphonique? Indépendance électrique. Pour VoIP : Il faut mettre en place des switchs Ethernet avec UPS et PoE VoIP: Option 2 passerelle voix à Leschot. 2 paires de FO doublent l accès IP. Assurer la transparence de la localisation physique du collaborateur Un central téléphonique unique pour les deux sites? Rendu possible avec le MAN. Numéros de téléphones internes courts pour l Athénée Remplacer le central téléphonique existant C est la motivation principale de «Phone 2000» VoIP : Récupérer des prises dans les bureaux. Une solution téléphonique compatible avec Phone Réduire et contrôler les coûts Faire une consultation afin de comparer les prix. Analyser et contrôler les communications VoIP : unifier les 2 réseaux et faciliter l administration du réseau. Eviter un deuxième PABX et une 2 ligne Un équilibre entre la demande de disponibilité, et la réduction des coûts Une solution modulaire qui pourra évoluer. Automatiser la surveillance des services. Unifier les deux réseaux La redondance VoIP peut être ajoutée par la suite, et bénéficier aux 2 sites. Maintenir la continuité pendant les migrations Interruptions hors des heures de bureaux. Interruptions limitées à 30mn : 12h30-13h00 L expression de ces besoins a été simplifiée et synthétisée dans le RFP b (Voir en annexe 14). a Fibre Optique noire = Une fibre éteinte, sans équipements dessus. En général les opérateurs préfèrent fournir des fibres avec les services de transport associés et les équipements correspondants (FDDI, FOIRL, etc.). b RFP = Request For Proposal (Appel d Offres)

18 < 12 > C h a p i t r e 3 LA RÉALISATION La démarche Figure 4 - Une démarche par étapes prudentes et professionnelles RFP $ Partenariat Décision Idée Modélisation Théorique Concept Maquette 1. Pilote «Live» 2. Déploiement réduit 3. Déploiement complet Au départ : Une étude de faisabilité et d opportunité En 2000, la direction IT de la NEWRE avec les architectes réseaux d Adventis subodoraient que les solutions de téléphonies sur IP pouvaient présenter certains intérêts. En particulier, afin de libérer des prises murales dans les bureaux. Adventis est alors mandatée pour en évaluer les bénéfices réels. Le détail de cette évaluation ne fait pas l objet de ce mémoire, en voici les conclusions principales : «La mise en place d une architecture LAN redondante et performante avec les équipements actuellement disponibles, permet d envisager la mise à disposition de postes téléphoniques IP qui partagent la même prise que le PC, avec un niveau de fonctionnement et un coût d acquisition similaires à un téléphone traditionnel» «La convergence de la voix et des données n est plus une hypothèse mais un fait établi. Cette convergence devrait être largement répandue à l horizon 2005, d après les prévisions actuelles» (Adventis, Mai 2000) Un partenariat technologique afin de créer un concept et un pilote Il est décidé de mettre en place une maquette opérationnelle afin de vérifier qu une solution «VoIP» est effectivement viable pour la NEWRE. Un accord est établi entre Cisco, Adventis et la NEWRE afin de tester une solution AVVID a en mode réel à la NEWRE. a Architecture for Voice, Video and Data : Solution globale Cisco qui incluait la téléphonie IP. (Voir en annexe 1)

19 < 13 > Tableau 3 - Partenariat entre Adventis, Cisco et NEWRE. Adventis Cisco NEWRE Investissements Formations interne et externe Une maquette opérationnelle pour la formation interne et préparer la maquette NEWRE Une plate-forme Cisco «IPTel» pour son propre usage Un contact technique pour du support et pour faciliter les échanges d informations avec les responsables produits AVVID de Cisco Participation financière à l acquisition technologique réalisée par Adventis Fourniture de son environnement pour les tests «in live» Bénéfices Compléter ses compétences «VoIP» et Téléphonie sur IP pour en obtenir la certification Cisco Etendre son catalogue de solutions Un partenaire certifié téléphonie pour la Suisse Romande Une éventuelle référence client dans les assurances Un «feedback» technologique sur leur solution Tester complètement cette solution en production réelle à moindre frais, afin d envisager une implémentation réelle sans risques Un appel d offres, une décision. Par la suite, il était nécessaire de mettre la solution Cisco en compétition économique. Les objectifs, le contexte et les besoins seraient alors présentés dans un appel d offre restreint (RFP a ), proposé aux fournisseurs locaux les plus importants ou déjà en relation avec la NEWRE. Les principaux objectifs de ce RFP étaient : De comparer les coûts avec une solution de téléphonie classique, ou d autres solutions VoIP. De prévoir une solution de rechange qui puisse être mise en place dans les délais requis si la maquette VoIP ne donnait pas satisfaction pour des raisons techniques ou économiques. Suite au pilote et au dépouillement du RFP, la NEWRE devait disposer des moyens nécessaires pour une prise de décision concernant l évolution de sa téléphonie. a RFP = Request For Proposal (Appel d Offres)

20 < 14 > Une planification, une réalisation Pour assurer le succès de l ensemble des projets de la NEWRE dans les délais demandés, il était nécessaire de procéder par étapes : Une mise en perspective de ce projet avec les autres donna lieu à la nouvelle planification suivante (qui remplace la planification initiale, voir le Tableau 1) : Tableau 4 Remaniement de la planification des projets NEWRE Projets Oct Déc Fév Avril 2001 Disaster II Backbone 1 Switch IT switchs Leschot switchs Athénée Leschot Préparatifs Déménagement Phone 2000 Etude Validation (IT) MeO a Leschot MeO Athénée (En gras : les modifications sur le plan initial) La création d un plan de projet initial a permis de construire une vision plus claire et d identifier les contraintes temporelles (voir le Tableau 5 en page 23). La construction d un «RFP» a permis de modéliser cette vision pour clarifier les objectifs et les contraintes, tout en assurant des demandes d'offres régionales. Les 3 phases techniques suivantes ont été prévues afin de fournir les meilleures garanties possible à la NEWRE si la solution VoIP était retenue : 1. Le pilote «VoIP» en Novembre 2000 avec des tests par des décideurs et utilisateurs. 2. L'utilisation de Leschot pour une validation réelle sur 25 personnes. 3. Le déploiement à l Athénée, après une validation par les utilisateurs de Leschot afin d adapter ou corriger la solution le cas échéant. Une philosophie La consultation et la concertation systématique : Des équipes internes du client, Des juniors Adventis impliqués dans les projets, Des seniors d Adventis, Des experts Cisco. M ont permis d améliorer très sensiblement : La qualité et la validité ; des designs et des plans de mises en œuvre. Les motivations chez le client et chez Adventis. De façon générale, les décisions étaient obtenues par consensus, sauf pour certains éléments qui étaient imposés par le commanditaire. a MeO = Mise en Oeuvre

21 < 15 > Le concept Architecture «VoIP» La solution de téléphonie sur IP Cisco «IPTel a» Avant de mettre en place un pilote, il est nécessaire de le concevoir. Le concept VoIP suivait les recommandations de Cisco (Architecture AVVID b ), mais il était trop coûteux (Voir en annexe 1 et 3). Les coûts majeurs sont portés par les «Call Manager c» (IP-PBX) et les passerelles voix (en particulier les interfaces ISDN d PRI). J ai apporté quelques optimisations sur cette architecture, en particulier : J ai supprimé une passerelle interne : Il était inutile d investir sur un interfaçage temporaire avec le PBX existant. La communication passerait par le réseau téléphonique (RTC ou «PSTN»). Ce concept devait être validé dans le pilote (plus de détail en page 18). Le 2 «Call Manager» et la 2 passerelle ne sont pas nécessaires pour Leschot. L intérêt principal d une solution «IP-PBX» réside justement dans la capacité de réduire leur nombre. Pour Leschot, un IP-PBX n était pas indispensable, mais pour la NEWRE globalement, une option de redondance était envisageable. La solution Cisco intègre un mode «cluster». Il était aussi possible d envisager un doublement de l accès au réseau téléphonique. C est dans cette optique que la salle technique de Leschot fût dimensionnée en conséquence. Le principal intérêt pour la NEWRE était de pouvoir utiliser une seule prise pour raccorder le PC et le téléphone. Dans l état existant, deux prises étaient nécessaires. Figure 5 - Architecture VoIP finale envisagée au départ du projet a «IPTel» est l abréviation internationale officielle pour «IP Telephony». «ToIP» n est utilisé dans les normes en vigueur (IETF) que pour «Text over IP». b Voir en annexe 1. c «Call Manager» est le nom donné par Cisco à son central IP-PBX. Il gère l établissement et le suivi des appels. d ISDN = RNIS (Voir le Glossaire en fin de document)

22 < 16 > Les paramètres techniques requis pour une communication VoIP professionnelle, comprenaient un réseau IP avec les caractéristiques principales suivantes : Une bande passante disponible par communication de : 24 kb/s a sur les WAN 80 kb/s b sur les LAN et MAN. Une latence du réseau inférieure à 150 ms («one way» c ). Des variations de la latence inférieures à 30 ms (voir la raison en annexe 5). Au-delà de ces valeurs, la qualité de la communication commencerait à se dégrader de façon audible. L exploitation de cette solution pour le site de Singapour (12 personnes) n était pas envisagée en Mais cela restait une ouverture possible dès la mise à disposition de la qualité de service (QoS) sur le WAN de MunichRe. Plan de numérotation La nécessité de construire un plan de numérotation a été mise en évidence pendant la maquette chez Adventis. (Voir en page 28) Disponibilité et forte résilience du réseau LAN Ethernet L architecture redondante du nouveau réseau assurait un excellent support. Mais pour garantir le bon fonctionnement de la téléphonie il fallait lui donner les moyens de résister à une saturation du réseau Ethernet. Il était nécessaire de mettre en place «QoS» sur le LAN. La solution Cisco permet d utiliser le téléphone IP comme un Switch Ethernet à 2 ports qui supporte des VLANs (802.1Q d ). Ainsi le trafic «data» reçoit un «CoS» (802.1p) normal, et le trafic voix reçoit un «tag e» prioritaire. Les switchs Cisco 3524 supportent «CoS» avec deux queues de traitements (Voir en annexe 10). L architecture IP elle-même avait été redéfinie dans un concept redondant. Les équipements IP en double ou de type «cluster» ont été répartis sur deux «subnets» différents (Voir annexe 7 et Bibliographie Tableau 13). Un IP-PBX redondant est proposé afin d assurer une excellente tolérance de panne (SFT f ) au niveau du central téléphonique. Le serveur IP-PBX redondant est d abord positionné dans la «Computer Room II» officielle de l Athénée (Voir Figure 5). Une seconde passerelle voix redondante est aussi proposée en option. Cette «Gateway» est suggérée sur Leschot car en y déplaçant le second IP-PBX, il pouvait devenir un site «Disaster» potentiel (capacité de recevoir les services urgents et fondamentaux de la NEWRE sur le site LESCHOT en cas d incident majeur et global sur le site ATHENEE). Cette option ne sera mise en œuvre qu en 2002 pour des raisons budgétaires. (Voir Bilan 2005, Figure 13, en page 41) a La solution Cisco supportait G.729A à 8kb/s, mais c est sans compter le transport par IP, un «payload» doit être ajouté. b G.711 à 64kb/s plus le «payload» IP. c One Way = Dans le sens aller simple, utilisé par les opérateurs. Les ordinateurs mesurent plutôt un aller&retour (ping, trace route). d Voie en Bibliographie le Tableau 13. e Tag = marqueur QoS (Voir en annexe 10) f SFT = System Fault Tolerance

23 Alimentations (PoE) < 17 > Les téléphones devaient fonctionner en cas de coupure électrique. La solution Cisco peut alimenter les téléphones IP via la connexion Ethernet. Les switchs «PoE a» et l IP-PBX sont doublement raccordés avec une alimentation électrique standard, et une alimentation électrique secourue par onduleur («UPS» existant dans le bâtiment). Deux solutions étaient disponibles pour alimenter les téléphones. Les switchs Cisco PWR supportaient les deux : 1. La norme existante IEEE 802.3af ; en l an 2000, elle supportait une alimentation sur 2 fils additionnels aux 4 conducteurs Ethernet. Cette solution n était pas exploitable à la NEWRE qui ne disposait pas des 6 cuivres requis. 2. La solution «Power In Line» (PWR) de Cisco ; permet d alimenter un périphérique sur les 4 cuivres Ethernet existant. Cette technique était proposée en «Draft» à l IEEE b par Cisco. Nos contacts Cisco nous ont alors «prédit» que la solution «PoE» de Cisco sur 4 fils, allait bientôt être normalisée c. Les précautions d utilisations consistaient à éviter de débrancher une prise alimentée PWR, pour y rebrancher une autre comprenant un périphérique non PWR, dans une intervalle de temps inférieure à 10 secondes. La sécurité des personnes Mettre en place une solution de téléphonie dans une entreprise engage plus de responsabilités qu une installation informatique. La défaillance d un système de sécurité ou la non disponibilité d un numéro d urgence peuvent donner lieu à des poursuites judiciaires. 1) Les alarmes Certaines lignes d appels automatiques (Ascenseurs, Centrale d alarme "Cerberus" d ) devaient maintenir un bon fonctionnement après la migration. Un inventaire exhaustif et fastidieux a été réalisé pour permettre de vérifier l ensemble des lignes téléphoniques directes existantes. A cette occasion, deux ou trois lignes qui avaient été «oubliées» ont pu être réutilisées. 2) Les lignes de secours Une ligne téléphonique analogique de secours est prévue sur chaque site : A l Athénée à côté du central à l accueil, A Leschot le téléphone «rouge» partage la ligne du fax. Ainsi, même en cas de rupture vers la ligne téléphonique Multilink, il était possible d appeler l accueil qui pourra utiliser le téléphone direct, maintenu chez Swisscom. Une procédure simple est prévue pour la mise en relation du poste de secours avec un poste interne, via le poste de l accueil ( Les deux combinés tête-bêche). Ceci permet de palier des défaillances : de la passerelle voix (initialement unique) de l opérateur ou encore de la fibre optique (FO) Leschot. a PoE = Power over Ethernet (Voir le Glossaire en fin de document) b Voir Annexe 12 Organismes de normalisation. c Voir «Rétrospective 2005 / PWR» en page 43. d Cerberus = Est en fait une marque de systèmes d Alarmes, répandue en Suisse.

24 < 18 > 3) Les numéros d urgences Les numéros d urgences principaux et obligatoires devaient être identifiés et testés selon les protocoles définis avec les autorités compétentes (voir en page 33). La sécurisation de l IP-PBX Le central IP-PBX de Cisco («Call Manager») est un serveur Windows C est un serveur dédié avec une installation prédéfinie et imposée par Cisco qui comprend le système et les applications. Il a fallu obtenir l agrément de Cisco pour installer un anti-virus (McAfee). Une procédure de maintenance a été établie pour faciliter les modifications (installation de «patchs» et de mises à jour). Un disque additionnel a été prévu pour permettre un retour en l état précédent rapide («rollback»). Il suffit d utiliser les fonctions RAID 1 (miroir) du serveur Cisco (qui est un serveur Compaq). Il est possible de redémarrer le «Call Manager» dans un état précédent connu et stable, en moins de 10 minutes. Des sauvegardes de la «database» permettaient de compléter une restauration des dernières modifications. Concept pour les FAX. Pour raccorder des télécopieurs existants sur VoIP, il fallait utiliser des boîtiers adaptateurs analogiques sur IP. Ce n était pas nécessairement la meilleure solution. Les 2 fax entrants principaux de la NEWRE étaient sur un groupement de 2 lignes dédiées et séparées, avec un numéro en dehors de la plage de la ligne principale. Il était plus simple et plus fiable de conserver cette installation. Pour les télécopieurs secondaires distribués dans les étages : Une solution «Fax over IP» (FoIP) a été initialement rejetée. Les utilisateurs souhaitaient conserver leurs télécopieurs habituels. Les Fax devaient être fiables, car ils sont plus importants encore que les téléphones. Au lieu d utiliser des adaptateurs analogiques/voip, il a été choisi d installer des lignes directes pour remplacer les lignes analogiques internes sur le PBX existant. Le Fax de Leschot disposerait de sa propre ligne BRI (un accès de base ISDN avec adaptateur analogique avec double sortie). Il partagerait son raccordement avec le téléphone de secours, et ils resteraient indépendants de toute rupture IP sur la fibre optique (FO). Il était envisagé ultérieurement une solution qui permettrait l émission et la réception de FAX via la messagerie électronique existante (Exchange). Les investissements («CAPEX») devaient donc être minimisés sur cette question, quitte à augmenter les coûts d exploitation («OPEX»). La passerelle entre le nouveau Cisco IP-PBX et l ancien Hicom PBX Le déroulement en 3 phases imposait une étape de cohabitation avec l ancien PBX (voir la Figure 6 plus loin). Les designs théoriques de Cisco et autres, prévoient systématiquement l installation d une ligne interne (PRI ou multiples BRI) entre l IP-PBX et l ancien PBX. Il était initialement envisagé de réutiliser le PRI des locataires sur le PBX existant. Mais les éléments suivants représentaient un coût trop important : Une carte additionnelle PRI pour le Cisco Une installation fastidieuse et aléatoire de cette passerelle : Sur un ancien PBX (compatibilité incertaine) Non supportée par Cisco La solution proposée via le réseau public était idéale. De nos jours, il est possible de négocier des communications intra urbaines gratuites avec certains opérateurs. On peut se demander si cette solution ne sera finalement pas généralisable, y compris pour une cohabitation prolongée.

25 < 19 > Plan de migration Etat intermédiaire (Cohabitation) Selon le concept réalisé, la configuration en mode mixte était la suivante : Figure 6 - Installation en mode Mixte, Fax migrés, IP-PBX en cluster. (Ce schéma comprend un «cluster» Cisco, qui ne sera en fait installé que deux ans plus tard) Cette configuration devait être mise à l épreuve dans le pilote car elle permettait de tester tous les cas de figure. Opérations de migration Le concept devait prendre en compte les coûts et la faisabilité des migrations. Celles-ci ont été conçues comme suit : 1) Cohabitation pour Leschot : Extension pour Leschot Acquisition d une plage de numéro (contiguë avec la plage existante, par chance) Ajout d un «PRI» Multilink à l Athénée, utilisé pour la nouvelle téléphonie VoIP. Installation de l IP-PBX avec sa Gateway (à l Athénée sur le PRI Multilink) Installation des téléphones IP pour les collaborateurs de Leschot et tests. Installation du département IT en téléphones IP (à l Athénée). Cohabitation de l ancien avec le nouveau PBX Les deux centraux PBX communiquent les appels «internes» entre eux par des numéros courts, mais utilisent en fait le réseau téléphonique public (PSTN a ). a PSTN = Abréviation internationale pour désigner le réseau téléphonique mondial (Voir glossaire).

26 < 20 > 2) Migration des Fax secondaires qui étaient encore sur l ancien central Déplacement sur des lignes séparées. Programmation du transfert d appels sur les anciens numéros de ces fax, sur le Hicom, mais aussi sur le Cisco IP-PBX en préparation de la migration du central. 3) Migration de l ancien central PBX vers l IP-PBX (Athénée) Préparation des 120 téléphones de l Athénée (configurations sur le Cisco IP-PBX, test de chaque téléphone depuis le même local, sans aucun déplacement) Transfert de tous les numéros d appels (SDA a ) sur le PRI «Multilink» et installation en un seul Week-end de tous les nouveaux téléphones. 4) Migration des habitudes (formations et informations) Peu de personnes lisent les manuels, afin de mieux sensibiliser les utilisateurs aux changements d habitudes, la direction IT décida d organiser une formation pour tous par petits groupes. Toutes ces étapes devaient être préparées et si possible répétées avec soin. a SDA = Sélection Directe à l Arrivée (DID en anglais), c est la page des numéros de téléphones utilisé pour des appels directs vers les usagers sans passer par le standard général.

27 < 21 > La vision à long terme Comme prévu dans le projet original excepté sur deux points ( ), la version finale du concept VoIP de la NEWRE devait intégrer les composants suivants : Deux Call Manager en «cluster», sur deux sites différents, dans deux «VLAN» et «subnets» IP différents, avec CoS et ToS prioritaires. Deux passerelles voix redondantes pour les appels sortants, sur les mêmes principes. Limitation : Le transfert de PRI pour les appels entrants ne peut être réalisé que par l opérateur (limitation Télécom vérifiée auprès de l OFCOM) Figure 7 - Installation en mode full IP-PBX, en cluster avec double accès voix. Le concept prévoyait aussi la possibilité d avoir : Un serveur de messagerie vocale interfacé avec la messagerie Exchange. Un serveur de FAX interfacé avec Exchange. Limitation : Il ne pourra pas utiliser les passerelles voix Cisco existantes. De plus, l installation de serveurs redondants à Leschot pouvait être envisagée suite à l aménagement de la salle technique. Planification Des actions anticipées pour tenir les délais La construction d un plan de projet initial a permis de déterminer les urgences et la validité du planning. La marge temporelle était réduite et les actions suivantes ont été réalisées rapidement : Commande des équipements pour le pilote (prémaquette chez Adventis, qui sera installée à la NEWRE en Novembre) Construction et émission du RFP afin de permettre une prise de décision au 1 décembre Commande des travaux pour Leschot (qui nécessitait quelques aménagements) J ai aidé à la réalisation d un cahier des charges pour la salle technique à Leschot. La surface étant suffisante, il a été proposé un dimensionnement pour 2 «racks», extensibles à 3. Un «UPS» et un refroidissement ont été dimensionnés pour supporter 3 racks pleins. Cette salle était pressentie comme une excellente candidate à un éventuel «Disaster III».

28 < 22 > Commande d une fibre noire négociée avec la ville de Genève (Voir en annexe 2). Réservation d une plage de 100 numéros téléphoniques contigus dans la suite de la plage déjà utilisée par la NEWRE (disponible par chance) Commande de la ligne «PRI» additionnelle. Commander les autres équipements requis (câbles, switchs, ) Validation du concept proposé en terme de Sécurité et d Analyse de risques, avec les officiers désignés de la NEWRE. Une passerelle voix unique correspond à l existant. La passerelle secondaire ne sera pas incluse dans le projet initial. La proposition de sécurisation et du processus de mises à jour du système IP-PBX avec capacité de "Roll-Back" a sur 3 disques a été agréée. La solution Cluster ne sera pas retenue dans un premier temps Un téléphone «rouge» de secours sera ajouté à Leschot et à l Athénée. a Roll Back = possibilité de revenir rapidement dans l état précédent, après une modification désastreuse.

29 < 23 > Le plan de projet La construction d un plan de projet est fondamentale pour planifier les ressources afin de respecter les délais. Tableau 5 - Plan simplifié du projet "Phone 2000" < Oct.2000 Nov.2000 Déc.2000 Janv.2001 Févr.-01 Mars.-01 Concept Fait Corrections Correct Correct Correct RFP Emis Business test Décision Visite MR a 1 Déc. Athénée? Télécom (PRI) Commandé Installé MeO IT Préparat Installat Doc Voice Mail Préparat Installation Install FO b Commandé Installation Allumage MeO Leschot Préparat Installat Evaluat MeO Athénée Migration locataires Préparat Phases 1. Pilote 2. Cohabitation (Leschot) 3. Finale Extra Décisions Résultats Eléments externes au projet mais qui en conditionne le déroulement «Miles stones», barrière décisionnelle définie dans le temps. Informations requises pour la prise de décision La gestion de projet Dans un contexte «Nouvelles Technologies», il était important d utiliser un modèle de gestion de projet dynamique et adaptable. La partie conceptuelle et le design de l architecture ont dû évoluer en fonction des nouveaux éléments découverts dans les phases successives de mises en œuvre : Soit suite à la découverte de besoins NEWRE non exprimés initialement ; Exemple : Fax secondaires en réception (ils n étaient censés être qu émetteurs) Soit suite à la découverte de points ou lacunes techniques qui requiert un complément de «design». Plan de numérotation inexistant et à construire. Traitement des appels d urgences, mise en place d une ligne de secours. a MR = MunichRe b FO = Fibre Optique des Services Industriels de Genève (SIG)

30 < 24 > Soit suite à des «bugs» ou des problèmes techniques. Routage aléatoire des fax par le «Call Manager» (Voir «Problèmes techniques» en page 36) Soit volontairement, car certains éléments n ont pas pu être complètement traités dans la conception, compte tenu des délais. Ils devaient être complétés pendant la phase pilote : Evolution du standard téléphonique de la NEWRE Constitution du groupe de travail projet En plus de quelques testeurs, le groupe de projet comprenait une dizaine de personnes : Utilisateur, «officier» de sécurité, «manager» et les exploitants actuels et futurs de la téléphonie de la NEWRE (SG et IT). Ce groupe assurait la validation des décisions stratégiques, au nom de la NEWRE, qui lui étaient soumises par le chef de projet (moi-même). Evaluation des solutions «Soft Phone a» Evaluation des fonctionnalités existantes réellement exploitées, et celles souhaitées. Validation du plan de numérotation Evaluation des risques Feedback des 12 testeurs Etc. Le travail de ce groupe me permettait de valider certains points du concept ainsi que le contenu du RFP en construction. Ce groupe allait devoir se prononcer en donnant un avis «favorable» ou «défavorable» à la solution VoIP, et sur la solution Cisco. L avis de ce groupe, le feedback des testeurs et le dépouillement du RFP devaient permettre à la direction de la NEWRE de prendre une décision pour la téléphonie de Leschot, et pour la nouvelle téléphonie de l Athénée à venir. Plans et anticipation La mise en œuvre a nécessité une excellente coordination avec une planification des multiples migrations pour tous les différents projets. Des planches détaillées ont permis de prévoir à l avance l implantation et les approvisionnements de l ensemble des équipements, en particulier ceux qui étaient prévus pour la suite de «Disaster II», mis en attente de la décision pour la téléphonie. (Voir un exemple en annexe 8) Déontologie Impliqués à la fois ; dans le pilote Cisco et dans la conduite du projet «Phone 2000», la situation était délicate pour Adventis et moi-même car elle présentait des conflits d intérêts : Adventis était impliqué dans la fourniture de la solution Cisco. J étais le chef de projet qui devait établir les éléments de validation technologiques et budgétaires pour permettre à la NEWRE de faire un choix Cisco ou non Cisco : a Soft Phone = Un téléphone sous forme de logiciel dans le PC, interfacé avec l utilisateur au moyen d un micro casque, ou éventuellement via un combiné téléphonique spécifique (raccordé sur l entrée/sortie sonore de l ordinateur).

31 < 25 > Adventis et NEWRE ont convenu que l approvisionnement Cisco serait assuré par une société tierce. Adventis se limiterait au mandat de consultance. Adventis était le réalisateur et concepteur technique de la solution de téléphonie Cisco pour la NEWRE, y compris pour la mise en place du pilote : Le directeur d Adventis et moi-même avions décidé que notre société en tant que «Cisco certified partner» ne fournirait pas d avis sur la décision à prendre, ne pouvant être juge et parti. Le RFP et son dépouillement restaient sous la supervision et le contrôle des équipes internes NEWRE, la décision finale lui revenait totalement. Le pilote d essai Principes La mise en place d un pilote nécessitait l installation et la configuration complète, comme pour une mise en production réelle. Une maquette préliminaire a été établie dans les locaux d Adventis (Voir Annexe technique 9 ci-dessous). Elle a permis : De faciliter la mise à niveau technologique des ressources Adventis. De préparer le pilote NEWRE afin d être certain de pouvoir le faire fonctionner correctement dans les délais requis. De corriger ou compléter certains points du concept. De servir de plate-forme pour la formation assurée par un expert «AVVID». La NEWRE a loué pendant 1 mois pour une somme réduite (4'000 SFr) : 10 combinés téléphoniques Cisco 7960, un IP-PBX Cisco («Call Manager» MCS-7835-TD), une passerelle Voix/IP (IP/PSTN a ) Cisco 2621, une carte voie ISDN PRI (NM-HDV-1E1-30). Pour permettre le déploiement réel de quelques postes téléphoniques IP dans les bureaux de l Athénée, la NEWRE a acheté trois switchs équipés du «power in-line» de Cisco (PWR). Un groupe d évaluation d une douzaine de personnes a été constitué pour tester ces téléphones pendant plusieurs jours chacun. Les combinés ont été installés à leur place de travail selon le concept établi, en déroutant le numéro interne vers la ligne Multilink selon le schéma suivant. a PSTN = Public Switched Telephony Network (RTC ou Réseau Téléphonique Commuté, en français)

32 < 26 > Figure 8 - Architecture du pilote (Bleu : existant, Rouge : ajouté) Rejet du "Soft Phone". Le groupe de travail a refusé la solution du téléphone logiciel, à cause principalement de la dépendance au PC. Les deux personnes en fonction à l accueil de la NEWRE étaient aussi très réticentes à la mise en place d un standard téléphonique informatisé. Fonctionnalités existantes et futures L identification des profils d utilisateurs Deux types de postes ont été inventoriés dans l existant. Le groupe de travail mettra en évidence 3 types de profils d utilisateurs souhaités, qui seront précisés dans le RFP. 1. Un profil de base qui utilise la fonction de groupe (Team) pour faciliter la reprise des appels en cas d absence sur un des postes. 2. Un profil qui facilite le renvoi temporaire des appels vers un ou deux collaborateurs, pour mieux garantir le traitement de l appel. 3. L utilisateur qui possède deux bureaux, un sur chaque site. Il a donc besoin de pouvoir travailler facilement avec le même numéro, sur n importe lequel des deux postes en programmant (facilement) celui qui doit sonner. Lister et pondérer les fonctionnalités existantes ou attendues La maquette devait fournir une réponse satisfaisante à la totalité des fonctionnalités souhaitées. Il était nécessaire de pouvoir correctement les identifier. C était une des tâches principales du groupe de travail :

33 < 27 > Une attention particulière a été portée aux fonctionnalités existantes utilisées qui seraient perdues dans une optique «VoIP Cisco». Le central existant était ancien. Afin de ne pas passer â côté d autres fonctions souvent disponibles sur un central téléphonique, une liste de fonctionnalités qui pourraient intéresser la NEWRE a été établie. Cette liste est une extraction de plus de 50 fonctionnalités qu il est possible de retrouver dans une solution de téléphonie. (Voir plus de détails en annexe 14 : page 20 du RFP) Le groupe de travail a permis d extraire parmi ces fonctions celles qui étaient fondamentales pour la NEWRE (Voir en annexe 14 ci-dessous : page 13 du RFP). Toutes ces fonctions seraient testées dans le pilote. Tableau 6 - Fonctionnalités principales perdues et gagnées avec Cisco Call Manager v 3.0 (NEWRE) Pertes Pas de protection par PIN code Pas de renvoi de son poste depuis un poste tiers (*) Pas de rappel automatique sur occupation Pas de fonction chef secrétaire intégrée Gains Administration simplifiée Conférences (interne et externe) Annuaire Statistiques d appels au format ODBC a (Excel) «Call park» (*) Certaines fonctions comme programmer un renvoi de sa ligne SDA à partir d un autre poste (via un code PIN) étaient disponibles depuis une page web sur l intranet du central téléphonique. Les utilisateurs peuvent s identifier et programmer un renvoi de leur propre poste, y compris depuis un accès à distance. Les numéros abrégés Parmi les fonctionnalités existantes qui ont été perdues puis recréées ; la «liste de numéros abrégées» est un bon exemple d une re-conception dans un esprit IT, afin de fournir un meilleur service à l utilisateur. Tableau 7 - changement de la fonction "numéros abrégés" Avant Une liste de numéros «importants» est remise à un pool de secrétaires. Ces numéros sont importés dans le PABX sous forme de numéros à 6 chiffres. Une liste «papier» avec les numéros abrégés est diffusée dans toute la NEWRE, et publiée dans un fichier Excel. Mises à jour rare, liste incomplète, numéros abrégés plutôt longs, processus manuel fastidieux. Après avec Cisco TAPI Numérotation au «clic» : Un utilitaire permet de faire apparaître le téléphone Cisco comme un «voice modem» sur le PC de son choix. Il est possible de l utiliser pour déclencher directement la numérotation du téléphone ou du GSM d un contact Outlook. Partage des contacts dans un ou plusieurs «public folder» Exchange (plusieurs listes, selon l activité métier), mises à jour immédiates, pas de papiers imprimés. La solution peut aussi être utilisée avec des contacts personnels. a ODBC est le standard Windows pour permettre d interroger une base de données depuis une application Windows (Ex. Excel)

34 La fonction "Chef Secrétaire" < 28 > L utilisation d astuces de routages des appels avec la configuration d une double ligne a été nécessaire pour simuler la fonction chef secrétaire qui n est pas disponible en standard sur un IP-PBX Cisco : Le chef doit pouvoir activer le mode filtrage afin que la secrétaire reçoive et traite les appels directs de son chef. Cette fonction de filtrage doit aussi être activable depuis le poste de la secrétaire. Dans le cas de la solution Cisco : pour permettre cette dernière opération, la secrétaire devra utiliser une page Web sur son PC, avec un login d identification pour permettre l accès à l activation/désactivation de renvois depuis le téléphone du chef, vers son propre poste. Sur le système existant, la fonction était activée par un simple bouton «on/off» sur les deux postes. Une programmation XML serait requise sur le Cisco pour installer une facilité similaire. Le standard téléphonique L accueil téléphonique est assuré à la NEWRE par l hôtesse de réception à l entrée de l Athénée. Le standard existant était surdimensionné et sous-exploité. La plupart des appelants utilisent un numéro direct. Un entretien avec les deux hôtesses d accueil et leur responsable a permis de valider les souhaits suivants : Mettre en place une solution simple et facile à utiliser ; Permettre la gestion de 2 à 3 appels simultanés. Ne pas mettre en place un standard «professionnel», et surtout pas une solution informatisée. Un répondeur vocal non enregistreur en dehors des heures d ouverture. Plan de numérotation Aucun plan fourni, excepté celui des Etats-Unis La solution Cisco ne fournissait pas de plan de numérotation adaptée à la Suisse. J ai donc recherché les informations à leur source, chez BAKOM (OFCOM), le régulateur Télécom pour la Suisse (voir Bibliographie en page e). Le plan de numérotation construit pour la NEWRE comprenait 3 groupes de numéros : 1. Les numéros d urgences et de services : disponibles pour tous, avec une contrainte légale forte pour les 6 numéros obligatoires (Suisse : 112, 117, 118, 143, 144 et 147). 2. Les numéros "internes" comprenaient aussi les numéros externes vers le Hicom de l Athénée. Une programmation de transformation dans l IP-PBX et surtout sur la passerelle voix, permettait d utiliser les numéros courts sur les téléphones Cisco pour appeler les postes de l ancien PBX. 3. Les autres numéros externes nationaux et internationaux étaient dans un groupe commun, car le métier de la NEWRE nécessite un accès global pour tous les collaborateurs.

35 Le contrôle et la limitation des appels < 29 > La NEWRE a choisi de contrôler les abus par un examen statistique et automatique des appels. Le règlement interne de la NEWRE comprenait déjà une clause d utilisation professionnelle pour ; le PC et l accès Internet. Ce règlement a été étendu à l usage du téléphone. Ce document signé à l engagement, stipule en clair l acceptation de l employé d être contrôlé au niveau de l usage de ces trois éléments. Ceci était, à priori, nécessaire en regard de la législation Suisse pour permettre au département IT d assurer la surveillance des lignes et des accès. La NEWRE décidera d afficher un classement hebdomadaire des «Top 10» mais sans le détail des appels. L approvisionnement de la ligne téléphonique Le PRI Multilink a été installé en parallèle, sur le site de l Athénée. La passerelle voix a été mise en place sans difficultés techniques majeures. Principales difficultés rencontrées La cohabitation entre le vieux et le nouveau PBX via le réseau téléphonique public se déroulait bien (Voir en page 35 la liste des désagréments associés). Le plus difficile lors de la mise en place était l acquisition des connaissances requises, et surtout la planification des tâches jusqu alors méconnues. Une formation externe par un expert AVVID et la maquette nous ont permis de faire une planification très réaliste. La solution de téléphonie Cisco n intégrait aucun des éléments et composants spécifiques au monde de la téléphonie européenne, et encore moins sur les spécificités Suisse. Il a donc fallu se mettre rapidement à niveau sur ces sujets, et créer les configurations correspondantes nécessaires. Le monde de la voix s est montré plus complexe que le monde de la «data». La voix est à la fois plus permissive (on peut perdre quelques paquets) et plus exigeante (30 ms c est bon, 35 ms c est mort). Elle comprend une très grande richesse en terme de fonctionnalités et de technologies (Voir en Annexe). Le RFP (Appel d Offres) Etude de marché Il était nécessaire pour les dirigeants de la NEWRE d avoir l assurance que la solution mise en pilote avec Cisco pouvait répondre aux besoins non seulement sur le plan technique (validé avec le pilote), mais aussi sur le plan financier. La nécessité de faire un RFP est apparue dès le début du projet. Il a été émis avant la mise en place du pilote pour les raisons suivantes : 1. Afin de prendre une décision dès la fin du pilote, pour permettre la fourniture d une solution à Leschot dans les délais. 2. Afin de disposer des mêmes objectifs, des mêmes contraintes et des mêmes besoins à résoudre et à vérifier sur le pilote. Emission du RFP C est ce RFP qui a aidé à clarifier les objectifs et mis en évidence l interdépendance des projets. A la demande de la NEWRE, il n a été émis qu à quatre entreprises (Voir annexe 14).

36 < 30 > Le RFP a été émis avant le pilote Cisco qui était planifié en novembre. Mais par souci d honnêteté, ce pilote était clairement mentionné dans le RFP. C est peut-être une raison additionnelle pour laquelle deux des fournisseurs sollicités, pourtant sur leur propre demande, ont finalement préféré ne pas y répondre. Dépouillement du RFP Désistements Commcare SA (Solution Nortel) n a pas répondu. La raison invoquée était : Les solutions n étaient pas suffisamment adaptées pour la NEWRE. EGGTELSA (Compagnie générale d électricité, fournisseur des SG de la NEWRE) : Leurs offres en matière de téléphonie n étaient pas adaptées à la NEWRE. Offres Swisscom a répondu avec deux offres : Une solution classique «Meridian», Une offre VoIP avec Cisco. Les prix proposés pour les mêmes équipements Cisco étaient relativement plus élevés que ceux proposés par le fournisseur établi de la NEWRE (Getronics). Siemens : Malgré une offre professionnelle existante «VoIP», la société Siemens a préféré répondre avec une téléphonie classique. La solution Siemens (Hicom) répondait au problème du manque de prises avec la possibilité de chaîner deux téléphones. Toutefois, cette solution ne permettait qu un gain de 25% en nombre de prises, contre 50% pour la solution Cisco. Nous avons demandé à Siemens de bien vouloir faire aussi une offre «VoIP» avec leur solution "Hipath" qui était reconnue dans le monde «IPTel». L offre dépassa les 230'000 SFr. Le téléphone se composait d un combiné couplé au clavier et d un logiciel sur le PC. La solution n était effectivement pas satisfaisante pour la NEWRE. Figure 9 - Récapitulatif des coûts (SFr HT) des offres proposées La solution Cisco nécessite la mise en place de «switch Power in line». Ce surcoût a été intégré dans ce récapitulatif, y compris dans l offre Cisco de Swisscom. Les coûts d installations de l Athénée pour la solution Cisco interne correspondaient à deux personnes en interne pendant deux jours, soit de l ordre de 2'000 SFr.

37 < 31 > L analyse des réponses montrait, comme nous l avions prévu, que le coût global au final serait compétitif avec une solution classique. Ce n est pas le cas si on ne considérait que la partie Leschot. Nous avions déjà évalué les ordres de prix avant le RFP, car il aurait suicidaire de mettre en place un pilote pour une solution qui n avait aucune chance de convenir sur le plan budgétaire. En conclusion, l amortissement d une solution «IPTel» face à un central classique ne pouvait se faire (en 2000) qu à partir d une centaine de postes minimum. La téléphonie IP gagne essentiellement sur les frais d installation (Avec des «IP-Phones» professionnels, sans utiliser des «Soft Phone»). Par la suite, il est possible de multiplier le nombre de téléphones sans coûts additionnels au niveau de l IP-PBX, alors qu un central classique doit ajouter des cartes de connexion. De plus il faut pouvoir disposer des lignes de distribution dans les étages, ce qui n était plus le cas pour la NEWRE. La décision Les raisons qui pouvaient attribuer l offre hors de la solution Cisco comprenaient : 1. Un rejet de la solution Cisco pour non-conformité lors du pilote. 2. Un rejet de la solution Cisco pour dépassement budgétaire. 3. Un rejet par la direction Télécom du groupe MunichRe. Les comptes rendus des testeurs «Business» étaient positifs. La direction Télécom MunichRe ne posa pas son veto sur ce choix désigné de : «courageux». La direction de la NEWRE confirma le choix Cisco. La mise en œuvre pour Leschot Mise en service Tous les éléments étaient déjà disponibles et en place. La mise en œuvre pour Leschot consistait essentiellement à : Installer le nouveau «Call Manager» et sa «Gateway» Reconfigurer le plan de numérotation établi dans le pilote, recharger les configurations. Recevoir et configurer les 25 téléphones (10 par poste, le plus long étant le déballage). Programmer les 25 renvois sur l ancien PBX, vers les nouveaux numéros. (Voir (1) ci-après) Programmer les 25 nouveaux numéros courts pour Leschot sur l ancien PBX. (Voir (2) ci-après) Brancher les téléphones et les PC. Répéter la même procédure pour les 12 téléphones du département IT.

38 < 32 > Figure 10 - Migration : La cohabitation PBX et IP-PBX, Fax existants. Conservation des numéros courts (1) Afin d anticiper et de faciliter la migration future pour l Athénée, les personnes de Leschot ont accepté de changer leur numéro d appel pour prendre un numéro sur la plage contiguë associée avec la nouvelle ligne. Les appels sur les anciens numéros allaient toutefois pouvoir être maintenu pendant plus de 3 mois (grâce à une redirection sortante programmée sur l ancien PBX). (2) Il a été possible de programmer les nouveau numéros courts, sur la nouvelle plage «Multilink», dans l ancien PBX afin d assurer aussi leur routage transparent à Leschot. Ainsi les collaborateurs de l Athénée ont pu commencer à utiliser les nouveaux numéros pour contacter Leschot. Tests de base, recette de fonctionnement. Tests d appels Les tests de base des téléphones furent simples et rapides (les tests fonctionnels détaillés ayant déjà été réalisés dans le pilote). Un appel interne suffisait pour s assurer que chaque téléphone était opérationnel. Des tests plus complets ont été faits à partir d un des postes : Tableau 8 - Grille de tests Appel Transfert Depuis, > vers : > Hicom int. > Cisco > Hicom > Cisco Hicom/Athénée (sans objet) Routage PSTN Routage PSTN Poste Cisco Routage PSTN Normal Routage PSTN Normal Depuis l externe vers un ancien n Depuis l externe vers un nouveau n Routage PSTN Normal

39 Tests des urgences < 33 > Nous venions de créer une installation nouvelle, avec un plan de numérotation construit de zéro. Il était nécessaire de tester les numéros d urgence : La procédure normale confirmée par les autorités, consistait à appeler ces numéros et à mentionner qu il s agissait d un : «Appel de test, voyez-vous correctement mon numéro d appelant?». Le test complet consistait à activer la séquence fournie par l opérateur, pour permettre le masquage du numéro appelant, et vérifier la bonne présentation du numéro malgré ce masquage (selon les normes Suisse en vigueur). La date et l heure d appel suffisaient pour certifier cette opération. C était le seul moyen de s assurer techniquement que notre installation était conforme. Le test a été réalisé avec les 4 principaux numéros d urgence (sur les 6 existants). Y compris le numéro «112» pourtant absent du bottin téléphonique de Swisscom. Le 112 Européen est extrêmement méconnu en Suisse. Ce fût pourtant le seul numéro opérationnel sur les GSM Swisscom dans tout le canton de Genève lors de la grande panne de 2002 qui dura plus d une journée. Formations Formation des exploitants La solution Cisco ne permettait pas de limiter les accès console de l IP-PBX pour une gestion de base des postes téléphoniques. Il était possible depuis la console de casser la configuration du central. Afin de réduire les risques et les besoins de formations, cet accès a été limité à l équipe IT de niveau 2 "réseaux". Les équipes Helpdesk premier niveau n avaient pas accès à la configuration de ce central. Un transfert de connaissances a été réalisé entre Adventis et l équipe réseaux de la NEWRE. Formation des utilisateurs C était une formation ciblée directe et par groupes d utilisateurs du même espace ouvert (pour faciliter la formation sur les captures d appels). Point remarquable : Les utilisateurs étaient invités à venir avec leur propre téléphone, qu ils débranchaient de leur PC eux-mêmes. Une personne spécialisée dans la formation a été chargée de passer 1h à 1h30 afin d expliquer leur nouveau téléphone. Elle a conçu un petit guide simplifié et adapté à la NEWRE. La formation couvrait aussi l utilisation de la messagerie vocale. Un message d accueil type, et validé par le département communication de la NEWRE, était enregistré par chaque collaborateur. Projets connexes Une solution de messagerie vocale Unity d Active Voice a été mise en œuvre. Elle s intégrait parfaitement avec Exchange et le «Call Manager» de Cisco. La société «Active Voice» était en cours de rachat par Cisco. Problèmes rencontrés Les problèmes et remarques fonctionnelles suivantes ont été escaladés à Cisco (Call Manager version 3.08) :

40 < 34 > Rupture des communications avec les passerelles H.323 dès la moindre configuration du plan de numérotation. Il manque un outil pour exporter, puis importer le plan de numérotation. Certaines configurations doivent être faîtes à double sur chaque «Call Manager» d un cluster. La capture d appels depuis un IP-Phone 7960 est fastidieuse (4 opérations à faire) Le «Corporate Directory» du téléphone n est plus utilisable durant un transfert d appel. La numérotation depuis Outlook (TAPI) ne fonctionnait pas pour un numéro comprenant un «interdigit time-out». Au total, une vingtaine de problèmes et remarques ont été escaladés concernant la solution «Unity», la passerelle voix, les téléphones et le Call Manager. La plupart étaient des points mineurs et ont été corrigés par la suite. Le temps investi ne dépassa que très légèrement celui qui avait été prévu. La mise en œuvre pour l Athénée Feedback des utilisateurs Leschot Une première enquête auprès du groupe de LESCHOT est assurée en interne par la NEWRE. L évaluation de la téléphonie Cisco et de la messagerie vocale est globalement très positive. Figure 11 - Enquête de satisfaction auprès des utilisateurs LESCHOT (NEWRE) Les principaux griefs concernent le téléphone 7960 : La fonction main libre (elle désactive le micro du combiné), peu audible pour le correspondant. L esthétique laisse à désirer. La lourdeur et la faible ergonomie du combiné.

41 < 35 > Suite à la mise en production à Leschot, aucun aménagement ni correction notable ne fut nécessaire sur les configurations et le design. Un report de 3 mois La solution temporaire en mode mixte fonctionnait tellement bien, que pour des questions de planification et de budget, la direction NEWRE avait décidé de retarder l achat des 130 postes restants. Pourtant le mode «cohabitation» Hicom+Cisco posait une quantité de problèmes mineurs : Présentation défaillante des numéros entre les utilisateurs Hicom et Cisco. La réception devait utiliser les anciens numéros Hicom pour transférer les appels Cisco. Le standard Siemens perdait la configuration fréquemment (redirections des lignes migrées). La messagerie vocale supporte un accès direct sur Cisco, pas sur une ligne Hicom (il fallait retaper son numéro de poste sur le répondeur vocal). Pas de transfert programmable par l utilisateur depuis un ancien poste Siemens vers un Cisco. Configuré uniquement depuis le plan de numérotation du Hicom. La messagerie ne fonctionne pas en dehors des heures de bureau (le Hicom est prioritaire) Finalement, la commande restante a été dégelée 3 mois plus tard suite à : Un crash du vieux central Siemens d une durée de 6 h. Seul Leschot et IT pouvaient téléphoner. Les pièces détachées devenaient très difficiles à remplacer sur le vieux Siemens (un disque IDE 40MB). Une demande de changement de bureau pour un grand nombre de collaborateurs de l Athénée (restructuration interne). La solution «VoIP» a permis d économiser de l ordre de 10'000 SFr (6'000 ) suite à la restructuration et le changement de bureau pour 70% du personnel NR en Juillet 2001, et avec très peu de perturbation. Les PC étaient déménagés en même temps que le téléphone. Mise en service (Juillet 2001) L installation La totalité des quelques 120 postes téléphoniques ont été déployés en moins de 12 h par 2 personnes. Il suffisait d intercaler le «switch IP-phone» sur le PC. Cette opération s est déroulée durant un vendredi soir et un samedi pour permettre la bascule de tous les numéros existants sur le nouveau PRI, sans perturber les services de la NEWRE. L ensemble des numéros et des routages étaient déjà prêts sur le central IP-PBX Cisco (6 à 8 jours hommes de travail environ en intégrant une partie du travail fait pendant le maquettage en comprenant les opérations de tests. Toutefois le projet complet pris 3 fois ce temps, avec le RFP) Des modifications importantes sont apportées dans le plan de numérotation («Call Manager») et sur les routages dans la passerelle. Il était donc nécessaire de procéder à un nouvel essai des deux numéros d urgences : 112 et 118. Il n a pas été jugé nécessaire de tester les autres numéros, les deux ci-dessus ayant fonctionnés.

42 < 36 > Des tests de contrôle ont été répétés sur les appels avec les premiers postes pour vérifier le bon transfert de la ligne PRI, avec le nouveau plan de numérotation. Les Fax n étaient pas impactés car ils avaient déjà été déplacés sur leurs lignes directes. Les systèmes de secours et de sécurité avaient été vérifiés (ils étaient indépendants). Des tests de routines sur les équipements de sécurités ont toutefois été demandés dans le courant de la semaine suivante. Il n y a eu aucun incident notable. La ligne PRI de Swisscom a pu être déco missionnée comme prévu. Le démontage et la récupération des téléphones et de l ancien Hicom ont été confiés à un «broker». Le standard téléphonique (l accueil) Le poste simple a été installé conformément à la demande. Il prend en charge : 6 lignes simultanées, avec un renvoi vers un pool de deux secrétaires en cas de saturation (soit une capacité de 18 appels parallèles non transférés). Un renvoi immédiat activable vers un répondeur vocal (via «Unity»). Un renvoi immédiat vers le pool secrétariat pour une absence courte. La formation des utilisateurs En l espace de 2 à 3 semaines, la quasi-totalité des collaborateurs de la NEWRE ont suivi l atelier par petits groupes comme pour Leschot. Ceci n était possible que grâce au relatif petit nombre des collaborateurs (environ 120 sur l Athénée). L upgrade En Août 2001, le système a été mis à niveau avec la dernière version mineure du Call Manager. Ceci a permis à la NEWRE de pouvoir disposer d une musique d attente. Des tests ont d abord été réalisés sur la plate-forme d Adventis afin de s assurer d une mise à jour sans risque. Ce type d opération a montré qu il était recommandé de pouvoir disposer d un LAB comprenant une plate-forme pour faire les essais. La procédure de «roll back» fonctionnait parfaitement. Problèmes rencontrés Malheureusement, des problèmes ont été mis en évidence après le déploiement général, malgré : Toutes les précautions prises, La mise en place d une maquette opérationnelle, Une phase en production de plus de 4 mois sur 35 personnes (Leschot + IT). Problèmes techniques 1) Echos La NEWRE rencontra de sérieux problèmes d échos. Ils étaient de deux origines : 1. Un écho acoustique dû à la conformité physique du combiné 7960

43 < 37 > Résolution : conserver le volume d audition réglage sur le poste en dessous de 80%. Ceci permettait de l atténuer suffisamment. 2. Un écho lié à la «VoIP» (Jitter). Ce problème n a été constaté que sur quelques appels vers des particuliers et à l étranger. C est la raison pour laquelle il n avait pas été détecté avant. Atténuation : Un réglage fastidieux des paramètres de «gain» et «attenuation» ont permis d en limiter les effets, mais sans les supprimer. Cisco a publié depuis des recommandations à ce sujet, pour faciliter ces réglages (voir Bibliographie). (Voir plus de détails techniques en annexe 5) 2) Pertes de FAX Les fax secondaires qui étaient normalement sortants, étaient utilisés aussi en réception. Ce fait a été constaté dès la conception. Un renvoi des numéros internes correspondants a été programmé sur l ancien puis le nouveau PBX. Car ces Fax ont été déplacés sur des lignes Swisscom dédiées. Le changement des numéros d appel de ces télécopieurs avait été communiqué pour être officialisé et transmis aux clients concernés. Le transfert de ces Fax n a posé aucun problème depuis le Hicom. Mais sur le «Call Manager» (3.08), un fax sur 5 disparaissait, et provoquait une erreur à l émetteur. La mise en évidence de ce problème aléatoire n a pas été facile, mais j ai pu montrer que : Il n y avait pas d erreur en utilisant le numéro Swisscom directement. Les traces de l appel du fax sont visibles chez l opérateur, vers le PRI NEWRE. Il n y a aucune trace d appel reçu concernant ces fax (et donc aucune cause de rejet), ni sur le «gateway», et encore moins sur le «Call Manager». L appel disparaît. Sans être critique, le problème était important, une solution de contournement rapide («workaround») a été mise en place : L opérateur Multilink a accepté de rediriger depuis leur central, Les 3 Fax concernés vers les lignes Swisscom correspondantes, pour une durée de 6 mois. Le problème n a jamais été identifié ni résolu, et nous n avons pas eu l occasion de le tester avec les versions suivantes du Call Manager. 3) Incident majeur sur la téléphonie En 5 ans, 1 seul véritable incident arrêta les téléphones. Le problème était lié au réseau, suite à 5 facteurs ; deux erreurs de configuration, une erreur de manipulation plus une panne au moment d un week-end prolongé : Le serveur DHCP est tombé en panne, Sur un week-end prolongé de 3 jours. La «lease duration» du scope DHCP des postes de travail était resté à 3 jours, par oubli. Il y avait une erreur de configuration sur les 2 routeurs «backbone Gb switch» (routeur GB)

44 < 38 > Au matin, l ensemble des postes de travail de la NEWRE ne pouvait plus ouvrir de session ni communiquer sur le réseau. En attendant l arrivée des deux ingénieurs réseaux (dont moi-même) : L équipe IT a procédé au redémarrage du premier routeur GB. Après 10 minutes, le problème n ayant pas été réglé, IT a procédé au redémarrage du 2 routeur. Les téléphones qui fonctionnaient toujours auparavant, sont devenus hors service. L erreur de configuration sur les routeurs ne leur permettait plus de redémarrer correctement. Il a été nécessaire de les reconfigurer. La compréhension du problème et sa correction ont pris 1 h, soit moins de 3 h d interruption de services. Les téléphones étaient correctement configurés avec une «lease DHCP» de 7 jours. C est la raison pour laquelle ils fonctionnaient toujours, jusqu à l arrêt des routeurs. Voici une excellente illustration de la loi dîtes de «Murphy». Nous en avons tiré les leçons nécessaires pour modifier les processus suivants 1. Seulement un des 2 ingénieurs réseau peut donner l ordre d un «reboot» du backbone (par téléphone le cas échéant). 2. Après avoir changé la configuration d un routeur, il doit être redémarré afin de vérifier que les modifications sont correctement enregistrées et qu elles ne provoquent pas d erreurs. Pour les passerelles critiques («VoIP»), il faudra attendre la période autorisée. 3. Installer un monitoring du service DHCP, avec une alerte (ceci avait déjà été recommandé par Adventis dans le projet Disaster II). Autres Problèmes Les mises à jour «Call Manager» de la version 2 vers la version 3 (puis 4), n étaient pas incluses dans la maintenance logicielles «Gold» fournie avec la solution. L obtention d une offre pour une extension de maintenance qui intègrerait ces mises à jour s est avérée coûteuse et a été abandonnée. Le besoin de pouvoir bénéficier des mises à jour majeures n était pas clairement établi.

45 < 39 > E p i l o g u e CONCLUSIONS Bilan en 2001 Satisfaction des utilisateurs Une enquête globale m a été confiée, elle sera facilitée par un formulaire Excel envoyé par interne, dont voici le dépouillement : Figure 12 - Enquête de satisfaction détaillée globale (NEWRE 2001) Le projet est une réussite. La satisfaction globale est un peu plus mitigée qu avec le groupe Leschot, mais la solution a rempli ses obligations et même au-delà. Après investigations, la fonction «park a» a été mal notée car totalement inconnue, elle n était pas présentée dans les ateliers, ou trop rapidement. a Fonction pour parquer un appel sur une zone d attente et aller le récupérer sur un autre poste, sans avoir besoin de faire un transfert.

46 < 40 > Le mode speaker du téléphone désactive le micro du combiné devenu inutile pour ses utilisateurs, qui s égosillaient pour rien sur le mauvais microphone. La messagerie vocale qui ajoutait des messages vocaux en plus des s déjà nombreux dans Exchange, n a pas été bien accueillie par tout le monde. Certains souhaitaient pouvoir la désactiver, mais cela était refusé par la direction. Point fort de la messagerie vocale Unity d Active Voice : Si de multiples redirections d un appel initial atterrissaient sur le «voic », il était enregistré correctement sur la boîte vocale de la personne initialement appelée, indépendamment des redirections. (Le protocole Skinny conserve la trace de la destination initiale de l appel et le transmet à «Unity»). Les quatre fonctionnalités les plus appréciées étaient : 1. La liste des numéros appelants sur absence ou sur occupation qui étaient mémorisés, avec la date et l heure de l appel. 2. La messagerie vocale intégrée dans Exchange, qui permettait l écoute des messages sur son propre téléphone directement commandé depuis l ouverture dans Outlook a. 3. L annuaire automatique incorporé dans le téléphone, par noms ou numéros. (annuaire LDAP) 4. L ouverture d un contact depuis Outlook permettait de numéroter par un «clic» directement sur son téléphone. Satisfaction des équipes IT Les équipes IT étaient satisfaites entre autre pour les raisons suivantes : Une gestion accessible et relativement conviviale. Un accès facilité sur les «CDR» (détail des appels) directement via Excel (en ODBC). Déploiements et déménagement des téléphones facilités. Très peu d incidents. «Disaster plan» facilité (Voir l exemple du Canton de Vaud en Bibliographie : Cisco). Mise en place d une configuration d escalade des appels pour le Help desk en quelques heures, (par adaptation des renvois, lignes groupées et groupes d appels). La NEWRE, satisfaite de mes services, a prolongé encore mon mandat de deux années pour prendre en charge d autres projets comme la migration Windows 2000 et Active directory de l ensemble des postes clients et des serveurs. Satisfaction du constructeur Cisco a pu bénéficier d une référence cliente supplémentaire et recevoir quelques suggestions d améliorations ou de corrections. (Voir la plaquette commerciale publiée par Cisco en annexe 13) Satisfaction de mon employeur Les durées, les budgets et les délais ont été tenus. a Outlook est le nom du logiciel client pour la messagerie Exchange.

47 < 41 > Satisfaction personnelle C était un projet complexe dans des délais courts, avec des interactions techniques et humaines étendues. J ai eu beaucoup de plaisir et de fierté d avoir pu relever ce «challenge». Rétrospective en 2005 Bilan des projets Cinq ans après, la NEWRE comprend presque une trentaine de serveurs et deux SAN en redondance. La salle informatique aménagée de façon anticipée à Leschot est effectivement devenue la deuxième salle machine opérationnelle. Dans son optique d améliorer étape par étape la disponibilité de ses applications critiques, la NEWRE a finalement installé son deuxième Call Manager en Figure 13 Jan.2002, Zurich - Présentation des travaux NEWRE à la conférence "Cisco Converged voice", (Source : NEWRE) En 2003, la deuxième passerelle voix a été installée à Leschot selon mes recommandations en Toutefois, afin de permettre le transport des numéros d appels vers Leschot en cas de panne grave et prolongée sur l Athénée, il était nécessaire de prendre une ligne PRI chez le même opérateur («T- System»). Le risque d une défaillance «opérateur» n est donc pas écarté. En 2001, mes recherches auprès de l OFCOM et de l ITU étaient restées sans solution à cette problématique. Comme prévu, les utilisateurs de Leschot vont bientôt retourner à l Athénée car la NEWRE a pu récupérer une partie des bâtiments qui étaient loués. Le déplacement des postes de travail informatique et des téléphones prendra moins d une journée, sans requérir la moindre reconfiguration (il s agit juste de débrancher puis rebrancher le téléphone et le PC). Le deuxième «Call Manager» restera sur place avec ; la passerelle voix, le deuxième SAN et les serveurs redondants, prêts au pire, en espérant le meilleur pour la NEWRE.

48 < 42 > Figure 14 - Schéma des installations en 2005 Les téléphones IP En 2000, l année 2005 devait voir en Europe le nombre de téléphones IP dépasser celui des téléphones classiques. En 2004 les perspectives de cette bascule prévue pour mi 2006, sont encore repoussées pour 2007 (Gartner : «Forecast : Premises Switching Equipment, Western Europe, »). En Suisse romande, les "téléphones IP" apparaissent dans le secteur privé ; par le biais du câble (Offre Cablecom «Digital Phone»), sous forme de téléphones "analogiques!". Ils sont branchés sur un adaptateur VoIP (modem câble). Les combinés analogiques DECT ou filaires vont décidemment persister encore un temps certain. Le constructeur Cisco Suite à l acquisition de «Active Voice», Cisco était initialement fortement pressentie comme un acteur majeur en solution globale de communication unifiée. En 2005, on constate que Cisco s est bien développé dans la solution téléphonie, mais plus timidement dans la sphère de la communication «All in One», comme nous pouvons le constater sur les schéma Gartner suivants :

49 < 43 > Figure 15 - Gartner VoIP "Magic quadrant" Téléphonie / Communications globales intégrées Les promesses non tenues 1) Des IP-Phones Skinny compatible? D autres constructeurs devaient fournir des postes téléphoniques compatibles avec les «IP phones» Cisco (modèles 7960). Nous les attendons toujours en Europe. L adaptation des postes aux différentes normes Européennes, la faible progression du nombre de postes vendus en Europe et l absence d inter opérabilité avec d autres centraux IP-PBX non Cisco, ont visiblement rendus cette perspective moins «accessible». 2) Des solutions de communication unifiées La NEWRE a installé une solution passerelle FAX «XMediusFAX» pour Exchange (via une passerelle SMTP, connectée sur un accès ISDN dédié mais pas sur la «Voice Gateway» existante). La solution passerelle Voix de Cisco ne fournissait pas de solutions pour faciliter l intégration d un accès «Fax over IP» (FoIP). A priori, c est toujours le cas en Ce serait pourtant techniquement relativement simple à implémenter (norme T.38, «FoIP»). 3) «PWR» et 802.3af Le «Power over Ethernet» (PoE) : La solution Cisco fournissait une solution d alimentation non standard IEEE, car il n existait pas encore de standard concernant «PoE» sur 4 conducteurs. Il existait une solution normalisée IEEE mais elle nécessitait 6 conducteurs (4 Ethernet + 2 «power»). La solution Cisco «Power in Line» sur 4 fils était promise à devenir un standard. C est "presque" chose faîte avec le dernier standard 802.3af. Toutefois, ce "nouveau" standard ne sera pas supporté par les «switchs 3524PWR-XL». Depuis 2003, ces derniers ne sont plus maintenus par Cisco (Voir Bibliographie Cisco : «POE, supported device»). La NEWRE est donc condamnée : 1. Soit à utiliser des périphériques compatibles «PoE» Cisco (et non 802.3af), 2. Soit à changer à nouveau tous ses switchs 100 Mb.

50 < 44 > 4) Une convergence retardée La convergence vers «VoIP», c'est-à-dire l intégration de la voix dans les communications «data», sera plus tardive qu initialement annoncée, principalement en Europe. [Forrester Research, 2003: «Western European VoIP deployment will move slowly, from five per cent of total fixed-voice traffic in 2006 to 100 per cent in 2020»]. Figure 16 -Indicateurs de convergence voix données Voix versus Data en 1999 La convergence en Europe, 2004 Les promesses tenues La solution fonctionne parfaitement, les déménagements de postes n ont jamais été aussi simples. Les mises en œuvre de sites additionnels ou de travailleurs à domicile seraient très facilitées, si la NEWRE en avait eu effectivement besoin. Il a été pris un tel niveau de précaution à la NEWRE, face à la VoIP réputée plus faillible, qu aujourd hui la solution présente un très fort taux de disponibilité. Même multiplié par le nombre de postes et sur les 3 dernières années, ce taux est supérieur à ce qu avait donné le précédent PBX sur sa dernière année. Une exploitation simplifiée mais aussi fastidieuse La gestion au quotidien est relativement aisée, facilement interfacée avec des outils IT comme «Excel» par exemple a. La NEWRE à développé des «routines» pour automatiser certaines tâches d exploitation de la téléphonie (Par exemple : Pour faciliter la gestion et la configuration de groupes d appels). Par contre, simplement pour maintenir la solution sécurisée, des opérations de mises à jour sont requises. Elles ne sont pas nécessairement très lourdes, mais elles sont relativement risquées car le téléphone est le principal outil de travail de la compagnie. Ainsi, les équipes en place ont dû choisir entre : 1. Faire ces opérations en dehors des heures d ouverture des bureaux. 2. Installer une plateforme IP-PBX laboratoire pour faire des tests, afin de pouvoir ensuite exécuter les maintenances pendant les heures de bureau à «moindre risque». Le premier choix avait été retenu par Adventis qui assurait l exploitation la première année. Les équipes internes NEWRE ont repris la suite et ont choisi la 2 solution. a Cela était possible grâce à l ouverture Windows et le support de ODBC

51 < 45 > Pour éviter l acquisition coûteuse d un «Call Manager», un «hack» a été fourni officieusement par Cisco pour permettre d installer le logiciel Call Manager sur un desktop normal pour les tests. Ces opérations se passent généralement bien. Le cluster favorise ces maintenances avec : De très courtes ruptures concernant la capacité d appeler (en général 10 minutes), Sans coupures des communications déjà établies. Toutefois, les informations régulières d une interruption pour maintenance du service téléphonique (une à 3 fois par trimestre, pendant 30 minutes, vers midi trente), vont agacer les usagers. Cela donne une impression de fragilité, puisqu il faut intervenir tout le temps dessus. Je recommande vivement de planifier plutôt ces opérations en dehors des heures «normales». Des fonctionnalités inexploitées Prises dans les impératifs du quotidien, les équipes internes n ont pas investies sur les nouvelles fonctionnalités pourtant disponibles avec les évolutions de la plate-forme IP-PBX de Cisco. Répertoires personnels synchronisés avec Outlook qui permettrait de faire apparaître sur le téléphone le nom de l appelant externe au lieu de son numéro. Un gestionnaire personnel de routage d appel pour permettre le filtrage d appels, et des routages conditionnels (basés entre autres sur le calendrier et le CLI a ). Cryptage des communications «voix». La solution de couplage du PC avec un téléphone (TAPI) s est avérée fastidieuse à maintenir opérationnelle et correctement configurée pour chaque PC. Elle a été abandonnée par plusieurs utilisateurs. Je crois savoir que seule la fonction d identification via un PIN code depuis un autre poste pour pouvoir transporter son propre numéro provisoirement sur ce poste, a été implémentée depuis la mise en service en Les autres fonctions n ont pas été mises en œuvre : soit parce que les équipes internes n en ont pas acquis la connaissance, soit car trop complexe pour les utilisateurs. De façon générale : parce que leurs utilités n étaient pas suffisantes en regard des investissements (humains) requis. a CLI = Calling Line Identification (identification de la ligne appelante)

52 < 46 > Conclusions personnelles Principales difficultés rencontrées Techniques Les quelques problèmes techniques rencontrés n ont pas représentés un obstacle majeur, même si chacun d eux étaient un challenge, car ils pouvaient potentiellement transformer un projet réussi, en un échec. La résolution des problèmes a été facilitée par : L existence d une maquette opérationnelle : Afin d en cerner le contexte par des simulations. Des «logs» et outils d analyses (Snifer) afin de mieux qualifier et tracer les erreurs. La mise en place d un processus d escalade des incidents, jusqu au concepteur (Cisco). Le plus difficile était d acquérir rapidement les informations techniques qui nous manquaient, en particulier sur des notions et technologies nouvelles. Humaines Les principales difficultés concernaient : La gestion des décisions, multiples et réparties. Il fallait faire communiquer un grand nombre de décideurs a. Un bon «leadership» était parfois nécessaire pour éviter de tomber dans le piège de "décisions absurdes". (Voir Jean Morel, Bibliographie en fin de document) Gestion de mon temps : Des délais parfois très courts. En plus de ces multiples projets : Je devais gérer Adventis, d autres clients et supporter l infrastructure Windows de la NEWRE. Elle ne disposait pas encore en interne d ingénieurs systèmes et réseaux. Mener à bien l ensemble et dans les délais donnés a été un véritable challenge. Ethique. J étais délégué pour la gestion d un projet d équipement d une solution de téléphonie pour la NEWRE. J étais aussi partenaire et ingénieur certifié Cisco. Il était difficile de rester objectif et de résister aux pressions. La transparence dont j ai fait preuve dans le «RFP» et vis-à-vis du client, m a permis de rester serein tout au long de ce projet et de conserver leur confiance. a (Le responsable IT, le responsable des infrastructures IT et SG («CTO»), le «CEO», le Chef de la cellule «Leschot», la responsable SG, le responsable télécoms MunichRe ainsi que mon propre Manager d Adventis)

53 Principales causes du succès de ce projet < 47 > Le RFP : est à mon sens la pièce maîtresse du succès de ce projet. Il a posé en terme clair, les objectifs, les contraintes et le contexte avec une excellente transparence. Je répète souvent : "Il vaut mieux un solution imparfaite correctement implémentée, qu'un excellent produit mal utilisé". A la NEWRE, l'investissement temps a été mis en priorité sur la compréhension des besoins et sur l'implication des utilisateurs. Ainsi, la solution Cisco a été adaptée pour satisfaire aux usagers, tout en apportant des nouvelles fonctions et des nouvelles méthodes de travail. Une attention particulière a été prise sur les fonctions perdues, afin de s'assurer qu'elles étaient correctement remplacées ou compensées, ou effectivement inutilisées. Un travail d'équipe : Je renouvelle mes remerciements à toutes ces personnes. (Cisco, NEWRE, Adventis). Mais la principale raison du choix NEWRE pour la «VoIP» est liée à un défi technologique et une passion humaine qui ont portés la solution «VoIP» contre la téléphonie classique. Car ce projet était dirigé et pris en charge par des informaticiens (NEWRE IT et Adventis). Si c était à refaire, principales améliorations Intégrer le plan de numérotation dans le concept Au même titre q un plan d adressage réseau, un plan de numérotation téléphonique propre à l entreprise doit être conçu avant la mise en œuvre. Ce n est pas un composant standard et commun à toutes les entreprises, même s ils présentent tous des similitudes (pour un même pays). Un RFP ou RFI d abord, un pilote après Dans la mesure où les délais le permettent, il est préférable de valider les modèles économiques et d identifier les protagonistes potentiels, avant la mise en place d un pilote. Je recommande vivement de commencer par un RFI («Request For Information», demande d évaluation budgétaire et de faisabilité). Nous avions convenu avec la NEWRE que Cisco était effectivement un fournisseur de référence valable sur ce sujet, et la NEWRE avait volontairement économisé cette consultation. Aujourd hui je pense toujours que c était effectivement justifié, essentiellement car nous avions fait une évaluation quelques mois avant. La recherche d une solution VoIP moins contraignante et plus ouverte Aujourd hui, un plus grand nombre d acteurs et de solutions matures sont présents sur le marché. Il serait très intéressant de comparer à nouveau les solutions disponibles, classiques et VoIP, en intégrant une évaluation plus réaliste des tâches de mises à jour et de maintenances requises. Un RFP qui prendrait mieux en compte le facteur OPEX Les coûts récurrents de maintenances, en termes de charge de travail et de frais financiers, sont une part importante dans les éléments budgétaires. La NEWRE souhaitait volontairement reprendre en interne la maîtrise technologique des équipements d infrastructure. Sans cela, les coûts de maintenance externe d une solution IP-PBX se seraient avérés nettement plus élevés qu une solution PBX classique (en 2000). Ces prix ont motivés l installation d un cluster à la place d un contrat d intervention en 4 heures, et ont freinés la mise à niveau vers les nouvelles versions du «Call Manager» (Version 4).

54 < 48 > Je réfute l argument en faveur de la «VoIP» publié sur ZDnet a concernant l économie en terme de contrat d exploitation avec un prestataire externe. Il faut comparer des choses comparables. Le fait d augmenter la charge de travail interne, pour arrêter un contrat externe, n est absolument pas une économie, surtout pour des équipes «IT» généralement déjà bien chargées. Mieux communiquer avec les utilisateurs Le téléphone est l objet dont l employé d assurance à le plus besoin, avant son ordinateur. C est un accessoire dont le dysfonctionnement agacera plus vite que pour un PC. Il y a un facteur émotionnel important. Pourtant, sans son ordinateur, l usager pourra probablement moins produire que sans son téléphone. Dans un projet de renouvellement complet des combinés téléphoniques (la seule partie perçue par les utilisateurs), tous les usagers doivent être impliqués. Il faut qu ils puissent s approprier cette solution et devenir fier d avoir ce type de téléphone précurseur. C est un travail de communication, et c est difficile. Au sujet de la Téléphonie sur IP (IPTel) Un marché de niche, pour combien de temps encore? Une solution VoIP ne se justifie pas par elle-même et requiert une synergie avec un projet connexe, comme un central d'appels interfacé avec un ou plusieurs systèmes d'information. Le projet «Phone 2000» à la NEWRE n a pu voir le jour que grâce à un ensemble de circonstances techniques particulières (entre autres) : Un Câblage 4 fils, dont l extension était limitée par le statut «Monument classé historique». L intégration de la téléphonie au sein du département IT. L extension à Leschot, raccordée par une fibre avec IP. Un LAN redondant et performant. Une direction IT de la NEWRE portée sur les nouvelles technologies. La présence sur le site d un partenaire performant et innovateur (Adventis). Sans ces conditions particulières, il aurait été difficile d envisager, en 2000, une solution «IPTel» dans le cadre d une PME comme la NEWRE. Des grandes structures géographiquement très disséminées mais sur une étendue relativement limitée (Citadine ou Nationale) peuvent rapidement exploiter les avantages de la VoIP (Exemple de l état de Vaud). Ces structures exploitent un WAN bien dimensionné (souvent de type MAN). Ils peuvent bénéficier rapidement de la consolidation de plusieurs petits centraux téléphoniques en un seul, avec la suppression d une multitude de lignes téléphoniques. Des économies d exploitation substantielles peuvent être effectivement réalisées. En PME, la solution «IPTel» me semble surtout pouvoir se développer avec l externalisation. La Voix sur IP permet : 1. Aux «téléphonistes» d étendrent leurs offres aux services d accès IP et Ethernet (exemple de Swisscom qui propose des accès Internet et des téléphones sans nécessiter de central téléphonique local, tout en louant des «switchs» Ethernet), 2. Aux entreprises «réseaux» de développer leurs offres avec de la téléphonie (ADSL, Opérateurs câble). a Voir Bibliographie

55 Des centraux IP ouverts ou fermés? < 49 > Il est pratiquement certains que dans l'avenir, tous les centraux PBX seront des ordinateurs plus ou moins spécialisés «VoIP» (Unix, Windows ou autres). Cette évolution est et sera visiblement plus lente en Europe que sur les Etats-Unis [Forrester Research, 2004 : «Dans quinze ans, plus une seule organisation n'utilisera encore les systèmes de téléphonie traditionnels» (Source : Belgacom)]. Certains resteront des "boîtes noires" avec un coût de maintenance faible, et d'autres des plates-formes ouvertes, comme la solution Cisco. Les solutions ouvertes adressent un marché où la téléphonie doit évoluer et pouvoir être facilement intégrée avec l IT (Par exemple pour un «Call Center», qui doit pouvoir interfacer une ou plusieurs applications «CRM a»). Les autres entreprises devraient plutôt se tourner vers une solution "boîte noire". Cisco a d ailleurs sorti depuis, une solution boîtier (Cisco Call Manager «Express»), limitée à moins de 250 postes. L ouverture sur Windows présente des avantages et un potentiel intéressant : Création des scripts d exploitation ODBC (à partir de simples fichiers Excel) Facilitation de l intégration dans les processus IT existants Les handicaps de la «VoIP» 1) Des standards insuffisants Les principaux freins à la téléphonie sur IP sont à mon avis un manque au niveau de la standardisation. A quoi cela sert d utiliser une plate-forme IP-PBX Cisco "ouverte", si on ne peut y raccorder que des téléphones Cisco? Toutefois, il faut relativiser cette question. Cisco a ouvert son protocole MGCP pour la passerelle VoIP, il est établi maintenant comme un standard à l IETF (RFC 3435, ex 2705). Il complète les protocoles H.323 et SIP. Mais si cela est suffisant pour de la téléphonie sur Internet, ce n est pas le cas pour gérer les facilités associées à un PBX. Cisco utilise son protocole propriétaire «Skinny». Seuls des IP-Phones compatibles Cisco peuvent être installés sur un «Call Manager». Les autres clients téléphoniques sont limités à H.323. L existence même de deux standards de signalisation différents comme SIP (issu du monde «data» : l IETF) et H.323 (issu du monde «Telecom» : par l ITU), montre bien une maturité grandissante, mais non encore finalisée, même en A quand un protocole «Skinny-like» universel? Probablement une évolution de SIP (porté par Internet) s imposera comme un standard pour les IP-Phones, et certainement pas la solution Cisco Skinny. Je ne serais pas étonné que des services «Call Manager like» deviennent directement 'externalisables', un peu comme des clients de messagerie avec leur serveur directement sur Internet. A l instar des solutions «Skype», peut-être verra-t-on dans les PME la disparition pure et simple des «Call manager»? C est à mon avis ce qui menace le plus l avenir des constructeurs de PBX, surtout s ils continuent de ne pas inter opérer, ce qui est fort probable. 2) Des LAN et WAN encore mal adaptés Rares sont les entreprises qui disposent de LAN IP avec «ToS» et encore moins des switchs Ethernet «CoS». La NEWRE ne voulait prendre aucun risque. D autres structures peuvent tabler sur la faible probabilité de saturer un switch de distribution, mais le réseau Ethernet reste "sensible" aux engorgements. Cette situation devrait évoluer rapidement dans les années à venir. a CRM = Customer Relation Management (Solution de Gestion de clientèle)

56 < 50 > 3) La sécurité C est à mon avis le plus grand facteur «frein» en 2005, mais il est peu évoqué. Tout périphérique IP est un vecteur de risque. Il y a déjà les anti-virus pour PDA, à quand les anti-virus pour IP-Phone? Plus sérieusement, une solution Téléphonie IP professionnelle ne pourra s appuyer que sur des fournisseurs capables d assurer les mises à jours de sécurités nécessaires, facilement (automatiquement) et très rapidement. Mon avis sur le «Call Manager» En 2000, nous avions déjà réclamé à Cisco la mise à disposition d une interface d exploitation simplifiée et limitée à des non «administrateurs a». Aujourd hui, Cisco sort des interfaces logicielles pour pouvoir faciliter la mise en œuvre et l exploitation de ses solutions «IPTel». La mise en service d une solution IP-PBX, malgré sa relative convivialité grâce à une interface Web, reste freinée par la capacité humaine à assimiler toutes les fonctions et écrans de configurations. Dans un environnement «classique», la configuration et la maintenance sont sous-traitées à un technicien spécialisé, et l exploitation en interne est réduite à son strict minimum. Je pense que nous retrouverons bientôt ce type d organisation pour l IPTel. La solution idéale pour la NEWRE? Aujourd hui, la NEWRE ne pourra pas facilement évoluer vers le gigabit pour les postes de travail. Il serait nécessaire de refaire totalement le système de câblage de 1991 pour mettre en place une solution UTP avec des câbles moins épais pour en augmenter le nombre. Ceci permettrait de pouvoir installer 8 conducteurs au lieu de 4 afin d être aux normes. Cette solution avait été proposée initialement, mais elle était évaluée à plus de 100'000 SFr. Le CAPEX b du projet étant limité, cette solution avait été écartée. Si les moyens avaient été disponibles, cette solution aurait été à mon avis un investissement valable. Cela aurait pu modifier la vision du projet «Phone 2000». La mise en place en place d IP-Phones switch avec «PoE» n aurait plus été autant nécessaire. Avec une consultation plus élargie, peut-être aurait-il été envisageable d économiser sur la solution de téléphonie, pour investir plus vers le Gigabit Ethernet? En Conclusion Même sans cette contrainte importante de câblage, je continue de penser que nous avions pris une excellente option dans le contexte existant. Cette solution reste valable en 2005 avec un fort potentiel et elle continue d évoluer. a Administrateur : Dans le sens IT du terme, veut dire celui qui assure l installation et la configuration complète de l architecture (Il possède tous les droits). b Capital Expend : Dépenses initiales, voir le Glossaire en fin de document.

57 < A.1 > ANNEXES TECHNIQUES 1. Architecture VoIP Une solution PBX classique est très généralement de type centralisé sous forme d un «boîtier» unique sur lequel se raccordent tous les téléphones et toutes les lignes Télécom. L architecture d une solution IP-PBX se présente sous une forme plus répartie, comprenant principalement les trois types de composants suivants : Les téléphones IP, ou périphériques clients («Soft Phone», «H.323 endpoint», ) Cela peut aussi être un périphérique analogique sur un adaptateur VoIP (ex. 1 fax Groupe 3) Les passerelles voix ; entre le réseau IP et le réseau téléphonique («Gateway PSTN/VoIP») Pour les liaisons externes avec le réseau téléphonique public (PSTN) Pour des liaisons internes avec un PBX classique (FXO, FXS, ISDN BRI, ISDN PRI, ) Pour connecter de multiples clients analogiques internes (Fax groupe 3, DECT, téléphones analogiques supportant FXS ou FXO) ou encore numériques (Fax groupe 4 ISDN) Le commutateur d appels téléphoniques ; va mettre en relation les «clients» avec d autres «clients» ou bien avec une passerelle. C est le «Call Manager» dans la solution Cisco. Figure 17 - Architecture AVVID Cisco (exemple pour 100 postes, source Cisco) Il est remarquable que les communications VoIP (G.711 à 64 kb) ne transitent pas via le «Call Manager», mais directement entres les «IP-Phones» en interne, ou d IP-Phone à «Gateway» en externe. Le Call Manager établi les communications. Il est averti en fin de communication par les clients, mais ne transporte pas la voix, sauf dans le cas d une audio conférence (en nombre limité). Pour des besoins plus importants en nombre de conférences, ou avec des débits «comprimés» pour le WAN (G.729 à 8 kb), des «Gateway» avec des cartes spécialisées sont disponibles (G.711, G.729 Endpoints). Cette architecture offre une grande souplesse et un excellent potentiel. Par exemple : nous avons pu intégrer un simple PC avec le logiciel «NetMeeting» de Microsoft, comme un des périphériques

58 < A.2 > «VoIP» de l architecture. Ce PC a pu émettre et recevoir des appels, comme un téléphone, grâce au standard H.323 a. Toutefois, il ne pouvait pas retransmettre l appel à un autre poste par exemple, ou toute fonction qui fait appel à une signalisation plus complexe. Les IP téléphones de Cisco utilisent pour cela un protocole Cisco propriétaire : Le protocole Skinny (ou SCCP pour «Skinny Client Control Protocol»). Cisco a du aussi créer le protocole MGCP, publié en RFC, pour supporter le transport de ces signalisations au niveau de la «Gateway» (Voir en Annexe 4). L architecture «IP Telephony» présente une plus grande complexité et par conséquent une certaine fragilité face aux solutions Classiques. 2. La mise en place d une fibre optique «noire» La mise à disposition d une connectivité «IP» de type «MAN» était nécessaire pour le projet «Leschot». Pour cette partie, j ai dû rapidement apprendre et comprendre les principes de calculs de budgets pour l allumage d une fibre optique monomode (SMF). Figure 18 - Budget optique Monomode prévisionnel pour la liaison Leschot (P. Kotté) Le calcul réalisé pour la NEWRE devait être établi sur le «pire» scénario. Dans le cas d une rupture de la ligne normale (un percement erroné de la chaussée par exemple), il a été demandé aux SIG de fournir la longueur totale de la nouvelle dérivation et le calcul de son atténuation, en fonction du nombre de NI (Nœud d Interconnexion) traversés. a Voir ITU-T, Bibliographie

59 < A.3 > 3. Conception initiale : architecture VoIP pour la NEWRE Figure 19 - Concept initial NEWRE : L'architecture Voix sur IP Dans ce schéma, l architecture comprend un Cisco Call Manager (CCM) par site et une liaison PRI ou BRI interne pour communiquer entre le PBX classique et l IP-PBX «Call Manager». Ce schéma sera ultérieurement corrigé pour ne comprendre aucune ligne directe entre l ancien et le nouveau PBX. La cohabitation étant temporaire, la communication entre les deux PBX sera donc assurée par

60 < A.4 > le réseau téléphonique public. Les «Call Manager» locaux sur les sites satellites ont aussi été supprimés. Ces deux abandons représentent des économies très significatives. 4. Les passerelles Voix sur IP Une «Voice Gateway» est la passerelle entre le monde IP et le monde «Voice PSTN» (le Réseau Téléphonique Commuté Public ou RTC). Si l interface du côté IP est clairement un port «Ethernet», l interface du côté PSTN est plus variable. Tableau 9 -Types d interfaces rencontrées dans le monde de la voix (PSTN) Interface Protocole Usage Ethernet MGCP /IP Signale les appels au «Call manager», assure la communication G.711/G.729A sur IP avec les «IP-Phones» Un port analogique téléphonique est à la base une simple paire de cuivre, mais avec quelle signalisation, et dans quel sens? Analog FXS Port analogique (foreign exchange station) Analog FXO Port analogique (foreign exchange office) Analog E&M Port analogique (Earth & Magnet) ( Analog DID/CLID Port analogique avec transport du numéro appelant Des interfaces PSTN numériques, mais pas en IP, il faut aussi configurer le sens de la signalisation (DTE ou DCE) : Digital T1 CAS T1 = 1'540 kb/s, (Channel Associated Signaling) USA, un concurrent de ISDN, non compatible. Digital E1 CAS E1 = kb/s. USA. Digital E1/R2 Europe, Latin America, Australia, and Asia (CCITT-R2, ITU-T Q.400-Q.490). Digital PRI ISDN à 1920 kb/s utilisables, 30 canaux B (64 kb/s), 1 canal D (64 kb/s) (Sauf aux USA, 23 canaux B, on peut perdre 7 canaux si on se trompe au «setup») Digital BRI ISDN à 128 kb/s, 2 Canaux B 64 kb/s + 1 canal D (16 kb/s). Digital DID/CLID Idem que l analogique, mais en numérique Tableau 10 - Codec de numérisation de la voix CODEC pour la compression de la Voix et le transport numérique (IP ou autres) G kb/s Sur IP = 80 kb/s G.729? G.729a 8 kb/s Sur IP = 24 kb/s G kb/s

61 < A.5 > 5. Echo et «VoIP» La problématique de l écho, nous sort du monde «IT» pour entrer dans celui de la Voix. Un écho est la perception de sa propre voix avec un décalage dans le temps. Selon la force du son la tolérance de l utilisateur variera entre un décalage de 10 à 100 ms. En moyenne, c est de l ordre de 30 ms pour être gênant, et 60 ms pour être insupportable. La source d un écho nécessite les 2 conditions suivantes : - un correspondant équipé d une ligne analogique, qui provoque une interférence. Les lignes numériques (ISDN) ne génèrent pas d interférences. - un correspondant très éloigné, ce qui va générer un «petit» décalage du signal dans le temps. Ces décalages de 10 à 15 ms, n étaient pas perceptibles par l utilisateur depuis un téléphone classique. Mais la «VoIP» introduit un décalage additionnel volontaire et obligatoire de l ordre de 30 ms. Le résultat obtenu est donc devenu de 40 à 45 ms, ce qui génère un écho pénible. Figure 20 - Principale source d'écho - Les lignes analogiques (source : Cisco) La «VoIP» est obligée d introduire ce décalage («Jitter») pour lui permettre de réceptionner puis de réordonner les paquets IP et les remettre dans le bon ordre (car ils arrivent en vrac). Ce décalage sera de 30 ms à l aller et 30 ms au retour. C est la raison pour laquelle le seuil de tolérance d une variation de latence de 30 ms est plus important que la latence elle-même. Car les paquets reçus audelà du délai fatidique de 30 ms, seront jetés (une microcoupure dans la communication audio). Les principales sources de communication avec écho, seront les appels vers des particuliers en pleine campagne, car la plupart des entreprises sont raccordés en numérique (ISDN). Pour palier à ce problème, la passerelle VoIP (PSTN/IP) doit intégrer un suppresseur d échos («echo canceller», ITU G.165, G.168). Il va écouter d abord, pour essayer de repérer un écho. Une fois repéré, il va l annuler ou l atténuer fortement. Les deux premières secondes de communications peuvent donc se faire avec écho, puis aller mieux ensuite. Mais, il y a bien souvent des réglages fins et subtils nécessaires («tuning»). Parmi les paramètres de ces réglages : ECC, Echo Cancellation Coverage (Tail Length) : C est la durée de la plage de l écoute. L écho doit avoir une longueur (durée) inférieure à cette valeur, mais cette valeur doit rester le plus bas possible. La valeur maximale est de 32ms pour la norme G.165 qui équipait les «Cisco Gateway». Au-delà, l écho ne pourra pas être supprimé. Output attenuation: permet de réduire le son émis pour limiter le retour d écho, mais avec une valeur trop grande, le correspondant n entendra plus rien. Input gain : permet de modifier le signal avant qu il n entre dans le système de suppression d écho. Mais là aussi, trop peu et nous n entendons plus rien. C est un véritable jeu de patience.

62 < A.6 > 6. Architecture LAN intermédiaire (Disaster II), niveau 2 de l OSI. Dans une étape intermédiaire en attendant la finalisation du projet «Phone 2000», le projet «Disaster II» a prévu de réutiliser les équipements «HUB» existants. Figure 21 Disaster II, étape 1 : Architecture Double Backbone Ethernet Gb Ainsi, il a été possible de mettre en place et de bénéficier d une dorsale Ethernet Gigabit, avec redondance, sans investir immédiatement sur la totalité des switchs de distribution capillaire, dit tertiaire en Suisse («access level» en anglais). 7. Architecture réseau TCP/IP (niveau 3 de l OSI) Dans le même temps, le réseau allait migrer sur la nouvelle architecture IP basée sur le plan d adressage que nous avons construit avec Adventis pour la NEWRE. Cette architecture est en corrélation avec le niveau 2, afin de permettre la prise en compte ultérieure des paramètres «ToS» au niveau IP (voir en annexe 10). Les «VLAN» Ethernet ont été définis selon les normes en vigueur afin de séparer les trafics prioritaires (la voix), des trafics moins prioritaires (data). Dans le schéma ci-dessous, on peut voir le VLAN par défaut et d origine (VLAN 1), qui a été vidé afin de transférer touts les équipements vers un autre VLAN mieux adapté à leur classe de service. Dans le plan d adressage VLAN et IP établi, le site Leschot a été intégré au même titre que les deux bâtiments existants, car grâce à la mise en place du «MAN», ce site est intégré directement sur le «backbone Gb». Leschot et l Athénée forment ainsi une sorte de campus unique à 3 bâtiments.

63 < A.7 > Figure 22 - La nouvelle architecture IP de la NEWRE 8. Planches techniques détaillées Afin d assurer le bon déploiement de tout les équipements matériels, j ai réalisé des schémas d implantation et de raccordements détaillés et à l échelle, dont voici un exemple ci-dessous : Figure 23 - Exemple : Schéma d'armoire de distribution

64 < A.8 > Ces planches étaient indispensables pour permettre la prévision des volumes et l approvisionnement des bonnes quantités et longueurs de câblages par exemple. 9. Prémaquette Adventis La mise en place de la maquette opérationnelle de NEWRE était limitée à 4 semaines, sans possibilité de prendre plus que quelques jours pour la mise en place. Afin d en valider la configuration, une répétition est réalisée en amont chez Adventis. Ainsi «les plâtres» auront pu être essuyés avant la mise en place du pilote chez le client. L objectif était aussi d assurer une redondance concernant le support des solutions de Voix sur IP chez Adventis en formant plusieurs personnes en interne, l un de ces ingénieurs EPFL a été assuré la mise en place de l extension «Unity Voic » pour compléter la solution «IPTel». Figure 24 - Maquette préliminaire chez Adventis Cette maquette et une solide formation avec un transfert de connaissances de la part d un expert AVVID, ont permis à Adventis de rapidement maîtriser le sujet.

65 < A.9 > 10. QoS : Une question de ToS et de CoS La qualité de service sur les réseaux nécessite de trier les paquets grâce à un marqueur de priorité. Ceci permet aux routeurs IP de gérer des queues de traitements en fonction de la valeur du «Tag ToS». Mais pour pouvoir gérer la priorité au niveau des Switch (OSI Level 2), il faut utiliser le «CoS» au niveau de la trame Ethernet. Peu de switchs prennent en charge le «CoS», il est nécessairement associé à la configuration de «VLAN». Figure 25 - QoS = ToS+CoS (Source : Cisco) Dans IPv4, le ToS comprend le DSCP sur 6 bits qui inclus «IP precedence» sur 3 bits. Tableau 11 - Classes de service (sources Cisco) Layer 2 Layer 3 DSCP Class of Service IP Precedence CoS 0 Routine (IP precedence 0) 0-7 CoS 1 Priority (IP precedence 1) 8-15 CoS 2 Immediate (IP precedence 2) CoS 3 Flash (IP precedence 3) CoS 4 Flash-override (IP precedence 4) CoS 5 Critical (IP precedence 5) (EF) CoS 6 Internet (IP precedence 6) CoS 7 Network (IP precedence 7) Adresses Internet Numéros d urgences (CH) Urgences int. Adventis SA NEWRE MunichRe Cisco Swisscom SIG OFCOM : chnischevorschriften/pta_1_3_version7_f.pdf Wikipedia : La société Swisscom est l équivalent de France Télécom pour la Suisse. Services Industriels de Genève :

66 12. Organismes de normalisation < A.10 > Tableau 12 - Organismes de normalisation Organisme Désignation/Domaine Informations Etendue 3GPP 3rd Generation Partnership Project Organizational Partners are ARIB, CCSA, ETSI, T1, TTA, and TTC US, Mondiale ANSI American National Standards Institute US APNIC Internet RIR Adresses IP Asie ART Organisme de régulations Télécoms FR Comité ONP Régulation Télécoms CE ETSI European Telecommunications Standard Institute ETS 300 EU F.C.C. Federal Communications Commission Organisme de régulation C.E.M. 30 à 230 MHz en Europe, 54 à 216 MHz aux USA. US gov. IANA Internet Assigned Numbers Adresses IP + Top-level Domains (TLD)+ARPA Mondiale ICANN The Internet Corporation for Assigned Names and Numbers Top level Authority Mondiale IEC International Electrotechnical Commission (ISO subdiv.) ISO/IEC1180: = 1000BT Mondiale IEEE Electrical and Electronics Engineers IEEE : Ethernet Mondiale IETF Internet Engineering Task Force RFC pour les standards IP Mondiale IMTC International Multimedia Telecommunications Consortium Promotions de standards Voice and Video Mondiale INTERNIC Internet Noms de domaines.3 TLD (ex,org),.net,.edu, ISO International Organization for Standardization Qualité : ISO 9000 Codes : liste pays Mondiale Mondiale ISOC Internet Domaines.org Mondiale ITU-T (old CCITT) International Telecomunication Union Telecommunications Sector. UIT en Français. ITU-T : Telecom, R : Radio Ex. ; ITU G.703, G.704, G.706 Mondiale UN N.E.N.A. N urgence, 911 (norme E911) Télécoms USA OFCOM BAKOM L'Office fédéral de la communication Régulateur de la Confédération Suisse dans les télécommunications et la radiodiffusion CH RIPE NCC Internet RIR Adresses IP EU/AF TIA Travel Industry Association of America US W3C World Wide Web Consortium Mondiale

67 < A.11 > 13. Plaquette commerciale réalisée par Cisco «Case Study»

68 < A.12 > Page 1/4 Page 2/4

69 < A.13 > Note de l auteur : Ils ont repris mon schéma mais avec quelques erreurs, voir la Figure 7. Page 3/4

70 < A.14 > Page 4/4 Lien en référence :

71 < A.15 > 14. Copie du RFP

72 < A.16 >

73 < A.17 >

74 < A.18 >

75 < A.19 >

76 < A.20 >

77 < A.21 >

78 < A.22 >

79 < A.23 >

80 < A.24 >

81 < A.25 >

82 < A.26 >

83 < A.27 >

84 < A.28 >

85 < A.29 >

86 < A.30 >

87 < A.31 >

88 < A.32 >

89 < A.33 >

90 < A.34 >