VoIP MEMOIRE DE FIN D'ETUDES ESIEA Solution IP-Centrex

MEMOIRE DE FIN D’ETUDES ESIEA
Solution IP-Centrex
BSNetwork
Date : A définir
Composition du Jury
A définir
Parrain : Jean-Louis MAS Maître de stage : Pierre PRENEL
Auteur : Frédéric OGUER

Mémoire de fin d’études ESIEA
Page 2 sur 248

Sommaire
I. Introduction ...................................................................................................................... 19
1) Présentation de l’entreprise .......................................................................................... 19
a) Les partenariats Universitaires: ................................................................................ 20
b) Les partenariats Industriels : .................................................................................... 20
c) Les solutions de BSNetwork .................................................................................... 21
2) Présentation du stage .................................................................................................... 23
3) Qu'appelle t'on voix sur IP ?......................................................................................... 23
II. Déroulement du stage ....................................................................................................... 24
III. La téléphonie classique ................................................................................................ 26
1) Une brève histoire du téléphone ................................................................................... 26
2) Le téléphone ................................................................................................................. 27
a) Les fondamentaux de la voix ................................................................................... 27
Fréquences .................................................................................................................... 27
Niveaux ........................................................................................................................ 27
b) Le fonctionnement du téléphone .............................................................................. 28
La signalisation ............................................................................................................ 28
SS7 (Signaling System 7) ............................................................................................. 29
La transfert de la voix................................................................................................... 30
Autres types de téléphones. .......................................................................................... 31
Téléphonie 2 fils versus téléphonie 4 fils ..................................................................... 31
3) Les commutateurs privés ou PABX (Public Automatic Branch Exchange) ................ 31
a) Présentation d’un commutateur ................................................................................ 32
b) Le routage des appels dans un PABX ...................................................................... 32
c) Types d’interfaces sur un PABX .............................................................................. 33
Page 3 sur 248

4) Numérisation de la voix ............................................................................................... 33
a) Les « trains » numériques normalisés – 1,544 Mbps / 2,048 Mbps ......................... 33
b) La numérisation de la voix : PCM (Pulse Code Modulation) G.711 ....................... 34
Lois A et mu ................................................................................................................. 35
La loi "A" ................................................................................................................. 35
La loi "mu" ............................................................................................................... 36
c) Puissance d’un signal numérique ............................................................................. 37
d) Distorsion apportée par le processus de quantification ............................................ 37
5) L’interface numérique 1,544 Mbps (DS-1) .................................................................. 37
a) L’interface physique ................................................................................................. 38
b) Framing D4 .............................................................................................................. 39
c) Framinig – ESF (Extended Super Frame) ................................................................ 39
d) CAS – Channel Associated Signaling (CAS) - DS-1 ............................................... 39
e) CCS – Common Channel Signaling (CCS) - DS-1 .................................................. 40
6) L’interface numérique 2,048 Mbps (E1) ...................................................................... 40
a) L’interface physique – G.703 ................................................................................... 40
b) La structure des trames – G.704 ............................................................................... 40
c) CAS – Channel Associated Signaling (CAS) – E1 .................................................. 41
d) CCS – Common Channel Signaling (CCS) – E1 ..................................................... 41
e) Alarmes E1 ............................................................................................................... 42
7) Le besoin de la synchronisation entre commutateurs................................................... 42
a) Commutateurs sans synchronisation ........................................................................ 42
b) Commutateurs avec synchronisation ........................................................................ 42
8) Analyse du trafic .......................................................................................................... 43
a) La théorie du trafic ................................................................................................... 43
Unités de mesure .......................................................................................................... 43
Heure de pointe ............................................................................................................ 43
Page 4 sur 248

Mesure de la capacité du réseau ................................................................................... 44
Grade of Service ........................................................................................................... 44
Types de trafic .............................................................................................................. 44
Méthodes d’échantillonnage ........................................................................................ 45
b) Critère pour choisir un modèle ................................................................................. 47
Types d’arrivée ............................................................................................................. 47
Régulier .................................................................................................................... 47
Par pique ................................................................................................................... 48
Aléatoire ................................................................................................................... 48
Appels bloqués ............................................................................................................. 48
Nombre de sources ....................................................................................................... 49
Durées d’appel.............................................................................................................. 49
c) Les modèles .............................................................................................................. 49
Erlang B........................................................................................................................ 49
Equations d’états ...................................................................................................... 49
Etat d’équilibre ......................................................................................................... 51
Probabilité d’état ...................................................................................................... 52
Distribution d’Erlang................................................................................................ 53
Temps de Congestion ............................................................................................... 54
Appel bloqué ............................................................................................................ 54
Erlang en pratique .................................................................................................... 55
IV. La compression de la parole ......................................................................................... 55
1) Différents types de codage ........................................................................................... 55
2) Adaptative Differential Pulse Code Modulation (ADPCM) ........................................ 56
3) CELP – Code Excited Linear Prediction...................................................................... 57
4) LD-CELP – Low Delay / Code Excited Linear Prediction (ITU-T G.728) ................. 58
5) CS-ACELP – Conjugate Structure / Algebraic Code Excited Linear Prediction (ITU-T

G.729) ................................................................................................................................... 58
Page 5 sur 248

6) Autres techniques de compression ............................................................................... 58
a) Compression de la parole et traitement des données................................................ 59
V. Introduction aux protocoles .............................................................................................. 62
1) Couche réseau pour les protocoles Internet .................................................................. 62
a) La couche physique .................................................................................................. 62
b) La couche Internet .................................................................................................... 63
IPv4 .............................................................................................................................. 63
IPv6 .............................................................................................................................. 63
c) La couche transport .................................................................................................. 63
TCP............................................................................................................................... 64
UDP .............................................................................................................................. 65
TLS ............................................................................................................................... 65
SCTP ............................................................................................................................ 65
d) La couche application............................................................................................... 66
VI. SIGNALISATION POUR LA VOIP ........................................................................... 67
1) Signalisation H.323 ...................................................................................................... 67
a) Introduction .............................................................................................................. 67
b) Principe du protocole H.323..................................................................................... 68
Les terminaux ............................................................................................................... 68
Les passerelles (gateway) ............................................................................................. 68
Les gardes-barrières (gatekeeper) ................................................................................ 70
Vue d’ensemble des gardes-barrières ....................................................................... 70
Différents niveaux de garde-barrières ...................................................................... 71
L’unité de contrôle multipoint...................................................................................... 72
Le contrôleur multipoint........................................................................................... 72
Le processeur multipoints ........................................................................................ 72
Les ponts de conférence ........................................................................................... 73
Page 6 sur 248

c) Les protocoles de la norme H323 ............................................................................. 73
d) Une communication H.323 simple ........................................................................... 75
e) Une Communication H323 avec gatekeeper ............................................................ 76
f) Conclusion ................................................................................................................ 78
2) Signalisation SIP .......................................................................................................... 79
a) Introduction .............................................................................................................. 79
L’IETF .......................................................................................................................... 79
Histoire du SIP ............................................................................................................. 80
b) En pratique ............................................................................................................... 80
c) Une communication SIP simple ............................................................................... 81
Message INVITE.......................................................................................................... 81
Message 180 Ringing ................................................................................................... 88
Message 200 OK .......................................................................................................... 89
Message ACK .............................................................................................................. 90
Le message BYE .......................................................................................................... 90
d) SIP avec un serveur Proxy en mode Stateless .......................................................... 90
e) SIP avec un serveur Proxy en mode Statefull .......................................................... 92
f) Serveur registrar ....................................................................................................... 93
3) Comparaison SIP et H.323 ........................................................................................... 94
4) L’avenir de la signalisation VoIP ................................................................................. 96
VII. Analyse du trafic pour la VoIP ..................................................................................... 97
1) Les codecs .................................................................................................................... 97
2) Les échantillons ............................................................................................................ 97
3) Détection de l’activité .................................................................................................. 97
4) Compression des en-têtes RTP ..................................................................................... 98
5) Synthèse ....................................................................................................................... 98
VIII. Problèmes de la VoIP ................................................................................................... 99
Page 7 sur 248

1) Généralités sur les problèmes de qualité ...................................................................... 99
2) Problèmes de qualité sur les réseaux sans fils. ........................................................... 101
IX. Architecture SIP ......................................................................................................... 103
1) Passerelle Vegastream ................................................................................................ 104
a) Introduction ............................................................................................................ 104
b) Connexion .............................................................................................................. 105
c) Architecture ............................................................................................................ 108
d) Plan d’appel ............................................................................................................ 108
e) Configuration de la passerelle ................................................................................ 109
Configuration des paramètres LAN ........................................................................... 110
Configuration des paramètres de connexion .............................................................. 111
Configuration du réseau (Nom d’hôte, etc.) ............................................................... 113
2) Firewall Ingate............................................................................................................ 114
a) Introduction ............................................................................................................ 114
b) Configuration ......................................................................................................... 116
3) IPBX Asterisk ............................................................................................................ 121
a) Introduction ............................................................................................................ 121
b) Architecture ............................................................................................................ 122
Globale ....................................................................................................................... 122
Le noyau ..................................................................................................................... 122
Le système de fichier.................................................................................................. 123
/etc/asterisk ............................................................................................................. 123
/usr/sbin .................................................................................................................. 123
/usr/lib/asterisk ....................................................................................................... 124
/usr/lib/asterisk/modules......................................................................................... 124
/usr/include/asterisk ................................................................................................ 124
/var/lib/asterisk ....................................................................................................... 124
Page 8 sur 248

/var/run ................................................................................................................... 124
/var/spool/asterisk................................................................................................... 124
Dénomination ............................................................................................................. 124
Canaux TDM Zaptel............................................................................................... 125
SIP .......................................................................................................................... 125
IAX, H.323, MGCP, etc. ........................................................................................ 125
c) Configuration ......................................................................................................... 126
Plan d’appel ................................................................................................................ 126
Les contextes et les extensions ............................................................................... 126
Les menus ............................................................................................................... 126
Modèles d’équivalence ........................................................................................... 126
Définition des extensions ........................................................................................... 127
4) Terminaux SIP............................................................................................................ 127
a) Snom....................................................................................................................... 128
Introduction ................................................................................................................ 128
Configuration ............................................................................................................. 130
Premier démarrage ................................................................................................. 130
Serveur de configuration ........................................................................................ 132
b) Cisco ....................................................................................................................... 133
Introduction ................................................................................................................ 133
Configuration ............................................................................................................. 134
DHCP ..................................................................................................................... 136
Les fichiers de configuration .................................................................................. 136
5) Opérateur Primus Telecom......................................................................................... 136
a) Primus et Asterisk .................................................................................................. 137
Dans sip.conf .............................................................................................................. 137
Dans extensions.conf .................................................................................................. 138
Page 9 sur 248

b) Primus et Vegatream .............................................................................................. 138
X. Solution hébergée ........................................................................................................... 141
1) Introduction à la solution............................................................................................ 141
a) Stabilité................................................................................................................... 141
b) Simplicité ............................................................................................................... 141
2) Introduction à la Haute Disponibilité ......................................................................... 141
a) Fiabilité versus disponibilité .................................................................................. 142
b) Les différentes méthodes ........................................................................................ 143
c) Les composants de la haute disponibilité ............................................................... 144
d) Exemples d’architecture ......................................................................................... 151
Cluster basé sur la réplication de données ................................................................. 151
Cluster basé sur le partage des données ..................................................................... 152
3) Architecture ................................................................................................................ 154
a) Introduction aux clusters Beowulf ......................................................................... 154
b) Comparaison Beowulf et SMP ............................................................................... 154
c) Architecture logique ............................................................................................... 155
Nœud de calcul ........................................................................................................... 156
Nœud de gestion ......................................................................................................... 156
Nœud d’installation .................................................................................................... 157
Nœud utilisateur ......................................................................................................... 157
Nœud de contrôle ....................................................................................................... 157
Nœud de stockage ...................................................................................................... 157
d) Architecture proposée ............................................................................................ 157
e) Base de données ..................................................................................................... 158
f) Asterisk................................................................................................................... 158
g) SER......................................................................................................................... 159
Introduction ................................................................................................................ 159
Page 10 sur 248

Architecture ................................................................................................................ 159
Configuration ............................................................................................................. 160
Le langage de routage ............................................................................................ 160
La redirection ......................................................................................................... 160
Les conditions ........................................................................................................ 160
Modification de l’URI ............................................................................................ 161
SER et BdD ............................................................................................................ 161
4) Obelisk ....................................................................................................................... 162
5) Haute Disponibilité des différents composants .......................................................... 163
a) Ingate Fail-Over ..................................................................................................... 163
Introduction ................................................................................................................ 163
Prérequis ..................................................................................................................... 164
Fonctionnalités ........................................................................................................... 164
Configuration ............................................................................................................. 164
Firewall actif .......................................................................................................... 165
Firewall en attente .................................................................................................. 165
b) HeartBeat et Mon ................................................................................................... 165
Fonctionnement .......................................................................................................... 165
Redondance d’adresses .............................................................................................. 166
Interactions avec Mon ................................................................................................ 166
Fonctionnalité manquante et problèmes communs .................................................... 166
Mise en place d’Heartbeat .......................................................................................... 167
Mon et Heartbeat ........................................................................................................ 167
Conclusion .................................................................................................................. 167
c) DRBD ..................................................................................................................... 167
6) Supervision ................................................................................................................. 169
a) Fournisseurs d’accès Internet ................................................................................. 169
Page 11 sur 248

b) Logiciel : Nagios .................................................................................................... 169
Principe de fonctionnemment..................................................................................... 170
Théorie des plugins ................................................................................................ 170
Fonctionnalités avancées ........................................................................................ 171
Nagios et Asterisk ...................................................................................................... 175
c) Matériel : Server View ........................................................................................... 177
ServerView - gestion et contrôle ................................................................................ 178
Fonctionnalités ........................................................................................................... 178
7) Management ............................................................................................................... 180
a) xCAT ...................................................................................................................... 180
Introduction ................................................................................................................ 180
L’installation .......................................................................................................... 180
La maintenance ...................................................................................................... 180
L’administration ..................................................................................................... 181
L’accès distant ........................................................................................................ 181
Installation du nœud de gestion .................................................................................. 181
Installation du cluster ................................................................................................. 181
b) VPN ........................................................................................................................ 184
c) Carte de prise en main à distance ........................................................................... 186
XI. Exemples d’implémentation ....................................................................................... 188
1) BSNetwork ................................................................................................................. 188
2) Pandatrade .................................................................................................................. 188
3) Marionnaud ................................................................................................................ 188
4) CNPS .......................................................................................................................... 189
a) Architecture globale ............................................................................................... 190
b) Siège central ........................................................................................................... 190
c) Agences .................................................................................................................. 191
Page 12 sur 248

XII. Migration .................................................................................................................... 192
1) Introduction ................................................................................................................ 192
2) Les acteurs .................................................................................................................. 192
3) Méthodologie ............................................................................................................. 193
a) Collecte d’informations .......................................................................................... 193
b) Analyse de données ................................................................................................ 193
c) Conception de l’architecture cible.......................................................................... 194
d) Le plan directeur..................................................................................................... 194
e) Phase pilote ............................................................................................................ 194
f) Migration ................................................................................................................ 194
XIII. Perspectives et enjeux économique............................................................................ 195
1) Etat de l’offre et de la demande ................................................................................. 196
2) Les gains objectifs de la téléphonie sur IP ................................................................. 197
3) Le prix de la téléphonie sur Internet pour les particuliers .......................................... 198
4) Le coût de la téléphonie sur IP pour une entreprise ................................................... 198
XIV. Conclusion .............................................................................................................. 200
XV. Annexe ....................................................................................................................... 201
1) Glossaire ..................................................................................................................... 201
2) Tonalité française : ..................................................................................................... 204
3) Politique de France Telecom : Interview. .................................................................. 205
a) Quelle est votre perception du marché actuel de la Téléphonie sur IP ? ............... 205
b) Quelle est la légitimité d‘un opérateur tel que France Télécom sur ce marché ?... 205
c) Quelle est votre approche et qu‘offrez-vous aux clients entreprises ? ................... 206
d) Quel message souhaitez-vous adresser aux entreprises désirant migrer vers la ToIP
? 206
e) En conclusion, comment France Télécom appréhende-t-elle ce nouveau marché ?

206
4) Extrait table B d’Erlang pour 0 à 50 canaux, 0,7 à 40 % ........................................... 208
Page 13 sur 248

5) Débit / codecs ............................................................................................................. 210
6) Fonctionnalités de l’IP PBX Asterisk ........................................................................ 211
7) VegaStream 100 E1 : spécifications techniques (en anglais) ..................................... 213
a) Vega 100 E1 features ............................................................................................. 213
b) Vega general product features ................................................................................ 213
c) Vega VoIP features ................................................................................................ 213
d) Environmental ........................................................................................................ 214
e) Power ...................................................................................................................... 214
f) Physical dimensions ............................................................................................... 214
g) Approvals ............................................................................................................... 215
h) Tech Spec ............................................................................................................... 215
E1 DSL Physical ........................................................................................................ 215
D-channel Signalling .................................................................................................. 216
8) Vega 100 E1 : Configuration standard ....................................................................... 217
a) Configuration du plan d’appel................................................................................ 217
b) Configuration du SIP et des paramètres audio ....................................................... 222
c) Configuration de l’Authentification ....................................................................... 223
d) Configuration de l’Enregistrement ......................................................................... 226
e) Configuration des ports DSL.................................................................................. 229
f) Configuration du pointeur vers la documentation .................................................. 233
g) Sauvegardes des modifications .............................................................................. 235
h) Archivage de la configuration de la passerelle....................................................... 236
9) Vega 100 E1 : Configuration transparente ................................................................. 236
10) Ingate : spécifications techniques (en anglais) ....................................................... 239
11) Cisco : exemple de fichiers de configuration ......................................................... 240
a) OS79XX.TXT ........................................................................................................ 240
b) SIPDefault.cnf ........................................................................................................ 240
Page 14 sur 248

c) SIP001193B6F141.cnf ........................................................................................... 242
d) Ringlist.dat ............................................................................................................. 243
e) Dialplan.xml ........................................................................................................... 244
12) DB_PSQL.PHP ...................................................................................................... 245
XVI. Bibliographie et références : .................................................................................. 246
1) Sites Web : ................................................................................................................. 246
a) Partenaires et fournisseurs ...................................................................................... 246
b) Informations divers ................................................................................................ 246
2) Documents techniques................................................................................................ 246
a) Les standards .......................................................................................................... 246
b) Les MIB (pour la supervision) ............................................................................... 247
c) Les RFC (du moins une partie…) .......................................................................... 247
3) Ouvrages et présentations........................................................................................... 247
Page 15 sur 248

Remerciements
Je tiens tout d’abord à exprimer ma reconnaissance à l’entreprise BSNetwork pour l’acceuil
réservé lors de mon stage.
Je remercie Pierre PRENEL (Responsable du pôle VoIP), Yoann DUPAS (Responsable du

pôle Réseaux & Sécurité), Michel VUANDA (Responsable Commercial) et Fabien WALLET
pour l’aide qu’ils m’ont apportée tout au long de mon stage, pour leur disponibilité et leur
compréhension.
Enfin, je remercie Monsieur Jean-Louis MAS, mon parrain de stage à l’ESIEA, pour son aide
et ses précieux conseils.
Page 16 sur 248

Résumé Français
Suite à l'explosion de la bande passante sur les réseaux IP et à l'avènement du haut débit chez
les particuliers, de nouvelles techniques de communications sont apparues ces dernières
années. L'une les plus en vogue actuellement, est ce que l'on appelle « Voix sur IP ».
Le développement de la voix sur IP est parti d’un constat simple : comment faire en sorte
d’utiliser les potentialités extraordinaires du réseau Internet afin de téléphoner moins cher,
voir gratuitement ?
Après des balbutiements anarchiques où les diverses solutions proposées (NetMeeting de

Microsoft et CoolTalk de Netscape par exemple) étaient complètement incompatibles entre
elles, la norme H323 a fait son apparition et a permit ainsi l’interopérabilité des différents
systèmes s’appuyant sur cette technologie. Mais ce protocole issu des grands opérateurs
nationaux est beaucoup moins flexible que le monde Internet et beaucoup trop proche de la
téléphonie classique pour une convergence globale des flux transportés. Ainsi est apparu
quelques années plus tard le protocole SIP, issu cette fois ci des grands opérateurs réseaux. Il
est souple, évolutif et il a un grand avenir devant lui. Mais il souffre du fait de l’implantation
majoritaire des solutions à base de H323.
Je commencerai par présenter l’entreprise BSNetwork, le déroulement de mon stage ainsi que
la téléphonie classique. Après une brève description des systèmes de compression et des
protocoles réseaux, j’expliquerais le principe de la VoIP, la manière d’analyser le trafic
téléphonique, les problèmes rencontrés ainsi que les solutions proposées.
Je finirai par détailler l’architecture que propose BSNetwork en l’illustrant d’exemples

concrets et les manières de migrer vers une telle solution.
Je conclurai par une analyse des enjeux économiques et les perspectives d’une telle solution.
Page 17 sur 248

Résumé Anglais
Thanks to the incrementation of the band-width on networks IP and new DSL connections at
home, new techniques of communications these last years appeared. One of there is called
"Voice on IP".
The development of the Voice over IP started from a simple report: how to use the
extraordinary potentialities of Internet network in order to telephone less expensive or free?
After anarchistic stammerings where the various solutions suggested (NetMeeting of
Microsoft and CoolTalk of Netscape for example) were completely incompatible between
them, the H323 standard made its appearance and allowed the interworking of the various
systems. But this protocol resulting from the large national operators is much less flexible
than world Internet and too much near to traditional telephony for a total convergence of
transported flows.
Few years later appeared the protocol SIP, resulting this time from the large operators
networks. It is flexible, evolutionary and it has a great future in front of him. But it suffers
because of majority establishment of H323.
I will start by presenting the BSNetwork Company, the course of my training course and the
traditional telephony. After a short description of the systems of compression and protocols
networks, I would explain the principle of VoIP, the manner of analyzing the telephone
traffic, the problems encountered as well as the solutions suggested.
I will end up detailing the architecture which BSNetwork proposes by illustrating it of

concrete examples and the manners of migrating towards such a solution.
I will conclude by an analysis from the economic stakes and the prospects for such solution.
Page 18 sur 248

I. Introduction
1) Présentation de l’entreprise
BSNetwork, créée en mai 2000 par Monsieur Hakim
BESTANDJI (Président Directeur Général), est une Société
Anonyme, au capital de 38 112 euros. Son chiffre d’affaires
est en hausse constante depuis sa création.
BSNetwork est une SSII - Société de Service en Ingénierie

Informatique - ayant développé une expertise dans six pôles
d’activités :
- Réseaux et Sécurité : mise en place de réseaux, interconnexion de sites, sécurisation

de systèmes d’informations, etc.
- Ingénierie : regroupe toute la partie dite de « conseil et développement ». Ce pôle

prend en charge le développement d’applicatifs spécifiques, de sites Internet, Intranet
ou Extranet.
- Vente de matériel : dans le cadre de son approche globale des besoins de ses clients,
BSNetwork propose un ensemble homogène de solutions matérielles.
- Progiciels de Gestion Intégrée : étude, préconisation, implémentation de solutions

intégrées, formation. BSNetwork offre des solutions qui couvrent l'ensemble du
spectre de l'informatique décisionnelle.
- Conduite du changement : mise en œuvre des moyens nécessaires pour que les
services et les hommes qui les composent soient opérationnels en même temps que les
systèmes d'information qui les outillent.
- Solutions de voix sur IP (VoIP) : étude, préconisation et installations de solutions

VoIP s’appuyant sur des standards ouverts et non-propriétaires.
BSNetwork offre une prestation globale, facteur clé de succès : la très forte implication des
ses équipes (consulting et implémentation) est un gage de réussite.
Le personnel est réparti suivant l’organigramme suivant :
Page 19 sur 248

Mr BESTANDJI
PDG
Camille FLOURET Claudine LECOEUVRE

Assistante Assistante de direction
Mr ADELINE Mr VUANDA Mr LHUILLIER Mr DUPAS

Mr PRENEL
Responsable Responsable Réseaux Responsable Responsable
Responsable VoIP
Marketing Qualité et sécurité Développement Technique
Stéphane DUPAS William Aurelien Yassine Yang Alexandre

Communication SIL ELONSRI HAO DUTRA Nicolas Fabien
HUGON WALLET
Stéphane Frédéric
CALLABER OGUER
Réseaux VoIP
Dans le cadre de ces projets, BSNetwork prend les mesures nécessaires pour atteindre les
objectifs, à savoir, développer et livrer un produit de qualité, en maîtrisant les ressources et les
délais. L'approche privilégiée est : l'anticipation.
BSNetwork SA dans le cadre de sa Recherche et Développement a lié de forts partenariats sur

différents axes :
a) Les partenariats Universitaires:

Dans le cadre d’accords avec de grandes universités tel que :
- EFREI
- EPITA
- INSIA
- Université d’Orsay
- Université de Tours
- Université de Montpellier …
BSNetwork organise des groupes de travail mixte (entreprise – Université) sur l’évolution,
dans de nouvelles technologies, du Système d’information des entreprises. En accueillant
également des jeunes ingénieurs dans le cadre de stage tout le long de leurs cursus.
Ce partenariat favorise l’émergence de nouvelles idées et l’optimisation des formations des

jeunes ingénieurs par une meilleure connaissance du monde des entreprises.
b) Les partenariats Industriels :

Dans le cadre d’accords avec des constructeurs et des opérateurs tel que :
Page 20 sur 248

- Fujitsu-Siemens
- France Télécom
- Vegastream
- Astaro
- COLT Telecom
- Ingate
- Primus Telecom
c) Les solutions de BSNetwork

BSNetwork SA développe :
- De nouveaux moyens de communication et de diffusion des systèmes d’information

des entreprises tel que la mobilité avec les PDA (iPaq, etc.) ou les ardoises.
- La mise en réseaux de tous sites distants quelque soit l’architecture d’interconnexions

(Ligne spécialisée, ADSL, ou ligne normale avec modem).
- La possibilité à une population nomade d’accéder et de transmettre toutes

informations au site central et ce, grâce aux technologies GPRS, e-token et VPN.
Les solutions proposées sont les suivantes :
BS@ est le premier Progiciel de Gestion Intégré (ou ERP)

Full Web sous Linux. S’appuyant sur une base de donnée
PostgreSQL, BS@ est une solution facile a mettre en place,
modulaire et économique.
BS@Wall est une solution Firewall basé sur un système

d’exploitation Linux. Elle permet d’assurer la sécurité de
l’ensemble d’un réseau grâce à de nombreuse
fonctionnalités : filtrage par packet, VPN, antivirus,
filtrage d’URL, de courrier non sollicité, d’accès à
distance, de proxy…
BS@Backup est une solution de sauvegarde

professionnelle pour les ordinateurs en réseaux. Elle
permet des restauration complète et quasi-automatique des
postes clients et serveurs (MySQL, LDAP, Oracle, DB2,
Exchange, Lotus, …).
Page 21 sur 248

La solution BS@e-secure est le complément de BS@Wall

et BS@. En effet, BS@e-secure permet un accès sécurisé à
un réseau ou à une application par l’utilisation de cartes à
puces ou clés USB.
BS@GroupMail est une solution de serveur Mail,

actuellement en cours de développement.
BS@FAX est une solution de serveur de fax, actuellement

en cours de développement.
BS@VoiceLan est la solution que j’ai développée au cours

de mon stage…
BS@Server est une solution de serveurs sous Linux. Il

s’agit d’une alternative aux serveurs Microsoft, pour tout
ce qui est des tâches bureautiques : serveur de fichiers,
serveur d’imprimantes, …
BS@Parc est une solution d’infogérance. Avec BS@Wall,

cette solution devient de la télé-infogérance : il est alors
possible de réagir à un problème à distance.
Enormément de solutions utilisent Internet. BSNetwork

propose donc des connexions Internet aux entreprises grâce
à un partenariat avec Colt Telecom.
Page 22 sur 248

BSNetwork est également un organisme de formation

agréé.
Enfin, BSNetwork propose des solutions de financement

grâce à un partenariat avec Globalease.
2) Présentation du stage
Mon stage avait comme objectif de compléter l’équipe réseaux et sécurité de BSNetwork pour
le développement de nouvelles solutions, en particulier une solution Voix sur IP.
3) Qu'appelle t'on voix sur IP ?

Le terme générique VOIP (Voice Over Internet Protocole) est souvent utilisé dans son sens le
plus général pour désigner toutes les solutions permettant le transport de la parole sur un
réseau IP. On peut en distinguer quatre types :
- la voix sur IP : transport de la parole sur un réseau IP de type privé (intranet/extranet).
- la voix sur Internet : le transport de la parole via Internet.
- la téléphonie sur IP : en plus de la parole, les fonctions téléphoniques (signalisation,

fax, multi appel) sur IP de type privé (intranet/extranet).
- la téléphonie sur Internet : propose les services téléphoniques de base via Internet.
Page 23 sur 248

II. Déroulement du stage

Mon stage s’est déroulé en 4 étapes.
Etape 2 :
Etape 1 : Etape 3 : Etape 4 :
- analyse de l’existant
- apprentissage des techniques - développement d’une plateforme complète Démonstrations
- rencontre et formation avec les futurs
Réseaux & Sécurité de BSNetwork - test et validation aux clients
partenaires
01/04/2004 01/07/2004 01/10/2004

01/02/2004 31/10/2004
La première était l’apprentissage des techniques et des méthodes propres à BSNetwork. En

effet, il était nécessaire pour moi d’avoir une parfaite connaissance technique des différentes
solutions.
L’objectif étant de développé une solution VoIP, il a fallut prendre contact avec les différents
acteurs du marché. Certainement démarches ont été soldées par des échecs (Centile par
exemple) et d’autres par véritable succès (Ingate, Primus, etc.) ce qui a permis de développer
de véritables partenariats. Il a alors fallut que je me forme sur les différents produits et
solutions.
Fort de la connaissance théorique que j’avis acquise, j’ai commencé a développer une
plateforme complète afin de faire les différents tests.
La dernière étape a été de faire des démonstrations, à la fois en interne et à certains clients.
Actuellement, la solution est en train d’être finalisée afin de la proposer aux clients, suivant ce
plan :
Page 24 sur 248

RoadMap Asterisk
Fred
Fred Fabien
Fabien Administratif
Administratif
Demonstration
Fichiers Conf :
Supervision :
Ajout tel SIP Ingate Serveur : Numéros
Logiciel Linux-HA PostGre-SQL HA
Gestion Primus 1400 RX100 Primus
Materiel
Music d’attente
Script :
Plateforme de
Console de DB Ligne test : PBL de serveurs ?
Haute Dispo
test :
Supervision DB/conf 512/512 Pour test HA
BSNetwork
Conf
Interface WEB
Fonctionnalités : Plateforme
Queue Début Interface opérationnel
Call parking HA: dev./op.
Flash pour acceuil
Gestion des
Interface complet
Interface :
Contrôle Qualité Interface pour extensions :
ajout tel
Communication standards Redirection,
Conf primus
transfert, etc.
Correction de
gestion LDAP
Fonctionnalité Fonctionnalité Premiere

l’interface, ajout
LDAP Messagerie Solution
fonctionnalité
Correction de Premiere
Fonctionnalité Demandes
l’interface, ajout Solution pour
Solution OK
Billing Clients
fonctionnalité L’entreprise
Solution à la Demandes
Visualisation
Visualisation Module Billing

demande Clients
Solution à la
demande
Page 25 sur 248

III.La téléphonie classique

1) Une brève histoire du téléphone
Durant les années 1870, essayant de comprendre le son et les communications sonores,
l’inventeur d’origine écossaise Alexander Graham Bell eut l’idée d’un équipement qui
transmettrait le son sur de longues distances, en convertissant le son en un signal électrique.
Cet équipement fut ensuite appelé téléphone à partir des mots grecs « tele » (à distance) et
« phone » (son). Bell n’était pas la seule personne à développer un tel équipement à cette
époque, mais ce fut le premier à déposer un brevet en 1876.
De nombreux autres développements furent réalisés autour de cet équipement à la fin des
années 1870. Bell fut à l’origine de l’écouteur (inducteur), et Thomas Edison fut le concepteur
du microphone (à base de carbone). L’incorporation de ces améliorations fit du téléphone un
objet utilisable pratiquement.
A l’origine, le téléphone n’avait pas de mécanisme pour composer un numéro. Pour appeler,
une poignée devait être manipulée afin de produire un courant électrique. Ce courant signalait
à un opérateur local la présence d’un appel. Pour connecter l’appelant à l’appelé, l’opérateur
réalisait manuellement la fonction de commutation, en connectant des fiches entre la prise de
l’appelant et de l’appelé.
Il fallut attendre 1889 pour qu’Almon B. Strowger développe l’embryon du commutateur

téléphonique automatique. Quoique complètement hors du monde de la téléphonie, Strowger
développa le premier commutateur automatique, ainsi que le téléphone avec la fonction de
numérotation ; ce qui élimina la fonction d’opérateur téléphonique.
Les réseaux téléphoniques ont subi de très nombreux changements depuis cette époque.
Cependant, la plupart des techniques restent les mêmes. Le téléphone « deux fils » utilisé par
la plupart des foyers d’aujourd’hui fonctionne grossièrement de la même manière qu’il y a
cent ans.
Page 26 sur 248

2) Le téléphone
Dans cette partie, les fonctions de base du téléphone sont examinées, avec un regard
particulier sur les deux fonctions de base qu’il offre : la signalisation et la fonction de la
transmission de la voix. Il est important de comprendre de quoi sont constituées la voix et
l’écoute chez l’homme. Pour finir cette partie, d’autres types de téléphones seront présentés
(conceptions propriétaires et postes numériques) ; l’objectif étant de comprendre comment
nous pourrons interfacer ces périphérique avec la VoIP.
a) Les fondamentaux de la voix
Fréquences
La voix résulte d’une vibration des cordes vocales, interrompant le flux d’air provenant des
poumons, produisant ainsi des signaux dans une gamme de fréquences allant de 50 à 5000 Hz.
Cette gamme de fréquence varie de manière sensible d’une personne à l’autre. La majorité de
l’énergie se concentre entre 300 et 3000 Hz. L’oreille humaine peut détecter des sons dans
une bande de fréquence allant de 20 Hz à près de 20 000 Hz, avec une sensibilité maximale
dans la bande 300 Hz – 10 000 Hz.
En prenant en compte ces différents facteurs, et à la suite de nombreux tests, la bande de

fréquence 300 Hz – 3400 Hz a été choisie comme base pour la transmission téléphonique.
Réduire cette bande de fréquence amène une perte d’intelligibilité des messages, alors que
l’augmentation de cette bande apporte certes une qualité supérieure, mais sans apporter une
qualité de reconnaissance ou d’intelligibilité significative.
Niveaux
Il est important de s’assurer que les signaux de voix sont transmis à des niveaux corrects à
travers le réseau, afin de maintenir une qualité de bout en bout. Un niveau trop faible fait que
Page 27 sur 248

le signal est noyé dans le bruit de fond ; un niveau de signal trop élevé amène la personne à
parler plus faiblement.
Aujourd’hui, les communications internationales sont monnaie courante. Les gens doivent
pouvoir communiquer avec leur voisin de palier, comme avec n’importe qui dans le monde.
Ce but est compliqué par le fait que les systèmes de téléphonie ont évolué de manière
différente dans plusieurs pays ou régions. Par exemple, un téléphone analogique aux USA
émet avec un niveau de signal plus faible que le même téléphone en Angleterre.
Les niveaux de signal s’expriment en décibels (dBs). (et en termes relatifs : dBm, dBm0 et
dBr.)
b) Le fonctionnement du téléphone
Aujourd’hui un poste téléphonique peut être classé dans deux catégories : analogique ou
numérique. Les postes développés à l’origine par A. Bell étaient analogiques. En fait, la
plupart des postes utilisés en environnement analogique sont toujours analogiques.
La forme la plus simple du téléphone aujourd’hui est le téléphone « deux fils » (loop
disconnect, ou loop start ou POTS : Plain Old Telephone Service). Il se connecte au
commutateur local par deux fils qui transportent le signal dans les deux directions. Ces fils
transportent également la numérotation vers le commutateur et le signal d’appel vers le
téléphone. Le commutateur envoie un signal de 48 V à travers cette paire pour alimenter le
téléphone, détecter le décrochage et l’activité de numérotation.
La signalisation
Pour initier un appel, l’utilisateur décroche le téléphone. Cette action ferme un interrupteur
dans le poste, et un courant circule en boucle (d’où le terme « loop start »). Le commutateur
détecte ce courant comme un appel entrant et fournit le signal de tonalité sur la ligne (440
Hz).Ce signal indique à l’utilisateur qu’il peut commencer à numéroter. Si le combiné
téléphonique utilise une numérotation par impulsions, le poste ouvre et ferme la boucle à une
vitesse de 10 ou 20 impulsions par seconde : c’est le système de numérotation par impulsions.
Le nombre d’impulsions est caractéristique de chacun des chiffres numérotés.
L’autre méthode aujourd’hui utilisée est la numérotation par fréquences vocales (DTMF :
Dual Tone Multi Frequency). Dans cette forme de signalisation, chaque chiffre est représenté
par un couple de fréquences qui sont transmises de manière simultanée sur la ligne pendant
une période de temps courte.
Page 28 sur 248

Ces fréquences sont définies par la recommandation de l’ITU-T Q.23. Cette méthode permet
un transfert plus rapide de la numérotation, et surtout la vitesse de transmission est
indépendante du chiffre numéroté. Ce système permet également de se servir d’autres touches
pour l’utilisation de boîtes vocales ou d’autres applications, comme la consultation de son
compte en banque…
Lorsqu’un appel téléphonique parvient au poste téléphonique, le commutateur local applique

un courant alternatif à la paire téléphonique. Pour répondre, l’utilisateur décroche le combiné
téléphonique. Cette action initie une boucle dans la ligne qui est détectée par le commutateur,
qui enlève alors ce signal, et applique le signal vocal.
SS7 (Signaling System 7)

Le Common Channel Signaling System N° 7 est un standard global de communications décrit
par l’ITU-T, qui définit les procédures et protocoles par lesquels les éléments des réseaux
publics commutés s’échangent des informations en utilisant un réseau numérique de
signalisation.
Ce réseau et ces protocoles sont utilisés pour :
- l’établissement, l’administration et l’arrêt des appels
- les services liés aux mobiles (authentification, …)
- les services liés aux numéros spéciaux (numéro vert, …)
- des fonctions avancées comme le transfert d’appel, l’affichage de l’appelant, la

conférence à trois, etc.
- l’amélioration et la sécurisation des communications internationales.
Page 29 sur 248

Les messages SS7 sont échangés par des éléments du réseau à travers des canaux
bidirectionnels (56Kbps ou 64 Kbps) appelés liens de signalisation (signaling links). Ces
canaux ne sont pas intégrés aux canaux de voix, mais sur des canaux de signalisation dédiés à
cette fonction. Cette méthode de signalisation (out of band) permet :
- des temps d’établissement plus rapides (en comparaison de la signalisation « in band »

comme l’utilisation de fréquences) ;
- une utilisation plus efficace des circuits de voix ;
- le support des services du réseau intelligent (IN : Intelligent Network) ;
- un contrôle amélioré sur l’utilisation des ressources du réseau (sécurisation).
Chaque point de signalisation (Signaling Point) est identifié de manière unique par un code
numérique (point code). Ces codes sont transportés dans les messages de signalisation entre
nœuds de ce réseau pour identifier de manière formelle la source et la destination de chaque
message. Une table de routage est utilisée dans ces nœuds pour sélectionner le meilleur
chemin pour joindre la destination.
3 types de point de signalisation ont été définis :
- SSP : Service Switching Point ;
- STP : Signal Transfert Point ;
- SCP : Service Control Point.
Les SSPs sont les commutateurs qui initient, terminent un appel. Un SSP envoie des messages
de signalisation à d’autres SSPs pour initialiser, administrer ou libérer des circuits de voix
nécessaire à la gestion des appels. Un SSP peut également envoyer une requête vers une base
de données centralisée (SCP) afin de déterminer comment router un appel particulier (ex :
numéro vert). Le SCP renvoie la réponse au commutateur d’origine contenant les
informations de routage avec le numéro appelé. Un chemin alternatif peut être utilisé par le
SSP si le premier numéro est occupé ou si le numéro échoue après un certain temps.
Le trafic entre les points de signalisation peut être routé par un commutateur de paquet appelé
STP. Un STP route chaque message d’entrée vers un lien de sortie en fonction des
informations de routage contenues dans le message SS7.
Le réseau SS7 étant stratégique pour l’établissement des appels, les SCPs et STPs sont
généralement doublés, et positionnés dans des emplacements physiques distants. Les liens
entre ces points sont également doublés. Le trafic est partagé à travers ces liens. Le protocole
SS7 permet à la fois la correction d’erreurs et la retransmission pour assurer un service
continu, quelque soit le problème (coupure de lien, etc.).
La transfert de la voix
En plus de la fonction de transfert de la numérotation, la principale fonction d’un poste
téléphonique est de transférer les communications vocales. Comme mentionné
précédemment, un poste simple doit transporter les signaux de voix dans les deux directions,
malgré le fait qu’il n’y a que deux fils. Cela est réalisé grâce à un circuit hybride, le but de ce
Page 30 sur 248

circuit étant de combiner les signaux d’émission et de réception (4 fils) sur 2 fils. Le
téléphone, la ligne téléphonique ainsi que l’interface créent une impédance qui détermine la
relation entre la tension et le courant sur la ligne. Afin de permettre un transfert aussi efficace
que possible du téléphone vers la ligne et vice versa, les impédances doivent être aussi
proches que possible. Cela est obtenu grâce à un circuit spécial, qui permet ainsi de réduire les
phénomènes de réflexion de signal entre la ligne et le combiné.
Autres types de téléphones.

Alors que le téléphone 2 fils est principalement utilisé dans le monde domestique et grand
public, il est nettement moins courant dans le monde professionnel, autour des commutateurs
d’entreprise (PABX : Private Automatic Branch Exchange), qui offrent de nombreuses
fonctionnalités supplémentaires. Ces fonctions varient d’un constructeur à l’autre. La plupart
des PABX utilisent aujourd’hui des interfaces numériques, mais permettent également
d’intégrer des combinés analogiques classiques. Dans ce cas, l’interface du PABX convertit le
signal analogique en signal PCM (voir ci dessous).
La plupart de ces postes numériques sont propriétaires, c’est à dire que le format des flux
numériques est toujours spécifique à un constructeur. Beaucoup de postes se réfèrent
cependant à la recommandation de l'ITU-T I.420 (ISDN). Cette interface définit une interface
numérique qui transporte deux canaux opérant à 64 Kbps (appelés canaux B) associés à un
canal de signalisation (appelé canal D) de 16 Kbps.
Les canaux B peuvent être utilisés pour transporter des données ou de la voix numérisée
d’une manière similaire aux interfaces PRI (Primary Rate Interface) qui seront définis dans
les parties suivantes. La différence principale tient dans le fait que sur une interface BRI
(Base Rate Interface) seuls deux canaux B sont disponibles. Le canal D est normalement
utilisé pour transporter les informations de signalisation (CCS : Common Channel Signaling)
pour le contrôle des appels d’une manière similaire à celle utilisée sur l’interface PRI. Les
spécifications permettent également au canal D de transporter des données (en mode paquet
ou en mode commuté).
Téléphonie 2 fils versus téléphonie 4 fils

Des confusions sont souvent faites entre combinés téléphoniques « 2 fils » ou « 4 fils ». Un
soin tout particulier doit être porté à la signification de ces termes. Un combiné « 2 fils »
signifie que la voix est transportée dans les deux sens sur une même paire, ce qui exige
l’utilisation de circuits hybrides pour séparer les signaux d’émission et de réception dans le
combiné. Il est également possible, particulièrement dans des postes d’architectures
propriétaires d’ajouter des paires supplémentaires, notamment pour la signalisation. Dans ce
cas, un combiné « 2 fils » se connecte au commutateur par plus d’une paire de fils.
Un combiné téléphonique réellement « 4 fils » signifie que la voix est transportée de manière
séparée pour l’émission et la réception.
3) Les commutateurs privés ou PABX (Public Automatic

Branch Exchange)
Cette section décrira de manière simplifiée les fonctions importantes d’un commutateur privé
d’entreprise. On parle sans distinction de PABX ou de PBX.
Page 31 sur 248

a) Présentation d’un commutateur

Un PABX peut être simplement défini comme un auto commutateur appartenant à une
entreprise privée. Son but est de fournir un service de voix (ainsi qu’un service de données
dans la plupart des cas) pour des utilisateurs. En plus du service de voix, il offre de
nombreuses autres fonctionnalités qui rendent la tâche des utilisateurs plus simple, comme un
numéro d’extension pour joindre un utilisateur au sein d’une entreprise. Dans le cas où l’appel
doit être routé sur le réseau public, un code d’accès (« 0 » ou « 9 ») doit précéder le numéro
complet.
La plupart des PABX sont aujourd’hui numériques. Cela signifie que les communications
sont faites de manière numérique, la voix étant systématiquement transformée dans un format
numérique (PCM : Pulse Code Modulation, voir plus loin).
Le cœur du PABX est constitué de deux parties : la matrice de commutation et la partie

contrôle. Cette partie contrôle est le cerveau du PABX : elle réalise les fonctions de détection
d’un appel, de génération de la tonalité, d’interprétation des numéros composés et du routage
des appels vers une interface numérique… La matrice de commutation réalise la commutation
entre les canaux de 64 Kbps provenant de plusieurs lignes à 1,544 Mbps ou 2,048 Mbps.
Les interfaces d’un PABX sont de deux types : les interfaces « lignes » ou les interfaces
« trunk ». Les interfaces de type ligne connectent les postes utilisateurs, qu’ils soient
analogiques ou numériques, ou d’autres éléments comme des terminaux de données. Les
« trunks » ou canaux sont des lignes partagées qui connectent le PABX soit au domaine
public (PSTN Trunk) soit au réseau de l’entreprise (Private Trunk ou Tie Line / Tie Trunk).
b) Le routage des appels dans un PABX
Lorsqu’un utilisateur compose le numéro d’un destinataire, le PABX a besoin de déterminer

comment acheminer l’appel d’une manière la plus efficace possible. La fonction
d’acheminement doit analyser plusieurs paramètres, comme : est ce que le numéro composé
est valide ? L’utilisateur a t il les droits pour appeler ce numéro ? Quel est le lien le moins
cher pour acheminer l’appel ? Y a t il un canal libre pour cet appel ? Dans le cas de PABX
interconnectés entre eux sur un réseau d’entreprise, les appels sont acheminés de PABX en
Page 32 sur 248

PABX à travers ces canaux, en utilisant des tables de routage qui permettent de réaliser de
manière efficace cette fonction d’acheminement.
c) Types d’interfaces sur un PABX

Les types d’interfaces présentes sur un PABX sont nombreuses et variées. Elles tombent dans
trois catégories :
- les interfaces « ligne » : ce sont les interfaces qui permettent la connexion des postes
utilisateurs ou des terminaux de données. Elles peuvent être de type « 2 fils », « 2
fils » ou « 4 fils » avec des caractéristiques propriétaires ou « 4 fils » en format
numérique, soit propriétaire, soit dans un format respectant la spécification ISDN BRI.
- les interfaces « trunk » privées, qui permettent l’interconnexion de PABX entre eux
sur un réseau d’entreprise. Ces interfaces permettent la communication d’utilisateurs
sans passer par le réseau public, permettant des économies. Elles peuvent être de type
« 2 fils » ou « 4 fils » avec une signalisation de type « E&M » (Earth & Mouth), « 4
fils » en analogique avec une signalisation de type AC15, ou complètement
numériques avec une signalisation CAS ou CCS.
- les interfaces « trunk » publiques, qui interconnectent le PABX au réseau public pour
les appels entrants / sortants. Elles peuvent être de type analogique (« 2 fils ») avec
des appels dans les deux sens, analogique avec appels entrants uniquement (ADDI :
Analog Direct Dial In), ou complètement numériques avec une signalisation CAS ou
CCS.
4) Numérisation de la voix
a) Les « trains » numériques normalisés – 1,544 Mbps / 2,048
Mbps
Ces systèmes furent les premiers composants permettant l’utilisation de la voix numérisée
d’une manière pratique. Ces éléments réalisent les fonctions de numérisation de la voix
(conversion analogique / numérique), puis la fonction de multiplexage sur des liens haute
vitesse. Deux systèmes existent aujourd’hui, le premier supportant 24 canaux de voix (1,544
Mbps), le second 30 ou 31 canaux (lien numérique 2,048 Mbps).
Le premier fut développé en Amérique du Nord en 1962, et prit le nom « D1 ». Il fournissait

24 entrées analogiques, chacune d’entre elles étant convertie en un signal PCM 8 bits (le bit le
moins significatif étant ignoré). Les 7 bits étaient utilisés pour chaque échantillon de voix, et
un bit pour la signalisation, pour un débit global de 1,544 Mbps. Il fut ensuite remarqué que
ce mode fournissait une qualité de voix non satisfaisante. Les générations suivantes utilisent
une conversion PCM 8 bits.
Ces systèmes ont évolué pour supporter plus que les simples signaux de voix analogiques.
Aujourd’hui, ces systèmes supportent de nombreux types d’interface, outre le simple signal
analogique, comme :
- le téléphone « 2 fils » ;
- le téléphone « 2 fils » ou « 4 fils » avec la signalisation E&M (Earth & Mouth) ;
Page 33 sur 248

- des données 0 – 64 Kbps ;
- des données n canaux 64 Kbps.
b) La numérisation de la voix : PCM (Pulse Code Modulation)

G.711
Un signal numérique est une suite de « 0 » et de « 1 » (Binary Digits ou bits) qui proviennent
de deux opérations : l’échantillonnage et la quantification. Lorsque l’utilisation parle, les
variations de pression sont transformées en un signal électrique par le microphone, qui est
l’analogue électrique de ces variations de pression (d’où le terme signal analogique). Ce
signal est alors transformé en un signal numérique, suite de bits, qui représentent ce signal
analogique.
Les raisons de cette conversion sont nombreuses, mais les plus importantes sont :
- de rendre indépendant le signal de la distance : lorsqu’un signal analogique est

transporté sur un canal de transmission, il subit de nombreuses modifications, comme
l’atténuation ou l’ajout de bruit, qui affectent la qualité de cette transmission. A
l’arrivée, après amplification, le signal originel est mêlé à du bruit, ce qui dans
certains cas, rend difficile la compréhension du message. Les signaux numériques ne
prenant que deux valeurs, « 0 » ou « 1 », le bruit occasionné par les canaux de
transmission peut être enlevé de manière simple et efficace. Le signal arrivant est une
réplique exacte du message d’origine, d’où une qualité sans équivalent.
- de pouvoir facilement multiplexer sur un même canal de transmission plusieurs

signaux de voix, qui sont agrégés sur un même lien physique. Ces signaux n’étant que
de simples données, ils peuvent être mêlés à d’autres signaux.
La méthode utilisée pour la représentation numérique des signaux de voix dans les systèmes
de téléphonie a été définie par l’ITU-T dans la recommandation G.711. Le signal analogique
Page 34 sur 248

est échantillonné à une fréquence de 8000 fois par seconde (8 kHz). Cette fréquence est
dérivée de la loi de Nyquist, qui impose le taux d’échantillonnage doit au moins être égal au
double de la fréquence maximal du signal d’origine. Le signal échantillonné n’est qu’une
suite d’impulsions (PAM : Pulse Amplitude Modulation) qui représente l’amplitude du signal
analogique lors de chaque échantillonnage. Chaque échantillon est comparé à certains niveaux
de quantification, chacun étant représenté par une suite numérique unique. La suite numérique
la plus proche du signal échantillonné est alors utilisée pour représenter le signal (opération de
quantification). Le nombre de niveaux de quantification étant limité, ce processus induit une
erreur entre la représentation numérique et le signal analogique (bruit de quantification ou
distorsion). Plus le nombre de bits utilisés pour cette représentation est important, plus
l’erreur est faible. En pratique, l’oreille humaine étant plus sensible aux distorsions sur des
signaux faibles que sur des signaux de forte amplitude, il a été possible de réduire le nombre
de bits, grâce à des méthodes particulières.
Lois A et mu
Il existe deux types de lois, la loi A et la loi mu, chacun étant utilisée dans des régions ou pays
différents. L’Amérique du Nord et le Japon utilisent la loi mu, alors que la plupart des autres
pays utilisent la loi A. Les deux types sont définis dans la recommandation de l’ITU-T G.711,
chacune différant sur un certain nombre de points. Par exemple, pour la loi A, après la
conversion PAM vers PCM, les bits impairs sont inversés avant transmission. Cette inversion
de bits fut conçue à l’origine pour s’assurer qu’un nombre de « 1 » suffisant soit présent sur la
ligne, un canal sans activité étant représenté par une suite de « 0 » sans cette modification. En
fait, dans le cas d’un train numérique à 2,048 Mbps, cette inversion n’est pas nécessaire,
puisque le problème du nombre de « 0 » est traité par l’encodage numérique sur la ligne
physique (codage « HDB3 »).
Pour ces raisons, et lors de l’interconnexion de systèmes différents entre pays implémentant
des lois différentes, il est nécessaire d’appliquer des fonctions de conversion, qui sont
explicités dans la recommandation G.711.
La loi "A"
Selon la proposition de la conférence européenne des postes et télécommunications (CEPT),
adoptée ensuite par le CCITT (G.711), la caractéristique de compression logarithmique idéale
a été approchée par le compromis suivant :
A  86,7
A x 1
y x
1  ln  A A
1  ln  A  x  1
y  x 1
1  ln  A A
Cette loi possède des petits pas de quantification à bas niveau et des grands pas à haut niveau :
Page 35 sur 248

Loi "A"
1,5
0,5
0
-1
-0
-0,9
-0,8
-0,6
-0,5
-0,4
-0,3
-0,2
0,0
0,2
0,3
0,4
0,5
0,6
0,8
0,9
-0,5
-1
-1,5
La loi "mu"
Les Américains ont normalisé une loi différente fondée sur la loi suivante :
m  255
ln 1  m  x 
y 1  x  1
ln 1  m
Loi "mu"
1,5
0,5
0
-1
-0
-0,9
-0,8
-0,6
-0,5
-0,4
-0,3
-0,2
0,0
0,2
0,3
0,4
0,5
0,6
0,8
0,9
-0,5
-1
-1,5
Page 36 sur 248

c) Puissance d’un signal numérique

Il est facile de mesurer la puissance d’un signal analogique, grâce à l’utilisation d’un
puissancemètre. Dans le monde PCM, il n’y a pas de méthode directe équivalente. A la place,
une relation d’équivalence spécifique a été définie entre un signal analogique et une séquence
numérique. Cette relation est définie dans la recommandation G.711 dans deux tables (une
pour la loi mu et l’autre pour la loi A) qui définit une séquence d’échantillons PCM. Après
décodage, ces échantillons forment un signal analogique de fréquence égale à 1 KHz, à un
niveau nominal de 0 dBm0. Cela définit alors un niveau maximum théorique de + 3,17 dBm0
pour la loi mu et de + 3,14 dBm0 pour la loi A. Tout dépassement de ce niveau induit une
distorsion du signal.
Système Européen Système Américain
Description
G.732 G.733
Fréquence d'échantillonnage 8 KHz 8 KHz
Nombre de niveau 256 127
Nombre de bit/échantillon 8 7
Débit binaire par voie 64 Kbit/s 64 Kbit/s
Quantification non uniforme non uniforme
Loi de codage loi A loi m
Caract. de compression à 13 segments à 15 segments
Nombre d'IT 32 24
Nombre de voie 30 24
Nombre de bits/trame 256 193
Débit binaire total 2,048 Mbit/s 1,544 Mbit/s
Verrouillage groupé réparti
Signalisation hors octet dans l'octet
d) Distorsion apportée par le processus de quantification
Lors du processus de quantification, une erreur est induite entre le niveau réel et le niveau
correspondant au niveau le plus proche défini par la méthode de quantification. Cette erreur
est décrite plus en détail plus loin.
5) L’interface numérique 1,544 Mbps (DS-1)

Cette interface 1,544 Mbps est commune en Amérique du Nord et au Japon, et est souvent
appelée « T1 » ou « DS-1 » (en pratique, ces deux termes sont souvent utilisés de manière
interchangeable, ce qui n’est pas vrai. DS-1 se réfère à la vitesse particulière de 1,544 Mbps,
alors que le terme T1 se réfère à un système de transmission numérique). Cette interface offre
23 ou 24 intervalles de temps (« ITs » ou « Time Slots »), la différence provenant du type de
signalisation utilisé.
Page 37 sur 248

Entrées Sortie
8 000 trames par seconde
(1 trame par 125 µs)
C.1
C.2 1 octet (8 bits) par canal dans l’ordre séquentiel
C.3
. T1
C.1 C.2 C.3 ... C.23 C.24 C.1
. Multiplexeur
.
C.23
Bit de trame Bit de trame
C.24
suivant
64 kbps x 24 = 1,536 Mbps

Chaque entrée (canal)
+ les bits de trames (8 kbps)
représente 64 kbps
Débit total : 1,544 Mbps
Interface
Interface numérique
numérique T1
T1 (24
(24 canaux)
canaux)
Dans les pays supportant l’interface DS-1, plusieurs types « T1 » sont offerts : deux types
principaux cohabitent :
- AMI (Alternate Mark Inversion) : le problème de cette spécification électrique est

qu’elle peut engendrer une suite importante de « 0 » sur le support de transmission, ce
qui peut amener à une perte de synchronisation. C’est donc à l’équipement de
transmission de s’assurer que le nombre de « 1 » est suffisamment important pour
éviter ce problème ;
- B8ZS (Bipolar 8 Zeros Substitution) : des viols de codes sont introduits dans le flux
numérique suite à une détection d’un nombre important de « 0 ». Cette technique est
similaire à celle utilisée par le codage HDB3 (voir ci dessous).
a) L’interface physique
DS-1 n’est supporté que sur un câble paires torsadées, à la différence d’E1 qui est supporté
sur un câble coaxial (mode unbalanced) et sur des câbles à paires torsadées :
Paire torsadée
Gaine extérieure Gaine extérieure Conducteur de cuivre
Isolant de plastique
Blindage Isolant de cuivre tressé Isolant de plastique
Conducteur de cuivre
Câble
Câble torsadée
torsadée blindée
blindée (STP)
(STP) Câble
Câble coaxial
coaxial
DS-1 utilise le codage de ligne AMI pour encoder électriquement le signal sur la ligne de
transmission. Cependant, pour éviter le problème de la perte de synchronisation, le codage
Page 38 sur 248

B8ZS peut également être utilisé, à la place du codage HDB3. Le mode de fonctionnement de
B8ZS est de remplacer une suite de 8 zéros consécutifs avec un code qui introduit un viol de
code dans les positions des 4 et 7 bits. Cela assure un nombre minimum de transitions au
niveau électrique, qui permet d’éliminer toute composante continue du signal.
b) Framing D4
Il y a deux types de format de trame utilisés sur une interface DS-1 : D4 et l’ESF (Extended
SuperFrame).
D4 consiste en une trame de 193 bits avec un taux de répétition de 8000 trames par seconde,
donnant le débit de transmission de 1,544 Mbps, chaque trame durant 125 us (micro
secondes). Chaque trame contient 24 time slots de 8 bits chacun, du time slot 1 au time slot
24, et un seul bit appelé « F » ou « Framinig bit ». Tous les 24 time slots sont normalement
utilisables pour du trafic, sauf lors de l’utilisation de la signalisation CCS. Dans ce cas, le
timeslot 24 est utilisé comme canal de signalisation.
La reconnaissance des trames est garantie par l’utilisation du bit « F » sur une séquence de 12
trames, qui constitue une « super trame ». Dans les trames impaires, le bit F est appelé Ft pour
Terminal Framing, et permet l’alignement de trames. Dans les trames paires, le bit F est
appelé Fs, et permet l’alignement entre super trames.
c) Framinig – ESF (Extended Super Frame)

Aujourd’hui, le format ESF est plus courant que le format D4, en raison des facilités de
monitoring de performance d’un lien T1. Cela n’était pas possible avec D4, l’envoi de trafic
utile devant être stoppé pour effectuer des tests de performance.
La supertrame étendue (« Extended Superframe ») étend le format de la super trame

(constituée à l’origine de 12 trames) à une super trame de 24 trames. Le rôle du bit F est
également changé. Seules 6 des 24 trames de l’ESF sont désormais utilisées à des fins de
synchronisation. Sur les 18 bits F restants, 6 sont utilisés pour une vérification de l’intégrité
de la trame (CRC), les 12 derniers constituant le FDL (Facility Data Link). Le FDL est
également connu sous le nom de DL (Data Link) et parfois sous le nom d’EOC (Embedded
Operation Channel). Le FDL est disponible pour le transfert des alarmes, les loop backs et des
informations de performance entre équipements de terminaison de ligne, comme les CSUs
(Customer Service Units), qui terminent les T1s dans les locaux du client.
d) CAS – Channel Associated Signaling (CAS) - DS-1

Le processus utilisé est le même que pour les trames D4 et ESF. Cependant, pour D4, seuls 2
bits de signalisation, A et B sont utilisés. Avec ESF, 4 bits sont utilisés : A, B, C et D.
La méthode utilisée est appelé « vol de bit » (robbed bit), parce que le bit le moins significatif
de chaque IT ou timeslot de trafic est utilisé pour transporter un signal de signalisation plutôt
que du trafic. Les autres bits restent utilisés pour le trafic utile, qui peut être un signal PCM.
Toute distorsion introduite au signal de voix PCM par cette technique est négligeable et peut
être ignorée. Cependant, pour des signaux de données, cette distorsion peut ne pas être
négligeable. Cela explique que le débit de trafic utile passe de 64 Kbps à 56 Kbps, avec les 7
bits les plus significatifs utilisés.
Page 39 sur 248

e) CCS – Common Channel Signaling (CCS) - DS-1

Dans cette méthode, l’IT ou timeslot 24 est utilisé pour transporter les informations de
signalisation dans un format de message HDLC (High Level Data Link Control).
6) L’interface numérique 2,048 Mbps (E1)

L’interface numérique à 2,048 Mbps, parfois appelée interface « E1 », a été conçue selon la
recommandation de l’ITU-T G.732 (« Characteristics of Primary PCM Multiplex Equipment
Operating at 2,048 Mbps »). Elle fait appel aux recommandations suivantes :
- G.703 : « Physical / Electrical Characteristics of Hierarchical Digital Interfaces » ;
- G.704 : « Synchronous Frame Structures Used at Primary and Secondary Hierarchical

Levels » ;
- G.711 : « Pulse Code Modulation (PCM) of Voice Frequencies ».
a) L’interface physique – G.703

La recommandation de l’ITU-T G.703 définit les caractéristiques électriques pour de
nombreux types/débits d’interfaces, incluant les débits de 64 Kbps, 1,544 Mbps, 6,312 Mbps,
32,064 Mbps, 44,736 Mbps, 2,048 Mbps, 8,448 Mbps, 34,368 Mbps, 139,264 Mbps, 97,728
Mbps et 155,52 Mbps. Les applications autour de la voix en Europe utilisent principalement
l’interface 2,048 Mbps. Deux types d’interface physique sont utilisés : l’interface coaxiale 75
ohms (mode unbalanced), et l’interface paires torsadées 120 ohms (balanced mode). Les
paramètres de tension, tolérance de tension et de fréquence, ainsi que beaucoup d’autres sont
explicités par la recommandation G.703.
Les bits de données sont transmis en utilisant le code AMI, suivi de l’encodage de ligne
HDB3 (High Density Bipolar 3). L’objectif de ce traitement est double : d’abord, enlever
toute composante continue au signal (fonction réalisée par le codage AMI) et d’autre part,
s’assurer d’un nombre minimum de transitions du signal (fonction réalisée par HDB3), qui
garantit la synchronisation de part et d’autre. AMI utilise un signal à 3 niveaux. HDB3, définit
par G.703, remplace chaque bloc de 4 zéros successifs par un pattern de soit 000V ou B00V,
B représentant une impulsion qui se conforme à la règle AMI, et V représentant le viol
apporté par AMI.
b) La structure des trames – G.704

La recommandation G.704 définit les structures de trames utilisées à des débits de lignes de
1,544 Mbps, 6,312 Mbps, 2,048 Mbps et 8,448 Mbps.
Une trame de 256 bits est définie à un taux de répétition de 8000 par seconde, donnant un
débit global de 2,048 Mbps et une durée de trame de 125 us (micro secondes). Chaque trame
comprend 32 ITs ou Time Slots, allant de 0 à 31. L’IT 0 est utilisée à des fins de
synchronisation et de génération d’alarme. L’IT 16 est généralement utilisée pour transporter
les informations de signalisation (utilisée dans certains cas pour du trafic utile). Les ITs 1 à 15
et de 17 à 31 sont transporter 30 canaux de trafic utile, qui peut être un signal PCM par
exemple. Cependant, chacun de ces ITs représente un canal de 64 Kbps, qui peut être utilisé
pour toute forme de trafic, incluant des données.
Page 40 sur 248

Une trame E1
2 1 0 31 30 ... 19 18 17 16 15 14 ... 3 2 1 0 31 Ligne E1
Canaux B Canaux B
transportant les transportant les
informations informations
Canal D
IT 0 de
Transportant les
synchronisation
informations pour
les canaux B
Trame
Trame E1
E1
Les ITs 0 transportent différents types d’informations à des fins de synchronisation et de
génération d’alarmes. Le bit « A » (également appelé RAI pour Remote Alarm Indication) est
positionné à 0 en fonctionnement normal et à 1 lors d’une condition d’erreur. D’autres bits,
comme Si ou Sa4-Sa8 sont de moindre importance. Si est utilisé pour un usage international.
G.704 spécifie l’utilisation de Si comme code CRC. Les autres bits sont utilisés à des fins de
monitoring des performances.
c) CAS – Channel Associated Signaling (CAS) – E1
CAS définit l’utilisation de bits spécifiques à l’intérieur de la trame pour le transport de la

signalisation pour chacune des ITs de trafic. L’information pour chacune des ITs est transmise
dans un groupe de 4 bits, appelés 1, B, C et D. Puisque l’IT 16 n’a que 8 bits disponibles pour
supporter 30 ITs de trafic, une structure multi trames constituée de 16 trames (trames 0 à
trame 15) est définie pour permettre aux bits A, B, C et D d’être transportés pour les 30 ITs.
La trame 0 transporte le signal MFAS (Multi Frame Alignment Signal) constitué de 4 zéros.
Cette suite permet à l’équipement de réception d’identifier les trames, et d’affecter une IT de
trafic avec sa signalisation. La trame 0 transporte également un indicateur d’alarme, indiquant
une perte de synchronisation multi trames. Dans ce système, l’IT 16 de la trame 1 transporte
les bits A, B, C et D pour les ITs 1 et 17, l’IT 16 de la trame 2 les bits A,B, C et D pour les
ITs 2 et 18, et ainsi de suite jusqu’à la trame 15 qui transporte les bits A, B, C et D pour les
ITs 15 et 31. La séquence se répète par la suite.
d) CCS – Common Channel Signaling (CCS) – E1

CCS utilise l’IT 16, comme le fait le mode CAS. Cependant, plutôt que de spécifier des bits
qui transportent la signalisation pour chacun des ITs de trafic, l’information de signalisation
est envoyée sous format de message HDLC.
Page 41 sur 248

e) Alarmes E1
La recommandation G.732 décrit de nombreuses conditions d’erreur et les actions à
entreprendre, comme une panne d’alimentation, de codec, etc …
7) Le besoin de la synchronisation entre commutateurs

De manière similaire à de nombreux systèmes numériques, les commutateurs numériques
fonctionnent de manière synchrone. Lorsque deux commutateurs sont reliés ensemble par un
lien numérique, ils doivent être synchronisés afin d’éviter des pertes de synchronisation.
Les interfaces numériques des commutateurs ont des mécanismes de type buffer pour traiter
les problèmes de type jitter, gigue, imprécision légère entre horloges. Cependant, dans le cas
où cette désynchronisation est trop importante, le buffer va se remplir. Une fois rempli, il doit
être vidé. Il en résulte des pertes de données et/ou de synchronisation entre trames. Le
processus de synchronisation doit être réinitialisé et rapidement opérationnel, pour permettre
un transfert des données. Les exemples suivants montrent deux commutateurs connectés sans
synchronisation, le second montrera le cas contraire.
a) Commutateurs sans synchronisation
Les deux commutateurs sont interconnectés par une liaison 2,048 Mbps. Ceci est une vitesse
nominale, et une légère différence est inévitable. Il est possible par exemple que l’horloge
d’émission du commutateur 1 aille un peu plus vite, 2,048001 Mbps, par exemple. Cela
représente une imprécision de 5 pour 10 millions, ce qui n’est pas improbable. L’horloge de
réception du commutateur 2 peut elle être de 2,047599 Mbps, ce qui représente également une
erreur de 5 pour 10 millions.
Chaque seconde, le commutateur 1 transmet 2 048 001 bits de données sur le lien trunk, et le
commutateur 2 reçoit 2 047 599 bits, laissant 2 bits dans le buffer de réception du
commutateur 2. Cela continue chaque seconde, jusqu’à remplissage complet du buffer,
causant à cet instant un vidage complet de ce dernier, qui déclenche une perte de
synchronisation. L’effet est difficile à prédire, mais il causera certainement des bruits sur les
communications en cours sur le lien ou une déconnexion totale.
b) Commutateurs avec synchronisation

Le système est alors conçu de telle manière que l’horloge du commutateur 2 se synchronise
sur les données arrivant sur le lien trunk. Le commutateur continue à envoyer les données au
rythme de 2 048 001 par seconde, mais le commutateur 2 les reçoit désormais à la même
vitesse. Le buffer ne se remplit pas, et la synchronisation des trames est garantie.
Des règles ont été définies pour garantir cette synchronisation, l’une d’entre elles étant que le
réseau entier doit être synchronisé par rapport à une seule et unique horloge. Dans de
nombreux cas, le réseau des opérateurs est utilisé pour garantir cette synchronisation sur un
réseau privé, une interconnexion avec une interface ISDN étant généralement un bon étalon
(horloge atomique de haute précision).
Page 42 sur 248

8) Analyse du trafic
Que se soit pour la téléphonie classique ou le VoIP que nous expliquerons plus tard, il y a
deux facteurs important : la qualité et le coût. La qualité est essentielle pour que le client soit
content. Le coût est le principal composant de la rentabilité. Afin d’avoir des coût minimum,
il est nécessaire d’optimiser la taille de la solution et en particulier le réseau qui sera utilisé.
En pratique, l’expérience nous permet de connaître le trafic qui transitera sur le réseau. Mais
cela est de plus en plus difficile. Le trafic est défini comme une quantité de données qui
circule durant une période de temps. L’analyse de ce trafic nous permet donc de connaître la
bande passante nécessaire.
a) La théorie du trafic
Unités de mesure
Tout d’abord, il est nécessaire de connaître la charge de trafic. Il s’agit en réalité de la durée
moyenne d’un appel. On l’obtient en divisant le temps total passé en ligne par le nombre
d’appel. Par exemple, si durant une période donnée (une heure), nous avons eu 23 appels pour
une durée total de 3976 secondes, la durée moyenne d’appel (ou AHT : Average Hold Time)
est de 172,87 seconds :
3976
 172,87
23
L’unité de mesure que nous utilisons pour la charge de trafic est le erlang. Un erlang
correspond à la charge maximale d’un réseau durant une heure. Le trafic en erlang est le
produit du nombre d’appel par la durée moyenne (en seconde), divisé par 3600 :
23 *172,87
 1,104
3600
Une autre unité est toutefois utilisée, le CCS (Centum Call Seconds) : 1 erlang = 36 CCS.
Heure de pointe
On mesure généralement le trafic durant une heure de charge maximale (ou BHT : Busy Hour
Traffic). Dans une entreprise classique, le trafic durant une heure de pointe correspond entre
15 et 20 % du trafic journalier. (Dans nos calculs nous utiliserons donc 17 %). De même, le
AHT moyen est situé entre 180 et 210 secondes.
Page 43 sur 248

Heure de Pointe
Traffic
6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
Heure de la journée
Trafic
Trafic téléphonique
téléphonique en
en France
France
Mesure de la capacité du réseau

Il existe différent moyen pour mesurer la capacité d’un réseau téléphonique :
- Tentatives d’appel durant l’heure de pointe (ou BHCA : Busy Hour Call Attempts)
- Appels aboutis durant l’heure de pointe (ou BHCC : Busy Hour Call Completions)
- Appels par secondes (ou CPS : Calls per Second)
Toutefois, toutes ces mesures sont basées sur un nombre d’appel et ne prennent pas en compte
la durée d’un appel. Il est donc nécessaire d’utiliser un AHT pour obtenir le BHT que nous
utilisons pour l’analyse du trafic.
Grade of Service
Le GoS (Grade of Service ou Degré de Service en français) est la probabilité qu’un appel soit
bloqué à cause du sous dimensionnement du réseau. Il est écrit sous la forme P.xx où xx est le
pourcentage d’appels bloqués. Par exemple, un trafic qui nécessite un GoS de P.01 signifie
qu’on accepte une probabilité de 1 % que l’appel soit bloqué. Un GoS de P.00 est rarement
demandé car cela signifie que 100 % des appels ne seront pas bloqués et qu’il est nécessaire
de dimensionner le réseau en conséquence.
Types de trafic
Il est facile d’utiliser les équipements de télécommunication pour obtenir les enregistrements
du trafic. Toutefois, les équipements n’enregistrent que le trafic transporté dans le système. Et
effet, les équipements n’enregistrent pas les pertes liées au GoS. La différence entre le trafic
transporté et le trafic réel peut engendrer des aberrations dans les calculs.
Evidement, plus le pourcentage de blocage est grand et plus la différence entre ces deux types
de trafic est grand lui aussi :
Page 44 sur 248

Charge transporté
Charge réelle 
1  Facteur bloquant
Toutefois, cette formule ne prend pas en compte les tentatives multiples qui se produise
lorsqu’un appel est bloqué. Pour cela, il est nécessaire d’intégrer un Facteur Réajusteur de
Charge (FRC ou OAF : Offered Load Adjustment Factors) :
Charge réelle  Charge transporté  Facteur Réajusteur de Charge (FRC)
FRC 
1,0  R  Facteur bloquant 
1 - Facteur bloquant
R est la probabilité de tentative multiple.
Méthodes d’échantillonnage
La précision de notre analyse du trafic dépendra de la précision de notre méthode
d’échantillonnage. De nombreux paramètres peuvent faire varier la charge :
- Jour de travail ou non
- Vacances
- Type de trafic (Modem, Fax, Téléphone…)
- Période d’échantillonnage
- Nombre total d’échantillon
- Stabilité de la période d’échantillonnage
Selon la théorie de probabilité des réseaux voix, il est nécessaire d’avoir au moins 30
échantillons dans une période qui corresponde à une heure de pointe. Pour monter en
exactitude, il faut le maximum d’échantillons possible. Toutefois, même des échantillons tout
au long d’une année ne permettent pas une parfaite exactitude. En effet, la charge peut varier
d’une année à une autre. L’ITU-T (International Telecommunication Union
Telecommunication Standardization Sector) fournit des recommandations pour les
échantillons qui serviront au dimensionnement du réseau.
L’ITU-T recommande des tranches d’échantillonnage pour la connexion PSTN de 15 ou 60

minutes. Ces intervalles sont important afin de pouvoir faire une moyenne de l’intensité du
trafic durant ces périodes. Si nous faisons des mesures tout au long de la journée, il est alors
possible de trouver l’heure de pointe. Il y a deux moyens de déterminer cette heure de pointe :
- Période de pointe (ou DPP : Daily Peak Period) : consiste à enregistrer la charge de
trafic durant une journée. Cette méthode nécessite des mesures continues et est
généralement utilisées dans des environnements où l’heure de pointe diffère d’un jour
à l’autre.
- Intervalle de mesure fixe (ou FDMI : Fixed Daily Measurement Interval) : nécessite
des mesures seulement durant les périodes de pointes prédictives. Cette méthode est
Page 45 sur 248

utilisée quand la charge est prévisible et que les périodes de pointes interviennent
régulièrement. En entreprises, ces heures se situent généralement de 10h00 à 11h00 et
de 14h00 à 15h00
Dans l’exemple ci-dessous, nous avons utilisé la méthode FDMI. L’heure de pointe est située
à 10h00 avec une charge de 60,6 erlangs :
Lundi Mardi Mercredi Jeudi Vendredi Total
9h00 12,7 11,5 10,8 11,0 8,6 54,6
10h00 12,6 11,8 12,5 12,2 11,5 60,6
11h00 11,1 11,3 11,6 12,0 12,3 58,3
12h00 9,2 8,4 8,9 9,3 9,4 45,2
13h00 10,1 10,3 10,2 10,6 9,8 51,0
14h00 12,4 12,2 11,7 11,9 11,0 59,2
15h00 9,8 11,2 12,6 10,5 11,6 55,7
16h00 10,1 11,1 10,8 10,5 10,2 52,7
Charge en erlangs en fonction de l'heure
70,0
60,0
50,0
40,0
30,0
20,0
10,0
0,0
9h00 10h00 11h00 12h00 13h00 14h00 15h00 16h00
En utilisant la méthode DDP, nous obtenons :

Lundi Mardi Mercredi Jeudi Vendredi Total
Charge Max 12,7 12,2 12,5 12,2 12,3 61,9
Heure de pointe 9h00 14h00 10h00 10h00 11h00
Avec la première méthode, nous obtenons une charge de 60,6 erlangs et avec la seconde une
charge de 61,9 erlangs.
Il est également nécessaire de regrouper les mesures en fonction du type de jour. L’ITU-T
défini ces groupes : jour normaux, week-end et jours fériés.
La recommandation E.492 de l’ITU-T détermine également une intensité normale et une

intensité élevée de trafic dans un mois. Une intensité normale correspond à la charge du 4 ème
jour le plus intense dans le mois. Une intensité élevée correspond à la charge du 2ème jour le
plus intense dans le mois. Ces résultats permettent d’avoir les charges mensuelles attendus.
Page 46 sur 248

b) Critère pour choisir un modèle

Maintenant que nous avons des mesures, il faut savoir les utiliser. Il est pour cela nécessaire
de prendre un modèle de trafic approprié. Le choix d’un modèle se fait en fonction de quatre
paramètres :
- Le type d’arrivée
- Les appels bloqués
- Le nombre de sources
- La durée d’appel
Types d’arrivée
La première étape pour choisir un modèle est de déterminé le type d’arrivée des appels. Le
type d’arrivée des appels correspond en réalité à la répartition des arrivées des appels dans le
temps. C’est un paramètre important car il affecte énormément les équipements. Les trois
types d’arrivées des appels sont :
- Régulier
- Par pique
- Aléatoirement
Régulier
Une arrivée régulière ou hypo-exponentielle signifie qu’il n’y a jamais une grande variation
du trafic. La durée d’un appel et la durée entre deux appels sont prévisibles ce qui permet de
prévoir le trafic en fonction du nombre de sources. Par exemple, le trafic sortant d’une société
de télémarketing est tout a fait prévisible : durant une période de une heure, nous pouvons
prévoir 30 appels de 2 minutes chacun par agent. La charge pour un agent est donc très proche
du 1 erlang et le nombre d’appels en fonction du temps reste quasiment constant :
Appels
Temps
Arrivées
Arrivées régulières
régulières
Page 47 sur 248

Par pique
Une arrivée par pique ou hyper-exponentielle signifie que les appels arrivent par paquets. Il
est alors nécessaire de prévoir des ressources suffisantes. Par exemple pour répondre à 30
appels en simultanés, il faut 30 lignes.
Appels
Temps
Arrivées
Arrivées par
par pique
pique
Aléatoire
Une arrivée aléatoire est comme sont nom l’indique : aléatoire. Elle est aussi connue sous le
nom de distribution de Poisson ou exponentielle. On remarque généralement ce type de trafic
dans un environnement avec un PBX : il y a un grand nombre d’utilisateurs, chacun générant
un peu de trafic :
Appels
Temps
Arrivées
Arrivées aléatoires
aléatoires
Appels bloqués
Un appel bloqué est un appel qui ne peut pas aboutir immédiatement. Un appel est considéré
comme bloqué s’il est rerouté vers une autre ligne, placé dans une queue ou mis en attente
avec une musique. La nature du blocage détermine le modèle à utiliser. En effet, la nature du
blocage détermine la charge de trafic.
Page 48 sur 248

Les principaux types de blocage sont :
- LCH (Lost Calls Held) : l’appel est définitivement perdu.
- LCC (Lost Calls Cleared) : l’appel est rerouté.
- LCD (Lost Calls Delayed) : l’appel est mis en attente. C’est ce qu’il arrive dans les
centres d’appel.
- LCR (Lost Calls Retried) : l’appel est perdu mais il va y avoir un autre essai.
Nombre de sources
Le nombre de sources est également un paramètre important. Par exemple, s’il y a une source
et une ligne, la probabilité de blocage est de zéro. Plus le nombre de sources augmente et plus
la probabilité d’appel bloqué augmente. Le nombre de source rentre en jeu pour dimensionner
un PBX : le but étant d’avoir le minimum de lien mais de toujours avoir le GoS désigné.
Durées d’appel
Quelques modèles prennent en compte la durée des appels.
c) Les modèles
Une fois que nous avons déterminé les 4 paramètres précédents, nous pouvons choisir le
modèle qui correspond le plus à notre environnement. Les modèles les plus utilisés sont :
Erlang B, Erlang B étendu et Erlang C. Toutefois, d’autres modèles sont couramment
utilisés : Engset, Poisson, EART/EARC et Neal-Wilkerson.
Ci-dessous, le tableau de comparaison de ces modèles :

Nombre de
Modèle Type d’arrivée Type de blocage Durée d’appel
Sources
Poisson Infini Aléatoire LCH Variable
Erlang B Infini Aléatoire LCC Variable
Erlang B étendu Infini Aléatoire LCR Variable
Erlang C Infini Aléatoire LCD Variable
Engset Fini Régulière LCC Variable
EART/EARC Infini Par pique LCC Variable
Neal-Wilkerson Infini Par pique LCH Variable
Crommelin Infini Aléatoire LCD Constant
Binomial Fini Aléatoire LCH Variable
Delay Fini Aléatoire LCD Variable
Erlang B
Le modèle de Erlang est celui que nous utiliserons pour tous nos calculs de dimensionnement
de ligne. Même si l’analyse mathématique de cette modélisation peut sembler superflu, les
sommes en jeu sont trop importantes pour ne pas y passer quelques instants.
Equations d’états
Page 49 sur 248

Pour la suite, nous utiliserons N pour le nombre de lignes dans le système et i pour le
nombre d’appels en cours. i est donc égal au nombre de lignes occupées et représente l’état
du système. Quand i  N alors le système est saturé, on parle alors de congestion. Un appel
arrivant, alors que le système est dans l’état i  N , est perdu.
Nous considérons :
- que tous les appels sont indépendants,
- que la probabilité d’un nouvel appel quand le système est à l’état i est  i ,
- que la probabilité de la fin d’un appel quand le système est à l’état i est  i ,
- seulement un événement (début ou fin d’un appel) peut arriver à un moment donné.
Nous obtenons donc un graphe à N  1 états :
0 1 i-1 i n-1
0 1 ... i ... N
µ1 µ2 µi µi+1 µn
0i N i  0,1,2...
Graphe
Graphe d’états
d’états Erlang
Erlang B
B
 i est donc directement lié a l’arrivé de trafic dans le système et  i est lié à la nature de ce
trafic. Il nous faut désormais obtenir la probabilité d’être dans l’état i.
La probabilité d’être dans l’état i au moment t  dt est égale à la somme des probabilités
suivantes :
- La probabilité que le système soit dans l’état i au moment t et qu’aucun appel arrive
ou se termine durant le temps dt.
- La probabilité que le système soit dans l’état i-1 au moment t et qu’un appel arrive
pendant le temps dt.
- La probabilité que le système soit dans l’état i+1 au moment t et qu’un appel se
termine pendant le temps dt.
Nous considération qu’il ne peux y avoir qu’une action durant le temps dt.
Soit x la probabilité que le système soit dans l’état i, alors nous avons :
Page 50 sur 248

i t dt  i t 1  i dt   i dt   i  1t  i 1dt   i  1t i 1dt 

Soit,
i t  dt  i t  i   i i t   i 1 i  1t  i 1 i  1t

dt
i  0 est un état limite avec  0  0 (pas de fin d’appel quand il n’y a pas d’appel…) et
1  0 (l’état -1 n’existe pas) :
0t  dt  0t  0 0t  1 1t

dt
Si dt  0 , nous pouvons écrire les équations sous la forme différentielle :
d 0t
 0 0t  1 1t
dt
d i t
 i   i i t   i 1 i  1t  i 1 i  1t
dt
Etat d’équilibre
Comme expliqué dans les parties précédente, nous utilisons le trafic moyen durant l’heure de
pointe comme donnée pour la modélisation. Etant une valeur moyen, cette valeur ne va pas
varier en fonction du temps. Ainsi, durant l’heure de pointe, la dépendance au temps de la
d i t
probabilité d’état est nulle et  0t
dt
Si nous appliquons cette condition aux deux équations précédentes, nous obtenons :
0 0  1 1
1  1 1  0 0  2 2, etc.

Soit en généralisant :
i   i i  i 1 i  1   i 1 i  1

En substituant les équations obtenues successivement,
1 1   2 2

2 2   3 3, etc.
L’expression générale devient :
Page 51 sur 248

i 1 i  1   i i 
Toutefois, il faut rappeler que cet état d’équilibre n’est qu’un concept et qu’il n’est valable
qu’avec la charge de trafic moyenne de l’heure de pointe.
Probabilité d’état
Nous avons dis que x représentait la probabilité que le système soit dans l’état i. En
pratique, durant l’heure de pointe, cette probabilité correspond à la proportion de temps passé
dans l’état i.
Prenons un cas simple : un système dispose de 5 lignes. Durant l’heure de pointe, la charge de
trafic est la suivante :
5
Lignes occupées
4 t1 t2 t3
Heure de Pointe
Exemple
Exemple
Prenons, l’état 4 par exemple :
4  t1  t 2  t 3  t 4 
 temps passé dans l' état 4
3600 Heure de pointe
Nous pouvons voir d’après le diagramme que :
1  2  3  4  5  1

En généralisant, s’il y a N états possible, nous avons :
 i   1
i 0
Page 52 sur 248

Distribution d’Erlang
Nous supposons que A erlangs sont disponibles pour N téléphones. Durant l’heure de pointe,
le système est en équilibre. De plus, la charge de trafic en erlang (A) est égale à la quantité
d’appel (  ) multiplié par la durée moyenne (s) de ces appels : A  s . De plus le taux de fin
d’appel correspond au nombre d’appel en cours divisé par la durée moyenne de ces appels.
Nous avons donc :
A i
 et  i 
s s
En substituant cela dans l’équation de l’état d’équilibre, nous obtenons :
i i  i  1 A
s s
ii  i  1A avec i  0,1,2...

Donc :
1  A0
2
2  A 0
2
Ai
i  0
i!
AN
N   0
N!
N
Or  i   1 ,
i 0
N
0  A0  ...  A 0  1
N!
Et par conséquent :
Page 53 sur 248

0  1
N
Av

v  0 v!
Ai
i   N N! v
A

v  0 v!
Nous avons donc la probabilité pour que le système soit dans l’état i en fonction de la charge
A et du nombre de lignes N.
Temps de Congestion
Le temps de congestion E est défini comme la probabilité d’être dans l’état de congestion,
c'est-à-dire i  N :
Temps de congestion E  N 
AN
E  N   N N! v  E N  A
A

v 0 v!
Ou bien encore :
AEi 1  A
E i  A  avec E0  A  1
i  AEi 1  A
Appel bloqué
La congestion entraîne des blocages d’appel. Soit B les appels bloqués. Alors :
Nombre d' appel quand le système est dans l' état N

B
Nombre total d' appel durant l' heure de pointe
Dans le cas du modèle de Erlang,
λN 
B N
 λi
i 0
Comme  est constant :
Page 54 sur 248

B
N 
N
 i 
i 0
B  N 
Erlang en pratique
Supposons que nous ayons à redimensionner un lien suite à de trop nombreux blocage
d’appels durant l’heure de pointe. Les équipements nous informe que la charge de trafic
durant l’heure de pointe est de 17 erlangs. Le nouveau lien doit être dimensionné pour obtenir
moins de 1% de blocage.
Si nous regardons la table de Erlang en annexe, pour une charge de 17 erlangs et une GoS de
0,9, il faut 27 lignes.
IV. La compression de la parole

La compression de la parole est le processus consistant à réduire le flux numérique PCM, qui
est normalement de 64 Kbps. De manière idéale, la qualité de la parole ne doit pas être
affectée : cependant, il y a toujours une dégradation qui est plus ou moins apparente aux
utilisateurs. De nombreuses techniques sont utilisées pour compresser la parole, avec des
débits de quelques Kbps à quelques 40 Kbps.
Le flux PCM peut être compressé parce qu’une part importante de ce flux est redondante. On
pense qu’une qualité de parole peut être fournie à des débits allant jusqu’au Kbps. Cela n’est
pas encore réalisé, en grande partie parce que les mécanismes de compréhension de la parole
ne sont pas encore connus. Au fur et à mesure de l’étude de la parole, des techniques de plus
en plus efficaces sont développées pour rendre ce débit aussi faible que possible avec une
qualité acceptable.
1) Différents types de codage

Les mécanismes de compression de la parole peuvent être séparés en trois catégories : codage
de forme, codage de source, codage hybride.
Codage de forme (waveform coding) : les codecs de ce type essaient de reconstruire la forme
du signal de manière aussi proche que le signal d’origine et basés sur des échantillons du
signal d’origine. En théorie, cela signifie que ces codeurs sont indépendants du signal, et
peuvent fonctionner avec des signaux non vocaux, de type modem ou fax par exemple. Ces
codeurs sont relativement simple à mettre en œuvre, et produisent une qualité acceptable
jusqu’à des débits de 16 Kbps. En deçà, la qualité du signal reconstruit se dégrade rapidement.
PCM est un exemple de cette technique. Dans le cas d’une quantification linéaire, au moins
12 bits par échantillon sont nécessaires pour assurer une bonne qualité, ce qui conduit à un
débit de 96 Kbps (8000 échantillons de 12 bits). Cependant, la nature de la parole et de
l’oreille humaine ne suit pas une échelle linéaire. La plupart des signaux vocaux sont de faible
amplitude, et l’oreille humaine n’est pas sensible à l’amplitude absolue d’un son, mais au
logarithme de l’amplitude. La représentation binaire (nombre de bits) est alors plus
Page 55 sur 248

importante pour les signaux de faible amplitude que pour les signaux de forte amplitude. Cela
conduit à un débit de 64 Kbps.
D’autres techniques de ce type existent comme l’ADPCM (Adaptative Differential Pulse

Code Modulation) ou CVSD (Continuously Variable Slope Delta).
Codage de source (source coding) : ces codeurs (appelés également Vocoders) sont
nettement plus complexes que les codeurs de forme, mais peuvent comprimer à des débits
allant jusqu’à 2,4 Kbps. Pour atteindre ces taux de compression, la connaissance du processus
de génération de la parole est requise. Le signal de parole est analysé et un modèle de la
source est généré. Un certain nombre de paramètres sont alors transmis au destinataire qui lui
permettent de reconstruire le modèle, et ainsi de recréer le signal de parole. Ces paramètres
incluent des informations comme le type (voyelles ou consonnes), l’amplitude…
Cependant, si la parole est reconnue, la reconnaissance de la personne parlant est très faible.
De plux, ces méthodes gèrent de manière difficile les signaux de type fax ou modem.
En raison de ces facteurs, ces codeurs ne sont pas utilisés dans des applications commerciales.
Leur utilisation principale est faite dans le domaine militaire, ou les débits faibles sont
privilégiés, avec un encryptage pour des raisons de sécurité.
Codage hybride (hybrid coding) : comme son nom l’indique, cette technique utilise les deux
techniques précédentes, essayant de prendre le meilleur des deux mondes.
Les techniques de ce type font appel à CELP (Code Excited Linear Prediction).
2) Adaptative Differential Pulse Code Modulation (ADPCM)

ADPCM est la technique la plus utilisée aujourd’hui pour la compression de la parole. Elle
offre un débit allant de 16 Kbps à 40 Kbps, avec une bonne qualité. Ses performances sont
bien connues, et parce que des versions propriétaires ont été développées, elle a été
standardisée par l’ITU-T dans un ensemble de recommandations : G.721 qui couvre
l’ADPCM au débit de 32 Kbps, et G.723 pour les débits de 16, 24 et 40 Kbps. Aujourd’hui,
les recommandations G.721 et G.723 ont été combinées et remplacées par la G.726, qui
couvre tous les débits, de 16, 24, 32 et 40 Kbps.
Le mode 32 Kbps fournit une qualité de parole qui ne peut être pratiquement distinguée de
celle fournit par le mode 64 Kbps (PCM). La qualité se dégrade aux débits de 16 et de 24
Kbps.
Les codeurs ADPCM effectuent un codage, non plus du signal direct, mais de la différence
entre le signal de parole et une prédiction de qu’est ce que sera le signal, en faisant
l’hypothèse que des échantillons adjacents sont extrêmement semblables. La valeur d’un
échantillon peut être prédite avec une bonne précision en considérant les valeurs des
échantillons précédents. Par exemple, la prédiction la plus simple consiste à dire que
l’échantillon suivant est le même que l’échantillon courant. Dans ce cas, la technique DPCM
(Differential Pulse Code Modulation) est utilisée, qui est à la base de l’ADPCM. Dans ce cas,
seule la différence entre l’échantillon et le suivant est transmise.
Pour PCM, le signal de parole est échantillonné à des intervalles réguliers, et c’est le niveau
absolu de l’échantillon qui est codé. Avec DPCM, c’est la différence entre l’échantillon
courant et le suivant qui est codée. En faisant cela, un nombre plus faible de bits est
Page 56 sur 248

nécessaire pour le codage du signal. Mais lorsque cette amplitude varie plus fortement que la
technique ne le permet, une distorsion est apportée sur le signal.
C’est pour cette raison qu’ADPCM a été développée, de telle manière que le ratio amplitude /
nombre de bits utilisés pour coder cette amplitude soit toujours optimisé, afin de réduire au
maximum cette distorsion. Pendant les premiers échantillons, la différence entre l’échantillon
courant et le suivant est relativement faible. Cette différence est codée avec l’amplitude
maximale permise par le nombre de bits utilisés pour la quantification, ce qui donne un
certain nombre de bits par échantillon. Par exemple, pour un débit de 32Kbps, cette différence
est codée sur 4 bits, un pour le signe (la différence peut être positive ou négative), et les 3
autres pour quantifier la différence de l’amplitude. Dans le cas où cette différence entre deux
échantillons est plus importante, il y a adaptation, c’est à dire que pour un même nombre de
bits utilisés, l’amplitude sera augmentée.
Comme mentionné précédemment, ADPCM supporte 4 débits différents :
- 40 Kbps : 5 bits utilisés ;
- 16 Kbps : 2 bits utilisés.
3) CELP – Code Excited Linear Prediction

La philosophie du codeur CEPL est d’analyser la parole, et ensuite de transmettre des
paramètres au décodeur afin qu’il puisse reconstituer le signal d’origine aussi fidèlement que
possible. Ces paramètres incluent le modèle mathématique d’un filtre qui simule le conduit
vocal de la personne qui parle (toutes les caractéristiques qui rendent reconnaissable
immédiatement une personne), des informations d’amplitude du signal, et un index de code,
qui pointe sur une séquence d’échantillons de voix pré établis, appelés vecteurs, qui sont
communs à l’émetteur et au récepteur. Le nombre d’entrées dans ce livre de codes et le
nombre d’échantillons pour chaque entrée est dépendant de l’implémentation actuelle de
CELP.
Du côté émetteur, des groupes d’échantillons de parole PCM (vecteurs), typiquement d’une
durée de 20 ms, sont comparés à des vecteurs stockés dans le livre de code. L’index pour le
vecteur qui produit la meilleure comparaison est alors envoyé au récepteur. Du côte récepteur,
la forme du signal est extraite du livre de code et filtrée, en utilisant le modèle mathématique
du conduit vocal de la personne qui parle.
En raison de la complexité de la parole et de l’étendue des différences entre les voix

humaines, la puissance de traitement exigée par CELP est importante, de l’ordre de 15 MIPS
pour un canal de voix. Cependant, CELP est devenue une méthode de compression de la voix
commune, en raison de la qualité de la voix obtenue, et pour des débits faibles entre 4,8 Kbps
et 16 Kbps. Les désavantages de CELP tiennent autour de deux problèmes : d’une part le
délai (entre 50 et 100 ms), à cause du processus de calcul intensif et le nombre d’échantillons
de voix qui sont temporisés pour analyse, ce qui peut amener de l’écho, et d’autre part, CELP
est spécialisé dans le traitement de la voix, et supporte très mal le traitement de données (fax,
modem, ou signaux DTMF).
Page 57 sur 248

4) LD-CELP – Low Delay / Code Excited Linear Prediction

(ITU-T G.728)
LD-CELP est basé sur CELP, et fournit une qualité de parole proche à l’ADPCM 32 Kbps
pour un débit de 16 Kbps. L’avantage est le délai, nettement plus faible que CELP, qui est de
l’ordre de 2 ms.
Du côté codeur, le signal PCM (loi A ou mu) est d’abord converti en PCM linéaire. Ce signal
est alors découpé en blocs de 5 échantillons successifs provenant du signal d’origine.
L’encodeur compare alors chacun des 1024 vecteurs du livre de code avec chacun des blocs
d’entrée. L’index du livre (10 bits) qui correspond le mieux est alors envoyé vers le décodeur.
L’opération de décodage est également effectuée bloc par bloc. Après réception de cet index
sur 10 bits, le décodeur effectue une recherche dans la table pour extraire le vecteur
correspondant dans le livre de code. Le vecteur extrait est alors filtré pour produire le signal
de sortie. Les 5 échantillons sont alors convertis selon la loi mu ou A.
5) CS-ACELP – Conjugate Structure / Algebraic Code Excited

Linear Prediction (ITU-T G.729)
CS-ACELP est une autre technique de compression, basée sur CELP. Elle fut conçue à
l’origine pour le support de la voix en mode paquet sur les réseaux mobiles, bien qu’un autre
processus, RPE-LPT ait été choisi pour le GSM.
CS-ACELP ne fonctionne qu’au débit de 8 Kbps, et apporte une qualité proche de celle
d’ADPCM au débit de 32 Kbps. De plus, les tests ont montré une très bonne résistance à la
perte de paquets.
Le codeur opère sur des trames de parole de 10 ms, correspondant à 80 échantillons

(fréquence d‘échantillonnage de 8000 Hz). Pour chaque trame de 10 ms, le signal de parole
est analysé pour extraire les paramètres de type CELP. Ces paramètres sont alors transmis au
récepteur dans un format de trame spécifié par la recommandation. Du côté récepteur, la
parole est reconstituée en prenant l’entrée dans le livre des 80 échantillons et en la filtrant.
Une description complète est donnée dans la recommandation G.729.
6) Autres techniques de compression

CVSD : Continuously Variable Slope Delta. CVSD a été l’une des premières techniques de
compression utilisée dans les années 80 dans les multiplexeurs TDM. C’est une méthode qui
travaille sur la forme du signal. Cependant, plutôt que de partir du signal PCM, comme c’est
le cas pour de nombreuses autres techniques, CVSD se base sur la nature analogique du
signal. Avec CVSD, le codeur compare la tension du signal d’entrée à une référence de
tension interne. Si le signal est plus grand que la référence, un « 1 » est transmis, et la tension
de référence est augmentée. Dans le cas contraire, c’est un « 0 » qui est transmis, et la tension
de référence est diminuée. A travers ce processus, le récepteur peut reconstituer la tension de
référence de l’émetteur, qui est fidèle au signal analogique en entrée.
Les techniques CVSD ne sont pas standardisées, et sont donc propres à chaque constructeur.
CVSD peut être utilisé pratiquement à n’importe quel débit, parce que le débit est fonction de
la fréquence d’échantillonnage. La qualité subjective de CVSD 32 Kbps n’est pas aussi bonne
qu’en ADPCM 32 Kbps, ce qui a amené à éliminer CVSD. La qualité se dégrade ensuite de
Page 58 sur 248

manière considérable, pour devenir inacceptable à des débits inférieurs à 16 Kbps. CVSD
supporte très mal le transfert de données, le signal DTMF étant non reconnaissable à des
débits inférieurs à 16 Kbps.
DSI : Digital Speech Interpolation. DSI est le terme générique pour des systèmes qui utilisent
les trous dans la parole pour arrêter la transmission d’échantillons, réduisant ainsi le débit sur
le canal de transmission. Il se base sur la probabilité que le facteur d’activité de la parole
(SAF : Speech Activity Factor) pendant une conversation est inférieur à 1. Le SAF est un
pourcentage de temps qu’une personne utilise réellement pour parler, et il est normalement de
0,4 ou de 40%.
Un exemple de l’utilisation de DSI est DCME (Digital Circuit Multiplication Equipment),

défini par la recommandation de l’ITU-T G.763. Si un canal de voix est compressé utilisant
l’ADPCM 32 Kbps, l’application de la technique DSI avec un SAF de 0,5 permet une
réduction de 2 du débit, soit 16 Kbps.
RPE-LTP : Regular Pulse Excitation – Long Terme Prediction. RPE-LTP est la technique
utilisée par le GSM (Global System for Mobile communications), et fonctionne au débit de 13
Kbps. La qualité est acceptable, bien qu’inférieure à celle offerte par LD-CELP ou CS-
ACELP. L’avantage principal est la relative simplicité pour l’implémentation sur des
machines dont le coût doit être faible.
a) Compression de la parole et traitement des données

La recommandation de l’ITU-T G.113 discute des effets des techniques de compression sur
les données transportées sur un canal voix. Trois techniques de compression sont étudiées :
LD-CELP 16 Kbps, ADPCM 32 Kbps et ADPCM 40 Kbps.
Bande
Codec Durée du paquet passante
(kbps)
G.711 (PCM) 64kbps non compressé 10 millisecondes (80 échantillons) 96
G.723.1 (ACELP) 5.3kbps compressé 30 millisecondes (1 échantillon) 16
G.723.1 (ACELP) 5.3kbps compressé 60 millisecondes (2 échantillons) 11
G.723.1 (MP-MLQ) 6.4kbps compressé 30 millisecondes (1 échantillon) 18
G.723.1 (MP-MLQ) 6.4kbps compressé 60 millisecondes (2 échantillons) 12
G.726 (ADPCM) 32kbps compressé 10 millisecondes (80 échantillons) 64
G.728 (LD-CELP) 16kbps compressé 10 millisecondes (16 échantillons) 48
Page 59 sur 248


G.729A (CS-CELP) 8kbps compressé 10 millisecondes (1 échantillons) 40
Les différents tests et recherches effectués pendant mon stage m’ont amenés à l’utilisation de
la technique CS-CELP, appelée également G.729. La bande passante nécessaire est plus faible
que les trois techniques étudiées dans l’ITU-T G.113 (8 kbps, comme le montre le tableau ci-
dessus, contre 16, 32 et 40 kbps), la qualité est bonne et cette technique possède une très
bonne résistance à la perte de paquet.
G.729A (CS-CELP) 8kbps compressé 80 ms

G.728 (LD-CELP) 16kbps compressé 80 ms
G.726 (ADPCM) 32kbps compressé 80 ms
G.723.1 (MP-MLQ) 6.4kbps compressé 90 ms
G.723.1 (ACELP) 5.3kbps compressé 90 ms
G.711 (PCM) 64kbps non compressé 80 ms
La qualité d’un codec est mesurée de façon subjective en laboratoire par une population test
de personnes. Ces dernières écoutent tout un ensemble de conversations compressées selon
les différents codecs à tester et les évaluent qualitativement selon la table suivante :
Qualité de la parole Score
Excellente 5
Bonne 4
Correcte 3
Pauvre 2
Insuffisante 1
Page 60 sur 248

Sur la base des données numériques des appréciations, une opinion moyenne de la qualité
d’écoute (Mean Opinion Score . MOS) est ensuite calculée pour chaque codec. Les résultats
obtenus pour les principaux codecs sont résumés dans le tableau ci-dessous :
Codec Débits (Kbps) Score MOS
G.711 (PCM) 64 4.1
G.726 32 3.85
G.729 8 3.92
G.723.1 6.4 3.9
G.723.1 5.3 3.65
GSM 13 3.5
G.729 * 2 3.27
G.729 * 3 2.68
G.729 * GSM 3.17
Deux observations principales peuvent être tirées du tableau ci-dessus :
- La qualité de la voix obtenue par les codecs G.729 et G.723.1 (à 6.4Kbps) est très
proche de celle du service téléphonique actuel, et ce pour des débits entre 8 et 10 fois
inférieurs. Ces deux codecs présentent une meilleure qualité que celle des réseaux
téléphoniques cellulaires (GSM).
- Le cumul, dans une même communication, d’opérations de

compression/décompression conduit à une rapide dégradation de la qualité.
Les solutions mises en oeuvre doivent éviter des configurations en tandem dans lesquelles un
PBX reçoit un appel d’un poste distant à travers une liaison VoIP et le redirige vers une autre
liaison semblable.
Offrant une qualité de voix très proche, les codecs G.729 et G.723.1 se distinguent
essentiellement par la bande passante qu’ils requièrent et par le retard que chacun introduit
dans la transmission. Le choix d’un équipement implémentant l’un ou l’autre de ces codecs
devra donc être fait selon la situation, en fonction notamment de la bande passante à
disposition et du retard cumulé maximum estimé pour chaque liaison (selon les standards de
l’UIT, le retard aller (« one-way delay ») devrait être inférieur à 150 ms).
Page 61 sur 248

V. Introduction aux protocoles

La VoIP est la convergence des réseaux téléphonique et des réseaux informatiques. Après
avoir étudié la téléphonie classique, il est nécessaire de connaître les différents processus des
réseaux informatiques.
1) Couche réseau pour les protocoles Internet

La figure ci-dessous montre les quatre couches des protocoles Internet.
Contrôle Media Utilitaires
Couches : SDP Media
Application H.323 SIP RTP DNS DHCP
Transport TCP UDP
Internet IP
AALx PPP
Physique
ATM V.90 Ethernet 802.11
Modèle
Modèle OSI
OSI
a) La couche physique
La couche la plus basse est la couche physique. Il peut s’agir d’un réseau local (ou LAN :
Local Area Network), d’une simple ligne téléphonique (V.90 ou modem 56k) utilisant un
protocole Point à Point (ou PPP : Point-to-Point Protocol), d’une ligne numérique (DSL :
Digital Subscriber Line) utilisant un mode de transport asynchrone (ou ATM : Asynchronous
transport mode) ou bien encore d’un réseau sans fil Wifi (802.11). Cette couche s’occupe de
toutes les fonctions d’échanges de données binaires, de synchronisation des trames et
d’interaction avec une interface physique.
Page 62 sur 248

b) La couche Internet
La couche immédiatement supérieure est la couche Internet. Le protocole IP (Internet
Protocol) est utilisé pour transporter un paquet à travers le réseau en utilisant l’adresse IP du
destinataire. Le protocole IP n’utilise pas de connexion pour transférer un paquet mais le
transfert directement. Ainsi un paquet peut être perdu, retardé ou arriver dans le désordre par
rapport aux autres. Un paquet est donc transféré de manière autonome grâce à son en-tête,
ajouté dans la couche physique. A ce niveau, un paquet n’a aucun sens.
Tous les exemples que nous utiliserons utilisent l’ancienne version du protocole IP, la version
4 (IPv4).
IPv4
Une adresse IP est composée de 4 octets. On l’écrit généralement avec 4 chiffres compris
entre 0 et 255 ; séparés par des points (par exemple, 192.168.6.4). Au niveau de la couche IP,
une somme de contrôle (checksum) est rajoutée dans l’en-tête IP. Elle permet de détecter la
corruption d’un en-tête IP et d’éviter ainsi qu’un paquet soit mal redirigé. Par contre, des
corruptions ou des erreurs en dehors de l’en-tête ne sont pas détectées ; une couche supérieure
est nécessaire pour faire cela. IP utilise un octet pour indiquer le numéro du protocole utilisé
pour le transport.
IPv6
L’IP version 6 a été développé par l’IETF pour remplacer l’IPv4. Il est désormais supporté
par un grand nombre de système d’exploitation. Avec un adressage de 128 bits (contre 32 bits
pour l’IPv4) cela permet d’avoir plus de 4 milliards d’adresse IP, afin de répondre aux
nouvelles demandes, en particulier dans le domaine de la téléphonie. Mais l’IPv6 apporte
également plus de sécurité. Contrairement à l’IPv4, une adresse IPv6 est représentée par une
séquence de 8 octets séparés par deux points. Les adresses IPv4 sont compatibles en rajoutant
une séquence de quatre zéros ; par exemple 0:0:0:0:aa:bb:cc:dd. La même adresse peut être
écrite comme cela :::aa:bb:cc:dd.
Les adresses IP utilisés sur le réseau public Internet sont assignées en bloc par l’IANA
(Internet Assigned Number Association) ; cela afin que chaque adresse soit unique. Ainsi, une
destination indiquée par une adresse IP est unique.
c) La couche transport
La couche suivante est la couche de transport. Elle utilise un numéro de port codé sur deux
octets pour transférer les données vers la bonne application. Certains ports sont dédiés à des
protocoles particuliers. Par exemple, le HTTP utilise le port 80. Ces ports sont appelés
« connus ». Ainsi le SIP, que nous verrons plus tard, utilise les ports connus 5060 ou 5061.
D’autres ports peuvent être assigné à un protocole de manière dynamique.
Les trois protocoles communs pour le transport sont : TCP (Transmission Control Protocol),
TLS (Transmission Layer Security) et UDP (User Datagram Protocol).
Page 63 sur 248

TCP
Le TCP est un protocole fiable orienté connexion. Le TCP utilise une séquence de nombre et
un système d’accusé de réception pour être sûr que chaque bloc de données, appelé segment,
soit correctement acheminé.
Le schéma suivant montre l’échange de messages pour établir et tenir une communication
TCP. Un serveur TCP « écoute » sur un port connu une requête TCP. Le client TCP envoi un
message SYN (synchronisation) pour ouvrir la connexion. Le message SYN contient le
premier chiffre de la séquence qui va être utilisé pendant la connexion. Le serveur répond
avec un message SYN contenant son propre premier chiffre de séquence et un numéro
d’accusé de réception ACK (acknowledge) pour signaler qu’il a bien reçu le message SYN.
Le client termine cette initialisation par un message ACK ou un paquet de données (DATA)
pour valider le numéro de séquence du serveur. Maintenant que la connexion est ouverte, le
client ou le serveur peuvent envoyer des paquets DATA, aussi appelé segment.
Client TCP Serveur TCP
SYN
SYN/AK
ACK
DATA
...
FIN
ACK
FIN
ACK
Communication
Communication TCP
TCP
Chaque fois qu’un paquet est envoyé, l’expéditeur démarre un minuteur. Si un paquet est
perdu, le minuteur expire et l’expéditeur retransmet le paquet jusqu’à ce qu’il reçoive un
accusé de réception. Le message FIN termine la connexion comme le montre la séquence des
quatre derniers messages de la figure précédente. Les ports dynamiques utilisés pour cette
communication sont libérés pour d’autres usages. L’en-tête d’un paquet TCP contient 24
Page 64 sur 248

octets. Les segments erronés sont détectés par une somme de contrôle qui couvre à la fois
l’en-tête et les données.
UDP
L’UDP est un protocole de transport sur Internet non fiable. L’UDP ne possède rien de la
complexité du TCP : il n’y a ni accusé de réception, ni numéros de séquence.
TLS
Le TLS est basé sur le protocole SSL (Secure Sockets Layer) qui était initialement utilisé par
les explorateurs Web. Il est désormais couramment utilisé sur Internet pour les sites Web
sécurisés.
Le protocole TLS possède deux niveaux : le protocole de transport et le protocole

d’initialisation. Le protocole de transport TLS permet un transport fiable et sécurisé des
données. Les données envoyées avec le protocole TLS sont cryptées et une personne tierce ne
peut pas les intercepter. Le protocole de d’initialisation TLS est utilisé pour établir une
connexion et négocier une clé de cryptage qui sera utilisé par le protocole de transport.
Client Serveur SIP
ClientHello
ServerHello
Finished
Finished
Données
Communication
Communication TLS
TLS simple
simple
Le système de cryptographie utilisé n’est pas simple et le grand nombre d’opérations

nécessaire pour ouvrir une connexion peut rajouter un temps de latence aux messages. Le
protocole TLS a de nombreux avantages au niveau de la sécurité par rapport à l’UDP ou au
TCP.
SCTP
Le protocole SCTP (Stream Control Transport Protocol) est similaire au TCP car il permet le
transfert d’un flux de données de manière fiable. Toutefois, il apporte quelques avantages.
Tout d’abord, il ne concatène pas les données à l'émission, les messages sont donc reçus tels
Page 65 sur 248

qu'ils sont émis. De plus, il gère plusieurs connections simultanées par association et le
multihoming. Cela signifie que si le destinataire est introuvable, il peut être automatiquement
remplacé.
L'unité de transport est un datagramme, chacun comporte un ou plusieurs chunks (morceaux).

Le contrôle d'erreur se fait par datagramme. Chaque chunk comporte un en-tête spécifique qui
supporte le contrôle de flux, les acquittements.
Le SCTP est un protocole de transport de niveau 2. Cela signifie qu’il nécessite un système
d’exploitation, ce qui ralenti considérable les communication. De plus, les avantages du SCTP
sur le TCP n’interviennent que pendant une perte de paquets. Sur un réseau fiable, sans perte
de paquets, les performances des deux protocoles sont identiques.
d) La couche application
La couche la plus haute est la couche application. Cela inclut les protocoles de signalisation
comme le SIP ou les protocoles de transfert de données multimédias comme le RTP (Real-
time Transport Protocol). Il est important de citer le protocole H.323 qui est le principal
concurrent du SIP, mais également le protocole SDP (Session Description Protocol) car il est
transporté dans le corps même des messages SIP. Les protocoles HTTP, FTP, SMTP, Telnet
font également partie des protocoles de la couche application.
Page 66 sur 248

VI. SIGNALISATION POUR LA VOIP

La signalisation concerne l’échange d’informations entre les noeuds d’un réseau. Ces
informations servent à l’établissement et au contrôle des connexions à travers le réseau.
L’utilité de la signalisation repose bien sûr sur le principe de l’établissement des connexions,
mais elle permet également le transfert d’informations concernant la gestion du réseau et de
ses ressources, entre autre. Pourquoi faut-il une signalisation standardisée pour la VoIP ?
Pour répondre à cette question, il faut revenir avant 1996, date où le protocole H.323 est
apparu. Les solutions de voix sur IP reposaient alors sur des architectures propriétaires. Ces
solutions bien que fonctionnelles présentaient des défauts parmi lesquels le manque
d'interopérabilité des équipements, l'impossibilité de raccordement au réseau public (seuls les
ordinateurs pouvaient communiquer entre eux) ainsi que l'absence d'architecture généralisée
pour la connexion de n'importe quel type de terminal. Chaque architecture était définie pour
deux équipements d'extrémité spécifiques et ne pouvait pas opérer avec d'autres équipements.
C’est pourquoi de nombreuses organisations ont alors pris part à l'élaboration d'un standard
suffisamment général pour décrire toutes les possibilités de service de voix sur IP. Ils se sont
regroupés au sein d'un groupe de travail de l'UIT.
Ci-dessous une liste des principaux organismes de normalisation pour les différents standards
de la VoIP :
- UIT-T (Union Internationale des Télécommunications, secteur Télécoms)
- IETF (Internet Engineering Task Force)
- IMTC (International Multimedia Teleconferencing Consortium)
- ECTF (Enterprise Computer Telephony Forum)
- ETSI (European Telecommunication Standards Institute)
- International Teleconferencing Association
- International Multimedia Association
Dans les deux sous-sections suivantes seront présentés les deux standards les plus utilisés : le
H323 et le SIP. Ils ont chacun leurs avantages et leurs inconvénients.
Toutefois, il ne faut pas oublier les protocoles que sont Megaco/MGCP (Media Gateway
Control Protocol), SS7 (Signaling System n°7), IPTEL (IP Telephony), SIGTRANS
(Signaling Transport),…
1) Signalisation H.323
a) Introduction
C'est aujourd'hui la norme la plus utilisée pour faire passer la voix et la vidéo sur IP ou sur
d'autres réseaux ne garantissant pas une QoS optimale pour l'établissement d'une
Page 67 sur 248

communication multimédia. Cette norme a été mise en place par l'UIT en 1996, elle est
reconnue et adoptée par de nombreux fabricants tel que Cisco, IBM, Intel, Microsoft, etc. Ce
standard concerne le contrôle des appels, la gestion du multimédia, la gestion de la bande
passante, la connectique pour les conférences point-à-point ou multipoints, etc. Il faut
remarquer que la norme H.323 a subie plusieurs modifications depuis sa création.
Actuellement la norme H.323 est à sa quatrième version.
b) Principe du protocole H.323

La norme H.323 définit plusieurs éléments de réseaux : les terminaux, les gardes-barrières
(gatekeepers), les passerelles (Gateways H.323 vers H.320/H.324/téléphones classiques) et les
contrôleurs multipoints (MCUs - MC, Multipoint Controller, MP - Multipoint Processor). Les
terminaux de type H.323 peuvent être intégrés dans des ordinateurs personnels ou implantés
dans des équipements autonomes tels que des vidéophones. La prise en charge de la parole est
obligatoire, tandis que celle des données et de la vidéo est facultative.
Les terminaux
Il existe deux types de terminaux H.323, l'un de haute qualité (pour une utilisation sur LAN),
l'autre optimisée pour les bandes passantes faibles (28.8/33.6 kbit/s - G.723.1 et H.263). Les
terminaux sont capables de gérer des conférences à plusieurs et le multicast, permettant à 3 ou
4 personnes de dialoguer directement, sans tiers centralisateur. Ils doivent prendre en charge
au minimum le codec G.711.
Les terminaux peuvent prendre différentes formes :
- micro ordinateur.
- terminal spécialisé pour la visioconférence.
Ils utilisent deux protocoles :
- le protocole H.245 : pour la négociation de l'ouverture d'un canal, et pour

l'établissement des paramètres de la communication.
- le protocole Q.931 de signalisation : pour l'établissement et l'arrêt d'une

communication.
Les passerelles (gateway)

Les passerelles en téléphonie IP sont des équipements qui fournissent un lien entre les réseaux
téléphoniques commutés (RTC) et les réseaux basés sur la commutation de paquets TCP/IP.
C’est une partie essentielle de l’architecture du réseau de téléphonie IP.
Les passerelles H.323 assurent la correspondance de signalisation de Q.931 vers H.225.0, la

correspondance des signaux de contrôle et la cohésion entre les médias (multiplexage,
correspondance des débits, transcodage audio, conversion T.123).
La passerelle est un élément optionnel pour de la conférence H.323. Les passerelles

fournissent certains de services comme la translation entre un point final H.323 et un autre
type de terminal. Une passerelle permet donc aux terminaux H323 d’opérer en
environnements hétérogènes :
Page 68 sur 248

Téléphonie classique
Telephone
Analogique
PBX PSTN
Passerelle H323
H323 Traduction Téléphonie Classique
Terminaux H323
Passerelle
Passerelle H323
H323
Les principales caractéristiques d’une passerelle sur IP sont les suivantes :
- Garde-barrières intégré : sécurisation de l'intranet, prise en compte des problématiques

d'accès différentes pour la voix et les données.
- Router les appels à l'intérieur de la zone H.323
- Compression de la voix et reconnaissance de fax.
- Suppression des silences et annulation d'écho.
- Modularité.
- Conversion (facultatif) entre les formats de transmission audio, vidéo et de données et

entre les procédures de communication.
- Etablissement et libération des communications du côté réseau et du côté réseau à

commutation de circuits (RTC).
Page 69 sur 248

- Informer (en général) de façon transparente un point d’extrémité du réseau SCN des
caractéristiques d'un point d'extrémité du réseau, et vice versa.
Les gardes-barrières (gatekeeper)

Vue d’ensemble des gardes-barrières
Un gatekeeper agit comme le gérant de tout appel H323 dans la partie du LAN qu’il occupe.
Il fournit deux services principaux :
- la gestion des permissions,
- la résolution d’adresses.
Le gatekeeper est aussi responsable de la sécurité. Quand un client H323 veut émettre un
appel, il doit le faire au travers du gatekeeper. C’est alors que celui-ci fournit une résolution
d’adresse du client de destination.
Dans le cas où il y aurait plusieurs gateways sur le réseau, il peut rediriger l’appel vers un
autre couple gateway/gatekeeper qui essaiera à son tour de router l’appel.
Pendant la résolution d’adresse, le gatekeeper peut aussi attribuer une certaine quantité de
bande passante pour l’appel et sélectionne les codecs à utiliser. Il peut agir comme un
administrateur de la bande passante disponible sur le réseau.
Le gatekeeper, de par ses fonctionnalités de routage et de sécurité, doit gérer ces gateways
pour faire en sorte que tout appel atteigne sa destination avec la meilleure qualité de service
possible.
Ainsi, le gatekeeper peut remplacer le classique PABX. Il est capable de router les appels
entrant et de les rediriger vers leur destination ou une autre passerelle. Mais, il peut gérer bien
d’autres fonctions telles que la conférence ou le double appel. Il n’existe pas les mêmes
contraintes avec un gatekeeper qu’avec un PABX.
En effet, ce premier est administré de façon logicielle et l’opérateur peut implémenter autant
de services qu’il le désire. Alors qu’avec un PABX, l’évolutivité est limitée par le matériel
propriétaire de chaque constructeur.
L'ensemble des terminaux, des passerelles et des Contrôleurs Multipoint dirigé par un seul
garde-barrières constitue une Zone H.323 :
Page 70 sur 248

Garde-
barrières
LAN LAN
Terminal Passerelle
H323
Routeur Routeur
Zone H323
Zone H323
Différents niveaux de garde-barrières

Il existe plusieurs niveaux de garde-barrières. En effet, certains gardes-barrières ne gèrent que
l’établissement d’appel entre les clients ce qui n’est pas suffisant dans la plupart des cas. C’est
pourquoi il faut considérer qu’un garde-barrières n’est jamais dans un état finalisé mais
toujours dans un état stable : on peut toujours ajouter de nouveaux services à un garde-
barrières. Pour mieux comprendre les différents niveaux de garde-barrières, nous pouvons en
considérer de 3 sortes :
Le garde-barrières basique :
Le garde-barrières basique est le plus simple qui puisse être trouvé sur le marché. Il ne gérera
que la connexion entre deux clients. Il aura les fonctions basiques qui lui permettront de faire
la signalisation à bas niveau pour l’établissement d’appel. Il ne permettra pas par contre de
gérer le double appel ou la conférence comme un PABX. Il n’aura pas non plus de fonctions
complexes telles que les annuaires distribués.
Le garde-barrières avancé :
Le marché des gardes-barrières basiques est si fermé que les entreprises portent leurs intérêts
dans le développement d’applications plus complexes. Ces entreprises développent des
applications au dessus de la « pile H323 » (garde-barrières basique) décrite ci-dessus. Le but
est de remplacer le PABX classique par une simple passerelle qui fournira toutes ses
fonctionnalités et l’interconnexion entre les flux de voix et de données. La passerelle n’a
aucune intelligence. Elle ne fournit que de bon DSP et des contrôleurs pour assurer la
connexion entre les ordinateurs et les téléphones ainsi que l’encodage et le décodage de la
voix. C’est le garde-barrières qui va contrôler tout le système et c’est à ce niveau que doivent
être implémentée toutes les fonctionnalités d’un PABX.
Page 71 sur 248

Le garde-barrières opérateur ou réseau intelligent :
Il n’y a pas que les entreprises qui veulent effectuer la convergence voix/données dans leur
réseau et qui sont intéressées par la téléphonie IP. En effet, les opérateurs télécoms désireux
de réduire le coût de leurs communications longues distances peuvent tirer profit de la
téléphonie IP. Mais bien qu’il soit relativement aisé de transporter de la voix sur IP, il reste un
problème pour le marché des opérateurs. En effet, en téléphonie classique ou en Numéris, les
opérateurs fournissent des services supplémentaires à leurs clients qu’il va falloir retrouver
avec la téléphonie IP. Ils utilisent en particulier la signalisation SS7 pour les réseaux
intelligents. Le but est de rendre le passage du RTC à la téléphonie IP transparent à
l’utilisateur.
L’unité de contrôle multipoint

L’unité de contrôle multipoint (MCU : Multipoint Control Unit) assiste les conférences entre
trois points terminaux ou plus. Dans H.323, un MCU est constitué d'un contrôleur multipoints
(MC : Multipoint Controller), qui est requis, et de zéro ou plus processeurs multipoints (MP :
Multipoint Processor).
Le contrôleur multipoint
Le MC permet de négocier avec tous les terminaux les moyens à mettre en œuvre pour
parvenir à établir des communications de même niveau. Il peut également exercer un contrôle
au niveau des ressources de la conférence pour déterminer par exemple l'entité qui transmet
en mode multi-diffusion (multicast) les signaux vidéos.
Le contrôleur multipoint n'assure pas le mélange ou la commutation des signaux audio, vidéo
et de données. Le traitement direct des flux des médias est laissé aux MP, qui mixent,
commutent, et élaborent l'audio, la vidéo et/ou les données.
Le processeur multipoints
Il reçoit les flux audio, vidéo et/ou de données, traite ces flux et les renvoie aux points
d’extrémité participant à une conférence multipoints (centralisée ou hybride).
Il faut remarquer que les communications entre le contrôleur multipoints et le processeur

multipoint ne sont pas normalisées.
Le rôle des MP est le suivant :
- Commutation vidéo : sélection de l'image à émettre vers les terminaux, selon la

détection automatique ou selon la commande H.245.
- Mélange vidéo : formater plusieurs sources vidéo dans le flux vidéo qui est émis vers
les terminaux.
- Préparer plusieurs sorties audio à partir d'autres entrées audio (commutation, mélange,
combinaison de ces 2 procédés).
- Combiner linéairement les signaux.
- Recoder le résultat dans le flux audio.
Page 72 sur 248

Les ponts de conférence

C'est un point d’extrémité qui permet la mise en œuvre de conférences multipoints. Il est
constitué d'un contrôleur multipoints et éventuellement d'un ou plusieurs processeurs
multipoints.
Pour une conférence multipoint centralisée, le pont de conférence doit être constitué de:
- Un contrôleur multipoint.
- Un processeur multipoint de signaux audio, vidéo et de données.
Pour une conférence multipoint décentralisée, le pont de conférence doit être constitué de :
- Un contrôleur multipoint.
- Un processeur multipoint de données conforme à la Recommandation T.120.
- Le traitement audio et vidéo est alors décentralisé.
La conférence multipoint peut être géré par plusieurs ponts de conférence, cette technique est
appelée ponts de conférence en cascade.
c) Les protocoles de la norme H323

Ci-dessous, la présentation des différents protocoles de la norme H.323 représenté suivant la
structure OSI :
Page 73 sur 248

Couches :
Audio Vidéo Données

Application
G.711 G.728 G.723 H.261 T.127
G.722 G.729 H.263

T.126
Transport T.124
RTCP RTP RAS

T.125 /
T.122
Services
H.235 H.450.3 H.450.2 X.224.0
H.450.1
Contrôle
H.245 H.225
UDP TCP
OSI H323
Modèle OSI
Modèle H323
- RAS (Registration/Admission/Status) : le protocole qui est utilisé entre le terminal ou

la passerelle H.323 et le garde-passerelle. RAS est utilisé pour l’enregistrement, le
contrôle d’admission et la gestion de la bande passante. RAS est le premier canal de
signalisation qui est ouvert entre la passerelle (ou bien le terminal) et le garde-
passerelle.
- H.225 : la signalisation d’appel est utilisée pour une connexion entre deux points de
terminaison H.323. Le canal est ouvert soit entre deux points de terminaison H.323 ou
entre un point de terminaison et un garde-passerelle. Les messages H.225 voyagent sur
TCP.
- H.255.0 : la transmission par paquets et la synchronisation. Signalisation d'appel,

empaquetage, enregistrement au garde-barrière
- H.245 : le contrôle. de l'ouverture et de la fermeture des canaux pour les médias ainsi
que la négociation des formats (codecs)
- H.261 et H.263 : les codecs (Codeur-Décodeur) vidéo
Page 74 sur 248

- G.711, G.722, G.723, G.728 et G.729 : les codecs audio. Ce sont des normes
d'encodage audio, la différence de ces différents codecs est le débit qui en découle
(Voir parties précédentes)
- RTP / RTCP : Real Time Protocol / Real Time Control Protocol. Fonctions de
transport de bout en bout pour les applications temps réel sur des services de réseau
multicast ou unicast. Les applications sont donc aptes à faire des conférences audio /
vidéo interactive ou encore de la simple diffusion de vidéo et d'audio.
- RSVP (Ressource Reservation Protocol) : l’idée « simple » de RSVP est de réserver,

pour un flux de données particulier, une partie de la bande passante du réseau, de
manière à pouvoir assurer une QoS (Quality of Service) à ce trafic. Le processus
consiste à utiliser un descripteur de flux pour requérir cette bande passante. Lors du
transfert de l’information utile, des ressources nécessaires à ce trafic sont alors
données à ce trafic, afin de garantir un certain niveau de performance.
- T.120 : recommandation pour le contrôle des données et des conférences. La série des
recommandations T.120 est utilisée pour les applications données de l'utilisateur, c'est
une série de protocoles de communications multimédias.
d) Une communication H.323 simple

Ci-dessous, le schéma simplifié de l’établissement d’une communication à l’aide de la norme
H.323 :
Pierre Fred
SETUP
Q.931
ALERTING (TCP)
CONNECT
Communication H.245
Adresses RTCP & RTP H.245

(TCP)
Adresses RTCP & RTP
Communication RTP Données

Communication RTCP (UDP)
Communication
Communication H323
H323
Page 75 sur 248

On peut se rendre compte de la complexité d’un appel avec le protocole H.323. On se rend
compte surtout qu’un établissement d’appel se compose de différentes parties qui sont :
- Parties verte : phase d’établissement de la couche transport par TCP et avertissement

au récepteur qu’un appel débute.
- Partie orange : phase d’échange des numéros de canaux logiques utilisables et

échangent des caractéristiques afin de déterminer les codecs qui pourront être utilisés.
Dans cette phase, il y a une multitude d’aller-retour pour établir la connexion H.245.
- Partie rose : phase de communication (le transport ce fait avec le protocole UDP
comme pour le protocole SIP).
e) Une Communication H323 avec gatekeeper

Dans cet exemple, Pierre essaye d’appeler Fred en utilisant un gatekeeper.
Page 76 sur 248

Pierre Gatekeeper Fred
Demande
d’admission
Confirmation RAS
d’admission
Q.931
SETUP
H.245
Lancement de l’appel
Demande
d’admission RTP
Confirmation
d’admission
ALERTING
CONNECT
Configuration capacités
Validation des capacités
Ouverture d’un canal logique
Validation de l’ouverture
Re-Validation de l’ouverture
Communication RTP
Communication
Communication H323
H323 avec
avec garde-barrières
garde-barrières
De même que pour un appel point à point, l’établissement d’appel se fait à 3 niveaux
différents. Fred commence par établir une connexion TCP sur le port classique pour H323
(1720). Pierre et Fred s’envoient alors des paquets Q931 sur cette connexion.
Durant cet échange, Pierre et Fred envoient aussi un numéro de port temporaire et supérieur à
1024 qui servira pour les échanges H245. Si l’on respecte le standard, dès que la connexion
H245 est établie, la connexion Q931 s’achève sans envoi de message particulier et sans
affecter le reste de la connexion H323. En pratique, la connexion Q931 est simplement laissée
de coté.
La connexion H245 est établie par l’appelant sur le port temporaire négocié lors de la
connexion Q931. H245 transmet tous les paramètres à utiliser lors de l’appel et négocie donc
Page 77 sur 248

l’usage de tels ou tels codecs par exemple. H245 permet aussi d’établir la connexion UDP qui
servira à la transmission de la voix (et de la vidéo).
En fait, une fois que les codecs et les autres paramètres de l’appel ont été négociés, la session
H245 exécute une séquence d’opérations visant à ouvrir un canal de transmission en UDP
(Open Logical Channel). Cette séquence permet de déterminer les adresses RTP et RTCP de
l’envoyeur et du receveur ainsi que le port sur lequel se fera la transmission du flux de
données (audio ou vidéo). On notera qu’avec H323, chaque canal logique est considéré
comme une voie.
C’est à dire, que pour que deux personnes échangent de la parole, il faut ouvrir 2 canaux
logiques : l’un pour aller de Pierre vers Fred et l’autre pour aller de Fred vers Pierre. Aussi, le
protocole RTP requière 2 connections UDP adjacentes. L’une des connexions est utilisée pour
RTP (transport du flux de données), l’autre pour RTCP (contrôle des données) et qui est
bidirectionnelle. Les ports utilisés par RTP et RTCP doivent être deux ports distincts, on
choisit souvent n+1 comme port RTCP si le port RTP est n.
La communication se termine ainsi :
Pierre Gatekeeper Fred
Communication RTP
RAS
Fermeture du canal logique
Q.931
Validation de fermeture
H.245
Fin de l’appel
Demande Demande RTP

de désengagement de désengagement
Confirmation Confirmation
de désengagement de désengagement
Communication
Communication H323
H323 avec
avec garde-barrières
garde-barrières
f) Conclusion
Comme nous pouvons le voir, l’établissement d’un appel n’a rien de trivial si l’on n'est pas
familier avec les bases de la téléphonie classique. Mais ce type de protocoles assure une
grande efficacité et une bonne qualité de service puisqu’ils utilisent les principes de la
téléphonie classique. Ceci est une révolution dans le monde de l’informatique. Le problème
est que cela complexifie le développement d’une plate-forme de téléphonie IP.
Page 78 sur 248

L'origine Télécom de H.323 fait que son adaptation aux réseaux IP est lourde et complexe, ce
qui est rend incompatible avec la simplicité du monde IP. C'est pourquoi, des recherches ont
été effectuées sur des normes de signalisation mieux adaptées à la philosophie IP. Ces
recherches ont abouties au SIP.
2) Signalisation SIP
a) Introduction
Le protocole SIP (Session Initiation Protocol) a été développé par l’IETF (Internet
Engineering Task Force) avec comme objectif de s’intégrer aux autres protocoles Internet
comme le TCP (Transmission Control Protocol), le TLS (Transmission Layer Security),
l’UDP (User Datagram Protocol), l’IP (Internet Protocol), le DNS (Domain Name System),
etc.
Comme son nom l’indique ce protocole permet d’établir une communication multimédia entre
deux points. Les principales fonctions de ce protocole sont de :
- Trouver le destinataire
- Contacter le destinataire pour déterminer s’il accepte la session
- Echanger des informations pour pouvoir établir une session
- Modifier une session
- Terminer une session
Le SIP permet également de transmettre un message instantané ainsi que des informations de
présence (en ligne/absent) ou d’autres informations d’état prédéfinies : occupé(e), parti(e)
manger, en ligne…
Même si nous utilisons le SIP dans le cadre de la téléphonie, il permet d’établir une session de
communication dans bien d’autres contextes ; dont certains n’ont aucune ressemblance avec
un appel téléphonique.
L’IETF
L'Internet Engineering Task Force est un groupe informel et auto-organisé dont les membres
contribuent à l'ingénierie et à l'évolution des technologies de l'Internet. C'est la principale
structure engagée dans le développement des spécifications pour les nouveaux standards de
l'Internet. L'IETF est atypique dans la mesure où elle est constituée d'une série d'événements,
sans cadre statutaire ni conseil d'administration, sans membres ni adhésion.
Elle a pour but de :
- Identifier les problèmes urgents opérationnels et techniques liés à l'Internet et proposer

des solutions;
- Spécifier le développement ou l'usage des protocoles et définir les architectures les

mieux adaptées à court terme pour résoudre ces problèmes;
Page 79 sur 248

- Faire des recommandations à l'IESG (Internet Engineering Steering Group) sur la
standardisation et l'usage des protocoles appliqués à l'Internet;
- Faciliter le transfert technologique entre l'IRTF (Internet Research Task Force) et la

communauté de l'Internet en général;
- Favoriser l'échange d'informations entre tous les acteurs de l'Internet : fournisseurs de

matériel, utilisateurs, chercheurs, opérateurs de réseaux et fournisseurs de services.
L’IETF utilise principalement deux types de documents : les I-Ds (Internet-Drafts) qui sont
les documents de travail et les RFC (Request for Comments). Tous ces documents sont
disponibles gratuitement sur le site Web de l’IETF : http://www.ietf.org
Histoire du SIP
Le SIP a été développé par un groupe de travail de l’IETF appelé « Multi-Party Multimedia
Session Control Working Group » ou MMUSIC. La version 1.0 a été proposée sous la forme
d’un I-D en 1997. Rapidement des changements significatifs ont eu lieu et l’I-D de la version
2.0 a été proposé en 1998. En avril 1999, il fut proposé comme standard et publié dans le RFC
2543.
En septembre de la même année, un groupe de travail « SIP » a été créé au sein de l’IETF
suite à l’intérêt grandissant autour de ce protocole. Un I-D contenant des corrections de
bogues et des clarifications fut proposé en juillet 2000 avec la référence RFC 2543 bis. Il a
aussi été publié comme RFC 3261.
La popularité du SIP a nécessité de diviser le groupe de travail de l’IETF. Ainsi est né le

SIPPING (Session Initiation Protocol Investigation) qui travail sur les applications du
protocole et les extensions nécessaires. Le groupe SIMPLE (SIP for Instant Messaging and
Presence Leveraging) travail sur la standardisation des applications de messagerie instantané.
Le groupe SPIRITS (Service in the PSTN/IN Requesting Internet Services) travaille sur les
interactions entre les différents réseaux.
Pour passer du cadre théorique à une véritable application pratique, un standard doit avoir
différentes implémentations et une réelle expérience opérationnelle. Dès le début du RFC
2543, la promotion du SIP a été faite par le SIPit (SIP interoperability test :
http://www.sipforum.org).
Le SIP peux être considéré comme un mélange des deux protocoles les plus utilisés sur
Internet : le HTTP (Hyper Text Transport Protocol) utilisé pour affiché une page Web et le
SMTP (Simple Mail Transport Protocol) utilisé pour le transport des e-mails. Du HTTP, le
SIP a récupéré une architecture client-serveur et l’utilisation d’URLs (Uniform Resource
Locator) et d’URIs (Uniform Resource Identifier). Du SMTP, la SIP a hérité l’encodage du
texte et les en-têtes. En effet, le SIP réutilise les en-têtes du SMTP comme To, From, Date,
Subject. Pour comprendre le SIP, il est important de comprendre comment il interagit avec les
protocoles Internet IP, TCP, UDP et DNS.
b) En pratique
Afin de mieux comprendre le protocole SIP, nous l’avons étudié en théorie mais également en
laboratoire afin de voir les différentes interactions.
Page 80 sur 248

Pour cela, nous avons monté une plateforme de test, composé d’un serveur Syslog qui permet
de récupérer en temps réel les logs, d’un registrar SIP et de deux téléphones. Chaque
téléphone étant utilisé par un utilisateur (Pierre et Fred) :
Registrar SIP
Serveur
SysLog
LAN
Téléphone IP Téléphone IP
Pierre Fred
Plateforme
Plateforme de
de test
test
Chaque périphérique possède son adresse IP :

Périphérique Type Adresse IP / Masque réseau
Téléphone IP de Pierre Snom 105 192.168.6.50 / 255.255.255.0
Téléphone IP de Fred Microsoft Messenger 4.7 192.168.6.41 / 255.255.255.0
Registrar SIP Ingate 1200 192.168.6.74 / 255.255.255.0
Serveur Syslog Kiwi SysLog Server -
Tous les messages de communication SIP que nous montrerons utilisent le RFC 3261.
c) Une communication SIP simple
Message INVITE
La figure suivante montre l’établissement d’une communication entre les deux téléphones
SIP :
Page 81 sur 248

Pierre Fred
INVITE
100 Trying
180 Ringing
200 OK
ACK
Communication RTP
BYE
200 OK
Communication
Communication SIP
SIP
L’initiateur de l’appel, Fred, commence par envoyer un message SIP d’invitation (INVITE) à
Pierre. Le message INVITE contient les informations nécessaires pour la communication.
Cette communication peux être une session vocale (voix) ou multimédia.
Le message INVITE est du type :

INVITE sip:pierre@192.168.6.50:5060;line=b5zaw7ti SIP/2.0
Via: SIP/2.0/UDP 192.168.6.74:5060;branch=z9hG4bK9c3396199601d5ffcfa7ac712a378954.0
Record-Route: <sip:11faa968@192.168.6.74;lr>
Via: SIP/2.0/TCP 192.168.6.41:16685
From: "fred" <sip:fred@192.168.6.74>;tag=f06d2431-4577-4f1f-8d96-c59b801a18ed
To: <sip:pierre@192.168.6.74>
Call-ID: 26120c57-fc20-4fa7-b500-53ed9539ae31@192.168.6.41
User-Agent: Windows RTC/1.0
Content-Type: application/sdp
Content-Length: 452
v=0
o=portfred 0 0 IN IP4 192.168.6.41
s=session
c=IN IP4 192.168.6.41
b=CT:1000
t=0 0
m=audio 7382 RTP/AVP 97 111 112 6 0 8 4 5 3 101
a=rtpmap:97 red/8000
a=rtpmap:111 SIREN/16000
Page 82 sur 248

a=fmtp:111 bitrate=16000
a=rtpmap:112 G7221/16000
a=rtpmap:6 DVI4/16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:4 G723/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
Le SIP est basé sur des messages en texte. Il est donc très facilement compréhensible et
déchiffrable. Les champs contenus dans le message INVITE sont appelés champs d’entête.
Chaque champ contient un nom et une valeur séparés par deux points. Chaque ligne se
termine par un retour à la ligne (ou CRLF : Carriage Return + Line Feed).
La première ligne du message, appelé ligne de départ, liste les éléments suivants :
- la méthode : INVITE,
- l’URI du destinataire : sip:Pierre@192.168.6.50:5060 ;line=b5zaw7ti
- la version du SIP utilisée : SIP/2.0
Chaque élément est séparé des autres par un espace.
Le premier champ qui suit la ligne de départ est le champ Via. Chaque périphérique qui émet
ou retransmet un message SIP inscrit son adresse ou son nom dans ce champ. Chaque entrée
est présentée sous la forme suivante :
- le nom du champ : Via
- la version du champ et le protocole utilisé : SIP/2.0/UDP
- le nom ou l’adresse de l’expéditeur et le numéro de port : 192.168.74 :5060
- un paramètre « branch » qui est l’identifiant de la transaction (les réponses à ce

message contiendront le même identifiant) :
z9hG4bK9c3396199601d5ffcfa7ac712a378954.0
Le champ suivant est facultatif. Appelé « Max-Forwards », il s’agit d’une valeur qui est
décrémenté à chaque passage d’un périphérique. Si sa valeur arrive à zéro, le message est
supprimé. Cela permet d’éviter les boucles.
Les champs suivants sont « To » et « From » ; ils indiquent l’expéditeur et le destinataire.

Quand un nom est utilisé, comme dans notre exemple, il est placé entre crochets et utilisé
pour le routage du paquet.
Le champ « Call-ID » est un identifiant qui permet de suivre une session SIP particulière.
L’expéditeur créé une chaîne de caractère unique suivie généralement du signe arobase et de
son nom ou adresse. En plus, chaque utilisateur créé un identifiant unique appelé « tag ». Cet
identifiant est rajouté aux champs « To » et « From ». Le message initiale INVITE contient un
identifiant dans « From » mais pas dans « To ».
Page 83 sur 248

L’expéditeur génère donc le champ unique « Call-ID » et l’identifiant unique pour « From ».
En réponse au message INVITE, le destinataire va généré l’identifiant unique pour « To ». La
combinaison de ces trois informations (« Call-ID », identifiants « From » et « To ») permet de
rentre une communication unique. Cette communication peut enfin être appelé un dialogue.
Ces informations sont utilisées par les deux parties pour identifier le dialogue car chacun peut
avoir plusieurs communications en même temps.
L’en-tête se termine par différent message. Au minimum, un en-tête se compose des champs :
Via, Max-Forwards, To, From, Call-ID et CSeq. Le champ Cseq contient un nombre suivi du
nom de la méthode (INVITE). Ce nombre est incrémenté à chaque nouvelle requête. Dans
notre exemple, les champs Max-Forwards et CSeq sont inexistants. Le logiciel utilisé
(Microsoft Messenger 4.7) pour la communication (on parle de « User-Agent ») ne répond
donc pas au RFC 3261.
Microsoft Messenger 4.7 est la version de Messenger qui est fournie avec Microsoft Windows
XP. Microsoft et les entreprises de la VoIP considèrent cette version comme la dernière.
Toutefois, Microsoft a développé la version 5.0 de Messenger. Même si cette version n’a pas
été largement diffusée, elle est disponible à l’adresse suivante :
http://www.microsoft.com/downloads/details.aspx?displaylang=fr&FamilyID=77c3799f-
6388-4193-8002-be55584c1ac1
L’avantage de cette version est qu’elle respecte le RFC 3261 comme le montre le message
INVITE suivant :
INVITE sip:pierre@192.168.6.50:5060;line=b5zaw7ti SIP/2.0
Via: SIP/2.0/UDP 192.168.6.74:5060;branch=z9hG4bK30e39f5d7ef9ac01cfa7ac712a378954.0
Via: SIP/2.0/TCP 192.168.6.41:13796
Max-Forwards: 69
From: "fred@192.168.6.74"
<sip:fred@192.168.6.74>;tag=c6d81c232554416a86b46ede1092cb72;epid=1a3c0eda16
To: <sip:pierre@192.168.6.74>
Call-ID: 1f2051f3865b4742bd0c4f2cb3d98304@192.168.6.41
CSeq: 1 INVITE
Contact: <sip:fred@192.168.6.74:13796;maddr=192.168.6.41;transport=tcp>
User-Agent: RTC/1.2
Content-Length: 523
v=0
o=- 0 0 IN IP4 192.168.6.41
s=session
c=IN IP4 192.168.6.41
b=CT:1000
t=0 0
m=audio 64620 RTP/AVP 97 111 112 6 0 8 4 5 3 101
k=base64:mJMsWP379vNe4Urr4vNh2iqiNZYc2H+idO9p3ehbXtQ
a=rtpmap:97 red/8000
a=rtpmap:111 SIREN/16000
a=rtpmap:112 G7221/16000
Page 84 sur 248

a=rtpmap:3 GSM/8000
a=fmtp:101 0-16
a=encryption:optional
Un champ « Contact » est également nécessaire dans un message INVITE. Il contient l’URI
de l’User-Agent (UA). Cette URI permet de contacter l’UA directement.
Les champs « Content-Type » et « Content-Length » indiquent respectivement que le reste du

message est du SDP et contient 523 octets de données. Chaque caractère est codé sur un octet
et chaque retour à la ligne est codé sur deux octets (un pour le CR et un pour le LF) ; comme
le montre le tableau ci-dessous :
Nombre de Nombre
Chaîne de caractère
caractères d'octets
v=0 3 5
o=- 0 0 IN IP4 192.168.6.41 27 29
s=session 9 11
c=IN IP4 192.168.6.41 21 23
b=CT:1000 9 11
t=0 0 5 7
m=audio 64620 RTP/AVP 97 111 112 6 0 8 4 5 3 101 48 50
k=base64:mJMsWP379vNe4Urr4vNh2iqiNZYc2H+
52 54
idO9p3ehbXtQ
a=rtpmap:97 red/8000 20 22
a=rtpmap:111 SIREN/16000 24 26
a=fmtp:111 bitrate=16000 24 26
a=rtpmap:112 G7221/16000 24 26
a=fmtp:112 bitrate=24000 24 26
a=rtpmap:6 DVI4/16000 21 23
a=rtpmap:0 PCMU/8000 20 22
a=rtpmap:8 PCMA/8000 20 22
a=rtpmap:4 G723/8000 20 22
a=rtpmap:5 DVI4/8000 20 22
a=rtpmap:3 GSM/8000 19 21
a=rtpmap:101 telephone-event/8000 33 35
a=fmtp:101 0-16 15 17
a=encryption:optional 21 23
Total 523
Il est important de signaler qu’une ligne vide sépare l’en-tête et le corps du message. Cette
ligne n’est pas comptabilisée dans le nombre d’octets.
Les informations contenues dans le corps du message permettent de savoir quel type de
session peut être établie entre les deux parties. Il contient les capacités VoIP d’un
périphérique. Ci-dessous les différents champs que nous détaillerons plus tard :
Chaîne de caractère Nom du champ Signification
SDP (Session Description Protocol)
v=0 Version
Version 0
Page 85 sur 248

o=- 0 0 IN IP4 192.168.6.41 Nom d'utilisateur : -

Identification de session : 0
Propriétaire /
Version de session : 0
Type de Réseau : IN
Créateur
Type d'adresse : IPv4
Adresse : 192.168.6.41
s=session Nom de la Session Nom de la session : session
c=IN IP4 192.168.6.41 Type de Réseau : IN
Information de
Type d'adresse : IPv4
connexion
Adresse : 192.168.6.41
b=CT:1000 Bande passante Modificateur : CT
Valeur : 1000
t=0 0 Temps Début : 0
Fin : 0
Média Type : audio
Port : 64620
Protocole : RTP/AVP
Format : 97
Format : 111
Format : 112
m=audio 64620 RTP/AVP 97
Format : DVI4 16000 samples/s
111 112 6 0 8 4 5 3 101
Format : ITU-T G.711 PCMU
Format : ITU-T G.711 PCMA
Format : ITU-T G.723
Format : DVI4 16000 samples/s
Format : GSM 06.10
Format : 101
k=base64:mJMsWP379vNe4U Clé de cryptage Type : base64
rr4vNh2iqiNZYc2H+idO9p3e
Clé : mJMsWP…
hbXtQ
a=rtpmap:97 red/8000 Attributs de média Nom : rtpmap
Valeur : 97 red/8000
a=rtpmap:111 SIREN/16000 Attributs de média Nom : rtpmap
Valeur : 111 SIREN/16000
a=fmtp:111 bitrate=16000 Attributs de média Nom : fmtp
Valeur : 111 bitrate=16000
a=rtpmap:112 G7221/16000 Attributs de média Nom : rtpmap
Valeur : 112 G7221/16000
a=fmtp:112 bitrate=24000 Attributs de média Nom : fmtp
Valeur : 112 bitrate=24000
a=rtpmap:6 DVI4/16000 Attributs de média Nom : rtpmap
Valeur : 6 DVI4/16000
a=rtpmap:0 PCMU/8000 Attributs de média Nom : rtpmap
Valeur : 0 PCMU/8000
a=rtpmap:8 PCMA/8000 Attributs de média Nom : rtpmap
Valeur : 8 PCMA/8000
a=rtpmap:4 G723/8000 Attributs de média Nom : rtpmap
Valeur : 4 G723/8000
a=rtpmap:5 DVI4/8000 Attributs de média Nom : rtpmap
Valeur : 5 DVI4/8000
Page 86 sur 248

a=rtpmap:3 GSM/8000 Attributs de média Nom : rtpmap

Valeur : 3 GSM/8000
a=rtpmap:101 telephone- Attributs de média Nom : rtpmap
event/8000 Valeur : 101 telephone-event/8000
a=fmtp:101 0-16 Attributs de média Nom : fmtp
Valeur : 101 0-16
a=encryption:optional Attributs de média Nom : encryption
Valeur : optional
Parmi, toutes ces lignes, seulement trois méritent notre attention :
- c=IN IP4 192.168.6.41
- m=audio 64620 RTP/AVP 0
- a=rtpmap:0 PCMU/8000
Ci-dessous, les détails des champs possibles :

Champs Nom Obligatoire
v= Version du Protocole Oui
o= Identifiant du Propriétaire Oui
s= Nom de la session Oui
i= information de session Non
u= URI Non
e= adresse email Non
p= numéro de téléphone Non
c= information de connexion Oui
b= information de bande passante Non
t= début et fin de la session Oui
r= répétition Non
z= correction de l'heure Non
k= clé d'encryptage Non
a= attributs de la ligne Non
m= information du média Non
La première (c=IN IP4 192.168.6.41) nous donne l’adresse IP de connexion : 192.168.6.41.
La seconde (m=audio 64620 RTP/AVP 0) nous informe qu’une session audio est demandée
sur le port 49170 avec le protocole RTP. Le reste de la ligne nous donne les codecs
disponibles.
La dernière (a=rtpmap:0 PCMU/8000) nous donne les détails sur le codec proposé : PCM µ
Law avec fréquence d’échantillonnage de 8000 Hz.
La liste complète des codecs disponible actuellement est la suivante :

Code Codec Fréquence Déscription
0 PCMU 8000 ITU G.711 PCM u-Law Audio 64 Kbps
1 1016 8000 CELP Audio 4.8 Kbps
2 G721 8000 ITU G.721 ADPCM Audio 32 Kbps
3 GSM 8000 GSM Européen Audio 13 Kbps
4 G.723 8000 ITU G.723 Audio
Page 87 sur 248

5 DVI4 8000 DVI ADPCM Audio 32 Kbps

6 DVI4 16000 DVI ADPCM 64 Kbps
7 LPC 8000 Experimental LPC Audio
8 PCMA 8000 ITU G.711 PCM A-Law Audio 64 Kbps
9 G.722 8000 ITU G.722 Audio
10 L16 44100 Linéaire 16-bits Mono Audio 705,6 Kbps
11 L16 44100 Linéaire 16-bits Stéréo Audio 1411,2 Kbps
12 G.723 8000 G.723
13 CN 8000 Cisco systems comfort noise (non officiel)
14 MPA 90000 MPEG 1 ou MPEG 2 Audio
15 G.728 8000 ITU G.728 Audio 16 Kbps
18 G.729 8000 ITU G.729 Audio 8 Kbps
25 CELB 90000 SUN Systems Cell-B Vidéo
26 JBEG 90000 JBEG Vidéo
28 NV 90000 Nv Vidéo
31 H.261 90000 ITU H.261 Vidéo
32 MPV 90000 MPEG 1 ou MPEG 2 Vidéo
33 MP2T 90000 MPEG 2 stream Vidéo
34 H.263 H.263
Dynamique iLBC - Internet bas débit 15 Kbps
Codec à débit variable adapté (Adaptive Multirate
Dynamique AMR -
Codec)
Le message INVITE est un exemple de message SIP. Il y a cinq autres méthodes définies
dans le RFC 3261 et ses extensions. La réponse normale à un message INVITE est un
message « 180 Ringing ». Ci-dessous la liste des méthodes SIP :
Méthode Description
INVITE Invitation à participer à une session
ACK Accusé de réception
OPTIONS Demande de fonctionnalité
BYE Fin d’un appel
CANCEL Annulation d’une demande
REGISTER Enregistrement sur un serveur SIP
Message 180 Ringing

Ce message indique que le destinataire a bien reçu le message INVITE et qu’une alerte est en
cours : sonnerie, message, etc.
Le message Ringing est un exemple de message de réponse SIP. Les réponses sont
numériques et classée en fonction du chiffre des centaines. Ainsi la réponse 180 est un
message d’information. Ci-dessous, les différents types de réponse :
Code Type Description
1xx Information La demande a été reçue
2xx Succès La demande a été acceptée
3xx Redirection Une action est demandée pour que la demande soit acceptée
4xx Erreur Client La demande contient une erreur
5xx Erreur Serveur Une demande valide ne peut pas être exécutée
6xx Erreur Globale La demande ne peut pas être exécutée sur aucun serveur
Page 88 sur 248

Seul le code à une importance. Le texte qui suit le code n’est donné qu’à titre d’information.
Ainsi, une réponse 180 a la structure suivante :
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.6.74:5060;branch=z9hG4bK30e39f5d7ef9ac01cfa7ac712a378954.0
Via: SIP/2.0/TCP 192.168.6.41:13796
From: "fred@192.168.6.74"
<sip:fred@192.168.6.74>;epid=1a3c0eda16;tag=c6d81c232554416a86b46ede1092cb72
To: <sip:pierre@192.168.6.74>;tag=he7ygxy8sp
Call-ID: 1f2051f3865b4742bd0c4f2cb3d98304@192.168.6.41
Contact: <sip:pierre@192.168.6.50:5060;line=b5zaw7ti>
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE,
INFO
Allow-Events: talk, hold, refer
Content-Length: 0
Ce message a été créé en recopiant de nombreux champs du message INVITE (Via, To, From,
Call-ID et CSeq) et en rajoutant la ligne de départ avec la version du SIP utilisé ainsi que le
numéro et le texte de réponse.
Message 200 OK
Quand l’utilisateur pierre décide d’accepter l’appel, un message « 200 OK » est renvoyé à
Fred. Ce message indique également que le type de média demandé par Fred est accepté :
SIP/2.0 200 Ok
Via: SIP/2.0/UDP 192.168.6.74:5060;branch=z9hG4bK33492227680c0333cfa7ac712a378954.0
Record-Route: <sip:38ab9afe@192.168.6.74;lr>
From: "fred@192.168.6.74"
<sip:fred@192.168.6.74>;epid=13c4966317;tag=ecfb071b5fe2499299accb91a0ed87a6
To: <sip:pierre@192.168.6.74>;tag=061byrzvpi
Call-ID: b5cbe6ee6a4141c7b2ce6f11463d1145@192.168.6.41
CSeq: 1 INVITE
Contact: <sip:pierre@192.168.6.50:5060;line=b5zaw7ti>
User-Agent: snom105-3.24
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE,
INFO
Allow-Events: talk, hold, refer
Supported: timer, 100rel, replaces
Content-Length: 208
v=0
o=root 1746986229 1746986229 IN IP4 192.168.6.50
s=call
c=IN IP4 192.168.6.50
t=0 0
m=audio 10008 RTP/AVP 0 101
a=rtpmap:0 pcmu/8000
a=fmtp:101 0-15
a=sendrecv
La réponse est construite de la même manière qu’un message « 180 Ringing ». Les capacités
de l’UA sont renvoyées dans le corps du message.
Page 89 sur 248

Message ACK
L’étape finale consiste a validé la session avec un message ACK :
ACK sip:38ab9afe@192.168.6.74;transport=tcp;lr SIP/2.0
Via: SIP/2.0/TCP 192.168.6.41:9283
Max-Forwards: 70
From: "fred@192.168.6.74"
<sip:fred@192.168.6.74>;tag=ecfb071b5fe2499299accb91a0ed87a6;epid=13c4966317
To: <sip:pierre@192.168.6.74>;tag=061byrzvpi
CSeq: 1 ACK
Route: <sip:pierre@192.168.6.50:5060;line=b5zaw7ti>
User-Agent: RTC/1.2
Content-Length: 0
Le numéro de séquence est le même que pour le message INVITE mais le nom de la méthode
est ACK.
Le message BYE
La communication se termine par l’envoie d’un message BYE :
BYE sip:fred@192.168.6.74:9283;maddr=192.168.6.41;transport=tcp SIP/2.0
Via: SIP/2.0/UDP 192.168.6.50:5060;branch=z9hG4bK-
obs6u8nnmkzh;received=192.168.6.50;rport=5060
Route: <sip:38ab9afe@192.168.6.74;lr>
From: <sip:pierre@192.168.6.74>;tag=061byrzvpi
To: "fred@192.168.6.74"
<sip:fred@192.168.6.74>;epid=13c4966317;tag=ecfb071b5fe2499299accb91a0ed87a6
CSeq: 1 BYE
Dans notre exemple, c’est Pierre qui a raccroché le premier. Fred confirmera la fin de la
communication par un message « 200 OK ».
d) SIP avec un serveur Proxy en mode Stateless

Dans notre exemple précédent, Fred connaissait l’adresse IP de Pierre et a été capable
d’envoyer un message INVITE directement. En pratique, c’est rarement le cas. Une adresse
IP ne peux pas être utilisée comme un numéro de téléphone (cela risque de changer avec
l’IPv6), le serveur proxy sert donc d’intermédiaire :
Page 90 sur 248

Pierre Serveur Proxy Fred
INVITE
INVITE
180 Ringing
180 Ringing 200 OK
200 OK
ACK
Communication RTP
BYE
200 OK
Communication
Communication SIP
SIP :: Proxy
Proxy Stateless
Stateless
Un serveur proxy a la charge de router les messages SIP. Il a uniquement un rôle dans la
signalisation et il ne gère pas de media. Il n'est en général à l'origine d'aucune requête
exceptée la requête CANCEL utilisée pour libérer une session. On en utilisera par exemple un
pour séparer un réseau privé local et Internet, comme le montre le schéma suivant :
BSNetwork :
sip.tcp SRV 0 0 5060 sip.bsnetwork.fr.
SRV 1 0 5060 backup.bsnetwork.fr.
Serveur sip.udp SRV 0 0 5060 sip.bsnetwork.fr.
DNS SRV 1 0 5060 backup.bsnetwork.fr.
Internet
Pierre Fred
Proxy SIP
BSNetwork
sip.bsnetwork.fr
Serveur
Serveur Proxy
Proxy
Page 91 sur 248

Il y existe deux sortes de proxys, les proxys « statefull » et « stateless ». La différence est le
fait que le proxy « statefull » enregistre la position du destinataire tandis que le proxy
« stateless » ne le fait pas.
Dans le cas présent, Fred ne connaît pas l'adresse exacte de Pierre, il ne connaît qu'une adresse
SIP (appelée URI SIP) qui ressemble à une adresse e-mail : « Pierre@bsnetwork.fr ». Fred va
tout d’abord contacter un serveur DNS pour obtenir le nom du serveur qui gère le SIP pour le
domaine « bsnetwork.fr ». Comme le montre le schéma ci-dessus, il existe quatre entrées
(deux pour le TCP et deux pour l’UDP) pour le protocole SIP (port 5060) : sip.bsnetwork.fr a
une priorité de 0 et backup.bsnetwork.fr a une priorité de 1. Fred va choisir le serveur qui a la
priorité la plus faible (sip.bsnetwork.fr) et lancera son appel.
Le proxy va recevoir l'appel (message INVITE), se charge de faire la correspondance avec

l'adresse IP de la machine sur laquelle est connectée Pierre et lui transmet le message ou le
fait suivre vers un autre proxy plus apte à trouver Pierre. Fred n'a donc pas à connaître
l'adresse IP exacte de Pierre, seul l'adresse du proxy suffit. Ce système est très utile car il
permet à un utilisateur de changer de machine ou de lieu sans avoir aucun problème de
changement d'adresse.
e) SIP avec un serveur Proxy en mode Statefull

Le serveur proxy en mode Statefull route les paquets et n'a aucune implication dans l'échange
de flux média qui suit.
Dans l'exemple précédent, cas d'un PS (Proxy Server) en mode Stateless, on peut constater
qu'une fois les premiers messages échangés, les UAs (User Agents) s'envoient directement
leurs messages sans passer par le proxy. C'est une fonctionnalité fournie par SIP qui permet
aux UAs de se donner leurs adresse SIP finales (dans un champ nommé « Contact : »). Lors
de la requête suivante les UAs peuvent alors se joindre directement.
Cependant le serveur proxy peut forcer toutes les requêtes suivantes d'une session à passer par
lui (en ajoutant son adresse dans le champ nommé « Record-Route : »). Dans ce cas le proxy
est dit en mode Statefull comme le montre la figure suivante :
Page 92 sur 248

Pierre Serveur Proxy Fred
INVITE
INVITE
180 Ringing
180 Ringing 200 OK
200 OK
ACK
Communication RTP
BYE
BYE
200 OK
200 OK
Communication
Communication SIP
SIP :: Proxy
Proxy Statefull
Statefull
Un des intérêts de ce type de fonctionnement est de pouvoir garder une trace des temps de
communication en vue de faire des statistiques sur les usages ou de mettre en place une
facturation basée sur le temps de communication. Un autre intérêt de ce fonctionnement est
qu'il offre la possibilité de contrôler le nombre de communication entre deux domaines et
donc l'opportunité de pouvoir contrôler la bande passante sur certains liens (nécessaire pour
pouvoir offrir une garantie de service).
Un type particulier de serveur proxy, appelé serveur forking proxy, peut dupliquer une
requête et l'envoyer vers plusieurs destinataires. Ces serveurs peuvent par exemple être
utilisés pour contacter plusieurs terminaux appartenant à la même personne.
f) Serveur registrar
Afin de pouvoir joindre une personne à partir de son adresse SIP, une entité dans le réseau
doit maintenir une correspondance (mapping) entre les adresses IP et les adresses SIP. C'est le
rôle du serveur Registrar. Un utilisateur peut donc changer d'adresse, il lui suffit de s'inscrire
auprès du Registrar en lui indiquant son adresse SIP et son adresse de machine sur le réseau
comme sur le schéma suivant :
Page 93 sur 248

Fred
Serveur
Registrar Base de
REGISTER
données
200 OK
Adresse IP Adresse SIP

192.168.6.41 fred@bsnetwork.fr
SIP
SIP Registrar
Registrar
La figure précédente montre l'enregistrement du terminal de Fred sur un serveur Registrar. A

la réception du message REGISTER, le serveur Registrar a accès à l'adresse IP de la source,
Fred, dans l'en-tête IP du message. Il enregistre alors la correspondance entre cette adresse IP
et l'adresse SIP donnée dans le champ « Contact : », soit ici « sip:fred@bsnetwork.fr ».
REGISTER sip:bsnetwork.fr SIP/2.0

Via: SIP/2.0/UDP 83.114.26.55:13045
Max-Forwards: 70
From: <sip:fred@bsnetwork.fr>;tag=308e3ac96b1748789de6ae09a13c8369;epid=1e770c8576
To: <sip: fred@bsnetwork.fr >
Call-ID: afbbe04dc4cf4ad6a6a774c4d943aaba@192.168.0.2
CSeq: 3 REGISTER
Contact: <sip:192.168.6.41:13045>;methods="INVITE, MESSAGE, INFO, SUBSCRIBE, OPTIONS,
BYE, CANCEL, NOTIFY, ACK, REFER"
User-Agent: RTC/1.2.4949 (Messenger 5.0.0482)
Expires: 0
Event: registration
Content-Length: 0
3) Comparaison SIP et H.323

Avant de décider d’un protocole, il est nécessaire de les comparer. Au niveau technique, le
SIP est plus ouvert que le H.323 :
H.323 SIP
Architecture Pile de protocoles Eléments
Origine ITU IETF
Transport TCP (UDP depuis V3) UDP
Codage ASN.1 Texte
Dérivé de Téléphonie Multimédia
Interopérabilité Faible Elevée
Adressage IP, URL,… URL
La version 3 du H.323 et le SIP offrent les mêmes contrôles d’appel :
Page 94 sur 248

Service H.323v1 H.323v2 H.323v3 SIP

Maintien NON OUI OUI OUI
Transfert NON OUI OUI OUI
Renvoi NON OUI OUI OUI
Attente NON OUI OUI OUI
Toutefois, le SIP offre des caractéristiques supplémentaires :

3ème appelants NON NON NON OUI
Conférence NON OUI OUI OUI
Click pour appel NON OUI OUI OUI
Echange paramètres OUI OUI OUI OUI
Le SIP offre également une meilleure qualité :

Délai d’appel 6-7 3-4 2,5 1,5
Traitement paquets perdus TCP TCP OUI OUI
Détection boucle NON NON Valeur du chemin Grâce au saut
Tolérant aux fautes NON NON Backup OUI
H.323 requiert une interaction entre plusieurs sous-protocoles ce qui le rend plus compliqué
que le SIP. La structuration du protocole SIP est hiérarchisée par un organe de
standardisation (IANA), tandis que celle du protocole H.323 dépend des implémentations par
les différents constructeurs. L’implémentation du SIP est donc plus facile :
H.323 SIP
Messages H.323 de formats binaires Messages SIP en format texte
Codage par ASN.1 Implémentation facile en Perl, Tcl, Java,…
Débuggage facile avec : tcpdump, ngrep,
Parsers spéciaux pour lire et écrire le code
netcat…
845 pages de spécifications 195 pages de spécifications
Implémentation et débuggage compliqué Débuggage et implémentation aisé
Le protocole SIP est de plus transparent aux proxys. Il accepte également les types arbitraires
MIME, du moment que ses champs options restent compatible avec le reste du protocole. La
personnalisation est donc aisée:
H.323 SIP
L’interaction entre les protocoles rend
Part l’ajout d’un champ d’en-tête
l’optimisation compliquée
Pleine compatibilité avec l’ensemble du
Champs non reconnus pouvant être ignorés
protocole
Enfin, le SIP est indépendant du protocole de transport:

H.323 SIP
Peut utiliser n’importe quel protocole de
TCP
transport
Supporte UDP dès la version 3
Page 95 sur 248

4) L’avenir de la signalisation VoIP

Il est évidant que H.323 est omniprésent dans la communication temps réel sur IP, lui offrant
une grande interopérabilité par le fait qu’il y a eu un développement important de produits
depuis 1996. Il ne faut pas oublier que H.323 possède certains avantages sur SIP tel que le
nombre plus important d’adressage ou encore le fait qu’H.323 est plus mature que SIP.
L’avenir du protocole SIP est pourtant très radieux. Grâce à ces atouts sur ses concurrents qui
sont réels et non négligeables :
- SIP se caractérise comme étant un protocole plus rapide. Tout d’abord la séparation
entre ses champs d’en-tête et son corps du message facilite le traitement des messages
et diminue leur temps de transition dans le réseau. De plus, le nombre des en-têtes est
limité (36 au maximum et en pratique, moins d'une dizaine d'en-têtes sont utilisées
simultanément), ce qui allège l'écriture et la lecture des requêtes et réponses.
- SIP est un protocole indépendant de la couche transport : il peut aussi bien s’utiliser
avec TCP que UDP. De plus, il sépare les flux de données de ceux de la signalisation :
en effet, une requête et sa réponse peuvent prendre deux chemins différents, ce qui
rend plus souple l'évolution d'une communication (arrivée d'un nouveau participant,
changement de paramètres…).
- SIP ne requiert pas de compatibilité descendante. SIP est un protocole horizontal au

contraire de H.323 : les nouvelles versions d’H.323 doivent tenir compte des
fonctionnalités des anciennes versions pour continuer à fonctionner. Ceci entraîne
pour H.323 de « traîner » un peu plus de code à chaque version.
- il y a des de multiples translateurs inter-standards de signalisation pour SIP. Il y en a

pour SS7 (Signaling System n°7), MGCP (Media Gateway Control Protocol),
SigTrans (Signalisation Transport), H.323,….
- le protocole SIP offre d’autres fonctions comme l’IM (Instant Messaging). Cette
fonction est d’ailleurs portée sur des systèmes IP téléphonie mobile afin de pouvoir
envoyer des messages du réseau IP sur un mobile GSM ou UMTS par le biais de la
signalisation SIP.
- les grands fournisseurs de solutions de VoIP et mêmes des plus petits ont arrêtés le
développement de leur produit compatible H.323 pour passer au protocole SIP
(Microsoft, Cisco,…).
- la description de SIP est beaucoup plus simple que celle d'H.323 (195 pages de RFC
contre 846), il est plus léger et donc plus facile à mettre en oeuvre, sans être moins
complet pour autant.
C’est pour toutes ces raisons que la majorité des participants à la mise en application de
solutions VoIP préconisent désormais l’utilisation de la signalisation SIP (Session Initiation
Protocol). Dans ces conditions, nous avons également choisi le protocole SIP plutôt que
H.323.
Page 96 sur 248

VII. Analyse du trafic pour la VoIP

La VoIP utilise le RTP (Real-Time Protocol) pour transporter la voix. En connaissant la
nature des informations encapsulées et le type de réseau, il est facile de correctement le
dimensionner.
1) Les codecs
Comme nous l’avons déjà vu, de nombreux codecs sont utilisés dans la téléphonie IP. Pour
avoir la bande passante de chacun de ces codecs, il suffit de regarder dans la partie
« Compression de la parole et traitement des données » ou dans la copie qui se trouve en
annexe.
2) Les échantillons
Le nombre d’échantillons par paquet est également un facteur important pour connaître la
bande passante d’un appel téléphonique. Le codec définit la taille d’un échantillon, mais le
nombre total d’échantillons dans un paquet nous donne le nombre de paquets qui seront
envoyés par seconde.
Par exemple, 10 ms d’un appel codé en G.711 demande 80 octets. Un paquet sera envoyé
toute les 10 ms soit 100 paquets par secondes :
80 octets + 20 octets IP + 12 octets UDP + 8 octets RTP = 120 octets par paquets.
120 octets par paquets * 100 paquets par secondes = (12000 * 8 bits)/1000 = 96 kbps par appel
Par contre, si nous mettons 2 échantillons de 10 ms par paquets, il n’y a que 50 paquets par
secondes :
80 octets * 2 + 20 octets IP + 12 octets UDP + 8 octets RTP = 200 octets par paquets.
200 octets par paquets * 50 paquets par secondes = (10000 * 8 bits)/1000 = 80 kbps par appel
Nous n’avons pas pris en compte les en-têtes de la couche 2. Toutefois, nous pouvons
constater que la différence entre les deux appels est de 16 kbps.
En changeant le nombre d’échantillons par paquets, il est donc facile de diminuer la bande
passante nécessaire pour un appel ; mais cela augmente le délai et il est alors nécessaire de
prévoir des buffers suffisants.
3) Détection de l’activité
Une conversation contient en général être 35 et 50 % de silence. Avec la téléphonie classique,
la bande passante est définie à 64 kbps, qu’il y ait une activité ou pas. Avec les réseaux VoIP,
les conversations et les silences sont mis en paquets. La technologie de détection de l’activité
(ou VAD : Voice Activity Detection) permet de n’envoyer un paquet que lorsque la voix est
détectée. On peut alors considérer que la bande passante nécessaire est réduite de 35 %. Ce
pourcentage prend en compte les différents dialectes et langues.
Les codecs G.729 Annex-B et G.723 Annex-A incluent une fonction de VAD, sinon, ils sont
identiques aux codecs G.729 et G.723.
Page 97 sur 248

4) Compression des en-têtes RTP

Tous les paquets VoIP ont deux composants : un échantillon de voix et un en-tête
IP/UDP/RTP. Bien que l’échantillon de voix soit compressé en fonction du codec utilisé, l’en-
tête à une taille fixe de 40 octets. A titre de comparaison, 20 octets sont nécessaires pour un
échantillon de voix codé en G.729. En utilisant la compression des en-têtes (ou cRTP :
Compressed Real Time Protocol), l’en-tête ne fait plus que 2 ou 4 octets. Pour conclure, un
appel en G.729 demande 24 kbps sans le cRTP et seulement 12 kbps avec. Mais très peu
d’équipements le gèrent.
5) Synthèse
Le choix du codec, le nombre d’échantillons par paquets, le VAD et le cRTP définissent la
bande passante nécessaire pour un appel. :
Bande
Bande
passante
Taille En-tête En-tête passante
Paquets En-tête totale
Voix de la IP/UD Couche couche totale
Codecs par CRTP (kb/s)
(kb/s) trame P/RTP 2 2 (kb/s)
seconde (octets) avec
(octets) (octets) (octets) sans
VAD (50
VAD
%)
G.711 64 80 50 40 — Ether 14 85.6 42.8
G.711 64 80 50 — 2 Ether 14 70.4 35.2
G.711 64 80 50 40 — PPP 6 82.4 41.2
G.711 64 80 50 — 2 PPP 6 67.2 33.6
G.711 64 80 50 40 — FR 4 81.6 40.8
G.711 64 80 50 — 2 FR 4 66.4 33.2
G.711 64 80 100 40 — Ether 14 107.2 53.6
G.711 64 80 100 — 2 Ether 14 76.8 38.4
G.711 64 80 100 40 — PPP 6 100.8 50.4
G.711 64 80 100 — 2 PPP 6 70.4 35.2
G.711 64 80 100 40 — FR 4 99.2 49.6
G.711 64 80 100 — 2 FR 4 68.8 34.4
G.729 8 10 50 40 — Ether 14 29.6 14.8
G.729 8 10 50 — 2 Ether 14 14.4 7.2
G.729 8 10 50 40 — PPP 6 26.4 13.2
G.729 8 10 50 — 2 PPP 6 11.2 5.6
G.729 8 10 50 40 — FR 4 25.6 12.8
G.729 8 10 50 — 2 FR 4 10.4 5.2
G.729 8 10 33 40 — Ether 14 22.4 11.2
G.729 8 10 33 — 2 Ether 14 12.3 6.1
G.729 8 10 33 40 — PPP 6 20.3 10.1
G.729 8 10 33 — 2 PPP 6 10.1 5.1
G.729 8 10 33 40 — FR 4 19.7 9.9
G.729 8 10 33 — 2 FR 4 9.6 4.8
G.723.1 6.3 30 26 40 — Ether 14 17.6 8.8
G.723.1 6.3 30 26 — 2 Ether 14 9.7 4.8
G.723.1 6.3 30 26 40 — PPP 6 16.0 8.0
G.723.1 6.3 30 26 — 2 PPP 6 8.0 4.0
G.723.1 6.3 30 26 40 — FR 4 15.5 7.8
Page 98 sur 248

G.723.1 6.3 30 26 — 2 FR 4 7.6 3.8

G.723.1 5.3 30 22 40 — Ether 14 14.8 7.4
G.723.1 5.3 30 22 — 2 Ether 14 8.1 4.1
G.723.1 5.3 30 22 40 — PPP 6 13.4 6.7
G.723.1 5.3 30 22 — 2 PPP 6 6.7 3.4
G.723.1 5.3 30 22 40 — FR 4 13.1 6.5
G.723.1 5.3 30 22 — 2 FR 4 6.4 3.2
VIII. Problèmes de la VoIP

Le fait que la VoIP ne devienne pas encore le standard qui remplace la téléphonie comme on
la connaît actuellement est la conséquence de deux facteurs :
- les réseaux IP ne garantissent actuellement que très « peu » de QoS (Quality of

Service). C’est à dire qu’en majorité des cas l’information est envoyée en mode « Best
Effort », ce qui veut dire que l’information est juste envoyée sans savoir comment et
quand elle sera acheminée vers la destination (si elle est acheminée un jour…).
- l’utilisateur est exigeant, ce qui veut dire qu’il veut que la qualité soit aussi bonne,
voire meilleure, que lorsqu’il téléphone avec son téléphone analogique ou ISDN
(Integrated Services Digital Network). Pourtant l’utilisateur s’est accommodé du
manque de qualité de la téléphonie mobile GSM…
1) Généralités sur les problèmes de qualité

Pour qu’un appel sur un réseau IP s’effectue à l’insu des utilisateurs la qualité de la voix
devra être la même que pour un appel « normal ». Plusieurs facteurs entrent en jeu quant il
s’agit de la qualité de la voix (QoS, Quality of Service) sur un réseau IP :
- nous devons utiliser un codec qui permet d’utiliser le réseau à profit et pour ce, il doit
produire une bonne qualité de voix dans des délais raisonnables. L’ITU propose
plusieurs standards G.7XX qui possèdent chacun des caractéristiques adaptées aux
différents besoins.
- nous devons annuler le retour du signal qui produit un écho. L'écho est le délai entre
l'émission d'un signal et la réception de ce même signal réverbéré. Ce problème se
pose généralement dans les communications PC à Téléphone, Téléphone à PC ou
Téléphone à Téléphone. Il est causé par les composantes électroniques des parties
analogiques du système qui renvoient une partie du signal traité. Un écho inférieur à
50 ms n'est pas perceptible. Au-delà, l'interlocuteur s'entend parler avec un retard.
Pour pouvoir offrir un service de téléphonie sur IP, les passerelles doivent traiter
l'écho électrique généré par le passage de 2 fils à 4 fils. Si ce traitement n'est pas
effectué, le service ne sera pas utilisable avec des postes analogiques classiques. La
qualité de la communication devient inacceptable si le délai de transmission et de
commutation excède 25 ms par sens. Pour résoudre ce problème, on introduit dans le
réseau des annulateurs d'écho (DSP).
- nous devons assurer un minimum de perte des paquets tout au long de la

communication. Le protocole UDP ne garantit pas que les paquets arriveront à
destination. Une erreur sur l'en-tête du paquet peut entraîner sa perte ou l'envoi vers
une mauvaise destination. D'autre part, lorsque les routeurs IP sont congestionnés, ils
Page 99 sur 248

libèrent automatiquement de la bande passante en détruisant une certaine proportion
des paquets entrants en fonction de seuils prédéfinis. Le taux de perte des paquets
dépendra de la qualité des lignes empruntées et du dimensionnement du réseau. Pour
avoir une qualité de parole acceptable, le taux de perte de paquet doit rester inférieur à
25 % (valeur échelon utilisée dans le domaine de la VoIP). Ci-dessous, la
correspondance entre le taux de pertes et la qualité de la communication :
Qualité Telecom
Clair
Qualité
Compréhensible
Inaudible
5% 10% 15% 20% 25% 30% 35% 40%

Taux de perte de paquets
Qualité
Qualité en
en fonction
fonction de
de la
la perte
perte de
de paquets
paquets
- il s’agit de réduire les délais réseau et d’éliminer les jitters (ou gigue). Il existe deux
types de délais, les délais fixes et les délais variables. Les délais fixes représentent le
temps nécessaire pour traverser tous les noeuds par lesquelles les paquets de voix
doivent passer ainsi que le temps pour mettre en paquets la voix en fonction du codec
utilisé. Les délais variables sont les événements incontrôlables qui font en sorte que
les paquets se perdent ou bien arrivent avec beaucoup de retard. Pour éviter que cela
ne se produise trop fréquemment les applications prévoient un tampon de gigue qui est
basé sur les délais variables du réseau. Donc les paquets de voix sont retenus dans le
tampon de gigue pendant une période de temps avant d’être joué, ce qui ajoute encore
du temps au délai fixe du réseau. Par exemple, si on calcul un délais fixe dans le
réseau de 50 ms et un délais variable de 5 ms, alors le tampon de gigue devra être de 5
ms et on se retrouvera maintenant avec un délais de 55 ms ce qui est un performance
« correcte » dans le cadre de VoIP. Le délai est le temps écoulé entre l'émission de la
parole et sa restitution à l'arrivée. Pour permettre un échange interactif, la voix doit
être transmise avec des contraintes de délai. Les chiffres suivants (tirés de la
recommandation UIT-T G114) sont donnés à titre indicatif pour préciser les classes de
Page 100 sur 248

qualité et d'interactivité en fonction du délai de transmission dans une conversation
téléphonique :
Classe n° Délai par sens Commentaires
1 0 à 150 ms Acceptable pour la plupart des conversations.
Acceptable pour des communications faiblement
2 150 à 300 ms
interactives (communication satellite : 250 ms par bond)
3 300 à 700 ms Devient pratiquement une communication half duplex
Inutilisable sans une bonne pratique de la conversation
4 Au-delà de 700 ms
half duplex
- il y a la gestion de la priorité des paquets VoIP. Les routeurs sont configurés de façon
à accorder une priorité plus grande aux paquets VoIP soit en favorisant les paquets
provenant d’un port UDP spécifié au préalable ou bien en utilisant le protocole RSVP.
- le nombre d’utilisateurs sur le réseau et la façon dont ces utilisateurs utilisent le dit
réseau est un facteur important à tenir en compte lors d’une implémentation de
solution VoIP. C’est à dire que plus le trafic engendré sur le réseau est important, plus
la qualité de la voix s’en ressentira dans le sens négatif bien sûr. Par exemple, il
pourrai arriver que le mécanisme de remise en ordre des paquets offert par TCP ne
fonctionne pas bien et donc il se pourrait que des paquets soient inversés à l’arrivée.
L’ensemble des problèmes est schématisé ci-dessous :
T T’ ≠ T
Réseau IP
BON JOU COM MENT VAS TU ? BON COM VAS MENT TU ?
Perte d’un Inversion de 2 Gigue : variation

paquet paquets du délai
Les
Les problèmes
problèmes de
de la
la VoIP
VoIP
2) Problèmes de qualité sur les réseaux sans fils.

De plus en plus de réseaux locaux sont sans fils (wireless ou technologie Wifi). Cela pose
d’autres problèmes pour la VoIP :
- le plus grand facteur pour obtenir une meilleure qualité de la voix possible est la
distance. C’est à dire que plus le terminal est loin de l’antenne et plus le débit sera
faible. Qui dit diminution du débit, dit également diminution de la bande passante,
donc abaissement des ressources pouvant être utilisée par les applications VoIP.
- La topologie du lieu où se situe le réseau wireless est un paramètre important. C’est à

dire que dans un lieu où il y a de nombreux obstacles (rebonds ou absorption des
ondes) la qualité de la transmission se fera ressentir. D’autres problèmes au niveau de
la topologie se trouvent dans la cohabitation avec d’autres sources hertziennes (entre 2
réseaux WLAN il y a déjà des interférences). Ne pas oublier également la cohabitation
avec la norme Bluetooth ou encore la norme Hiperlan pour ne citer que ces 2 autres
normes « concurrentes ».
Page 101 sur 248

- On ne peut pas augmenter la bande passante pour accroître les ressources disponibles.
On ne peut pas le faire tout bonnement par le fait qu’on travaille dans le domaine
hertzien implique qu’on est forcément limité.
- De plus, si débit effectif disponible est de 5 Mbps/s pour un utilisateur (valeur

mesurée lors des tests effectués), comme le lien est unique, il est donc partagé par le
nombre d’utilisateur utilisant le lien wireless. C’est à dire que si le lien est utilisé par 5
utilisateurs, ils auront approximativement 1 Mbps chacun. Toutefois, si une
réservation de bande passante est faite, cela dépendra des différentes réservations.
Page 102 sur 248

IX. Architecture SIP

L’objectif de mon stage était de créer une solution globale, permettant une réduction
maximale des coûts. Pour cela, il a fallut contacter divers fabricants et opérateurs :
Entreprise Site Web Fonction
Vegastream est le premier fournisseur

http://www.vegastream.com
de passerelle VoIP.
Ingate Systems Inc. est la compagnie

http://www.ingate.com qui propose le premier firewall
compatible SIP pour les entreprises.
Asterisk est un logiciel Open-Source

http://www.asterisk.org disponible sous Linux, capable de
remplacer un PBX.
Digium est le premier développeur et

sponsor d’Asterisk. Digium propose
http://www.digium.com une gamme complète de matériel et
de logiciel (dont le codec G.729) pour
Asterisk.
Snom Technology AG produit
exclusivement des éléments pour la
http://www.snom.com
VoIP, en particulier des terminaux
SIP.
Cisco Systems est aujourd’hui le
premier fournisseur mondial de
solutions réseaux pour Internet. Cisco
http://www.cisco.com fournit la gamme la plus étendue de
solutions pour le transport des
données, de la voix et de la vidéo ; en
particulier des terminaux SIP.
Primus Telecommunications est un
des principaux opérateurs de voix et
http://www.primustel.fr/ données dans le monde, offrant une
gamme complète de services
téléphoniques et internet.
Page 103 sur 248

1) Passerelle Vegastream
a) Introduction
Avant de passer tout le réseau d’une entreprise en téléphonie IP, il est nécessaire de conserver
un lien avec la téléphonie classique. Pour cela nous utilisons des passerelles « Vegastream ».
Créée en 1998, cette entreprise est située en Angleterre et en Californie. Elle propose des
passerelles compatibles avec les protocoles SIP et H323, comme le montre le tableau suivant :
Vega 10 20 25 50 100 400
4 ETSI
1 FXS + 1 10 FXO
Interfaces 1 FXS 2 FXS 1-2 E1 4 E1/T1
FXO
8 FXS +
2FO
Nombre
1 2 1 8 30-60 120
d’appels
Protocole SIP SIP SIP SIP/H323 SIP/H323 SIP/H323
Image
Une passerelle Vegastream permettra par exemple de router tous les appels sortant d’une
entreprise vers Internet. Cela permet une économie immédiate sur les factures téléphoniques :
Page 104 sur 248

France
Internet
Telecom
VoIP
ISDN
Passerelle VoIP
Appels Entrants Appels Sortants

Routeur
PABX
Téléphonie
classique
Vegastream
Vegastream
b) Connexion
Dans l’implémentation que nous envisageons, la passerelle Vegastream est placée entre
l’ISDN France Telecom et le PABX. La plupart du temps, nous allons donc la placer sur le
lien E1 (en France, on parle de lien T2 – 30 canaux). Pour cela, nous utilisons une
Vegastream 100. Elle possède 2 ports DSL et 1 port LAN :
Page 105 sur 248

Alimentation DSL 1 & 2 Série LAN

(RS232)
Ports
Ports Vegastream
Vegastream 100
100
Il existe donc 3 connexions possibles pour la Vegastream 100 :
- Soit on connecte 2 ports de la Vegastream sur l’ISDN France Telecom et dans ce cas
les 2 ports doivent être configuré en mode TE (Terminal EndPoint/Equipement)
- Soit on connecte 1 port sur l’ISDN et un port sur le PBX (c’est ce modèle que nous
utilisons)
- Soit on connecte 2 ports de la Vegastream sur le PBX et dans ce cas les 2 ports
doivent être configuré en mode NT (Network Termination)
1 2 3
France France NT : Network Termination

TE : Terminal Endpoint/Equipement
Telecom Telecom
2 liens 1 lien
ISDN ISDN
TE TE
1 lien
1 lien NT 1 lien 1 lien NT 2 liens
LAN
LAN PBX LAN PBX
LAN LAN LAN
Connexion
Connexion Vegastream
Vegastream 100
100
Page 106 sur 248

En pratique, nous allons devoir sectionner le lien T2 pour intercaler la passerelle entre le PBX
et l’ISDN. La plupart du temps, un lien T2 est un câble à paires torsadées. Il est alors
nécessaire d’y mettre des connecteurs RJ45 afin de pouvoir connecter la passerelle, comme le
montre le schéma suivant :
FT ISDN/PSTN PABX
Le code de couleur est celui

de la norme TIA/EIA 568A
(4) Rx+ (1) Rx+
(5) Rx - (2) Rx -
(1) Tx+ (4) Tx+

(2) Tx - (5) Tx -
Câble Câble
croisé droit
(Bleu) (Rouge)
Prise Prise
RJ45 87654321 87654321 RJ45
mâle mâle
Rx+
Rx+
Rx+
Tx+
Tx+
Tx+
Rx-
Rx-
Rx-
Tx-
Tx-
Tx-
87654321 87654321 87654321
VEGA
PORT ISDN 01 (TE) PORT ISDN 02 (NT) PORT LAN 99
Le connecteur croisé est

Connecteur utilisé pour remplacer la
Vega
Croisé
Prise Prise
RJ45 87654321 87654321 RJ45
femelle femelle
Câblage
Câblage Vegastream
Vegastream 100
100
Page 107 sur 248

c) Architecture
L’architecture des Vegastream est dédiée à la VoIP. Ainsi, le passage de la téléphonie vers le
réseaux (ou l’inverse) se fait de la manière la plus rapide possible. En effet, les passerelles
Vegastream utilisent des DSP dédiés pour la compression et la décompression audio, ainsi
qu’une architecture sans routage. Il est donc possible d’avoir 60 communications simultanées
sans perte de qualité :
Signaux
Paquets IP
téléphoniques et voix
Interface
LAN
Module
d’interface des
signaux Processeur
Contrôleur MIPS
Ethernet
BUS TDM
BUS PCI
DSP
Architecture
Architecture Vegastream
Vegastream 100
100
d) Plan d’appel
Les passerelles Vegastream utilisent un plan d’appel qui fonctionne un peu comme une table
de routage. Chaque interface est numéroté (ISDN : 01 et 02 ; LAN : 99). En fonction, du
numéro appelé, et de l’interface source, la passerelle est capable de transférer un appel vers la
bonne destination. Pour cela, il est nécessaire d’utiliser des variables et des expressions
régulières :
Variable Explication
IF : Numéro de l’interface source ou de destination
Page 108 sur 248

TEL Numéro de téléphone appelé

TA Nom ou adresse IP de destination
TELC Numéro de téléphone de l’appelant
TAC Nom ou adresse IP source
DISP Message affichable
QOS Choix de la QoS (Quality Of Services)
Expression Explication
. Un caractère unique
<> Place la séquence dans une variable
[abc] Le caractère a, b ou c
[x-y] Un caractère entre x et y
[^abc] Un caractère différent de a, b et c
* Le caractère précédent répété zéro ou plusieurs fois
+ Le caractère précédent répété une ou plusieurs fois
? Le caractère précédent répété zéro ou une fois
\ Transforme le caractère suivant en caractère littéral
e) Configuration de la passerelle
L’installation d’une passerelle se fait en 2 étapes. Tout d’abord, on connecte la passerelle sur
le lien et on la configure de telle manière qu’elle soit complètement transparente :
France
Telecom
1 lien
ISDN
TE
NT 1 lien
PBX
Passerelle
Passerelle transparente
transparente
Lors d’une installation complète, la procédure est la suivante :
Page 109 sur 248

- Connexion de la passerelle au LAN, au réseau téléphonique et mise sous tension.
- Configuration des paramètres LAN
- Configuration des paramètres de connexion (mot de passe et délai d’inactivité avant

déconnexion)
- Configuration du réseau (Nom d’hôte, etc.)
- Configuration du plan d’appel.
- Configuration du SIP et des paramètres audio
- Configuration de l’Authentification
- Configuration de l’Enregistrement
- Configuration des ports DSL
- Configuration du pointeur vers la documentation
- Sauvegardes des modifications
- Archivage de la configuration de la passerelle
Configuration des paramètres LAN

Si un serveur DHCP est disponible, la passerelle va automatique récupéré une adresse IP. Si
ce n’est pas le cas, où si l’adresse IP est inconnue, il est nécessaire de se connecter à
l’interface série de la passerelle, avec la configuration suivante :
Vitesse : 115200 baud
Bits de données : 8
Parité : aucune
Bit d’arrêt : 1
Contrôle de flux : aucun
Une fois connecté, en appuyant sur la touche entrée, on obtient un message d’invite :
Username :
Il est alors nécessaire de rentrer le nom d’utilisateur « admin » et le mot de passe « admin »
par défauts.
Pour afficher l’adresse IP actuelle, il suffit de taper :

Show lan.ip
Il est possible de modifier la configuration actuelle avec la syntaxe suivante :

Set lan.use_dhcp=0
Set lan.ip=aaa.bbb.ccc.ddd
Set lan.subnet=eee.fff.ggg.hhh
Set lan.gateway=iii.jjj.kkk.lll
Save
Reboot System
Page 110 sur 248

Configuration des paramètres de connexion

La suite de l’installation peut se faire en utilisant l’interface Web. Pour cela, il suffit de taper
l’adresse IP de la passerelle dans un navigateur Internet :
Et on obtient ainsi la page de connexion :
Le nom d’utilisateur et le mot de passe sont identiques à ceux utilisés pour la connexion sur le
port série (admin/admin).
Page 111 sur 248

En cliquant sur le lien « Users » dans le menu de gauche, il est possible de configurer le temps
d’inactivité avant déconnexion et le mot de passe de l’utilisateur « admin » :
Page 112 sur 248

Le délai d’inactivité est configuré par défaut à 240 secondes. Le maximum que l’on puisse
mettre est 7200 secondes, soit 2 heures. Ce délai d’inactivité ne concerne que les connexions
sur l’interface Web et pas les autres types de connexions (série, telnet, etc.)
Configuration du réseau (Nom d’hôte, etc.)

En cliquant sur LAN dans le menu de gauche, on obtient la configuration réseau de la
passerelle :
Page 113 sur 248

Il est alors possible de donner un nom à la passerelle (Host Name), de vérifier la configuration
réseau et de choisir la vitesse du port réseau (10 ou 100 Mbits)
Le reste de l’installation est spécifique à chaque client. La configuration en mode transparent,

la configuration standard et les spécifications techniques (en anglais) de la passerelle
Vegastream 100 sont disponibles en annexe.
Il faut signaler que la passerelle régénère les différentes sonneries et est configurée de base
avec les sonneries américaines. Il est donc nécessaire de configurer la passerelle avec les
sonneries française pour qu’elle soit complètement transparente pour les utilisateurs finaux.
Les fréquences et les durées des sonneries françaises sont également disponibles en annexe.
2) Firewall Ingate
a) Introduction
Dès le moment où nous connectons des équipements à Internet, il est nécessaire de les
protéger des pirates informatiques. Pour cela nous utilisons des pare-feux Ingate, spécialisés
dans le protocole SIP.
Page 114 sur 248

Ingate est une entreprise Suédoise. Elle est la seule à proposer une gamme complète de pare-
feux compatibles avec le protocole SIP :
Ingate 1200 1400 1800 1880
4-8 10/100 4-16 10/100
Nombre de
2 10/100 4 10/100
ports
0-2 1000 0-2 1000
Utilisateurs
400 1000 4000 8000
Max.
Communication
50 180 400 800
Max.
Image
Il est alors possible de sécuriser la connexion Internet utilisée :
Page 115 sur 248

France
Internet
Telecom
VoIP
ISDN
Passerelle VoIP
Firewall SIP
Appels Entrants Appels Sortants
PABX
Téléphonie
classique
Ingate
Ingate
b) Configuration
La spécificité des firewalls Ingate est leurs capacités à gérer le protocole SIP. Nous nous
attarderons uniquement sur la configuration de ce module.
Prenons par exemple l’architecture suivante :
Page 116 sur 248

Internet
Routeur
119.15.17.1
Eth1 Serveur DNS
119.15.17.2 Externe
195.15.17.12
DMZ
Eth2
119.15.17.9
Eth0
172.22.1.1
LAN
Serveur DNS
Interne 172.22.1.101
172.22.1.3
172.22.1.102
Firewall Ingate
Exemple Firewall
Exemple Ingate
Comme pour les passerelles Vegastream, la configuration se fait à l’aide d’une interface Web.
Tout d’abord, il faut s’assurer que la passerelle par défaut et que le serveur DNS sont
correctement rentré dans la page « Basic Configuration ». Cela est en effet nécessaire pour
que les requêtes SIP puissent être gérées :
Page 117 sur 248

Il faut ensuite activer le module SIP du firewall dans la page « Basic » :
Sur la page « Filtering », les requêtes venant du réseau interne doivent être autorisées. Pour
cela on créer une règle proxy. Toutes les autres requêtes ne doivent être autorisées que si elles
en direction du domaine local. Pour cela, on configure le paramètres « Default policy for
requests » sur « Local only » :
Page 118 sur 248

Il faut donc ensuite spécifier ce domaine local. Cela se fait dans la page « Registra rand
Users ». Générallement, le domaine local SIP correspond au nom de domaine internet de
l’entreprise. Toutefois certains équipements utilisent l’adresse IP à la place du nom de
domaine. Il est donc conseiller de spécifier les deux comme « Locally handled domain » :
Pour autoriser les clients SIP interne à recevoir des requêtes SIP, ils doivent être enregistré. Il
faut pour cela rajouter une ligne par domaine ; tous les utilisateurs de chaque domaine sont
autorisés à s’enregistrer. Cela est possible car l’authentification SIP n’est pas activée par
défaut. Comme le montre l’image ci-dessous nous n’utilisons que les utilisateurs du réseau
interne à s’enregistrer :
Page 119 sur 248

Il suffit d’appliquer la configuration sur la page « Save/load configuration » pour que le

Firewall gère le trafic SIP.
Dans la solution globale que nous envisageons, nous ne souhaitons pas utiliser les firewalls
Ingate comme serveur d’enregistrement, mais uniquement comme proxy SIP. En effet, nous
utilisons un serveur SIP externe.
Dans la page « Filtering », toutes les requêtes doivent donc être gérée car le firewall n’a pas
de « Locally handled domains ». Si une autre option est sectionnée, aucune requête ne va être
traitée.
Sur la page « Routing », il est nécessaire de spécifier l’adresse IP du serveur SIP que nous
souhaitons utiliser.
Page 120 sur 248

Sur la page « Registrar and Users », nous pouvons spécifier les utilisateurs autorisés à utiliser
le SIP. Si l’authentification n’est pas utilisée, on peut utiliser un astérisque.
Il est toutefois possible d’effectuer une authentification au niveau du proxy mais cela
nécessite de rentrer tous les utilisateurs :
Cela semble irréalisable dès que le nombre d’utilisateur dépasse la dizaine…
3) IPBX Asterisk
a) Introduction
Asterisk est un logiciel libre d’IP PBX. Il permet de mettre en œuvre un standard
téléphonique pour la téléphonie et le voix sur IP. Les solutions de téléphonie basées sur
Asterisk offrent non seulement les fonctionnalités classiques d’un standard téléphonique mais
aussi des fonctionnalités avancées qui sont possibles grâce à l’intégration de la téléphonie et
de l’informatique :
- VoiceMail
- Conférences téléphoniques à plus de deux
Page 121 sur 248

- Mise en attente, transferts, routages intelligents
- Requêtes sur bases de données
- Enregistrement des paramètres détaillés des appels…
La liste complète des fonctionnalités est disponible en annexe. L’IP PBX Asterisk permet
donc d’étendre les fonctionnalités d’un PBX classique :
France
Internet
Telecom
VoIP IP PBX Asterisk
ISDN
Firewall SIP
Passerelle VoIP Chez le client
ou hébergé
Appels Entrants Appels Sortants LAN
PABX
IP PBX Asterisk
Téléphonie
classique
Asterisk
Asterisk
b) Architecture
Globale
L’architecture d’Asterisk est fondamentalement très simple, mais différentes des principaux
produits téléphoniques. Asterisk agit essentiellement comme le lien entre les technologies
téléphoniques et les applications téléphoniques, permettant ainsi un environnement mixte. Les
technologies téléphoniques sont composées des services VoIP comme SIP, H.323, AIX et
MGCP mais également les technologies TDM traditionnelles : T1, ISDN PRI, POTS
analogique, PSTN, Basic Rate ISDN (BRI), etc.
Le noyau
Le noyau d’Asterisk est composé de différents éléments qui jouent chacun un rôle critique
dans les opérations du logiciel. Quand Asterisk est démarré pour la première fois, la gestion
Page 122 sur 248

dynamique des modules charge et initialise chacun des drivers (drivers des lignes, des flux,
des applications et des fichiers) et les lient à l’API interne correspondant.
A ce moment, le noyau PBX de commutation peut accepter des appels. Le module

d’exécution est alors utilisé pour réaliser les actions en fonctions du plan d’appel (faire sonner
un téléphone, se connecter à la boîte vocale, etc.).
Le noyau permet également une gestion des entrées et des sorties ce qui permet aux
applications et aux drivers de pouvoir utiliser les différents codecs.
Annuaire
Conférence VoiceMail
API Application Asterisk

API Gestion flux Audio & Vidéo
GSM G.723
CODECS
API Gestion des fichiers

Gestion Entrées/
G.723 GSM
Sorties
Module d’exécution
PCM Gestion dynamique WAV

des modules
Noyau PBX :
commutation
MP3 MP3
API gestion des lignes
ISDN H.323 Zaptel
SIP Modem
Architecture
Architecture d’Asterisk
d’Asterisk
Le système de fichier
Asterisk est un programme. Et comme tout programme, il utilise des fichiers qui sont stockés
dans différents répertoires :
/etc/asterisk
Ce répertoire contient tous les fichiers de configuration d’Asterisk.
/usr/sbin
Ce répertoire d’exécutable système contient la version actuelle des exécutables d’Asterisk
ainsi que les différents script, ce qui inclut asterisk, astman, astgenkey et safe_asterisk.
Page 123 sur 248

/usr/lib/asterisk
Ce répertoire contient les différents éléments que nous venons de spécifier dans l’architecture
/usr/lib/asterisk/modules
Ce répertoire contient les modules pour les applications, les drivers, les codecs, les formats de
fichiers, etc.
/usr/include/asterisk
Ce répertoire contient les fichiers d’en-tête permettant de compiler l’application Asterisk et
les différents modules
/var/lib/asterisk
Ce répertoire contient les différentes données utilisées par Asterisk :
- Les différents scripts AGI utilisés dans le plan d’appel.
- La base de données d’Asterisk (astdb)
- Les images
- Les clés de cryptage
- Les musiques d’attente
- Les différents fichiers audio
/var/run
Ce répertoire contient :
- L’identifiant principal du processus Asterisk (asterisk.pid)
- Un « pipe » nommé permettant des opérations à distance (asterisk.ctl)
/var/spool/asterisk
Ce répertoire contient :
- Les informations des appels sortants
- Les informations pour les applications
- Le contenu des boîtes vocales
Dénomination
Pour comprendre Asterisk, il est nécessaire de connaître la convention utilisée pour le nom
des canaux. La syntaxe est la suivante :
Page 124 sur 248

<Technologie>/<chaîne de l’appel>
<Technologie> représente le type d’interface que nous utilisons (SIP, Zap, MGCP, IAX, etc.)
<chaîne de l’appel> est une chaîne de caractère qui représente la destination désirée.
Canaux TDM Zaptel

Les cartes Zaptel sont des cartes analogiques et numériques. La syntaxe pour les utiliser est la
suivante :
Zap/[g]<identifiant>[c][r<cadence>]-<instance>
<identifiant> est un chiffre représentant le canal physique que l’on souhaite utiliser. S’il est
préfixé par la lettre g, cela désigne un groupe.
La lettre c signale une demande de confirmation
La lettre r, suivi d’un nombre permet d’utiliser une sonnerie différente (entre 1 et 4) pour cet
appel.
<instance> est valable uniquement pour les appels entrant. Cela permet d’identifier un appel.
En effet, plusieurs appels peuvent être effectués en même temps sur le même canal.
SIP
Cette partie est celle qui nous concerne le plus. La syntaxe est différente s’il s’agit d’un appel
entrant ou sortant.
Appel sortant
La syntaxe est la suivante :

SIP/[<extension>@]<serveur>[:<numéro de port>]
<serveur> est le nom ou l’adresse IP du serveur appelé
<numéro de port> est le numéro du port utilisé pour l’appel (le port standard pour le SIP est
5060)
<extension> est le contact à appeler (optionnel)
Appel entrant
La syntaxe dans le cas d’un appel entrant est la suivante :

SIP/<serveur>-<id>
<serveur> est le nom ou l’adresse IP du serveur appelant
<id> est le numéro unique de la communication
IAX, H.323, MGCP, etc.

IAX (Inter-Asterisk eXchange) est un protocole d’interconnexion des serveurs Asterisk.
Page 125 sur 248

La syntaxe pour les autres protocoles utilise le même principe.
c) Configuration
Plan d’appel
Le plan d’appel est la partie la plus importante. En effet, c’est lui qui va diriger un appel
entrant vers la bonne destination. Les applications comme la messagerie, les conférences, les
menus automatiques sont eux aussi géré par le plan d’appel.
Les contextes et les extensions

Le plan d’appel est séparé en différents contextes. Un contexte possède un nom unique et
permet de différencier différents utilisateurs ou services. Chaque contexte possède ainsi ses
règles et ses options.
Un contexte est composé de plusieurs extensions. Une extension peut être un utilisateur, un
téléphone ou un service. Comme le montre le contexte suivant :
Extension Description
101 Fred
102 Pierre
103 Vérification de la messagerie
104 Service de conférence
0 Standardiste
Dans cet exemple, les deux premières extensions (101 et 102) sont associé à des utilisateurs et
donc à un téléphone. La troisième extension (103) est le service qui permet de consulter ses
messages. La quatrième extension (104) est associée au service de conférence. Enfin,
l’extension 0 permet de contacter le standard.
Les menus
Avec ce principe, il est très facile de réaliser des standards automatiques :

Extension Description
S Message de bienvenu et instructions
1 Service commercial
2 Service Technique
3 Direction
# Raccrocher
L’extension « s » est l’extension de début (Start). C’est vers elle qu’un utilisateur est transféré
quand un appel arrive. Cette extension va lire un message de bienvenu et les indications du
menu : « Appuyer sur 1 pour le service commercial, sur 2 pour le service technique et sur 3
pour la direction ». Chaque option du menu est en fait une extension qu’il est possible
d’appeler.
Modèles d’équivalence
Plutôt que d’utiliser des numéros d’extension fixe, il est possible d’utiliser des modèles
d’équivalence. Un chiffre ou une série de chiffre est ainsi remplacé par son équivalence. Un
Page 126 sur 248

modèle d’équivalence doit être précédé d’un underscore et est composé des caractères
suivants :
Caractère Description
X Un chiffre entre 0 et 9
Z Un chiffre entre 1 et 9
N Un chiffre entre 2 et 9
[14-6] Le chiffre 1, 4, 5 ou 6
. Une suite de chiffre quelconque
Ainsi le modèle d’équivalent représente un numéro commençant par 01 :

_01.
Définition des extensions

Contrairement à un PBX traditionnel où les extensions sont liées à un téléphone, un menu ou
autre chose, les extensions Asterisk sont liées à des applications (avec des arguments).
Chaque étape de l’exécution d’une extension possède une priorité. Quand une extension est
appelée, chaque priorité est exécuté dans l’ordre, jusqu’à ce que l’appel soit raccroché, qu’une
application retourne un code de fin (-1) ou que l’appel soit dirigé vers une autre extension.
Chaque étape d’une extension suit la syntaxe suivante :

Exten=><extension>,<priorité>,<application>,[(<arguments>)]
Si nous considérons l’extension suivante :

Exten=>100,1,Wait(1)
Exten=>100,2,Answer
Exten=>100,3,Playback(fichierson)
Exten=>100,4,Hangup
Quand un appel arrive à l’extension 100, Asterisk va attendre une seconde (Wait(1)) et ensuite
va répondre à l’appel (Answer). Troisièmement, Asterisk va lire un fichier son appelé
« fichierson » et va raccrocher à la fin de la lecture.
Pour appeler un téléphone, on utilise l’application « Dial ». Cette application prend un

argument qui est la période durant laquelle le téléphone va sonner avant qu’Asterisk ne passe
à la priorité suivante :
Exten=>100,1,Dial(SIP/Fred,10)
Cet exemple va faire sonner le téléphone SIP de l’utilisateur Fred pendant 10 secondes. Si
l’utilisateur Fred décroche avant les 10 secondes, la communication est établie, sinon Asterisk
met fin à cette communication.
4) Terminaux SIP
Un IP PBX apporte donc de nouvelles fonctionnalités et est capable de remplacer un PBX
classique. Mais dans ce cas, il est souvent nécessaire de remplacer les téléphones par des
téléphones IP.
Il est alors possible d’avoir une solution entièrement IP et de supprimer la téléphonie

classique :
Page 127 sur 248

France
Internet
Telecom
VoIP
ISDN
Appels Sortants Firewall SIP

Passerelle VoIP
Appels Entrants LAN
Téléphones IP
IP PBX Asterisk
Téléphonie
classique
Téléphones
Téléphones IP
IP
Les téléphones IP apportent eux aussi de nouvelles fonctionnalités. Les deux gammes
actuellement proposées par BSNetwork sont Snom et Cisco
a) Snom
Introduction
Snom est une entreprise allemande créée en 1999 et spécialisée dans les téléphones IP. Ses
téléphones sont considérés comme la référence des téléphones IP bien qu’ils présentent de
nombreuses imperfections :
SNOM 105 SNOM 200 SNOM 220
D’un point de vue matériel tout d’abord, il est difficile de raccrocher correctement (le
combiné se positionne mal) et les touches ne sont pas agréables. Les produits Snom possèdent
également des avantages : ils intègrent pour la plupart un Switch réseaux ce qui permet de
Page 128 sur 248

connecter dessus un ordinateur et il est facile de connecter un casque et/ou un micro grâce a
des connectiques jack :
LAN Microphone
Haut-Parleur/
Alimentation Casque
48 V
Ordinateur
Téléphone
Téléphone Snom
Snom 105
105
D’un point de vue logiciel, outre la traduction française qui n’est pas finalisée, cette gamme
de téléphone souffre de nombreux bugs. Chaque ajout d’une nouvelle fonctionnalité est suivi
d’un ou plusieurs correctifs, comme le montre le nombre de mise à jour mensuelle :
Page 129 sur 248

Nombre de mise à jour par mois

pour le SNOM 200
18
16
14
12
10
8
6
4
2
0 fé 4
dé 3
ao 03
ao 04
m -04
ju 3
4
m 4
no 3
4
av 4
se 03
se 04
ju 4
ja 3
oc 3
oc 4
-0
0
r-0
-0
-0
t-0
t-0
0
-0
-0
-0
0
v-
il-
il-
s-
-
-
c-
nv
vr
in
in
ût
ût
pt
pt
ai
ju
ar
ju
Configuration
Premier démarrage
Lors du premier démarrage d’un téléphone Snom, il est nécessaire de le configurer. Cela se
fait en différentes étapes :
Langue
Tout d’abord, il est nécessaire de sélectionner la langue des menus :
Pour cela, il faut utiliser les touches « » et « », et valider par la touche « »
Configuration du DHCP
Si un serveur DHCP est disponible sur le réseau, le téléphone est capable de l’utiliser.
Configuration Réseau
Si ce n’est pas le cas, il faut spécifier l’adresse IP à utiliser :
Page 130 sur 248

Masque de sous réseau
De la même manière, il faut spécifier le masque de sous réseau :
Passerelle par défaut
Il faut également spécifier la passerelle par défaut :
Serveur DNS
Enfin, il faut rentrer le serveur DNS :
La sonnerie
Il est ensuite nécessaire de sélectionner une sonnerie :
Fuseau horaire
La dernière étape consiste à sélectionner le fuseau horaire. La ville pour le fuseau horaire
français est Nice …
Page 131 sur 248

Le reste de la configuration peut se faire avec l’interface Web en utilisant l’adresse IP que
l’on a spécifié.
Serveur de configuration
Plutôt que d’utiliser l’interface Web, il est possible d’utiliser un serveur pour une
configuration de masse. Dans ce cas, le téléphone essayera de récupérer un fichier de
configuration sur ce serveur.
Lecture des paramètres en

mémoire
Cela permet au
Configuration du réseau et du DNS
téléphone de se
connecter à Internet
Charge la configuration du
« setting_server »
Modification de la configuration
actuelle :
- adresse IP
- masque de sous réseau
- passerelle par défaut
- nom du téléphone
- domaine et les serveurs DNS
- décalage et le serveur de temps
- activation du DHCP ou non
Démarrage
Démarrage d’un
d’un téléphone
téléphone Snom
Snom
La configuration doit se télécharger sur un serveur Web. L’adresse de configuration est donc
une adresse URL. Cette adresse peut être configurée sur l’interface Web (« setting_server »
sur la page « advanced ») ou directement grâce au DHCP avec les options 66 et 67.
Chaque téléphone a sa propre configuration. Afin de différencier un téléphone d’un autre, il

est possible de spécifier l’adresse MAC du téléphone lors de la demande de configuration.
Ci-dessous, un exemple de configuration du « setting_server » :

Setting_server : http://sip.bsnetwork.fr/conf.php?mac={MAC}
Page 132 sur 248

Le champ « {MAC} » sera automatique remplacé par l’adresse MAC du téléphone, par le
téléphone.
Le fichier ainsi récupéré doit avoir la forme suivante :

<html>
<pre>
# fichier de configuration
#
phone_name: testphone
dns_domain: bsnetwork.fr
dns_server1!: 192.168.6.10
</pre>
<html>
Le caractère « ! » après un nom de variable signifie que ce paramètre peut être modifié par
l’utilisateur, alors que le caractère « & » signifie qu’il est en lecture seul (par défaut).
De cette manière, il est possible de gérer la configuration de tous les téléphones Snom depuis
un serveur Web.
b) Cisco
Introduction
Cisco n’est plus à présenter. L’entreprise s’est tout d’abord orientée vers un protocole et une
solution VoIP propriétaire. Depuis peu, ses téléphones sont disponibles en version SIP. Même
s’ils n’ont pas encore toutes les fonctionnalités que propose Snom et qu’ils sont plus chères,
ils sont plus agréable d’utilisation :
7902
7940
7960+7914
7960
7912
7905 7920 7970
Page 133 sur 248

Grâce à leurs écrans et à leurs menus contextuelles, toutes les options et services sont
facilement accessibles et utilisables ; ce qui est agréable pour l’utilisateur. De même, la
qualité sonore est supérieure aux téléphones Snom :
Lignes ou appels
Combiné Ecran LCD rapides
Ajustement de
l’inclinaison
Boutons
d’onglets
Services et
informations
Gestion du
volume
et du son
Ascenseur
Clavier vertical
numérique
Téléphone
Téléphone Cisco
Cisco 7960
7960
Configuration
Les téléphones Cisco ne disposent pas d’une interface Web pour la configuration. Il est
toutefois possible de les configurer directement grâce à des menus interactifs ou grâce à un
serveur trivial FTP (TFTP).
Le démarrage d’un téléphone Cisco se fait de la manière suivante :
Page 134 sur 248

Chargement de l’image Firmware
Si le téléphone est
Apprentissage du VLAN connecté à un switch
Catalyst, il peut
obtenir son VLAN
Obtention d’une adresse IP Si le téléphone utilise

le DHCP.
Connexion au serveur TFTP et

téléchargement des fichiers :
Permet au téléphone
OS79XX.TXT de savoir quel
firmware il doit utiliser
Contient les
SIPDefault.cnf paramètres communs
à tous les téléphones
Contient les
SIP<mac>.cnf paramètres pour le
téléphone ayant
l’adresse mac <mac>
RINGLIST.DAT Contient la liste des

sonneries disponibles
Dialplan.xml Contient les

informations d’appel
Contient les
Vérification de la version du
paramètres pour le
firmware
téléphone ayant
l’adresse mac <mac>
Téléchargement
d’une nouvelle
version
Redémarrage
Démarrage
Démarrage d’un
d’un téléphone
téléphone Cisco
Cisco
Page 135 sur 248

DHCP
Si un serveur DHCP est utilisé pour le téléphone Cisco, les options suivantes peuvent être
utilisées :
- option 1 : masque de sous réseau
- option 3 : passerelle par défaut
- option 6 : serveur de nom
- option 15 : nom de domaine
- option 50 : adresse IP
- option 66 : serveur TFTP pour la configuration
Les fichiers de configuration

Un exemple de fichiers de configuration est disponible en annexe.
5) Opérateur Primus Telecom

A ce niveau, il reste deux problèmes : comment supprimer le lien ISDN France Telecom pour
les appels entrant et comment des appels sortant sur Internet peuvent-ils aboutir vers un
téléphone fixe ou portable ? Un opérateur téléphonique capable de gérer le VoIP permet de
répondre à ces deux questions. Primus Telecom est un de ces opérateurs.
Fondé en 1994, Primus possède désormais une infrastructure permettant de faire aboutir un
appel téléphonique aux meilleurs prix. Il permet donc de faire le lien entre la téléphonie
classique et la VoIP. De même, il est capable de rediriger les appels entrants vers le firewall
SIP. Il est alors possible de supprimer complètement la téléphonie classique dans l’entreprise :
Page 136 sur 248

France
Internet
Telecom
VoIP
ISDN
Primus
Telecom
Appels Appels
Entrants Sortants Firewall SIP
LAN
Téléphones IP
IP PBX Asterisk
Primus
Primus Telecom
Telecom
Au 13 octobre 2004, les tarifs proposés par BSNetwork, en partenariat avec Primus Telecom,
sont les suivants :
France UE, USA et Canada Reste du monde
Vers Fixe 1,5 ct/min 3,5 ct/min 25 ct/min
Vers Mobile 18 ct/min 25 ct/min 25 ct/min
a) Primus et Asterisk
L’objectif est donc d’utiliser Primus Telecom pour tous les appels en provenance ou à
destination de la téléphonie classique. Afin que n’importe qui ne puisse pas utiliser leurs
serveurs, Primus a mis en place un système d’authentification et d’enregistrement. Notre
système, basé sur Asterisk doit donc s’enregistrer et s’authentifier quand cela est nécessaire
Dans sip.conf
Le fichier « sip.conf » contient la configuration des différents périphériques SIP. Primus
utilise le protocole SIP donc c’est dans ce fichier que va se trouver la plus grande partie de la
configuration.
Tout d’abord, les numéros de téléphone que nous utilisons doivent être enregistrés chez
Primus. Chaque numéro est associé à un mot de passe. La syntaxe pour réaliser cela est la
suivante :
register => numéro:motdepasse@francevoip.com
Ensuite il faut préciser pour chaque numéro de téléphone les informations qui seront utilisés
pour l’authentification. Voici un exemple :
[primus_bsnetwork]
type=peer
Page 137 sur 248

host=francevoip.com
username=numéro
secret=motdepasse
fromdomain=francevoip.com
Voici un exemple complet d’un fichier « sip.conf » pour l’utilisation des serveurs Primus :
register => 33172770210:motdepasse@francevoip.com
register => 33172770215:motdepasse@francevoip.com
[primus_bsnetwork]
type=peer
host=francevoip.com
username=33172770210
secret=motdepasse
[fred_bsnetwork]
type=friend
host=dynamic
context=bsnetwork
secret=motdepasse
callerid=Fred <215>
username=215
subscribecontext=bsnetwork
mailbox=215@bsnetwork
qualify=500
Dans extensions.conf
Ensuite, pour chaque appel sortant, il faut spécifier quel numéro on va utiliser. Pour cela, il
faut spécifier l’identifiant de l’appelant avec « SetCallerID ».
La syntaxe complète pour passer un appel depuis le numéro 0172770210 est la suivante :
[bsnetwork]
exten=>_0.,1,SetCallerID(33171770210 <33172770210>)
exten=>_0.,2,Dial(SIP/${EXTEN}@primus_bsnetwork)
exten=>_0.,3,Hangup
b) Primus et Vegatream
Dans un premier temps, il peut être intéressant d’utiliser Primus pour faire baisser les factures
téléphoniques. Dans ce cas, nous n’utilisons pas de serveurs Asterisk. L’enregistrement et
l’authentification se fait donc au niveau de la passerelle Vegastream
Page 138 sur 248

Primus
Telecom
France
Internet
Telecom
VoIP
ISDN
Enregistrement
Authentification
Passerelle VoIP
Appels Entrants Appels Sortants Firewall SIP
PABX
Téléphonie
classique
Primus
Primus et
et Vegastream
Vegastream
Primus utilise, pour l’authentification, un serveur proxy SER (Sip Express Router). Il
compare l’adresse E164 (internationale) de l’appelant contenue dans le champ "From" avec
celle contenue dans la base de donnée du proxy SER. L'adresse E164 transmise par la Vega
est celle qui lui est transmise par le PABX, au format National "
sip:0172770240@francevoip.com". Le format attendu est international
"sip:33172770240@francevoip.com" ; ainsi le paquet SIP suivant va être refusé :
195.214.56.210:5060 -> 195.214.56.194:5060
INVITE sip:0155232578@francevoip.com:5060 SIP/2.0
Via: SIP/2.0/UDP 195.214.56.210:5060;branch=z9hG4bK-vega1-000A-2D73A3F0-1846-475C8904
From: <sip:0172770240@francevoip.com>;tag=0011-0C34-CB0E0185
To: <sip:0155232578@francevoip.com>
Max-Forwards: 70
Call-ID: 0010-000C-7D99E6E8-0@195.214.56.210
CSeq: 762553329 INVITE
Contact: <sip:0172770240@195.214.56.210:5060;maddr=195.214.56.210>
Authorization: Digest username="33172770240", realm="francevoip.com",
nonce="4149901cd7e8fa13948b30c3ffefddb525ddd157",
uri="sip:0155232578@francevoip.com:5060", response="34c9d052b04ab7ad24767212dcbc3fe0"
Supported: replaces
Allow: INVITE,ACK,BYE,CANCEL,INFO,NOTIFY,OPTIONS,REFER
Accept-Language: en
User-Agent: VEGA100/08.02.06xS016
Content-Length: 275.
v=0
o=Vega50 13 1 IN IP4 195.214.56.210
Page 139 sur 248

s=Sip Call
t=0 0
m=audio 10024 RTP/AVP 18 4 8 0 96.
c=IN IP4 195.214.56.210
a=rtpmap:18 G729/8000
a=fmtp:96 0-15,16
a=sendrecv
Le numéro contenu dans le champ "from" est celui de l'appelant. Si le PABX est configuré
pour donner le numéro en format national, la Vega retransmettra ce numéro en format
national dans le champ "from".
Il y a donc deux possibilités :
- Modifier la configuration du PABX pour qu’il fournisse le numéro au format

international
- Modifier le numéro de téléphone de l'appelant dans le Dialplan de la Vega, avec le

champ TELC:
Ainsi en créant le DialPlan suivant, on force le numéro de l’appelant à « 33172770240 »

Source : IF:02,TEL:<.*>
Destination : IF:99,TEL:<1>,TELC:33172770240
De la même manière, il est possible de créer un DialPlan générique pour transférer le bon
numéro d’appelant :
Source : IF:02,TEL:<.*>,TELC:0<.*>
Destination : IF:99,TEL:<1>,TELC:33<2>
Les deux méthodes ont été testées en collaboration avec Primus et fonctionnent correctement.
Page 140 sur 248

X. Solution hébergée
1) Introduction à la solution
Une infrastructure VoIP n’est pas simple à gérer. C’est pourquoi BSNetwork propose de gérer
les système téléphoniques grâce a une solution hébergée : IP centrex.
L'IP Centrex substitue les équipements télécoms installés sur le site de l'entreprise par des
services opérés et fournis à distance par l'opérateur. L’entreprise réduit donc
considérablement sa charge d’investissement et de maintenance. En externalisant
complètement sa fonction télécom, elle gagne en productivité. Enfin, de puissants services à
valeur ajoutée deviennent accessibles à moindre coût et apportent de nouvelles sources de
compétitivité.
L’objectif est que toutes les entités de l’entreprise (siège social, autres établissements,
collaborateurs nomades, télé-travailleurs), quelle que soit leur dispersion géographique,
bénéficient du même niveau de service et de tarification dans une architecture souple et
économiquement avantageuse. Ces économies sont augmentées par le fait que les serveurs qui
hébergent le PBX (virtuel) peuvent être mutualisés.
J’ai travaillé sur cette solution d’IP-centrex avec 2 pôles directeurs : stabilité et simplicité.
a) Stabilité
La stabilité tout d’abord la pérennité de la solution. En effet, une telle solution doit être
pérenne dans le temps : l’architecture qui est décidée au début ne peux plus être changée. La
stabilité concerne également la fiabilité du service. En effet, la téléphonie actuelle dispose
d’une disponibilité de 99,99 %. Mon objectif est d’atteindre une disponibilité de 99,9 % avec
la solution proposée. La défaillance d’un matériel doit être tout de suite identifiée et une
solution apportée sans que cela perturbe le service.
b) Simplicité
La simplicité doit se faire à différents niveaux. Tout d’abord au niveau des utilisateurs, l’accès
aux services proposés doit être le plus simple possible, voir transparent quand cela est
possible. Au niveau des administrateurs dans les entreprises, ils doivent pouvoir accéder aux
informations qui les intéressent de manière simple. Par ailleurs, ils doivent pouvoir agir sur
ces informations (ajout d’un téléphone, configuration d’un standard, etc.) ce qui était, pour
des raisons de complexité technique, impossible avec un PBX traditionnel. Enfin la solution
doit être simple à administrer pour les employés de BSNetwork…
2) Introduction à la Haute Disponibilité

Il est très difficile de garantir la stabilité d’un système. Plutôt que de passer beaucoup de
temps en étude et en analyse (sans garantie du résultat) pour faire un système qui ne tombe
jamais en panne, il est plus simple de pallier à la faillibilité des systèmes complexes, qu'ils
soient matériels ou logiciels (les deux étant désormais indissociables). En effet, plutôt que de
Page 141 sur 248

chercher à rendre ces systèmes fiables, on peut inverser la démarche et intégrer à la source la
notion de panne dans l'étude de ces systèmes : si l'on peut prévoir la panne d'un composant
matériel ou logiciel, on peut alors l'anticiper et mettre en oeuvre une solution de substitution.
On parle alors de disponibilité du service, voire de Haute Disponibilité selon la nature de
l'architecture mise en place.
Il existe trois grandes familles de disponibilité :
• Disponibilité des données : même si le système n'est pas critique et peut supporter un
arrêt de service à durée variable, il est généralement inhabituel de se satisfaire de la
perte de données. Dans ce cas précis, toutes les techniques utilisées convergent pour
garantir l'intégrité des données
• Disponibilité des services : dans le contexte d'un service critique rendu dans le cadre
d'une entreprise (serveur de fichiers ou mail) ou vis à vis d'une clientèle (site
marchand), une panne occasionnant un arrêt du service peut causer un tort
considérable entraînant une perte de productivité voire une perte de confiance du
client. Dans tous les cas, cela peut coûter à cours ou moyen terme beaucoup d'argent.
On base la démarche sur la disponibilité des données pour ensuite fiabiliser par
différentes techniques la continuité du service ;
• Tolérance aux désastres : tremblements de terre, attentats, incendies sont des

évènements certes inattendus mais aussi terriblement dévastateurs à la fois pour les
biens, les personnes et, pour ce qui nous intéresse, les données et les services. Si ces
derniers ne sont pas géographiquement éloignés à bonne distance les uns des autres, ce
risque est réel : cela peut paraître alarmiste et ne vaut peut être pas pour la petite PME
locale mais devient un vrai problème pour les sociétés de taille conséquente qui
brassent d'énormes flux d'informations et se doivent de fournir un service continu à
leur clientèle (comme un opérateur téléphonique).
a) Fiabilité versus disponibilité
Pour appréhender la notion même de Haute Disponibilité, il nous faut d'abord aborder les
différences qui existent entre la fiabilité d'un système et sa disponibilité.
La fiabilité est un attribut permettant de mesurer la continuité d'un service en l'absence de

panne. Les constructeurs fournissent généralement une estimation statistique de cette valeur
pour leurs équipements : on parle alors de MTBF (pour Mean Time Between Failure). Un
MTBF fort donne une indication précieuse sur la capacité d'un composant à ne pas tomber en
panne.
Dans le cas d'un système complexe (que l'on peut décomposer en un certain nombre de
composants matériels ou logiciels), on va alors parler de MTTF pour Mean Time To Failure,
soit le temps moyen passé jusqu'à l'arrêt de service consécutif à la panne d'un composant ou
d'un logiciel.
L'attribut de disponibilité est plus difficile à calculer car il englobe la capacité du système
complexe à réagir correctement en cas de panne pour redémarrer le service le plus rapidement
possible. Il est alors nécessaire de quantifier l'intervalle moyen de temps ou le service est
Page 142 sur 248

indisponible avant son rétablissement : on utilise l'acronyme MTTR (Mean Time To Repair)
pour représenter cette valeur.
La formule qui permet de calculer le taux de disponibilité relative à un système est la suivante
:
MTTF
disponibilité 
MTTF  MTTR
Un système qui aspire à une forte disponibilité se doit d'avoir soit un MTTF fort, soit un
MTTR faible.
Une autre approche, plus pratique, consiste à mesurer la période de temps ou le service n'est
plus rendu pour évaluer le niveau de disponibilité. C'est la méthode la plus souvent utilisée
même si elle ne tient pas compte de la fréquence des pannes mais plutôt de leur durée.
Le calcul se fait le plus souvent sur une année calendaire. Plus le pourcentage de disponibilité
du service est fort, plus nous pouvons parler de Haute Disponibilité.
Il est assez facile de qualifier le niveau de Haute Disponibilité d'un service à partir de la durée
d'arrêt cumulée en utilisant le principe normalisé des « 9 » (en dessous de 3 neuf, il n'est plus
possible de parler de Haute Disponibilité mais simplement de disponibilité) :
Nombre de 9 Arrêt du service sur 1 an
3 neuf (99,9%) environ 9 heures
4 neuf (99,99%) environ 1 heure
5 neuf (99,999%) environ 5 minutes
6 neuf (99,9999%) environ 30 secondes
b) Les différentes méthodes

Une bonne part des techniques disponibles reposent sur la multiplication des ressources
critiques (physiques ou logicielles) constituant un serveur. En multipliant les ressources, on
supprime du même coup leurs caractères critiques. Le service pourra donc être assuré même
en cas de panne d'un composant.
Cela permet notamment d'utiliser des composants moins cher puisque la fiabilité du
composant ne devient plus le critère principal.
Une seconde approche considère que l'on peut assez facilement mettre en place une solution
où ce n'est plus la ressource que l'on va chercher à dupliquer, mais directement le serveur.
L'utilisation de grappes de machines (cluster en anglais) est un bon moyen de répondre à cette
problématique. Si l'on parvient à disposer d'au moins deux machines sur lesquelles le service
est exécuté de façon unique (sur l'un ou l'autre des noeuds), la continuité du service sera
garantie moyennant le temps de basculement d'une machine à l'autre (On parle en anglais de
Failover Services, FOS).
La principale difficulté consiste à maintenir une copie des données entre les noeuds (dans ce
type de cluster dit de Haute Disponibilité, une machine s'appelle un noeud) pour que le
service puisse être indifféremment lancé sur l'un ou l'autre des serveurs. Pour accomplir cela,
il existe différentes techniques basées soit sur la réplication plus ou moins temps-réel des
Page 143 sur 248

données entre les noeuds, soit sur le partage d'une ressource unique en utilisant notamment un
système de fichiers distribués ou partagés.
Dans ce type de configuration, il est important de faire en sorte que le temps de rétablissement
du service soit le plus faible possible pour réduire le gène occasionné aux utilisateurs. Le
basculement du service dans le cluster ne doit pas être perceptible et ne doit surtout pas
occasionner une modification du paramétrage coté client : afin de rendre transparent cette
étape, on utilise la notion d'alias IP pour associer une adresse IP dite flottante sur le noeud
hébergeant le service. La continuité apparente du service coté client est donc assurée.
Une dernière technique moins connue permet de répartir la charge sur un ensemble de noeuds
physiques sur lesquels un service de type réseau est exécuté en parallèle et en concurrence.
Un noeud maître se charge de répartir les requêtes sur le noeud le moins chargé du cluster. Si
un noeud tombe en panne, il sera détecté par le maître qui pourra facilement le retirer de sa
liste des noeuds actifs.
La plus grande partie des architectures misent en oeuvre pour garantir la disponibilité d'un
service dérivent plus ou moins directement de ces trois approches.
c) Les composants de la haute disponibilité

Comme nous l'avons déjà vu, anticiper les pannes fait partie du travail préliminaire dans la
constitution d'une architecture HA. En ce sens, il est important de pouvoir suivre fidèlement
les modifications de l'environnement dans lequel évolue les machines : une augmentation
anormale de la température (par exemple) peut notamment provoquer des pannes qui ne se
seraient pas produites en temps normal.
Deux axes de réflexion peuvent être évalués pour réduire ce type de risques :
Solution Explication
La salle dans laquelle dans laquelle sont déployée les
machines doit garantir une température stable et une
Climatisation et hydrométrie hydrométrie raisonnable.
En cas de panne de courant, il faut garantir au moins

pendant un certain lapse de temps la bonne alimentation
électrique des serveurs : si les batteries de l’onduleur
Onduleurs devaient ne pas suffire, il peut envoyer un signal au
système pour lui intimer l'ordre de s'arrêter proprement. Le
mot onduleur est traduit de l'anglais sous l'acronyme UPS
pour Uninterruptible Power Supplies
La multiplication des différents composants critiques présents dans votre système peut
permettre de survivre à une panne en considérant que les solutions matérielles de Haute
Disponibilité disponibles sous Linux se rapprochent de plus en plus de celles proposées sur
les serveurs Unix haut de gamme.
Il est assez simple de redonder les alimentations électriques (transparent pour le système
d'exploitation) mais aussi les disques durs, les contrôleurs disques et les interfaces réseaux :
Page 144 sur 248

Certains constructeurs proposent de fournir deux ou trois

alimentations pour prévenir la perte de ce composant. Les
alimentations sont des composants critiques et il n'est pas rare de
voir celles-ci faillir bien avant les autres composants du système.
Alimentation redondée Les alimentations ATX par exemple ne sont pas réputées pour être
des plus fiables (elles sont notamment très sensibles aux variations
de tension)
L'utilisation des technologies Raid est un bon moyen de sécuriser

les données et prendre en compte notamment la perte d'un disque.
On peut disposer de cette technologie de façon logicielle sous
Utilisation de grappes Linux même si il est tout à fait envisageable de l'utiliser par
de disques durs l'intermédiaire de cartes d'interface IDE, SCSI et dernièrement
SATA
Un câble réseau peut être accidentellement débranché ; Une carte

réseau peut subir les aléas d'une panne et ne plus pouvoir être
utilisable. Heureusement pour nous, il existe une couche logicielle
sous Linux permettant de créer une interface réseau virtuelle
Multiplication des regroupant plusieurs cartes : on appelle cela, le Channel Bonding.
cartes réseaux Ce procédé est normalisé, on peut donc l'utiliser en point à point
mais aussi en interface avec des switchs et mêmes des hubs selon
le type d'algorithme sélectionné. En considérant le prix modeste de
certaines cartes réseaux, il parait incontournable d'utiliser
massivement cet artifice
Multipliez les serveurs peut être, au même titre que la multiplication des composants, un bon
moyen de garantir la disponibilité d'un service : si le service est rendu par l'intermédiaire d'un
cluster de machines, on pourra alors survivre à la perte de N-1 noeuds.
Heartbeat est un maillon essentiel dans la construction d'un cluster avec
basculement de services (de type Failover Services). Les services sont démarrés
généralement sur un seul noeud du cluster, appelé communément le noeud
principal : En cas de détection d'une panne, les services sont alors basculés sur
le noeud de secours. Pour garantir la continuité apparente du service coté
utilisateur, on utilise le principe des alias IP pour associer une adresse IP
virtuelle à la machine qui héberge le service (Heartbeat utilise le programme
Fake qui s'occupe de plus de mettre à jour les tables ARP).
Heartbeat
Les deux machines du cluster communiquent entre elles par l'intermédiaire de
liaisons Ethernet et de liaisons séries dédiées pour obtenir toutes les
informations utiles sur l'état du cluster et décider éventuellement de déplacer un
service d'un noeud vers un autre
On peut choisir d'équilibrer la charge en démarrant une partie des services sur
le noeud principal et une seconde partie sur le noeud secondaire : Heartbeat sait
Page 145 sur 248

parfaitement gérer ce type de configuration.
La principale difficulté consiste à disposer des données utilisées par les services
indifféremment sur l'un ou l'autre des noeuds du cluster : pour cela, il est
possible de répliquer les données entre les noeuds ou partager ces dernières à
partir d'une source commune partagée.
La mécanique de surveillance de Heartbeat ne détecte que les pannes

matérielles ou résultant d'un blocage du système d'exploitation. Il est alors
nécessaire d'utiliser un logiciel dédié (Mon) pour réaliser la surveillance
applicative des services.
FailSafe est une contribution de SGI qui permet de disposer d'un outil similaire
à Heartbeat pour basculer des services entre plusieurs noeuds d'un cluster.
L'approche est un petit peu différente avec une notion de plugins plus construite
que sous Heartbeat et avec le support d'un plus grand nombre de noeuds
(jusqu'à 16).
L'application est architecturée pour fonctionner avec des données partagées

mais rien ne vous empêche de l'utiliser sur de la réplication de données (un
FailSafe
plugin pour DRBD est disponible).
Moins connu que Heartbeat mais nettement plus puissant, ce programme mérite
clairement qu'on lui donne sa chance.
Toutefois, SGI et Suse ont arrêtés le développement de ce programme.
A la différence des solutions basées sur Heartbeat ou FailSafe, toutes les

machines présentes dans un cluster LVS (Linux Virtuel Server) sont capables
de fournir le même service et accèdent donc toutes aux mêmes données
partagées.
Un noeud chef d'orchestre (dispatcher) s'occupe de répartir de façon

transparente les requêtes réseau en équilibrant la charge sur l'ensemble du
cluster. Coté client, ce mécanisme est transparent car seule l'adresse IP du chef
d'orchestre est visible.
LVS
Plusieurs avantages découlent de cette architecture :
• En cas de panne d'un des noeuds du cluster, on retire ce dernier de la

liste des noeuds actifs ;
• Augmenter la puissance de traitement consiste simplement à ajouter à

chaud un nouveau noeud dans le cluster.
Il est habituel de placer le noeud chef d'orchestre au sein d'un cluster basé sur
du basculement de services (Heartbeat ou FailSafe) pour éliminer son caractère
Page 146 sur 248

critique.
Le routage se fait par l'intermédiaire d'un module noyau, la performance est

donc très bonne.
La disponibilité d'un service est indissociable de la disponibilité des données. Dans la

constitution d’une architecture HA, parvenir à garantir l'intégrité des données est l’une des
étapes les plus importantes.
Les données sont sécurisées en multipliant les disques durs (RAID) ou par réplication sur un
second serveur. De même, la notion de réplication est soit transparente pour l'application (on
réplique une partition ou un répertoire), soit intégrée dans une application comme c'est le cas
de certaines bases de données.
Des systèmes de fichiers spécifiques offrent aussi des fonctionnalités de tolérance aux pannes
intéressantes : on parle alors de systèmes de fichiers distribués ou partagés.
Reste la solution ultime du clustering HA : l'utilisation d'une baie de disques partagée qui va
permettre de centraliser les données sur un support unique accessible en concurrence ou non
(selon le type de la solution) par l'un ou l'autre des noeuds.
Le RAID est un mécanisme permettant d'agréger virtuellement plusieurs
ressources de types blocs (dans notre cas, des disques durs) pour offrir à
l'utilisateur une vision unifiée du stockage de ses données. De nombreux
algorithmes sont disponibles pour sécuriser les données et améliorer les
performances : dans ce cas, la perte d'un disque sera transparente pour
Utilisation du
l'utilisateur et n'affectera pas l'intégrité des données.
RAID
Il est classique d'utiliser un RAID de niveau 1 (miroir) pour sécuriser le
système d'exploitation et un RAID de niveau 5 pour les données
DRBD est un outil de réplication réseau de données localisées sur deux

serveurs distincts. La synchronisation peut se faire de façon partielle (après
une déconnexion réseau par exemple) ou complète (dans le cadre d'un
changement de média ou d'une première utilisation). DRBD ne gère pas
directement les mécanismes de détection des pannes et de basculement des
services pour une utilisation dans un cluster : Il fournit toutefois des scripts
DRBD
qui lui permettent d'être intégré assez facilement à Heartbeat.
L'utilisation d'une telle couche de réplication (livré sous la forme d'un

driver) est absolument transparente pour les applications
NFS est un système de fichiers distribués, bâtit sur un modèle

client/serveur, permettant de partager des données entre plusieurs machines.
NFS
Dans le cadre d'un cluster, on peut envisager une configuration où chaque
noeud récupère ses données sur un serveur NFS ce qui simplifie les
Page 147 sur 248

problématiques de réplication de données entre les noeuds.
Par contre, le problème est déporté sur le serveur NFS qui doit être lui
même sécurisé ...
Plutôt que de chercher à répliquer les données entre tous les noeuds d'un
cluster, une solution idéale consiste à utiliser une baie de disques partagée
pour stocker les données.
Afin d'éviter les accès concurrents, seul un noeud du cluster à la possibilité

de monter les données présentes sur la baie. En cas de panne, le noeud de
Baie de secours réagit en récupérant la ressource et en redémarrant les services
stockage (adresse IP inclus).
partagée
Le matériel nécessaire pour monter une architecture de ce type est assez
spécifique : la baie de disques (de type Fibre Channel ou SCSI), les
contrôleurs d'entrée/sortie et les câbles doivent supporter cette
fonctionnalité
RSYNC est un petit programme assez sympathique qui peut nous permettre
de synchroniser à la demande deux répertoires localisés sur deux machines
distantes.
Le protocole utilise soit la couche RPC, soit la couche SSH pour transporter
les données. Ces dernières peuvent être compressées et seules les données
RSYNC
réellement modifiées sont échangées.
C'est une brique élémentaire indispensable lorsque l'on souhaite répliquer

des données qui évoluent peu, ce qui est le cas d'un serveur web statique
Les bases de données relationnelles fonctionnent sur un modèle

transactionnel : la tentation est donc forte de vouloir placer au niveau de la
base de données la notion même de réplication en considérant très justement
qu'un tel mécanisme sera forcément plus efficace qu'une réplication de type
DRBD.
C'est le moyen idéal pour répliquer des données entre deux serveurs dans le
Réplication de
cadre d'un cluster avec basculement de services (Heartbeat) lorsque ce
base de
dernier est constitué d'un service rendu par l'intermédiaire d'une base de
données
données
Il ne faut pas hésiter à l'utiliser si cela est supporté par la base de données :
MySQL et PostgreSQL, en particulier, supportent parfaitement cette
fonctionnalité
Page 148 sur 248

Redonder les composants matériels de l’architecture permettra certainement au système
d'exploitation de réagir correctement en cas de panne mais nécessitera à terme une
intervention manuelle corrective : plus on attend avant de remplacer un composant en panne,
plus le risque est important d'en voir un second suivre le même chemin.
L'arrêt de service doit être évité au maximum : une architecture cluster permet d'arrêter
uniquement le noeud hébergeant un élément défectueux ; une approche moins brutale consiste
à changer à chaud le composant en panne (aucun arrêt de la machine) si ce dernier supporte la
fonctionnalité sous Linux.
Une panne peut aussi affecter l'ensemble de votre architecture imposant un arrêt brutal qui
peut laisser le système de fichier dans un état instable. Ce dernier doit donc pouvoir être
vérifié au redémarrage de la machine en un temps raisonnable.
Toutes ces techniques sont regroupées dans la notion de reprise sur panne :
En cas d'arrêt violent d'un serveur, rien ne peut garantir l'intégrité des
systèmes de fichiers si l'on considère les mécanismes de cache
mémoire mis en place pour accélérer les entrées/sorties. Linux a été
longtemps pénalisé par l'absence de solutions adaptées : tout arrêt
anormal résultait en une vérification minutieuse de la surface du
disque pour localiser et réparer les erreurs de cohérence dans les
systèmes de fichiers (le fameux fsck). Depuis environ 2 ans, des
systèmes de fichiers dit journalisés existent sous Linux : Ext3,
Système de fichiers Reiserfs, Xfs ou encore JFS. Ces systèmes de fichiers mémorisent
journalisé dans un journal tous les évènements et sont donc capables, en cas de
problèmes, de ne vérifier que les derniers échanges en cours sur le
disque.
Le redémarrage d'un serveur qui utilise un système de fichiers

journalisé est donc quasiment immédiat : cette brique élémentaire est
donc indispensable
Si on utilise une solution RAID, il est dommage de devoir arrêter le

système juste pour changer un disque dur en panne (changement à
froid). Pour vous éviter cette étape inutile, certains constructeurs de
cartes RAID permettent de changer les disques durs à chaud
(indispensable dans la pratique). Dans le cas du RAID logiciel, la
Chargement à situation est plus compliquée car vous devez d'abord enlever le
chaud des périphérique du système d'exploitation avant de pouvoir le remplacer
périphériques physiquement par un nouveau disque. La situation est différente
suivant le type du contrôleur : le SCSI permet assez facilement ce type
de manipulation en jouant sur un fichier virtuel présent alors que l'IDE
est plus complexe mais peut en certaines circonstances être envisagé.
Changement à Le regroupement PCIMG (PCI Industrial Manufacturers Group) a

chaud des élaboré tout un ensemble de normes et de recommandations pour
composants faciliter la maintenance des composants au format CompactPCI :
Page 149 sur 248

matériels Ceux ci peuvent être remplacés à chaud dans un serveur du moment

que toute la chaîne logicielle et matérielle supporte la fonctionnalité.
A force de chercher à corriger les dysfonctionnements matériels, on peut facilement oublier

le logiciel qui est un des aspects les plus imprévisibles de l’architecture. Aucun code n'est
exempt de bogues et rien ne peut garantir que le système d'exploitation ou que les applications
ne vont pas tomber en panne. Il est donc nécessaire de surveiller la bonne marche du logiciel,
quitte à le relancer automatiquement en cas de nécessité :
Mon est un outil de surveillance applicative qui permet de surveiller l'état
des ressources logicielles et de déclencher des actions paramétrables. C'est
un composant essentiel pour déclencher un basculement dans le cadre d'un
Mon cluster avec migration de services (Heartbeat) si l'application ne tourne
plus sur le noeud actif
Un script taillé à la mesure de des applications est peut être la solution

idéale qui permet de surveiller la bonne marche des services et de relancer
ceux-ci automatiquement en cas de problème ou de provoquer un
Scripts maison
basculement dans un cluster.
Linux a la réputation d'être un système stable et robuste : mais comme tout

logiciel, celui-ci n'est pas exempte de bogues. La tentation est souvent
forte pour les éditeurs d'intégrer dans leurs distributions une version
récente du noyau au détriment d'une version plus ancienne, moins
performante, mais plus éprouvée. Généralement, cela se traduit par un
blocage général du système entraînant à coup sûr un redémarrage.
Utilisation d'un
chien de garde Une carte de type WATCHDOG permet de provoquer automatiquement
une telle relance (reset matériel) du moment que le système d'exploitation
cesse de la stimuler. Cela assure le redémarrage de l'applicatif lorsque
l'arrêt n'a pas été causé par une défaillance matérielle permanente.
Cette solution n'est à utiliser que dans les cas extrêmes car une mise à jour
du noyau est à envisager en cas de répétition du problème
Les phases d'administration et d'exploitation d'un système en Haute Disponibilité ne se

comparent pas avec celles des autres serveurs moins critiques. Il faut notamment parvenir à
détecter une panne le plus rapidement possible pour pouvoir rétablir le service sous les
meilleurs délais :
Suivre l'évolution de la température ou vérifier la bonne marche des
ventilateurs font partie du travail à accomplir dans le cadre de la
Surveiller l'état
surveillance d'un système critique.
du système
Redémarrage à Il est souvent possible de démarrer à distance le serveur en envoyant une

distance du simple requête UDP sur l'adresse MAC du serveur. La technique s'appelle
Page 150 sur 248

serveur le « Wake On Lan » (le réveil par le réseau)
De nombreuses pannes ou dysfonctionnements ont pour origine une

installation bâclée ou une sous-évaluation de la charge que devra tenir le
Dimensionner
serveur. Il faut donc disposer d'une partition de swap adaptée, d'une
correctement le
volumétrie disque évolutive et d'une puissance CPU convenable.
serveur
Certains BIOS autorise ce type de configuration à utiliser néanmoins avec

Démarrage dès
précaution (il faut éviter les redémarrages en boucle)
la mise sous
tension
Disposer d'un accès distant sur le serveur permet de gagner en temps et en
réactivité. Telnet et SSH sont deux moyens.
Accès distant
Si on utilise des briques logicielles aussi diverses que le Channel Bonding

ou le RAID logiciel, on doit mettre en place des moyens pour remonter
les évènements (perte d'une carte, perte d'un disque) vers un exploitant
Remontée des
(par un email généralement). De même, il faut surveiller le pourcentage
évènements
de saturation des partitions systèmes, etc.
d) Exemples d’architecture
Cluster basé sur la réplication de données

Ce type de cluster connaît plusieurs variantes suite aux nombreuses briques logicielles ou
matérielles misent à notre disposition.
Nous avons choisi d'utiliser DRBD pour répliquer les données entre les noeuds, MON pour
surveiller l'état de nos services et du système, le Channel Bonding pour sécuriser les
composants réseaux et améliorer en particulier les performances entre les noeuds (la vitesse
de réplication dépend directement de la performance du réseau), une carte RAID pour
fiabiliser les données et héberger le système d'exploitation, un onduleur (UPS) et enfin
Heartbeat pour lancer et basculer les services :
Page 151 sur 248

Serveur
Serveur 11 Serveur
Serveur 22
Channel
Bonding
Carte RAID Cartes réseaux Cartes réseaux Carte RAID
Raid 1 Lien série Raid 1

Données Données
+ +
Système Système
DRDB
Service 1 Service 1
Service 2 HeartBeat Service 2
Service 3 Service 3
Cluster
Cluster avec
avec réplication
réplication de
de données
données
Cluster basé sur le partage des données

La difficulté principale consiste à réunir au sein d'une même configuration tous les
composants matériels nécessaires pour autoriser le partage d'une ressource par plusieurs
machines. Ce n'est pas une étape triviale à mener et il s'agit de ne pas se tromper dans le choix
des composants.
Il nous faut d'abord trouver une baie de disques externe qui supporte l'accès simultané de tous
les noeuds de notre cluster.
Il est conseillé de choisir une baie de type RAID permettant de garantir la disponibilité des
données à la différence d'une baie standard moins cher : on utilise le terme JBOD (Just a
Bunch Of Disks) pour désigner une baie de disque qui n'intègre pas de contrôleur RAID
interne ; la Haute Disponibilité des données n'est donc pas garantie dans ce cas. On peut
toutefois utiliser du RAID logiciel (RAID 1 ou RAID 5) pour sécuriser les données (activé sur
un noeud à la fois).
Il nous faut ensuite sélectionner un contrôleur SCSI ou Fibre Channel pour connecter la baie
aux machines présentes dans le cluster : le choix d'une interface de type SCSI permet de
partager une ressource entre deux et quatre noeuds alors que le Fibre Channel pourra en
supporter beaucoup plus. Le choix final va donc dépendre du type de configuration que l’on
souhaite mettre en oeuvre.
Le logiciel que nous allons ensuite utiliser pour gérer le cluster doit pouvoir nous garantir
l'unicité du service si les connexions dédiées (Ethernet et liaison série) entre les noeuds du
cluster sont rompues. Dans ce cas précis, personne ne sait dans quel état se trouve le voisin et
le logiciel est donc dans l'incapacité de prendre une décision (choix d'un basculement de
services). On dit alors que le cluster est en site partition : une situation qui ne doit pas arriver.
• Une première solution consiste à dialoguer par l'intermédiaire d'une partition quorum
dédiée sur la baie de disques pour échanger des informations et réserver des disques
Page 152 sur 248

ou des partitions : c'est la solution technique la plus souvent implémentée sous Linux
de par son indépendance au niveau du matériel ;
• Une seconde approche (dans un cluster de 2 noeuds) consiste à poser un verrou

(commande SCSI RESERVE) sur le disque ou sur la partition que l'on souhaite
réserver. Si le noeud de secours ne sait pas dans quel état se trouve son voisin, il va
chercher à libérer la ressource par la commande SCSI RELEASE. Si le noeud
principal du cluster repose immédiatement le verrou, c'est indubitablement qu'il est en
vie. Cette technique n'est pas implémentée sous Linux ;
• Une dernière approche met à contribution des équipements Power Switches pour
essayer de « tuer » (au niveau électrique) le noeud voisin avant de récupérer ses
services : on est alors certain de ne pas entrer en conflit avec un noeud avec lequel on
ne parvient plus à communiquer. C'est une méthode simple mais particulièrement
efficace.
Les clients ne discutent pas directement avec les adresses IP des machines du cluster mais
uniquement avec des adresses IP flottantes qui permettent d'abstraire complètement la
localisation des services dans le cluster.
Il est possible, en combinant des composants logiciels et matériels que nous venons de voir,
de réaliser ce type de cluster :
Serveur
Serveur 11 Serveur
Serveur 22
Channel
Bonding
Carte RAID Cartes réseaux Cartes réseaux Carte RAID
Raid 1 Lien série Raid 1

Système Système
DRDB
Service 1
Contrôleur Contrôleur
Service 2
Service 3
Baie disque : Raid 5
Cluster
Cluster avec
avec partage
partage de
de données
données
Bien que d'un niveau technique largement suffisant pour des besoins standards, la solution
précédente est pourtant handicapée par la notion même de partage des données qu'elle
Page 153 sur 248

impose : la réservation est forcément exclusive et implique de verrouiller les accès au niveau
du disque ou de la partition pour un seul noeud.
Il est pourtant possible de descendre à un niveau beaucoup plus fin en considérant l'utilisation
d'un système de fichiers distribué comme GFS ou OpenGFS. Par son intermédiaire et son
arbitrage, chaque noeud pourra accéder aux mêmes données (pas forcément au même
moment) et réduire d'autant les risques de corruption des données.
3) Architecture
a) Introduction aux clusters Beowulf
Afin de comprendre l’architecture, il faut comprendre le concept des clusters Beowulf. Le
projet Beowulf est né en 1994 au Goddard Space Flight Center de la NASA. Le principe est
de construire des clusters parallèles sous GNU/Linux avec du matériel commun (simples
PCs), donc peu cher.
Une des premières réalisations concrètes de cluster date de 1995. Il s'agissait alors de 16 PCs
de type 486DX4@100MHz avec chacun deux interfaces Ethernet à 10Mbps et des disques
durs de 250Mo, une architecture énorme pour l'époque. Ce cluster était employé par la NASA
pour la simulation de phénomènes physiques et l'acquisition de données. (D’après un
document de la NASA).
Après cette première approche très concluante, divers autres projets sont apparus, dont des
architectures de l'ordre de 100 PCs P-II...
Aujourd'hui, les clusters Beowulf apparaissent dans le TOP-100 des super-calculateurs les
plus puissants au monde, et peuvent aller jusqu'à plusieurs dizaines de stations chacune multi-
processeurs et totalisant des Téra-octets (milliers de Giga) de capacité de disque dur et
plusieurs dizaines de Giga-octets de RAM.
b) Comparaison Beowulf et SMP
L'architecture SMP est celle rencontrée dans les PCs multi-processeurs, les stations SGI, les
stations SUN, les stations HP/PA, certains des super-calculateurs de type CRAY, ... Elle
consiste à mettre une seule mémoire vive en commun pour plusieurs processeurs qui sont plus
ou moins sur la même carte mère (64 processeurs ne sont pas tout à fait sur la même carte) et
en partagent toutes les ressources.
L'architecture de type Beowulf (et la majorité des clusters en général) est constituée quant à
elle de machines indépendantes (processeur, mémoire, disque(s) dur(s), alimentation)
connectées entre elles par un réseau de type Ethernet.
Alors que dans une architecture SMP les processeurs travaillent en communication
permanente, dans un cluster une des machines répartit les tâches entre toutes les autres qui lui
envoient le résultat une fois les calculs terminés.
Prenons un exemple: Une machine Bi-P-II ou Bi-Celeron va perdre 25% de sa fréquence

totale à cause entre autres des communications entre processeurs. Avec 2 processeurs à
500MHz, on aura ainsi le même résultat qu'avec un processeur à 750MHz. En mettant 2
Page 154 sur 248

machines mono-processeur en parallèle, elles ne gaspilleront que quelques milisecondes de
temps de calcul à communiquer.
Mais il y a une limitation. Dans les deux cas, les logiciels doivent être "parallélisés" pour
utiliser plusieurs processeurs (qu'ils soient dans la même machine ou pas). Mais dans le cas
d'un cluster il faut faire en sorte que les "processus" communiquent le moins possible entre
eux. Une connexion réseau (même Gigabit Ethernet) est un peu juste pour que les processeurs
se synchronisent tout le temps entre eux, alors qu'avec un logiciel "bien programmé", une
connexion 10Mbps peut éventuellement suffire.
Dernière raison et non la moindre, le coût. On constate généralement qu'un cluster de

puissance équivalente coûte initialement 10 fois moins cher. C’est pour toutes ces raisons
qu’une architecture de type Beowulf a été choisie :
LAN
Nœuds de
calcul
(Production)
Nœud de
Gestion
LINUX
MPI Outils de
Gestion de
Applications Clusters
parallèles
Structures
Structures des
des Clusters
Clusters BeoWulf
BeoWulf
c) Architecture logique
D’un point de vue logique, toutes les machines d’un cluster n’ont pas le même rôle. Il faut
signaler que la même machine peut avoir plusieurs rôles.
Page 155 sur 248

Nœud de
contrôle
Cluster
(DHCP,
DNS, etc.)
Nœud
Nœud de d’installation
Gestion (image des
(Supervision, CD, etc.)
etc.) Nœuds de
calcul
(Production)
Cluster
Nœud de
stockage
Nœud
utilisateur (Seul
accès pour
extérieur)
Utilisateurs/
Administrateurs
Structure
Structure logique
logique d’un
d’un Cluster
Cluster
Nœud de calcul
Le nœud de calcul est l’endroit où les actions de production sont effectuées. Dans notre cas, il
s’agit de gérer des communications et des services. La majorité des nœuds d’un cluster sont
des nœuds de calcul.
Nœud de gestion
Les clusters sont des environnements complexes et la gestion d’un cluster est très importante.
Le nœud de gestion propose diverses fonctionnalités :
- La supervision de l’ensemble des nœuds
- Des commandes de management pour gérer différant problèmes.
Il ne faut pas sous estimer l’importance de la gestion d’un cluster.
Page 156 sur 248

Nœud d’installation
Dans la plupart des clusters, les nœuds de calcul doivent être réinstallés (nouvelle version,
etc.) relativement souvent. De même, il est des fois nécessaire de rajouter des nœuds pour
augmenter les capacités.
Le nœud d’installation fournit les images et les mécanismes pour réinstaller facilement et
rapidement un nœud de calcul
Nœud utilisateur
Le nœud utilisateur est en quelque sorte la porte d’entrée du cluster. C’est sur ce nœud qu’un
utilisateur peut lancer une action et récupérer les résultats.
Nœud de contrôle
Le nœud de contrôle propose des services pour les autres nœuds du cluster. C’est par exemple
lui qui va gérer les services DNS et DHCP. Par ailleurs, il peut gérer la répartition des tâches
sur l’ensemble du cluster.
Nœud de stockage
L’ensemble des nœuds de calculs doit souvent accéder aux mêmes informations. Il est donc
nécessaire de rajouter un nœud de stockage. La technologie employée peut être très variable
en fonction du cluster, de la vitesse d’accès, de la capacité de stockage nécessaire, etc.
d) Architecture proposée
L’architecture proposée pour la solution hébergée est totalement redondante.
Pour l’instant, tant que la charge le permet, les nœuds utilisateur, de contrôle, de stockage et
gestion sont regroupé sur un seul serveur que nous appelons serveur de contrôle. Ce serveur
est mis en haute disponibilité avec un second.
Les nœuds de calcul sont sur ce que nous appelons des serveurs de production. Un ou
plusieurs serveurs sont en attente, au cas où un des serveurs de production tomberait en
panne. Ces serveurs permettent également de compléter les serveurs de production en cas
d’augmentation de la charge :
Page 157 sur 248

*
* N serveurs
Production
*
.
.
.
* LAN 1Gb
VPN
1 ou 2 serveurs
Standby
*
2 serveurs
Contrôle
Réplication
- Supervision
- Configuration
- Administration
Supervision
BSNetwork
Serveur Web *
Serveur Asterisk Serveur de Fichiers Annuaire Supervision Base de données Billing
Solution
Solution hébergée
hébergée
e) Base de données
Tout le système est architecturé autour d’une base de donnée. Cette base contient à la fois les
informations des clients, des appels et des serveurs.
Le système de gestion de base de données (SGBD) utilisé est PostgreSQL. Il a l’avantage

d’être maîtrisé par les développeurs, d’être performant mais également gratuit.
f) Asterisk
Dans un tel scénario, et afin de pourvoir utiliser une base de donnée, tout le plan d’appel
d’Asterisk sera géré par un programme externe. On parle alors d’AGI. Tous les appels sont
alors redirigés vers une sorte de script :
exten=>.,1,AGI(script.agi)
Le script peut être écrit dans n’importe quel langage informatique. Nous avons choisi le PHP
pour son aspect dynamique, sa modularité et sa capacité d’interaction avec une base de
données. Par ailleurs, c’est un langage qui est maîtrisé par la plupart des programmeurs
(contrairement au PERL, par exemple).
L’exemple suivant illustre cette méthode :

#!/usr/local/php-4.3.9/bin/php -q
<?php
$stdout = fopen('php://stdout', 'w');
$stdin = fopen('php://stdin', 'r');
$ficid = fopen('/home/dev/out', 'w');
while (!feof($stdin))
{
Page 158 sur 248

$temp = fgets($stdin);
$temp = str_replace("\n","",$temp);
$s = explode(":",$temp);
if (isset($s[1]))
{
$agivar[$s[0]] = trim($s[1]);
fflush($stdout);
}
if (($temp == "") || ($temp == "\n"))
{
break;
}
}
require_once "db_psql.php";
$db = New DB();
$query_string = " SELECT callerID, context FROM Phone WHERE internal =
".$agivar["agi_extension"];
$db->query($query_string);
$result = $db->getResult();
$command = "EXEC DIAL SIP/".$result[0]["callerid"]."_".strtolower($result[0]["context"]);
fputs($stdout,$command);
fflush($stdout);
fclose($stdout);
fclose($stdin);
?>
Le fichier « db_psql.php » utilisé dans ce programme est disponible en annexe
g) SER
Introduction
SER ou Sip Express Router est un serveur VoIP gratuit basé sur le protocole SIP. SER est un
programme à la fois performant et robuste ; il est extrêmement configurable en ce qui
concerne la création de règle de routage (redirect) et de sécurité, contrairement à Asterisk.
Basé sur les derniers standards, SER fonctionne comme serveur proxy, d’enregistrement et de
redirection. C’est ce dernier mode qui nous intéresse.
Architecture
L’objectif de l’utilisation de SER est de rediriger une demande client vers le bon serveur. En
effet, toutes les demandes arrivent sur les serveurs de management. Il faut rediriger ces
demandes vers les serveurs Asterisk de production, en fonction de la requête.
Page 159 sur 248

*
1
Requêtes
*
2
Requêtes Requêtes Client 1
N serveurs
Client 2 Production
*
3 4
Client 3 & 4
*
5 6 7
.
Client 5,6 & 7
.
Serveur SER
.
Redirection des
requêtes 1 ou 2 serveurs
Standby
SER
SER
*
Configuration
Le langage de routage
SER possède un langage spécial de routage qui permet aux administrateurs de définir les
conséquences d’une requête SIP d’une manière précise. Ils peuvent par exemple séparer le
trafic SIP par méthodes, destination, utilisateur, etc.
Le premier bloc de construction du langage de routage est l’action. Il existe des blocs
d’actions de base comme « Forward » ou « Strip » et des blocs d’actions qui sont importés de
différents modules. Les actions peuvent être regroupées entre elles grâce à des accolades
(exemple : {action1() ;action2() ;}) pour former un bloc de routage. Au début, seul le bloc de
routage par défaut (appelé route[0]) est considéré par SER. Les autres blocs de routage
peuvent être appelés par l’action « Route ». Les appels récursifs sont autorisés, comme les
appels conditionnels.
Le script de routage est exécuté pour chaque requête reçue, dans l’ordre logique. Chaque
action doit retourner un résultat positif, négatif ou nul. Un résultat nul est considéré comme
une erreur alors qu’un résultat positif signifie une réussite de l’action (ou VRAI) et un résultat
négatif signifie un échec de l’action (ou FAUX).
La redirection
Pour configurer un serveur de redirection, il suffit d’indiquer à la requête le serveur suivant.

Ainsi, la requête est redirigée vers un autre serveur. Pour configurer une redirection statique,
il faut utiliser l’action « forward(adresse IP, numéro de port) » :
# si l’uri demandé est numérique et commence par un zero
# la requete est redirigé vers le serveur 192.168.99.3 sur le port 5080
if (uri=~"^sip:0[0-9]*@bsnetwork.fr") {
forward( 192.168.99.3, 5080 );
}
Les conditions
Page 160 sur 248

Malheureusement, le routage statique est souvent insuffisant. Il est alors nécessaire de mettre
des conditions. Dans notre cas, il est intéressant de séparer les différents clients. Ainsi si la
requête concerne une URI avec le nom de domaine « bsnetwork.fr », on redirige la requête
vers le serveur 1, sinon vers un autre serveur :
# si la requete concerne bsnetwork alors on la redirige vers le serveur 1...
if (uri=~"^sip:[0-9]+@bsnetwork.fr") { # on vérifie l’uri demandée
forward( serveur1, 5060 );
} else { # Sinon vers le serveur 2
forward( serveur2, 5060 );
};
Les conditions dans les scripts SER peuvent dépendre d’une grande variété d’expressions.
Une action qui est souvent utilisé est « search ». Cette action recherche une expression dans
une chaîne de caractère. Si cette expression est trouvée, l’action retourne VRAI, sinon FAUX.
Modification de l’URI
Une autre possibilité de SER est la modification des URI. Ainsi une requête qui arrive avec
une URI « fred@bsnetwork.fr » peut être transférée vers un serveur de production avec l’URI
« fred_bsnetwork@192.168.6.8 ». Cela permet par exemple d’être certain d’avoir des noms
uniques sur les serveurs, sans que les utilisateurs s’en aperçoivent.
Pour cela, on utilise l’action rewriteuri (dans le même style, on trouve : rewritehost,
rewritehostport, rewriteuser, rewriteuserpass et rewriteport) :
if (uri=~"fred@bsnetwork.fr") {
rewriteuri("sip:fred_bsnetwork@serveur1")
# la requête est transférée en fonction de l’URI actuelle,
# c’est à dire : sip:fred_bsnetwork@serveur1:5060
forward( uri:host, uri:port);
}
SER et BdD
Toutefois, la configuration des serveurs de production n’est pas figée. Ainsi un client qui se
trouve sur le serveur 1 un jour, peut être transférer sur le serveur 2 pour des raisons de
performance.
Il est alors nécessaire de faire la redirection en fonction des dernières informations. Ces
informations sont contenues dans la base de données principale du système. Il est donc
nécessaire d’interroger cette base de donnée.
Voici un exemple d’interrogation d’une base de données MySQL :

# ------------------ module loading ----------------------------------
loadmodule "modules/exec/exec.so"
loadmodule "modules/sl/sl.so"
# affiche un message quand une requête arrive
route[0] {
if (!exec_msg(’REQUETE="select serveur_actuel from clients where user=\"$SIP_OUSER\"";
REDIRECT=‘mysql -Bsuser -pheslo -e "$REQUETE" ser‘; if [ -z "$REDIRECT" ] ; then exit 1;echo
"Une requête en provenance de $SIP_HF_FROM pour $SIP_OUSER. Redirigée vers " $REDIRECT’))
{
# l’utilisateur n’existe pas
sl_send_reply("404", "L’utilisateur n’existe pas");
} else {
Page 161 sur 248

sl_send_reply("600", "Pas de messages");
};
}
SER interroge la base de donnée pour connaître le serveur actuel d’un utilisateur. Le nom de
ce serveur est alors affiché.
Toutefois, une deuxième solution consiste à créer un petit module de connexion à la base de
données. Il est alors possible d’avoir une action simple pour interroger la base de données.
4) Obelisk
Toutes les actions se font donc en fonction de la base de données. Toutefois, il est
impenssable de pouvoir la modifier directement et encore plus de laisser les clients y avoir
directement accès.
J’ai donc travaillé avec Fabien WALLET, Ingénieur Développeur, pour créer une interface
graphique. Cette interface, surnommée Obelisk, permet une interaction avec la base de
données. Cette interface est utilisable à la fois par les administrateurs du système et par
clients, grâce à des niveaux de droits.
La gestion des téléphones se fait grâce à des tutoriaux. Ainsi, le système est utilisable sans
problème par des non professionnels et sans formation poussée.
Cette interface permet également de gérer l’ensemble du système et des modules optionnels
comme le FOP (Flash Operator Pannel) qui est en fait un standard en Flash :
L’applicatif est construit sur un schéma relativement simple : un bandeau principal en haut,
un menu de navigation à gauche, un menu de logout/profile et d’actions à droite, les sections
Page 162 sur 248

spécifiques au milieu avec en général dans le cas des gestions un listing obligatoire des entités
déjà créées, et enfin un bandeau de bas de page :
5) Haute Disponibilité des différents composants

a) Ingate Fail-Over
Introduction
La fonction de tolérance de panne des firewalls Ingate consiste à avoir 2 firewalls avec la
même configuration. L’un est actif et l’autre attend que le premier tombe en panne… Ces 2
firewalls sont appelés une équipe de tolérance de panne ou « Failover Team »
Cette fonction nécessite une interface dédiée sur chaque firewall :
Page 163 sur 248

Internet
LAN
Routeur
Failover Team
Ingate
Ingate Fail-Over
Fail-Over
Prérequis
La tolérance de panne nécessite donc 2 firewalls. Chacun doit disposer d’au moins 3
interfaces et le firewall en attente doit avoir autant d’interface que le firewall actif. Les deux
doivent avoir la même version logicielle (firmware). Tous les modules sur le firewall actif,
doivent être également présents dans le firewall en attente.
Enfin il est nécessaire de relier les deux unités avec un câble croisé
Fonctionnalités
La tolérance de panne permet de créer un binôme où un firewall est actif et l’autre est en
attente. Le firewall en attente reste en contact constant avec le firewall actif pour vérifier s’il
fonctionne bien et synchroniser la configuration. Quand le firewall actif tombe en panne, le
firewall en attente le remplace, avec la même configuration.
Si l’un des deux firewalls arrête de fonctionner ou si le firewall actif n’arrive pas à contacter
le firewall en attente, le firewall actif ne va plus accepter des changements de configuration.
En effet, dans ce cas, il serait impossible de transférer la nouvelle configuration au firewall en
attente. Si un tel cas se produit, et qu’il est impossible de rétablir la connexion entre les deux
firewalls, le firewall actif doit être changé de mode. Il passe alors en mode autonome et le
binôme est détruit.
La communication entre le binôme est vérifiée toutes les 30 secondes. Ainsi, si une panne se
produit, le temps maximal de panne correspond à la durée maximale jusqu’à la prochaine
vérification (30 secondes) et au temps d’application de la configuration sur le firewall en
attente. Toutes les sessions TCP et UDP sont alors perdues. De même les appels SIP sont
interrompus. Toutefois, le nouveau firewall actif conserve les informations d’enregistrement
SIP.
Configuration
Pour créer un binôme, il faut configurer les deux firewalls de manière différente. Le premier
(l’actif) sera configuré par l’interface graphique alors que le second sera connecté au premier
grâce à une connexion série.
Page 164 sur 248

Firewall actif
Pour configurer le binôme sur le premier firewall, il faut aller sur la page « Failover Settings »
de l’interface Web, sélectionner l’interface qui sera directement connecté au second firewall
(« Dedicated interface to use ») et cliquer sur le bouton « Create new team ». Le firewall va
alors redémarrer.
Firewall en attente
Pour connecter le firewall en attente au firewall actif, il faut se connecter au firewall avec un
câble série. Une fois connecté sur la console avec le compte « admin », il faut sélectionner la
troisième option du menu : « 3. Become a failover member ».
Il faut alors sélectionner l’interface qui a été configuré comme interface dédiée. Toute la
configuration existante va alors être effacée et le firewall va redémarrer. Il va alors obtenir sa
configuration du firewall actif.
Le binôme est alors créé.
b) HeartBeat et Mon
Heartbeat prend en charge les défaillances en transférant des ressources (services, IP, disques)
d’un maître vers une machine esclave.
Fonctionnement
Le scénario type est le suivant :
- Défaillance du serveur
- L’esclave détecte l’absence du serveur
Page 165 sur 248

- Récupération des ressources par l’esclave
Si le maître revient, il reprend ou non les ressources (suivant la configuration choisie).
Les ressources pouvant être partagées sont multiples, Heartbeat est en effet capable de lancer
n’importe quel script. Par conséquent, c’est l’ensemble des services d’une distribution
standard qui peuvent être gérés sans difficulté.
De plus des scripts spécifiques ont été développés, ils permettent de partager facilement des
systèmes de fichiers (scsi partagé) et des adresses IP. C’est ce dernier point qui est
traditionnellement le plus utile puisque il est nécessaire à tout partage de services réseaux.
Pour détecter une défaillance système, Heartbeat se base sur un système d’échanges de
messages. Les supports de cette communication sont le réseau (en UDP, broadcast ou
multicast) ou un câble série disposé entre deux machines. Les deux supports peuvent
fonctionner simultanément ce qui permet d’éviter une fausse défaillance en cas de rupture
d’un des liens. Chaque machine surveille l’état de l’autre et, en cas d’absence de signal
pendant une certaine durée sur tous les supports physiques, la machine défaillante est déclarée
morte et la machine vivante récupère les ressources.
Redondance d’adresses
Lors du partage d’adresse IP, ce sont les adresses actives qui se déplacent. Il est toutefois utile
de pouvoir accéder aux machines du cluster quel que soit l’état de celui-ci, notamment afin de
pouvoir les administrer, il faut donc disposer d’une adresse IP fixe sur chaque machine.
Heartbeat a donc recours à l’IP-aliasing pour faire migrer les IPs du cluster. Il utilise
l’algorithme suivant pour déterminer automatiquement quelle doit être l’interface physique
recevant la nouvelle IP : une IP est attribuée à l’interface possédant la route vers le réseau le
plus proche de celui de l’IP à attribuer. Dans le cas où aucune route n’est trouvée, l’interface
de la route par défaut est choisie.
Interactions avec Mon

Heartbeat ne permet pas de surveiller la défaillance des services. Il est donc toujours possible
d’utiliser Mon pour indiquer au système heartbeat qu’il y a défaillance. Pour arriver à ce
résultat et déclencher avec Mon le basculement des ressources, il suffit tout simplement
d’appeler le script d’initialisation Heartbeat avec l’argument stop. Quand Heartbeat est arrêté,
l’esclave déclare la mort du maître et donc reprend les ressources.
Il faut donc utiliser Mon pour détecter les interruptions des services nécessitant une bascule.
C’est ensuite Heartbeat qui s’occupe de basculer les ressources.
Fonctionnalité manquante et problèmes communs

Plusieurs choses manquent à Heartbeat. Tout d’abord, Heartbeat est limité à deux machines et
la gestion d’une architecture du type, 2 serveurs et une machine de backup, n’est pas
supportée.
Enfin, dans le cas de deux machines distantes, le protocole UDP reste le seul moyen d’assurer
les communications d’Heartbeat. Malheureusement, il peut arriver qu’il y ait perte de paquets
UDP. Dans ce cas là, au moins une des deux machines pense que l’autre ne répond plus.
Page 166 sur 248

L’esclave prend alors les ressources qui sont donc possédées par les deux machines. La
situation est tout simplement chaotique.
Mise en place d’Heartbeat

La configuration d’Heartbeat repose sur trois fichiers. Le premier fichier « ha.cf » décrit la
configuration physique du système. Le second « haresources » indique les ressources à
partager, et enfin « authkeys » contient les clefs de cryptage utilisées pour communiquer entre
les machines.
Mon et Heartbeat
Il est nécessaire de créer un fichier permettant de gérer les alertes envoyées par mon,
« heartbeat.alert ».
#!/bin/bash
HEARTBEAT="/etc/rc.d/init.d/heartbeat"
if [ "$9" = "-u" ]; then
$HEARTBEAT start
else
$HEARTBEAT stop
fi
Il faut ensuite déclarer un appel à « heartbeat.alert » dans le fichier de configuration de mon,

« mon.cf ». Ainsi pour surveiller, la défaillance d’un serveur http en interne et déclencher le
passage des ressources :
hostgroup server localhost
watch server
service http
interval 10s
monitor http.monitor
period NORMAL: wd {Sun-Sat}
numalerts 1
alert heartbeat.alert
upalert heartbeat.alert
Cette combinaison permet donc de déclencher un switch des ressources dès que l’on détecte
que le serveur apache ne répond plus (et ce en dehors de tout problème réseau)
Conclusion
Le duo Heartbeat / Mon est donc parfait pour assurer la redondance de deux machines proches
physiquement avec surveillance des défaillances des services et des systèmes. C’est donc la
solution idéale pour redonder notre serveur de management qui va héberger à la fois la base
de donnée, SER et les services WEB.
c) DRBD
Dans la partie précédente, nous avons vu qu’il était possible de maintenir les services sur l’un
ou l’autre des serveurs. Il reste toutefois un problème : les données doivent être, elles aussi,
maintenues. La solution la plus simple est de faire une réplication via le réseau, a chaque fois
qu’une modification est faite. C’est le rôle de DRBD.
Page 167 sur 248

DRDB est un module noyau accompagné de scripts qui permet de créer un périphérique de
stockage. Il est possible de répliquer ce périphérique sur une autre machine, via une interface
dédiée (ou non).
Ce service est relativement simple à mettre en place et le meilleur moyen de l’expliquer est de
prendre un cas concret. Supposons que nous ayons un serveur avec un serveur Web (Apache)
et une base de donnée (MySQL). Chaque processus utilise des données qui sont dans un
répertoire distinct :
Périphérique
Nom Nom DRBD Périphérique DRDB Point de montage
physique
Apache Drbd0 /dev/nb0 /dev/sda1 /ha/web
MySQL Drbd1 /dev/nb1 /dev/sda2 /ha/mysql
Il faut donc remplir le fichier « drbd.conf » pour spécifier cette configuration :

# WEB
resource drbd0 {
net {
sync-group=0
}
on node1 {
device=/dev/nb0
disk=/dev/sda1
}
on node2 {
device=/dev/nb0
disk=/dev/sda1
}
}
# BdD
resource drbd1 {
net {
sync-group=1
}
on node1 {
device=/dev/nb1
disk=/dev/sda2
}
on node2 {
device=/dev/nb1
disk=/dev/sda2
}
}
Cela suffit au bon fonctionnement de DRDB.
Par contre, il est intéressant de superviser ce système avec HeartBeat. Dans ce cas, il faut
rajouter ces deux lignes dans la configuration de HeartBeat :
node1 datadisk::drbd0 Filesystem::/dev/nb0::/ha/web httpd
node2 datadisk::drbd1 Filesystem::/dev/nb1::/ha/mysql mysqld
Nous avons donc désormais une disponibilité au niveau des services et des données.
Page 168 sur 248

6) Supervision
Même si le système est redondant, il est important d’en avoir une visualisation globale. De
plus, en cas de défaillance d’un composant, il faut faire remonter l’information vers la
personne responsable. Cette supervision se fait à 3 niveaux :
- au niveau des fournisseurs d’accès Internet, pour vérifier que la bande passante
disponible est suffisante
- au niveau logiciel, afin de vérifier que tous les processus critiques fonctionnent
correctement.
- au niveau matériel, il est important d’avoir une remonté d’information sur l’état
physique du système : la température, l’état de la mémoire, des disques durs, des
connections réseaux, etc.
a) Fournisseurs d’accès Internet

Désormais, tous les fournisseurs d’accès Internet proposent d’avoir une visualisation du trafic.
Cela permet de connaître l’utilisation de la bande passante et d’estimer si oui ou non, le lien
est correctement dimensionné.
Ci-dessous, l’exemple d’une courbe tracée avec les informations d’un routeur sur une ligne
SDSL :
b) Logiciel : Nagios
Avec l’accroissement incessant des LAN et des WAN, il devient indispensable de mettre en
oeuvre de bons moyens de surveillance et d’alerte. Nagios est une solution open source
entièrement configurable permettant de répondre à ce besoin.
Voici l’étendue des possibilités de monitoring apportée par Nagios :
- Surveillance des services réseaux (SMTP, POP3, HTTP, NNTP, PING, etc.)
- Surveillance des ressources des hôtes (charge processeur, utilisation des disques, etc.)
- Système simple de plugins permettant aux utilisateurs de développer facilement leurs

propres vérifications de services.
- Parallélisation de la vérification des services.
Page 169 sur 248

- Possibilité de définir la hiérarchie du réseau en utilisant des hôtes parents, ce qui
permet la détection et la distinction entre les hôtes qui sont à l’arrêt et ceux qui sont
injoignables.
- Notifications des contacts quand un hôte ou un service a un problème et est résolu (via
email, pager, ou par méthode définie par l’utilisateur)
- Possibilité de définir des gestionnaires d’évènements qui s’exécutent pour des

évènements sur des hôtes ou des services, pour une résolution des problèmes pro-
active
- Rotation automatique des fichiers log
- Support pour l’implémentation de la surveillance des hôtes de manière redondante
- Interface web optionnelle, pour voir l’état actuel du réseau, notification et historique
des problèmes, fichiers log, etc.
Principe de fonctionnemment
Théorie des plugins
Contrairement à beaucoup d’autres outils de supervision, Nagios ne dispose pas de
mécanisme interne pour vérifier l’état d’un service, d’un hôte, etc. A la place, il utilise des
programmes externes appelés plugins. En fonction de la configuration définie par
l’administrateur, Nagios, qui n’est un fait qu’un noyau (core), exécute les plugins et analyse
les résultats obtenus.
Voici comment on peut schématiser le fonctionnement de base :
Ressources
Plugin ou Services
Locaux
Processus Nagios
(Noyau) Plugin
Ressources
Plugin ou Services
Distants
Hôte
Hôte local
local Hôte
Hôte distant
distant
Principe
Principe de
de fonctionnement
fonctionnement de
de Nagios
Nagios
Concrètement, comme le montre ce schéma, il est possible d’effectuer des tests de toutes
sortes sur la machine Nagios (fonctionnement de services, espace disque, charge, ...). On peut
également effectuer des tests sur des machines distantes, mais dans la mesure où il s’agit de
Page 170 sur 248

test simples, c’est-à-dire par exemple ping. En effet, on ne sait pas, à priori, tester l’espace
disque d’une machine distante de manière simple.
Fonctionnalités avancées
Il reste donc le problème des tests avancés sur un hôte distant comme la vérification de
l’espace disque.
Nrpe et nsca
La première réponse apporté par le concepteur de Nagios est nrpe : Nagios Remote Plugin
Executor. Il s’agit en fait d’un plugin à part entière, mais qui a la particularité de permettre
l’exécution d’un autre plugin, cette fois-ci, sur la machine distante. Ce système utilise le
démon nrpe, installé au préalable sur la machine distante. Le plugin check_nrpe va permettre
à la machine Nagios d’envoyer l’instruction au démon nrpe d’exécuter un test avancé en local
sur la machine distante.
Cependant, nrpe constitue une méthode de surveillance dite active, c’est-à-dire que l’initiateur
et ordonnanceur des tests est la machine Nagios. Une autre solution envisageable est la
méthode dite passive. Dans ce cas, ce n’est plus la machine Nagios qui est à l’origine des
tests. Un client nsca (Nagios Service Check Acceptor) est installé, configuré et lancé sur
chaque hôte distant, de sorte à envoyer spontanément à la machine Nagios, exécutant le
démon nsca, des résultats de tests. Nagios pourra dès lors voir ces résultats quand il le
souhaitera.
Cette méthode présente l’avantage de ne pas avoir à ouvrir de port sur le firewall en entrée de
réseau (jonction internet/réseau). En effet, comme les informations sont envoyées par le client
nsca vers le démon présent sur la machine Nagios, il suffit juste de permettre le passage des
informations dans le sens sortant sur le firewall.
Page 171 sur 248

Hôte
Hôte distant
distant 22 Hôte
Hôte distant
distant 33
Ressources
ou Services
Distants Méthode
Plugin
Active
Ressources
ou Services
Distants
NSCA NRPE Plugin
Méthode
Passive
NCSA Plugin
Ressources
Plugin ou Services
Locaux
Processus Nagios
(Noyau) Plugin
Ressources
Plugin ou Services
Distants
Hôte
Hôte local
local Hôte
Hôte distant
distant 11
NRPE
NRPE et
et NSCA
NSCA
En pratique
Voici quelques copies d’écrans qui illustrent les fonctionnalités de Nagios :
Page 172 sur 248

Page 173 sur 248

Page 174 sur 248

Nagios et Asterisk
Asterisk est le cœur de notre système. Il est donc primordial que Nagios puisse le superviser.
Asterisk accepte qu’on accède à ses informations grâce à un système de management. Ce

système se configure dans le fichier « manager.conf ». Ainsi, on peut rajouter une entrée pour
que Nagios puisse accéder aux informations d’Asterisk :
[nagios]
secret = XyXyXyXyXy
permit=127.0.0.1/255.255.255.0
read = system
write = log
Comme nous l’avons déjà dit, Nagios fonctionne avec des scripts. Il faut donc faire un script
capable de tester Asterisk :
#!/usr/bin/perl
# Script en Perl pour tester la connectivité d’Asterisk
$ENV{'PATH'}='';
$ENV{'BASH_ENV'}='';
$ENV{'ENV'}='';
$| = 1;
use Net::Telnet ();

use File::Basename;
use lib "/usr/local/nagios/libexec";
use utils qw(%ERRORS);
Page 175 sur 248

my $mgr_user = "<MANAGER_USER>";
my $mgr_secret = "<MANAGER_PATH>";
my $failed = 0;
my $reason = undef;
my $server_ip = "<MANAGER_HOST>";
#on configure une session telnet sur le port 5038

$tn = new Net::Telnet (Port => 5038,
Prompt => '/.*[\$%#>] $/',
Output_record_separator => '',
Errmode => 'return'
);
#on essaye d’ouvrir cette session
$tn->open($server_ip);
#on attend une réponse
$tn->waitfor('/0\n$/');
#on envoit le login et le mot de passe
$tn->print("Action: Login\nUsername: $mgr_user\nSecret: $mgr_secret\n\n");
#soit ca marche pas
unless($tn->waitfor('/Authentication accept*/'))
{
$failed = 1;
$reason = "Failed Connect";
}
#soit ce marche
else
{
$tn->print("Action: Ping\n\n");
#et dans ce cas on fait des tests
unless($tn->waitfor('/Pong/'))
{
$failed = 1;
$reason = "Pas de Pong";
}
else
{
$tn->print("Action: Logoff\n\n");
}
}
print "Asterisk PBX est Ok\n" unless $failed;

print "Impossible de se connecter à Asterisk ($reason)\n" if $failed;
exit $ERRORS{'CRITICAL'} if $failed;

exit $ERRORS{'OK'};
exit 0;
__END__
Soit le système est dans un état critique et dans ce cas le script nous l’indique, soit le système
est opérationnel.
Il faut donc indiquer à Nagios que ce script existe. Pour cela on va créer une commande
« Check_pbx » qui va exécuter ce script. Pour ça, il faut rajouter dans le fichier
« checkcommands.cfg » les commandes suivantes :
define command{
command_name check_pbx
Page 176 sur 248

command_line /etc/asterisk/monitor_pbx.pl
}
Finalement, on peut définir le service Asterisk dans Nagios. Cela se fait dans le fichier
« services.cfg » :
define service{
use generic-service
host_ pbxhost
service_description AsteriskPBX
is_volatile 0
check_period 24x7
contact_groups helpdesk
max_check_attempts 10
normal_check_interval 5
retry_check_interval 1
notification_interval 60
notification_period 24x7
notification_options w,u,c,r
check_command check_pbx
}
Notre serveur « pbxhost » est donc désormais supervisé par Nagios et si jamais le service
n’est plus opérationnel, on sera informé.
c) Matériel : Server View

En complément des logiciels mentionnés ci-dessus, FUJITSU a développé des outils pour la
gestion des grappes de PC de grande dimension. Ces outils sont regroupés dans le module
ServerView.
ServerView contrôle et évalue les systèmes ainsi que les unités de stockage connectées au
réseau, et fournit les données les plus importantes concernant la charge du système et l'état
actuel de ses divers éléments. ServerView est fourni avec les serveurs Fujitsu-Siemens.
Les principales caractéristiques de ServerView sont:
- Gestion du serveur par l'intermédiaire d'un ou de plusieurs systèmes centralisés de

contrôle, dans un réseau local ou un WAN. L'extension Web de ServerView permet
aux informations du serveur d'être également consultées en utilisant un navigateur
web.
- Détection préventive des faiblesses (PDA - Pre-failure Detection & Analysis) et

analyse des disques durs, des ventilateurs, et des batteries
- Fonctions de reprise pour la reconfiguration automatique du système et le redémarrage

correct en cas d'erreur
- ServerView est basé sur les normes SNMP
- Intégration facile dans de nombreux systèmes, réseau ou systèmes de gestion

d'entreprise
- Visualise les informations disponibles au standard SNMP provenant d'autres

constructeurs par l'intermédiaire d'un navigateur MIB
Page 177 sur 248

- Configuration fiable et facile des alarmes et utilitaires de transfert des alarmes
ServerView - gestion et contrôle

Le programme de gestion (ServerView Manager) fonctionne sur un système de contrôle
central et possède une interface utilisateur de type Windows. Il centralise toutes les
informations concernant la configuration des serveurs et l'état courant des opérations, et, en
cas d'erreur, il peut contrôler le comportement des serveurs.
Les agents sont des applications spécifiques qui s'exécutent sur les systèmes à contrôler. Ils
recueillent l'information demandée par le gestionnaire et la lui transmettent. Les agents
peuvent également transmettre au gestionnaire des événements exceptionnels sur les serveurs,
concernant des pannes sur la ventilation, la charge du processeur, la température, etc. Ceci
signifie que - si des valeurs spécifiées sont dépassées, ou si le système a un incident - des
mesures correctives peuvent être lancées en temps utile. ServerView dispose d'agents SNMP
pour la plupart des systèmes d'exploitation : NT 4 et Windows 2000, de Microsoft, NetWare
de Novell, Linux (SuSe et Red Hat), UnixWare (pour certains serveurs), de SCO, OS/2 Warp
Server (pour certains serveurs) d’IBM.
Console de Intégration pour

Management le management
Station de
Management
Serveur
administrés
Architecture
Architecture ServerView
ServerView
Fonctionnalités
ServerView complète parfaitement Nagios en apportant d’autres fonctionnalités :
- Serveur de liste - affiche les informations de tous les serveurs et ordinateurs du réseau,
de manière graphique et synthétique.
Page 178 sur 248

- Supervision - ServerView affiche des informations détaillées sur tous les composants
serveurs : processeurs, mémoire, niveau d'utilisation des bus PCI, alimentations (UPS
inclus), ventilateurs, température, contrôleurs et disques, réseau.
- Gestion des pannes - Le transfert des données de configuration d'un serveur à un autre
par le réseau permet de gagner un temps considérable pendant l'installation et la
reconfiguration du système.
- Gestion d'alarme - a pour but d'informer l'administrateur sur les erreurs système d'une
manière rapide, correcte, et fiable. ServerView offre des fonctionnalités de gestion
d'alarme, simples à configurer, depuis l'affichage et la journalisation des alarmes,
jusqu'à l'appel téléphonique.
- Gestion de seuil - contrôle de manière permanente certains paramètres du système

pour vérifier s’ils dépassent des limites prédéfinies.
- « Watchdog » - si un échec est détecté (boot, logiciel) l'élément en cause sera

automatiquement relancé. Le seuil de déclenchement d'un « watchdog » est
configurable.
- Détection rapide d'anomalie - les fonctionnalités du PDA permettent de remplacer

avant qu'ils ne soient réellement défectueux. ServerView fournit actuellement ce
service pour les ventilateurs, la batterie CMOS et les disques.
- Reconfiguration du serveur et relance automatiques (ASR&r) - si une défaillance

survient sur un composant matériel ou sur le système, le serveur essaie de le relancer
indépendamment de celui-ci (ignorant les composants matériels défectueux).
- Gestion des rapports - pour le contrôle, l'analyse de tendance et la planification de

capacité à long terme sur le serveur. L'affichage des données est possible sous forme
de tableaux ou de graphiques.
- Gestion de versions (InventoryView) - les composants matériels du système, les

versions du microprogramme, du BIOS ainsi que des différents pilotes peuvent être
inventoriés facilement et rapidement. Ces données peuvent être exportées, par
exemple, vers Excel ou Access de Microsoft.
- Gestion de cycle de vie (Archive Manager) - permet aux administrateurs de stocker et

vérifier les données d'exploitation et les données système du serveur dans un site
central et en facilite le contrôle en comparant les données de différentes générations
d'archives. Tous les changements sont mis en évidence par des changements de
couleur. En cas d'erreur, ils peuvent réagir rapidement, tracer les sources d'erreurs plus
aisément et maintenir un coût d'entretien bas. La planification d'investissement pour
mise à niveau du serveur devient plus facile et plus sécurisée.
- Sécurité - toutes les fonctions permettant de configurer ou de modifier le

comportement du serveur sont protégées par un système de mot de passe.
- Intégration de ServerView avec d'autres systèmes de gestion.
- Support de cluster - ServerView supporte ClusterServer de Microsoft. ServerView

détecte tous les clusters MS sur le réseau, sur lesquels les agents de ServerView sont
Page 179 sur 248

installés. Les clusters sont identifiés par des icônes spéciales dans la catalogue des
serveurs.
- Alimentation sans coupure - ServerView intègre la gestion des alimentations sans

interruptions (UPS), et l'affichage de leurs états sous forme graphique. Un problème
peut, si besoin est, déclencher une alarme.
- Web Extension - L'option Web Extension de ServerView permet d'accéder à toutes les
informations via Internet ou Intranet, à tout moment, en tout lieu et depuis tout
système d'exploitation supportant des navigateurs Internet standard.
7) Management
La gestion d’un cluster n’est pas une tache facile. Même si la solution ne compte actuellement
moins d’une dizaine de machines, il n’est pas improbable que la centaine soit dépassé un jour.
Ainsi, il faut mettre en place dès maintenant les processus pour gérer un tel parc :
l’installation, la maintenance, etc.
a) xCAT
Introduction
xCAT est un outil gratuit proposé par IBM. Il permet d’automatiser la plupart des taches liées
à l’installation et à la configuration d’un cluster.
xCAT est un ensemble de script (korn shell, perl et Expect). Il est donc facile de les modifier.
Les fonctionnalités offertes par xCAT peuvent être séparé en quatre familles : l’installation, la
maintenance, l’administration et l’accès distant
L’installation
xCAT offre différents composants pour une installation automatique :
- Démarrage via le réseau (PXE ou Etherboot/GRUB)
- Installation de l’OS avec Kickstart
- Possibilité d’image et de clone
- Configuration automatique
- Mise à jour automatique
La maintenance
Les options de maintenance dépendent du matériel utilisé. En effet, xCAT ayant été
développé par IBM, il supporte principalement des serveurs IBM eServer. Par ailleurs,
ServerView offre des options beaucoup plus poussées.
Page 180 sur 248

L’administration
xCAT offre des outils pour la gestion du cluster :
- Exécution de commandes en simultanés sur plusieurs nœuds
- Copie et synchronisation de fichiers en parallèle
- Des assistants pour l’installation d’autres outils.
L’accès distant
xCAT offre la possibilité de se connecter à distance aux différents nœuds, grâce à une
compatibilité avec différents composants :
- Equinox ELS et ESP
- iTouch In-Reach et LX
- RCR de IBM
- VNC
Installation du nœud de gestion

Une fois que tous les nœuds sont connectés, il faut commencer l’installation du cluster. Pour
cela on commence par le nœud de gestion. Ce nœud va également servir de nœud
d’installation pour installer les nœuds de calcul.
L’installation du nœud de gestion se fait de la manière suivante :
- Installation du système d’exploitation (Suse)
- Installation des mises à jour pour le système d’exploitation
- Configuration du réseau
- Installation et configuration de xCAT
- Remplissages des tables de xCAT (les tables contiennent les informations du cluster)
- Configuration des différents services : authentification, DNS, DHCP, TFTP, NFS,

NTP, SSH et SNMP
Installation du cluster
Une fois le nœud de gestion complètement configuré, il faut configurer et installer les autres
composants du cluster. Il y a quatre étapes :
- Configuration du matériel
- Récupération des adresses MAC
Page 181 sur 248

- Configuration de RemoteView (Accès distant de Fujitsu-Siemens)
- Installation des nœuds
Une fois le matériel configuré et les adresses MAC récoltées, il est possible de lancer
l’installation et la configuration des nœuds depuis le nœud de gestion. Durant l’installation,
tous les nœuds vont démarrer sur le réseau, se connecter au serveur de gestion et démarrer
l’installation automatiquement :
Page 182 sur 248

Nœuds de Nœud de
calcul Gestion
Requête DHCP
Configuration IP
Serveur DHCP
Adresse IP du serveur TFTP
Démarrage via le Nom du fichier Boot
réseau avec le
PXE
Requête pour le bootloader

Bootloader pxelinux.0
Requête configuration du bootloader

Serveur TFTP
Configuration du bootloader
Bootloader Requête noyau Linux

pxelinux.0 Noyau Linux
Requête du RamDisk initial
Initial RamDisk
Requête des fichiers de démarrage rapide

Installation Linux Fichiers de démarrage rapide
Requête des fichiers d’installation Linux
NFS Serveur
Fichiers d’installation Linux
Requête des fichiers post installation
Fichiers post installation
Scripts post
installation
Configuration du nœud pour démarrer sur un disque local SSH
Requête PXE Serveur DHCP/

Redémarrage
Démarrage en local TFTP
Démarrage sur
un disque local
Installation
Installation automatique
automatique d’un
d’un nœud
nœud de
de calcul
calcul
Comme le montre le schéma ci-dessus, le processus d’installation utilise une installation

rapide via NFS. Dans le cluster, tous les nœuds sont configurés pour démarrer sur le réseau en
premier. Chaque nœud a un fichier de démarrage qui est manipulé par xCAT. Les fichiers de
Page 183 sur 248

configuration sont stockés dans le répertoire « tftpboot/pxelinux.cfg/ ». Dans le cas d’un
problème réseau, le nœud démarre sur son disque local.
Quand un nœud démarre sur le réseau, il fait une requête DHCP pour obtenir la configuration
du réseau. Le serveur DHCP lui retourne une adresse IP et les autres paramètres. Il retourne
également le nom du fichier de démarrage (Bootfile) et l’adresse IP du serveur TFTP où il se
trouve. Le fichier de démarrage utilisé par linux est appelé « pxelinux.0 »
Le nœud télécharge le fichier « pxelinux.0 » sur le serveur TFTP et l’exécute. Le programme

de démarrage va alors récupérer le fichier de configuration du nœud en convertissant son
adresse IP en un nombre en hexadécimal. Il va alors essayer de récupérer un fichier ayant ce
nom sur le serveur TFTP. Si il ne le trouve pas, il réessaye en enlevant le dernier chiffre. Si le
programme PXE ne trouve aucun fichier, il essaye de télécharger le fichier « default ».
Ainsi, si l’adresse IP est 10.9.0.1, la valeur convertie en hexadécimal est 0A090001 et le

résultat du PXE est :
Trying to load: pxelinux.cfg/0A090001
Trying to load: pxelinux.cfg/0A
Trying to load: pxelinux.cfg/0
Trying to load: pxelinux.cgf/default
Cette méthode permet donc une gestion simple et rapide des noeuds de calcul. Pour installer
un nouveau nœud, il suffit d’activer le démarrage via le réseau et xCAT fera le reste.
b) VPN
Les réseaux locaux d'entreprise (LAN ou RLE) sont des réseaux internes à une organisation,
c'est-à-dire que les liaisons entre machines appartiennent à l'organisation. Ces réseaux sont de
plus en plus souvent reliés à Internet par l'intermédiaire d'équipements d'interconnexion. Il
arrive ainsi souvent que des entreprises éprouvent le besoin de communiquer avec des filiales,
des clients ou même du personnel géographiquement éloignées via internet.
Pour autant, les données transmises sur Internet sont beaucoup plus vulnérables que
lorsqu'elles circulent sur un réseau interne à une organisation car le chemin emprunté n'est pas
défini à l'avance, ce qui signifie que les données empruntent une infrastructure réseau
publique appartenant à différents opérateurs. Ainsi il n'est pas impossible que sur le chemin
parcouru, le réseau soit écouté par un utilisateur indiscret ou même détourné. Il n'est donc pas
concevable de transmettre dans de telles conditions des informations sensibles pour
l'organisation ou l'entreprise.
La première solution pour répondre à ce besoin de communication sécurisé consiste à relier

les réseaux distants à l'aide de liaisons spécialisées. Toutefois la plupart des entreprises ne
peuvent pas se permettre de relier deux réseaux locaux distants par une ligne spécialisée, il est
parfois nécessaire d'utiliser Internet comme support de transmission.
Un bon compromis consiste à utiliser Internet comme support de transmission en utilisant un

protocole d'"encapsulation" (en anglais tunneling, d'où l'utilisation impropre parfois du terme
Page 184 sur 248

"tunnelisation"), c'est-à-dire encapsulant les données à transmettre de façon chiffrée. On parle
alors de réseau privé virtuel (noté RPV ou VPN, acronyme de Virtual Private Network) pour
désigner le réseau ainsi artificiellement créé.
Ce réseau est dit virtuel car il relie deux réseaux "physiques" (réseaux locaux) par une liaison
non fiable (Internet), et privé car seuls les ordinateurs des réseaux locaux de part et d'autre du
VPN peuvent "voir" les données.
Le système de VPN permet donc d'obtenir une liaison sécurisée à moindre coût, si ce n'est la
mise en oeuvre des équipements terminaux. En contrepartie il ne permet pas d'assurer une
qualité de service comparable à une ligne louée dans la mesure où le réseau physique est
public et donc non garanti.
Ce système peut être facilement mis en place grâce aux Firewall Ingate. Cela permet par
exemple de relier le cluster à certains clients qui ont besoin d’un haut niveau de sécurité, ou à
un centre de supervision :
Solution
Hébergée
Firewall
Ingate
VPN VPN
Internet
LAN
Supervision Client
BSNetwork Critique
Utilisation
Utilisation de
de VPNs
VPNs
Page 185 sur 248

c) Carte de prise en main à distance

La solution étant hébergée, il est très difficile d’y acceder. Ainsi, en cas de probleme sur une
alimentation ou sur un processeur, il est indispensable de se déplacer. Dans le cas d’une
architecture critique, cela n’est pas possible.
Fujitsu-Siemens propose une carte de connection à distance qui est independante du système.
La « Remote Service Board » ou RSB est un système autonome. L’accès LAN et

l’alimentation sont séparés. Elle intègre un serveur Web et un agent SNMP :
Il est possible, grâce à cette carte, de faire une redirection des flux clavier, souris et vidéo. Il
est également possible de simuler un lecteur. Il est ainsi possible de démarrer le serveur à
partir d’un périphérique distant installé sur une station de management. Cela signifie que l’on
peut réinstaller le serveur à distance si nécessaire…
L’image suivante nous montre la rédirection du flux vidéo :
Page 186 sur 248

Page 187 sur 248

XI. Exemples d’implémentation

1) BSNetwork
BSNetwork a toujours été le premier site de test. L’architecture y était en perpétuelle
mouvement afin d’effectuer de nouveaux tests. Toutefois, il faut signaler que les locaux ne
permettaient pas d’utiliser des passerelles VoIP. Ainsi, la téléphonie classique cohabite avec
le téléphonie IP.
2) Pandatrade
Pandatrade dispose déjà d’équipement en provenance de BSNetwork. La solution
BS@VoiceLan est positionnée en parallèle des autres offres (Firewall en particulier) :
Pandatrade Internet
Opérateur
VoIP
Colt Via Oléane
France
Telecom
ISDN
WallLan
Wall
Sip Firewall
Premium
LAN
VoiceLan Passerelle
Ordinateur
PhoneIP
Serveur
Téléphonie
Téléphonie IP
classique
3) Marionnaud
L’objectif chez Marionnaud est d’équiper au final le site de Vincennes en tout IP :
Page 188 sur 248

Vincennes
France
iPBX hébergé Telecom
Opérateur
VoIP
WAN
iPBX
France
Telecom
ISDN
FireWall SIP
LAN
Passerelle VoIP
Ordinateur
Téléphones IP
Téléphonie Serveur
classique Téléphonie IP
Il est alors possible de supprimer la téléphonie classique. De plus, en installant des passerelles
sur les autres sites, les communications entre sites deviennent gratuites.
4) CNPS
Le CNPS est composé du siège et de 6 agences. L’architecture proposée a été la suivante.
Page 189 sur 248

a) Architecture globale
Réseau Global
20/10/2004 300 postes
1E
LINK
ACT
ETH 0
EN
SERIAL A/S
7 6 5 4
Cisco 3640
2 NM-1E
EN
3 2 1 0
1E
ISDN
ETH 0
LINK
ACT EN
2 * T2
1 NM-8A/S PABX
Alcatel
/s
s/s bits Ra
Mbit M 6,5 M dio
io 6,5 6,5
Rad dio bits/s
Ra
CONN SERIAL CONN SERIAL CONN SERIAL CONN SERIAL CONN SERIAL CONN SERIAL
Cisco 1605 R Cisco 1605 R Cisco 1605 R Cisco 1605 R Cisco 1605 R Cisco 1605 R
55 postes 49 postes 57 postes Cocody Abobo Koumassi
Yopougon 60 postes 20 postes Postes ?

Adjamé Treichville
CMS
PABX PABX PABX

Matra Hicom ?
70 postes
1 * T2 ?
?
Yopougon Yopougon
C. d’appareillage CIFOCSS
ISDN
b) Siège central
ISDN
6 agences
1E
ETH 0
SERIAL A/S
Cisco 3640 2 * T2
2 NM-1E
7 6 5 4
LINK
ACT EN
EN
3 2 1 0
1E
ETH 0
LINK
1 NM-8A/S
ACT EN
Passerelle VoIP
LAN
PABX
Alcatel
Postes IP
IP PBX
300 postes
Siège de la CNPS
20/10/2004
Page 190 sur 248

c) Agences
L’architecture est relativement identique pour l’ensemble des agences. Ci-dessous, l’exempel
de Cocody :
Radio
Siège
6,5 Mbits/s
ISDN
Cisco 1605 R
CONN SERIAL
1 WIC-1T T2
LAN Passerelle VoIP
PABX Matra
Postes IP
Site de Cocody 60 Postes

20/10/2004
Page 191 sur 248

XII. Migration
1) Introduction
Une migration vers la VoIP doit se faire de manière rigoureuse sinon le projet est voué à
l’échec.
Tout d’abord il faut préparer la migration en vérifiant les infrastructures réseaux LAN/WAN
et téléphoniques existantes. Il est également nécessaire de communiquer avec l’administration
de la téléphonie et les utilisateurs.
Ensuite, la migration peut se faire de manière douce ou brutale (rupture) en fonction de

l’ancienneté du parc de terminaux téléphoniques, du montant des investissements non
amortis, de l’hétérogénéité des matériels, du profil des utilisateurs et de la cohérence s’il y a
plusieurs sites.
Enfin, il faut planifier les actions et les budgets.
2) Les acteurs
Actuellement, les acteurs qui proposent des solutions VoIP sont soit issus de la téléphonie
classique, soit issus du monde des réseaux IP. Ces derniers arrivent avec une perspective de
conquête, alors que les autres font du protectionnisme.
Chaque acteur possède ses défauts et ses qualités pour la VoIP :

Acteurs issus de la téléphonie
Acteurs issus du monde de l’IP
classique
Il y a un existant au sein de Discours du tout IP en
l’entreprise : connaissance des concordance avec la politique des
problématiques clients et contacts entreprises visant à rationaliser les
directs avec les décideurs télécoms infrastructures et les équipes de
gestion
Avantages
Connaissance fine du modèle des
coûts d’exploitation de la téléphonie Maîtrise des solutions IP et du
routage
Robustesse et fiabilité des solutions
classiques éprouvées Nouvelles fonctionnalités
Perception par les décideurs d’un
Positionnement non « Ip centric » déficit de maturité des solutions de
téléphonie
Problématique de cannibalisation avec
Inconvénients
l’offre existante : discours client Connaissance moindre des
orienté vers l’IP ou les solutions modèles économiques de
traditionnelles ? l’exploitation relatifs à la
téléphonie
Page 192 sur 248

3) Méthodologie
Quel que soit l’acteur, le passage vers la VoIP doit se faire de manière méthodique.
a) Collecte d’informations
La première chose à faire est de recenser l’existant et de collecter les informations
pertinentes :
- Locaux techniques, câblages téléphoniques et informatiques
- L’architecture du réseau téléphonique
- L’architecture du système d’information (serveurs, applications)
- Terminaux téléphoniques existants, localisations,
- Plan de numérotation
- Configuration des équipements réseaux téléphoniques (pabx, messageries, ACD…) et

réseaux informatiques (switches, routeurs, fonctions de priorité, Vlan, …)
- La politique sécurité
- La configuration des terminaux informatiques
- Plan d'adressage IP,
- L’organisation de l’exploitation de la téléphonie et de l’informatique
- Fonctionnalités déployées
- Les applications périphériques : alarmes, rondier, ...
- Les trafics inter-sites en téléphonie et data
- Les coûts (consommations, exploitation, maintenance, standard, services)
- La sécurisation
- Audit approfondi de la qualité des réseaux
b) Analyse de données
A partir des données collectées, il faut identifier les besoins et les contraintes. Tout d’abord,
quels sont les besoins des utilisateurs en fonction de leurs profils et de leurs métiers (fonctions
téléphoniques de base ? évoluées ? ou une véritable convergence Voix et Données ?). Ensuite,
est-ce qu’il existe des communications inter sites ? Dans ce cas, il faut faire la matrice de
trafic par profil de poste. De même, il faut étudier le besoin en termes de sécurité et de
disponibilité, en fonction du site et de l’utilisateur.
Page 193 sur 248

En fonction de la politique immobilière et de l’administration téléphonie, il faut faire le
planning prévisionnel de déploiement des terminaux et des applications (messageries, CRM,
…). Pour cela, il est nécessaire de faire une grille de besoins classée par priorité.
c) Conception de l’architecture cible

Les scénarios d’architecture sont nombreux. De plus, pour chaque entreprise il faut analyser
des scénarios intermédiaires en fonction de la complexité de design des solutions
(modélisation du trafic voix et données, architecture réseau, architecture informatique,
sécurisation, sécurité, cohabitation de deux architectures) et des impacts financiers.
d) Le plan directeur
La fin de l’étude sur la migration vers la technologie VoIP se termine par la rédaction d’un
plan directeur de migration de la téléphonie.
Ce plan directeur doit tout d’abord désigner les objectifs et leurs priorités.
Ensuite, il est essentiel de présenter et de justifier l’architecture cible.
Il faut planifier les phases de migration technique, en déduire des plannings de mise à jour des
infrastructures et évaluer les budgets correspondants.
Enfin, il faut planifier les phases correspondantes de migration de l’organisation et des

procédures d’exploitation. Cela doit prendre en compte un budget formation.
e) Phase pilote
Afin de valider la solution, il faut valider l’acceptabilité des utilisateurs. Pour cela, un nombre
restreint d’utilisateurs en IP est migré en IP. En fonction de leurs remarques, il faut adapater
le plan de migration.
f) Migration
La migration doit se faire de manière progressive (services, agences, domaines applicatifs,
etc.), à des périodes creuses (La nuit, le week-end, etc.) et au rythme des capacités
d’investissement.
Page 194 sur 248

XIII. Perspectives et enjeux économique

Aujourd'hui, le principal attrait de la téléphonie sur IP est économique, comme le montre le
graphique suivant. En effet, en utilisant Internet pour transmettre les communications longue
distance, l'utilisateur ne paie que le prix d'une communication locale. La demande croissante
pour des communications multimédia et pour l'intégration de la voix et des données sont
également deux autres bénéfices de la téléphonie sur IP.
Motivation pour l'IP

Changement
de PABX Autres
Economie
Simplicité de 3%
8% 29%
gestion
12%
Nouveaux
Stratégie
services
25%
23%
Parmi tous les acteurs de la téléphonie sur IP, les opérateurs de télécommunications tiennent
une place prépondérante. L’enjeu est de taille puisque le marché ciblé concerne aussi bien les
entreprises que les particuliers. Le développement d’offres de transfert de voix basées sur le
protocole IP constitue potentiellement un élément majeur du marché des télécommunications.
De nos jours, la majorité des communications téléphoniques a lieu sur le réseau commuté
(RTC) mais la tendance risque de s’inverser.
Du coté des opérateurs, le transport de la voix sur les réseaux de données présente plusieurs
avantages :
- Une seule infrastructure à gérer.
- Une bande passante optimisée grâce aux techniques de compression (et la possibilité
de supprimer les silences).
- Un effet stimulateur d’Internet qui permet l’arrivée de nouveaux abonnés.
Pour les utilisateurs et les fournisseurs de services, deux principales raisons justifient
l’utilisation de cette technologie :
- Les économies réalisées sur les appels longues distance : il est possible d’appeler
n’importe où dans le monde pour le prix d’une communication locale. Ces économies
sont toutefois nuancées en raison de la baisse des prix introduite par la concurrence
nationale.
Page 195 sur 248

- La possibilité de disposer de nouveaux services sans changer de réseau de transport.
Si le développement en entreprise apparaît évident, nous ne connaissons pas l’ampleur qu’il

prendra et s’il supplantera à long terme le réseau téléphonique traditionnel. Une chose est
sûre, la croissance du phénomène est étroitement liée aux facteurs suivants :
- La généralisation des passerelles.
- L’amélioration de la qualité de service.
- La pratique de tarifs très attractifs.
1) Etat de l’offre et de la demande

Plusieurs études prévoient une croissance importante des chiffres d'affaires relatifs du
domaine dans les années à venir. En termes de trafic, une étude de la Société Analysys donne,
exprimée en nombre de minutes, l'évolution du trafic international de la voix sur IP (voir
figure ci-dessous). Les chiffres méritent d'être rapprochés du trafic total de France Telecom
mentionné dans son rapport annuel de 1997, à savoir 138 milliards de minutes.
Appels Internationaux
50000 30
45000
25
40000
35000
20
30000 Minutes d'appel internationales
(Millions)
25000 15
Minutes d'appel internationales
20000 (%)
10
15000
10000
5
5000
0 0
1997 1998 1999 2000 2001 2002 2003
En termes d'offre, de nombreux constructeurs (plus d'une centaine rien que pour les
passerelles) offrent des systèmes (équipements et/ou logiciels) permettant à des internautes
sur PC d'ajouter la dimension vocale, à des entreprises d'interconnecter leurs PABX et leurs
réseaux intranet pour la voix, à des fournisseurs d'accès ou de service Internet d'offrir des
services de voix et de fax sur IP, etc. On peut en citer quelques uns comme Vocaltec, Lucent
technologies, 3COM, Nortel, Siemens,...
Des sociétés telles que IDT, Net2phone, Qwest, Deltathree, USA Global Link, ITXC Corp,
Sonera (Telecom Finland), Glocalnet (Suède), Networks Telphony Corporation, Concentric
Network, level 3, ICG Netcom, ... se sont érigées en ce que l'on a appelé plus haut des
"pseudo-opérateurs", c'est-à-dire qu'elles proposent à tout abonné au téléphone traditionnel de
bénéficier de tarifs attractifs en faisant passer leurs communications longue distance par
Internet via leurs passerelles.
Page 196 sur 248

Par ailleurs, comme on l'a dit plus haut, il existe des solutions, comme celle de la Société
française APLIO, à base de boîtiers d'adaptation pour connecter des postes téléphoniques sur
Internet (avec mise en œuvre sur Internet d'un serveur spécialisé, sans intervention de
l'utilisateur, pour établir les communications). La société singapourienne Innomedia
commercialise également des boîtiers de ce type.
Enfin, en France, les principaux constructeurs de télécommunications affinent leurs stratégies.

Alcatel prévoit d'offrir des produits de voix sur IP. CS Telecom développe des produits de
voix sur réseaux de paquets (Frame Relay actuellement, extension possible à l'IP notamment
sur Intranet) dans le contexte de son offre pour réseau interne d'entreprise et envisage de se
positionner sur le marché des passerelles.
Ainsi, en 2004, la pénétration moyenne de la téléphonie sur IP est estimée à 9% et ce, sans
réelle différence selon les profils de sites. Progressive jusqu’en 2006, elle devrait décoller
véritablement en 2007, portée notamment par un nombre significatif prévisible de
renouvellements de PABX traditionnels. Pour les sites de moins de 300 postes, la pénétration
sera supérieure à 50% en 2008 :
Pénétration de la téléphonie sur IP en France, par site
70
60
50
< 100 postes
40
100 - 300 postes
30
> 300 postes
20
10
0
2004 2005 2006 2007 2008
2) Les gains objectifs de la téléphonie sur IP

La première raison objective pour que les communications sur IP soient en principe moins
coûteuses que les communications sur réseau téléphonique commuté classique, est inhérente à
la mise en œuvre de la transmission de la voix par paquets qui, par nature, utilise mieux les
liaisons de télécommunications (tout au moins au-delà des liaisons terminales de
raccordement de l'utilisateur) que la technique de commutation de circuits qui dédie un circuit
de bout en bout à chaque communication téléphonique sans tenir compte des temps morts de
la conversation.
De plus, en téléphonie sur IP, pour s'accommoder des différents maillons de la chaîne côté
utilisateur (rapidité des modems notamment, dans le cas de l'utilisation de micro-ordinateurs),
on pratique une compression de l'information numérique qui fait passer la voix numérisée du
débit standard de 64 kbit/s à un débit de moins de 10 kbit/s, d'où là encore une meilleure
utilisation des liaisons.
Page 197 sur 248

Une troisième raison concerne la nature des équipements mis en œuvre : il s'agit, dans le cas
de la voix sur IP, d'équipements (serveurs, routeurs, etc.) en synergie avec les équipements du
monde de la microinformatique et qui, de ce fait, bénéficient des mêmes évolutions de coûts
que ce domaine. On aboutit ainsi à la mise en œuvre d'équipements moins sophistiqués (un
routeur est beaucoup moins rapide qu'un commutateur de circuits) et moins coûteux (mais
aussi avec des fonctionnalités plus rudimentaires) que les commutateurs qui interviennent
dans les réseaux de télécommunications.
Enfin, en vu de cette conception différente des équipements, on est conduit dans le cas de la
téléphonie sur IP à accepter des fonctionnalités différentes de celles de la téléphonie
classique, notamment en termes de qualité de service dans tous les sens du terme.
3) Le prix de la téléphonie sur Internet pour les particuliers

Sur le plan des prix pour l'utilisateur final, d'autres considérations viennent s'ajouter aux
économies intrinsèques de coûts.
Dans le cas d'une utilisation de micro-ordinateurs par deux internautes, il est clair que les
utilisateurs ne se sont pas équipés spécialement pour faire du téléphone. Ils ont donc tout
naturellement tendance à ne tenir compte d'aucun amortissement de leurs équipements
informatiques. Pour eux, au delà de l'acquisition éventuelle d'un logiciel spécialisé (en plus du
logiciel de voix dont on dispose déjà le plus souvent et que l'on peut de toutes façons
télécharger gratuitement) et d'un microphone (les haut-parleurs sont maintenant livrés "en
série"), le seul prix ressenti est celui d'une communication téléphonique locale, quelle que soit
la localisation géographique du correspondant.
Dans le cas d'une utilisation de type "PC to phone", on est à peu près dans la même situation ;
en particulier, dans le cas des applications vraisemblablement très prometteuses de type "PC
to Call Centre" (en accompagnement d'une transaction de commerce électronique), le prix
pour l'utilisateur est celui de la communication locale qu'il avait initiée pour se connecter sur
Internet en vue de sa transaction commerciale.
Dans le cas de l'utilisation de boîtiers d'adaptation, on a affaire à des applications très ciblées
du type de l'expatrié souhaitant garder un contact fréquent avec sa famille. Le prix à payer par
les utilisateurs doit être alors calculé en tenant compte à la fois des coûts de communication
(une voire deux communications locales, donc un prix dépendant des pays concernés) et de
l'incidence de l'amortissement du coût des boîtiers achetés des deux côtés (qui dépend bien
sûr du taux d'utilisation).
Enfin, les pseudo-opérateurs, par exemple fournisseurs d'accès (IAP) ou de services (ISP)
s'équipant en passerelles avec les réseaux téléphoniques locaux des zones géographiques
d'offre du service, sont bien évidemment amenés à répercuter, sur le prix facturé à l'utilisateur,
l'amortissement de tous les équipements installés par leur soins et à faire payer à l'utilisateur
un prix dépendant de l'usage effectif par ce dernier.
4) Le coût de la téléphonie sur IP pour une entreprise

Dans le cas d'une entreprise équipant ses PABX des systèmes nécessaires pour l'interface avec
son réseau intranet, voire avec Internet, un calcul d'amortissement de même nature que ce qui
a été indiqué ci-dessus est à faire. Il est clair que le cas le plus favorable, mais aussi le plus
répandu à terme, est celui où l'entreprise aura déjà mis en place un intranet pour des besoins
Page 198 sur 248

autres que la téléphonie. Dans ce cas, si l'entreprise opte pour l'utilisation de son intranet pour
transmettre le trafic téléphonique interne (notamment entre sites géographiques distants), elle
réalisera une véritable intégration voix-données au sein de son réseau d'entreprise. Il est
probable qu'elle en profitera pour ajouter des possibilités supplémentaires telles que la
téléconférence ou la visioconférence entre ses différents sites.
Page 199 sur 248

XIV. Conclusion
A travers ce travail j’ai dans un premier temps présenté la notion de Voix sur Internet qui est
d’actualité aujourd’hui. Depuis peu, il n’est plus considéré comme un service margina mais
bien comme le service appelé à supplanter le téléphone classique. La téléphonie sur Internet
se développe rapidement pour différentes raisons :
- Hyper rapidité sur Internet,
- Marché très porteur,
- Intérêts financiers en perspective,
Cela m’a permis d’introduire les différentes difficultés les fournisseurs d’équipement
d’infrastructure doivent faire face pour développer des réseaux de voix sur IP. Enfin, je me
suis intéressé à la présentation des protocoles et normes utilisées pour faciliter l’arrivée de
cette technologie ce qui m’a permis de m’apercevoir de nouveaux défis à relever pour les
constructeurs de terminaux et d’équipement d’infrastructure ainsi que pour les opérateurs
téléphoniques. Les opérateurs télécoms prennent la menace au sérieux, à tel point que certains
tentent de freiner cette évolution et d’autres mettent le réseau IP au centre de leur stratégie.
Tous les grands de l’informatique sont aujourd’hui de la partie. Actuellement, il est évident
que la téléphonie IP va continuer de se développer dans les prochaines années. Le marché de
la téléphonie IP est très jeune mais se développe à une vitesse fulgurante. C’est aujourd’hui
que les entreprises doivent investir dans la téléphonie IP si elles veulent y jouer un rôle
majeur.
Le fait est que IP est maintenant un protocole très connu et qui a fait ses preuves et que
beaucoup d’entreprises disposent ou vont disposer d’un LAN. Ceci est le grand avantage de la
téléphonie IP car elle demande un très faible investissement pour son déploiement. La
téléphonie IP ouvre la voie de la convergence voix/données et celle de l’explosion de
nouveaux services. De plus, maintenant que la normalisation a atteint une certaine maturité, il
n’est plus dangereux de miser sur le standard SIP qui a été accepté par l’ensemble de la
communauté. La téléphonie IP est donc une bonne solution en matière d’intégration, de
fiabilité, d’évolutivité et de coût.
Dès à présent, il est possible de prévoir qu'un développement substantiel devrait se faire dans
le domaine des télécommunications d'entreprises car c'est là que la notion d'intégration
complète voix-données pourra prendre toute sa dimension économique. Il est même
vraisemblable que c'est par ce biais que s'introduiront de nouveaux services tels que la
visiophonie, la téléconférence, la visioconférence, dont on parle depuis longtemps. Le
développement de la téléphonie entre passerelles, de poste ordinaire à poste ordinaire, est
quant à lui vraisemblablement voué, dans un premier temps, à un écrémage du trafic sur des
zones géographiques où une telle implantation s'avérerait rapidement rentable. Le
déploiement ira-t-il ensuite plus loin, par effet d'entraînement ? Probablement, comme le
laissent supposer les annonces qui se multiplient dans ce domaine. Il permettra alors des
communication à bas coût et il est clair qu'en tout état de cause, la résultante nette de cette
apparition sera une baisse de coût généralisée des tarifs de télécommunications, à longue
distance et notamment en international, quels que soient les moyens utilisés.
Page 200 sur 248

XV. Annexe
1) Glossaire
Terme Définition
Abréviation de ACKnowledged ou ACKnowledgement. Code indiquant
ACK
un accusé de réception.
AD-PCM Adaptive Differential PCM
AMI Alternate Mark Inversion
API Applicaton Programming Interface
ARP Adress Resolution Protocol
ASP Application Service Provider
ATA Analog Telephone Adaptor
ATM Asynchronous Transfer Mode
Backbone Epine Dorsale
Base Rate Interface : accès de base au RNIS. Composé de 2 canaux B
BRI
pour les données et d’un canal D pour la signalisation.
B8ZS Bipolar 8 Zeros Substitution
CAS Channel Associated Signaling
CBX Converged Branch eXchange -PABX IP
CCS Common Channel Signaling
CELP Code Exited Linear Prediction
Customer Premise Equipment -Equipement installé chez le client (fourni
CPE
par l‘opérateur ou par le client)
CTI Couplage Téléphonie Informatique (Computer Telephony Integration)
CVSD Continuously Variable Slope Delta
DCME Digital Circuit Multiplication Equipement
DHCP Dynamic Host Control Protocol
DSP Digital Signal Processor
DTMF Dual Tone Multi Frequency
DWDM Dense Wavelenght Division Multiplex
E&M Earth & Mouth
EMC Equipements Multiplicateurs de Circuits
ESF Extended Super Frame
FAI / ISP Fournisseur d'Accès Internet -Internet Service Provider
Frame Relay Relais de trames
FTP File Transfer Protocol
FTP File Transfer Protocol -Protocole de Transfert de Fichier
Gatekeeper Routeur d'appels
Variance du délai d‘acheminement d‘un paquet d‘un émetteur à un
Gigue
destinataire donné
GNU Licence pour les projets Open-Source
GSM Global System for Mobile Communications
GUI Graphical User Interface
H323 Protocole de contrôle d'appel créé par l'UIT-T
HDLC High Level Data Link Control
HMP Host Media Processing
HTTP HyperText Transfer Protocol -Protocole de transfert Hypertexte
IAP Internet Access Provider
IN Intelligent Network : réseau intelligent
Page 201 sur 248

IP Internet Protocol
IPDC Internet Protocol Device Control
ISP Internet Services Provider
IT Intervalles de Temps (Time Slots)
Internet Telephony Service Provider -Fournisseur d'Accès de
ITSP
Téléphonie par Internet
ITU International Telecommunication Union
IVR Interactive Voice Response
LAN Local Area Network
LCC Lost Calls Cleared : l’appel est rerouté
LCD Lost Cost Delayed : l’appel est mis en attente
LCH Lost Calls Held : l’appel est définitivement perdu
LCR Lost Calls Retried : l’appel est perdu avec une nouvelle tentative
LDAP Lightweight Directory Access Protocol
LLQ Low Latency Queuing -Mise en file d'attente à faible latence
MAC Media Access Control
MC Multipoint Controler
MCU Multipoint Control Unit
Media Gateway Control Protocol -Protocole de contrôle d'appels &
MGCP
gestion des passerelles PABX
MOS Mean Opinion Score : moyenne de l’opinion d’écoute
MP Multipoint Processor
NIC Network Interface Card
PABX Private Automatic Branch eXchange -Commutateur d'entreprise
PAM Pulse Amplitude Modulation
PCM Pulse Code Modulation
Position
Eléments composant le poste de travail d‘un téléopérateur
(centre d‘appel)
POTS Plain Old Telephone Service
Primary Rate Interface : accès primaire au RNIS. Composé de 30
PRI
canaux B pour les données et d’un canal D pour la signalisation.
PSTN Public Switched Telephone Network
QoS Quality of Service –Qualité de service
RFC2833 Request For Comment du SIP
RNIS Réseau Numérique à Intégration de Services
ROI Return On Investment –Retour Sur Investissement
RPE-LTP Regular Pulse Excitation – Long Terme Prediction
RPV Réseau Privé Virtuel
RSVP Resource Reservation Protocol -Protocole de Réservation de Ressources
RTC Réseau téléphonique commuté
RTCP Réseau Téléphonique Commuté Public
Real Time Control Protocol. Protocole lié à RTP véhiculant de manière
RTCP
sûre des informations relatives à la transmission RTP
Real Time Protocol. Protocole de transport temps réel généralement
RTP
utilisé pour le transport d‘audio, de la vidéo et des données
SCP Service Control Point
SGCP Simple Gateway Control Protocol
Session Initiation Protocol -Protocole de contrôle d'appels créé par
SIP
l'IETF
SLA Service Level Agreement œ clauses contractuelles entre un fournisseur
Page 202 sur 248

et un client concernant des engagements de services

Systems Network Architecture -architecture mainframe propriétaire
SNA
IBM
Signal System N°7 -Protocole de signalisation, standard mondial utilisé
SS7
pour les télécommunications voix
SSP Service Switching Point
STP Signal Transfert Point
TCP/IP Transmission Control Protocol / Internet Protocol
TDM Time Division Multiplexing / Multiplexage Temporel.
Télétravail Travail à distance au moyen des NTIC
Traffic Shaping Lissage de trafic
UDP User Datagram Protocol
VAD Voice Activity Detection
Voice Gateway Passerelle d'interconnexion RTCP / réseau paquet
VoIP Voice Over Internet Protocol
WDM Wavelength Division Multiplexing
WFQ Weighted Fair Queuing -Mise en file d'attente pondérée
Page 203 sur 248

2) Tonalité française :
Tonalité Fréquence Durée
DIAL TONE 440//330+440 CONTINUOUS
RINGING TONE 440 1.5 – 3.5
BUSY TONE 440 0.5 – 0.5
SPECIAL
950/1400/1800 (3×0.3 – 2×0.03) – 1.0
INFORMATION TONE
ROUTE TONE 440 0.05 – 0.05
Page 204 sur 248

3) Politique de France Telecom : Interview.

Interview paru dans le livre blanc “Téléphonie sur IP” de Cesmo Consulting, à l’initiative de
France Telecom en 2004. France Telecom est actuellement le leader de la téléphonie en
France grâce à sa place d’opérateur historique. Il est intéressant de voir la position de France
Telecom par rapport au nouveau marché qu’est la VoIP, et à la nouvelle concurrence qu’elle
entraîne.
a) Quelle est votre perception du marché actuel de la

Téléphonie sur IP ?
Le marché est réellement entré dans une phase de croissance comme le montrent les
déploiements récents issus des secteurs de la banque, de l‘industrie et de la grande
distribution. Un cap a d‘ores et déjà été franchi : ces projets ne concernent plus seulement une
centaine de postes mais bien plusieurs milliers de postes classiques à migrer en IP. De leur
côté, les constructeurs sont désormais tous présents sur ce marché et ont orienté leur stratégie
vers la téléphonie sur IP : même les leaders issus de la téléphonie traditionnelle ont annoncé la
fin de la commercialisation de leur gamme de PABX classiques dans les prochaines années.
Cette intensification de la concurrence a enclenché une baisse des prix qui, ajoutée à la
multiplication des solutions d‘IP-VPN (Equant en compte aujourd’hui 1 300) et des accès
xDSL, va favoriser l‘adoption des solutions de Téléphonie sur IP à court terme. La
pénétration de la Téléphonie sur IP dans les pays développés progresse d‘ailleurs de manière
assez importante. Elle pourrait d‘ailleurs l‘être encore davantage si certains déploiements
étaient moins complexes, si les amortissements relatifs aux PABX traditionnels n‘atteignaient
pas 7 ans en moyenne, surtout si la visibilité sur les applications de la Téléphonie sur IP était
plus forte.
b) Quelle est la légitimité d‘un opérateur tel que France Télécom

sur ce marché ?
France Télécom est déjà familier avec les technologies de VoIP et de ToIP. En tant
qu‘opérateur de téléphonie fixe, France Télécom achemine déjà certaines communications
internationales en VoIP sur les terminaisons d‘appels vers les destinations concernées. Sur le
marché entreprises, plus de 130 clients ont fait confiance à Equant pour transporter de la VoIP
à l‘international sur des IP VPN. Dans un tout autre domaine, nous proposons également des
solutions de centres de contacts IP, reposant sur la convergence entre la téléphonie et les
applications informatiques, naturellement couplées grâce à l‘IP.
L‘ambition de France Télécom est d‘accompagner les entreprises dans leurs projets en leur
proposant les solutions de communication les mieux adaptées. Nous avons l‘expertise des
services de téléphonie et de réseaux IP ; nous connaissons bien aussi les contraintes et les
attentes des entreprises. Cette expérience, couplée à notre force d‘innovation, nous a permis
d‘être les premiers à lancer un service de téléphonie managé sur IP en France, afin d‘aider nos
clients dans la migration progressive vers des services IP adaptés à leur taille : des offres
packagées pour les PME/PMI et des solutions personnalisées et sur mesure pour les grandes
entreprises et les multinationales.
Page 205 sur 248

Enfin, nous sommes actifs dans le domaine de la recherche, à l‘image d‘un projet pilote mené
par FT R&D, mettant en jeu 2300 IP phones. Nous sommes également impliqués dans des
actions de normalisation des solutions IP commercialisées par les équipementiers.
c) Quelle est votre approche et qu‘offrez-vous aux clients

entreprises ?
Le groupe France Télécom est capable de fournir une prestation complète aux clients dans le
cadre de leur migration Téléphonie sur IP. Au-delà d‘un opérateur de solutions WAN, nous
nous positionnons désormais en tant qu’opérateur-intégrateur, capable d‘offrir une offre de
services intégrée de bout en bout. Nous pouvons intervenir au niveau des sites clients et ce,
dès la phase amont d‘un projet, en proposant une équipe d‘experts capables, entre autres,
d‘accompagner nos clients dans la phase d‘audit, de leur fournir une méthode de calcul de
ROI et de les conseiller dans leurs choix techniques. Par la suite, si notre client le souhaite,
nous pouvons également prendre en charge l‘intégration de la solution d‘IPBX et l‘ingénierie
au niveau du LAN grâce à notre nouvelle unité d‘affaires dédiée aux services sur sites clients.
Un autre axe fort de diversification de notre offre repose sur les solutions de Centrex IP. Le
lancement de l‘offre e-téléphonie en juin 2004, permet aux entreprises souhaitant bénéficier
des avantages de la Téléphonie sur IP d‘externaliser la plate-forme IP, ainsi que sa gestion, au
niveau du cœur de réseau. A l‘échelle internationale, nous sommes présents à travers Equant
dans 200 pays hors de France où nous sommes capables d‘offrir l‘expertise du groupe France
Télécom dans la voix et la data/IP.
d) Quel message souhaitez-vous adresser aux entreprises

désirant migrer vers la ToIP ?
Les réticences ou l‘attentisme des entreprises face à la Téléphonie sur IP s‘expliquent parfois
par la complexité de certains déploiements. Le retour sur investissement s‘avère aussi parfois
difficile à évaluer dans certaines configurations.
Une des réponses que nous apportons, en tant qu”opérateur, consiste à mettre en place des
passerelles voix au cœur des réseaux IP. Chaque site migré en Téléphonie sur IP peut donc
s‘appuyer sur ces passerelles qui assurent la collecte et la terminaison des appels OFF-NET
du RTC. Les communications nationales sortantes peuvent être ainsi acheminées au plus près
et deviennent des communications locales, d‘où une réduction des coûts de trafic. Un autre
gain financier provient de la substitution par ces passerelles des liens T0/T2 placés en sortie
des sites, traditionnellement utilisés pour le trafic OFF-NET entrant et sortant du RTC.
Equant propose d‘ailleurs déjà ce type de solutions pour acheminer les communications
internationales OFF-NET de 130 multinationales clientes. Cette solution va dans le sens d‘une
amélioration du ROI d‘un projet mais aussi d‘une progressivité des investissements. En plus
de cet aspect économique, cette solution présente l‘avantage de permettre le portage des
numéros noirs et ainsi la possibilité de conserver le plan de numérotation existant.
e) En conclusion, comment France Télécom appréhende-t-elle

ce nouveau marché ?
France Télécom est le leader sur le marché français des services voix et data. Les technologies
de voix sur IP étant à la croisée de ces deux mondes, il apparaît logique que nous soyons un
acteur de premier plan. Ces nouveaux services ne sont qu‘une composante d‘une stratégie
plus globale du groupe, centrée sur l‘IP. Au sein du Groupe France Télécom, l‘IP est
Page 206 sur 248

désormais un axe fort de développement, tant sur le marché entreprises que grand public.
Outre la voix et l‘accès haut-débit, nous allons fournir une offre multi-accès de services,
comprenant la voix sur IP bien entendu, mais également la visiophonie, la vidéo et d‘autres
applications multimédias. Les synergies entre les différentes entités du groupe (Wanadoo,
Orange et Equant) sont des avantages de premier plan, décisifs pour affirmer le rôle du groupe
France Télécom en tant qu‘acteur majeur des services IP.
Page 207 sur 248

4) Extrait table B d’Erlang pour 0 à 50 canaux, 0,7 à 40 %

n Probabilité de perte (E) n
0,007 0,008 0,009 0,010 0,020 0,030 0,050 0,100 0,200 0,400
1 0,007 0,008 0,009 0,010 0,020 0,031 0,053 0,111 0,250 0,667 1
2 0,126 0,135 0,144 0,153 0,223 0,282 0,381 0,595 1,000 2,000 2
3 0,397 0,418 0,437 0,455 0,602 0,715 0,899 1,271 1,930 3,480 3
4 0,777 0,810 0,841 0,869 1,092 1,259 1,525 2,045 2,945 5,021 4
5 1,236 1,281 1,322 1,361 1,657 1,875 2,219 2,881 4,010 6,596 5
6 1,753 1,809 1,861 1,909 2,276 2,543 2,960 3,758 5,109 8,191 6
7 2,315 2,382 2,444 2,501 2,935 3,250 3,738 4,666 6,230 9,800 7
8 2,913 2,990 3,062 3,128 3,627 3,987 4,543 5,597 7,369 11,419 8
9 3,540 3,627 3,708 3,783 4,345 4,748 5,370 6,546 8,522 13,045 9
10 4,191 4,289 4,378 4,461 5,084 5,529 6,216 7,511 9,685 14,677 10
11 4,864 4,971 5,069 5,160 5,842 6,328 7,076 8,487 10,857 16,314 11
12 5,554 5,671 5,777 5,876 6,615 7,141 7,950 9,474 12,036 17,954 12
13 6,261 6,386 6,501 6,607 7,402 7,967 8,835 10,470 13,222 19,598 13
14 6,981 7,116 7,238 7,352 8,200 8,804 9,730 11,473 14,413 21,243 14
15 7,714 7,857 7,987 8,108 9,010 9,650 10,633 12,484 15,608 22,891 15
16 8,458 8,609 8,747 8,875 9,828 10,505 11,544 13,500 16,807 24,541 16
17 9,212 9,371 9,517 9,652 10,656 11,368 12,461 14,522 18,010 26,192 17
18 9,975 10,143 10,296 10,437 11,491 12,238 13,385 15,548 19,216 27,844 18
19 10,747 10,922 11,082 11,230 12,333 13,115 14,315 16,579 20,424 29,498 19
20 11,526 11,709 11,876 12,031 13,182 13,997 15,249 17,613 21,635 31,152 20
21 12,312 12,503 12,677 12,838 14,036 14,885 16,189 18,651 22,848 32,808 21
22 13,105 13,303 13,484 13,651 14,896 15,778 17,132 19,692 24,064 34,464 22
23 13,904 14,110 14,297 14,470 15,761 16,675 18,080 20,737 25,281 36,121 23
24 14,709 14,922 15,116 15,295 16,631 17,577 19,031 21,784 26,499 37,779 24
25 15,519 15,739 15,939 16,125 17,505 18,483 19,985 22,833 27,720 39,437 25
26 16,334 16,561 16,768 16,959 18,383 19,392 20,943 23,885 28,941 41,096 26
27 17,153 17,387 17,601 17,797 19,265 20,305 21,904 24,939 30,164 42,755 27
28 17,977 18,218 18,438 18,640 20,150 21,221 22,867 25,995 31,388 44,414 28
29 18,805 19,053 19,279 19,487 21,039 22,140 23,833 27,053 32,614 46,074 29
30 19,637 19,891 20,123 20,337 21,932 23,062 24,802 28,113 33,840 47,735 30
31 20,473 20,734 20,972 21,191 22,827 23,987 25,773 29,174 35,067 49,395 31
32 21,312 21,580 21,823 22,048 23,725 24,914 26,746 30,237 36,295 51,056 32
33 22,155 22,429 22,678 22,909 24,626 25,844 27,721 31,301 37,524 52,718 33
34 23,001 23,281 23,536 23,772 25,529 26,776 28,698 32,367 38,754 54,379 34
35 23,849 24,136 24,397 24,638 26,435 27,711 29,677 33,434 39,985 56,041 35
36 24,701 24,994 25,261 25,507 27,343 28,647 30,657 34,503 41,216 57,703 36
37 25,556 25,854 26,127 26,378 28,254 29,585 31,640 35,572 42,448 59,365 37
38 26,413 26,718 26,996 27,252 29,166 30,526 32,624 36,643 43,680 61,028 38
39 27,272 27,583 27,867 28,129 30,081 31,468 33,609 37,715 44,913 62,690 39
40 28,134 28,451 28,741 29,007 30,997 32,412 34,596 38,787 46,147 64,353 40
41 28,999 29,322 29,616 29,888 31,916 33,357 35,584 39,861 47,381 66,016 41
42 29,866 30,194 30,494 30,771 32,836 34,305 36,574 40,936 48,616 67,679 42
43 30,734 31,069 31,374 31,656 33,758 35,253 37,565 42,011 49,851 69,342 43
44 31,605 31,946 32,256 32,543 34,682 36,203 38,557 43,088 51,086 71,006 44
Page 208 sur 248

45 32,478 32,824 33,140 33,432 35,607 37,155 39,550 44,165 52,322 72,669 45
46 33,353 33,705 34,026 34,322 36,534 38,108 40,545 45,243 53,559 74,333 46
47 34,230 34,587 34,913 35,215 37,462 39,062 41,540 46,322 54,796 75,997 47
48 35,108 35,471 35,803 36,109 38,392 40,018 42,537 47,401 56,033 77,660 48
49 35,988 36,357 36,694 37,004 39,323 40,975 43,534 48,481 57,270 79,324 49
50 36,870 37,245 37,586 37,901 40,255 41,933 44,533 49,562 58,508 80,988 50
0,007 0,008 0,009 0,010 0,020 0,030 0,050 0,100 0,200 0,400
Page 209 sur 248

5) Débit / codecs
Bande
Codec Durée du paquet passante
(kbps)
G.723.1 (ACELP) 5.3kbps compressé 30 millisecondes (1 échantillon) 16
G.723.1 (MP-MLQ) 6.4kbps compressé 30 millisecondes (1 échantillon) 18
Page 210 sur 248

6) Fonctionnalités de l’IP PBX Asterisk

- Conférence à 3 (3 Way Calling : géré par le téléphone)
- Rappel automatique (Autodial Keys : en fonction du téléphone)
- Sélection automatique de la ligne (Automatic Line Selection)
- Music de fond (BackGround Music : flux mp3 ou fichier audio, en fonction des
demandes)
- Enregistrement des détails d’un appel (Call Detail Record : possibilité d’enregistrer les
détails dans une base de données)
- Visualisation des appels quand occupé (Call Display when busy : en fonction du
téléphone, le Cisco 7960 affiche le numéro de la personne qui appel)
- Génération d’appel (Call Generation : possibilité de générer des appels avec un script
- Transfert d’Appel (Call Forward : tous les appels, en cas d’occupation, en cas
d’absence, etc.)
- Mise en attente (Call Park/Call Waiting)
- Prise d’Appel (Call Pickup : directement, par groupe, à distance, etc.)
- Enregistrement (Call Recording : possibilité d’enregistrer une communication)
- File d’attente (Call Queuing : avec indication de la position si nécessaire)
- Conférence à N (MeetMe : création d’une salle de conférence avec possibilité de

désactiver des micros)
- Indication « Ne pas Déranger » (DND Do Not Disturb : en fonction du téléphone)
- Standard automatique (Interactive Voice Response : menu avec sélection par touche,
possibilité de reconnaissance vocale)
- Choix de la langue (Language Choice : nécessité de fournir les fichiers sons, en

fonction du téléphone)
- Rappel du dernier numéro (Last Number Redial : en fonction du téléphone)
- Service de nuit (Night Service : possibilité de modifier les services en fonction de

l’heure)
- Messagerie Unifié (Unified Messaging : transfert des messages vers mail, pager, page
web, serveur ftp, etc. Possiblité de configurer le codec, la taille max., etc. Indication
visuelle et/ou sonore)
- Service d’annuaire (Directory Service)
Page 211 sur 248

- Connexion à un annuaire LDAP (compatible OpenLDAP et Active Directory)
- Compatible Windows Messenger, etc.
- Appel par Annuaire (Appel d’un contact via Outlook ou ACT – non testé avec Lotus
Notes)
- Standard Visuel (Visualisation de l’ensemble des appels avec une interface Flash :
visualisation des lignes occupées, qui sonnent et disponibles avec affichages des
numéros ; possibilité d’interagir : transférer, raccrocher, appeler, etc.)
- Gestion de la Vidéo (avec le matériel compatible)
- Gestion de code d’accès (pour accès à la messagerie ou à des fonctionnalités).
- Services XML (uniquement avec téléphone IP Cisco)
Page 212 sur 248

7) VegaStream 100 E1 : spécifications techniques (en anglais)
a) Vega 100 E1 features

- Desktop or 19” rack mount
- 2 E1 connections
- 30 or 60 calls to LAN
- Euro ISDN signaling
- QSIG - available for basic calls from Release 4 - tunneled QSIG (all supplementary
services) from Release 5
- NT / TE configurable
b) Vega general product features

- Web browser configuration
- 10 base T / 100 base TX LAN
- QOS packet marking - layer 3 Type Of Service - layer 2 802.1 p/q
- Call detail records available - from Telnet and Serial interfaces - via Radius
accounting records
- Built in dial planner
- SNMP
- Auto-load config and firmware
c) Vega VoIP features

- Echo cancellation –G.168 – up to 32ms (R6 up to 128ms)
- Codecs / companders –G.711Alaw64k –G711ulaw64k –G729AnnexA (/b) –G.723.1 –

T.38
Page 213 sur 248

- Silence suppression configurable per codec
d) Environmental
- Operating temperature: 0ºC to +40ºC
- Storage temperature: -20ºC to +70ºC
- Humidity: 0 to 90% (non condensing)
e) Power
- 100 - 240 Vac, 47 - 63 Hz, 1A - 0.5A
- Fuse rating: 2A - type T (e.g. Bussmann S505)
f) Physical dimensions
- 440mm (17.4") x 63mm (2.5") x 330mm (13") width / height / depth
- Industrial rack mount: 483mm (19"), 1.5U
- Weight: 7.5kg
ISDN DSL Status LED LED Off LED Flash LED On

Vega E1 No physical Connection Physical Only Physical + Layer 2
Page 214 sur 248

Vega100 E1 10030 / 10060
2 RJ-45 connectors are used; connectors 3 and 4 are reserved for future expansion
E1 Cables supplied :
- Blue booted ISDN cable – Vega TE NT
- Red booted ISDN cable – Vega NT TE
g) Approvals
For European CE Countries :
- ISDN – TBR4 (Euro ISDN)
- Safety – EN60950, IEC60950
- EMC – EN55022 class B (CISPR22), EN55024(CISPR24)
h) Tech Spec
E1 DSL Physical
- 120 Ohm connection
- 30 bearer channels - channels 1 to 15 & 17 to 31
- 1 "D" channel (signalling) - channel 16
- 1 framing channel - channel 0
- PCM30 or CRC-4 framing
- HDB3 line encoding
Page 215 sur 248

- 30 bearer channels + signalling (30B+D)
- TE / NT mode soft configurable by DSL
- Line power not supplied (NT)
- Line power not detected (TE)
D-channel Signalling
- PRI Euro-ISDN/CTR4/NET4/DSS1
Page 216 sur 248

8) Vega 100 E1 : Configuration standard

a) Configuration du plan d’appel.
Une fois la configuration réseau effectuée, il faut configurer le plan d’appel, pour y accéder, il
faut cliquer sur le lien « Dial Plan » dans le menu de gauche :
Par défaut, il existe une configuration Vega100T1E1_default). Il faut la désactiver. Pour cela,
il faut cliquer sur « Modify », décocher la case « Enabled » et cliquer sur « Submit » :
Page 217 sur 248

Il est maintenant nécessaire de créer un nouveau « profil ». Pour cela, il faut cliquer sur
« add » :
Une fois le nouveau profil créé, il faut le modifier en cliquant sur « Modify » à droite de
« new_profile » :
Il est alors possible de modifier le nom du profil :
Ce profil va correspondre aux appels en provenance de l’ISDN et que nous allons transférer
vers le LAN ; nous pouvons donc l’appeler « ISDN_To_LAN ». En appuyant sur « Submit »
pour valider et en cliquant sur « Modify » une seconde fois, on obtient :
Page 218 sur 248

Il est alors possible de modifier le plan d’appel en appuyant sur « Modify » :
Page 219 sur 248

Il faut renommer le plan pour plus de compréhension : « From_ISDN_or_PBX » par example.

En modifiant la source en IF :[^9].,TEL :<.*>, nous n’acceptons que les appels en provenance
des interfaces 01 et 02 et nous stockons le numéro appelé dans <1>. Ainsi, en modifiant la
destination en IF :99,TEL :<1>, nous transférons cet appel sur l’interface LAN. En appuyant
sur « Apply » nous validons ce plan d’appel et nous obtenons :
Page 220 sur 248

Il faut donc cliquer sur « Dial Plan » pour revenir au menu d’origine.
Il est alors nécessaire de créer un chemin inverse. C'est-à-dire de transférer les appels venant
du LAN vers le PBX ou l’ISDN.
Il faut donc de la même manière créer un profil « LAN_to_ISDN_or_PBX » et modifier le

premier plan de ce profil avec les paramètres suivants :
- Nom : From_LAN
- Source : IF : 99,TEL :<..><.*>
- Destination : <1>,TEL :<2>
Ainsi, si le numéro commence par 01, l’appel est transféré sur le port ISDN 01 et si le numéro
commence par 02, l’appel est transféré sur le port ISDN 02.
Page 221 sur 248

b) Configuration du SIP et des paramètres audio

Nous venons de configurer les plans d’appel. Quand nous transférons un appel vers le port
LAN, il est nécessaire de lui indiquer une destination. La plupart du temps, cela correspond au
Proxy SIP. Il est donc nécessaire de configurer le SIP sur la passerelle.
Pour cela, il faut cliquer sur « SIP » dans le menu de gauche :
Les paramètres à configurer sont les suivants :
- Default Proxy Host Name/IP : Nom ou addresse IP du Proxy SIP
- Local Domain : nom de domaine public du serveur proxy, utilisé par les autres
périphériques pour envoyer leurs messages INVITE
- Accept Non-Proxy Invites : si cette case est décochée, seul les appels en provenance
du proxy seront gérés.
Page 222 sur 248

Après avoir validé avec « Submit », il est nécessaire de configurer les paramètres audio. Sur
la même page, dans la rubrique Audio, il faut sélectionner les codecs qui seront utilisés :
c) Configuration de l’Authentification
L’environnement que nous utilisons nécessite que chaque appel soit préalablement autorisé.
Pour cela, nous employons l’authentification SIP avec un nom d’utilisateur et un mot de
passe. Le nom d’utilisateur est composé de trois parties : un préfix, un nom et un suffixe.
Supposons que nous ayons configuré un compte utilisateur avec « VegaGateway123 » comme
nom et « LetMeIn » comme mot de passe.
Dans la page « SIP », cliquez sur le lien « SIP Authentication » :
On obtient alors la page suivante :
Page 223 sur 248

Cliquez sur « Modify » pour changer l’utilisateur par défaut.
Les paramètres à changer sont les suivants :
Page 224 sur 248

- Username Suffix : none
- Username : VegaGateway123
- Password : LetMeIn
- Source : IF :.*
Il est nécessaire de valider en cliquant sur « Submit »
Il faut ensuite spécifier à la passerelle d’utiliser l’authentification. Dans la page « SIP », il

existe un lien « Advanced SIP » :
Cliquez sur ce lien, pour accéder aux paramètres SIP avancés :
Page 225 sur 248

Il suffit de cocher « Use authentication users » pour activer l’authentification.
d) Configuration de l’Enregistrement
En temps normal, une passerelle comme la Vega 100 n’a pas besoin de s’enregistrer sur un
proxy SIP. L’enregistrement SIP est destiné aux utilisateurs finaux qui doivent s’enregistrer
sur le serveur proxy, pour se faire connaître. En effet, une passerelle peut gérer plusieurs
milliers d’utilisateurs finaux et dans ce cas, l’existence de la passerelle et ses capacités sont
configurées directement au niveau du proxy SIP.
Dans le cas d’un appel routé de la téléphonie classique vers le protocole SIP, le proxy SIP est
généralement configuré pour accepter les appels en provenance de la Vega 100 et le numéro
appelé est placé dans le champ « request uri » par la Vega.
Dans le cas d’un appel routé du SIP vers la téléphonie classique, le proxy envoyé un paquet
avec un champ « request uri » du style : iittt…t@adresse où ii représente l’interface sur lequel
l’appel doit être transférer et ttt…t le numéro que la passerelle doit appeler.
Page 226 sur 248

Toutefois, il existe des cas où il nécessaire d’enregistrer la passerelle sur le proxy SIP. Cela
permet par exemple de signaler au proxy que la passerelle existe et est opérationnelle pour
prendre des appels. Le nombre d’utilisateurs qu’il faut enregistrer sur le proxy dépend de la
configuration du proxy. Typiquement, un seul utilisateur est requis.
Par exemple, pour enregistrer l’utilisateur « Vega100Gateway123 », dans la page « SIP »

descendez jusqu’à la section « registration » :
Cliquez sur « Register on Start-up » et rentre l’adresse IP ou le nom complet du serveur

d’enregistrement. Appuyez sur « Submit » pour valider.
Dans la section « Sip Registration Users Configuration », cliquez sur « SIP Registration
Users » :
Page 227 sur 248

Cliquez sur « Modify »
Dans la section « Sip Registration User 1 », cochez la case « Enable », choisissez « none »
comme « Username Suffix » et « Vega100Gateway123 » comme « Username ».
Enfin, si l’enregistrement nécessite une authentification, sélectionnez le bon utilisateur dans

« Authentication User Index » :
Page 228 sur 248

Il est nécessaire de sauvegarder et de redémarrer la passerelle pour activer cette configuration.
e) Configuration des ports DSL

Les ports DSL correspondent aux 2 ports ISDN de la Vega 100. Pour les configurer, il faut
cliquer sur « DSL » dans le menu de gauche :
Page 229 sur 248

La configuration standard est la suivante :
Page 230 sur 248

Cliquez sur « submit » pour la valider.
Il est ensuite nécessaire de configurer chacun des ports. Dans notre configuration, le port 01
est connecté au PSTN et le port 02 est connecté au PBX. Le port 01 est donc configuré en
mode TE, et le port 02 en mode NT.
Il est nécessaire de signaler à la passerelle que son horloge interne doit être synchronisée avec
l’horloge du port 01.
Dans la section « Port Configuration », vérifiez que « g711Alaw64k » est bien sélectionné
pour le « layer 2 ». Ensuite, modifié la valeur du « DTMF Dial Timeout » à 5 :
Page 231 sur 248

Enfin, il faut sélectionner le nombre de canaux sur le lien. Sur la Page « SIP », dans le section
Port Configuration », cliquez sur le lien « Modify » du « PORT ID 1 » :
Page 232 sur 248

La valeur « Last Channel » correspond au nombre de canaux du lien.
Il faut faire ensuite de même pour le « PORT ID 2 »
f) Configuration du pointeur vers la documentation

Afin de pouvoir accéder à l’aide de la passerelle, il est nécessaire de stocker le contenu du CD
sur un serveur web. Il est donc nécessaire de signaler l’emplacement de ce serveur, pour avoir
une aide interactive.
Dans la page « LAN », cliquez sur « Advanced LAN » :
Page 233 sur 248

Il suffit alors de rentrer le chemin :
Page 234 sur 248

g) Sauvegardes des modifications

Dans le menu de gauche, cliquez sur « save » :
Validez et cliquez ensuite sur « Reboot System » :
Page 235 sur 248

Validez. La Vega va redémarrer. Elle est prête pour gérer son premier appel.
h) Archivage de la configuration de la passerelle

Une fois configurée, il est conseillé de sauvegarder la configuration sur un serveur distant.
Tout d’abord il est nécessaire de configurer le serveur TFTP dans la page « LAN », ensuite,
dans la page « Advanced » descendez jusqu’à la section « CLI command » :
Entrez « PUT tftp :initial_cfg.txt » et cliquez sur « Submit »
Il est également possible d’envoyer la configuration vers un serveur FTP. Dans ce cas, la
ligne de commande sera « PUT ftp :initial_cfg.txt ». Si le serveur FTP nécessite un nom
d’utilisateur et un mot de passe, il faut les configurer de la manière suivante :
set _advanced.lan.ftp.anonymous_login=0
set _advanced.lan.ftp.username=<ftp username>
set _advanced.lan.ftp._password-<ftp password>
9) Vega 100 E1 : Configuration transparente

Pour configurer la passerelle Vega 100 pour qu’elle soit transparente, il faut commencer par
désactiver les processus inutiles. Pour cela, dans la page « Advanced », dans la section
« Setup Mapping – Calling Party Number », modifiez les champs de « Map ID 1 » de la
manière suivante :
- Type = supplied
- Plan = supplied
- Presentation = supplied
- Screening = supplied
Dans la section « Setup Mapping – Called Party Number », modifiez les champs de « Map ID
1 » de la manière suivante :
- Type = supplied
- Plan = supplied
Page 236 sur 248

Maintenant, sélectionnez la page « DSL ». Pour chaque port, effectuez les modifications
suivantes :
- « Setup Mapping » = 1.
A cet instant, il est possible de configurer le délai avant la numérotation d’un numéro
(« DTMF Dial Out ») mais également dans quel ordre attribuer les canaux. Pour cela il faut
savoir comment sont attribuer les canaux au niveau du PSTN et de l’IPBX. Il est possible de
le savoir grâce au lien « Show Ports » de la section System de la page « Management » :
- « I » indique un appel entrant sur ce lien.
- « O » indique un appel sortant sur ce lien
A partir des informations visualisées aux cours des appels, il faut configurer le champ « Alloc
Channel » dans la section « Modify Port Group » de chaque port.
Il est désormais possible de configurer le plan d’appel.
Pour cela, il faut commencer par désactiver le profil par défaut.
Ensuite, il faut créer un nouveau profil que nous appelons « Trunking_pass-thru ». Nous lui
rajoutons un plan avec les paramètres suivants :
- Name = PSTN_to_PBX
- Source = IF :01,TEL:<.*>
- Destination = IF :02,TEL:<1>
Nous lui rajoutons ensuite un deuxième plan avec les paramètres suivants :
- Name = PBX_to_PSTN
- Source = IF :02,TEL :<.*>
- Destination = IF:01,TEL:<1>
Page 237 sur 248

Il est possible de spécifier des plans d’appel spécifique afin de ne pas être obligé d’attendre la
fin de la période de numérotation.
Il est ensuite nécessaire de configurer les sonneries.
Enfin, il faut vérifier les éléments suivants :

_advanced.media.direct_TDM_enable=
Ce paramètre permet de ne pas passer par les DSP.

_advanced.isdn.alert_with_progress=1
Les sonneries en provenance du PSTN du type « RingBack » passent à travers la Vega et ne

sont pas régénérée. (Si un message signale que le numéro n’existe plus, essayez la valeur 2)
_advanced.isdn.user_progress=0
Le port TE ne génère pas de sonneries de type « RingBack » ou « Disconnect » en local.
Page 238 sur 248

10) Ingate : spécifications techniques (en anglais)
Page 239 sur 248

11) Cisco : exemple de fichiers de configuration

a) OS79XX.TXT
P003-07-2-00
b) SIPDefault.cnf
# SIP Default Generic Configuration File
# Image Version
image_version: P0S3-07-2-00
# Proxy Server
proxy1_address: "francevoip.com" ; Can be dotted IP or FQDN
proxy2_address: "" ; Can be dotted IP or FQDN
# Proxy Server Port (default - 5060)

proxy1_port: 5060
proxy2_port: 5060
proxy3_port: 5060
proxy4_port: 5060
proxy5_port: 5060
proxy6_port: 5060
# Proxy Registration (0-disable (default), 1-enable)

proxy_register: 1
# Phone Registration Expiration [1-3932100 sec] (Default - 3600)

timer_register_expires: 3600
# Codec for media stream (g711ulaw (default), g711alaw, g729a)

preferred_codec: g711ulaw
# TOS bits in media stream [0-5] (Default - 5)

tos_media: 5
# Inband DTMF Settings (0-disable, 1-enable (default))

dtmf_inband: 1
# Out of band DTMF Settings (none-disable, avt-avt enable (default), avt_always - always avt )
dtmf_outofband: avt
# DTMF dB Level Settings (1-6dB down, 2-3db down, 3-nominal (default), 4-3db up, 5-6dB up)
dtmf_db_level: 3
# SIP Timers
timer_t1: 500 ; Default 500 msec
timer_t2: 4000 ; Default 4 sec
sip_retx: 10 ; Default 10
sip_invite_retx: 6 ; Default 6
timer_invite_expires: 180 ; Default 180 sec
####### New Parameters added in Release 2.0 #######
# Dialplan template (.xml format file relative to the TFTP root directory)
dial_template: dialplan
Page 240 sur 248

# TFTP Phone Specific Configuration File Directory

tftp_cfg_dir: "" ; Example: ./sip_phone/
# Time Server (There are multiple values and configurations refer to Admin Guide for Specifics)
sntp_server: "" ; SNTP Server IP Address
sntp_mode: directedbroadcast ; unicast, multicast, anycast, or directedbroadcast (default)
time_zone: EST ; Time Zone Phone is in
dst_offset: 1 ; Offset from Phone's time when DST is in effect
dst_start_month: April ; Month in which DST starts
dst_start_day: "" ; Day of month in which DST starts
dst_start_day_of_week: Sun ; Day of week in which DST starts
dst_start_week_of_month: 1 ; Week of month in which DST starts
dst_start_time: 02 ; Time of day in which DST starts
dst_stop_month: Oct ; Month in which DST stops
dst_stop_day: "" ; Day of month in which DST stops
dst_stop_day_of_week: Sunday ; Day of week in which DST stops
dst_stop_week_of_month: 8 ; Week of month in which DST stops 8=last week of month
dst_stop_time: 2 ; Time of day in which DST stops
dst_auto_adjust: 1 ; Enable(1-Default)/Disable(0) DST automatic adjustment
time_format_24hr: 1 ; Enable(1 - 24Hr Default)/Disable(0 - 12Hr)
# Do Not Disturb Control (0-off, 1-on, 2-off with no user control, 3-on with no user control)
dnd_control: 0 ; Default 0 (Do Not Disturb feature is off)
# Caller ID Blocking (0-disbaled, 1-enabled, 2-disabled no user control, 3-enabled no user control)
callerid_blocking: 0 ; Default 0 (Disable sending all calls as anonymous)
# Anonymous Call Blocking (0-disabled, 1-enabled, 2-disabled no user control, 3-enabled no user
control)
anonymous_call_block: 0 ; Default 0 (Disable blocking of anonymous calls)
# DTMF AVT Payload (Dynamic payload range for AVT tones - 96-127)
dtmf_avt_payload: 101 ; Default 101
# Sync value of the phone used for remote reset

sync: 1 ; Default 1
# Backup Proxy Support

proxy_backup: "" ; Dotted IP of Backup Proxy
proxy_backup_port: 5060 ; Backup Proxy port (default is 5060)
# Emergency Proxy Support

proxy_emergency: "" ; Dotted IP of Emergency Proxy
proxy_emergency_port: 5060 ; Emergency Proxy port (default is 5060)
# Configurable VAD option

enable_vad: 0 ; VAD setting 0-disable (Default), 1-enable
####### New Parameters added in Release 2.2 ######
# NAT/Firewall Traversal
nat_enable: 0 ; 0-Disabled (default), 1-Enabled
nat_address: "" ; WAN IP address of NAT box (dotted IP or DNS A record only)
voip_control_port: 5060 ; UDP port used for SIP messages (default - 5060)
start_media_port: 16384 ; Start RTP range for media (default - 16384)
end_media_port: 32766 ; End RTP range for media (default - 32766)
nat_received_processing: 0 ; 0-Disabled (default), 1-Enabled
Page 241 sur 248

# Outbound Proxy Support

outbound_proxy: "" ; restricted to dotted IP or DNS A record only
outbound_proxy_port: 5060 ; default is 5060
####### New Parameter added in Release 3.0 #######
# Allow for the bridge on a 3way call to join remaining parties upon hangup
cnf_join_enable : 1 ; 0-Disabled, 1-Enabled (default)
# Allow Transfer to be completed while target phone is still ringing

semi_attended_transfer: 1 ; 0-Disabled, 1-Enabled (default)
# Telnet Level (enable or disable the ability to telnet into the phone)
telnet_level: 1 ; 0-Disabled (default), 1-Enabled, 2-Privileged
# XML URLs
services_url: "http://195.68.111.21/CiscoIPServices/index.xml" ; URL for external Phone
Services
directory_url: "" ; URL for external Directory location
logo_url: "http://195.68.111.21/CiscoIPServices/asterisk-tux.bmp" ; URL for
branding logo to be used on phone display
# HTTP Proxy Support

http_proxy_addr: "" ; Address of HTTP Proxy server
http_proxy_port: 80 ; Port of HTTP Proxy Server (80-default)
# Dynamic DNS/TFTP Support

dyn_dns_addr_1: "" ; restricted to dotted IP
dyn_dns_addr_2: "" ; restricted to dotted IP
dyn_tftp_addr: "" ; restricted to dotted IP
# Remote Party ID
remote_party_id: 0 ; 0-Disabled (default), 1-Enabled
# Call Hold Ringback (0-off, 1-on, 2-off with no user control, 3-on with no user control)
call_hold_ringback: 0 ; Default 0 (Call Hold Ringback feature is off)
# Dialtone Stutter for MWI

stutter_msg_waiting: 0 ; 0-Disabled (default), 1-Enabled
# RTP Call Statistics (SIP BYE/200 OK message exchange)

call_stats: 0 ; 0-Disabled (default), 1-Enabled
c) SIP001193B6F141.cnf
# SIP Configuration Generic File
line1_name: "33172770218" ; Line 1 Extension\User ID
line1_displayname: "Fred OGUER" ; Line 1 Display Name
line1_authname: "33172770218" ; Line 1 Registration Authentication
line1_password: "motdepasse" ; Line 1 Registration Password
Page 242 sur 248

line2_password: " motdepasse " ; Line 1 Registration Password




# All user_parameters have been removed
# Phone Label (Text desired to be displayed in upper right corner)

phone_label: "" ; Has no effect on SIP messaging
# Line 1 Display Name (Display name to use for SIP messaging)

line1_displayname: "Telephone TEST"
# Line 2 Display Name (Display name to use for SIP messaging)

line2_displayname: ""
####### New Parameters added in Release 3.0 ######
# Phone Prompt (The prompt that will be displayed on console and telnet)
phone_prompt: "SIP Phone" ; Limited to 15 characters (Default - SIP Phone)
# Phone Password (Password to be used for console or telnet login)

phone_password: "cisco" ; Limited to 31 characters (Default - cisco)
# User classifcation used when Registering [ none(default), phone, ip ]

user_info: none
d) Ringlist.dat
Ahh! ahh.pcm
Doh! doh.pcm
Old Style ringer1.pcm
Synth Low ringer2.pcm
Dungeon ringer3.pcm
Lightbulb ringer4.pcm
Synth High ringer6.pcm
Are You There M AreYouThere.raw
Are You There F AreYouThereF.raw
ClockShop ClockShop.raw
Page 243 sur 248

Curley Curley.raw
Drums 1 Drums1.raw
Drums 2 Drums2.raw
FilmScore FilmScore.raw
FlintPhone FlintPhone.raw
HarpSynth HarpSynth.raw
Jamaica Jamaica.raw
Klaxons Klaxons.raw
KotoEffect KotoEffect.raw
MusicBox MusicBox.raw
Neuro Neuro.raw
Ohno Ohno.raw
Piano 1 Piano1.raw
Piano 2 Piano2.raw
Pop Pop.raw
Pulse Pulse1.raw
Saxaphone 1 Sax1.raw
Saxaphone 2 Sax2.raw
Asleep asleep.raw
Caramba caramba.raw
MayIHelp mayihelp.raw
Dilbert Boss SICA-dilbert-BungeeBoss.raw
Dilbert Meeting SICA-dilbert-PHB.raw
NyukNyuk NyukNyuk.raw
Merlin2 merlin2.pcm
Merlin3 merlin3.pcm
Merlin4 merlin4.pcm
Merlin5 merlin5.pcm
Merlin6 merlin6.pcm
Merlin7 merlin7.pcm
e) Dialplan.xml
<DIALTEMPLATE>
<TEMPLATE MATCH="*" Timeout="5" /> 
</DIALTEMPLATE>
Page 244 sur 248

12) DB_PSQL.PHP
<?php
class DB{
var $id;
var $qstring;
var $errmsg = "";
var $result;
function DB()
{
$q = pg_connect("host=192.168.6.23 user=xxxx dbname=voip
password=xxxx");
if (!$q) $this->errmsg .= "Connection à la base échouée!\n";
else $this->id = $q;
}
function query($query_string)
{
$this->qstring = $query_string;
$q = pg_query($this->qstring);
if (!$q) $this->errmsg .= "Requête echouée!\n";
else $this->result = pg_fetch_all($q);
function close()
{
$q = pg_close();
$this->id = "";
}
function getResult()
{
return $this->result;
}
};
?>
Page 245 sur 248

XVI. Bibliographie et références :

1) Sites Web :
a) Partenaires et fournisseurs
• Cisco (Général) : http://www.cisco.com
• Cisco (Documentation) : http://www.cisco.com/univercd/home/home.htm
• Vegastream (Informations générales) : http://www.vegastream.com
• Vegastream (Support Technique) : http://www.vegaassist.com
• Ingate : http://www.ingate.com
• Asterisk : http://www.asterisk.org
• Digium : http://www.digium.com
• Snom : http://www.snom.com
• Primus Telecom : http://www.primustel.fr/
b) Informations divers
• Le site de référence pour Asterisk : http://www.voip-info.org
• Présentation H.323 et SIP : http://www.lifl.fr/~boulet/formation/syst-

dist/exposes2003-2004/voip/Standards.html
http://perso.club-internet.fr/f_bailly/interface/inter_voip.htm
• Le site SipFoundry : http://www.sipfoundry.org/index.html
• Les couches de transport :

http://www.invocom.et.put.poznan.pl/~invocom/courses/P4-1/fr/ch4.html
• Le module RTP de Microsoft utilisé dans Messenger :

http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/wcertc/html/cmconReal-timeCommunications.asp
2) Documents techniques
a) Les standards
Désignation Description
draft_ietf_avt_profile_new_12 RTP Profile for Audio and Video Conferences with
Page 246 sur 248

Minimal Control
draft_ietf_avt_rtp_mime_06 MIME Type Registration of RTP Payload Formats
RTP Payload for Comfort Noise, Internet Draft of
draft_ietf_avt_rtp_cn_06 the Internet Engineering Task Force (IETF)
Audio/Video Transport (AVT) working group
draft_ietf_mmusic_sdp_comedia_04 Connection_Oriented Media Transport in SDP
ISDN Basic Rate Interface Call Control Switching
GR_268_CORE
and Signalling Generic Requirements
b) Les MIB (pour la supervision)

CISCO_SIP_UA_MIB Le MIB de Cisco pour le SIP. Disponible sur le site de Cisco
c) Les RFC (du moins une partie…)

RFC 1889 RTP: A Transport Protocol for Real-Time Applications
RFC 2052 A DNS RR for Specifying the Location of Service (DNS SRV)
RFC 2543 SIP: Session Initiation Protocol
RFC 2617 HTTP Authentication: Basic and Digest Access Authentication
RFC 2782 A DNS RR for Specifying the Location of Service (DNS SRV)
RFC 2806 URLs for Telephone Calls
RFC 2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals
RFC 2976 SIP INFO Method
RFC 3261 SIP: Session Initiation Protocol
RFC 3262 Reliability of Provisional Responses in Session Initiation Protocol (SIP)
RFC 3264 An Offer/Answer Model with Session Description Protocol (SDP).
RFC 3326 The Reason Header Field for the Session Initiation Protocol
3) Ouvrages et présentations
• “SIP Understanding the Session Initiation Protocol”, Second Edition, Alan B.
Johnston – Editions Artech House
• « Comprendre la Voix sur IP », S. Descombes, JDNet, October 2002.
• « Voix sur IP (IP telephonie) », P. Pinard, 2000.
• « Téléphonie sur IP : Bilan UREC et résultat de quelques tests », J. Archimbaud and

P. Leca, CNRS-UREC, 1999.
• « La Voix sur IP (Voice over IP) », T. Debeaupuis, 1997.
• « Telephonie sur IP: Mythes et Réalités », C. Chassagne, CRI-UPMF, Mai 2000.
• “Approach For Services in Converged Network”, S. Kapur, R. Vij, Hughes Software

Systems, Workshop on IP Telecom Service (IPTS), Georgia, USA, September 2000
Page 247 sur 248

• “Service Development and Deployment in H.323 and SIP”, Josef Glasmann,

Wolfgang Kellerer, Harald Müller, Proceedings of the Sixth IEEE Symposium on
Computers and Communications (ISCC’01), Munich, 2001.
• “Entreprising with SIP - A Technology Overview”, Avaya, White Paper, February

2004.
• “Session Initiation Protocol (SIP) Technology”, Ixia, 2004.
• “Design and Implementation of a SIP-based VoIP Architecture”, S. Zeadally and F.

Siddiqui, Proceedings of the 18th International Conference on Advanced Information
Networking and Application (AINA’04), 2004.
• “Advanced VoIP Tests Suites”, P. Miller, product datasheet, BRIX Networks, May,
2004.
• “SIP, Security and Session Controllers”, white paper, Newport Networks, April,
2004.
• “Performance Estimation of a SIP based Push-to-Talk Service for 3G Networks”, Eoin

O’Regan and Dirk Pesch, Proceedings of the EW2004, 2004.
• “Survey on QoS Management of VoIP”, Xiuzhong Chen, Chunfeng Wang, Dong

Xuan+, Zhongcheng Li, Yinghua Min and Wei Zhao, Proceedings of the 2003
International Conference on Computer Networks and Mobile Computing
(ICCNMC’03), 2003
• “The Performance Analysis of SIP-T Signaling System in Carrier Class VoIP

Network”, J. S. Wu, and P. Y. Wang, NCU, In the 17 th International Conference on
Advanced Information Networking and Applications (AINA'03), March 23, 2003.
• “SIP Proxy Server Effectiveness”, J. Janak, Master's Thesis, Faculty of Electrical

Engineering, Czech University, May 21st, 2003.
• “SIPstone - Benchmarking SIP Server Performance”, H. Schulzrinne, S. Narayanan, J.

Lennox, and M. Doyle, Columbia University, Ubiquity, April 12, 2002. [.pdf].
• “Performance Measurements on the SIP Server”, White Paper, April, 2002.
• “Service Assurance and Performance Management for VoIP Networks”, White Paper,
BRIX Networks, April, 2002.
• “SIP Call Setup Delay in 3G Networks”, Igor D.D. Curcio and Miikka Lundan, Nokia
Corporation, 2002.
• “Téléphonie sur IP”, Livre Blanc, Cesmo Consulting à l’initiative de France Telecom.
2004.
Page 248 sur 248

VoIP MEMOIRE DE FIN D'ETUDES ESIEA Solution IP-Centrex

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

VoIP MEMOIRE DE FIN D'ETUDES ESIEA Solution IP-Centrex

Hochgeladen von

Copyright:

Verfügbare Formate

MEMOIRE DE FIN D’ETUDES ESIEA

Parrain : Jean-Louis MAS Maître de stage : Pierre PRENEL

Auteur : Frédéric OGUER

Page 2 sur 248

1) Présentation de l’entreprise .......................................................................................... 19

a) Les partenariats Universitaires: ................................................................................ 20

b) Les partenariats Industriels : .................................................................................... 20

c) Les solutions de BSNetwork .................................................................................... 21

2) Présentation du stage .................................................................................................... 23

3) Qu'appelle t'on voix sur IP ?......................................................................................... 23

II. Déroulement du stage ....................................................................................................... 24

III. La téléphonie classique ................................................................................................ 26

1) Une brève histoire du téléphone ................................................................................... 26

a) Les fondamentaux de la voix ................................................................................... 27

b) Le fonctionnement du téléphone .............................................................................. 28

SS7 (Signaling System 7) ............................................................................................. 29

Autres types de téléphones. .......................................................................................... 31

Téléphonie 2 fils versus téléphonie 4 fils ..................................................................... 31

3) Les commutateurs privés ou PABX (Public Automatic Branch Exchange) ................ 31

a) Présentation d’un commutateur ................................................................................ 32

b) Le routage des appels dans un PABX ...................................................................... 32

c) Types d’interfaces sur un PABX .............................................................................. 33

Page 3 sur 248

a) Les « trains » numériques normalisés – 1,544 Mbps / 2,048 Mbps ......................... 33

b) La numérisation de la voix : PCM (Pulse Code Modulation) G.711 ....................... 34

La loi "A" ................................................................................................................. 35

La loi "mu" ............................................................................................................... 36

c) Puissance d’un signal numérique ............................................................................. 37

d) Distorsion apportée par le processus de quantification ............................................ 37

5) L’interface numérique 1,544 Mbps (DS-1) .................................................................. 37

a) L’interface physique ................................................................................................. 38

c) Framinig – ESF (Extended Super Frame) ................................................................ 39

d) CAS – Channel Associated Signaling (CAS) - DS-1 ............................................... 39

e) CCS – Common Channel Signaling (CCS) - DS-1 .................................................. 40

6) L’interface numérique 2,048 Mbps (E1) ...................................................................... 40

a) L’interface physique – G.703 ................................................................................... 40

b) La structure des trames – G.704 ............................................................................... 40

c) CAS – Channel Associated Signaling (CAS) – E1 .................................................. 41

d) CCS – Common Channel Signaling (CCS) – E1 ..................................................... 41

7) Le besoin de la synchronisation entre commutateurs................................................... 42

a) Commutateurs sans synchronisation ........................................................................ 42

b) Commutateurs avec synchronisation ........................................................................ 42

8) Analyse du trafic .......................................................................................................... 43

a) La théorie du trafic ................................................................................................... 43

Unités de mesure .......................................................................................................... 43

Heure de pointe ............................................................................................................ 43

Page 4 sur 248

Grade of Service ........................................................................................................... 44

Types de trafic .............................................................................................................. 44

Méthodes d’échantillonnage ........................................................................................ 45

b) Critère pour choisir un modèle ................................................................................. 47

Types d’arrivée ............................................................................................................. 47

Par pique ................................................................................................................... 48

Appels bloqués ............................................................................................................. 48

Nombre de sources ....................................................................................................... 49

c) Les modèles .............................................................................................................. 49

Equations d’états ...................................................................................................... 49

Etat d’équilibre ......................................................................................................... 51

Probabilité d’état ...................................................................................................... 52

Temps de Congestion ............................................................................................... 54

Appel bloqué ............................................................................................................ 54

Erlang en pratique .................................................................................................... 55

IV. La compression de la parole ......................................................................................... 55