UNIVERSITE HENRI POINCARE Xavier AMEZIANE

NANCY I Sébastien LEVEQUE

Lionel ZEINER
Ecole Supérieure d’Informatique et
Applications de Lorraine ESIAL Troisième année
Année universitaire 2002 – 2003

PROJET RESEAUX
Voice over Internet Protocol
 Sommaire

Introduction 2

1. Idée 3
2.Le but : une réduction des coûts attendus 3
3. La voix 3
4. Difficultés associées à la transmission de la voix sur IP 4
4.1 Comparaison IP - Télécoms 4
4.2 Le transfert de la voix : un chemin semé d’embûches 5
4.2.1 Analyse des délais 5
4.2.2 Analyse des pertes 7
4.2.3 Conclusions 7
5. Principe de fonctionnement 7
6. Les protocoles 8
6.1 Le protocole H.323 8
6.2 Le protocole SIP 9
6.2.1 Les fonctionnalités utilisées par SIP 10
6.2.2 Les composants de SIP 10
6.2.3 Utilisation de SIP 11
6.2.4 Les protocoles utilisés 11
6.2.5 Les messages SIP 12
6.2.6 Exemples de transactions 17
6.2.7 Conclusions 19
6.3 Le protocole MGCP 20
6.3.1 Généralités 20
6.3.2 Fonctionnement de MGCP 21
7. Matériels nécessaires à la mise en place de la VoIP 27
7.1 Introduction 27
7.2 Approche centralisée contre approche distribuée 27
7.3 Exemple de matériel proposé par le constructeur Cisco 28
7.4 Détail des matériels Cisco à utiliser 30
Conclusion 37

1
 Introduction
Avec plus de 100 millions d'utilisateurs au niveau mondial, Internet représente à
l'évidence un phénomène en forte croissance (exponentielle depuis plusieurs années) dans le
domaine des nouveaux moyens de communication.
Bien que l’Internet se développe rapidement, le téléphone reste encore le favori du
public en matière de communication. Plus convivial car le contact est presque réel, il reste en
plus simple d'utilisation. Pourtant, il fusionne de plus en plus avec le matériel informatique.
Les utilisateurs du téléphone ont depuis toujours été habitués à payer leurs
communications en fonction de la distance et de la durée de celles-ci, mais depuis l'émergence
et l'extraordinaire développement de l'Internet, les mentalités changent et on s'habitue au
principe de réseau informatique et de son accès forfaitaire. On peut ainsi communiquer, par
écran interposé, n'importe où dans le monde sans aucune considération financière puisque le
prix est toujours celui d'une communication locale. C'est évidemment cet aspect financier qui
est à l'origine de la téléphonie sur IP. Car c'est une révolution au niveau des tarifs qui
s'annoncent démesurément bas.

2
 1. Idée
Voice over IP : voix sur IP. Transport de la voix sur des réseaux de données IP. La
voix est numérisée, enfermée dans des paquets de données, puis transmise sur le réseau.
Confondue parfois avec la téléphonie sur IP (ToIP : telephony on IP), terme désignant une
architecture tout-IP et ses services de téléphonie associés.
L'enjeu de la voix sur IP est de taille : téléphoner en utilisant les réseaux de données
traditionnels. À la clé, une convergence voix-données-images autour d'un protocole unique
(IP), une réduction des coûts et la centralisation des infrastructures dans un unique réseau.
Pour le grand public, la téléphonie sur IP désigne avant tout les logiciels ou les offres
permettant de coder la voix sur un réseau IP public. Avec évidemment une qualité et une
sécurité minimales. Dans le monde de l'entreprise, qualité de service oblige, la VoIP ne se
conçoit aujourd'hui que dans le cadre d'un réseau privé, WAN (Wide Area Network) ou LAN
(Local Area Network).

2. Le but : une réduction des coûts attendue

Premier bénéfice attendu de la VoIP : l'allégement des factures téléphoniques intra-
entreprises, voire entreprises- fournisseurs-clients dans le cas de réseaux étendus. Imaginons,
par exemple, la société Durand disposant de deux sites de production, l'un à Paris, l'autre à
Lyon. Pour tout ce qui concerne le transfert de données informatiques, les deux entités sont
reliées par une ligne spécialisée. Pour les communications téléphoniques, chacune dispose
d'une infrastructure télécoms traditionnelle construite autour d'un PBX (autocommutateur
téléphonique interne). Lorsqu'un salarié parisien téléphone à l'un de ses collègues lyonnais,
l'appel transite par le PBX avant d'être acheminé jusqu'à Lyon par le réseau téléphonique
traditionnel ou RTC (réseau téléphonique commuté). Comment la société Durand peut-elle
passer à la VoIP ? En reliant directement, dans un premier temps, ses deux PBX par la ligne
spécialisée. Le signal de voix analogique est alors compressé et codé pour être inséré dans des
paquets IP, transmis sur le lien, puis décodé et décompressé à l'autre extrémité. Mais
l'entreprise Durand peut aller plus loin. Elle peut faire le choix du tout-IP et miser sur la
téléphonie sur IP. Elle pourra alors remplacer ses anciens combinés téléphoniques par des
terminaux IP (téléphones IP ou PC équipés d'un logiciel de téléphonie). Cet exemple se place
dans un contexte de WAN ou de réseau étendu. Reste qu'avec la chute actuelle des tarifs
téléphoniques, un changement d'architecture n'est pas toujours facile à justifier. Certains
défendent néanmoins que la téléphonie sur IP est déjà rentable au niveau d'un LAN ou réseau
local. Ici, le surcoût de la téléphonie classique est à mettre au compte du déplacement fréquent
des téléphones (déménagements, aménagements de nouveaux bureaux...) et à la gestion du
câblage. Avec la téléphonie sur IP, ce souci disparaît car les terminaux, dotés chacun d'une
adresse IP, peuvent être connectés instantanément à n'importe quel endroit du réseau.

3. La voix
Le système vocal est complexe et basé sur des ondes sonores de fréquences
différentes. Le spectre des fréquences perçues par l’oreille humaine s’étale de 100 Hz à 20
kHz. Cette fourchette est, cependant, à réduire si l’on veut distinguer les fréquences utiles des
fréquences audibles. En effet, la quasi-totalité d’un message sonore est compréhensible dans

3
la fourchette 300-3400 Hz. Cette dernière correspond, d’ailleurs, à celle utilisée par le
téléphone standard.
Une conversation entre deux personnes respecte deux principes : intelligibilité et
interactivité. Couper la parole à quelqu’un ne se fait pas, mais c’est un gage d’interactivité et
de dialogue. En terme de transmission numérique, cela se traduit par le terme duplex. Une
conversation full duplex assure cette interactivité car chaque locuteur peut parler en même
temps, ce qui arrive quand deux personnes parlent de leur propre expérience sans s’écouter...
Un mode half duplex induit une conversation unidirectionnelle du style CB (Citizen Band) :
« quel est ton QRZ, à toi ! je viens de Moselle, à toi ! »
Cette interactivité implique des notions de délais dans le transport de la voix (avec le
téléphone, par exemple). Les mesures effectuées montrent qu’un temps de transit inférieur à
150 ms garantit un dialogue actif. Jusqu’à 400 ms (limite supérieure) le dialogue reste tout de
même assez réactif. Au-delà de cette limite le contradicteur aura l’impression de parler dans le
vide.

4. Difficultés associées à la transmission de la voix sur IP

Afin de bien percevoir les difficultés associées au transport de la voix sur IP, un
comparatif entre la commutation de circuits des télécoms et la commutation de paquets d’IP
est nécessaire. Ensuite, une étude des différents délais associés à VoIP permettra de
comprendre les facteurs incompressibles négatifs pour la communication.

4.1 Comparaison IP – Télécoms

Les deux approches IP et télécoms sont pratiquement opposées. Où IP est simple et

débrouillard, les télécoms sont complexes et figés. Le réseau qui est utilisé par les télécoms
est le réseau X25. Le tableau suivant établi la comparaison entre ces deux systèmes sur
différents points :

4
 4.2 Le transfert de la voix : un chemin semé d’embûches

Le tableau précédent fait un état des lieux des différences entre IP et X25. Il est
cependant nécessaire d'expliquer comment arrivent ses défauts de transmission. Voici
pourquoi cette partie répertorie les trois principales caus es des difficultés et des limites
associées à VoIP :
• Délai : temps de transmission d'un paquet (doit rester inférieur à 400ms pour respecter
les contraintes d'une conversation interactive).
• Gigue : variation de délai (nécessite un buffer de resynchronisation en bout de
chemin).
• Perte : disparition de paquets au cours de la communication (fait partie de la
transmission IP mais doit être soit réduite, soit inhibée).

Le schéma ci-dessus reprend les difficultés évoquées et permet de comprendre quels

sont les effets indésirables impliqués.

4.2.1 Analyse des délais

Quantifier le délai de transmission sur le réseau de manière fiable est quasi impossible,
car il y a trop d'inconnues : Table de routage, congestion, pannes, files d'attente… Cependant
sur le chemin que prendrait une transmission de voix, on peut détailler certains délais
inhérents au réseau :

5
Délais de l'émetteur :

• Numérisation et codage : temps mis par une carte son ou une passerelle pour
numériser et coder un signal initialement analogique.
• Compression qui se décompose en trois parties :
o Délai de trame : contrairement à la numérisation d'un signal qui se fait en
continue, la compression porte sur une certaine longueur de données. Attendre
ces informations induit un temps non nul de traitement
o Délai d'encodage : la compression par synthèse s'appuyant sur la prédiction, ce
délai est nécessaire à l'encodeur pour savoir, pendant qu'il est en
fonctionnement comment évolue le signal.
o Délai de traitement : temps mis par l'algorithme pour compresser une trame. Il
dépend du processeur et de l'algorithme utilisé.
• Mise en paquets : intervalle de temps pendant lequel l'application constitue un paquet
(création de l'en-tête, remplissage des données).
• Transmission : ce temps dépend de la configuration dans laquelle on se trouve. A
savoir soit on est relié par modem soit par accès direct sur un LAN-WAN.

Délais réseau :

• Propagation : sur un réseau filaire, la vitesse de propagation est de 200000 km/s, cela
induit un temps de propagation non nul.1111111111111111111111111111111111111
- Commutation et files d'attente : suivant la nature du réseau différents temps peuvent
être indexés.

Délais du récepteur (ce sont les mêmes que pour l'émetteur) :

• Réception.
• Buffer de gigue : cette mémoire tampon permet de resynchroniser les paquets arrivant
avec des délais variables. Elle sert donc à compenser les décalages et remettre en ordre
les paquets.
• Dépaquetisation.
• Décompression.

6
 • Décodage et conversion numérique analogique.

Jusqu'à présent les mesures effectuées avec une solution téléphone à téléphone (via
IP), sur un réseau bien géré et surdimensionné (en bande passante), montrent un délai total de
200 ms.

4.2.2 Analyse des pertes

La perte d'un paquet occasionne un manque d'information lors de la réception du

signal audio. Suivant le nombre de paquets perdus, la qualité sonore en bout de ligne peut s'en
ressentir. Dans la philosophie IP, cette perte de paquet fait partie intégrante du concept. En
effet les routeurs sont obligés (avec l'algorithme Random Early Detection) de détruire des
paquets afin d'anticiper d'éventuelles congestions.

Il existe principalement quatre causes de perte de paquet :

• Durée de vie épuisée (TTL = 0).
• Retard à la réception supérieur au buffer de gigue.
• Destruction par un module congestionné.
• Invalidité du paquet due à des défauts de transmission.

4.2.3 Conclusions

Toutes ces contraintes et défauts inhérents à IP sont les fondements des difficultés
rencontrées par le concept VoIP.

5. Principe de fonctionnement
Tout projet de VoIP ou de téléphonie sur IP nécessite une transformation du PBX de
l'entreprise. Une première solution consiste à y insérer une carte IP faisant office de passerelle
entre le réseau téléphonique et le réseau IP. Cette démarche présente l'avantage de préserver
l'existant et les postes analogiques. Seconde possibilité : remplacer le PBX par un IPBX, un
matériel profilé pour le tout-IP et qui implique un déploiement massif de terminaux IP. Ces
deux solutions techniques intègrent différentes fonctions de base, dont une unité de contrôle
d'accès (gatekeeper), qui gère l'identification des appels, la traduction du numéro de téléphone
en adresse IP, et éventuellement la définition des règles d'appel. Viennent ensuite une
passerelle (gateway), chargée de l'interconnexion entre équipements réseaux hétérogènes
(téléphone analogique ou numérique, carte RNIS...), et enfin une unité de contrôle (MCU
Multipoint Controller Unit) gérant les sessions multicast. Aujourd'hui, l'un des freins de la
téléphonie sur IP réside dans l'absence de standards communs à tous les constructeurs. Même
s'il constitue souvent une base commune, le protocole de signalisation H.323 (issu d'une
recommandation de l' International Telecommunication Union - Telecommunication
standardization (ITU-T)) est rarement utilisé tel quel. Plus simple, SIP (proposé par Internet
Engineering Task Force (IETF)) est encore peu adopté par les constructeurs de matériels.
Enfin, MGCP (Media Gateway Control Protocol), autre standard de l'IETF, peine aussi à
s'imposer. Une fois la communication établie, le transport et le contrôle des flux de données
sont assurés par deux autres protocoles : RTP (Realtime Transport Protocol) et RTCP
(Realtime Transport Control Protocol). Le premier permet de reconstituer la base de temps, de
détecter les pertes et d'identifier le contenu des paquets pour leur transmission sécurisée. Le

7
second, RTCP fournit, entre autres, des informations sur la qualité de la session. Lorsque les
paquets de voix transitent sur le réseau, les paramètres à maîtriser sont la latence (délai de
transmission), la gigue (variation du délai de transmission), la perte des paquets (au-delà de
20 %, le signal n'est plus audible). Pour s'en assurer, les différents équipements du réseau
(postes clients, routeurs...) doivent être dotés de dispositifs de QoS (qualité de service). La
priorité est ainsi donnée aux paquets de voix. Sur Internet, l'hétérogénéité des matériels réseau
impliqués empêche toute maîtrise de la qualité de transmission. C'est la raison pour laquelle il
est aujourd'hui impossible de mettre en place de la voix sur IP sur Internet avec un niveau
d'exigence acceptable pour une entreprise.

6. Les protocoles
Ainsi, nous pouvons conclure qu’il existe trois principaux protocoles utilisés pour la
voix sur IP :
• Le protocole H.323 (de l’ITU-T)
• Le protocole SIP (de l’IETF)
• Le protocole MGCP (de l’IETF)

6.1Le protocole H.323

H.323 (« Visual Telephone Systems and Equipment for Local Area Networks which
Provide a Non-Guaranteed Quality of Service ») : le standard H.323 fournit les services pour
le transfert de l’audio, de la vidéo ou de données à travers des réseaux IP. En se référant à ce
standard, les produits de constructeurs différents sont censés interopérer, sans souci de
compatibilité.
H.323 est un ensemble de recommandations venant le ITU-T, qui définissent des
standards pour le transport de données multimédia sur des réseaux locaux qui ne fournissent
pas une qualité de service garantie.
La première version a été approuvée en 1996 par le Study Group 16 de l’ITU-T, la version 2
l’ayant été en janvier 1998. Ce standard a une étendue très large, incluant à la fois des stations
de visio conférence que des PC multimédia, en mode point à point ou en mode multi points.
H.323 définit également le contrôle des appels, la gestion de la bande passante, les interfaces
entre le(s) LAN(s) et les autres réseaux.
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 de visio confé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 visio conférences en
multi points.

Concernant le support de la voix, H.323 supporte 5 algorithmes : G.711 ( obligatoire ),

G.722, G.728, G.723.1 et G.729, G.723.1 ayant été choisi comme celui par défaut pour les
applications de téléphonie dans le monde Internet.
H.323 fait partie d’une série plus large de standards de communication qui permettent la
visioconférence à travers un ensemble de réseaux. Connus sous le terme générique, H.32x,
cette série inclut notamment H.320 et H.324, qui adressent les communications dans le monde
ISDN d’une part, et pour les réseaux RTCs d’autre part.

8
Schéma de la pile protocolaire H.323 :

Architecture globale d’H.323 :

6.2 Le protocole SIP

Cette partie se concentre sur le protocole d’ouverture de session (SIP), qui est un
protocole récent publié par l’I.E.T.F. (Internet Engineering Task Force) sous la RFC (Request
For Comments) 2543 en mars 1999. La RFC 2543 présente la source d’information la plus
complète sur le sujet.

Selon la RFC 2543, le protocole d’initiation de session (SIP) est un protocole de

signalisation appartenant à la couche application du modèle OSI. Son rôle est d’ouvrir,
modifier et libérer les sessions ou appels ouverts entre un ou plusieurs utilisateurs. Pour ouvrir
une session, l’utilisateur émet une invitation transportant un descripteur de session permettant
aux utilisateurs souhaitant communiquer de s’accorder sur la compatibilité de leur média. SIP

9
peut relier des stations mobiles en transmettant ou redirigeant les requêtes vers la position
courante de la station appelée.

6.2.1 Les fonctions utilisées par SIP

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

6.2.2 Les composants de SIP

Comme HTTP, SIP propose l’établissement, la modification et la clôture de sessions

en mode client / serve ur, c’est à dire l’échange de requêtes coté client et réponse coté serveur.

Exemple :

User Agent User Agent

SIP Serveur SIP SIP
A B
1 INVITE 2 INVITE

4 OK 3 OK

6 ACK
5 ACK

Dans un système SIP on trouve deux composantes, les users agents (U.A.S et U.A.C)
et un réseau de serveurs.
• l’U.A.S (User Agent Server) : représente l’agent de la partie appelée, c’est une
application de type serveur qui contacte l’utilisateur lorsqu’une requête SIP est reçue.
Et elle renvoie une réponse au nom de l’utilisateur
• l’U.A.C (User Agent Client) : représente l’agent de la partie appelante, c’est une
application de type client qui initie 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

10
 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 RG (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.

6.2.3 Utilisation de SIP

L’ouverture d’une session à l’aide du protocole SIP peut s’effectuer de façon directe
entre deux User Agents qui jouent le rôle de client et de 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) 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

6.2.4 Les protocoles utilisés

L’architecture en couches de SIP, telle que la présente le modèle OSI, incorpore les
protocoles : RTP, RSVP, RTCP, SAP et SDP.

SDP Media

RTSP SIP RTCP RTP RSVP

TCP UDP

IPV4,IPV6

• 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

11
 • 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 mutimedia
ouvertes
• S.D.P.(Session Description Protocol) est un protocole de description des sessions
multimédia

Exemple de SDP pour la téléphonie sur internet :

6.2.5 Les messages SIP

Contrairement au protocole HTTP, qui est basé sur TCP, SIP utilise UDP pour les
applications multimédia. Pour transporter plusieurs transactions à la fois, SIP peut utiliser une
simple connexion TCP(mode flux) ou des datagrammes UDP(mode bloc). Seulement,les
datagrammes UDP, tout en-têtes compris, ne doivent pas excéder une certaine
longueur(M.T.U. pour Maximum Transmission Unit). Si la MTU est inconnue, elle est de
1500 octets par défaut. Cette taille permet l’encapsulation des datagrammes UDP ou segments
TCP dans des paquets IP sans fragmentation.
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 :

Ligne de requête ou ligne d’état

Entête de requête ou de réponse
CRLF : Balise indiquant le début de corps du message
Corps du message

6.2.5.1 Les requêtes et les réponses SIP

Ø Les requêtes SIP

Les méthodes utilisées dans une requête SIP sont :

12
 • INVITE : indique que l’application ou 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).
• 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é.

Ø Les réponses SIP

Une réponse à une requête est caractérisée, par un code et un motif , appelés code
d’état et reason phrase respectivement. Un code d’état est un entier codé sur 3 bits indiquant
un résultat à l’issue de la réception d’une requête. Ce résultat est précisé par une phrase, text-
based (UTF-8), expliquant le motif du refus ou de l’acceptation de la requête. Le code d’état
est donc destiné à l’automate gérant l’établissement des sessions SIP et les motifs aux
programmeurs. Il existe 6 classes de réponses et donc de codes d’état, représentées par le
premier bit :
• 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 éronné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

Exemple :

13
 Requête INVITE Réponse à la requête INVITE
SIP/2.0 200 OK INVITE sip :mattias@mars.ausys.se SIP/2.0

Via : SIP/2.0/UDP swerdet.ausys.se Via : SIP/2.0/UDP swerdet.ausys.se

FROM : Mattias<sip : mattias@ausys.se> From : Lars<sip :lars@ausys.se>

TO: Lars<sip: lars@ausys.se> To: Mattias<sip:mattias@ausys.se>

Call-ID: 4353456345@swerdet.ausys.se Call – ID: 4353456345@swerdet.ausys.se

Content- Type: application/sdp Cseq: 1 INVITE

Content-length : 158 Subject: Hello Mattias

V=0 Content – Type: application/sdp

O=lars 3245436364 3453633533 IN IP4 Content-type : application/sdp

172.4.5.4
Content-Lengt : 187
S=Hello again
V=0
C= IN IP4 mars.ausys.se
O=mattias 52655765 2687637 IN IP4 172.2.2.5
M=audio 3456 RTP/AVP 0 3 4 5
S= Hello Mattias

C= IN IP4 swerdet.ausys.se

M = audio 3456 RTP/AVP 0 3 4 5

6.2.5.2 Les en-têtes SIP

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 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".

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

14
 • 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.

Dans le tableau suivant on donnera le détail d’utilisations de ces différents champs :

Champs Utilisations
Accept Utilisé dans les messages INVITE, OPTIONS et REGISTER qui
permet d'indiquer les types de média qui seront acceptés dans la
réponse à ce message.

Accept-Encoding Conditionne la réponse car il détermine quels codages text-based

y seront acceptés.

Accept-Language Il permet au client d’indiquer au serveur quel langage à utiliser

dans le corps du message de la réponse au client.

Allow Indique les méthodes valides supportées par les entités

identifiées par la requête URI.

Authorization Champ optionnel à inclure par l'utilisateur souhaitant

s'authentifier vis à vis du serveur auquel il est relié
Call-ID Identifie une invitation précise ou tous les enregistrements d’un
client particulier.
Contact Champ pouvant apparaître dans les requêtes INVITE, ACK et
REGISTER ou dans les réponses de codes 1xx, 2xx, 3xx et 485.
Il fournit en général l’URL où l'utilisateur pourra

Content-Encoding Indique le code utilisé pour écrire et lire l'en-tête d'entité. Ainsi
le serveur qui reçoit le message sait quel mécanisme de
décodage appliquer pour lire le Content-Type décrit ci-dessus et
peut connaître le type de média utilisé. Ce champ est très utile si
l'on veut compresser les en-têtes sans perdre les informations
précieuses qu'ils contiennent
Content-Length Il indique simplement la taille du Corps du message envoyé, en
nombre décimal d'octets.

Content-Type Il indique les types de média utilisés dans le Corps du message

envoyé.

15
Cseq Chaque requête doit obligatoirement contenir un numéro de
séquence Cseq (entier non signé de 32 bits). Le Cseq initial est
choisi arbitrairement par celui qui envoie la requête INVITE
mais doit toujours être inférieur à 2^31.
Date donne la date d’émission de la requête ou de la réponse. Les
retransmissions possèdent la même date que la requête ou
réponse d’origine.

Encryption Ce champ spécifie si le message est crypté et suivant quel

cryptage.
Expires donne la durée au-delà de laquelle le message expire.

From indique la personne à l'origine du message

Hide Le client utilise ce champ lorsqu'il veut que le chemin compris
dans l'En- Tête VIA soit caché aux prochains Proxy Servers que
traversera le message.
Max-Forwards utilisé pour limiter le nombre de PS ou passerelles que la requête
peut traverser jusqu’au prochain serveur dans le sens de l'UAC
vers l'UAS (downstream).
Organization Précise le nom de l’organisation à laquelle l’entité dont émane la
requête ou la réponse appartient
Priority Indique le niveau d’urgence de la requête, tel qu’il est perçu par
le client.

Proxy-Authenticate Ce champ doit être rempli dans une réponse Proxy

Authentification Required (code 407).

Proxy-Authorization Permet au client de s’identifier dans sa requête en destination

d’un PS le lui ayant demandé.

Proxy-Require Indique quels champs d’en-tête le PS supporte.

Record-Route Ce champ permet de mémoriser un chemin pour faciliter

l'acheminement de la réponse. Chaque Proxy Serveur traversé
ajoute son adresse dans ce champ en début de liste. Le serveur
appelé copie cette liste, sans la changer, dans l'en-tête Route de
sa réponse. La première entrée est ainsi l'adresse du serveur le
plus proche de celui qui répond.

Response-Key le client utilise cet en-tête dans sa requête pour déterminer la clé
a utilisé pour crypter la réponse.

Retry-After ce champ n'est utilisé que dans les réponses Service

Unavailable(code 503), Not Found (code 404), Busy (code 600)
ou bien Decline (code 603) pour indiquer à l'emetteur de la
requête quand est-ce qu'un service "normal" pourra reprendre. Il
contient une date ou un nombre en décimal de secondes.

Server Il contient les informations sur les softwares utilisés par les

16
 UAS.
Subject Résumé ou nature de l'appel qui peut permettre de le filtrer sans
avoir à lire la description de la session.

Timestamp Précise l'instant (date) où le client a envoyé la requête au

serveur.
To C'est l'adresse du destinataire. Ce champ est bien sûr
obligatoire.

Unsupported Liste quelles configurations ne sont pas supportées par le

serveur.

User-Agent Contient des informations sur le terminal de l'utilisateur

(UAC/UAS) à l’origine de la requête.

Via Contient les adresses des serveurs (PS) que traverse la requête.
Warning Les avertissements sont contenus dans les réponses dans le
langage le plus compréhensible pour l'utilisateur.
WWW-Authenticate Doit être inclus dans une réponse Unauthorized (code 401).

Contrairement aux protocoles standards tels que IP ou TCP, où le format des paquets
ou 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 les
champs d’en-tête suivants :

Champ d’en-tête Abréviation associée

Content-Type C
Content - Encoding E
From F
CALL-ID I
Contact M(pour " moved ")
Content-Length L
Subject S
To T
Via V

Les clients doivent être capables de mélanger des champs d’en-tête de messages courts
(format normal) avec ceux de messages longs (format compact) en utilisant les mêmes
requêtes. Les serveurs doivent accepter ces deux formats à la fois.

6.2.6 Exemples de transactions

Pour faire appel à SIP, l’application de l’UAC appelant envoie une requête INVITE au
Proxy Server (PS) auquel il est relié. Ce serveur, via d'autres PS, transmet cette requête à
l'UAS auquel est relié l’appelé. Cette requête demande à l’appelé s’il veut rejoindre un forum

17
de discussion, assister à une visioconférence ou établir simplement une communication privée
avec l’appelant. Si l’appelé est d’accord, il renvoie une réponse OK (code 200) à l’appelant
qui confirme alors qu’il a bien reçu la réponse de l’appelant. Pour cela, il envoie une requête
ACK, acquittement (acknoledgement) à l’appelé. De la même manière, si l’utilisateur
souhaite se déconnecter, l’application de l’utilisateur émet une requête BYE au lieu de ACK.
La requête INVITE contient la description de la session ouverte qui stipule quels sont
les médias et formats des messages SIP utilisés (protocole SDP) . Pour une communication
unicast, la requête INVITE précise les types de média et formats que l’appelant utilisera et
vers où il souhaite que les données soient envoyées. Si l’appelé est d’accord avec cette
description, sa réponse contiendra les mêmes paramètres(toutes les requêtes et leurs réponses
ont le même Call-ID) . En multicast, l’appelé répondra que si sa description est différente.

Exemple de fonctionnement d’une requête INVITE en mode Proxy Server (PS) :

1. Le client appelant (UAC) envoie au PS une requête INVITE avec l’adresse SIP du
destinataire henning@columbia.edu
2. Le PS contacte le Location Serveur et lui fournit toute ou une partie de l’adresse SIP du
destinataire : henning
3. Le PS obtient alors une adresse plus précise hgs@play
4. Le PS envoie une requête INVITE au serveur destinataire dont l’adresse lui a été fournie
par le service de localisation du Location Server : play
5. L’UAS du destinataire avertit l'appelé
6. Et retourne au PS de l'appelant l’accord du destinataire pour communiquer par une réponse
OK (code 200)
7. Ce PS retourne alors au client appelant l’accord du destinataire
8. La réception de l’accord du destinataire est acquittée par le client appelant par une requête
ACK
9. Cet acquittement est transmis directement à l’appelé
10. Communication établie

18
Exemple de fonctionnement d’une requête INVITE en mode Redirect Server [5]

1. Le client appelant (UAC) envoie une requête INVITE au redirect serveur (RS) avec
l’adresse destinataire
2. et 3. Le RS contacte le Location Server qui lui fournit l’adresse du serveur destinataire :
columbia.edu
4. Le RS renvoie au client appelant la nouvelle adresse par une réponse Moved (code 302)
signalant que le terminal destinataire a changé de PS ;
5. Le client appelant envoie une requête ACK au RS pour acquitter ;
6. Puis ce client envoie une requête INVITE au serveur du destinataire. Cette requête possède
le même Call-ID que la première mais son numéro de séquence Cseq est plus élevé
7. Le PS du destinataire avertit l'UAS de l'appelé , qui retourne au PS son accord pour
communiquer par une réponse OK (code 200). Le PS retourne au client appelant l’accord du
destinataire
8. La réception de l’accord du destinataire est acquittée par le client appelant par une requête
ACK , Cet acquitteme nt est transmis directement à l’appelé

Nous venons de voir, à travers ces 2 exemples que si certains paramètres de la session
doivent être changés, un nouveau INVITE est émis tout en conservant le Call-ID mais un
Cseq plus grand doit être utilisé. Pour localiser un utilisateur SIP, notons d’abord qu’un
terminal utilisateur peut constamment se déplacer. Sa position doit être enregistrée
dynamiquement par un location server. Un tel serveur enregistre plusieurs positions pour un
même terminal, qui est relié à plusieurs PS à la fois lorsqu’il se déplace (les PS les plus
proches) . Lorsqu'un serveur SIP interroge son location server, il établit une liste des postions
possibles de l’utilisateur à partir des résultats reçus. Cette liste contient 0 position ou plus.
Pour communiquer sa nouvelle position au serveur SIP, le terminal de l’utilisateur lui envoie
une requête REGISTER.

6.2.7 Conclusions

SIP (Session Invitation Protocol) est un protocole de signalisation permettant à un

appelant de retrouver un appelé via des serveurs dits "proxy" ou "redirect", ceux-ci pouvant
consulter des serveurs de "localisation" ou des serveurs "registrars" auprès desquels les
utilisateurs ont pu enregistrer leur localisation (même temporaire). Une fois que le client

19
(l'appelant) a localisé l'appelé, ce dernier accepte ou refuse ou redirige l'appel. S'il accepte,
l'appelant et l'appelé peuvent communiquer.

6.3 Le protocole MGCP

Le protocole MGCP (Media Gateway to Media Controller Protocols) résulte de la

fusion des deux protocole SGCP 1.1 ( Simple Gatte Control Protocol ) et du protocole IDPC
1.0 ( Internet Protocol Device Control ). Le protocole SGCP est utilisé pour contrôler
l’activité d’une Telephony Gateway à travers un élément de contrôle d’appel externe nommé
Call Agent. Le protocole IPDC est utilisé pour réaliser le control de connexions du Media
Gateway et le transport de la signalisation.
Le protocole MGCP suppose une architecture de contrôle d’appelle dont laquelle
l’élément intelligent de contrôle se trouve en dehors de Gateway, et c’est lui qui assure le
contrôle de l’activité de la passerelle multimédia à l’aide d’un protocole de contrôle. Cet
élément de contrôle s’appelle Media Gateway Contoller ou Call Agent.
Dans l’architecture MGCP il existe plusieurs Call Agent. Le protocole MGCP suppose
que ces différents Calls Agents doivent se synchroniser l’un avec les autres pour envoyer des
messages cohérents aux passerelles au-dessous de leurs contrôles.
Finalement MGCP est un protocole maître /esclave ou on s’attend à ce que les
Gateways exécutent des commandes envoyées par les Call Agents.

6.3.1 Généralités

Dans le réseau téléphonique la couche de signalisation est séparée de la couche de

transport de parole. Le rôle important de la signalisation est d’échanger les messages entre les
différentes entités pour établir un circuit de parole entre des utilisateurs qui désirent dialoguer.
Le rôle des protocoles de VOIP est d’assurer la connexion entre les deux réseaux RTC/RNIS
et le réseau Internet. C’est dans cette notion d’interconnexio n entre les deux mondes que se
situe le protocole MGCP.
Cette intégration permet au réseau RTC de voir les éléments de réseau téléphonique
comme étant autre switcher du réseau RTC.
L’architecture relative à l’interconnexion du réseau téléphonique avec un réseau IP est
présente sur le schéma ci-dessous.

20
 Le pôle d'interconnexion est composé de trois entités fonctionnelles et d'un protocole
permettant le dialogue au niveau de ces entités :

• Passerelle multimédia (Media Gataway). Elle assure la transformation d'un flux vocal
entre le mode circuit et le mode paquet.
• Contrôleur de la passerelle multimédia (Media Gateway Controller). Il assure le
contrôle de l'activité de la passerelle multimédia à l'aide du protocole de contrôle
(Control Protocol).
• Module de signalisation. Il assure la transcription de la signalisation ISUP.

Ces trois entités fonctionnelles peuvent être physiquement séparées ou alors couplées au sein
d'un même équipement.

Le protocole MGCP est le protocole de contrôle qui permet le dialogue entre Media Gateway
Controller ( Call Agent ) et Media Gateway.

Dans ce protocole l’interconnexion entre le réseau téléphonique et le réseau IP est assuré par
deux niveaux logiques :

• Niveaux de signalisation assurés par l’utilisation du SG (Signaling Gateway).

• Niveaux de voix assurés par l’utilisation de passerelle multimédia.

Pour plus d’information on peut regarder le scénario d’établissement d’un appel.

En ce qui concerne le Call Agent il y a trois catégories de messages :

• Des messages du réseau RTC transférés par le SG ( Signaling Gateway).

• Des messages originaires Network Management échangés entre le Call Agent et les
Gateways..
• Des messages de la MGC pour maintenir la Bases de données.

L’architecture générale du protocole MGCP la suivante :

• STP Point de Transfert de Signalisations

• SSP Point de Signalisation
• SG Gateway de Signalisation
• MG Media Gateway (Passerelle Multimédia)
• ISUP ISDN User Part

Dans cette architecture la gestion des différents Gateways ainsi que les
interconnexions avec le réseau PSTN est assurée par les Call Agents. L’identification d’une
extrémité ce fait par la nom du domaine de la Gateway a laquelle l’extrémité est reliée et par
un nom local dans ce Gateway.

6.3.2 Fonctionnement de MGCP

6.3.2.1 Les commandes MGCP

21
 Le protocole MGCP est un protocole de contrôle de fonctionnement de Media
Gateway. Dans ce protocole l’élément intelligent est le Call Agent il contrôle les passerelles
par l’utilisation des huit commandes échanger entre lui et les passerelles.
Ces commandes sont représentées dans le tableau suivant :

Commandes Directions Code

NotificationRequest Call Agent à Gateway RQNT
Notification Gateway à Call Agent NTFY
CreateConnection Call Agent à Gateway CRCX
ModifyConnection Call Agent à Gateway MDCX
DeleteConnection Call Agent à Gateway DLCX
AuditEndPoint Call Agent à Gateway AUEP
AuditConnection Call Agent à Gateway AUCX
RestartInProgress Gateway à Call Agent RSIP

Notification Request :

Le Call Agent peut envoyer cette commande au Gateway, pour lui demander de
détecter l’apparition des évènements spécifiques pour un terminal. Ces spécifications peuvent
être des signalisations téléphoniques comme l’accrochage ou le décrochage du téléphone ou
bien des tonalités pour des extrémités spécifique.
Une des plus importantes options de Notification Request est l’association d’une
action avec chaque évènement. L’utilisation de cette option permet la réduction de nombre de
messages échangés entre le Call Agent et le Media Gateway.

Notification Command :

Le Gateway utilise cette commande comme réponse à la commande Notification

Request envoyer par le Call Agent, cette commande indique au Call Agent que l’évènement
est déclenché.
Le Gateway peut envoyer un ou plusieurs réponses à des évènement dans une seule
commande, ces évènements sont envoyés par le Media Gateway dans l’ordre de détection des
ces évènements et c’est le rôle de Call Agent de mettre ces évènements dans l’ordre correcte.

Create Connection :

Cette commande est envoyée par le Call Agent au Media Gateway pour créer une
connexion entre deux extrémités. Autres que les paramètres nécessaires qui permettent au
Media Gateway de créer des connexions, il y a des options LocalConnectionOptions qui
définissent les qualités de services de la connexion.
Par l’envoie du message Notification Request le Call Agent a la capacité d’envoyer
des actions qui correspondent à chaque évènement. L’utilisation de cette option dans la
création d’une connexion permet de diminuer le nombre de messages échangés entre le Call
Agent et le Media Gateway.

Modify Connection :

22
 Cette commande permet au Call Agent de modifier les paramètres associés à une
connexion déjà établie.

Delete Connection :

Cette commande est envoyée par le Call Agent au Gateway, elle lui permet de
terminer une conversation téléphonique. S’il existe plus d’un seul Media Gateway pour une
conversation le Call Agent doit envoyer cette commande à chaque Gateway.
Une fonctionnalité important du protocole MGCP associé à cette commande est qu’il
faut au Media Gateway lors de la terminaison d’un appel d’envoyer au Call Agent une
réponse qui contient les informations suivantes :

− Nomb res de paquets (RTP) envoyés.

− Nombres d’octets envoyés.
− Nombres de paquets (RTP) reçus.
− Nombres d’octets reçus.
− Nombres de paquets perdus.
− Information sur la gigue.
− Information sur les délais de transmission.

Pour plus d’information sur ces paramètres on peut regarder le RFC 1889.
Le protocole MGCP permet au Gateway de couper une connexion quand il veut. Dans
ce cas le Gateway envoie au Call Agent une commande Delete Connection qui contient tous
les paramètres statistiques si dessus.
Il faut noter aussi que la Call Agent à la possibilité de supprimer une connexion de
multiples-extrémités dans le même temps et ceci par l’envoie d’un message Delete
Connection a un Gateway avec le caractère *. Cette commande ne ramène pas des
informations statistiques sur la connexion.

Audit Endpoint :

Le Call Agent peut utiliser cette commande pour détecter si une extrémité est
décrochée ou en état de sonnerie. Dans ce cas le Gateway ramène une réponse qui contient
des informations sur des extrémités spécifiques.

Audit Connection :

Cette commande permet au Call Agent de détecter tous les paramètres liés à une
connexion spécifique.

Restart In Progress :

Cette commande est envoyée par le Gateway au Call Agent. Il permet d’informer le
Call Agent de mettre hors services une extrémité ou un groupe d’extrémités qu’ils ont des
problèmes. Dans ce cas la Call Agent peut décider de tester ces extrémités avant de les mettre
hors service.

Pour se familiariser un peu avec le protocole MGCP nous allons développer un

scénario d’établissement d’une connexion entre deux extrémités.

23
 Nous allons développer un scénario de création d’une connexion dont laque lle
l’utilisateur A appelle l’utilisateur B.

6.3.2.2 Scénario

L’utilisateur A utilise un terminal analogique. Dans ce cas le CO ( Central Office) qui

sert l’utilisateur A est connecté à un réseau de signalisation SS7 à travers un STP (Point de
Transfert de sémaphore ).

L’interconnexion entre le réseau téléphonique et le réseau IP est assurée par deux

niveaux logiques :
1. Niveaux de signalisation, dans ce cas le STP est connecté au Call Agent à travers une
Gateway de signalisation( SG ), le rôle de SG est de convertir la signalisation SS7 du
réseau téléphonique en une signalisation sur le réseau IP. Dans ce cas le Call Agent
joue le rôle d’une entité intermédiaire entre le Gateway de signalisation et le Gateway
de multimédia.
2. Niveaux de voix, dans ce cas l’interconnections entre les 2 réseaux se fait à travers le
Media Gateway.

Les Media Gateway A et B sont contrôlés par le Call Agent et ceci par l’utilisation du
protocole MGCP.

TGW : Trunking Gateway.

24
 La fonctionnalité de Call Agent est représentée dans la figure suivante :

Les messages échangés entre les différentes entités pendant l’établissement de l’appel
sont représentés dans le tableau suivant :

Round CO SS7 TGW Call Agent RGW Utilisateur Etapes

trips
0.5 IAM à 1
1 IAM à 2
1.5 Database lookup 3
2 ß CRCX 4
2.5 ACK à 5
3 CRCX à 6
3.5 ß ACK 7
4 ß MDCX 8
4.5 ACK à 9
5 RQNT à Ring 10
5.5 ß ACK 11
6 ß ACM
12
6.5 ß ACM 13
décrocher 14
7 ß NFTY 15
7.5 ACK à 16
8 RQNT à 17
8.5 ß ACK 18

25
 9 ß MDCX 19
9.5 ACK à 20
10 ß ANM 21
10.5 ß ANM 22
(parole) 23
raccrocher 24
0.5 ß NTFY 25
1 ACK à 26
1.5 DLCX à 27
2 ß DLCX 28
2.5 ß REL 29

Scénario:

1. CO: émet un message d’initialisation (IAM) au Call Agent à travers son STP.
2. SS7 : le point de transfert de signalisation (STP) conduit le message ISUP au Gateway
de signalisation attaché au Call Agent.
3. Call Agent : cherche dans la base de données l’adresse IP de la Gateway à laquelle le
destinataire qui correspond à ce numéro est rattaché.
4. Call Agent : envoie un message Create Connection au Gateway de l’utilisateur A pour
ce connecter au réseau téléphonique.
5. TGW : envoie un message ACK au Call Agent pour lui indiquer la réception du
message CRCX.
6. Call Agent : saisit la réponse et envoie un message CRCX au Gateway de l’utilisateur
B.
7. RGW : envoie un message ACK au Call Agent pour lui indiquer la réception du
message CRCX.
8. Call Agent : indique ces informations au TGW par l’envoie d’un message Modify
Connection .
9. TGW : envoie un message ACK au Call Agent.
10. Call Agent : envoie un message Notification Request au RGW B pour lui indiquer de
sonner le téléphone B.
11. RGW : envoie un message ACK au Call Agent.
12. Call Agent : quand le Call Agent reçoit le message ACK de RGWB il envoie un
message ACM ( Address Complete Message ) au Gateway de signalisation.
13. SS7 : le STP transport cette information au CO.
14. Utilisateur B : le terminal B se décroche.
15. RGW : détecte cet évènement et informe le Call Agent par envoie de message
Notification.
16. Call Agent : envoie un message ACK au RGWB.
17. Call Agent : dans l’ordre de pouvoir détecter la terminaison de la conversation, le Call
Agent demande au RGW de lui informer le raccrochage du téléphone et ceci par
l’envoie d’un message Notification Request.
18. RGW : envoie un message ACK au Call Agent.
19. Call Agent : maintenant le canal de voix doit être transformé en mode full duplex ; le
Call Agent fait ceci par l’envoie du message Modify Connection au TGW.
20. TGW : envoie un message ACK au RGWB.
21. Call Agent : peut dans ce cas envoyer un message de réponse au Gateway de
signalisation.
22. SS7 : le STP envoie cette information aux CO.

26
 23. Les deux parties entrent en conversation.
24. RGW : l’utilisateur B se raccroche.
25. le RGW envoie un message de Notification au Call Agent.
26. Call Agent : envoie un message ACK au RGW.
27. Call Agent : envoie un message Delete Connection au RGW B.
28. Call Agent : envoie un message Delete Connection au TGW A.
29. Call Agent : émet un message RELEASE au Gateway de signalisation.
30. SS7 : le STP transport cette information au CO.

7. Matériels nécessaires à la mise en place de la VoIP

7.1 Introduction

L'intégration de services de téléphonie au sein de réseaux de données augure des

changements majeurs pour les entreprises car elle permet de distribuer les informations de
manière plus poussée et efficace que les stratégies multiréseaux actuelles.

7.2 Approche centralisée contre approche distribuée

Dans le passé, tous les réseaux vocaux furent construits en utilisant une architecture
centralisée dans lesquels les terminaux étaient contrôlés par des switchs centralisés. Bien que
ce modèle fonctionne pour tous les services basiques de téléphone, il limite de beaucoup les
évolutions des services associés.

Un des bénéfices de la technologie VoIP est qu’elle permet aux réseaux d’être construits soit
sur une architecture centralisée soit distribuée. Cette souplesse permet aux entreprises de bâtir
des réseaux caractérisés à la fois par un management simplifié et aussi de l’innovation pour
les terminaux, cela en fonction des protocoles ut ilisés.

En général, les architectures centralisés sont associés avec les protocole MGCP ou
H.248/Megaco. Ces protocoles ont été créés pour une interface centralisée qui gère le contrôle
de l’appel et la logique du «switching ». L’interface centralisée discute avec les différentes
passerelles qui routent et transmettent les paquets de voix.

Dans les architectures centralisées, l’intelligence du réseau est centralisée et les terminaux
sont relativement peu intelligents. Les partisans des architectures VoIP centralisées
encouragent ce modèle car il centralise le management et le contrôle des appels. Il simplifie
également le flux des appels ainsi que sa compréhension par les ingénieurs de développement.
Les critiques de cette architecture avancent qu’elle étouffe l’innovation des caractéristiques
des terminaux et qu’elle deviendra une entrave quand il s’agira de mettre en place des services
VoIP qui vont au-delà du simple transport de voix.

Les architectures distribuées sont associées avec les protocoles H.323 et SIP. Ces protocoles
permettent à l’intelligence du réseau d’être distribuée entre les terminaux et les interfaces de
contrôle d’appels. Dans ce contexte, « l’intelligence » englobe l’état d’un appel, les interfaces

27
d’appel, les procédures d’appel, la réservation de ressources, le paiement ou n’importe quel
autre aspect de la gestion d’un appel. Les terminaux peuvent être des passerelles VoIP, des
téléphones IP, des serveurs de média, ou n’importe quelle interface qui peut initier ou
terminer un appel VoIP. L’interface de contrôle d’appel est appelé « gatekeeper » dans un
réseau H.323 et proxy ou « redirect server » dans un réseau SIP.

Les avocats de l’approche centralisée mettent en avant la souplesse de ce modèle. Il permet

aux applications VoIP d’être traitées comme n’importe quel autre application IP distribuée et
sa souplesse autorise d’ajouter de l’intelligence soit sur les terminaux soit sur les interfaces de
contrôle d’appels en fonction du marché et des exigences technologiques du réseau.

Les architectures distribuées sont souvent bien comprises par les ingénieurs qui utilisent des
réseaux de données IP. Ses détracteurs soulignent que les réseaux distribués ont tendance à
rendre beaucoup plus complexe leurs mises en place.

Exemple d’architecture d’un réseau VoIP

7.3 Exemple de matériel proposé par le constructeur Cisco

Cisco est le constructeur leader mondial dans le domaine des matériels VoIP. Voyons
maintenant quelqu’uns des types de produits proposés par ce constructeur avant de les
détailler par la suite.

28
Produits Caractéristiques principales
Téléphones IP de la Possibilité de brancher des téléphones simples comme multifonction
directement sur une connexion Ethernet 10/100 Base-T
gamme Cisco 7900
- Téléphones simples à programmer et utiliser
- Commutateur Ethernet 2 ports intégré
- Nombreuses fonctions IP comprenant les applications XML
Cisco CallManager 3.2 - Traitement logiciel des appels et composant de contrôle des appels pour
les solutions de téléphonie sur IP de Cisco
- Installé sur les serveurs de convergence média Cisco (MCS), les
systèmes Cisco ICS 7750 ou sur certains serveurs tiers (CallManager 3.2)
IPPC (Cisco IP Contact IPCC (Cisco IP Contact Center) propose un routage intelligent des
appels, une téléphonie assistée par ordinateur (TAO) réseau/bureau ainsi
Center) qu'une gestion des contacts multimédia concernant les agents des centres
de contacts sur un réseau IP. Il inclut plusieurs applications, notamment
les suivantes :

- CallManager
- Cisco ICM (Intelligent Contact Manager)
- Cisco IP IVR/IP Queue Manager
Cisco IP ICD - Cisco IP ICD est à la fois un répartiteur automatique d'appels (ACD)
basé sur logiciel et une application IVR destinée aux centres de contacts de
(Integrated Contact taille moyenne utilisant les réseaux de téléphonie sur IP basés sur
Distribution) l'architecture Cisco AVVID.
- Contrairement aux systèmes ACD propriétaires hérités, Cisco IP ICD est
une plate-forme système ouverte permettant de configurer des interactions
client simples ou complexes.
- Cisco IP ICD dispose d'un éditeur CRS workflow graphique comportant
une interface standard permettant de créer ces interactions (également
appelées flux d'appels) et de construire une logique commerciale entre les
fonctions IVR et ACD.
Équipement d'accès Équipement d'accès intégré (IAD) à configuration fixe pour entreprises
intégré de la gamme
- Transmission données/voix par TDM ou par paquet sur une seule liaison
Cisco IAD 2400 ascendante WAN
- Le service de téléphonie IOS (ITS) assure un traitement IAD des appels
locaux avec des fonctions de commutation. Idéal pour les petits bureaux (5
à 20 téléphones)
- Fonctions reposant sur IP Keyswitch, idéal pour les petits bureaux (5 à 20
téléphones) n'ayant pas besoin de toutes les fonctions de Cisco
CallManager
- Prise en charge des téléphones classiques et des téléphones IP sur une
seule plate-forme
- Modèles de ports voix analogiques 8 FXS/16 FXS/16FXS+8FXO et port
voix numérique T1
- Interfaces WAN de type T1, G.SHDSL et ADSL
Passerelles vocales Les passerelles vocales dédiées Cisco VG200 et Cisco VG248 permettent
de relier des réseaux IP à des systèmes de téléphonie traditionnels, tels
Cisco que le RTC

- Prise en charge de plusieurs types d'interface, dont T1 et E1

- Entièrement paramétrable par Cisco CallManager, par une interface de
commande en ligne via Telnet, ou par SNMP

29
 7.4 Détail des matériels Cisco à utiliser

• Téléphones IP de la gamme Cisco 7900

Les téléphones IP Cisco permettent d'établir des communications professionnelles très

simplement. Entièrement programmables, avec un choix de quatre modèles (7960, 7940,
7910 et 7910+SW ainsi que le nouveau 7905), les téléphones IP Cisco vous proposent les
fonctions les plus utiles en environnement professionnel, tout cela au sein d'une plate-forme
simple à programmer et à utiliser.

Les modèles 7960, 7940 et 7910+SW sont des téléphones multifonction pouvant être
branchés directement sur une connexion Ethernet 10/100Base-T standard. Chaque modèle
permet de passer des communications de qualité téléphonique. Ils sont équipés d'un
commutateur Cisco 2 ports 10/100 pour une éventuelle connexion à un PC.

Les modèles 7910 et 7905 sont des modèles à fonctionnalités basiques avec une
connexion un seul port 10 Base-T. En tant que téléphones IP, ils peuvent être installés en tout
point du réseau IP de l'entreprise.

Les téléphones prennent en charge le protocole de configuration DHCP et il n'est pas

obligatoire de les identifier à l'aide de Cisco CallManager. Les téléphones IP Cisco prennent
en charge les algorithmes de compression audio G.711 et G.729a, le modèle 7905 prenant
également en charge les algorithmes de compression audio H.323 pour répondre aux
exigences en termes de bande passante bas débit. Une fonction de téléchargement du
microcode permet de leur ajouter de nouvelles fonctions en les programmant depuis le
système.

Caractéristiques principales :

Modèle Cisco 7960 et 7940
Module d'expansion Cisco
7914
Station de conférence
Cisco IP 7935
Modèles Cisco 7905, 7910
et 7910+SW
Le modèle Cisco 7960 est un téléphone IP multifonction avec 6
lignes programmables et des touches de numérotation rapide. Le
modèle Cisco 7940 dispose de deux boutons pour les utilisateurs
disposant d'applications qui utilisent une moindre bande
passante. Les deux comprennent un haut-parleur mains libres
fonctionnant en mode bidirectionnel, ainsi qu'un bouton muet
avec témoin lumineux. Un écran à cristaux liquides de 7,6 x 10
cm affiche les graphiques et les textes, tels que la date, l'heure, le
nom et le numéro de l'appelant, ainsi que les numéros composés.
Ces téléphones prennent également en charge le format XML,
les rendant ainsi idéaux pour afficher les contenus Internet.
Le module d'expansion 7914 permet d'étendre les possibilités du
téléphone IP Cisco 7960 grâce à des boutons supplémentaires et
à un écran à cristaux liquides, portant ainsi le nombre total de
boutons à 20 avec un module ou à 34 avec deux modules.
La station de conférence Cisco IP 7935 est une station
bidirectionnelle mains libres disposant de trois nouvelles touches
programmables, d'un écran à cristaux liquides et de touches de
navigation dans le menu. Elle convient pour les postes de travail,
les bureaux et les salles de conférence de petite à moyenne taille.
Les modèles Cisco 7910 et 7910+SW sont des téléphones IP
conçus pour les environnements à faible trafic, ne nécessitant

30
 pas des performances supérieures, tels que les halls d'accueil ou
les cantines. Ces deux modèles fonctionnent sur une seule ligne
et sont équipés d'un écran à cristaux liquides affichant 2 lignes
de 24 caractères, pour indiquer l'état de l'appel et afficher la
présentation du numéro. Le nouveau téléphone 7905 à faible
trafic dispose d'un écran large

Fonctionnalités principales :

• Avec le DHCP, les nouvelles installations des téléphones IP sont extrêmement rapides. Ces
derniers peuvent être déplacés d'un port Ethernet à un autre, et ce en tout point du réseau IP de
l'entreprise. Si vous déplacez un téléphone IP Cisco, aucune modification de base de données
ou de câblage n'est nécessaire, contrairement aux systèmes téléphoniques traditionnels. Les
téléphones IP Cisco redémarrent automatiquement et s'enregistrent de nouveau auprès de Cisco
CallManager.
• Les téléphones IP Cisco sont compatibles avec Microsoft NetMeeting. Si vous utilisez
NetMeeting, le partage d'applications ou la visioconférence sont accessibles à partir d'un simple
bouton situé sur votre téléphone IP Cisco.
• Tous les modèles utilisent le protocole CDP (Cisco Discovery Protocole), afin de tirer leur
alimentation du réseau local, éliminant ainsi tout besoin d'un bloc d'alimentation local.

• Cisco CallManager 3.2

Le logiciel de traitement d'appels Cisco CallManager ajoute des fonctions de

téléphonie aux réseaux locaux d'entreprise et aux équipements réseau de téléphonie par
paquets, tels que les téléphones IP, les équipements de traitement des médias, les passerelles
de voix sur IP (VoIP) et les applications multimédia. Grâce à l'interface de programmation
d'applications (API) de téléphonie ouverte de CallManager, les services de vidéo, voix et
données, tels que les messageries unifiées, les conférences multimédia, les centres de contacts
de collaboration et les systèmes de réponse interactive multimédia peuvent enfin interagir
avec les solutions de téléphonie IP. Cisco CallManager est installé sur le serveur de
convergence média Cisco (MCS) et sur certains serveurs tiers. Il est livré avec une suite
d'applications vocales et d'utilitaires intégrés, dont Cisco WebAttendant constitué d'une
console logicielle d'administration manuelle, d'une application de conférence et d'utilitaires de
création de rapports. Pour plus d'informations sur la gestion réseau VoIP, reportez-vous à
CiscoWorks Manager IP Telephony Environment Monitor Cisco CallManager version 3.2 est
une solution de traitement des appels de téléphonie IP d'entreprise évolutive, hautement
disponible et déployable. Les multiples serveurs sont mis en grappe et gérés comme une entité
unique, permettant ainsi d'accepter jusqu'à 10000 utilisateurs par grappe. En reliant de
multiples grappes, la capacité d'un système comportant 100 sites peut être augmentée jusqu'à
près d'un million d'utilisateurs. Cette mise en grappe permet de mettre en commun la
puissance de plusieurs serveurs Cisco CallManager répartis, augmentant ainsi l'évolutivité et
la disponibilité de ces serveurs pour les téléphones, les passerelles et les applications. La triple
redondance de serveurs de traitement des appels améliore grandement la disponibilité
générale du système.

31
Caractéristiques principales :

Cisco Call - Cisco CallManager est livré avec une suite d'applications vocales
Manager 3.2 permettant d'initier des conférences vocales ou d'obtenir une console
d'administration manuelle, évitant ainsi d'avoir recours à du matériel dédié
pour le traitement de la voix.
- Les services supplémentaires ou les servic es avancés, tels que la mise en
attente, le transfert et la redirection d'appels, les conférences, l'utilisation de
plusieurs lignes, la sélection automatique à l'arrivée, la numérotation rapide,
le rappel du dernier numéro ou de nombreuses autres fonctions, sont ainsi
disponibles sur les téléphones IP et les passerelles.
- L'amélioration des fonctions est possible grâce à l'évolutivité du logiciel et
permet d'éviter des dépenses excessives en matériel qui sont le lot des
systèmes de commutateurs privés classiques.
- Cisco CallManager Attendant Console : cette application avec interface
Web remplace la classique console d'administration manuelle et permet
d'accepter et de répartir rapidement les appels vers les utilisateurs de
l'entreprise. Un service d'annuaire intégré permet d'apporter des fonctions
de témoin d'appel (BLF) et de sélection directe de poste (DSS) à chaque
ligne du système. La console surveille l'état de chaque ligne sans recourir à
des équipements de surveillance dédiés, économisant ainsi sur les coûts.
- Les applications logicielles, telles que le système de répondeur vocal
interactif de Cisco, Cisco IP Contact Center, Cisco Automated Attendant et
Cisco SoftPhone, interagissent avec Cisco CallManager via les API de
téléphonie.

• IPPC (Cisco IP Contact Center)

IPCC (Cisco IP Contact Center) propose une téléphonie assistée par ordinateur (TAO)
réseau/bureau par routage intelligent des appels ainsi qu'une gestion des contacts multimédia
pour les agents des centres de contact sur le réseau IP. Grâce à une solution unifiée combinant
les fonctionnalités logicielles ACD avec la téléphonie IP, IPCC garantit aux sociétés le
déploiement rapide d'une infrastructure distribuée de centre de contacts permettant de prendre
en charge l'ensemble de leurs ventes et initiatives de services électroniques.

Fonctionnalités principales :

• Intégration d'un commutateur hérité

• Option de redondance
• Évolutivité totale : de moins de 100 équipements à des milliers d'équipements
• Interaction multicanaux - collaboration par interface Web avec fonction IRC et de rappel,
routage des e-mails, messagerie vocale et télécopie.
• Liste évolutive des partenaires EcoSystem permettant d'intégrer des applications tierces
essentielles
• Prise en charge de centres de contacts multisite, intégration CRM
• Enregistrements détaillés des appels de contacts de bout en bout
• Bureaux de superviseurs et d'agents communs à tous les produits servant à gérer l'interaction
avec les clients Cisco, tels que les produits Cisco IP ICD Standard, IP Enhanced et Cisco IP
Contact Center
• Rapports historiques personnalisés et prédéfinis ; rapports en temps réel intégrés dans les

32
 bureaux de superviseurs et d'agents
• Prise en charge du traitement personnalisé des appels en attente comprenant la gestion de la
musique d'attente et des messages personnalisés
• Affichage standard à l'écran permettant de transmettre à l'agent toute information déjà saisie
concernant l'appelant
• Prise en charge complète de l'interaction agent/superviseur via une session IRC
• Possibilité de prédéfinir des messages transmis entre agent et superviseur

• Cisco IP ICD (Integrated Contact Distribution)

Cisco IP Integrated Contact Distribution (IP ICD) est un répartiteur automatique

d'appels (ACD) économique, simple à installer et à utiliser, destiné aux entreprises. Cisco IP
ICD est intégré de manière transparente à toutes les applications de réponse au client, dont
Cisco IP IVR (Interactive Voice Response) et Cisco IP AA (Automated Attendant). IP ICD
présente de nombreux avantages : ce répartiteur automatique d'appels d'entrée de gamme
économique est à la fois simple à installer, administrer et utiliser. Employé conjointement à
Cisco IP IVR, il prend en charge les accès multimédia (voix, données et Web) et apporte des
outils de personnalisation complète des scripts de gestion des flux d'appels. En outre, il peut
être intégré de manière transparente aux applications de réponse au client de Cisco.
IP ICD est disponible en deux versions : Cisco IP ICD Standard et Cisco IP ICD
Enhanced. La version Standard convient aux utilisateurs de premier niveau et leur permet de
s'affirmer dans le segment de marché des PME.
La version Enhanced, quant à elle, offre un distributeur automatique d'appels (ACD)
multifonction convenant plus particulièrement aux centres de contacts de taille moyenne.
Cette version fournit également un chemin de migration vers IPCC (IP Contact Center) de
Cisco, premier centre de contacts haut de gamme de Cisco.

Fonctionnalités principales :

• Administration de Cisco IP ICD par navigateur Web totalement intégrée avec celle de Cisco
CallManager
• Enregistrements détaillés des appels de contact de bout en bout ; l'affichage standard à l'écran
permet de transmettre à l'agent toute information déjà saisie concernant l'appelant
• Rapports historiques personnalisés ou prédéfinis ; rapports en temps réel intégrés dans les
bureaux de superviseurs et d'agents
• Bureaux de superviseurs et d'agents communs à tous les produits servant à gérer l'interaction
avec les clients Cisco, tels que les produits Cisco IP ICD Standard, IP Enhanced et Cisco IP
Contact Center
• Invite et points de files d'attentes d'appels IP complets, regroupement des fonctionnalités
d'interaction vocale
• Prise en charge du traitement personnalisé des appels en attente comprenant la gestion de la
musique d'attente et des messages personnalisés
• Prise en charge complète de l'interaction agent/superviseur via la fonction IRC, possibilité de
prédéfinir des messages transmis entre agent et superviseur

33
 • Équipement d'accès intégré de la gamme Cisco IAD 2400 avec service de
téléphonie IOS (ITS)

Les équipements d'accès intégrés de la gamme Cisco IAD 2400

combinent les services de données, voix et vidéo sur les réseaux
IP et ATM et constituent des solutions efficaces et économiques
permettant de fournir des services vocaux et des accès Internet à
haut débit pour les PME, le tout dans un système n'occupant
qu'une unité d'armoire (1 RU). Associé au logiciel optionnel ITS,
l'équipement IAD 2400 est une solution idéale pour fournir des
services de téléphonie IP sur un réseau local convergent au sein
d'un environnement de bureau réduit (5 à 20 téléphones) ne
nécessitant pas les fonctionnalités de CallManager.

Caractéristiques principales :

Gamme Cisco IAD Équipement d'accès professionnel complètement intégré

2400
- Fonctions reposant sur le service de téléphonie IOS (ITS), idéal pour
les petits bureaux (5 à 20 téléphones) ne nécessitant pas les
fonctionnalités de Cisco CallManager

- Prise en charge des téléphones classiques et des téléphones IP sur une

seule plate -forme

- Modèles de ports voix analogiques 8 FXS/16 FXS/16FXS+8FXO et

port voix numérique T1

- Interfaces WAN de type T1, ADSL et G.shdsl

Fonctionnalités principales :

• Combine des services d'accès Internet à haut débit et des services vocaux de qualité
téléphonique sur une seule plate-forme IOS (le service ITS existe depuis la version 12.1(5)YD
de Cisco IOS)
• TDM, VoIP et VoATM (AAL2) tous disponibles sur une seule plate-forme
• Migration transparente des clients de réseaux GR-303 TDM vers des réseaux GR-303 par
paquets ou des réseaux utilisant des agents d'appel
• Possibilité d'installation et de configuration automatisée à distance via le protocole SNAP
(Simple Network Auto Provisioning) et l'outil Cisco Configuration Express

34
Caractéristiques détaillées :

IAD 2421 IAD 2423 IAD 2424

Ports LAN fixes 1 port Ethernet Idem IAD 2421 Idem IAD 2421
(10Base-T)
Ports WAN fixes T1, 1 port 1 port ADSL 1 port G.shdsl
Ports vocaux Analogiques : 8FXS, Analogiques : 8FXS Analogiques : 8FXS,
16FXS, 16FXS, 16FXS+8FXO,
16FXS+8FXO, Numérique : 1 T1
Numérique : 1 T1
Vitesse du 80 MHz (RISC) Idem IAD 2421 Idem IAD 2421
processeur (type)
Mémoire flash 16 Mo (par défaut), 16 Mo (par défaut), 32 16 Mo (par défaut), 32
32 Mo (max) Mo (max) Mo (max)
Mémoire DRAM 64 Mo 64 Mo 64 Mo
Dimensions (H x 4,32 x 44,45 x 28,70 Idem IAD 2421 Idem IAD 2421
cm.
L x P)

• Passerelles vocales Cisco

Les passerelles vocales sont reliées directement aux réseaux téléphoniques privés ou
publics pour assurer le trafic voix sur les réseaux IP, en convertissant les appels IP en appels
téléphoniques standard et inversement. Elles permettent l'échange entre la téléphonie par
paquets et la téléphonie classique, telle que les réseaux téléphoniques publics ou privés, les
télécopieurs, etc.
L'ensemble de la gamme des routeurs multiservice Cisco apporte également des
fonctionnalités de passerelle vocale analogique et numérique grâce à des modules réseaux et à
des cartes d'interface vocale adaptés, tels que le module d'interface analogique Catalyst 6000
FXS.
Cisco fournit les passerelles vocales dédiées suivantes : Cisco VG200 et Cisco
VG248.

Caractéristiques principales :

Passerelle vocale - Conception et validation exclusivement destinées aux

environnements AVVID de CallManager
Cisco VG200 - Particulièrement adaptée aux petits bureaux et aux applications
d'entreprise
- Prise en charge des protocoles H.323 et MGCP, ainsi que des codecs
vocaux G.711, G.729, G.723.1
- Services de transcodage et de téléconférence avec le module
optionnel DSP de mise en grappe en réseau
- Attribution automatique d'adresse IP et identification auprès de
CallManager grâce au protocole DHCP
- Point de configuration et d'administration unique via Cisco
CallManager
- Administration via SNMP ou ligne de commande par Telnet, gestion
des téléchargements de logiciels par TFTP

35
 - Accès RNIS primaire (T1/E1) (côtés réseau et utilisateur) ; T1/E1-
CAS, T1/E1 QSIG avec MGCP, BRI, E&M, FXS et FXO (démarrage
en boucle et par terminaison)
- Services complémentaires (maintien d'appels, transfert d'appels,
téléconférence, mise en attente, etc.)
Passerelle vocale La passerelle vocale Cisco VG248 est un équipement occupant 1 unité
d'armoire permettant l'utilisation de 48 équipements analogiques
Cisco VG248 (téléphones, fax et modems) avec Cisco Call Manager. Cette passerelle
permet aux organisations possédant un parc important d'appareils
téléphoniques analogiques (hôtels, universités, hôpitaux, etc.) de
déployer la téléphonie sur IP tout en protégeant les investissements
antérieurs. Les lignes analogiques sont multifonction (identification
d'appelant, indicateur de message en attente, codes) et le prix par port
est plus compétitif.
La passerelle vocale VG248 permet de générer un protocole SMDI
pour les ports analogiques associés, autorisant ainsi l'établissement
d'une connexion à un réseau Cisco Call Manager via des systèmes de
messageries vocales traditionnels. La passerelle permet de partager les
systèmes de messageries vocales SMDI entre Cisco Call Manager et
les PBX traditionnels.

36
 Conclusion
VoIP n'a pas encore pu prendre son essor pour des raisons techniques qui constituent
encore un lourd handicap.

• Fiabilité

VoIP n'est pas encore suffisamment fiable et le protocole IP en est le principal

responsable. De larges segments de la population internet utilisent des versions IP, comme la
version IPv4 qui ne fournit pas un bon support pour un routage fiable. Or la question est la
suivante : combien de temps accepte-t-on d'attendre la tonalité lorsque l'on décroche le
téléphone ? Tant que IPv6, la future génération de protocole IP, n'est pas largement
implémentée, VoIP ne sera pas une option intéressante pour les entreprises. Il faudrait
l'utiliser avec d'autres solutions hybrides qui combinent l'IP avec des protocoles plus fiables,
comme l'ATM. Bien qu'IPv6 soit déjà intégré à un certain nombre de solutions internet et à
des systèmes d'exploitation comme Linux, peu d'entreprises ont migré de l'IPv4 à l'IPv6. Mais
cela devrait changer dans les trois années à venir, où nous assisterons à l'utilisation conjointe
de IPv4 et de IPv6 sur internet, le temps que les entreprises mettent à jour leurs équipements.

• Une qualité de son médiocre

Pour le moment, il n'y a pas de garantie de qualité sonore pour la VoIP. Elle est
souvent plus mauvaise que celle d'un téléphone cellulaire utilisé dans une zone à la couverture
médiocre... Les temps de latence sur le réseau, les problèmes de compression et un résultat
sonore peu fidèle affaiblissent grandement la qualité sonore du VoIP. La tâche devrait être
facilitée avec l'implémentation à grande échelle d'IPv6 d'ici les trois prochaines années, et
l'établissement de nouveaux standards par des organismes regroupant des industriels des
télécoms.

• Améliorer l'utilisation

VoIP doit offrir des fonctionnalités telles que la mise en attente d'un appel et
l'identification de l'appelant, des services de base de la téléphonie traditionnelle. Aujourd'hui,
l'implémentation de VoIP nécessite souvent que l'appelant tape jusqu'à 25 chiffres (numéro
d'accès, numéro d'identification personnel, code et numéro de téléphone du destinataire) avant
de pouvoir passer son appel. Tant que VoIP ne peut pas proposer la facilité d'utilisation et les
services fournis par les systèmes vocaux traditionnels, il aura du mal à convaincre les
entreprises.

• Localisation

Le nombre et la localisation des passerelles IP, qui fournissent les services de routage
VoIP, limitent également le développement du VoIP. Les fournisseurs de service doivent
supporter un nombre suffisant de passerelles situées dans les zones de gros trafic pour réussir
à faire des économies de coûts. Mais ce sont notamment les clients internationaux qui seront
pénalisés : le manque de passerelles signifie que les fournisseurs d'accès internet sont obligés

37
d'acheter et de revendre des services de routage via une autre entreprise (particulièrement
pour les routages longue distance). Les coûts de la solution VoIP augmentent d'autant.

• Standards

Le VoIP dépend principalement du standard téléphonie H.323, qui permet de mélanger

la voix, la vidéo et les données. Cependant, le H.323 est un standard globalement difficile à
implémenter pour les fournisseurs VoIP. Bien souvent, ils choisissent une solution
propriétaire afin d'obtenir un déploiement plus rapide. Ce qui peut entraîner des problèmes
d'interopérabilité pour les utilisateurs.

• Support administratif

Les systèmes administratifs de comptabilité, de facturation et de gestion du réseau

pour VoIP doivent être implémentés à des niveaux qui sont au moins parallèles à ceux de la
téléphonie traditionnelle. Mais pour l'instant, ces derniers détiennent l'avantage dans le
domaine des systèmes administratifs évolutifs qui gèrent les services administratifs.

38