Memoire IDPE at 2005 Pascal Kotte at ESS

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

<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.
Memoire_IDPE-2005Kotte@Essi-Phone2000_v1.02.docx IDPE@kotte.net
< 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.
< 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 a–e
Bibliographie & références 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 2001 ............................................................................ 4
Les demandes et les attentes de la NEWRE ............................................................................ 6
Les objectifs ............................................................................................................................. 6
Les contraintes ........................................................................................................................ 6
Les projets connexes (contexte) .......................................................................................... 8
Les besoins............................................................................................................................. 11
La réalisation ................................................................................................................................. 12
La démarche .......................................................................................................................... 12
Le concept ............................................................................................................................. 15
Planification ........................................................................................................................... 21
Le pilote d’essai ..................................................................................................................... 25
Le RFP (Appel d’Offres) .................................................................................................... 29
La mise en œuvre pour Leschot ........................................................................................ 31
La mise en œuvre pour l’Athénée...................................................................................... 34
Conclusions .................................................................................................................................. 39
Bilan en 2001 ......................................................................................................................... 39
Rétrospective en 2005.......................................................................................................... 41
Conclusions personnelles .................................................................................................... 46
< iv >
Annexes Techniques ..................................................................................................................... 1

1. Architecture VoIP .................................................................................................... 1
2. La mise en place d’une fibre optique « noire » .................................................... 2
3. Conception initiale : architecture VoIP pour la NEWRE ................................ 3
4. Les passerelles Voix sur IP ..................................................................................... 4
5. Echo et « VoIP » ...................................................................................................... 5
6. Architecture LAN intermédiaire (Disaster II), niveau 2 de l’OSI. .................. 6
7. Architecture réseau TCP/IP (niveau 3 de l’OSI) ............................................... 6
8. Planches techniques détaillées................................................................................ 7
9. Prémaquette Adventis ............................................................................................. 8
10. QoS : Une question de ToS et de CoS ................................................................. 9
11. Adresses Internet...................................................................................................... 9
12. Organismes de normalisation .............................................................................. 10
13. Plaquette commerciale réalisée par Cisco « Case Study » ............................... 11
14. Copie du RFP ......................................................................................................... 15
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.
<v>
TABLE DES ILLUSTRATIONS
Numéro Page
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 .................................................................................. 12
Figure 5 - Architecture VoIP finale envisagée au départ du projet ................................................................................... 15
Figure 6 - Installation en mode Mixte, Fax migrés, IP-PBX en cluster. .......................................................................... 19
Figure 7 - Installation en mode full IP-PBX, en cluster avec double accès voix. .......................................................... 21
Figure 8 - Architecture du pilote (Bleu : existant, Rouge : ajouté)..................................................................................... 26
Figure 9 - Récapitulatif des coûts (SFr HT) des offres proposées .................................................................................... 30
Figure 10 - Migration : La cohabitation PBX et IP-PBX, Fax existants. ......................................................................... 32
Figure 11 - Enquête de satisfaction auprès des utilisateurs LESCHOT (NEWRE) ..................................................... 34
Figure 12 - Enquête de satisfaction détaillée globale (NEWRE 2001) ............................................................................ 39
Figure 13– Jan.2002, Zurich - Présentation des travaux NEWRE à la conférence "Cisco Converged voice", (Source :
NEWRE) ........................................................................................................................................................................................ 41
Figure 14 - Schéma des installations en 2005 ......................................................................................................................... 42
Figure 15 - Gartner VoIP "Magic quadrant" Téléphonie / Communications globales intégrées ............................. 43
Figure 16 -Indicateurs de convergence voix données .......................................................................................................... 44
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 Page
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. ................................................................................................ 13
Tableau 4 – Remaniement de la planification des projets NEWRE................................................................................. 14
Tableau 5 - Plan simplifié du projet "Phone 2000" .............................................................................................................. 23
Tableau 6 - Fonctionnalités principales perdues et gagnées avec Cisco Call Manager v 3.0 (NEWRE) ................. 27
Tableau 7 - changement de la fonction "numéros abrégés" ............................................................................................... 27
Tableau 8 - Grille de tests ........................................................................................................................................................... 32
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 ............................................................................................................................ 10
Tableau 13 -Les standards suivants ont été mis en œuvre dans les projets NEWRE (2000) : ...................................... f
<1>
Prologue
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 « Voicemail ».
La NEWRE décida de séparer et de créer les trois projets suivants :
1. « Disaster II » (Nouveau « LANa ») 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 2000. 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 2001. « Phone 2000 » était alors initialement repoussé à 2001.
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)
<2>
Chapitre 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 2000.
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)
<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 100BTc »
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)
<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 Cb utilisée, un « subnetc » 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
WANd 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 2001. 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é « QoSe » au niveau de ces deux switchs « Backbone », mais aussi au niveau des
switchs de distribution (d’étages).
 Une gestion des VLANf (802.1Qg).
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
<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’OSIa. Au niveau
3 : Les deux « switchs » routeurs se partagent le routage IP des « VLANs » en utilisant le protocole
Cisco « HSRPb » pour la redondance des passerelle IP par défaut (« Default IP Gatewayc »). 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 2001. 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.
<6>
Chapitre 2
LES DEMANDES ET LES ATTENTES DE LA NEWRE

Les objectifs
Objectifs Businessa
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 travailb à la nouvelle adresse, pour février 2001.
 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 Swisscomc.
 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
<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 5a 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
(« Voicemail »), 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)
<8>
Les projets connexes (contexte)

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. 2000 Déc. 2000 Fév. 2001 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 FOa (Gbb
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 « VoIPc » 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)
<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 « IPTela » 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 « RFIb » 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 SFrc 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)
< 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
Gba 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 PRIb 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 PBXc 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)
< 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 L’existence d’un lien IP Un lien FO permet de Pour des raison de
avec Leschot performant est une donnée considérer Leschot comme confidentialité et
importante du projet, en un 3° bâtiment "local". performances, une solution
faveur d’une solution VoIP FO « noirea » sera retenue
(pas obligatoire « IPTel ») (Voir en annexe 2).
Augmenter la disponibilité La présence d’un LAN C’est la motivation du C’est la motivation du
et les performances de la performant et moderne est projet Disaster II. MAN ci-dessus.
connexion des postes un facteur clef, en faveur Double Backbone Gb. 2 paires de FO doublent
informatiques sur leurs d’une solution VoIP. l’accès IP.
« Full Switching 100Mb »
serveurs
Assurer la disponibilité des Double accès opérateur Pour VoIP : Il faut mettre VoIP: Option 2° passerelle
communications téléphonique ? en place des switchs voix à Leschot. 2 paires de
téléphoniques Indépendance électrique. Ethernet avec UPS et PoE FO doublent l’accès IP.
Assurer la transparence de Un central téléphonique Rendu possible avec le Numéros de téléphones
la localisation physique du unique pour les deux sites ? MAN. internes courts pour
collaborateur l’Athénée
Remplacer le central C’est la motivation VoIP : Récupérer des Une solution téléphonique
téléphonique existant principale de « Phone prises dans les bureaux. compatible avec Phone
2000 » 2000.
Réduire et contrôler les Faire une consultation afin VoIP : unifier les 2 réseaux Eviter un deuxième PABX
coûts de comparer les prix. et faciliter l’administration et une 2° ligne
Analyser et contrôler les du réseau.
communications
Un équilibre entre la Une solution modulaire qui Automatiser la surveillance La redondance VoIP peut
demande de disponibilité, pourra évoluer. des services. être ajoutée par la suite, et
et la réduction des coûts Unifier les deux réseaux bénéficier aux 2 sites.
Maintenir la continuité Interruptions hors des Interruptions limitées à

pendant les migrations heures de bureaux. 30mn : 12h30-13h00
…
L’expression de ces besoins a été simplifiée et synthétisée dans le RFPb (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)
< 12 >
Chapitre 3
LA RÉALISATION
La démarche
Figure 4 - Une démarche par étapes prudentes et professionnelles
RFP
$
Partenariat Décision
1. Pilote
Modélisation « Live »
Théorique 2.
Idée Concept
Déploiement
Maquette
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 AVVIDa 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)
< 13 >
Tableau 3 - Partenariat entre Adventis, Cisco et NEWRE.
Investissements Bénéfices
Adventis  Formations interne et externe  Compléter ses compétences « VoIP »
 Une maquette opérationnelle pour la et Téléphonie sur IP pour en obtenir
la certification Cisco
 Etendre son catalogue de solutions
formation interne et préparer la
maquette NEWRE
 Une plate-forme Cisco «IPTel» pour
son propre usage
Cisco  Un contact technique pour du  Un partenaire certifié téléphonie pour
support et pour faciliter les échanges la Suisse Romande
d’informations avec les responsables  Une éventuelle référence client dans
produits AVVID de Cisco les assurances
 Un « feedback » technologique sur
leur solution
NEWRE  Participation financière à l’acquisition  Tester complètement cette solution en
technologique réalisée par Adventis production réelle à moindre frais, afin
 Fourniture de son environnement d’envisager une implémentation réelle
pour les tests « in live » 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 (RFPa), 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)
< 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. 2000 Déc. 2000 Fév. 2001 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) MeOa 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
< 15 >
Le concept
Architecture « VoIP »
La solution de téléphonie sur IP Cisco « IPTela »
Avant de mettre en place un pilote, il est nécessaire de le concevoir. Le concept VoIP suivait les
recommandations de Cisco (Architecture AVVIDb), mais il était trop coûteux (Voir en annexe 1 et 3).
Les coûts majeurs sont portés par les « Call Managerc » (IP-PBX) et les passerelles voix (en particulier
les interfaces ISDNd 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)
< 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/sa sur les WAN
 80 kb/sb 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 2000. 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.1Qd).
Ainsi le trafic « data » reçoit un « CoS » (802.1p) normal, et le trafic ‘voix’ reçoit un « tage » 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 (SFTf) 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
< 17 >
Alimentations (PoE)
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 « PoEa » 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’IEEEb par Cisco.
Nos contacts Cisco nous ont alors « prédit » que la solution « PoE » de Cisco sur 4 fils, allait bientôt
être normaliséec. 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.
< 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 2000. 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.
< 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 (PSTNa).
a PSTN = Abréviation internationale pour désigner le réseau téléphonique mondial (Voir glossaire).
< 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 (SDAa) 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.
< 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».
< 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.
< 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"
< Nov.2000 Déc.2000 Janv.2001 Févr.-01 Mars.-01

Oct.2000
Concept Fait Corrections Correct° Correct° Correct°
RFP Emis Dépouillé
Pilote @adventis @NEWRE
Business test
Décision Visite MRa 1° Déc. Athénée?
Télécom (PRI) Commandé Installé
MeO IT Préparat° Installat° Doc
Voice Mail Préparat° Installation
Install FOb Commandé Installation Allumage
MeO Leschot Préparat° Installat° Evaluat°
MeO Athénée Migration Préparat°
locataires
Phases 1. Pilote 2. Cohabitation (Leschot) 3. Finale
Extra Eléments externes au projet mais qui en conditionne le déroulement

Décisions « Miles stones », barrière décisionnelle définie dans le temps.
Résultats 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)
< 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 Phonea »
 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).
< 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/PSTNa) 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)
< 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 :
< 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 Gains
 Pas de protection par PIN code  Administration simplifiée
 Pas de renvoi de son poste  Conférences (interne et externe)
depuis un poste tiers (*) 
 Pas de rappel automatique sur occupation
Annuaire
 Statistiques d’appels au format ODBCa (Excel)
 Pas de fonction chef secrétaire intégrée  « 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 Après avec Cisco TAPI

Une liste de numéros « importants » est remise à un Numérotation au « clic » :
pool de secrétaires. Ces numéros sont importés dans Un utilitaire permet de faire apparaître le téléphone
le PABX sous forme de numéros à 6 chiffres. Une Cisco comme un « voice modem » sur le PC de son
liste « papier » avec les numéros abrégés est diffusée choix. Il est possible de l’utiliser pour déclencher
dans toute la NEWRE, et publiée dans un fichier directement la numérotation du téléphone ou du
Excel. GSM d’un contact Outlook.
Mises à jour rare, Partage des contacts dans un ou plusieurs « public
liste incomplète, folder » Exchange (plusieurs listes, selon l’activité
métier), mises à jour immédiates, pas de papiers
numéros abrégés plutôt longs,
imprimés. La solution peut aussi être utilisée avec des
processus manuel fastidieux. contacts personnels.
a ODBC est le standard Windows pour permettre d’interroger une base de données depuis une application Windows (Ex. Excel)
< 28 >
La fonction "Chef Secrétaire"

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.
< 29 >
Le contrôle et la limitation des appels

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).
< 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.
< 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.
< 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 Routage PSTN
vers un ancien n°
Depuis l’externe Normal
vers un nouveau
n°
< 33 >
Tests des urgences

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) :
< 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é.
< 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.
< 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 3.0.10
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
< 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)
< 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.
< 39 >
Epilogue
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 Email
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 « parka » 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.
< 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 emails 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
« voicemail », 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 Outlooka.
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.
< 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 2002.
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 2000.
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.
< 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, 1999-
2008 »).
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 :
< 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 2005. 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.
< 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 exemplea. 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
< 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 CLIa).
 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 2001. 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)
< 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écideursa. 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)
< 47 >
Principales causes du succès de ce projet

 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).
< 48 >
Je réfute l’argument en faveur de la « VoIP » publié sur ZDneta 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
< 49 >
Des centraux IP ouverts ou fermés ?

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 « CRMa »). 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 2005.
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)
< 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 « administrateursa ». 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 CAPEXb 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.
< 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
< 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.323a. 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
< 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
< 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)

(http://www.cisco.com/warp/public/788/signalling/e_m_overview.html)
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 = 2’048 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.711 64 kb/s Sur IP = 80 kb/s
G.729 ?
G.729a 8 kb/s Sur IP = 24 kb/s
G.723.1 6.4 kb/s
< 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 au-
delà 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.
< 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.
< 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
< 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 Voicemail » 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.
< 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) 16-23
CoS 3 Flash (IP precedence 3) 24-31
CoS 4 Flash-override (IP precedence 4) 32-39
CoS 5 Critical (IP precedence 5) 40-47 (EF)
CoS 6 Internet (IP precedence 6) 48-55
CoS 7 Network (IP precedence 7) 56-63
11. Adresses Internet

Numéros OFCOM :
d’urgences http://www.bakom.ch/imperia/md/content/deutsch/telecomdienste/grundlagenundkonsultation/te
(CH) chnischevorschriften/pta_1_3_version7_f.pdf
Urgences int. Wikipedia : http://fr.wikipedia.org/wiki/Num%C3%A9ro_d'appel_d'urgence
Adventis SA www.adventis.ch
NEWRE www.newre.com
MunichRe www.munichre.com
Cisco www.cisco.com
Swisscom La société Swisscom est l’équivalent de “France Télécom” pour la Suisse.
www.swisscom.ch
SIG Services Industriels de Genève : www.sig-ge.ch
< A.10 >
12.Organismes de normalisation
Tableau 12 - Organismes de normalisation
Organisme Désignation/Domaine Informations Etendue

3GPP 3rd Generation Partnership Project Organizational Partners are ARIB, US, Mondiale
CCSA, ETSI, T1, TTA, and TTC
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 ETS 300 EU
Standard Institute
F.C.C. Federal Communications Commission C.E.M. 30 à 230 MHz en Europe, US gov.
Organisme de régulation 54 à 216 MHz aux USA.
IANA Internet Assigned Numbers Adresses IP + Top-level Domains Mondiale
(TLD)+ARPA
ICANN The Internet Corporation Top level Authority Mondiale
for Assigned Names and Numbers
IEC International Electrotechnical ISO/IEC1180: = 1000BT Mondiale
Commission (ISO subdiv.)
IEEE Electrical and Electronics Engineers IEEE 802.3 : Ethernet Mondiale
IETF Internet Engineering Task Force RFC pour les standards IP Mondiale
IMTC International Multimedia Promotions de standards Voice and Mondiale
Telecommunications Consortium Video
INTERNIC Internet Noms de domaines .3 TLD Mondiale
(ex ,org), .net, .edu, …
ISO International Organization for Qualité : ISO 9000 Mondiale
Standardization Codes : liste pays…
ISOC Internet Domaines .org Mondiale
ITU-T International Telecomunication Union – ITU-T : Telecom, R : Radio Mondiale
(old CCITT) Telecommunications Sector. UIT en Ex. ; ITU G.703, G.704, G.706 UN
Français.
N.E.N.A. N° urgence, 911 (norme E911) Télécoms USA
OFCOM L'Office fédéral de la communication Régulateur de la Confédération CH
BAKOM Suisse dans les télécommunications
et la radiodiffusion
RIPE NCC Internet RIR Adresses IP EU/AF
TIA Travel Industry Association of America http://www.tiaonline.org/ US
W3C World Wide Web Consortium http://www.w3.org/ Mondiale
< A.11 >
13.Plaquette commerciale réalisée par Cisco « Case Study »
< A.12 >
Page 1/4
Page 2/4
< A.13 >
Note de l’auteur : Ils ont repris mon schéma mais avec quelques erreurs, voir la Figure 7.
Page 3/4
< A.14 >
Page 4/4
Lien en référence : http://www.cisco.com/global/CH/fr/press/brochures/docs/new_re_fr.pdf
< A.15 >
14.Copie du RFP
< A.16 >
< A.17 >
< A.18 >
< A.19 >
< A.20 >
< A.21 >
< A.22 >
< A.23 >
< A.24 >
< A.25 >
< A.26 >
< A.27 >
< A.28 >
< A.29 >
< A.30 >
< A.31 >
< A.32 >
< A.33 >
< A.34 >
< A.35 >
< A.a >
GLOSSAIRE
Voici quelques précisions sur certains termes utilisés dans le contexte de ce mémoire. Attention,
ce glossaire ne comprend pas une terminologie académique (disponible sur Internet), mais mes
propres interprétation de ces termes.
10,100BT 10 ou 100 Base T correspondent à la désignation de réseaux Ethernet 10 ou 100 Mégabits, établis sur
1000BT un câblage en cuivre de paires torsadées. Il existe aussi le 1000 Base T, qui correspond au Gigabit
Ethernet sur cuivre paire torsadée. 1000BFx utilise la fibre optique.
Application Ensemble de logiciels et de méthodes qui permettent d’assurer le (bon) fonctionnement d’un ou de
plusieurs services. Programme.
AVVID Architecture for Voice, Video and Integrated Data : Architecture Voix et vidéo de Cisco.
Backbone Dans les réseaux, une DORSALE (en français) correspond à un « tuyau » de plus grande capacité
permettant de relier tous les réseaux satellites afin de les faire communiquer entre eux avec un
minimum de congestion.
Bandwidth, Forme anglaise et française pour désigner la capacité de charge d’un réseau, d’une ligne télécoms, ou
Bande Passante encore un bus de communication interne à un système (exemple : Bus SCSI pour interfacer des disques
durs). La capacité est exprimée en « Bits » ou « Bytes » par secondes.
Broadcast Dans un réseau, une information destinée à plusieurs postes, par exemple pour une recherche
d’adresse, sera émise sous forme d’un paquet broadcast. Son adresse de destination en IP est par
exemple « 10.1.1.255 » pour une classe C (niveau 3), et FFFFFF-FFFFFF pour un paquet Ethernet
(OSI niveau 2). Ces broadcast pénalisent le réseau car ils doivent être répétés sur tous les segments
d’un même VLAN. En général, les paquets ne transitent que sur les segments concernés par les 2
machines en communication, sous forme d’un UNICAST, un paquet avec une adresse de destinataire
unique.
Broker En Français, un récupérateur (Brocanteur). La Suisse utilise beaucoup de terme anglais.
Bundle C’est un ensemble packagé non dissociable, dans le domaine IT : pré configuré et pré installé.
Business Terme anglais qui désigne ici la partie spécifique de l’activité de l’entreprise, en opposition
(complément) à la partie commune aux entreprises (Services Généraux, IT, Comptabilité, RH…). Les
personnes du « Business » comprennent généralement les comités de direction, les structures de
conception et de production (en incluant la vente).
Cabling La partie physique et passive d’un réseau est le système de câblage.
Call Manager Nom donné par Cisco à son IP-PBX.
Campus Voir site
CAPEX « Capital Expensive », désigne un coût financier unique d’acquisition (« one shot cost »), en
complément du terme « OPEX »
Capillaire Dans le contexte du câblage, c’est le câblage « horizontal » qui assure la distribution des prises dans les
bureaux, depuis une l’armoire de brassage. En Suisse, le terme utilisé est « câblage tertiaire ».
CDR Call Detail Records : Il s’agit du détail de la liste des appels reçu et émis, avec les durées.
Cluster Dans le contexte « systèmes informatiques » : C’est un système redondant, Soit avec un système
primaire, et un secondaire pour désigner un système dormant, qui est prêt à prendre le relais en cas de
défaillance du primaire. Mais cet usage est abusif, un « cluster » devrait en fait partager ses fonctions
sur tous ses membres.
CoS Class of Services – marqueur de priorité des paquets Ethernet (801.1Q/p)
DECT Système de téléphones sans fils, sur une base analogique.
Disaster plan Un plan en cas de sinistre majeur (inondation, incendie, séisme, …), pour permettre la remise en route
rapide des services vitaux, en général sur un autre site.
Dorsale Voir à Backbone.
Draft Brouillon en anglais (Terme usité pour désigner la forme non finalisée d’un document écrit, pour un
logiciel on parlera de forme « Beta »). Dans le cadre Internet, DRAFT désigne une proposition de
norme pour l’Internet auprès de l’IETF. Une fois discutée et aménagée, ce Draft deviendra peut-être
un RFC.
Email Courrier électronique, par déformation, ce terme désigne en général le support de communication par
messages électronique de l’Internet (cf. SMTP)
Ethernet Il existe plusieurs Ethernet, les plus courants sont 100BT (100 base T), 1000BT (Gigabit sur 4 câbles
cuivres avec des connecteurs rj45), 1000BFX (sur fibre optique), etc.
< A.b >
Exécutable Les informations ne vivent qu’à travers un programme, un logiciel, sous la forme directe ou indirecte
de codes exécutables.
Frame Voir Trame
Freeware C’est un logiciel généralement téléchargeable depuis l’Internet, dont l’utilisation et la copie sont
totalement libres et gratuites (sous réserve en général de maintenir les références des auteurs et de ne
pas en faire une revente commerciale directe ou indirecte)
Full duplex Dans le contexte Ethernet, c’est le mode de connexion avec un Switch, ou bien entre deux
équipements reliés avec un câble Ethernet croisé (100BT). Voir Half Duplex.
H.323 Standard ITU, établi en 1996, assure une standardisation du transport de communications
« multimédia » (voix, vidéo et données en communication « temps réel ») sur des réseaux numériques
par paquets, comme TCP/IP.
Half duplex C’est le mode de connexion avec un HUB, ou bien un coaxial Ethernet. La communication Ethernet
peut entrer en collision avec un autre équipement qui partage le même segment Ethernet, le poste doit
donc attendre un « blanc » pour pouvoir émettre, et il doit aussi contrôler l’absence de collisions. Avec
un Switch, une interface Ethernet unique est dédiée : ce qui permet le fonctionnement en mode « Full
duplex » et sans contrôle de collision.
HUB A la différence des switchs, les HUB Ethernet sont de simples répéteurs, et tous les équipements qui
y sont raccordés partagent la même bande passante de 10 ou 100 Mb, en mode « Half duplex ».
Internet Est un ensemble d’ordinateurs reliés entre eux par un réseau (des connexions physiques), régi par le
protocole de communication (le langage) TCP/IP. Par extension l’Internet est le réseau mondial dit
‘public’ car il requiert pour les ordinateurs connectés une adresse IP publique. Il n’y a qu’un seul
Internet, qui est une sorte d’intranet mondial. Il n’est possible de s’y raccorder que par l’intermédiaire
d’un opérateur via une ligne fixe (Câble, Frame-Relay, Fibre optique ADSL, ligne louée, …), ou bien
une ligne commutée payée à la durée de communication (Modem analogique ou adaptateur ISDN)
raccordée sur le ‘RTC’.
IP Composant de base du protocole TCP/IP. C’est le langage de communication universel et normalisé
par les RFC de l’IETF, et qui permet l’interconnexion de systèmes informatiques différents. C’est le
langage utilisé pour l’Internet et les intranets. Une adresse IP est une suite numérique unique dans un
intranet (exemple 62.202.158.61) attribuée définitivement ou provisoirement à un système
informatique. Celle des ordinateurs membres d’Internet est « publique », celle des ordinateurs
membres d’un intranet est généralement « privée ».
IP-PBX Commutateur téléphonique directement raccordé sur un réseau « IP », dont les périphériques sont de
type « VoIP ».
IPTel Acronyme anglais pour la téléphonie sur IP (« IP Telephony »). Abusivement remplacée par « ToIP »
sur certaines publications Françaises et Anglaises.
ISDN RNIS en Français, Numéris chez France Télécom. C’est une technique d’accès au réseau téléphonique
totalement numérique. Elle permet de disposer de fax à plus haute définition (Groupe 4), et d’une
signalisation plus riche (identification de l’appelant et du type de périphériques : Téléphone, fax,
modem, …). Les entreprises utilisent des accès de base (BRI) avec 2 canaux Voix ou données de 64kb
ou bien accès primaire (PRI) avec 30 canaux de 64 kb (de l’ordre de 2 Mb).
IT « Information Technology », désigne généralement le département d’une entreprise qui s’occupe de
l’informatique, ou comme adjectif pour désigner une affiliation (affinité) avec le domaine
informatique, comme NTIC qui désigne les Nouvelles Technologies de l’Information et de la
Communication…
kB, kb, kb/s kB = « Kilobyte » ou Kilooctet, kb est plus souvent utilisé pour l’abréviation de kilobit, et kb/s pour
kilobits par secondes.
LAN Abréviation anglaise pour « Local Area Network ». Elle désigne un (inter) réseau local, c’est à dire sur
le même campus (intra campus). NB : Nous considèrerons par déformation un réseau métropolitain
comme un LAN. Un MAN (« Metropolitan Area Network ») est un réseau de plusieurs bâtiments
dispersés assez loin, mais reliés par des liaisons hauts débits (Fibres optiques ou assimilables). On parle
aussi de campus étendu. Si dans une même cité, plusieurs bâtiments sont reliés par des lignes télécoms
classiques, même rapides, c’est un WAN, pas un LAN.
Logiciels Les applications programmées, ou programmes, désignés aussi sous le terme « Soft » ou « Software ».
Un logiciel est associé à une licence d’utilisation, et possède une version.
MAC
MAN Voir LAN.
MMF Multimode Fiber, fibre optique multi mode, pour des distances courtes (rocades intra bâtiment, inter
bâtiments proches). Il existe deux types de MMF, 50 microns () et 62.5 microns (plus courtes
distances).
< A.c >
ODBC Open Database Connectivity : Facilite les échanges de données entre des logiciels clients et des bases
de données (comme la base SQL incluse dans le Call Manager)
Open Source Mieux qu’un Freeware, ces logiciels dits « libres », publient les lignes de programmation qui les
composent. Ce qui permet de garantir la possibilité de suivre et de débuguer ces logiciels. La licence
se nomme GNU, elle impose de republier les codes sources utilisés après modification.
OPEX « Operating Expensive », coût financier récurrent (par défaut annuellement), en complément du terme
« CAPEX ».
OS, Operating Le système d’exploitation d’un ordinateur : Exemples : Windows 2000, Windows 2003, Windows XP,
System Linux (Unix), IBM-AIX (Unix), Mac OS 8…
OSI Open System Interconnection, 1984. Modélisation du fonctionnement des réseaux en « couches
(Layers) », établie par l’ISO, organisme de normalisation (Voir à ISO).
Outsourcing Action qui consiste à confier à une entreprise externe le mandat d’exploitation (de gestion et
d’optimisation) d’un produit, d’une solution ou un rôle (un ensemble de tâches).
Paquet Packet en anglais, Voir Trame (Frame en anglais)
PBX, PABX Private (Automatic) Branch Exchange: En français un central téléphonique. Par définition, ce terme
désigne un système « classique », par opposition à un IP-PBX qui utilise la Voix sur IP (VoIP).
PoE Power Over Internet
Process Terme anglais souvent utilisé en Français, pour désigner des procédures, des façons de traiter les
informations, avec les actions associées.
Protocoles Langage de communication entre ordinateur basé sur une solution normalisée (TCP/IP, ISO) ou
propriétaire (Netware IPX/SPX, Decnet, Appletalk, …). Les protocoles applicatifs vont toujours
s’appuyer sur un ou plusieurs protocoles de transport (DNS sur IP, Netbios de Microsoft sur IPX ou
IP, SNMP sur IP, http sur IP, Telnet sur IP, FTP sur IP, …)
PSTN « Public Switched Telephony Network », voir ‘RTC’.
QoS Quality of Services: La qualité de services est réalisée avec la mise en place de ``prioritisation`` des
flux. Certaines trames réseaux pourront être marquées prioritaires (selon la valeur du « ToS » sur IP,
« CoS » sur Ethernet)
Rack Armoire équipée de rails perforés verticaux, écartés d’une largeur de 19 pouces. Destiné à recevoir des
bandeaux (supports) de raccordements aux câblages, ainsi que des équipements réseaux et télécoms,
afin d’en faciliter les raccordements (le brassage). Beaucoup de solutions serveurs sont conformes à
ce standard. Le terme français est souvent `ferme`, mais la ferme est normalement de type mural, et
parfois en un seul montant destiné à recevoir des modules CAD.
Recette (RFP) Dans le sens de réception, elle décrit les conditions dans lesquelles une solution pourra être considérée
comme réussie ou acceptée.
RFC Request For Comment: Dans le contexte Internet et IP, les « RFC » sont numérotés. Ils identifient
l’ensemble des mécanismes normalisés. Dans le contexte RFP, le RFC vient en amont pour préparer
le RFP.
RFP « Request for Proposal », Appel d’offres.
RJ45 Type de prises utilisées essentiellement par des raccordements de type ISDN (Numéris) ou Ethernet.
Routine Terme français pour désigner un petit programme, généralement de type « batch » ou « script », qui
permet d’exécuter une fonction simple mais répétitive, et fastidieuse à la main.
RTC, RTP Réseau Téléphonique Commuté Public, c’est l’ensemble des lignes téléphoniques du monde entier,
accessibles par l’intermédiaire d’un opérateur téléphonique. « PSTN » en anglais. Il est possible de s’y
raccorder via une connexion Analogique (Modem, Fax groupe 3, Téléphones simple ou sans fils, ...),
ou via une connexion numérique ISDN (RNIS, Numéris, Fax groupe 4, téléphones ISDN, routeurs
ISDN). Le standard des entreprises européennes est l’accès primaire à 30 canaux Voix (2 Mb,
équivalent d’un T1)
SFT System Fault Tolerance (Tolérance de panne). Contrairement à une idée reçue, une solution SFT n’est
pas une solution avec des systèmes de redondances. C’est en fait une solution qui est capable de
maintenir un service opérationnel à plus de 99.9% du temps. C’est à dire, une panne tous les 3 ans.
Pour aboutir à cela il faut parfois installer des redondances.
Site, Campus Un ensemble de bâtiments interconnectés (ou connectables) par un LAN. Par déformation, deux
campus interconnectés à travers un « MAN » pourront être considérés comme un seul et même site.
SMF Single Mode Fiber : Fibre optique monomode, pour des distances plus grandes (Campus étendues,
lignes télécoms). Les équipements de terminaisons sont nettement plus prohibitifs que pour la fibre
« MMF ».
SMTP Sur IP (L’Internet et les intranets), ce protocole de communication permet l’envoi de messages
électroniques (Email). POP (ou IMAP) est le protocole pour aller lire ces messages, sur un serveur
« POP » ou « IMAP ».
< A.d >
SNMP Simple Network Management Protocol. Généralement transporté sur IP, ce standard normalisé
permet de ``monitorer`` les équipements sur les réseaux.
Software Anglais de logiciel, voir à exécutable.
Subnet (IP) Une plage d’adresses IP (ou « scope »).
Switch Ils remplacent les « HUB » Ethernet. Ces anciens répéteurs passifs, ont été supplantés par des
commutateurs actifs, plus performants car ils peuvent segmenter le trafic sur chaque port.
TCP/IP Voir IP
Telecom Les lignes et contrats télécoms comprennent l’ensemble des raccordements fixes ou commutés (voir
‘RTC’), vers des réseaux privés ou publics (‘Internet’ + ‘RTC’), pour le transport de la Voix
(téléphones, fax), des données, ou encore des deux à la fois.
ToIP Contrairement à un usage abusif fréquent pour « Telephony over IP », ToIP désigne la fonction Text
over IP (http://www.techabulary.com/t/toip.html) qui désigne le transport de messages textes sur de
la téléphonie interfacée via IP (périphériques multiples IP ou RTC) L’acronyme anglais correspondant
à la téléphonie sur IP est « IPTel » (IP Telephony). Ce terme « ToIP » reste toutefois très couramment
employé dans plusieurs ouvrages. il ne sera pas employé dans ce document afin d’éviter toute
confusion : le terme « IPTel » sera utilisé à la place.
ToS Type of Services : Marqueur («Tag») de priorité des paquets réseaux au niveau IP.
Trame Frame en anglais, dans le contexte réseau, cela désigne le paquet de données qui est émis entre deux
ordinateurs (un l’émet, l’autre le reçoit). Un flux ou un échange de données nécessitera plusieurs
trames. Chacune comprendra un en-tête avec entre autres, l’adresse du destinataire et celle de
l’émetteur.
Le paquet (packet) désigne plus l’ensemble, la trame (frame) désigne plus l’emballage (en-tête et ``en
pied`` du paquet)
Tuning Optimisation. Action qui permet d’améliorer le fonctionnement d’un système ou d’un service, soit en
réduisant sa charge d’exploitation soit en améliorant son niveau de disponibilité ou ses performances.
UNICAST Voir les informations associées à Broadcast.
UPS Unit Power Supply : L’onduleur permet de réguler l’alimentation électrique et éventuellement d’assurer
une autonomie minime sur des coupures électriques.
UTP Universal Twisted Pair, ou paire torsadée universelle en français. Ce système de câblage unanime utilise
des prises de type RJ45 (module à 8 connecteurs à plat), sur 8 fils (conducteurs) organisés en 4 paires
torsadées (1-2, 3-6, 4-5, 7-8). Un signal est toujours transporté sur une paire torsadée, ou plusieurs.
Cette technique permet de limiter les parasites sans utiliser de blindage, ce qui permet de maintenir la
puissance d’un signal sur une distance de 100 mètres. Ethernet utilise la paire 1-2 pour le signal
montant, et la paire 3-6 pour le signal descendant. Les câbles supporteront une fréquence maximale
(un débit, une capacité de bande passante) en fonction de leurs caractéristiques électriques. Un câble
de catégorie 3 supportera de 10 à 100 Mégabits (Mb) par seconde (Ethernet 10 ou 100 Base T par
exemple). Un câble de catégorie 5 supportera jusqu’à 1 Giga bits (Gb) par seconde (1000 Base T).
VLAN Virtual LAN: Il permet de simuler l’existence de plusieurs réseaux Ethernet distincts tout en utilisant
les mêmes équipements de raccordement (Switch). Ceci optimise le nombre de Switch, évite des
brassages physiques fastidieux et sur chaque local (Les VLAN se configurent à distance). Ceci permet
aussi de transporter sur de multiples localisations plusieurs réseaux Ethernet sur une seule ligne (ex.
FO).
VoIP Voice over IP : Voix sur IP. Cette technologie permet de transporter des communications vocales sur
un intranet ou l’Internet.
WAN Abréviation anglaise « Wild Area Network », désigne les réseaux étendus ou de télécommunication,
qui permettent d’interconnecter des sites distants (Inter campus).
Web Une des nombreuses applications du Net (Internet), est la navigation à partir d’un explorateur
(« Browser »), de pages électroniques dîtes « web ». Elles utilisent le langage et protocole HTTP. Un
site Web est un (ou plusieurs) serveur qui fourni ces pages, chacune ayant une référence mondialement
unique, l’URL. Par exemple : http://www.sidpe.org/Ethique.html ou www.essi.fr.
L’ensemble de ces pages compose le « World Wide Web ».
< A.e >
BIBLIOGRAPHIE
24 Documents de références, 4 Nouvelles, 9 Liens.
BAKOM (OFCOM)
Office Fédéral de la Communication (Suisse) :
 Bases légales et plans de numérotation :

http://www.bakom.ch/fr/telekommunikation/numad/unterseite00992/unterseite01063/index.html
Numéros d’urgences :
http://www.bakom.ch/imperia/md/content/deutsch/telecomdienste/grundlagenundkonsultation/technischevor
schriften/pta_1_3_version7_f.pdf
Cisco
 Annonce de la sortie du Call Manager version 2.4, Septembre 1999, NEWS :

http://newsroom.cisco.com/dlls/fspnisapi52ac.html
WHITE PAPER : “Architecture for Voice, Video and Integrated Data (AVVID Model)”

http://www.cisco.com/warp/public/cc/so/neso/vvda/iptl/avvid_wp.htm
WHITE PAPER, 2000 : “Technical Considerations for Converging of Data, Voice, and Video
Networks”
 WHITE PAPER : “DiffServ—The Scalable End-to-End QoS Model”
 WHITE PAPER, 2000: “Choosing a Voice-over-IP Gateway-A 3.0 Gateway Solution Guide”
 Cisco PoE, Power over Ethernet, IEEE 802.3af : « supported devices » (updated 2005)

http://www.cisco.com/en/US/netsol/ns340/ns394/ns147/ns412/netbr09186a00801f4329.html
Power over Ethernet (« PoE ») Overview Brochure :

http://www.cisco.com/en/US/netsol/ns340/ns394/ns147/ns412/netbr09186a00801f4b9b.html
Cisco Catalyst 3500 XL Series Switches : « EoS Announcement Inline Power Switch »

http://www.cisco.com/en/US/products/hw/switches/ps637/prod_eol_notice09186a008032d4dc.html
2001, « Case Study » : Canton de Vaud :

http://www.cisco.com/global/CH/fr/press/brochures/docs/kanton_waadt_fr.pdf
2001, « Echo Analysis for Voice over IP » :

http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/voipsol/ea_isd.pdf
WHITE PAPER : “BENEFITS OF CISCO IP COMMUNICATIONS IN A CISCO
INTELLIGENT NETWORK”
http://www.cisco.com/application/pdf/en/us/guest/netsol/ns268/c654/cdccont_0900aecd801183b7.pdf
France Telecom
 Cesmo Consulting : Livre Blanc Téléphonie sur IP, 2004 :
http://www.francetelecom.com/fr/entreprises/grandes_entreprises/telechargement/att00027
842/LivreBlanc_TOIP.pdf
< A.f >
Gartner
 G00123539, S. Blood, C. Lock: Research Note, 20 September 2004,
“Magic Quadrant for Corporate Telephony in EMEA, 2004”.
 G00125707, B. Elliot, S. Blood, D. Kraus: Research Note, 14 February 2005,
“Magic Quadrant for Unified Communications, 2005”
L’IEEE (i 3 e)
 Standards Ethernet: http://grouper.ieee.org/groups/802/3/index.html
Tableau 13 -Les standards suivants ont été mis en œuvre dans les projets NEWRE (2000) :
Standard Sujet Liens

IEEE 802.1p QoS/CoS Protocol http://standards.ieee.org/getieee802/download/802.1D-1998.pdf
(cf. 802.1D) Traffic Prioritization http://www.javvin.com/protocol8021P.html

IEEE VLAN: Virtual Local http://standards.ieee.org/getieee802/download/802.1Q-1998.pdf
802.1Q Area Network http://www.javvin.com/protocolVLAN.html
IEEE STP: Spanning Tree http://standards.ieee.org/getieee802/download/802.1D-1998.pdf
802.1D Protocol http://www.javvin.com/protocolSTP.html
Les standards ci-dessous sont apparus après 2001

802.1s Multiple Spanning http://www.cisco.com/warp/public/473/147.html
Tree Protocol
802.1w Rapid Spanning Tree http://www.ieee802.org/1/pages/802.1w.html
802.3af Power over Ethernet http://standards.ieee.org/getieee802/download/802.3af-2003.pdf
L’IETF
Standardisation de la téléphonie sur IP, et par conséquent, aussi sur l’Internet :
 RFC “Telephony Routing over IP (TRIP) ” (2002) :
ftp://ftp.rfc-editor.org/in-notes/rfc3219.txt
 Draft “A Telephony Gateway REgistration Protocol (TGREP)":
http://www.ietf.org/internet-drafts/draft-ietf-iptel-tgrep-06.txt
 RFC “Session Description Protocol (SDP)” (1998) :
 RFC “Session Initiation Protocol (SIP)” (1996-1999) : Le concurrent de H.323 !
 RFC “Media Gateway Control Protocol (MGCP)” (multiples RFC, dont le RFC 2705 de 1999,
remplacée en 2003 par le RFC 3435) : ftp://ftp.rfc-editor.org/in-notes/rfc3435.txt
< A.g >
L’ITU-T
 Forum 01 WTP, UIT News : Session d'information sur la téléphonie IP
http://www.itu.int/itunews/issue/2001/02/ip_telephony-
fr.html#Session%20d'information%20sur%20la%20téléphonie%20IP
 G.729: Conversion numérique avec compression de la voix à 8 kb/s, (G.729a: est une version
simplifiée). http://www.vocal.com/data_sheets/g729d0.html
 G.723.1: Une version améliorée de G.729, le “DivX” de la voix, avec un codage à 6,4 kb/s. Ne
pas confondre avec la norme G.723 (ADPCM). Ce n’était pas disponible en l’an 2000 :
http://www.vocal.com/data_sheets/full/g723.html
 ITU-T H.323, H.320, H.324, T.120 Standards, http://www.itu.int
L’OSI de l’ISO
 NETgroup resources : (CH)
http://www.hta-bi.bfh.ch/Resources/Computing/NetGroup/netcours/Le-modele-
OSI_fichiers/frame.htm
 Wikipedia : http://fr.wikipedia.org/wiki/Mod%C3%A8le_OSI
Siemens
 The Executive’s Guide to Practical Convergence, 2002 : www.siemens.com/hipath
Divers
 Les décisions absurdes :


La pensée de groupe : http://fr.wikipedia.org/wiki/Pens%C3%A9e_de_groupe
Christian Morel, « Les décisions absurdes », 2002 (Gallimard, Bibliothèque des Sciences
Humaines) :
http://management.journaldunet.com/imprimer/dossiers/050269decision/morel.shtml
 SEI White paper, 2004 : “VoIP Phone set Power Via the Ethernet”
http://www.seipower.com/pdf/VoIP%20Power%20Via%20Ethernet.pdf
 ZDnet, 2003, NEWS : Pourquoi Infogrames a choisi la téléphonie sur IP (2001)
http://www.zdnet.fr/techupdate/reseaux_telecoms/0,39020969,39129886,00.htm
 ZDnet, 2003, NEWS : Téléphonie sur IP: les constructeurs lorgnent vers les PME
http://www.zdnet.fr/techupdate/reseaux_telecoms/0,39020969,2129009,00.htm
< A.h >
Remerciements
Je voudrais avant tout remercier :
 Mon épouse Stéphanie, pour m’avoir soutenu au cours de mes longues plongées sur
ce mémoire.
Mais aussi, pour leurs disponibilités et leurs esprits constructifs :
 Mon directeur et mes collègues d’ADVENTIS.
 Ainsi que la direction et les collaborateurs IT de la NEWRE.
A propos de l’auteur
 Pascal KOTTÉ. Né en 1964, Diplôme Informatique Scientifique et Technique de l’Université d’Aix-Marseille II en 1987.
 Analyste-programmeur en langage C sous HP-UX (Unix) chez Pastel (Groupe Telema) à Marseille jusqu’en 1989.
 Ingénieur Technico-commercial spécialiste microsystèmes, intégrations en réseaux et systèmes hétérogènes, chez l’Apple Center Joy
Informatique jusqu’en 1992, puis ELP informatique jusqu’en 1994 à Marseille (Certifications Apple et DAN de Novell).
 Responsable Méditerranée du support technique pour le constructeur de PC ADD-X (Normerel) jusqu’en 1998 à
Aix-en-Provence (Certifications MCP)
 Responsable des réseaux européens chez Jet On Line à Lyon en 1999.
 Consultant IT chez Adventis SA depuis 2000 à Lausanne et Genève. (certifications MCSE, CCNA, Altiris)

Memoire IDPE at 2005 Pascal Kotte at ESS

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Memoire IDPE at 2005 Pascal Kotte at ESS

Transféré par

Droits d'auteur :

Formats disponibles

Mémoire présenté pour l’obtention du diplôme d’

Ingénieur Diplômé Par l’Etat (FR)

Ecole Supérieure en Sciences Informatiques

Destinataires _____________________ Jean-Louis FARAUT (Président du Jury)

Date ______________________________________ jeudi 17 Novembre 2005

Version _____________________________________________ Version 1.02

Par Pascal KOTTÉ

Mots-clefs : IP, VoIP, ToIP, Téléphonie, Cisco, Convergence, voix, PBX.

Keywords: IP, VoIP, Telephony, IPTel, Cisco, Voice, Convergence, PBX.

TABLE DES MATIÈRES

Sections Contenu Pages

Annexes Techniques ..................................................................................................................... 1

TABLE DES ILLUSTRATIONS

a Local Area Network (Réseau Local)

La société Adventis Communication Engineering SA

L’infrastructure initiale de la NEWRE

L’infrastructure de câblage de l’Athénée (OSI 1) a

L’infrastructure Ethernet de l’Athénée (OSI 2) b

(Les 3 ‘étoiles’ indiquent les zones principales de congestion réseau)

L’infrastructure IP de la NEWRE (OSI 3) a

Les évolutions prévues en 2000 et 2001

a OSI Layer 3 : Couche « réseau » (IP)

Figure 2 - La vision du nouveau LAN (Disaster II)

Le projet « Phone 2000 »

LES DEMANDES ET LES ATTENTES DE LA NEWRE

Le câblage existant sur 2 paires seulement.

Gestion facilitée et ouverture

Les projets connexes (contexte)

Projets Oct. 2000 Déc. 2000 Fév. 2001 Mars 2001

Pourquoi changer ce calendrier ?

Disaster II (New LAN design)

La téléphonie des locataires

Messagerie vocale, communication unifiée.

a Gb = Gigabit, soit 1000 Mb (mégabits par secondes)

Maintenir la continuité Interruptions hors des Interruptions limitées à

Au départ : Une étude de faisabilité et d’opportunité

Un partenariat technologique afin de créer un concept et un pilote

Tableau 3 - Partenariat entre Adventis, Cisco et NEWRE.

Un appel d’offres, une décision.

a RFP = Request For Proposal (Appel d’Offres)

Une planification, une réalisation

Projets Oct. 2000 Déc. 2000 Fév. 2001 Avril 2001

Leschot Préparatifs Déménagement

(En gras : les modifications sur le plan initial)

a MeO = Mise en Oeuvre

Au-delà de ces valeurs, la qualité de la communication commencerait à se dégrader de façon

Disponibilité et forte résilience du réseau LAN Ethernet

La sécurité des personnes

Certaines lignes d’appels automatiques (Ascenseurs, Centrale d’alarme "Cerberus"d) devaient

2) Les lignes de secours

a PoE = Power over Ethernet (Voir le Glossaire en fin de document)

3) Les numéros d’urgences

Concept pour les FAX.

La passerelle entre le nouveau Cisco IP-PBX et l’ancien Hicom PBX

1) Cohabitation pour Leschot :

 Extension pour Leschot

 Cohabitation de l’ancien avec le nouveau PBX

 Déplacement sur des lignes séparées.

3) Migration de l’ancien central PBX vers l’IP-PBX (Athénée)

4) Migration des habitudes (formations et informations)

La vision à long terme

Le concept prévoyait aussi la possibilité d’avoir :

De plus, l’installation de serveurs redondants à Leschot pouvait être envisagée suite à