Embed Size (px)
Citation preview
N° d’ordre : 10/ L3/ TCO Année Universitaire : 2012 / 2013
UNIVERSITE D’ANTANANARIVO
----------------------
ECOLE SUPERIEURE POLYTECHNIQUE
-----------------------
DEPARTEMENT TELECOMMUNICATION
MEMOIRE DE FIN D’ETUDES
en vue de l’obtention
LICENCE ES SCIENCES TECHNIQUES
en TELECOMMUNICATION
par : RATOVONANTOANDRO Sandy Mialisoa
ETUDE D’UNE IMPLEMENTATION ET GESTION
DE LA VOIP PAR « CISCO UNIFIED
CALLMANAGER »
Soutenu le 02 Juin 2014 devant la Commission d’Examen composée de :
Président : Monsieur RAKOTOMALALA Mamy Alain
Examinateurs :
Monsieur RANDRIAMITANTSOA Andry Auguste
Monsieur RANDRIAMIHAJARISON Mparany Jimmy
Monsieur RASOLOMANANA Jean Fanomezantsoa
Directeur de mémoire : Monsieur RAVONIMANANTSOA Ndaohialy Manda
i
REMERCIEMENTS
« Le secours me vient de l’Eternel qui a fait les Cieux et la Terre. » Psaumes 121 : 2
Je rends à Dieu la Gloire pour la bénédiction et toutes les aides qu’Il ne cesse de me donner chaque
jour de ma vie.
Je tiens également à remercier toutes les personnes qui ont contribué de près et de loin à la réalisation
de ce présent mémoire. Cordialement à:
- Monsieur ANDRIANARY Philippe, Professeur titulaire, Directeur de l’Ecole Supérieure
Polytechnique d’Antananarivo ;
- Monsieur RAKOTOMALALA Mamy Alain, Maître de conférences, chef de département du
département Télécommunications à l’ESPA qui me fait l’honneur de présider le jury de soutenance
de ce mémoire.
Je souhaiterais manifester ma reconnaissance particulièrement à Monsieur
RAVONIMANANTSOA Ndaohialy Manda-Vy, Maître de conférence, enseignant chercheur au
sein de l’ESPA, d’avoir accepté d’être mon encadreur, avec un suivi constant et un intérêt démontré
tout au long de mon travail.
Je tiens à temoigner ma profonde gratitude à Monsieur RASOLOMANANA Jean Fanomezantsoa,
doctorant à l’ESPA, qui n’a pas hésité à transmettre ses précieux savoirs et de m’avoir aidé à la
concrétisation de ce mémoire.
J’exprime également ma gratitude aux membres de jury qui ont accepté d’examiner ce mémoire
malgré leurs innombrables occupations:
Monsieur RANDRIAMITANTSOA Andry Auguste, Maître de Conférences.
Monsieur RANDRIAMIHAJARISON Mparany Jimmy, Enseignant chercheur.
ii
En outre, j’exprime mes reconnaissances à toutes les personnes qui m’ont aidé de prés et de loin à
la réalisation de ce mémoire. Que ces personnes trouvent dans ce travail, la récompense de leur
précieuse aide à savoir :
- les enseignants ainsi que tout le personnel administratif du Département Télécommunication pour
tous les aides qu’ils nous ont dispensé durant le cursus universitaire ;
-tous mes amis et mes proches faisant preuve de considération et de collaboration pendant
l’élaboration de ce mémoire ;
Et enfin, j’exprime un chaleureux remerciement envers toute ma famille particulièrement mes
parents et ma soeur, pour tous leurs sacrifices et leur soutien tant bien moral que matériel et qui m’a
permis de poursuivre mes études et mes projets.
« Que Dieu vous remplisse sa joie et sa paix dans tous vos projets…. »
iii
TABLE DES MATIERES
REMERCIEMENTS ...................................................................................................................................... i
TABLE DES MATIERES ........................................................................................................................... iii
ABREVIATIONS ........................................................................................................................................ vii
INTRODUCTION GENERALE ............................................................................................................ 1
CHAPITRE 1 LES RESEAUX IP ............................................................................................................... 3
1.1 Introduction ........................................................................................................................... 3
1.2 L’architecture TCP/IP .......................................................................................................... 3
1.2.1 La couche Accès Réseau ................................................................................................. 4
1.2.2 La couche Internet .......................................................................................................... 4
1.2.3 La couche transport Hôte à Hôte .................................................................................... 4
1.2.4 La couche Application ..................................................................................................... 4
1.2.5 Principe d’encapsulation dans le réseau TCP/IP .......................................................... 4
1.2.6 Hiérarchie de l’implémentation TCP/IP ........................................................................ 5
1.3 L’adressage dans les réseaux IP ........................................................................................... 6
1.3.1 Résolution d’adresses : ARP et RARP ............................................................................ 6
1.3.2 Adresse IP ........................................................................................................................ 6
1.4 Le protocole IP .................................................................................................................... 10
1.4.1 Format du datagramme IP ............................................................................................ 11
1.4.2 Taille du datagramme IP .............................................................................................. 13
1.4.3 Fragmentation IP .......................................................................................................... 13
1.4.4 Routage IP ..................................................................................................................... 14
1.5 Les protocoles TCP et UDP ................................................................................................ 15
1.5.1 Notions de port ............................................................................................................... 15
1.5.2 Le protocole TCP ........................................................................................................... 16
1.5.3 Le protocole UDP .......................................................................................................... 17
iv
1.6 Conclusion ............................................................................................................................ 18
CHAPITRE 2 L’ENVIRONNEMENT DE LA VOIP ET DE LA TOIP ............................................... 19
2.1 Généralités sur la voix sur IP ............................................................................................. 19
2.1.1 Définition ....................................................................................................................... 19
2.1.2 Les familles de Voix sur IP ........................................................................................... 19
2.1.3 Les principes de la VoIP................................................................................................ 20
2.1.4 Les protocoles de signalisation de la VoIP ................................................................... 21
2.1.5 Représentation en couche de l’architecture VoIP ....................................................... 21
2.2 Le protocole H323 ............................................................................................................... 22
2.2.1 Présentation générale .................................................................................................... 22
2.2.2 Le H.320 et le H.323 ...................................................................................................... 22
2.2.3 Les principaux apports de H.323 .................................................................................. 22
2.2.4 Les fonctions .................................................................................................................. 23
2.2.5 Le gatekeeper ................................................................................................................. 25
2.3 Le protocole Session Initiation Protocol............................................................................ 28
2.3.1 Architecture de Session Initiation Protocol ................................................................ 29
2.3.2 Etablissement d’une communication en mode client serveur ..................................... 30
2.3.3 Les messages Session Initiation Protocole ................................................................... 32
2.3.4 Les en-têtes Session Initiation Protocole ...................................................................... 33
2.3.5 Comparaison entre H.323 et SIP .................................................................................. 35
2.4 Le protocole MGCP ............................................................................................................ 35
2.4.1 Généralités ..................................................................................................................... 35
2.4.2 Principe de fonctionnement de MGCP ......................................................................... 36
2.4.3 Etablissement d’une communication MGCP ............................................................... 37
2.4.4 Messages MGCP ............................................................................................................ 38
2.4.5 Les requêtes MGCP ....................................................................................................... 38
2.4.6 Les réponses MGCP ...................................................................................................... 39
v
2.5 Les protocoles de transport ................................................................................................ 40
2.5.1 Le protocole RTP ........................................................................................................... 40
2.5.2 Le protocole RTCP ........................................................................................................ 43
2.6 Le protocole T38 .................................................................................................................. 45
2.6.1 Définition ....................................................................................................................... 45
2.6.2 Mode de fonctionnement ............................................................................................... 45
2.7 Conclusion ............................................................................................................................ 46
CHAPITRE 3 IMPLEMENTATION DE LA COMMUNICATION SUR LA VoIP ............................ 47
3.1 Introduction ......................................................................................................................... 47
3.2 Les Logiciels utilisés ............................................................................................................ 47
3.2.1 Etude comparative des IPBX ........................................................................................ 47
3.2.2 Présentation de Cisco Unified Communications Manager ......................................... 47
3.2.3 Le logiciel de Fax sur IP avec Open Text Fax Server, Right Fax Edition ................. 66
3.2.4 Les équipements clés d'une communication ToIP ....................................................... 68
3.2.5 Représentation du site pris en compte .......................................................................... 76
3.2.6 Architecture du réseau IP pris en compte ................................................................... 77
3.2.7 Conclusion ..................................................................................................................... 82
CHAPITRE 4 REALISATION D’UN RESEAU LOCAL GERE PAR CISCO UNIFIED
COMMUNICATIONS MANAGER .......................................................................................................... 83
4.1 Les équipements mis en jeu ................................................................................................ 83
4.1.1 Un routeur ..................................................................................................................... 83
4.1.2 Un switch ....................................................................................................................... 84
4.1.3 Les Téléphones IP ......................................................................................................... 85
4.1.4 Vue en perspective du réseau local entrepris nommé « LAB » ................................... 88
4.1.5 Test de l’opérabilité du réseau par un appel entre les téléphones IP .......................... 92
4.2 Conclusion ............................................................................................................................ 92
CONCLUSION GENERALE .................................................................................................................... 93
vi
ANNEXES .................................................................................................................................................... 94
ANNEXE 1 ETUDE COMPARATIVE DES IPBX .................................................................................. 94
ANNEXE 2 INSTALLATION DU CISCO UNIFIED CALLMANAGER v7 DANS LE ROUTEUR96
BIBLIOGRAPHIE .................................................................................................................................... 107
FICHE DE RENSEIGNEMENT ............................................................................................................. 109
RESUME .................................................................................................................................................... 110
ABSTRACT ............................................................................................................................................... 110
vii
ABREVIATIONS
AC Auto Conference
ANI Automatic Number Identification
API Application Programming Interface
ARP Address Resolution Protocol
CLI Command Line Interface
CLID Caller IDentification
CCM Cisco CallManager
CME Cisco CallManager Express
CDR Call Detail Records
CCM Cisco CallManager
CFA Call Forward All
CMR Call Management Records
CUCM Cisco Unified Communications Manager
CUCME Cisco Unified Communications Manager Express
CRTP Compressed Real-time Transport Protocol
DHCP Dynamic Host Configuration Protocol
DNS Domain Name Service
DoD Department of Defense
DND Do Not Disturb
DRS Disaster Recovery System
DSP Digital Signal Processor
EGP Exterior Gateway Protocol
ELIN Emergency Line Identification Number
ER Emergency Responder
ERP Exterior Routing Protocol
FAI Fournisseur d’Accès Internet (ou ISP : Internet Service Provider)
FDDI Fiber Distributed Data Interface
FoIP Fax over IP
FTP File Transfer Protocol
FXO Foreign Exchange Office
FXS Foreign Exchange Station
viii
GPL General Public License
GSM Global System for Mobile communication
GUI Graphic User Interface
HDLC High Level Data Link Control
HSS Home Subscriber Server
HTTP Hyper-Text Transport Protocol
Host ID Host Identifiant
IANA Internet Assigned Number Authority
IAX Inter-Asterisk Exchange
IBM International Business Machine
ICCS IntraCluster Communication Signaling
ICMP Internet Control Message Protocol
ID IDentifiant
IDCP Internet Device Control Protocol
IEEE Institute of Electrical and Electronics Engineers
IETF Internet Engineering Task Force
IGP Interior Gateway Protocol
IHL Internet Header Length
IPPBX Internet Protocol Private Branch Exchange
IPv4 Internet Protocol version 4
IPv6 Internet Protocol version 6
IMS IP Multimedia Subsystem
IP Internet Protocol
IRP Interior Routing Protocol
IVR Interactive Voice Response
JTAPI Java Telephony Application Programming Interface
LAN Local Area Network
LAP-B Link Access Protocol classe B
LCD Liquid Cristal Display
LDAP Lightweight Directiory Access Protocol
KPML Keypad Markup Language
LS Localisation Server
ix
MC Multipoint Controller
MCU Multipoint Control Unit
MCS Media Convergence Server
MEGACO Media Gateway Control
MGCP Media Gateway Control Protocol
MPLS Multi-Protocol Label Switching
MTU Maximum Transfer Unit
MWI Message Waiting Indication
NAT Network Address Translation
Net ID Network Identifiant
OSPF Open Shortest Path First
OSI Open System Interconnection
PABX Private Automatic Branch Exchange
PC Personal Computer
PDA Personal Digital Assistant
PME Petit et Moyenne Entreprise
PS Proxy Server
PSAP Public Safety Answering Point
PSTN Public Switched Telephone Network
QoS Quality of Service
RARP Reverse Address Resolution Protocol
RAS Registration Admission and Status
RAM Random Access Memory
RED Random Early Detection
RFC Request For Comments
RG Registrar server
RIP Routing Information Protocol
RNIS Réseau Numérique à Intégration de Service
RS Redirect Server
RSVP Resource ReSerVation Protocol
RTC Réseau Téléphonique Commuté
RTCP Real-time Transport Control Protocol
x
RTP Real-time Transport Protocol
SCCP Skinny Client Control Protocol
SCSI Small Computer System Interface
SDP Session Description Protocol
SGCP Simple Gateway Control Protocol
SIP Session Initiation Protocol
SMTP Simple Mail Transfer Protocol,
SNMP Simple Network Management Protocol
SOFTPHONE SOFTware telephone
SOAP Simple Object Access Protocol
TAPI Telephony Application Programming Interface
TCP Transmission Control Protocol
TCP/IP Transmission Control Protocol / Internet Protocol
TDM Time Division Multiplexing
TELNET TErminaL NETwork protocol
TFTP Trivial FTP
TL Total Length
TTL Time To Live
ToIP Telephony over IP
UA User Agent
UAC User Agent Client
UAS User Agent Server
UDP User Datagram Protocol
UFF User-Facing Features
UIT-T Union Internationale des Télécommunications section Télécommunication
URL Uniform Resource Locator
URI Uniform Resource Identifier
VLAN Virtual LAN
VoIP Voice over IP
WAN Wide Area Network
Wi-Fi Wireless Fidelity
WLAN Wireless Local Area Network
xi
WRED Weighted RED
WWW World Wide Web
XML Extensible Markup Language
1
INTRODUCTION GENERALE
Vu l’effet de la mondialisation aux yeux de la vie quotidienne et de la vie professionnelle, nous
sommes en présence de l’ascension de la technologie. En effet, particuliers, universités, PME et
grandes entreprises doivent apporter une évolution de leurs infrastructures informatiques ainsi que
leurs systèmes de réseaux IP pour bénéficier des diverses avantages.
Depuis longtemps, les entreprises ont adopté l’utilisation du PABX pour réduire les coûts de
communication et de gérer facilement les appels interne et externe. Le PABX traditionnel demeure
l’autocommutateur téléphonique le plus utilisé en termes de gestion de communication. Il prend en
charge le réseau à commutation de circuit RTC. Au fur du temps, on a vu l’arrivée du PABX IP ou
IPBX qui a apporté un nouvel air de développement des entreprises. L’IPBX est un système utilisé
qui assure l'acheminement de tout ou partie des communications en utilisant le protocole internet.
Aujourd’hui, les entreprises et leurs collaborateurs doivent plus que jamais échanger, partager les
informations, gérer la mobilité pour développer leur compétitivité.
Face à ce contexte et à la multiplication des médias de communication, les solutions de
communications unifiées et de travail collaboratif prennent tout leur sens. Les solutions de
Communications Unifiées, de Gestion de Présence, de Travail Collaboratif contribuent à accroître
les performances de l’entreprise tout en maîtrisant les coûts
La téléphonie sur IP (ToIP) est certainement l’application de télécommunication qui engendre le
plus d’activité dans le monde de l’entreprise. Elle a comme particularité d'associer à la fois des
notions de réseaux (transport sur réseaux IP) et des notions de télécommunications (téléphonie et
services associés), la visioconférence, le Fax sur IP (FoIP), la messagerie instantanée et bien d’autres
services qui seront rattachés aux services pris en charge par ce type de réseau IP.
La technologie de la Voix sur IP tient suffisamment l’intention à porter une étude mais en particulier
une implémentation de celle-ci à l’ESPA. Ainsi, ce présent mémoire intitulé : « Etude d’une
implémentation et gestion de la VoIP par Cisco Unified CallManager » se fixe sur ce thème.
2
Pour le premier chapitre, on traitera une vue d’ensemble des réseaux TCP/IP avec les principes des
protocoles utilisés et des différentes couches ainsi que les architectures.
Le second chapitre se rapporte sur l’environnement de la VoIP et de la ToIP suivi de l’architecture
protocolaire de la VoIP.
Ensuite, le troisième chapitre nous montre « l’Implémentation d’une communication basée sur la
VoIP» est consacré pour la mise en place des systèmes utilisés par le réseau tout en tenant compte
de l’architecture de la téléphonie sur IP et le Fax sur IP.
Le dernier chapitre présentera la réalisation d’un réseau local géré par le Cisco Unified CallManager.
3
CHAPITRE 1
LES RESEAUX IP
1.1 Introduction
Ce chapitre traite généralement l’architecture TCP/IP. Ce protocole est un protocole de
communication de système multi-utilisateurs inventé par l’Armée américaine en collaboration avec
le programme de recherche pour le développement de voies de télécommunication redondante ou
l’ARPANet. Il était primordial de contenir la bonne circulation de l’information et la confidentialité
de l’information lors des conflits mais surtout
L’adressage dans les réseaux IP et les protocoles IP utilisés seront parmi les domaines traités. Les
différentes couches du modèle TCP/IP, les adressages dans le réseau IP ainsi que les protocoles
utilisés reflèteront les facettes de ce domaine.
1.2 L’architecture TCP/IP
Tous réseaux IP reposent sur une architecture appelée TCP/IP conçue bien avant le modèle OSI. Le
modèle OSI est tellement théorique qu’il va à l’encontre de l’efficacité. Il est donc souvent simplifié.
Les simplifications se bornant toutefois à regrouper les fonctions de plusieurs couches OSI en une
seule. Avec l’architecture TCP/IP, on a un exemple de modèle simplifié de l’OSI. Comme TCP/IP
a été historiquement créé à la demande du Ministère de la défense américaine, cette architecture
porte aussi le nom de modèle DoD [4] [5].
Modèle OSI Modèle DoD
7 Couche Application Couche Application
6 Couche Présentation
5 Couche Session
4 Couche Transport Couche Hôte à Hôte
3 Couche Réseau Couche Internet
2 Couche Liaison de Données Couche Accès Réseau
1 Couche physique
Figure 1.01: Correspondance entre OSI et DoD
4
1.2.1 La couche Accès Réseau
Cette couche permet d’envoyer des paquets IP sur le réseau à travers la connexion au medium (câble,
ondes, ..). Par contre, rien n’est très précis concernant la méthode à utiliser, tout va dépendre de la
technologie utilisée. Par exemple, si on est dans un réseau local, il est possible qu’on utilise
l’implémentation Ethernet de cette couche [6].
1.2.2 La couche Internet
On retrouve les éléments importants de la couche 3 du modèle OSI. En effet, cette couche doit gérer
l’envoi des paquets (et leur réception), en mode non connecté. Le paquet doit donc pouvoir trouver
seul son chemin à travers le réseau. Pour cela, cette couche établit grâce aux protocoles ARP et
RARP, une correspondance entre l’adresse logique et l’adresse physique fourni par la couche Accès
Réseau. Le protocole IP est une implémentation de cette couche. Les problèmes, les diagnostiques
et les conditions particulières associées aux protocoles IP relèvent du protocole ICMP, qui opèrent
aussi au niveau de la couche Internet [4] [6].
1.2.3 La couche transport Hôte à Hôte
Cette couche est identique dans son rôle à la couche 4 du modèle OSI. Son rôle est d’assurer un
transfert de données entre les entités en session. Le modèle DoD comprend deux protocoles hôtes à
hôtes : TCP et UDP. Le protocole TCP est responsable du service de transmission fiable des données
avec détection et correction d’erreur tandis qu’UDP est un protocole peu fiable et peut-être utilisé
pour des applications qui n’exigent pas la fiabilité TCP [1] [4] [6].
1.2.4 La couche Application
Elle permet aux applications d’utiliser les protocoles de la couche hôte à hôte. Parmi ces
applications, on trouve : FTP, Telnet, SMTP, HTTP, VoIP, etc. La couche application interface les
applications utilisateurs à la pile de protocole TCP/IP.
1.2.5 Principe d’encapsulation dans le réseau TCP/IP
Pendant l’échange de données dans un réseau TCP/IP, les données traversent de haut en bas, la pile
TCP/IP, en émission et de bas en haut à la réception. En émission, chaque couche ajoute (encapsule)
des bits en en-têtes des données et définit une nouvelle unité de données. Ces bits représentent des
informations de contrôle de protocole utilisées comme enveloppe de chaque couche. A la réception,
chaque couche supprime (désencapsule) les en-têtes établis par la couche correspondante pendant
l’émission [2].
5
La figure suivante illustre un exemple d’échange de donnée dans un réseau TCP/IP:
Figure 1.02 : Principe d’encapsulation de données dans TCP/IP [2]
1.2.6 Hiérarchie de l’implémentation TCP/IP
La suite de protocole TCP/IP comprend un ensemble performant de services qui peuvent utiliser
une grande variété de technologie réseau comme les réseaux étendues (WAN), les réseaux locaux
(LAN), les ondes radio, les satellites ou les lignes numériques (RNIS). Les modules du protocole
TCP/IP et la relation entre eux forment la hiérarchie de l’implémentation TCP/IP.
Figure 1.03 : Hiérarchie d’implémentation TCP/IP [3]
6
1.3 L’adressage dans les réseaux IP
1.3.1 Résolution d’adresses : ARP et RARP
Chaque machine raccordée au réseau logique IP, est identifiée par un identifiant logique appelé
adresse IP indépendant de l’adressage physique utilisé dans le réseau réel. Le réseau logique IP
masquant le réseau physique, pour assurer l’acheminement des données, il est nécessaire de définir
des mécanismes de mise en relation de l’adresse logique, seule connue des applications avec
l’adresse physique correspondante (résolution d’adresses). Les techniques utilisées pour réaliser la
mise en correspondance des adresses diffèrent selon que le réseau supporte ou non la diffusion [2].
Dans les réseaux où la diffusion est réalisable, la machine source diffuse un message du type
broadcast pour s’acquérir de l’adresse physique du destinataire. Seul le destinataire, qui reconnaît
son adresse IP, répond en indiquant quelle est son adresse physique. L’émetteur mémorise cette
correspondance pour une utilisation ultérieure dans une table dite table ARP ou cache ARP. C’est le
protocole ARP qui se charge de cette résolution d’adresse IP en adresse physique. L’opération
inverse (adresse physique vers adresse IP) met en jeu le protocole RARP [2].
1.3.2 Adresse IP
1.3.2.1 Classes d’adressage
Chaque machine connectée à un réseau IP a une adresse IP représentée par quatre décimaux séparés
par des points. Chaque décimal est équivalent à un nombre binaire de 8 bits. D’où l’adressage IPv4
est de 32 bits. Une adresse IP est constituée de deux parties : un identificateur de réseau et un
identificateur de la machine pour ce réseau [1] [2]. Il existe 4 classes d’adresses, chacune permettant
de coder un nombre différent de réseaux et de machines :
a. Classe A
Les adresses de classe A s’étendent de 1.0.0.1 à 126.255.255.254. Elles permettent d’adresser 126
réseaux (27 – 2) et plus de 16 millions de machines (2 24 – 2, soit 16 777 214) [1] [2].
b. Classe B
Les adresses de classe B vont de 128.0.0.1 à 191.255.255.254, ce qui correspond à plus de 16 384
réseaux de 65 533 machines (14 bits pour les réseaux et 16 pour les machines). Cette classe est la
plus utilisée et les adresses sont aujourd’hui pratiquement épuisées [1] [2].
c. Classe C
7
La classe C couvre les adresses 192.0.0.1 à 223.255.255.254, elle adresse plus de 2 millions de
réseaux (2 097 152) de 254 machines (21 bits pour le réseau et 8 pour les machines) [1] [2].
d. Classe D
Les adresses de la classe D sont utilisées pour la diffusion (multicast) vers les machines d’un même
groupe. Elles vont de 224.0.0.0 à 239.255.255.255 (28 bits pour les machines appartenant à un même
groupe). Ce groupe peut être un ensemble de machines mais aussi un ensemble de routeurs
(diffusion des tables de routage). Certains systèmes ne supportent pas les adresses de multicast [1]
[2].
1.3.2.2 Masques de sous-réseau
Pour une adresse IP donnée, un masque est utilisé pour dissocier la partie réseau de l’adresse et la
partie hôte. C’est une valeur de format identique à l’adresse IP. Il est formé par une succession de
1 à gauche suivi d’une succession de 0. Pour chaque classe, il existe un masque par défaut [1] [2]:
- Classe A : 255.0.0.0
- Classe B : 255.255.0.0
- Classe C : 255.255.255.0
Pour subdiviser un grand réseau en des sous-réseaux comportant des nombres réduits de machine,
on peut fabriquer un masque de sous-réseau. Pour ce faire, on prend le masque par défaut puis on
emprunte des bits à la partie adresse machine, et on met ces bits à 1. Il faut noter que
- Deux bits au moins doivent rester pour adresser les machines.
- On emprunte au moins deux bits.
- Par exemple, 255.255.255.224 est un masque de sous-réseau de classe C construit en empruntant
trois bits.
1.3.2.3 Adresses spéciales
a. Adresse réseau :
Tout hôte d’un réseau IP est identifié par le couple <Net_ID><Host_ID>. Certaines valeurs de ces
champs ont une signification particulière. C’est ainsi que l’adresse <Net_ID><0>, où tous les bits du
champ Host_ID à zéro, désigne le réseau lui-même [2].
8
b. L’adresse 0.0.0.0
Cette adresse est généralement utilisée lorsqu’un nœud IP essaie de déterminer sa propre adresse IP.
Via le protocole Boot P, par exemple, le nœud qui perd connaissance de son adresse IP envoie une
requête initiale au serveur Boot P, en utilisant l’adresse IP 0.0.0.0, pour se procurer de son adresse
IP. L’adresse IP 0.0.0.0 ne peut donc pas être affectée à une machine particulière [2].
c. Adresse de boucle locale
La machine elle-même ou machine locale peut être auto-adressée avec une adresse de la forme
127. x. x. x, cette adresse dite de boucle locale (loopback ou encore localhost) est utilisée lors de
tests de la machine ou de programmes applicatifs. Tout datagramme émis à destination d’une adresse
127. x. x .x est directement recopié du tampon d’émission vers le tampon de réception, il n’est jamais
émis sur le réseau, ce qui protège ce dernier d’éventuels disfonctionnements du nouvel applicatif [2].
d. Adresses de diffusion
L’adresse 255.255.255.255 utilisée pour envoyer un message à toutes les machines du même
segment de réseau. La diffusion est limitée aux seules machines de ce segment, le datagramme n’est
pas relayé sur d’autres réseaux. L’adresse 255.255.255.255 est dite adresse de diffusion générale ou
limitée [2].
Si une machine veut s’adresser à toutes les machines d’un autre réseau, elle utilisera une adresse du
type <Net_ID><1>, tous les bits à 1 du champ Host_ID identifient toutes les machines du réseau
<Net_ID><0>. Ce message de diffusion est relayé de réseau en réseau pour atteindre le réseau
destinataire. L’adresse est dite de diffusion dirigée [2].
Figure 1.04 : Les types de diffusion [2]
9
1.3.2.4 Adresses privées et adresses publiques
L’organisme IANA offre un plan d’attribution d’adresse pour les réseaux connectés à Internet
(réseau publique). Or, tous les réseaux n’ont pas nécessairement un besoin d’interconnexion via un
réseau public, dans ce cas l’unicité d’adresse au plan mondial est inutile. Certaines entreprises
disposent de leur propre réseau (réseau privé) et n’ont aucun besoin d’interconnexion vers
l’extérieur, il est alors possible d’utiliser n’importe quelle adresse IP. Toutefois, afin d’éviter
l’anarchie dans l’utilisation des adresses, l’IANA a défini dans la RFC 1918 des plages d’adresses
réservées pour ces réseaux privés. Ces adresses sont dites privées et donc non routables sur Internet.
Le tableau 1.01 indique ces plages d’adresses.
Classe
d’adresse
Plages
d’adresses privées Masque réseau
Nombre de machines
adressables
Nombre de
réseaux
adressables
A 10.0.0.0 à
10.255.255.255
255.0.0.0 Sur 24 bits, soit 16 777 216
machines
1
B 172.16.0.0 à
172.31.255.255
255.240.0.0 Sur 20 bits, soit
1 048 576 machines
16
C 192.168.0.0 à
192.168.255.255
255.255.0.0 Sur 16 bits, soit
655 36 machines
256
Tableau 1.01: Plages d’adresses privées
Dès que ces réseaux privés ont des besoins de se connecter à un réseau public comme Internet, il
faut convertir ces adresses privées en des adresses publiques. Pour ce faire on doit renuméroter tous
les terminaux avec des adresses publiques ou bien réaliser une translation d’adresses au moyen d’un
translateur d’adresse NAT [1] [2].
Le processus de NAT fait intervenir une entité entre un terminal, ayant une adresse IP privée, et tout
autre ayant une adresse IP publique. Ce mécanisme consiste à insérer un boîtier, appelé passerelle
NAT, entre le réseau Internet et le réseau privé (LAN, intranet d’une entreprise,…). Ce boîtier se
charge de la translation des adresses IP privées en des adresses IP publiques, et effectue aussi
l’opération inverse. Actuellement, la plupart des boîtiers (Internet Box) des FAI proposent à leurs
abonnés cette fonctionnalité. La figure 1.05 illustre ce principe de NAT [1] [2].
10
Figure 1.05 : Translation d’adresses [1]
La traduction d’adresse par la passerelle NAT peut être statique ou dynamique. Dans le cas du NAT
statique, une adresse IP public fixe est associée à chaque adresse IP privée. Une table NAT
renseignée par l’administrateur du réseau contient cette association d’adresse. Pour le NAT
dynamique, une plage d’adresses publiques est disponible et partagée par tous les utilisateurs du
réseau privé. Chaque fois qu’une demande d’un utilisateur du réseau privé arrive à la passerelle
NAT, celui-ci attribut dynamiquement une adresse IP publique [1].
1.4 Le protocole IP
Défini dans la RFC 791, le protocole IP fait partie de la couche Internet de l’architecture TCP/IP et
a pour principal objectif de masquer les réseaux physiques traversés. Il permet l’adaptation de la
taille des unités de données (datagrammes) aux capacités d’emport du réseau physique traversé
(MTU), l’acheminement dans le réseau logique de ces datagrammes, sans toutefois en assurer la
livraison (Best effort) et la désignation des hôtes (adressage IP).
11
1.4.1 Format du datagramme IP
Le datagramme IP contient un en-tête IP d’une longueur minimale de 20 octets suivi des données
IP provenant des protocoles des couches supérieures. L’en-tête IP est conçu pour s’accommoder des
particularités de la couche IP. La figure 1.06 représente le format d’un datagramme IP [2][4] [7].
0 3 4 7 8 15 16 31
Version Long
En-tête
Type de
service Longueur totale
En
-têt
e m
inim
um
20
oct
ects
Identification D
F M F
offset
Durée de vie Protocole Total de contrôle
Adresse IP source
Adresse IP destination
Options
Bourrage
Champs données
Figure 1.06: Format d’un datagramme IP
Version (4 bits) : il s'agit de la version du protocole IP que l'on utilise (actuellement on
utilise la version 4 IPv4) afin de vérifier la validité du datagramme. Elle est codée sur 4 bits.
-IHL ou Internet Header Length (4 bits) : il indique, en multiple de mots de 32 bits, la
longueur de l’en-tête. La valeur courante, lorsqu’aucune option n’est invoquée, est 5 (20
octets).
-TOS ou Type de service (8 bits) : il informe le réseau de la qualité de service désirée,
spécifiant ainsi la préséance, le délai, le débit et la fiabilité.
- TL ou Total Length (16 bits): il indique la taille totale du datagramme octet. Ce champ
fait 16 bits de long ce qui limite la taille totale du datagramme à 65 536 octets.
-ID ou Identification (16 bits): Ce champ est défini de manière distinct pour chaque
datagramme et contient le numéro du datagramme. Chaque source numérote le datagramme
à partir d’une certaine valeur initiale et utilise un compteur qui sera incrémenté à chaque
datagramme envoyé. Le champ ID fait 16 bits de long, cela permet de numéroter les
12
datagrammes de 0 à 65535. Ce champ sert principalement à identifier des fragments de
datagrammes IP afin de les relier à un datagramme IP original donné.
DF ou Don’t Fragment (1 bit) : Si ce flag est à 1, cela signifie que le datagramme ne doit
pas être fragmenté.
MF ou More Fragment (1 bit) : Si ce flag est à 1, le destinataire est informé que d’autre
fragment vont suivre. Quand MF est à 0, cela indique qu’il s’agit du dernier fragment.
Offset (13 bits) : Ce champ indique, en cas de fragmentation, la position du premier bit du
fragment dans le datagramme d’origine, en multiple de 8 octets. En conséquence, tous les
fragments, sauf le dernier, ont une longueur multiple de 8
TTL ou Time To Live (8 bits) : Ce champ détermine, en seconde, la durée de vie d’un
datagramme. Ainsi ce champ est décrémenté à chaque passage dans un routeur, lorsque celui-
ci atteint la valeur critique de 0, le routeur détruit le datagramme. Cela évite l’encombrement
du réseau par les datagrammes perdus.
Protocole (8 bits) : ce champ, en notation décimale, permet de savoir de quel protocole est
issu le datagramme.
ID de protocole Abréviation Signification
0 Réservé
1 ICMP Internet Control Message Protocol
2 IGMP Internet Group Management Protocol
4 IP IP dans IP
5 TCP Transmission Control Protocol
17 UDP Datagramme utilisateur
Tableau 1.02: Les ID de protocole
Total de contrôle ou checksum (16 bits) : Ce champ contient une valeur codée sur 16 bits
qui permet de contrôler l'intégrité de l'en-tête afin de déterminer si celui-ci n'a pas été altéré
pendant la transmission. Ce champ est recalculé par chaque routeur car le champ TTL est
décrémenté au niveau du routeur ce qui modifie l’en-tête IP
Adresse IP source (32 bits) : Ce champ représente l'adresse IP de la machine source, il
permet au destinataire de répondre.
13
Adresse IP destination (32 bits) : adresse IP du destinataire du message
.Option : De longueur variable, ce champ permet d’indiquer des informations sur le niveau
de sécurité d’un datagramme, des informations de type « source root » et des informations
de« timestamp ». Ce champ est facultatif car ces informations sont rarement utilisées.
Champ données : contient les données provenant des couches supérieures (segment TCP,
message ICMP, ARP, RARP, …) [2] [4] [7].
1.4.2 Taille du datagramme IP
Comme on l'a vu précédemment, la taille d'un datagramme IP maximale est de 65 536 octets.
Toutefois cette valeur n'est jamais atteinte car les réseaux n'ont pas une capacité suffisante pour
envoyer de si gros paquets. La taille maximale d'une trame de la couche liaison de donnée, appelée
MTU, diffère selon le réseau. Voici quelques exemples de MTU associé à des types réseaux [4] [7].
Type de réseau MTU en Octets
Ethernet 1500
IEEE 802.3 1492
Tokeng ring 4440 à 17940
FDDI 4352
IEEE 802.4 8166
X25 576
Tableau 1.03: Les MTU des réseaux
1.4.3 Fragmentation IP
Si la taille d’un datagramme IP dépasse la taille du MTU du réseau qu’il doit franchir, le datagramme
ne peut être envoyé en un seul morceau. Il doit être fragmenté en morceaux de tailles inférieures au
MTU du réseau à parcourir. Cette fragmentation se fait au niveau du routeur qui se place à l’entrée
du réseau à traverser. Pour tenir compte de la fragmentation et pour faciliter le réassemblage, chaque
datagramme possède des champs, définis précédemment, comme le champ offset (permettant de
connaître la position du début du fragment dans le datagramme initial), le champ ID (numéro attribué
à chaque fragment), le champ TL (recalculé pour chaque fragment) et les champs flags DF et MF
[2] [4] [7].
14
1.4.4 Routage IP
Le routage IP fait partie intégrante de la couche IP du modèle DoD. Le routage consiste à assurer
l'acheminement d'un datagramme IP à travers un réseau en empruntant un chemin choisi suivant des
critères spécifiques déterminés par les protocoles de routage. Ce rôle est assuré par des machines
appelées routeurs, c'est-à-dire des machines reliant au moins deux réseaux.
1.4.4.1 Principe du routage
Les routeurs sont des périphériques de la couche Internet du modèle DoD qui correspond à la couche
3 du modèle OSI. Un routeur dispose au moins deux ports. Quand un datagramme IP arrive sur le
port du routeur, le logiciel de routage intégré dans le routeur examine l’en-tête du datagramme pour
déterminer la manière dont on doit la transmettre. L’information la plus déterminante est l’adresse
de destination du datagramme. Le logiciel de routage consulte la table de routage qui se trouve sur
le routeur, puis transmet le datagramme par le biais d’un des ports du routeur [4].
1.4.4.2 Les protocoles de routage
Il existe deux grandes familles de protocole de routage :
- Le protocole de routage intérieur ou IRP : qui est un protocole de routage partagé uniquement par
tous les routeurs d’un système autonome. Les protocoles IRP sont appelés aussi IGP (Interior
Gateway Protocol)
- Le protocole de routage extérieur ou ERP : qui est un protocole de routage relais entre des systèmes
autonomes. Les protocoles ERP sont appelés aussi EGP (Exterior Gateway Protocol).
Voici quelques exemples de protocole de routage :
a. Le protocole RIP
RIP est le protocole le plus utilisé dans l’environnement TCP/IP pour router les paquets entre les
passerelles du réseau Internet. C’est un protocole IGP qui utilise un algorithme permettant de trouver
le chemin le plus court. Le nombre de nœud traversés doit être entre 1 et 15. La valeur 16 indique
une impossibilité. RIP se fonde sur une diffusion périodique des états du réseau d’un routeur vers
ses voisins [1].
15
b. Le protocole OSPF
Utilisant les algorithmes de routage à état des liens, OSPF est un protocole de routage beaucoup
plus complexe mais très performant que RIP. Il utilise une base de données distribuée, qui garde en
mémoire l’état des liens. Ces informations forment une description de la topologie et de l’état des
routeurs, qui permet de définir l’algorithme de routage par un calcul des chemins les plus courts.
Les routeurs OSPF se communiquent entre eux par l’intermédiaire d’un protocole OSPF placé au-
dessus d’IP [1].
1.5 Les protocoles TCP et UDP
La couche hôte à hôte du modèle DoD, équivalente de la couche transport du modèle OSI, définit
deux grandes familles de protocoles: TCP et UDP. Ces deux protocoles assurent chacun les
fonctions caractéristiques de cette couche :
- Le transport de bout en bout (hôte à hôte) des messages provenant de la couche supérieure ;
- La création de plusieurs connexions logiques par multiplexage sur la même connexion réseau.
1.5.1 Notions de port
La notion de port est utilisée par la couche hôte à hôte pour autoriser à plusieurs programmes
d’établir une connexion simultanée et de multiplexer les données reçues des différentes applications.
C’est cette couche qui attribue, un numéro de port, à une connexion. Un numéro de port identifie
une application particulière dans une machine. Les 1024 premiers ports sont réservés, ils sont dits
référencés. Voici un tableau qui contient quelques exemples de numéros de ports associés à des
services [1] [2] [4].
Nom du service Numéro de port/ Protocole Commentaire
FTP 21/TCP Protocole de transfert de fichiers
Telnet 23/TCP Emulation de terminal
SMTP 25/TCP Service de messagerie
DNS 53/UDP Service de noms de domaine
HTTP 80/TCP Service web
H.323 1720/TCP Service de visioconférence sur IP
SIP 5060/UDP Service multimédia sur IP
Tableau 1.04: Exemples d’association de services et de numéros de ports
16
1.5.2 Le protocole TCP
Défini dans la RFC 793, TCP est un protocole de transport fiable. En effet, il ouvre une session et
effectue lui-même le control d’erreur de bout en bout. On dit qu’il est alors « en mode connecté ».
TCP ne définit qu’un seul format de segment. De ce fait, l’en-tête de TCP est prévu à la fois pour le
transport des données, des ACK et des commandes. La figure suivante décrit le format d’un segment
TCP [2] [8].
Figure 1.05: Format d’un segment TCP
Port source : codé sur 16 bits et correspond au port relatif à l'application en cours sur la machine
source.
Port destination : codé sur 16 bits et correspond au port relatif à l'application en cours sur la
machine de destination.
Numéro de séquence : codé sur 32 bits et correspond au numéro du paquet. Cette valeur permet
de situer à quel endroit du flux de données le paquet, qui est arrivé, doit se situer par rapport aux
autres paquets.
Numéro de séquence acquitté : codé sur 32 bits et définit un acquittement pour les paquets
reçus. Cette valeur signale le prochain numéro de paquet attendu. Par exemple, si il vaut 1500,
cela signifie que tous les Datagrammes <1500 ont été reçus
Longueur de l’en-tête ou offset : codé sur 4 bits et définit le nombre de mots de 32 bits dans
l'en-tête TCP. Ce champ indique donc où les données commencent.
17
Un espace de 6 bits ne sera pas utilisé. Ce champ doit être mis à 0.
Le champ flag contient 6 indicateurs:
URG : codé sur 1 bit et indique que le champ Pointeur de donnée urgente est utilisé.
ACK : codé sur 1 bit et indique que le numéro de séquence pour les acquittements est valide.
PSH : codé sur 1 bit et indique au récepteur de délivrer les données à l'application et de ne
pas attendre le remplissage des tampons.
RST : codé sur 1 bit et demande la réinitialisation de la connexion.
SYN : codé sur 1 bit et indique la synchronisation des numéros de séquence.
FIN : codé sur 1 bit et indique fin de transmission.
Fenêtre : codé sur 16 bits et correspond au nombre d'octets à partir de la position marquée
dans l'accusé de réception que le récepteur est capable de recevoir.
Total de contrôle ou checksum : codé sur 16 bits et calculé sur l’ensemble du segment
TCP, en-tête compris.
Le pointeur sur données urgentes : codé sur 16 bits, ce champ pointe sur le dernier octet
urgent du champ de données. Les données comprises entre le début du champ données et la
valeur du pointeur données urgentes sont traitées, en priorité, par le destinataire. [2] [8].
1.5.3 Le protocole UDP
UDP est un protocole de transport allégé. Il est non fiable car il n'ouvre pas de session et n’effectue
pas de control d'erreur. Il n’utilise aucun acquittement et ne met en place aucun contrôle flux. Il est
alors appelé « mode non connecté ». Tout cela explique sa simplicité et lui permet d’être plus rapide.
- UDP est utilisé pour transmettre de faibles quantités de données où le coût de la création de
connexions et du maintien de transmissions fiables s’avère supérieur aux données à émettre. UDP
peut également être utilisé pour les applications satisfaisant à un modèle de type « interrogation
réponse ». La réponse étant utilisée comme un accusé de réception l’interrogation. On y trouve
classiquement SNMP et DNS. UDP est aussi utilisé dans un second cas, dans la Voix sur IP. L'envoi
en temps réel est primordial, donc si une trame n’arrivait pas, la retransmission serait inutile [1] [2]
[9].
La figure suivante présente le format d’un segment UDP.
18
0 15 16 31
Port Source UDP Port destination UDP
Longueur Segment Checksum UDP
Données
Figure 1.06: Format d’un segment UDP
Le segment UDP ne contient que les champs ports source et destination qui tient sur 16 bits chacun
(les valeurs attribuées sont différentes de celles de TCP), le champ longueur totale du segment (en-
tête compris sur 16 bits), le champ total de contrôle (16 bits) et les données utilisateurs. L’utilisation
du champ checksum est facultative, dans ce cas, le champ est à 0.
1.6 Conclusion
Le fait d’être le support de tous les réseaux IP classe le protocole TCP/IP le plus utilisé au monde.
Le succès des réseaux IP résident dans la souplesse du protocole IP. Quant à la création de la
première génération IP appelée «Internet » et la création d’IP se sont faites en même temps. Par
ailleurs, le modèle OSI issu du modèle TCP/IP va à l’encontre de l’efficacité sur le point de vue
technique. La modélisation en couche dit modèle DoD permet de définir à part le protocole IP, deux
autres protocoles qui sont le TCP et l’UDP. Ce sont des protocoles de transport de bout en bout des
données. TCP est dit fiable et prend en charge des contrôles d’erreurs alors qu’UDP est dit non
fiable, ne garantissant aucun contrôle. UDP est très adapté pour les applications en temps réel et
c’est pourquoi il est plus sollicité en VoIP. Mais, on évoquera dans le chapitre suivant les protocoles
nécessaire et mis en jeu dans la VoIP pour assurer la signalisation, le transport et le contrôle de bout
en bout des données.
19
CHAPITRE 2
L’ENVIRONNEMENT DE LA VOIP ET DE LA TOIP
2.1 Généralités sur la voix sur IP
2.1.1 Définition
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 distinguer en vrac:
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. [11]
2.1.2 Les familles de Voix sur IP
Les subtilités sont telles que nous retiendrons toutefois qu'il existe trois grandes familles de Voix
sur IP :
De poste informatique à poste informatique :
Cela nécessite que les deux interlocuteurs soient équipés informatiquement et dialoguent en utilisant
de simples applications genre « NetMeeting » ou « Skype » utilisant pour cela un simple micro et
des hauts parleurs. Ce genre de communication est gratuite exception faite du coût du logiciel.
De Poste informatique à téléphone (ou vice-versa):
Cela nécessite la mise en œuvre d'une passerelle soit au départ de l'appel soit à l'arrivée afin de faire
transiter la communication d'un réseau IP à un réseau téléphonique. L'appel est taxé uniquement
pour la traversée du réseau téléphonique. Ainsi, pour les appels internationaux, plus la proportion
du segment IP est grande, plus l'économie réalisée ne sera importante.
De téléphone à téléphone :
Lorsque l'appelant et l'appelé sont tous les deux sur téléphone, le réseau de transport devient
transparent, cela nécessite la mise en œuvre de plusieurs passerelles. La tarification dépend de
l'opérateur, s'il s'agit d'un réseau privé, c'est gratuit. Mais c'est la solution qui permet le plus
l'intégration voix données.
20
Le fait de mettre en œuvre des postes téléphoniques IP a engendré le terme TOIP ( Telephony Over
IP) qui est une « sous branche » de la voix sur IP mais qui est plus largement utilisée. Ainsi parler
de téléphonie ou de voix sur IP bien que l’un soit plus spécifique que l’autre revient dans le langage
courant au même.
Figure 2.01 : Comparaison entre VoIP et ToIP [12]
2.1.3 Les principes de la VoIP
Le principe consiste à :
Convertir la voix (signal analogique) en un code numérique.
Compresser le code obtenu (pour diminuer la quantité de données à transmettre).
Supprimer les silences.
Expédier les données sur le réseau de la même manière qu’une page web ou un courrier par
exemple :
Découpage en paquets.
Identification (Port source, Port dest, @IP source, @IP dest, …). [13]
Figure 2.02: Principe de la VoIP
21
2.1.4 Les protocoles de signalisation de la VoIP
Avant de pouvoir communiquer directement, les interlocuteurs de la discussion doivent établir un
protocole pour se communiquer.
Les principaux protocoles utilisés pour l’établissement de la communication sont :
H.323 ;
SIP ;
IAX (SIP amélioré, issu du projet de PABX Asterisk) ;
MGCP ;
SCCP ;
Jingle ;
2.1.5 Représentation en couche de l’architecture VoIP
On peut établir une représentation en couche de la VoIP comme indique la figure suivante.
Figure 2.03 : La VoIP dans le modèle OSI
22
2.2 Le protocole H323
2.2.1 Présentation générale
H.323 est un protocole de communication englobant un ensemble de normes utilisées pour l’envoi
de données audio et vidéo sur Internet. Il existe depuis 1996 et a été initié par l’ITU (International
Communication Union), un groupe international de téléphonie qui développe des standards de
communication. Concrètement, il est utilisé dans des programmes tels que Microsoft Netmeeting
ou encore dans des équipements tels que les routeurs Cisco.
Il existe un projet Open H.323 qui développe un client H.323 en logiciel libre pour que les
utilisateurs et les petites entreprises puissent avoir accès à ce protocole sans avoir à débourser
beaucoup d’argent. [15]
2.2.2 Le H.320 et le H.323
Le protocole H.323 est utilisé pour l’interactivité en temps réel, notamment la visioconférence
(signalisation, enregistrement, contrôle d’admission, transport et encodage). C’est le leader du
marché pour la téléphonie IP. Il s’inspire du protocole H.320 qui proposait une solution pour la
visioconférence sur un réseau numérique à intégration de service (RNIS ou ISDN en anglais),
comme le service Numéris proposé par France Telecom.
Le protocole H.323 est une adaptation de H.320 pour les réseaux IP. A l’heure actuelle, la
visioconférence sur liaison RNIS est toujours la technique la plus déployée. Elle existe depuis 1990.
Les réseaux utilisés sont à commutation de circuits. Ils permettent ainsi de garantir une Qualité de
Service (QoS) aux utilisateurs (pas de risque de coupure du son ou de l'image). Aujourd'hui, c'est
encore un avantage indiscutable. Par contre, comme pour le téléphone, la facturation est fonction du
débit utilisé, du temps de communication et de la distance entre les appels. [15]
2.2.3 Les principaux apports de H.323
Définition des normes de compression des flux audio et vidéo que les équipements doivent
nécessairement supporter.
Définition des protocoles de signalisation pour l'interopérabilité des équipements.
Limitation de la bande passante réservée pour chaque type de communication.
Indépendance vis-à-vis des applications et systèmes d'exploitation.
Indépendance vis-à-vis du réseau physique supportant la communication.
23
2.2.4 Les fonctions
L'architecture H.323 fonctionne selon une stratégie bout en bout qui lui confère une transparence
vis-à-vis des évolutions du réseau. Elle s’appuie sur des protocoles de communications (RTP,
RTCP, …), mais également sur des codecs audio (G.711 obligatoire, G723.1, G.728,…) et des
codecs vidéo (H.261 et H.263). [15]
Les fonctions dédiées à H.323 sont les suivantes :
Contrôle de la procédure d'appel : requête, établissement et suivi de l'appel.
Gestion des flux multimédias : liste de codecs recommandés ou obligatoires.
Gestion des conférences multipoint : modèle de conférence géré par une entité centrale.
Gestion de la bande passante : le gatekeeper devient un centre de contrôle et a les moyens
de limiter les connexions et d'allouer la bande passante disponible.
Interconnexion à d'autres réseaux : ATM, RNIS, RTC.
H.323 définit quatre composants majeurs qui interagissent dans un réseau de paquets:
les "endpoints", qui initient un appel audio, vidéo ou visioconférence.
une passerelle («gateway») pour l’interaction avec un réseau téléphonique commuté
un élément optionnel («gatekeeper») qui permet la connectivité entre des équipements ISDN
externes qui appellent dans le réseau de paquets pour atteindre un élément H.323.
les MCUs (« Multipoint Control Units ») pour la conduite de visioconférences en multipoints
Figure 2.04 : Visioconférences en multipoint Figure 2.05: Visioconférence point à point
24
Les différents protocoles sont représentés ci-dessous par rapport à l’architecture H323 puis par
rapport au modèle OSI :
Figure 2.06: Les différents protocoles utilisés par l’architecture H323 [15]
Figure 2.07: Les différents protocoles utilisés par rapport au modèle OSI [15]
25
La signalisation se fait avec les protocoles suivants :
RAS : Gère l’admission et l’état des communications.
Q.931 : Gère les appels et le raccrochage.
H.245 : Gère l’utilisation des canaux et leur capacité.
Des fonctions optionnelles sont également proposées par les protocoles H.235 (sécurité et
authentification) et H.450.x (divers services supplémentaires). [15]
2.2.5 Le gatekeeper
Un gatekeeper agit comme un moniteur de tout appel H323 dans la partie du LAN qu’il gère. 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. [15]
Figure 2.08 : Fonctionnement du gatekeeper
26
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 entrants
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 logiciel 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. Avec un gatekeeper, l’amélioration des services d’un réseau de téléphonie
IP n’a pas de limites. Ci-dessous, nous présentons le diagramme d’un établissement de connexion
point à point avec H323. Le schéma ne s’appuie que sur les groupes de messages importants et ne
détaille pas la négociation des codecs par exemple. Pourtant la négociation des codecs existe et le
flux de données peut être contrôlé sur tout le réseau. [15]
Figure 2.09 : Exemple d’appel entre deux endpoints
27
Commençons par comprendre les bases d’un appel point à point.
L’établissement d’appel se fait à 3 niveaux différents. Endpoint1 commence par établir une
connexion TCP sur le port classique pour H323 (1720). Endpoint2 et Endpoint1 s’envoient alors
des paquets Q931 sur cette connexion.
Durant cet échange, Endpoint2 et Endpoint1 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), sans
affecter le reste de la connexion H323. En pratique, la connexion Q931 est simplement laissée de
côté.
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 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 Endpoint2 vers Endpoint1 et l’autre pour aller de Endpoint1 vers Endpoint2.
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.
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.
28
L'origine télécom de H.323 fait que son adaptation à IP est complexe et lourde à gérer ce qui la 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. [15]
2.3 Le protocole Session Initiation Protocol
Le SIP est la nouvelle norme de communication IP. On le retrouve principalement dans la téléphonie
IP, mais il sert également pour la vidéoconférence, l’indication de disponibilité, et la messagerie
instantanée.
L’idée de départ du SIP était de développer un protocole englobant toutes les fonctions de traitement
des appels actuellement offertes par le réseau téléphonique public commuté. Ainsi, le SIP gère les
fonctions standards de signalisation téléphonique telles que la composition du numéro, la sonnerie,
le signal d’appel et la tonalité qui indique lorsque la ligne est occupée.
Ce protocole a par ailleurs été conçu pour fournir de nombreuses fonctionnalités SS7 ( Signalling
System 7) de gestion des appels incluant les services de traduction de numéros, mais aussi des
options beaucoup plus complexes telles que l’identification de l’appelant. De plus, puisque le SIP
fonctionne avec un grand nombre de protocoles de transmission multimédia, il permet d’initier, de
gérer et de terminer un large éventail de services multimédia.
Le protocole SIP permet de localiser les utilisateurs d’Internet et d’établir des sessions entre eux.
Une « session » peut être un appel téléphonique basé sur IP, du « chat » via la messagerie
instantanée, un partage de pages et de documents Web, voire une importante vidéoconférence
réunissant des centaines de participants. Tandis que la plupart des protocoles utilisés sur Internet
fonctionnent grâce à la connexion établie entre un client et un serveur distant, le SIP permet aux
clients de communiquer entre eux. Ainsi, un utilisateur équipé d’un ordinateur, portable ou non, ou
même d’un PDA relié au réseau, peut établir une session multimédia directement avec un autre
utilisateur.
Le SIP permet une interaction multimédia en temps réel, intégrant en toute transparence la voix, les
données et la vidéo en une session spécifique. Par exemple, vous pouvez inclure dans une même
session SIP, une vidéo conférence avec un groupe de collègues, la distribution de documents
29
électroniques et l’envoi d’un message confidentiel instantané à l’un d’eux. Tout cela grâce à une
connexion unique dédiée.
Chaque utilisateur SIP se voit attribuer une identité unique comparable à une adresse e-mail. Elle
est utilisée par le serveur SIP pour l’identifier quel que soit le moyen de connexion au réseau utilisé.
En pratique, cela se traduit par un accès à des services multimédia personnalisés et homogènes
depuis quasiment n’importe où. [16]
2.3.1 Architecture de Session Initiation Protocol
Pour établir et terminer des communications multimédia, SIP utilise les 5 fonctions suivantes :
User location : permet de localiser le poste terminal utilisé pour communiquer
User capabilities : détermine quels média vont être échangés (voix, vidéo, données…) ainsi
que les paramètres associés ;
User availability : détermine si le poste appelé souhaite communiquer et autorise l’appelant
à la contacter ;
Call setup ou " ringing ": avertit les parties appelant et appelé de la demande d’ouverture
de session (sonnerie ou message de réception d’appel) et mise en place des paramètres
d’appel.
Call handling : gère le transfert et la fermeture des appels. [16]
SIP permet l’ouverture de sessions entre :
2 utilisateurs unicast : communication entre 2 stations.
plusieurs utilisateurs en multicast : via une unité de contrôle M.C.U. (Multipoint Control
Unit).
plusieurs utilisateurs pleinement interconnectés en multicast via un réseau à maillage
complet de connexions.
Notons que les utilisateurs reliés au Réseau Téléphonique Commuté Public (P.S.T.N. pour Public
Switched Telephone Network) peuvent utiliser SIP car le PSTN est interconnecté au réseau des
réseaux grâce à des passerelles (gateways). [16]
L’architecture en couches de SIP, telle que la présente le modèle OSI, fait apparaître une palette
de nombreux protocoles :
30
Figure 2.10 : Palette de nombreux protocoles de l’architecture en couche de SIP [16]
SIP peut être également utilisé sur ATM(AAL5), X25 et frame relay.
A chacune des couches de l’architecture SIP sont associés des protocoles tels que :
RSVP est un protocole utilisé pour réserver les ressources réseaux sur IP avec une excellente
qualité de service (QoS).
R.T.P.(Real-time Transport Protocol) pour transporter des informations en temps réel avec
une excellente qualité de services.
R.T.C.P.(Real-Time streaming Control Protocol) pour assurer le contrôle de flux des
données multimédia .
S.A.P.(Session Announcement Protocol) pour préciser si les sessions multimédia ouvertes
le sont en multicast .
S.D.P.(Session Description Protocol) est un protocole de description des sessions
multimédia. [16]
2.3.2 Etablissement d’une communication en mode client serveur
Pour établir une communication, l’appelant, que l’on désignera par client, adressera sa requête à un
serveur SIP, qui lui donnera les moyens de communiquer.
Seulement il existe 5 types de serveurs :
31
l’U.A.S. (User Agent Server) : c'est l'application du terminal d'abonné qui reçoit les
requêtes et l'U.A.C (User Agent Client) est l'application de ce même terminal qui émet les
requêtes.
le relais mandataire ou P.S. (Proxy Server) : auquel est relié un terminal fixe ou mobile
(lors de son déplacement, le terminal est relié au PS le plus proche et change constamment
de PS) agit à la fois comme client et serveur. Un tel serveur peut interpréter et modifier les
messages qu’il reçoit avant de les retransmettre.
le R.S. (Redirect Server) : réalise simplement une association (mapping) d’adresses vers
une ou plusieurs nouvelles adresses (lorsqu’un client appelle un terminal mobile - redirection
vers le PS le plus proche - ou en mode multicast - le message émis est redirigé vers toutes
les sorties auxquelles sont reliés les destinataires -). Notons qu’un Redirect Server est
consulté par l'UAC comme un simple serveur et ne peut émettre de requêtes contrairement
au PS.
le L.S. (Location Server) fournit la position courante des utilisateurs dont la communication
traverse les RS et PS auxquels il est rattaché : cette fonction est assurée par le service de
localisation.
Le R.G (Registrar) est un serveur qui accepte les requêtes REGISTER et offre également
un service de localisation comme le LS. Chaque PS ou RS est généralement relié à un
Registrar.
L’ouverture d’une session à l’aide du protocole SIP peut s’effectuer de façon directe entre deux
User Agents jouant le rôle du client et du serveur ou de façon indirecte au travers d’un serveur proxy.
Dans ce dernier cas, le serveur à en charge la localisation du serveur B (Exemple II.2.1) dont l’adresse
est passé dans le message INVITE. Dans le cas de changement de localisation, le serveur proxy est
renseigné sur l’adresse de l’utilisateur à l’aide du serveur de localisation. Et le serveur proxy adresse
un message 302 MOVE TEMPORARILY avec les nouvelles coordonnées de localisation. [16]
32
Figure 2.11: Exemple d’appel entre deux clients SIP
2.3.3 Les messages Session Initiation Protocol
Un message SIP peut être à la fois une requête d’un client vers un serveur ou une réponse d’un
serveur vers un client. Ces deux types de messages SIP utilisent le format suivant :
Figure 2.12: Les composants d’un message SIP [16]
2.3.3.1 Les requêtes
Les méthodes utilisées par les requêtes SIP sont les suivantes :
INVITE : indique que l’application ou l’utilisateur est invité à participer à une session. Le
Corps du message contient la description de la session (média supportés par l’appelant entre
autres).
33
ACK : confirme que le client a reçu une réponse définitive à une requête INVITE.
OPTIONS : un PS en mesure de contacter l’UAS appelé, doit répondre à une requête
OPTIONS en précisant ses capacités à contacter l’UAS.
BYE : est utilisée par l’UAS de l'appelé pour signaler au PS local qu’il ne souhaite plus
participer à la session.
CANCEL : la requête CANCEL permet d’annuler une requête non validée par une réponse
finale d’état.
REGISTER : cette méthode est utilisée par le client pour enregistrer l’adresse listée dans
l’URL TO par le serveur auquel il est relié. [16]
2.3.3.2 Les réponses
Chaque réponse aux requêtes reçues est caractérisée par ce qu’on appelle un code et un motif,
appelés respectivement Code d’état et Reason Phrase. Le motif étant la définition en clair du code
d’état. Il existe 6 classes de réponses :
1xx = Information : la requête a été reçue et continue à être traitée ;
2xx = Succès : l’action a été reçue avec succès, comprise et acceptée ;
3xx = Redirection : une autre action doit être menée afin de valider la requête ;
4xx = Erreur du client : la requête contient une syntaxe erronée ou ne peut pas être traitée
par ce serveur ;
5xx = Erreur du serveur : le serveur n’a pas réussi à traiter une requête apparemment
correcte ;
6xx = Echec général : la requête ne peut être traitée par aucun serveur. [16]
2.3.4 Les en-têtes Session Initiation Protocol
Les différents champs d'en-tête qu'utilise SIP ne nécessitent pas d'ordre particulier sauf dans le cas
de l'en-tête général Via où l'ordre des champs d'en-tête importe. En particulier, l'on distingue les
champs d'en-têtes des messages transmis saut par saut (c'est-à-dire qui sont interprétés et peuvent
être modifiés ou ajoutés par tous les serveurs qu'ils traversent) des en-têtes des messages transmis
de bout en bout (interprétés par les émetteurs et destinataires uniquement et non modifiables par les
serveurs traversés). Les champs d'en-tête saut par saut doivent apparaître avant les champs d'en-tête
34
de bout en bout. Les PS ne doivent pas réordonner les champs d'en-tête mais peuvent ajouter
éventuellement des champs Via ou autres champs de type "saut par saut".
Chaque méthode (ACK, BYE, CANCEL, INVITE, OPTIONS, REGISTER) requière, ne supporte
pas ou supporte de façon optionnelle certains champs d'en-tête. Par exemple, les champs d'en-tête
CALL-ID, Cseq, FROM, TO et Via sont requis par toutes les méthodes (dans le cas de la méthode
OPTIONS, il faut ajouter en plus le champ d'en-tête Allow ). Ces champs d'en-tête sont de type "de
bout en bout".[16]
Il existe 4 types de champs d'en-tête:
En-tête général : s’applique à la fois aux messages de requête et de réponse : Accept ou
Accept-Encoding ou Accept-Language ou CALL-ID ou Contact ou Cseq ou Date ou
Encryption ou Expires ou From ou Record-Route ou Timestamp ou To ou Via
En-tête d’entité: définit le type d'informations contenues dans le Corps du message ou la
ressource identifiée par la requête en l'absence du Corps du message : Content-Encoding ou
Content-Lenght ou Content-Type
En-tête de requête Le champ d'en-tête de requête autorise le client à ajouter des
informations concernant sa requête et lui-même à destination du serveur : Authorization ou
Contact ou Hide ou Max-Forwards ou Organization ou Priority ou Proxy-Authorization ou
Proxy-Require ou Route ou Require ou Response-Key ou Subject ou User-Agent
En-tête de réponse. Le champ d'en-tête de réponse autorise le serveur à ajouter des
informations concernant sa réponse, qui ne peuvent pas être placées dans la ligne d'état, sur
lui-même et sur l'accès à la ressource identifiée par la requête URI : Allow ou Proxy-
Authorization ou Retry-After ou Server ou Unsupported ou Warning ou WWW-
Authenticate.
Contrairement aux protocoles standards tels qu’IP ou TCP, où le format des paquets ou des segments
est bien déterminé, le format des messages SIP n’est pas standard. Les champs d’en-tête sont
choisis " à la carte " selon un panel de champs. Lorsque les messages SIP sont transportés par UDP,
avec authentification et une description de session complexe, il arrive que la taille du message SIP
de requête ou réponse dépasse la MTU. Pour résoudre ce problème, un format compact a été défini
utilisant des abréviations pour certains champs. [16]
35
2.3.5 Comparaison entre H.323 et SIP
SIP H323
Nombre d’échanges pour
établir la connexion
1,5 aller-retour
6 à 7 aller-retour
Maintenance du code
protocolaire Simple par sa nature textuelle à
l'exemple de HTTP
Complexe et nécessitant un
compilateur
Evolution du protocole
Protocole ouvert à des nouvelles
fonctions
Ajout d'extensions
propriétaires sans concertation
entre vendeurs
Fonction de conférence Distribuée Centralisée par l'unité MCU
Fonction de téléservices Oui, par défaut H.323 v2 + H.450
Détection d'un appel en
boucle
Oui
Inexistante sur la version 1 un
appel routé sur l'appelant
provoque une infinité de
requêtes
Signalisation multicast Oui, par défaut Non
Tableau 2.01: Comparaison entre H.323 et SIP [17]
La simplicité, la rapidité et la légèreté d'utilisation, tout en étant très complet, du protocole SIP sont
autant d'arguments qui pourraient permettre à SIP de convaincre les investisseurs. De plus, ses
avancées en matière de sécurité des messages sont un atout important par rapport à ses concurrents
[17].
2.4 Le protocole MGCP
2.4.1 Généralités
Résultantes de plusieurs initiatives comme SGCP, IDCP ; le protocole MGCP ou Media Gateway
36
Control Protocol a été standardisé en 1998 à l’IETF par le groupe de travail MEGACO. Au début,
la RFC 2705 présentait la première version de MGCP. Celle-ci sera rendue obsolète en janvier
2003 par la RFC 3435, qui sera complétée par la RFC 3661, en décembre 2003 [1].
MGCP et ces antécédents ont été conçus pour suivre un modèle client-serveur ou aussi maître
esclave.
L’idée-force est de disposer d’un réseau dont toutes les passerelles multimédias soient des
composants simples (esclaves). Ces passerelles sont reliées à un contrôleur maître concentrant toute
l’intelligence du réseau et centralisant les décisions [1].
2.4.2 Principe de fonctionnement de MGCP
Pour comprendre son fonctionnement, MGCP définit deux types d’entités : Le Call Agent et les
passerelles multimédias. Le protocole MGCP s’applique uniquement à transmettre de la
signalisation entre ces deux entités. Les flux de données multimédias ne transitent jamais par le
Call Agent [1].
Figure 2.13: Architecture MGCP [1]
a. Le Call Agent
Egalement appelé contrôleur de passerelles multimédias ou MGC, le Call Agent est l’entité maître
d’un architecture MGCP. Il a pour fonction de contrôler les passerelles et de concentrer toute
l’intelligence ainsi que la prise de décision dans le réseau. Pour ses communications, le Call
37
Agent utilise par défaut le port 2727 [1].
b. Les passerelles multimédias
Selon le protocole MGCP, une passerelle multimédia est une entité simple dit esclave ayant des
fonctionnalités réduites par rapport à la notion de passerelle introduite dans H.323. Pratiquement,
elle peut être une passerelle d’opérateur téléphonique, une passerelle résidentielle de type box ou un
PBX d’entreprise. Pour ses communications, les passerelles utilisent par défaut le port 2427.
2.4.3 Etablissement d’une communication MGCP
Pour mettre en relation les deux endpoints (terminaux), MGCP définit les cinq étapes illustrées par
la figure suivantes:
Figure 2.14: Mise en relation de deux endpoints [1]
1: Requête de création de connexion vers la première passerelle : Le Call Agent sollicite la d’une
connexion avec un endpoint auprès d’une passerelle reliée à cet endpoint.
2 : Réponse de la première passerelle : La passerelle sollicitée attribue à l’endpoint les ressources
nécessaires à la communication. Une session est donc créée entre les deux. En retour, la passerelle
envoi au Call Agent un descriptif de la session créée contenant les paramètres permettant de joindre
l’endpoint (adresse IP, port UDP, codecs,..).
3 : Requête de création de connexion vers la seconde passerelle : De même façon que pour la
première endpoint, le Call Agent envoie un message de création de session à la passerelle reliée à la
seconde endpoint. En plus, il spécifie dans ce message le descriptif de session retourné par la
première passerelle.
4 : Réponse de la seconde passerelle : La seconde passerelle agit de la même manière que la
première passerelle. Une session est aussi créée entre elle et Endpoint_2.
38
5 : Mise en relation des deux endpoints : Le Call Agent contacte la première passerelle et lui
transmet le descriptif de la session retournée par la seconde passerelle. Comme une connexion déjà
avec l’endpoint, il n’est pas nécessaire de créer une nouvelle connexion. Il suffit de modifier celle
qui existe et de la compléter. C’est donc une commande de modification qui est effectuée par le Call
Agent.
Une fois ces étapes achevées, la communication peut être débuté dans les deux sens. Elle peut être
modifiée ou terminée à tout moment par le Call Agent [1].
2.4.4 Messages MGCP
Un message MGCP est soit une requête soit une réponse à une requête. Il est constitué sous forme
textuelle et présente plusieurs analogies avec le message SIP. Ainsi, une transaction MGCP est-elle
constituée d’une requête et de la réponse à cette requête éventuellement précédée de réponses
temporaires [1].
Le format d’un message MGCP est illustré par la figure suivante :
Figure 2.15: Format de message MGCP [1]
2.4.5 Les requêtes MGCP
Pour établir la communication entre Call Agent et passerelles, MGCP définit neuf requêtes. Ces
requêtes peuvent être distinguées en deux catégories de commandes: celles qui sont lancées par le
Call Agent vers une ou plusieurs passerelles et celle qui est envoyée par une passerelle pour un
Call Agent [1].
39
Format complet Format
abrégé Description
Endpoint Configuration EPCF Utilisée par le Call Agent pour informer la passerelle des
caractéristiques (codage) d’un endpoint distant.
Create Connection CRCX Utilisée par le Call Agent pour créer une connexion entre
passerelle et endpoint
Modify Connection MDCX Utilisée par le Call Agent pour modifier les paramètres
associés à une connexion déjà établie.
Delete Connection DLCX Utilisée par un Call Agent pour supprimer une connexion
existant. Peut être utilisée aussi par une passerelle pour
informer le Call Agent qu’une connexion peut être supprimée.
Notification Request RQNT Utilisée comme moyen d’inviter la passerelle à observer des
événements spécifiques tels que le décrochage sur un endpoint
indiqué.
Notify NTFY Utilisée par une passerelle pour informer le Call Agent de la
production d’un évènement spécifique.
Audit Endpoint AUEP Utilisée par le Call Agent pour découvrir le statut d'un
endpoint donné
Audit Connexion AUCX Utilisée par le Call Agent pour rechercher les paramètres
attachés à une connexion.
Restart In Progress RSIP Utilisée par une passerelle pour signaler le Call Agent qu'un
endpoint, ou un groupe d’endpoint, est mise en service et
d’autres deviennent hors de service.
Tableau 2.02 : Les requêtes MGCP [18]
2.4.6 Les réponses MGCP
Similaire à SIP, MGCP utilise des réponses sous forme de code (nombre entier) et de motif
éventuellement suivi de paramètre de réponse (nombre entier). Le tableau suivant récapitule les
plages de code de réponse [18].
40
Plage de code
de réponse
Signification
000 à 099 Indiquent une reconnaissance de réponse
100 à 199 Indiquent une réponse temporaire
200 à 299 indiquent un accomplissement réussi
400 à 499 Indiquent une erreur passagère
500 à 599 Indiquent une erreur permanente
Tableau 2.03: Les réponses MGCP [18]
2.5 Les protocoles de transport
Entre les deux grandes familles de protocoles de transport qui sont TCP et UDP, le protocole UDP
s’impose pour le transfert des flux multimédia pour des raisons d’efficacité en temps réel. Pour
apporter un peu plus de fiabilité dans le transport des flux voix, deux protocoles complémentaires
ont été adjoints à UDP, le premier, RTP a essentiellement pour objet de fournir les informations
nécessaires à la correction de gigue. Le second, intégré dans RTP, RTCP fournit périodiquement
des informations sur la qualité du réseau. RTP et RTCP sont définis, depuis juillet 2003, par la RFC
3550 rendant obsolète la version précédente RFC 1889 [2].
2.5.1 Le protocole RTP
RTP est un protocole qui a été développé par l'IETF afin de faciliter le transport temps réel de bout
en bout des flots de données audio et vidéo sur les réseaux IP. L'utilisation de RTP se fait
généralement au-dessus d’UDP ce qui permet d'atteindre plus facilement le temps réel. Qui dit
application temps réel, dit présence d'une certaine qualité de service (QoS) que RTP ne garantit pas.
De plus RTP est un protocole qui se trouve dans un environnement multipoint, donc on peut dire
que RTP possède à sa charge, la gestion du temps réel, mais aussi l'administration de la session
multipoint [17].
2.5.1.1 Les fonctions de RTP
Le protocole RTP, standardisé en 1996, a pour but d'organiser les paquets à l'entrée du réseau et de
les contrôler à la sortie. Ceci de façon à reformer les flux avec ses caractéristiques de départ [17].
41
RTP est un protocole adapté aux applications présentant des propriétés temps réel. Il permet ainsi
de :
Reconstituer la base de temps des flux (horodatage des paquets : possibilité de
resynchronisation des flux par le récepteur).
Mettre en place un séquencèrent des paquets par une numérotation et ce afin de permettre
ainsi la détection des paquets perdus. Ceci est un point primordial dans la reconstitution des
données.
Identifier le contenu des données pour leurs associer un transport sécurisé.
Transporter les applications voix dans des trames (avec des dimensions qui sont dépendantes
des codecs qui effectuent la numérisation). Ces trames sont incluses dans des paquets afin
d'être transportées et doivent de ce fait être récupérées facilement au moment de la phase de
dépaquetage afin que l'application soit décodée correctement [17].
En revanche, ce n'est pas la solution qui permettrait d'obtenir des transmissions temps réel sur IP.
En effet, il ne procure pas de :
Réservation de ressources sur le réseau (pas d'action sur le réseau);
Fiabilité des échanges (pas de retransmission automatique, pas de régulation automatique du
débit);
Garantie dans le délai de livraison et dans la continuité du flux temps réel.
De plus l’encapsulation RTP n’est perçue que par les machines périphériques. Donc, les routeurs
intermédiaires ne peuvent pas différencier les paquets RTP des autres [19].
2.5.1.2 En-tête RTP
L'en-tête d'un paquet RTP est obligatoirement constitué de 16 octets. Cet en-tête précède le
« payload » qui représente les données utiles.
Figure 2.16 : En-tête RTP [20]
42
V (Version) : Ce champ, codé sur 2 bits, permet d'indiquer la version de RTP. Actuellement, V=2.
P (Padding) : Ce bit indique, s’il est à 1, que les données possèdent des octets de bourrage. Le
nombre d’octets de bourrage est précisé dans la charge utile.
X (Extension) : Ce bit spécifie, s’il est à 1, que l'en-tête est suivi d’un en-tête supplémentaire.
CC (CSRC Count) : Ce champ, codé sur 4 bits, représente le nombre de CSRC qui suit l'en tête.
M (Marker) : Le bit M (Marker) définit un profil RTP, par exemple, si la récupération des
silences est activée, dans chaque premier paquet d’un échange ce bit est à 1.
PT (Payload Type) : Basé sur 7 bits, ce champ identifie le type du payload (audio, vidéo, image,
texte, html, etc.) et le format de codage.
Numéro de séquence : Ce champ, d'une taille de 2 octets, représente le numéro d'ordre
l'horloge système ou l'horloge d'émission des paquets. Sa valeur initiale est aléatoire et il
s'incrémente de 1 à chaque paquet envoyé, il peut servir à détecter des paquets perdus.
Timestamp : Ce champ horodatage, de 4 octets, représente l'horloge retour d'informations
d'échantillonnage de l'émetteur. Elle doit être monotone et linéaire pour assurer la
synchronisation des flux. Cette information permet la récupération de la gigue, sa valeur initiale
est aléatoire.
SSRC (Synchronisation Source Report Count) : Basé sur 4 octets, ce champ identifie de
manière unique la source de synchronisation, sa valeur est choisie de manière aléatoire par
l'application.
CSRC (Contributing Source Report Count) : Ce champ, sur 4 octets, identifie les sources de
contribution. Ce champ est utilisé quand plusieurs sources fournissent des informations et que
le paquet contient des informations reconstituées à partir de ces différentes sources.
Bien qu'autonome, RTP peut être complété par RTCP. Ce dernier apporte un retour sur la
transmission et sur les éléments destinataires [17].
43
Figure 2.17 : Relation entre RTP et RTCP [20]
2.5.2 Le protocole RTCP
2.5.2.1 Fonction de RTCP
Le protocole RTCP est fondé sur la transmission périodique de paquets de contrôle à tous les
participants d'une session. Le protocole RTP utilise le protocole RTCP qui transporte les
informations supplémentaires suivantes pour la gestion de la session [17]:
Les récepteurs utilisent RTCP pour renvoyer vers les émetteurs un rapport sur la QoS. Ces
rapports comprennent le nombre de paquets perdus, la gigue et le délai aller-retour. Ces
informations permettent à la source de s'adapter ie de modifier le niveau de compression pour
maintenir une QoS.
Une synchronisation supplémentaire entre les médias : Les applications multimédias sont
souvent transportées par des flots distincts.
L'identification : En effet, les paquets RTCP contiennent des informations d'adresses, comme
l'adresse d'un message électronique, un numéro de téléphone ou le nom d'un participant à une
conférence téléphonique.
Le contrôle de la session : Parce que RTCP permet aux participants d'indiquer leur départ d'une
conférence téléphonique (paquet Bye de RTCP) ou simplement de fournir une indication sur
leur comportement.
Le protocole RTCP demande aux participants de la session d'envoyer périodiquement les
informations citées ci-dessus. On peut dire que les paquets RTP ne transportent que les données des
utilisateurs. Tandis que les paquets RTCP ne transportent en temps réel, que de la supervision.
44
On peut détailler les paquets de supervision en 5 types :
200 : SENDER REPORT: Ce rapport regroupe des statistiques concernant la transmission
(pourcentage de perte, nombre cumulé de paquets perdus, variation de délai (gigue), ...Ces
rapports sont issus d'émetteurs actifs d'une session.
201 : RECEIVER REPORT: Ensemble de statistiques portant sur la communication entre
les participants. Ces rapports sont issus des récepteurs d'une session.
202 : DESCRIPTION SOURCE: Carte de visite de la source (nom, e-mail, localisation).
203 : BYE: Message de fin de participation à une session.
204 : APPLICATION SPECIFIC: Fonctions spécifiques à une application. Ces différents
paquets de supervision fournissent aux nœuds du réseau les instructions nécessaires à
meilleur contrôle des applications temps réel.
2.5.2.2 En-tête RTCP
Voici l'en-tête commun à tous les paquets RTCP.
Figure 2.18 : En-tête RTCP [20]
V : Ce champ, codé sur 2 bits, permet d'indiquer la version de RTP, qui est la même que
dans les paquets RTCP. Actuellement, V=2
P : Ce bit indique, s’il est à 1, que les données possèdent une partie de bourrage.
RC : Ce champ, basé sur 5 bits, indique le nombre de blocs de rapport de réception contenus
en ce paquet. Une valeur de zéro est valide.
PT : Ce champ, codé sur 1 octet, est fixé à 200 pour identifier ce datagramme RTCP comme
SR.
Longueur : Ce champ de 2 octets, représente la longueur de ce paquet RTCP incluant l'en
et le bourrage.
SSRC : Basé sur 4 octets, ce champ, représente l'identification de la source pour le paquet
SR [17].
45
2.6 Le protocole T38
2.6.1 Définition
T38 est un protocole qui décrit comment envoyer un fax à partir d’un réseau de données
informatiques. T38 est indispensable car les données de fax ne peuvent pas être envoyées à un réseau
de données informatiques de la même façon que la communication vocale.
T38 est décrit dans le RFC 3362, et défini la façon dont un appareil doit communiquer les données
de fax. Dans l’image ci-dessous, la passerelle et la télécopieuse derrière la passerelle doivent être
compatibles avec T38. En ce qui concerne le fax G3sur une ligne analogue, ce procédé sera
transparent. La télécopieuse analogue n’a pas besoin de connaître le T38.[13]
Figure 2.19 : Envoi et réception de fax venant d’un fax analogique vers un fax over IP
2.6.2 Mode de fonctionnement
Le schéma suivant illustre une implémentation type de fax sur IP en temps réel avec un serveur de
fax basé sur une carte TR1034 résidant derrière une passerelle/routeur Cisco qui supporte le contrôle
des appels SIP.
Figure 2.20 : Les étapes de fonctionnement du Fax sur IP [24]
46
Etape 1: Le serveur fax basé sur carteTR1034 est connecté à un réseau IP sur lequel il transmet les
données des images fax et du protocole T.30 à l'aide de paquets T.38 vers la passerelle/routeur Cisco
réceptrice.
Etape 2: La passerelle/routeur Cisco retransforme à son tour les paquets T.38 en signaux de
protocole T.30 et les transmet au télécopieur destinataire via le réseau RTPC.
Etape 3: Le télécopieur destinataire comporte un moteur de protocole T.30 qui communique avec
celui du serveur fax TR1034 via la passerelle Cisco. [24]
2.7 Conclusion
La VoIP est le transport de la Voix sur un réseau IP. Ainsi, on peut communiquer par la Voix sur
un réseau IP. On a pu voir que les différents protocoles peuvent permettre ce transport. En outre, les
technologies de multimédias sont les points forts de la VoIP Les protocoles de signalisation tels que
le H323, le SIP et le MGCP ainsi que les protocoles de transport : RTP et le RTCP ne garantissent
en aucun cas le transport en « temps réel » des communications. Mais des solutions ont été entreprises
pour faire face à ces failles.
Le protocole T38 pour le fax sur IP améliore la productivité et réduit les coûts dans tout le réseau
dans le domaine de distributions des documents.
47
CHAPITRE 3
IMPLEMENTATION DE LA COMMUNICATION SUR LA VoIP
3.1 Introduction
La communication sur IP est une technologie rénovatrice plus simple, rapide et économique pour la
communication en entreprise. Pour faciliter la gestion de celle-ci, des solutions sont disponibles
selon les différentes exigences d’une entreprise.
On les appelle IPBX ou PABX IP signifiant Private Automatic Branch Exchange Internet Protocol.
C’est un autocommutateur téléphonique privé utilisant le protocole Internet pour gérer les appels
téléphoniques d’une entreprise en interne sur un réseau local (LAN) .Associé à la technologie de la
Voix sur IP, le réseau pourra effectuer des communications téléphoniques en réseau étendu (WAN).
Tenant compte qu’il existe un nombre de solutions d’IPBX définies selon leurs caractéristiques et
leurs capacités mais le dernier mot appartient à chaque entreprise.
3.2 Les Logiciels utilisés
3.2.1 Etude comparative des IPBX
Dans l’annexe 1, on a effectué un tableau de comparaison entre les solutions IPBX qui sont les plus
utilisés : ASTERISK, Cisco Unified Communications Manager et Alcatel Lucent.
Les caractéristiques de chacun d’eux nous ont permis de tenir compte de ces apports correspondants
à notre implémentation.
Pour notre part, on a choisi d’utiliser la solution Cisco Unified Communications Manager pour ses
nombreux avantages.
3.2.2 Présentation de Cisco Unified Communications Manager
Il y a des années, Cisco Unified Communications Manager (CUCM) et le Cisco Unified
Communications Manager Express (CME) étaient nommés Cisco CallManager (CCM) et Cisco
CallManager Express(CME). Des années après, le nom de CallManager vit dessus car il est plus
simple de le dire. Ainsi, si vous n’entendez jamais quelqu’un dire « allons installer CallManager »
ce n’est probablement pas la meilleure expression à dire, « Saviez-vous que le Cisco l’a renommé
Cisco Unified Communications Manager ?
48
3.2.2.1 Vue d’ensemble de Cisco Unified Communications Manager (CUCM)
Juste en jetant un coup d’œil à la suite des produits CISCO pour la VoIP, il s’avère que CISCO
essaye de transmettre quelque chose. Le thème résonnant le plus utilisé est « Unified » ou « unifié »
en français (avec « collaboration » en entrée second).Mais, quand vous épluchez l’externe des
ventes, vous trouvez qu’il y a beaucoup plus d’ « unifié » que juste du VoIP. Cette matière croise
des frontières et rassemble toute la communication en une seule, cadre sans couture. Les équipes de
travail virtuelles ont comporté des individus de télétravail partageant les whiteboards, la
documentation et les plans de projet dedans en temps réel, un responsable des ventes de mobile
menant la réunion vidéo-coulée d’équipe à partir des dispositifs mobiles dans sa voiture. Oui, nous
sommes certainement venus loin des modems et des systèmes commutés de tableau de bord ou
Bulletin Board Systems (BSS).
La stratégie unifiée de CISCO entoure tous les types de communication électronique: voix, vidéo et
données. Néanmoins, la plupart des ingénieurs qui entendent l’expression « Unified
Communications » ou « communication unifiée » se relie directement aux produits de VoIP de Cisco
et c’est ce qu’on va comprendre par la suite.
Description de Cisco Unified Communications
Le Cisco Unified Communications (UC) est une intégration de système de communications basé
sur IP intégrant la voix, la vidéo, les données, produits et applications de mobilité. Elle permet des
communications plus efficace et plus sures mais peuvent aussi transformer la manière dont nous
communiquons.
Le Cisco UC enlève les barrières géographiques des communications efficaces par l'utilisation de la
voix, de la vidéo, et l’intégration des données. Des affaires peuvent être conduites avec une fluidité
qui progresse et évolue avec vous.
L'information a été aux bouts de nos doigts pendant longtemps, mais Cisco UC permet le partage
de cette information pour créer la connaissance et la valeur.
Le Cisco UC fait partie d'une solution intégrée qui inclut l'infrastructure de réseau, la sécurité, la
mobilité, les produits de gestion de réseau, les services de cycle de vie, le déploiement flexible et
des options de gestion d’externalisation des paquets de financement d'utilisateur et d'associés et un
tiers d’applications de communication.
49
Cisco UC peut changer rigoureusement le résultat des affaires en créant les communications plus
efficace sans perdre la nature personnelle d'une conversation en tête à tête. Une communication plus
efficace mène au délai d'arrivée au marché réduit et la transformation agile des processus d'affaires
par la collaboration. [22]
b. Présentation de l’architecture de Cisco Unified Communications
Le Cisco Unified Communications constitue une solution de traitement d’appel pour les entreprises
évolutive, à haute disponibilité et qui peut opérer dans une architecture centralisée ou distribuée.
Plusieurs serveurs CallManager peuvent être formés en cluster et administrés comme une seule
entité. La construction d’un cluster contenant plusieurs serveurs de traitement d’appel sur un réseau
IP est une possibilité unique sur le marché, qui met en évidence la qualité avancée de l’architecture
proposée par Cisco. Le modèle en cluster permet une évolution de 1 à 30.000 téléphones IP pour
un cluster et permet le partage de charge entre serveurs et la redondance du service de traitement
d’appel.
Un Cluster de communication Manager est composé :
Publisher, utilisé pour administrer le Call Manager (config routeur, postes etc…)
Suscriber, utilisé pour les sauvegardes, conserver toutes les configurations.
Figure 3.01 : Architecture d’un cluster
50
Figure 3.02 : Exemple de mise en place de cluster [21]
3.2.2.2 Les composants de la solution Cisco Unified Communications Manager
La stratégie UC de Cisco entoure la voix, vidéo et les données circulant dans une infrastructure
simple de réseau. L'équipement de Cisco UC est capable de contrôler chacun des trois types du trafic
et de se connecter par interface à tous les protocoles de réseau standardisé.
Le Cisco IP Communications représente une nouvelle manière de fournir la fonctionnalité de Cisco
UC aux clients d'entreprise. Au lieu de livrer une collection de produits disjoints avec différentes
dates de dégagement, de méthodologie d' essai et de documentation, le Cisco UC est un dégagement
coordonné d'un ensemble intégré de produits qui sont examinés, documentés et soutenus comme
système.
La figure 3.03 illustre les quatre couches standard du modèle UC d’infrastructure de voix de Cisco
et les composants qui composent les couches. [22]
51
Figure 3.03: Les composants de la solution Cisco Unified Communications
Les composants de la couche standard sont composés de :
-Couche d'infrastructure:
L'infrastructure se compose de routeurs, des commutateurs, et des passerelles voix. La couche
d'infrastructure porte les données, la voix, et la vidéo entre tous les dispositifs de réseau et les
applications. Cette couche fournit également la disponibilité élevée, la gestion, la qualité du service
(QoS), et la sécurité de réseau.
- Couche de commande d'appel:
La couche de commande d'appel prévoit le traitement d'appel, la commande d'appareil et
l’administration du plan de numérotations et les caractéristiques.
La commande d'appel peut être fournie par un CUCM, CUCM Express ou CUCM Business Edition
(CMBE).
On se concentre sur le produit de CUCM qui est presque identique au Cisco Unified CMBE. Le
traitement d'appel est physiquement indépendant de la couche d'infrastructure. Par exemple, un
CUCM, Cisco Unified CMBE, ou CUCM Express à Ankatso peut traiter la commande d'appel pour
un dispositif physiquement situé à Vontovorona.
52
- Couche application:
Les applications sont indépendantes des fonctions de commande d’appel et de l'infrastructure
physique de processus voix. Des applications, y compris ceux énumérées ici, sont intégrées par IP
qui permet aux applications de résider n'importe où dans le réseau:
Voicemail, la transmission de messages intégrée et les applications unifiées de messages unifiés
sont fournies par Cisco Unity, Cisco Unity Express ou les produits Cisco Unity Connections.
Des centres de contact de diverses tailles peuvent être établis avec le Cisco Unified Contact Center
et Cisco Unified Contact Center Express.
Le Cisco Unified Meeting Place et Meeting Place Express sont les points à grande échelle pour les
serveurs de conférence qui supporte l’intégration des vidéos. Le produit Meeting Place intègre les
conférences de style lecture avec une collaboration de gamme et d’outils de contrôle. Cisco Unified
Meeting Place Express est utilisé dans les petites et moyennes entreprises. Meeting Place Express
est le successeur du serveur Cisco Conference Connection.
Le Cisco Emergency Responder (ER) augmente la fonctionnalité existante de secours offerte par
CUCM. Le Cisco ER fournit des mises à jour d'endroit physique pour les dispositifs mobiles pour
garantir que des appels d'urgence au point de réponse de sûreté publique (PSAP) sont correctement
conduits au PSAP responsable des appels d'urgence pour ce site. Le Cisco ER identifie l'endroit de
visiteur et trace tous les appels de cet endroit physique à un numéro d'identification de ligne de
secours (ELIN) par l'utilisation du numéro d'identification automatique standard (identification
d'ANI)/identification d’appelant (CLID). L'ELIN est inscrit au PSAP comme endroit de réponse de
secours (ERL). Déployer ces possibilités aide à assurer une conformité plus efficace aux
engagements légaux ou de normalisation en réduisant les risques de la vie et de responsabilité liés
aux appels d'urgence.
Le serveur Cisco Unified Presence rassemble des informations sur la disponibilité et les possibilités
de communications d'un utilisateur et fournit ces informations aux observateurs de l'utilisateur
comme l’indication de statut. L'information de statut inclut la disponibilité de dispositif des
communications de l'utilisateur. Par exemple, l'utilisateur pourrait être disponible par l'intermédiaire
du téléphone, de la vidéo, de la collaboration web ou de la vidéoconférence.
53
Les interfaces de protocole standard incluant le TAPI, le JTAPI, Q.SIG, H.323 et le SIP sont
disponible pour soutenir de le tiers-applications.
- Couche des terminaux:
La couche des terminaux apporte des applications à l'utilisateur, si le dispositif d'extrémité est un
téléphone IP Cisco, un PC utilisant un logiciel simulateur de téléphone appelé softphone, une
communication cliente ou terminal vidéo. Le Cisco UC fournit le support multiprotocole comme le
Skinny Client Control Protocol (SCCP), le H.323, le MGCP, et le SIP.
3.2.2.3 Le réseau de Cisco UC
Le système Cisco Unified Communications fournit des communications entièrement intégrées, la
voix convergente, la vidéo et des données au-dessus d'une infrastructure de réseau simple en utilisant
des protocoles basés standard. Le système Cisco UC fournit l'exécution et les possibilités inégalées
pour satisfaire les besoins courants et naissants des communications dans l'environnement
d'entreprise comme illustré par la topologie de réseau sur la figure 3.04. [22]
Figure 3.04 : Réseau de Cisco Unified Communications
54
La suite du produit Cisco UC est conçue pour optimiser la fonctionnalité, pour réduire des besoins
de configuration et d'entretien et pour fournir à l'interopérabilité d’une variété d'autres applications.
Elle fournit ces possibilités tout en maintenant la disponibilité élevée, le QoS et la sécurité.
Le système Cisco UC intègre les technologies principales de communications suivantes :
-La téléphonie sur IP: La téléphonie sur IP se rapporte à la technologie de transmission de voix à
travers un réseau en utilisant des normes IP. Le Cisco UC inclut une grande sélection de matériels
et de logiciels tels que les agents de processus d’appel, les téléphones IP, les systèmes de message
par voix, les dispositifs visuels, la conférence et beaucoup d'autres applications.
- Centre de contact de client: Les produits Cisco Unified Contact Center sont une combinaison de
la stratégie et de l'architecture pour révolutionner les environnements des centres d'appel. Le Cisco
Unified Contact Center favorise des communications efficaces et actives des clients à travers de
grands réseaux en permettant à des organisations de disposer d'une plus large gamme de ressources
pour entretenir les clients. Ces ressources incluent l'accès à un grand nombre d’agents, aux canaux
multiples de communication et aux outils de services clientèles.
- Téléphonie visuelle: Les produits Cisco Unified Video Advantage permettent les communications
visuelles en temps réel et la collaboration en utilisant le même réseau IP et l’appel d’agent que le
Cisco UC. Le Cisco Unified Video Advantage n'exige pas la formation spéciale de l’utilisateur.
L’appel vidéo avec le Cisco Unified Vidéo Advantage est aussi facile en composant un numéro de
téléphone.
- Communication de Riche-medias: Cisco Unified Meeting Place crée un environnement virtuel
de réunion avec un ensemble intégré d’équipements IP pour la voix, la vidéo et la conférence web.
-L’application Third-party: Cisco travaille avec les compagnies marginales pour fournir un plus
large choix pour les applications de communication sur IP de Third-party innovant et il produit les
besoins critiques d'affaires tels que la transmission de messages, le soin de client et l'optimisation
de main d'œuvre.
55
3.2.2.4 Les fonctions CUCM
CUCM développe des dispositifs et des fonctions des appareils de réseau de téléphonie sur paquet.
Ces dispositifs de réseau de téléphonie sur paquet incluent des téléphones IP Cisco, des dispositifs
médias, des passerelles de VoIP et des applications de multimédia. Les données additionnelles, la
voix et les services vidéos tels que les messages convergés, la conférence multimédia, les
collaborations des centres de contact et les systèmes de réponse de multimédia interactifs agissant
avec la solution de téléphonie sur IP par l'interface de programmation d'application de CUCM : API.
[22]
CUCM fournit ces fonctions:
-Traitement d'appel: Le traitement d'appel se rapporte au processus complet de lancer, de routage,
et de terminaison des appels y compris toutes les facturations et les processus de collection statique.
-Signalisation et commande d'appareil: CUCM a installé tous les connections de signalisation entre
les terminaux d'appel et les dispositifs directs tels que les téléphones, les passerelles et les ponts de
conférence pour établir et couper les connections en service. La signalisation se réfère également au
contrôle d'appel et le décrochage/ le raccrochage d’appel.
-Administration de plan d’appel: Le plan d’appel est un ensemble de listes configurables que
CUCM utilise pour améliorer l’acheminement des appels. CUCM est responsable de l'analyse de
nombre de tous les appels. CUCM permet à des utilisateurs de créer des plans d’appel.
-Administration de dispositifs de téléphone: CUCM prolonge des services tels que la prise, le
transfert, le renvoi, la conférence, appel rapide, renumérotation, parc d'appel et beaucoup d'autres
dispositifs pour les téléphones IP et des gateways.
-Services d'annuaire: CUCM emploie sa propre base de données pour stocker l'information sur les
utilisateurs. L'authentification d'utilisateur est effectuée localement ou contre un annuaire externe.
La synchronisation d'annuaire tient compte de la gestion d'utilisateurs centralisée. La
synchronisation d'annuaire permet au CUCM d’influencer les utilisateurs déjà administrés dans
l’annuaire de large corporation. Le Microsoft Active Directory (2000 et 2003), le Netscape 4.x,
iPlanet 5.1 et l’intégration de Sun ONE 5.2 sont supportés. La base de données locale de CUCM est
56
appelée Lightweight Directory Access Protocol (LDAP ; LDAPv3) dans le serveur de base de
données d'IBM Informix (IDS).
-Interface de programmation aux applications externes: CUCM fournit une interface de
programmation aux applications externes telles que le SoftPhone IP Cisco, Cisco IP Communicator,
le Cisco Unified IP Interactive Voice Response (IP IVR), le Cisco Personnal Assistant, le Cisco
Unified Personnal Communicator et le CUCM Attendant Console.
-Outils de sauvegarde et de restauration: CUCM fournit un système de rétablissement de désastre
ou Disaster Recovery System (DRS) pour sauvegarder et restaurer la configuration des bases de
données de CUCM. Le système DRS soutient également les registres de mouvement d'appel ou Call
Details Records (CDR), des registres de gestion d’appel ou Call Management Records (CMR) et les
CDR Analyse et Reportage de la base de données (CAR).
La figure ci-après montre les téléphones IP qui s'inscrivent logiquement à l’un des CUCMs dans le
cluster.
Les serveurs multiples de CUCM partagent une base de données et le téléphone maintient une
connexion active à la fois au serveur primaire et à la sauvegarde de CUCM. La figure montre les
raccordements logiques du TCP / IP du téléphone au serveur primaire.
Figure 3.05: Fonctionnement de CUCM
3.2.2.5 La signalisation de CUCM et les chemins médias
CUCM emploie le SIP ou le SCCP pour communiquer avec des téléphones IP Cisco pour l'émission
d'appel et le démontage et pour des tâches supplémentaires de service.
57
Après qu'un appel ait été installé, l'échange de médias se produit directement entre les téléphones
IP Cisco à travers le réseau IP en utilisant le protocole RTP pour la transmission radio. CUCM n'est
pas impliqué dans un appel après que l'appel ait été émis. Si le serveur de CUCM était débranché
pendant la durée de l'appel, les utilisateurs ne verront pas à moins qu'ils aient essayé d’utiliser les
touches du téléphone. CUCM est impliqué seulement dans l'émission d'appel, le décrochage et les
dispositifs. Si le serveur de CUCM, qui a émis un appel, a mal fonctionné et coupé pendant une
conversation, les utilisateurs verraient un message indiquant « CM Down, Features Disabled » (ou
« CM coupé, dispositif désactivé ») sur l'écran LCD du téléphone IP. [22]
3.2.2.6 Le matériel de CUCM, le logiciel et le Clustering
CUCM version 6.0 est une solution complète de matériels et de logiciels qui fonctionne comme
appareil de réseau. Un appareil de réseau est un système fermé qui soutient des applications qui
supportent seulement les Cisco certifiés. Les buts du modèle d'appareils sont : de simplifier
l'installation et la mise à niveau du système. Un modèle d’appareil permet à un administrateur
d’installer, d’implémenter et de contrôler un serveur de CUCM sans exiger la connaissance ou avoir
l’accès au système d'exploitation fondamental. [22]
a. Les dispositifs utilisés par CUCM
L'appareil de CUCM utilise les dispositifs suivants :
Solution complète de matériel et de logiciel : Les serveurs de CUCM sont préinstallés avec
tous les logiciels qui sont exigés pour actionner, maintenir, fixer et contrôler un serveur ou
un cluster des serveurs (sécurité y compris Cisco Security Agent).CUCM est également
fourni comme un produit de logiciel qui peut être installé sur un support Cisco Media
Convergence Servers (MCS) ou sur les plateformes de serveur third-party approuvé par
Cisco.
Le système d'exploitation d'appareils fournit la facilité de l'installation et de la mise à niveau,
tout en fournissant la sécurité et la fiabilité.
Vous pouvez améliorer les serveurs de CUCM tandis qu'ils continuent à traiter des appels.
L'administration de système est effectuée par l'intermédiaire de l'interface utilisateur
graphique (GUI), de l'interface de ligne de Commande (CLI) et a à travers documenté APIs
pour l’accès third-party.
58
CUCM soutient le groupement (clustering) des serveurs afin de partager la redondance et la
charge.
La redondance de base de données est fournie en partageant une base de données commune
à travers les serveurs multiples. La redondance de processus d’appel est réalisée par le
paramétrage du groupe de CallManager dans lequel des serveurs multiples sont assignés à
un dispositif pour les buts de fournir la tolérance de fautes. [22]
Un cluster de CUCM peut avoir y jusqu'à 20 serveurs. Seulement un serveur de Publisher est permis
dans un cluster. Le Publisher loge la copie lecture/écriture de la base de données. Jusqu'à huit
serveurs de Subscriber peuvent être dans le Cluster avec la restriction que seulement quatre des
serveurs de Subscriber peuvent effectuer le traitement d'appel actif. Si plus de quatre serveurs de
Subscriber sont utilisés dans un cluster, les serveurs additionnels sont les serveurs de secours
consacrés au cas où le serveur actif de Subscriber ne serait pas disponible. Les 11 autres serveurs
dans le cluster peuvent être responsables de divers services y compris TFTP et ressources de médias
(communication, musique sur la prise, transcodage).
Bien qu'il soit possible que CUCM s’exécute sur la plupart des ordinateurs, Cisco exige l’exécution
de CUCM seulement sur le matériel approuvé par Cisco. Par exemple pour supporter le CUCM 6.0,
les matériels doivent avoir les configurations suivantes
processeur 2-GHz
RAM de 2 GIGAOCTETS
disque dur 72-gb
Les conditions minimum pour CUCM 6 sont les mêmes que pour le Cisco Unified CallManager
version 5 mais seulement les modèles spécifiques de support de consoles multiples sont approuvés.
Les serveurs Cisco 7800 séries sont disponibles dans les variantes de -H ou de -I. -H représente
Hewlett-Packard, et -I représente des plateformes de serveur d'IBM. Le serveur 7825 est 19-inch ou
un serveur 23-inch en rack qui fournit un simple disque dure et une alimentation d'énergie. Le
serveur 7835 améliore la fiabilité et l'exécution en incluant les commandes chaud-permutables du
disque dure SCSI, le disque de duplexage RAID et les alimentations d'énergie superflues. Les 7845
améliorent la fiabilité et l’exécution en fournissant une deuxième CPU et un ventilateur de secours.
59
CUCM doit être installé sur un serveur qui répond à des normes de configuration de Cisco. Le Cisco
collabore activement avec deux fabricants de matériels pour répondre à cette exigence: Hewlett-
Packard (HP) et IBM. [22]
b. Le logiciel utilisés pour installer CUCM
Le système d'exploitation de CUCM est basé sur RedHat Linux. Le système d’exploitation et les
mis à jour des applications sont fournies par Cisco par les pièces rapportées qui sont digitalement
signées par Cisco. Le logiciel sans support et les applications (pas digitalement signées par Cisco)
ne peuvent pas être téléchargé ou installé sur le système.
L'accès de racine au système de fichiers n'est pas autorisé. Le système d'exploitation a été durci en
neutralisant tous les comptes et les services inutiles. Il n'y a également aucun accès aux interfaces
du système d'exploitation initial. Des traces, les alarmes et les compteurs d'exécution peuvent être
permis et surveillés par le CUCM-GUI. Quelques dossiers et annuaires sont accessibles par le Cisco
CLI et GUI pour des entretiens.
L'appui d'accès à distance permet aux ingénieurs en Cisco Technical Assistance Center (TAC)
d’accéder au serveur de CUCM pour un intervalle restreint de temps.
Les IBM IDS est la base de données pour les applications Cisco Unified Communications.
L'installation et la configuration de base de données d'IDS est inscrit dans le DVD d’installation de
CUCM. Aucun UNIX ou la connaissance de base de données d'identifications d'IBM est exigée pour
configurer et actionner CUCM.
L'agent bloqué de Cisco est inclus avec l'appareil pour assurer la protection contre des attaques
connus et d'inconnus. Le Cisco Secure Agent est un système géré par le système central
d'empêchement d'intrusion ou Host-Based Intrusion Prevention en anglais (HIPS).
Un serveur de DHCP est intégré dans CUCM pour fournir aux téléphones IP leurs conditions
d’adressage IP.
Le système d'exploitation de Cisco UC est également employé pour ces applications Cisco UC
Cisco Emergency Responder 2.0
Unity Connection 2.0
Cisco Unified Presence 6.0
60
c. Le Cluster de CUCM
Le cluster de CUCM (groupement de CUCM) permet au réseau de mesurer à plusieurs milliers de
terminaux. Il fournit la redondance en cas d'échec de réseau ou de serveur et fournit un point central
d'administration. Le schéma 3.07 montre une base de données de Publisher synchronisant des
composants de base de données à tous les autres serveurs dans le cluster. Les serveurs exécutant le
processus de CCM.exe effectuent le traitement d'appel et les autres serveurs prennent des rôles
spéciaux. Le groupement de CUCM crée la stabilité en isolant des processus à d'autres machines qui
augmente la performance. [22]
Figure 3.06: Cluster de CUCM
Les paramétrages des dispositifs sont stockés dans la base de données d'IBM IDS. La base de
données est le dépôt pour des paramètres de service, des dispositifs, des configurations de dispositif
et des configurations de plan de composition.
La base de données replie presque toute l'information de configuration dans une topologie hub-and-
spoke (un Publisher, quelques Subscribers). Les nœuds de CUCM emploient également une
deuxième méthode de communication pour replier des données d'exécution en utilisant une
topologie de maille. (Chaque nœud met à jour chaque autre nœud.).
Une topologie de maille du partage de l'information fournit l'enregistrement dynamique et les
informations actives d'appel qui changent beaucoup plus fréquemment que base de données. La
réplique en temps réel de maille est employée pour communiquer les nouveaux enregistrements de
téléphone, de passerelles and de processeur de signal digital ou Digital Signal Processor (DSP),
garantissant le cheminement optimum d'appel. [22]
61
Figure 3.07: Relation des bases de données CUCM
Chaque cluster de CUCM soutient un serveur Publisher simple et jusqu’à huit serveurs de
Subcribers. Ces serveurs fournissent la tonalité, recevant des chiffres, conduisant des appels et la
musique coulante sur la prise. Cependant, le serveur de Publisher accomplit typiquement et
seulement deux fonctions primaires : le maintien de la base de données et le service des demandes
de TFTP.
Puisque le serveur de Publisher possède un rôle si critique en maintenant la copie d’écriture de la
base de données de CUCM, il est habitué à garder tout le lourd travail. Les demandes de TFTP
viennent de téléphone IP Cisco pendant leur processus de démarrage.
N.B : Dans les plus petits environnements (500 téléphones IP ou moins), le serveur de Publisher
doit parfaitement être très bien employé pour le traitement d’appel et la gestion de base de données.
Cependant, une fois que vous excédez au numéro, il est dans généralement de meilleurs habitudes
de tirer le serveur Publisher hors du traitement d’appel et de basculer vers le serveur de Subscriber.
De même, une fois que vous excédez 1 250 utilisateurs, le Cisco recommande de déplacer le rôle de
serveur de TFTP à un serveur dédié.
3.2.2.7 La base de données de Cisco UC
Les données dans la base de données de CUCM sont divisées en deux types comme décrit dans les
sections qui suivent.
62
a. Données de Configuration statique
Des données de configuration statiques sont créées en tant qu'élément de la configuration du cluster
de CUCM. L'accès lecture/écriture à ces données est généré par le Publisher seul. Les Subscribers
fournissent seulement la lecture seule à ces données. Si le Publisher devient indisponible, les
données de Subscriber peuvent être utilisées pour émettre des appels mais elles ne peuvent pas être
modifiées. La réplique de base de données est unidirectionnelle du Publisher vers le Subscriber.
Seuls, les CDRs et les CMRs sont repliés des serveurs du Subscriber vers le Publisher. Toute autre
information de configuration est téléchargée de l'éditeur.
b. Les dispositifs d'User-Facing
Vous avez appris que le serveur Publisher est le seul serveur avec une copie lecture/écriture de la
base de données et tous les changements de configuration devraient être faits sur le Publisher. Ces
changements sont alors repliés en aval aux serveurs de Subscriber. Ce modèle représente un seul
point d'échec de la perspective des mouvements, d'ajout, et de changements (MAC). Le problème
est davantage exacerbant que le Publisher était le seul serveur dans le cluster responsable des
changements du renvoi d'appel, l’extension de la mobilité de l’utilisateur et l’indicateur d’attente
d’appel avant le CUCM 6.0.
CUCM 6.0 traite une partie de la base de données en tant que données dynamiques de configuration.
L'accès lecture/écriture aux données de configuration dynamiques est fourni sur tous les serveurs,
permettant à certaines informations d'être modifiées si le serveur d'éditeur est indisponible.
L'information dynamique qui peut être changée pendant une panne du Publisher est connue pendant
l’User-Facing Features (UFF). Des données UFF sont repliées des serveurs Subcribers où le
changement a été débuté pour tous autres serveurs Subscriber dans le cluster de CUCM.
Les exemples d'UFFs incluent :
Transfer de tous les appels ou Call Forward All (CFA)
Indication d’attente de message ou Message Waiting Indication (MWI)
Privé, Activé/Désactivé
Ne dérangez pas ou Do Not Disturb, Activé/Désactivé (DND)
Ouverture de mobilité de prolongation ou Extension Mobility Login (EM)
Hunt Group Login Status
63
Moniteur ou Monitor (Utilisation future)
Mobilité de dispositif
Statut de CTI CAPF (Computer Telephony Integration, Certificate Authority Proxy
Function).
Les services ont énuméré dans le tableau 1-1 comptent sur la disponibilité du serveur Publisher
indépendamment de la version utilisée de CUCM.
COMPOSANT FONCTION
CCM Admin Disposition de tout
CCM User Disposition des paramétrages des utilisateurs
BAT Disposition de toutes les initiations par le Bulk Administration
Tools
TAPS Disposition de toutes les initiations par le Tool for Auto-
Registered Phone Support
AXL Disposition de tout lancer par le service d’AVVID XML Layer
AXIS-SOAP Services d’activations et de désactivations par SOAP
CCM Installation de téléphones (auto-enregistrement seul)
LDAP Sync Mis à jour des informations sur l’utilisateur
License Audit Mis à jour des tables de licence
Tableau 3.01 : Services Requis par le serveur Publisher
3.2.2.8 Un exemple basique d’un appel effectué par les téléphones IP [22]
Prenant en compte la figure 3.06 illustrant un utilisateur au téléphone A plaçant un appel pour
téléphoner le B.
Au début d'un appel, un utilisateur au téléphone IP A prend le combiné et un message est envoyé à
CUCM faisant savoir que le dispositif est décroché. CUCM répond à ce stimulus en répondant avec
un message qui indique au dispositif d’effectuer une émission de tonalité qui est entreposé dans la
64
mémoire instantanée du téléphone. L'utilisateur au téléphone A entend la tonalité et commence à
composer le numéro de téléphone du téléphone B. SCCP envoient les chiffres à CUCM pendant
qu'ils sont composés (chiffre par le chiffre) tandis que les téléphones de SIP envoient ces chiffres
composés dans un message (en bloc signalant) par défaut. Les téléphones de SIP ont des options qui
leur permettent de se comporter pareillement aux téléphones de SCCP (Keypad Markup Language[
KPML ] et le cadran) de marge bénéficiaire de bloc de touches. CUCM exécute l'analyse de chiffre
contre les chiffres composés. Si le chiffre est trouvé, CUCM conduit l'appel par sa configuration. Si
CUCM ne trouve pas le chiffre, une tonalité de commande est à l’appelé.
Figure 3.08 : Chemins de signalisation et de médias de CUCM
CUCM signale la partie de l’appelé pour lancer le rappel, ainsi l'utilisateur au téléphone A entendra
la tonalité de rappel. CUCM signale également l'appel au téléphone de destination qui joue la
tonalité de ring down. Des informations additionnelles sont fournies aux téléphones pour indiquer
l’appel, le nom de l’appelé et son numéro (Téléphone A montrera le nom du dispositif de destination
et son numéro, et le téléphone B montrera le nom et le nombre de l’appelé.) Quand l'utilisateur au
téléphone B accepte l'appel, CUCM envoie un message aux dispositifs les faisant savoir
l'information du socket IPv4 (adresse IPv4 et numéro de port) dans laquelle ils devraient
communiquer pour la durée de l'appel. Le chemin de médias de RTP s'ouvre directement entre les
deux téléphones.
65
Les téléphones IP Cisco n'exigent aucune autre communication avec CUCM jusqu'à ce que l'un ou
l'autre téléphone appelle un dispositif tel que le transfert d'appel, conférence d'appel ou l’arrêt
d'appel.
3.2.2.9 Les logiciels de messagerie utilisés par CUCM
Plusieurs types de messagerie peuvent être utilisés sur le gestionnaire d’appel CallManager. [22]
- Cisco Unity Express est une messagerie vocale doublée d’un standard automatique pour les
entreprises de petite taille. Cisco Unity Express offre jusqu’à 100 boîtes vocales utilisateurs et
jusqu’à 25 boîtes vocales générales. Cisco Unity Express s’intègre aux routeurs d’accès Cisco sous
la forme d’une carte AIM ou d’un module réseau. Elle est la messagerie de choix pour CallManager
Express, permettant ainsi d’avoir un unique système pour le réseau, la gestion des appels et la
messagerie vocale. Elle fonctionne également avec CallManager.
- Cisco Unity apporte les fonctions de messagerie vocale aux entreprises de toute taille. Cisco Unity
est disponible avec la fonction messagerie vocale et messagerie unifiée. La version messagerie
unifiée permet aux utilisateurs Outlook ou Notes d'accéder et de gérer les messages et appels de
toute provenance, à tout moment, et ce quel que soit le type d'équipement ou de média. Ils peuvent
écouter leurs e-mails par téléphone, consulter des messages vocaux via Internet et rediriger des fax
vers un télécopieur local lorsqu'un serveur de fax est installé.
Une option serait également de faire suivre les fax directement du réseau RNIS vers la messagerie
unifiée utilisant les possibilités standard T37 des passerelles Cisco.
La configuration se fait par l’administrateur et/ou l’abonné via une interface navigateur http et
permet la mise en œuvre de :
fonctions de standard automatique (mise en œuvre possible en dehors des heures ouvrables)
d'interrogation à distance des boîtes aux lettres pour les utilisateurs concernés ;
de journaux parlés permettant l'émission de messages ;
boîtes aux lettres indépendantes ou partagées (jusqu’à 10 alias par boîte) ;
systèmes de protection des messages par mot de passe ;
procédures de rediffusion ;
procédures de sauvegarde, d’archivage et de destruction des messages.
66
Figure 3.09: Les applications utilisées par CUCM
3.2.3 Le logiciel de Fax sur IP avec Open Text Fax Server, Right Fax Edition
La télécopie sur IP (« Fax over IP », FoIP) se développe de plus en plus dans les entreprises de toutes
tailles cherchant à réduire leurs coûts et à consolider leurs ressources. À celles qui ont choisi la
solution FoIP, Open Text Fax Server offre un moteur de distribution de documents puissant, sécurisé
et éprouvé, grâce auquel elles pourront exploiter leur infrastructure IP de manière efficace, sûre et
rentable. [23]
3.2.3.1 Options de mise en œuvre d'une solution FOIP avec Open Text Fax Server
FOIP avec Open Text Fax Server Open Text Fax Server est une solution flexible, qui permet aux
entreprises de mettre en œuvre le protocole FOIP via des logiciels ou du matériel, selon leurs
besoins.
Solution logicielle T.38 : envoi de télécopies en temps réel sur Internet
Utilise le logiciel Dialogic® Brooktrout® SR 140
Pour les entreprises qui ont besoin d'une solution logicielle
Gain de temps et d'argent pour le matériel et sa maintenance
Solution avec carte de télécopie T.38 : envoi de télécopies en temps réel sur Internet
Utilise une carte Dialogic® Brooktrout® TR1034 T.38
Peut être utilisée à des fins de télécopie FoIP ou RTPC traditionnelle
Solution Doc Transport intégrée T.37 : mode différé
Envoyez des messages électroniques
67
3.2.3.2 Rôle du serveur de télécopie dans un environnement IP
Pour accroître les avantages de leur infrastructure IP, de plus en plus d'entreprises adoptent des
technologies IP complémentaires de type VoIP (Voice over IP) et FoIP.
Objectif : réduire leurs coûts, consolider leurs ressources, simplifier leurs opérations de gestion et
accélérer leur retour sur investissement. Le serveur de télécopie est l'un des composants essentiels
d'une solution FoIP réussie. L'application de serveur de télécopie basée sur le réseau constitue un
véritable moteur pour la distribution de documents électroniques dans l'entreprise. Elle se présente
comme un hub centralisé, pour un échange sécurisé et rentable de tout type de document.
Elle s'intègre à la messagerie, aux systèmes ERP et à d'autres applications d'entreprises vitales, ainsi
qu'à des périphériques multifonctions. Elle distribue les documents de manière sécurisée, efficace
et fiable via les réseaux IP et RTPC traditionnels, selon les besoins de la société.
Spécifications techniques
RightFax 9.4
Licences de canaux de télécopie : 2 à 120 ports
DialogicBrooktroutSR140 (pour les solutions logicielles)
Cartes DialogicBrooktroutTR1034 (compatibles IP)
Equipement réseau compatible (UIT T.38)
Figure 3.10: Serveur de télécopie et VoIP
68
3.2.3.3 Les principales fonctionnalités d'Open Text avec FoIP
FoIP logiciel ou matériel
L’Open Text avec FoIP permet l'utilisation de cartes IP TR1034 pour l'envoi de télécopies
via RTPC afin de garantir les investissements des entreprises ; celles-ci peuvent en effet
migrer vers un environnement IP sans acheter de nouvelle carte ou de nouveau logiciel.
Il permet aux entreprises investissant dans une infrastructure logicielle de tirer parti de cette
approche grâce à la solution SR140 d'Open Text Fax Server.
Intègre la technologie T.30 éprouvée
Incorpore le protocole de télécopie RTPC T.30 dans les paquets T.38 d'Open Text Fax
Server.
Utilise de nombreuses techniques pour maintenir la communication T.30 entre deux points
d'extrémité T.30 lors du passage via Internet.
Assure des communications de télécopie de bout en bout.
Architecture Doc Transport pour l'installation et la configuration
Fournit des outils de gestion performants et une architecture de transport robuste.
Facilite l'installation et la configuration des solutions de télécopie IP logicielles (SR140) et
matérielles (TR1034).
Architecture Doc Transport distante
Permet de paramétrer des méthodes de transport FoIP sur des nœuds distants pour une
intégration encore plus transparente au réseau IP.
Prend en charge la consolidation du réseau.
3.2.4 Les équipements clés d'une communication ToIP
3.2.4.1 Les terminaux téléphoniques IP
Un téléphone VoIP est un matériel dédié qui se connecte à un réseau de VoIP. Un téléphone VoIP
peut supporter un ou plusieurs protocoles de VoIP. Quelques fonctions intéressantes à prendre en
considération lors de l'achat d'un téléphone VoIP : [24]
69
bande passante réduite : support des codecs à haute compression (par exemple G.729,
Speex).
bonne interface d'administration : interface Web.
interface audio : sortie audio externe et support des kits main libre (pour la formation à
distance).
a. Les hardphones
Ce sont des postes téléphoniques totalement indépendants de l’équipement informatique de
l’utilisateur. Ils sont destinés à remplacer l’équipement de téléphonie classique existant et présentent
l’avantage de ne pas remettre en cause les mécanismes comportementaux d’un utilisateur par rapport
à son téléphone. Un poste du genre dispose d’un microswitch intégré lui permettant de partager la
connexion LAN avec le PC (PC connecté au téléphone ou téléphone connecté à la prise LAN). [24]
Le téléphone IP 7970G est le téléphone haut de gamme avec écran couleur pour les dirigeants
d’entreprise et leurs collaborateurs directs. Ce téléphone à la pointe de la technologie dispose d’un
écran couleur rétroéclairé haute résolution avec des fonctions tactiles qui permettent d’accéder
facilement aux informations et aux fonctionnalités. Il gère jusqu’à 8 lignes téléphoniques ou
combinaisons de lignes et d’accès direct aux fonctions de téléphonie grâce à ses huit boutons
programmables.
Figure 3.11: Téléphone IP7970G
Le téléphone IP 7960G est le téléphone idéal pour les dirigeants d’entreprise et leurs collaborateurs
directs. Le téléphone IP 7960Gpeut gérer six lignes téléphoniques grâce à ses six boutons
programmables et possède quatre touches de fonctionnalités interactives qui guident l’utilisateur au
sein des fonctionnalités téléphoniques sur l’écran LCD du téléphone. Les capacités graphiques de
l’écran permettent de présenter à l’utilisateur les informations des appels et lui offre un accès intuitif
aux fonctionnalités.
70
Figure 3.12: Téléphone IP 7960G
Le téléphone IP sans fil 7920 est la solution de mobilité idéale pour tous les collaborateurs d’une
entreprise, des dirigeants se déplaçant fréquemment au sein des bureaux aux employés se trouvant
dans les entrepôts. Son écran LCD permet d’accéder facilement à ses six lignes et au menu de
fonctionnalités téléphoniques. Le téléphone IP sans fil 7920 utilise le standard de réseau local sans
fil IEEE802.11b pour se connecter au réseau de l’entreprise.
Figure 3.13: Téléphone IP 7920
La station de conférence 7936 est la solution idéale pour les conférences téléphoniques au sein des
bureaux ou des salles de réunion. La station de conférence 7936 offre une qualité sonore
exceptionnelle éliminant les échos, les coupures et les réverbérations lors des communications pour
les rendre le plus naturel possible. Elle intègre trois microphones, permettant aux participants de
communiquer tout en se déplaçant dans la pièce.
Figure 3.14: Station de conférence 7936
71
b. Les softphones
Ce sont des applications permettant d’émuler un terminal téléphonique sur un PC (équipé d’un micro
et d’un écouteur). La réception d’un appel sur un softphone est conditionnée par l’ouverture du poste
informatique. Pour prendre ou composer un appel, l’utilisateur ne décroche plus de combiné mais
clique sur sa souris.
L’alimentation du terminal est un point sensible de l’architecture de la téléphonie sur IP. Alors que
les systèmes téléphoniques classiques sont systématiquement alimentés par les PABX (eux-mêmes
secourus par des batteries disposant de plusieurs heures d’autonomie), l’alimentation d’un terminal
IP peut se faire : Soit localement (le poste dispose d’une alimentation indépendante sur une prise de
230V) ; Soit à distance (dans ce cas, le poste téléphonique est télé-alimenté via l’infrastructure du
réseau local par le biais du commutateur selon la norme 802.3af ou par un équipement intermédiaire
appelé MID #177; SPAN situé entre le Switch et le panneau de câblage). [24]
Figure 3.15: Cisco Unified Personal Communicator
Le téléphone logiciel IP Communicator est une application bureautique de communication
extrêmement performante pour votre PC. Il peut gérer complètement la gamme des téléphones IP
Cisco ou peut fonctionner comme téléphone logiciel indépendant. Il est similaire au téléphone IP
7970G.
XLite :
Pour composer un numéro, il suffit de cliquer sur les chiffres du pavé numérique virtuel de
72
X-lite. On raccroche et on décroche avec les boutons respectivement Rouge à droite et Vert gauche.
On peut régler le volume d'entrée et de sortie avec les petits ronds à déplacer de haut en bas, situés
à gauche et à droite du pavé numérique.[4]
Il existe le bouton qui ajuste le volume. Le bouton HOLD lorsqu’on passe un appel sert à mette la
ligne en attente (pour utiliser l'autre en cas de double appel par exemple). RECORD permet
d'enregistrer la conversation (dans C:\Documents and Settings\<NOM>\Mes Documents\X-Lite).
Le bouton Answer sert à répondre automatiquement en cas d'appel (attention aux mauvaises
surprises!), et au contraire, DND (Do Not Disturb, ne pas déranger) permet de passer en statut
d'occupé pour envoyer les appels sur la messagerie (si elle existe) sur le serveur SIP.
Le bouton CONF (Conférence) permet de créer une mini conférence audio à 3 en mettant en relation
les deux lignes téléphoniques de votre softphone X-Lite, permettant ainsi le dialogue à 3.
Enfin, le bouton AC (Auto Conférence) permet de passer directement en mode conférence en cas
de double appel.
Voici son aperçu :
Figure 3.16: Logiciel de Softphone installé dans un ordinateur
3.2.4.2 Le gatekeeper
Il assume les fonctions de contrôle d’appels et de gestion des terminaux. Cet équipement détient
l’intelligence du réseau H.323 ou SIP et donne les fonctionnalités de téléphonie aux terminaux
distants. Physiquement, le gatekeeper est un serveur informatique localisé sur le même réseau que
les terminaux téléphoniques IP. Les principes de communication sont les suivants : [25]
Un utilisateur souhaitant communiquer avec un autre utilisateur lance une requête vers le
gatekeeper en composant le numéro de ce destinataire sur son terminal IP.
73
Le gatekeeper assure la correspondance entre le numéro de l’appelé et son adresse IP et vérifie par
une requête la disponibilité du terminal destinataire. Si cette disponibilité est admise, le gatekeeper
met en relation directe les deux terminaux en fournissant l’adresse IP du destinataire à l’appelant.
Dans le cas où le terminal destinataire ne se trouve pas dans le réseau local, le gatekeeper route
l’appel vers la Gateway pour accéder au terminal distant.
Lorsque l’appel est terminé, le gatekeeper met à jour ses tables pour rendre les postes
disponibles.
Ce principe décrit l’architecture de communication non centralisée mettant en relation directe les
interlocuteurs pendant toute la communication (flux voix). Les seules informations échangées avec
le gatekeeper sont des informations de signalisation qui permettent l’établissement et la libération
de l’appel. Un des apports fonctionnels important du gatekeeper dans l’administration des services
de téléphonie est sa capacité à se synchroniser avec l’annuaire du système d’information de
l’entreprise (Active directory, LDAP.).
3.2.4.3 La Voice Gateway
Une Voice Gateway est une passerelle permettant l’interconnexion entre un réseau à commutation
de circuits (RTC) et un réseau en mode paquet (de type réseau IP). Ainsi, elle assure la conversion
des communications classiques en IP et vice-versa. Elles permettent d’assurer l’acheminement :
Des appels sortants du réseau IP : cas d’un appelant disposant d’un téléphone IP mais souhaitant
contacter un destinataire utilisant un téléphone classique.
Des appels entrants dans le réseau IP : cas d’un appelant disposant d’un téléphone classique
mais souhaitant contacter un destinataire utilisant un téléphone IP. [25]
Les processus clés d’une Voice Gateway sont :
La translation de protocole (échanges d’informations de signalisation entre les deux
réseaux).
La conversion de formats d’informations (échanges de signaux audio décodés).
Le transfert d’informations.
74
Physiquement, les Voice Gateway sont des serveurs contenant des cartes d’interfaces numériques
(T0 ou T2) ou analogiques. Certaines d’entre elles peuvent être dédiées à la conversion de ligne
analogique/IP afin de permettre le raccordement des télécopieurs.
3.2.4.4 Les équipements de visioconférence
Figure 3.17 : Architecture générale d’un dispositif de visioconférence sous IP
3.2.4.5 Les équipements complémentaires
Outre ces fonctionnalités basiques, les systèmes de téléphonie sur IP savent proposer des fonctions
péritéléphonie à travers les équipements suivants : [25]
a. Plate-forme de supervision et d’administration
Serveurs de messagerie vocale
Standards téléphoniques
Serveurs de taxation
Serveurs d’enregistrement
75
b. Les adaptateurs FXO et FXS
Un adaptateur FXS (Foreign eXchange Subscriber) : c'est une interface qui sert à connecter une
ligne téléphonique analogique à un système ToIP. On les trouve sous forme d'un boitier équipé d'un
port Ethernet et d'un ou plusieurs ports analogiques.
Figure 3.18: Un adaptateur FXS
Un adaptateur FXO (Foreigne eXchange Office) se présente sous forme de boitier contenant un port
servant à connecter le PBX au réseau Internet. Ce type d'adaptateur est utilisé pour les entreprises
qui ont système téléphonique traditionnel.
Figure 3.19: Un adaptateur FXO cisco-small-business-spa9000
76
3.2.5 Représentation du site pris en compte
3.2.5.1 Plan du site pris en compte
Figure 3.20 : Plan du réseau IP de l’ESPA
3.2.5.2 Architecture d’un VoIP classique
Figure 3.21: Une architecture de VoIP classique
77
3.2.6 Architecture du réseau IP pris en compte
3.2.6.1 Les solutions « Full IP »
Ils se regroupent en deux grandes architectures à savoir : l’architecture de téléphonie sur IP locale
(inter-sites) et l’architecture de téléphonie sur IP distant (centrex IP). Pour notre réseau IP, on
effectuera une architecture de téléphonie sur IP inter-sites qui se présente comme suit :
Figure 3.22 : Architecture de téléphonie sur IP inter-site
78
Figure 3.23: Architecture de téléphonie sur IP inter-sites dans les branches du site
3.2.6.2 Les différentes branches du site
L’Ecole Supérieure Polytechnique de Vontovorona est un site très vaste. On peut distinguer
différents bâtiments qui sont destinés à l’Administration et des salles de classe ainsi qu’à des
bureaux de chaque département composant les branches d’étude à l’Université.
a. Bâtiments des administrations
Réellement, les bâtiments administratifs i-e les bâtiments où se situent les bureaux des
Administrations de l’Ecole sont les Bloc 30 et le Bloc 21. Ainsi, on a classé ces blocs comme les
BLOCS DES ADMINISTRATIONS pour leur occupation actuelle et pour ne pas trop saturer
l’installation des infrastructures.
On a prévu d’installer dans chaque bureau des Personnels administratifs 1 PC servant aux tâches
quotidiennes de ces derniers mais aussi pour pouvoir utiliser les softphones et de disposer des
diverses applications logicielles VoIP telles : la messagerie instantanée, les appels téléphoniques
79
vidéo. Il y aura aussi un téléphone IP pour chaque bureau. On installera aussi des imprimante-Fax
sur IP pour distribuer facilement les documents et les communiqués pour les Personnels.
On suppose que pour un bureau administratif, il aura un personnel classé comme le Directeur ou le
Chef et un personnel nommé Secrétaire pour faciliter la distribution des branches de connexion.
Alors, deux PC et 2 téléphones IP seront connectés visiblement au réseau IP à mettre en place.
Le projet prévoit le Bloc 21 où sont installés les bureaux des Chefs de département en sus des
bureaux actuels tels que le bureau du Service d’Administration Générale (SAG), le Service de
Direction des Relations Extérieures (SDRE).
Prenant conscience qu’il y a 11 principaux départements à l’Université donc le Bloc 21 constituera
13 bureaux dont 2 bureaux au rez-de-chaussée et les 11 bureaux à l’étage.
Dans ce bâtiment, on disposera de 26 PC, 26 téléphones IP, 13 imprimante-fax sur IP.
Alors que le bureau de la Scolarité qui se situe au rez-de-chaussée du bloc 30, comportera 3PC, 2
téléphones IP, 1 imprimante-fax sur IP.
Figure 3.24: Vue en perspective du Bloc 21
80
Figure 3.25: Façade du Bloc 21
Figure 3.26: Façade du Bloc 30 de la Scolarité
b. Les bâtiments de la Bibliothèque et de Bloc technique
Pour la Bibliothèque et le Bloc technique, on mettra en place pour chacun 3 PC, 2 téléphones IP
ainsi qu’une imprimante-fax sur IP pareil aux bureaux des administrations.
L’infrastructure basée sur la VoIP nous permet de disposer de toutes les fonctionnalités et les
applications en temps réel pour mieux communiquer. La technologie de la Visioconférence en fait
partie. La visioconférence qui est une technologie de haut point où des personnes peuvent parler et
discuter en temps réel sera mise en place dans ces bâtiments. Pour cela, une salle de conférence est
81
nécessaire d’être ménager dans chacun de ces bâtiments pour avoir plus de disponibilité lors des
réunions en visiophonie et en visioconférence des Personnels ou des soutenances en ligne
.
Figure 3.27 : Bibliothèque avec visioconférence: G
82
Figure 3.28: Bloc technique avec visioconférence
3.2.7 Conclusion
Dans ce chapitre, le Cisco Unified Communications Manager est présenté tel un logiciel gérant le
traitement d'appel au sein d'une solution Cisco Unified Communications. Elle permet à l'entreprise
d'étendre les services de téléphonie aux équipements réseaux comme les téléphones IP, les
passerelles VoIP ou encore les applications multimédia. Le CCM peut aussi gérer les conférences
multimédia, les boites vocales, les softphones, les logiciels de messagerie instantanée ou encore les
services SMS. Le CUCM est une solution très appréciée car elle fonctionne parfaitement avec les
équipements Cisco (téléphones, routeurs…) et propose de bonnes mesures de sécurité. Son
administration requiert une certaine maîtrise particulière. Pour l’implémentation de la
communication sur IP sur le site, il est nécessaire d’élaborer un cahier de charge pour dégager
l’inventaire des équipements nécessaire.
83
CHAPITRE 4
REALISATION D’UN RESEAU LOCAL GERE PAR CISCO UNIFIED
COMMUNICATIONS MANAGER
4.1 Les équipements mis en jeu
Pour réaliser le réseau local, il faut :
1 Virtual Machine VMWare
DVD d’installation Cisco Unified CallManager v7
2 IPphones
1 routeur
1 switch
4.1.1 Un routeur
La gamme Cisco 2800 se compose de quatre nouvelles plates-formes (voir la Figure 1) : les routeurs
Cisco 2801, Cisco 2811, Cisco 2821 et Cisco 2851.
Figure 4.01 : La gamme de Cisco 2800[26]
Cette gamme apporte une importante valeur ajoutée par rapport aux générations précédentes de
routeurs, et ce pour un prix équivalent. Les principales caractéristiques différenciatrices sont : la
multiplication par cinq des performances sécurité et multiplication par 10 performances téléphonie,
de nouvelles options de service intégrées augmentation considérable en terme de capacités et de
densité d’emplacements d’interfaces. [26]
84
Mais, le choix se tourne vers le Cisco 2811.
Figure 4.02 : Le routeur Cisco 2811 [26]
4.1.2 Un switch
La gamme Cisco Catalyst 3560 (Figure 1) est une ligne de commutateurs à configuration fixe, de
classe entreprise incluant des commutateurs Fast Ethernet et Gigabit Ethernet PoE (Power over
Ethernet) au standard 802.3af et pré-standard Cisco. Le Cisco Catalyst 3560 est un commutateur
d’accès idéal pour les réseaux locaux d’entreprise ou leurs succursales. Il permet des configurations
mixtes 10/100/1000 et PoE pour offrir un maximum de productivité et une protection des
investissements tout en permettant le déploiement de nouvelles applications telles que la téléphonie
IP, le réseau sans fil, la vidéo surveillance, les systèmes de gestion de bâtiment, et les kiosques de
vidéo à distance. [27]
Figure 4.03: Commutateurs Cisco Catalyst 3560 [27]
85
Le Cisco Catalyst 3560 à 8 ports suffira à notre réalisation.
Figure 4.05: Cisco Catalyst 3560 WS-C3650 8PC-S [27]
4.1.3 Les Téléphones IP
La gamme IP Cisco est un dispositif de communications normalisé. La gamme des téléphones IP
Cisco peut fonctionner avec des systèmes de téléphonie IP basés sur la technologie Cisco
CallManager, H.323, le protocole SIP (Session Initiated Protocol) et, à l’avenir, sur le protocole
MGCP (Media Gateway Control Protocol), avec des mises à jour logicielles initialisées par le
système. Cette capacité multiprotocole est d’abord une industrie. Elle offre une protection de
l’investissement et une fonction de migration. [28]
4.1.3.1 Le téléphone IP Cisco 7942G
Le Cisco 7942G (figure 4.06) est un téléphone IP complet à haut-parleur et combiné, conçu pour
offrir une qualité sonore large bande. Il répond aux besoins des professionnels dont l’activité
implique une forte utilisation du téléphone. Cet appareil est doté de deux boutons rétroéclairés
programmables, pour les lignes ou les fonctions, et de quatre touches programmables interactives
facilitant l’utilisation des fonctionnalités d’appel. Il est équipé d’un large écran LCD en niveaux
de gris 4 bits permettant d’afficher des données telles que la date et l’heure, le nom et le numéro
de l’appelant, le numéro composé ainsi que des informations de présence. L’excellente qualité
graphique de l’écran permet d’intégrer des applications avancées en langage XML (Extensible
Markup Language) et de prendre en charge des paramètres régionaux incluant des polices Unicode
codées sur deux octets. Le téléphone IP Cisco 7942G est équipé en standard d’un haut-parleur et
d’un combiné offrant une qualité sonore haute fidélité à large bande. Il inclut également un
86
connecteur pour casque d’écoute et un commutateur Ethernet. [29]
Figure 4.06: Téléphone IP Cisco 7942G [29]
Figure 4.07: Les fonctions des touches du Cisco 7942G
87
4.1.3.2 Un téléphone IP Cisco 7960G
Figure 4.08: Téléphone IP Cisco 7960G [29]
4.1.4 Vue en perspective du réseau local entrepris nommé « LAB »
Figure 4.09 : Réseau local installé
88
SWITCH>en SWITCH#conf t SWITCH(config)#hostname SWT_LAB SWT_LAB(config)# vlan10 SWT_LAB(config-vlan)# name Voice SWT_LAB(config)# vlan20
SWT_LAB(config-vlan)# name Data
SWT_LAB(config)# interface fa2/0/1 SWT_LAB(config-if)# description Vers routeur CME SWT_LAB(config-if)# switchport trunk encapsulation dot1q
SWT_LAB(config-if)# switchport mode trunk
SWT_LAB(config)# interface fa2/0/2 SWT_LAB(config-if)# switchport access vlan 20 SWT_LAB(config-if)# switchport mode access SWT_LAB(config-if)# switchport voice vlan 10
SWT_LAB(config-if)# spanning-tree portfast
4.1.4.1 Configuration du routeur et du switch Voici, les
configurations que devront être effectuées :
Figure 4.10: Schema Lab
Le Switch
D’abord, les commandes suivantes vont être utilisées pour créer un vlan pour la DATA
(données) et un autre pour la VOICE (voix)
Puis, la configuration des interfaces du switch sera la prochaine étape à faire.
Le mode trunk permet de faire une liaison entre le switch et le routeur.
La configuration de l’interface sur lequel sera connecté l’IP phone (à répéter sur chaque interface)
se fait comme suit :
89
SWT_LAB(config)# ip dhcp pool Voice SWT_LAB(dhcp-config)# network 10.10.10.0 255.255.255.0 SWT_LAB(dhcp-config)# default-router 10.10.10.1
SWT_LAB(dhcp-config)# option 150 ip 10.10.10.1 SWT_LAB(config)# ip dhcp pool Data SWT_LAB(dhcp-config)# network 10.10.20.0 255.255.255.0 SWT_LAB(dhcp-config)# default-router 10.10.20.1
Aprés cela, la creation des interfaces de Voix et Data est important :
On exclut les adresses hors du scope DHCP
:
La configuration du pool d’adresse pour le réseau voix et pour le réseau données poursuivra notre série de configurations.
Si le modèle de switch utilisé ne permet pas la configuration en serveur DHCP, il faut alors injecter
la configuration ci-dessus dans le routeur CCME (la configuration reste identique).
Le Routeur
Etape 1 : Configurons les interfaces du routeur et configurer le serveur NTP
C’est comme suit que se fait la configuration du serveur NTP
Lors de la configuration de l'heure exacte d'un routeur (ou commutateur), la première étape consiste à
configurer le fuseau horaire approprié. C'est la première étape parce que si vous définissez la première
fois et puis essayez de se mettre sur le fuseau horaire, vous devrez régler l'heure à nouveau. Il est
SWT_LAB(config)# ip dhcp excluded-address 10.10.10.1 10.10.10.5
SWT_LAB(config)# ip dhcp excluded-address 10.10.20.1 10.10.20.5
SWT_LAB(config)# interface vlan 10 SWT_LAB(config-if)# ip address 10.10.10.2 255.255.255.0
SWT_LAB(config)# interface vlan 20 SWT_LAB(config-if)# ip address 10.10.20.2 255.255.255.0
Router>en
Router#conf t
Router (config)#hostname CME_LAB
CME_LAB(config)# interface fa0/0.10
CME_LAB(config-if)# encapsulation dot1q
10
CME_LAB(config-if)# ip address 10.10.10.1 255.255.255.0
CME_LAB(config)# interface fa0/0.20
CME_LAB(config-if)# encapsulation dot1q 20
CME_LAB(config-if)# ip address 10.10.20.1
CME_LAB(config)# clock timezone GMT +3:
CME_LAB# clock set 23:58:31 21 Mar 2012
CME_LAB(config)# ntp master 2
90
CME_LAB(config)# telephony-service CME_LAB(config-telephony)# max-ephones 35 CME_LAB(config-telephony)# max-dn 50 CME_LAB(config-telephony)# ip source-address 10.10.10.1 CME_LAB(config-telephony)# cnf-file location flash:
nécessaire d’injecter le bon IOS et de charger les fichiers dans le routeur.
Commandes de troubleshooting
Etape 2: Extraction des fichiers dans le mémoire flash du routeur
Etape 3 : Chargement des fichiers dans le serveur TFTP
Etape 4 : Configuration du routeur en tant que CCME
Etape 5: Chargement des fichiers dans les IP phones
Etape 6: Générer le fichier de configuration
Commandes de troubleshooting
CME_LAB# archive tar /xtract tftp://@ du serveur / nom_du_fichier.tarflash:
CME_LAB# show telephony-service tftp-bindings
CME_LAB# Show ephone registered
CME_LAB# show clock
CME_LAB# show ip interface brief
CME_LAB(config)# tftp-server flash:/nom_du_fichier.bin CME_LAB(config)# tftp-server flash:/nom_du_fichier.loads CME_LAB(config)# tftp-server flash:/nom_du_fichier.sb2 CME_LAB(config)# tftp-server flash:/nom_du_fichier.xml
CME_LAB(config-telephony)# load 7935 P00503010100 CME_LAB(config-telephony)# load 7960-7940 P0030702T023 CME_LAB(config-telephony)# load 7914 S00104000100
CME_LAB(config-telephony)# load 7942
CME_LAB(config-telephony)# create cnf-files
91
CME_LAB(config)# ephone 1 CME_LAB(config-ephone)# mac-address ………………………. CME_LAB(config-ephone)# type 7942 CME_LAB(config-ephone)# button 1:1 CME_LAB(config-ephone)#exit CME_LAB(config)# ephone 2 CME_LAB(config-ephone)# mac-address ………………………. CME_LAB(config-ephone)# type 7960
CME_LAB(config-ephone)# button 1:2
Etape 7 : Création des numéros d’extension
name : Correspond le nom de l'agent propriétaire du téléphones
description : La description de l'agent (son poste dans l'entreprise ou le département)
label : Permet d'entrer le nom complet d'un utilisateur qui va prendre un
numéro quelconque
Etape 8:Création des ephones virtuels dans le CCME
Commandes de troubleshooting
4.1.5 Test de l’opérabilité du réseau par un appel entre les téléphones IP
Comme les numéros sont attribués pour chacun des téléphones, on peut maintenant effectuer des
appels entre le téléphone Cisco 7942G et le téléphone Cisco 7960G.
CME_LAB(config)# ephone-dn 1 dual-line CME_LAB(config-ephone-dn)# number 1001 CME_LAB(config-ephone-dn)# label nom – 1001 CME_LAB(config-ephone-dn)# description nom CME_LAB(config-ephone-dn)# name nom CME_LAB(config-ephone-dn)#exit CME_LAB(config)#ephone-dn 2 dual-line CME_LAB(config-ephone-dn)#number 1002 CME_LAB(config-ephone-dn)#label nom-1002 CME_LAB(config-ephone-dn)#description nom CME_LAB(config-ephone-dn)#name nom CME_LAB(config-ephone-dn)#exit CME_LAB(config)# telephony-service
CME_LAB(config-telephony)# system message Lab CCM
CME_LAB#show ephone registered
CME_LAB#debug ephone register
92
4.2 Conclusion
Ce dernier chapitre nous a permis d’effectuer une réalisation simple d’une communication sur IP
d’un réseau local. On a pu voir les différentes configurations indispensables pour les équipements
tels que le switch et le routeur. Le choix d’une réalisation partielle à l’aide d’un réseau local se
résigne à l’impossibilité de concevoir réellement le site tout entier. Mais la concrétisation de
l’implémentation de la VoIP sur le campus universitaire est tout à fait réalisable ceci dépend du
pouvoir et du financement disponible.
L’aboutissement de l’appel entre les softphones a démontré que le réseau marche convenablement
d’après les résultats attendus d’une réelle communication.
93
CONCLUSION GENERALE
La technologie rénovatrice a soutenu l’idée d’une entreprise totalement équipée d’une
communication basée sur IP. Le TCP/IP serait à l’origine du support des réseaux de cette
technologie dite la Voix sur IP (VoIP). Les entreprises ont besoin de réduire leurs coûts de
communication et d’avoir une très bonne qualité de service grâce aux solutions apportées par la
VoIP. De ce fait, on a tenté de dégager les besoins pour pouvoir implémenter la technologie de la
VoIP au sein de l’Ecole Supérieure Polytechnique d’Antananarivo.
D’abord, il est nécessaire d’avoir de nombreuses connaissances concernant les différents principes,
les modèles d’architecture et les protocoles opérant dans le modèle TCP/IP. Ce qui nous a amené à
faire une étude à ce propos dans le premier chapitre.
Ensuite, l’environnement de la VoIP a permis de connaître l’importance de cette solution avec ses
différents types de protocoles tels que les protocoles de signalisation (H323 et le SIP) et les
protocoles de transport (RTP et RTCP) et tant d’autres. Les autres communications sur IP telles que
la messagerie instantanée et le Fax sur IP (FoIP) ont été mis en exergue pour éclaircir leurs
caractéristiques et les protocoles qu’ils utilisent.
Par la suite, notre choix se porte sur l’utilisation de l’IPBX : Cisco Unified Communications
Manager choisi comme l’autocommutateur téléphonique privé effectuant la gestion des appels et
aussi des échanges de données dans une entreprise. Cet IPBX est totalement numérique apportant
beaucoup plus de fonctionnalités et de services à l’entreprise et il sera installé dans un routeur.
Quant au dernier chapitre, la réalisation d’un réseau local équipé totalement des équipements Cisco
a montré notre capacité à entreprendre et à configurer convenable les équipements mis en œuvre
dans cette communication sur IP. C’est un moyen d’appliquer les théories citées dans les chapitres
précédents.
Malheureusement, le coût de ce déploiement est onéreux à cause de l’enchérissement du logiciel de
gestion et des équipements CISCO actuels. De plus, les administrateurs de ce type de réseaux
doivent avoir beaucoup de connaissances mais surtout une maîtrise parfaite de l’ensemble de la
technologie et voire même des certifications délivrées par la Société CISCO pour pouvoir déployer
cette communication basée sur la VoIP en entreprise.
94
ANNEXES
ANNEXE 1 ETUDE COMPARATIVE DES IPBX
ASTERISK
CISCO UNIFIED
COMMUNICATIONS
MANAGER
ALCATEL Lucent
SYSTEME
D’EXPLOITATION
Linux Linux/BSD, Mac OS X,
Solaris
Linux
REPROTOCOLE ADSI;H.323
IAX/2 MGCP
SIP SCCP
SIP;H.323;IAX;MGCP
Q.SIG;CTI/QBE
SCCP
SIP
CODECS Ulaw G.711 =
ulawAlaw G.711 =
alaw G.723.1 = g723.1
G.726 = g726
G.729 = g729
GSM = GM/M
iLBC = ilbc
LPC10 = lpc10
Speex = speex
ADPCM = adcpm
-Codecs audio
PCM/G711
G723.;G729.a
iLBC and co
G722 and co
autre
-Codecs Vidéo
H261 ; H263 ;
H264 and co
H264 SVC
Autres…
Choix impose entre
G711
G729a
95
AVANTAGES
-Très puissant, Stable
Flexibilité,
-Autocommutateur
privé et complet
-Une interface web simple,
ergonomique et multi-
langues
- Une approche multi-
clusters
- Le gel de compte
- Le déménagement
d'utilisateurs
- Une solution souple pour interfacer avec les différents annuaires de l'entreprise
- Assurance d’une société reconnue
- Protocoles propriétaires
(SCCP…)
- Configuration aisée des
déploiements
- Approvisionnement aisé
d’utilisateurs, de téléphones,
de lignes et de
fonctionnalités
téléphoniques•
- Maintenance aisée du
système (sauvegardes et
restaurations simplifiées,
etc.)
Stabilité,
Qualité
Justifié
INCONVENIENTS
-Stabilité
-Qualité
-justifié
-Java Virtual Machine - SQL Server - License Cisco - Prix maintenance - Quasi impossible à utiliser avec d’autres téléphones que les Cisco - Prix serveurs (hp, dell…) « rebadgés » Cisco
-Un poste peut
changer
d’utilisateur mais
pas l’inverse
-Absence de
composants
redondants.
MISE A JOUR
-Facile suivant les
modules
-Pas de licence car
étant
complètement une
solution libre
- Maintenance aisée du
système (sauvegardes et
restaurations simplifiées,
etc.)
-Suivant les
fonctionnalités
désirées par l’ajout
de modules si
l’argent est
disponible
-Achat de license
96
MISE EN PLACE ET
ADMINISTRATION
-Un peu difficile car
nécessitant un
connaisseur du
domaine
-Administration aisé
car on peut y
implémenter ce qu’on
désire si l’on s’y
connait
Mise en place plus intuitive
-Pas trop aisé
-L’administration
est partagée car
l’administrateur n’a
pas accès à tout
COÛT
-Logiciel Open Source
-Faible selon les
équipements à acquérir
Solution payante
-Logiciel Open
Source
-Faible selon les
équipements à
acquérir
Tableau A1.01: Comparaison des solutions IPBX
ANNEXE 2
INSTALLATION DU CISCO UNIFIED CALLMANAGER v7 DANS LE ROUTEUR
On démarre la machine virtuelle.
Figure A2.01 : Affichage écran du chargement de la machine virtuelle
97
On lance une vérification du média pour éviter les erreurs lors de l’installation.
Figure A2.02 : Lancement de l’installation
Si tout est OK, on poursuit l’installation.
Figure A2.03 : Confirmation de l’installation
On conserve le choix par défaut ie CallManager. Le second choix permet d’installer Cisco Unity
(messagerie unifiée de Cisco).
Figure A2.04 : Choix du logiciel à installer
98
Acceptons l’installation par :« YES »
Figure A2.05 : Confirmation de l’installation du Cisco Unified CallManager
Utilisation de l’assistant d’installation.
Figure A2.06 : Installation par l’assistant
L’étape suivante est utile dans le cas d’une migration ou restauration de machine d’un cluster
CUCM.
99
Figure A2.07 : Mis à jour du logiciel CUCM installé (upgrade)
Figure A2.08 : Suite de la mise à jour du logiciel CUCM
Figure A2.09 : Installation complète du logiciel CUCM
100
Figure A2.10 : Configuration du temps selon de pays
Figure A2.11 : Relation entre ethernet NIC et duplex
Figure A2.12 : Changement de la taille du MTU dans l’OS par défaut
L’étape suivante nous permettrait de définir le CUCM en tant que serveur DHCP.
Cette méthode n’est pas conseillée par Cisco et très peu usité dans le domaine.
101
Alors, on clique sur « ‘NO »
Figure A2.13 : Utilisation du DHCP du routeur
A cette étape, on renseigne le nom DNS ainsi que les paramètres réseau de notre machine.
Name : CUCM<X>
IP Address :10.50.<X>.1
IP Mask : 255.255.255.0
GW Address : 10.50.<X>.254
Figure A2.14 : Configuration du réseau IP
102
Nous travaillons qu’en IP direct : « NO »
Figure A2.15 : Configuration du paramètre DNS dans le routeur
Configurez un login et un password d’administrateur tel que :
Figure A2.16 : Configuration de la plateforme d’administration
103
Entrez les informations concernant votre organisation.
Figure A2.17 : Configuration des informations sur l’organisation
Le routeur est attribué comme étant le Publisher donc on accepte par « YES ».
Figure A2.18 : Confirmation du routeur en tant que Publisher
104
Dans cette étape, on renseigne un serveur NTP de stratum inférieur à 6.
On peut utiliser un serveur NTP publique, comme par exemple celui de l’université de Strasbourg :
serveur de temps : ntp.u-strasbg.fr
adresse IP : 130.79.14.177
Dans notre cas, on va créer un NTP sur notre routeur.
Renseigner alors comme serveur NTP : 10.50. <X>.253
Figure A2.19 : Adressage du serveur NTP publique
Le mot de passe qu’il faut taper sert à l’intégration d’un nouvel hôte dans cluster.
Figure A2.20 : Configuration du mot de passe de la sécurité du système
105
Figure A2.21 : Configuration de l’hôte SMTP du routeur
Ce user et ce password dans la figure A2.22 servent pour les administrateurs du CUCM, mais
seulement en tant que administrateurs système, pas de l’OS.
Figure A2.22 : Entrée du nom de l’utilisateur et mot de passe
Figure A2.23 : Configuration complète de la plateforme
106
Figure A2.24 : Installation de la plateforme dans le routeur
107
BIBLIOGRAPHIE
[1] Pujolle G., « Les Réseaux », Eyrolles, Paris, 2008.
[2] Servin C., « Réseaux et Télécoms », Dunod, Paris, 2003.
[3] Archimbaud J.L., J.P. Gautier, « TCP/IP : Protocole de l’Internet », [email protected]., 2014
[4] Randriarijaona E.L., « Réseaux TCP/IP », Cours L3-TCO, Dép. TCO. –ESPA, AU/2012-2013
[5] Caleca C., Aysse L., « Les Réseaux », http://christian.caleca.free.fr/reseaux/., 2014
[6] Jacquenod F., « Normalisation des réseaux », Janvier 2008.
[7] "Le protocole IP"http://www.commentcamarche.net/.,2014
[8] « Entête TCP », http://www.frameip.com/, _SebF, Septembre 2003.
[9] « Entête UDP », http://www.frameip.com/,_SebF, Septembre 2003.
[10] « Mémoire Online - Audit et schémas d'évolution d'une plate - forme d'interconnexion de
sociétés multi-sites par ToIP - Achille DAVO »,"http://www.memoireonline.com/, 2014
[11] Bruno Xavier et Sark Frank, « La ToIP », Décembre 2004.
[12] « Sip/h323», www.chez.com/jaaayyy/html/ProjetSIP/SommaireSIP.html, 2014
[13] « Qu’est-ce que T38 »,"http://www.3cx.fr/T38.html, 2014
[14] « inter voip », http://perso.club-internet.fr/f_bailly/interface/inter_voip.htm, 2014
[15] « h323», http://cric.grenoble.cnrs.fr/utilisateurs/visio/h323/ , 2014
[16] « Sommaire SIP», www.chez.com/jaaayyy/html/ProjetSIP/, 2013
[17] _SebF, « Voix sur IP – VOIP », Novembre 2004.
[18] Andreasen F., Foster B., « MGCP Version 1.0», RFC 3435, Janvier 2003.
[19] Lassous I.G., « Voix et téléphonie sur IP », QoS et Multimédia SIR /RTS.,
2014
[20] « La voix sur IP : Les protocoles associés», http://www.guill.net/., 2014
[21] « Introduction au Cisco Call Manager 4.2 », http://www-igm.univ-mlv.fr/,2014
[22] CCNA, « Cisco UC Manager Architecture»,2014
108
[23] Open Text Corporation, « Fax sur IP avec Open Text Fax Server, RightFax Edition », 2009
[24] Cisco Systems, « GUIDE DES SOLUTIONS DE COMMUNICATIONS IP », 2005
[25] Jean-Marc CHARTRES, « LA TOIP », 16 octobre 2006
[26] Cisco Systems, « Routeurs à services intégrés de la gamme cisco 2800 »,2004
[27] Cisco Systems, «Commutateurs Cisco Catalyst 3560 », 2007
[28] Cisco Systems, « Téléphone IP Cisco 7942», 2007
[29] Cisco Systems, « Téléphone IP Cisco 7960 », 2000
109
FICHE DE RENSEIGNEMENT
Nom : RATOVONANTOANDRO
Prénoms: Sandy Mialisoa
Adresse : S35 Mandikanamana Alasora
Email : [email protected]
Titre du mémoire :
ETUDE D’UNE IMPLEMENTATION ET GESTION DE LA VOIP PAR
« CISCO UNIFIED CALLMANAGER »
Nombre de pages : 108
Nombre de tableaux : 9
Nombre de figures : 88
Directeur de mémoire :
Nom : RAVONIMANANTSOA
Prénoms : Ndaohialy Manda-Vy
Téléphone : +261 33 12 358 00
Email : [email protected]
RESUME
La communication sur la VoIP est une technologie expansive et rénovatrice actuellement. La plupart
des universités et des entreprises voit en celle-ci une source bénéfique selon leurs besoins. Le
système Cisco Unified Communications Manager est un logiciel composé de produits et
d’applications de communication voix et IP qui leur permettront de communiquer plus efficacement
et de simplifier ses processus métiers, de contacter les personnes compétentes à la première tentative
et d’améliorer son chiffre d’affaires et ses bénéfices.
Cet ouvrage tente d’extraire les différentes des protocoles utilisés ainsi que les facettes de ce logiciel
dont le but de pouvoir implémenter la VoIP sur un site.
Mots clés: CUCM, Voix sur IP, Téléphone sur IP, Session Initial Protocol, H.323
ABSTRACT
The communication on VoIP is currently an expansive and renovating technology. The majority of
the universities and the companies see in this one a beneficial source according to their needs.
System Cisco Unified Communications Manager is a software made up of products and applications
of communication voice and IP which will enable them to communicate more effectively and to
simplify its processes trades, to contact the qualified people with the first attempt and to improve its
sales turnover and its benefit.
This work tries to extract the different ones from the protocols used as well as the facets from this
software of which the goal to be able to implement VoIP on a site.
Keys words: CUCM, Voice over IP, Telephone over IP, Session Initial Protocol, H323
![[VoIP] Cisco CallManager Basics (VoIP)](https://img.dokumen.tips/doc/110x75/55cf99c3550346d0339f0d92/voip-cisco-callmanager-basics-voip.jpg)
