Téléphonie Internet

par François TOUTAIN

Docteur ès sciences
Ingénieur de recherche
École Nationale Supérieure des Télécommunications de Bretagne

1. Normes de l'ITU-T .................................................................................... IP 2 960 - 2

1.1 Recommandation H.323.............................................................................. — 2
1.2 Protocoles H.323 .......................................................................................... — 4
1.3 Fonctionnement d'un système H.323 ........................................................ — 6
1.4 Services avancés offerts par H.323 ............................................................ — 6
1.5 H.332 (large scale) ....................................................................................... — 7
1.6 H.235 (sécurité) ............................................................................................ — 7
2. Approche Internet.................................................................................... — 7
2.1 SIP ................................................................................................................. — 7
2.2 SDP ............................................................................................................... — 7
2.3 RTSP ............................................................................................................. — 8
2.4 MEGACO & IPTEL ........................................................................................ — 8
3. Comparaison H. 323/SIP ........................................................................ — 10
3.1 Philosophie des deux approches................................................................ — 10
3.2 Points de comparaison................................................................................ — 10
3.3 Services ........................................................................................................ — 11
4. Enjeux de la téléphonie Internet.......................................................... — 11
Pour en savoir plus ........................................................................................... Doc. IP 2 960

ne des principales idées-force à l'œuvre dans le secteur des télécommuni-

U cations depuis plus de quinze ans est l'intégration de services. Ce concept
vise à permettre, dans un réseau de communication unifié, la coexistence de
communications hétérogènes aussi bien en terme de contenu qu'en terme de
contraintes de transmission (débits, délais, pertes, critères de fiabilité, critères
de trafics...) et a été le prélude aux technologies du RNIS (réseau numérique à
intégration de services) ou de l'ATM (Asynchronous Transfer Mode). Le domaine
en pleine expansion de la téléphonie Internet s'inscrit dans cette optique,
puisqu'il cherche à reproduire (et à étendre) le service fourni par le réseau télé-
phonique traditionnel sur un réseau à commutation de paquets, muni des proto-
coles du monde Internet, et donc destiné de prime abord à la transmission
asynchrone de données informatiques. Ce service de téléphonie se caractérise
par des transmissions « temps-réel » de flux de données audio entre deux usa-
gers ou plus (dans le cas des conférences téléphoniques) ainsi que par l'échange
des informations requises pour contrôler ces transmissions, ou données de
signalisation. Son extension passe par l'ajout d'autres modes de communica-
tion, flux vidéos, données textuelles ou graphiques et autres partages d'applica-
tions, ainsi que par l'évolution des procédures de signalisation, autorisant de
nouvelles fonctionnalités de gestion d'appels, de reroutage, d'intégration à des
applications informatiques...
Nous passons en revue dans cet article les deux grandes approches de la télé-
phonie Internet, l'une issue de l'International Telecommunication Union (ITU) et
dont les diverses composantes sont regroupées sous l'appellation H.323 ;
l'autre proposée par la communauté Internet au travers de l'Internet Engineering
Task Force (IETF), regroupée sous le nom de système SIP (cf. article « Protocole

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Réseaux IP 2 960 − 1
TÉLÉPHONIE INTERNET _________________________________________________________________________________________________________________

SIP » de ce traité). Ces approches ont en commun la définition de procédures de

signalisation permettant l'établissement, le contrôle et le relâchement d'appels
téléphoniques et par extension, multimédias. De tels appels sont des communi-
cations entre deux interlocuteurs (point-à-point) ou plus (conférences multi-
point), qui interconnectent des équipements terminaux et d'autres offrant des
fonctionnalités de passerelle (interface avec un réseau non IP) et d'administra-
tion au sens large.
Quelle que soit l'approche utilisée, l'avantage immédiat procuré par la télépho-
nie Internet, en l'état actuel du réseau, se traduit par une réduction des coûts due
à la tarification particulière qui prévaut pour l'Internet, ainsi qu'aux coûts artifi-
ciellement élevés des communications téléphoniques. La nature des réseaux IP
et des mécanismes de transport qu'ils proposent font à plus long terme l'intérêt
de la téléphonie Internet, en facilitant l'intégration des communications de type
téléphonique au sein de services variés.

1. Normes de l'ITU-T Équipement

Codecs vidéo
vidéo
Compensation
délai et gigue
Équipement
L'International Telecommunication Union (ITU), organisme suc- audio
Codecs audio
cesseur du CCITT (comité consultatif international téléphonie et
télégraphie), a proposé au travers de son secteur de standardisation Applications
ITU-T un ensemble de recommandations applicables à la téléphonie T.120
Internet. Ces documents sont référencés dans la série H, qui Interface
Unité de contrôle d'accès
concerne les systèmes audiovisuels et multimedias et plus précisé- au réseau
ment s'intéresse aux aspects d'infrastructure et d'équipements ter- H.225.0
minaux dans le contexte de services audiovisuels. Contrôle d'appel

Interface
Signalisation d'appel
usager
1.1 Recommandation H.323
Contrôle d'admission

La recommandation H.323 [1] constitue le point d'entrée obligé de

cette série de normes, en cela qu'elle est une introduction à l'appro-
che préconisée par l'ITU-T et aux autres recommandations. Elle
décrit plusieurs entités fournissant collectivement un service de
communication multimedia au-dessus de réseaux à commutation
de paquets, ces derniers pouvant ne pas fournir de garanties de
qualité de services. Le cadre visé est donc analogue à l'Internet
actuel, dans lequel la qualité de service, en termes de débit alloué,
délai de transmission de bout en bout et pertes de paquets, est du
type best-effort (« au mieux »). Cette recommandation est actuelle-
ment disponible en version 2, approuvée en février 1998 et supplan-
tant la version 1 qui fut adoptée en 1996. La version 2 étend le
champ de compétence de la norme, en englobant a priori tous les
réseaux à commutation de paquets, qu'ils soient locaux, réseau
d'entreprise, réseau métropolitain ou étendus (intranet, Internet), ou
encore connexions établies au-dessus du réseau téléphonique ou
RNIS, qu'ils offrent des mécanismes de gestion de qualité de service
ou non. Par contraste, la version 1 se focalisait uniquement sur des
réseaux locaux de type best-effort.
Les entités décrites doivent obligatoirement proposer un service
de communication audio, tandis que la transmission de vidéo et de
données est optionnelle. Elles peuvent être intégrées à des micro-
ordinateurs par le biais de compléments matériels et logiciels, ou
mises en œuvre en tant qu'équipements autonomes, à l'instar de
visiophones. Ces entités sont exploitées en configuration point à
point ou multipoint – cette dernière configuration ouvrant la voie
aux applications de type conférences – et sont conçues de façon à
pouvoir interopérer d'une part entre elles, pour déterminer des
types de media communs, et d'autre part avec un ensemble de ter-
minaux audiovisuels définis par un certain nombre de recomman-
dations ITU-T de la série H (H.320 pour le RNIS, H.321 pour le RNIS
large bande, c'est-à-dire la technologie ATM, H.322 pour les termi-
naux opérant sur des réseaux locaux avec garanties de qualité de
service, etc.).
Figure 1 – Architecture d’un terminal H.323
Les entités H.323 sont des composants d'un système de commu-
nication multimédia H.323. La recommandation distingue les termi-
naux (terminals), les passerelles (gateways), les portiers,
(gatekeepers), les contrôleurs multipoint (multipoint controllers ou
MC), les processeurs multipoint (multipoint processors ou MP) et
les unités de contrôle multipoint (multipoint control units ou MCU).
Ces entités peuvent constituer un équipement à part entière, ou être
intégrées au sein d'une même machine. La recommandation décrit
enfin les procédures et les messages qui permettent à ces entités de
communiquer.
1.1.1 Terminaux
Un terminal H.323 est un équipement d'extrémité fournissant
un service de communication temps-réel bidirectionnelle avec
un autre terminal, une passerelle ou une unité de contrôle mul-
tipoint.
Ces communications se composent de données de contrôle et
d'indication, ainsi que de données multimédia de type audio, vidéo,
et/ou données télé-informatiques. Un terminal peut offrir des capa-
cités de communication audio uniquement, audio et données, audio
et vidéo, ou encore audio, vidéo et données.
L'architecture d'un terminal H.323 est donnée en figure 1.
Un terminal H.323 renferme :
— une unité de contrôle, qui se décompose en trois sous-
ensembles ; le contrôle d'appel, explicité par la recommandation

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
IP 2 960 − 2 © Techniques de l’Ingénieur, traité Réseaux
_________________________________________________________________________________________________________________ TÉLÉPHONIE INTERNET
Facturation Contrôle d'appel global
Gestionnaire d'appel H.323 Signalisation
Q.931
H.225 H.245
H.225.0
RTP RTCP signal. signal. Contrôle lien
RAS
Appel Contrl LAPD
Protocoles transport & interface réseau Interface physique
côté H.323 côté RNIS
Figure 2 – Architecture d’une passerelle H.323
H.245, la signalisation d'appel (dérivée de la norme Q.931) et le
contrôle d'admission (RAS pour Registration, Admission, Status),
tous deux décrits dans la recommandation H.225 ;
— un ou plusieurs codecs audio, conformes aux
recommandations :
• G.711 (codage PCM à 56 et 64 Kbit/s, en version µ-law ou
A-law) ; le codec G.711 est obligatoire dans tout terminal H.323,
• G.722 (codage SB-ADPCM à 64 Kbit/s),
• G.723.1 (codage CELP à 5,3 et 6,3 Kbit/s),
• G.728 (codage Low Delay CELP, 16 Kbit/s),
• G.729 (codage CS-ACELP à 8 Kbit/s),
• MPEG-1 audio.
— de façon optionnelle un ou plusieurs codecs vidéo. Ces codecs
se conformant aux recommandations H.261 et H.263 ;
— de façon optionnelle une interface pour la transmission de
données, conforme à la recommandation T.120, et permettant
l'échange de fichiers et d'images, l'accès distant à des bases de don-
nées, l'accès à des applications partagées... ;
— un mécanisme de compensation de délai et de gigue, permet-
tant une synchronisation fine des flux audio et vidéo reçus ;
— une interface pour l'accès au réseau à commutation de
paquets. Cette interface est en fait hors de la recommandation
H.323, mais doit néanmoins être conforme à la description donnée
dans la recommandation H.225.0 : transport fiable de bout en bout
(à l'aide par exemple du protocole TCP), transport de messages non
fiable (à l'instar de UDP).
Lorsqu'un terminal comporte plusieurs codecs audio, il doit être
capable d'opérer de façon asymétrique, en utilisant un codec donné
pour l'émission et un autre codec pour la réception. Lorsqu'un ter-
minal est destiné à une utilisation sur un réseau à faible débit, en
deçà du minimum requis pour le codec G.711, la norme préconise
que ce terminal intègre le codec G.729. Lorsqu'un terminal com-
porte un ou plusieurs codecs vidéo, le support de H.261 au format
d'image QCIF (Quarter Common Intermediate Format) constitue le
service minimal obligatoire.
1.1.2 Passerelles
Une passerelle H.323 est un équipement fournissant un ser-
vice de communication temps-réel bidirectionnelle entre un ter-
minal H.323 situé sur un réseau à commutation de paquets et un
autre équipement. Celui-ci peut être un terminal ITU localisé sur
un réseau à commutation de circuit, ou une autre passerelle.
Un exemple d'architecture d'une passerelle H.323 est donné en
figure 2.
Cet exemple met en évidence les deux mondes qui sont intercon-
nectés par la passerelle ; sur la partie gauche sont regroupés les
composants du monde H.323, se comportant à l'image d'un termi-
nal mais avec un module de contrôle d'appel particulier, tandis
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Réseaux
qu'en partie droite se trouvent les composants du réseau à commu-
tation de circuits, ici le RNIS.
La passerelle H.323 est fonctionnellement constituée de trois
sous-ensembles :
— une passerelle de signalisation (signalling gateway), qui com-
prend les terminaisons des réseaux de signalisation et opère la
médiation de la signalisation (traduction et retransmission des mes-
sages, confidentialité, tenue de statistiques) ;
— une passerelle média (media gateway), constituée des termi-
naisons de réseau pour les flux audio/vidéo/données, y compris les
codecs ; la passerelle media exécute des traitements de condition-
nement de flux (transcodage, suppression de silence, annulation
d'écho, conversion des séquences DTMF...) et peut superviser les
aspects sécurité (confidentialité des données) ;
— un contrôleur de passerelle media (media gateway controller),
chargé de la logique de traitement des appels (routage, authentifica-
tion, sélection de la qualité de service, facturation des appels, col-
lecte d'informations statistiques...), du contrôle d'admission des
flux de données et d'aspects relatifs à la sécurité.
La passerelle H.323 est donc chargée d'abstraire les caractéristi-
ques des réseaux qu'elle interconnecte, tant sur le plan de la signa-
lisation d'appel qu'au niveau des flux de données eux-mêmes. Les
aspects de médiation de la signalisation sont traités dans plusieurs
documents de l'ITU-T, par exemple la recommandation H.246 dans
le cas d'une passerelle H.323/RNIS bande étroite. Dans ce cas de
figure, la passerelle doit se conformer d'un côté à la signalisation du
RNIS (Q.931), de l'autre à la signalisation d'appel H.225.0. Cette der-
nière étant un sous-ensemble de la Q.931, le document précise les
règles d'adaptation et de retransmission des messages de signalisa-
tion. Ainsi un message d'établissement (SETUP), reçu du côté H.323,
entraîne la génération d'un message analogue sur le réseau RNIS,
tandis que la réception d'un message de fin d'appel RELEASE COM-
PLETE côté H.323 initialise la déconnexion en RNIS, procédure plus
complète impliquant l'échange de plusieurs messages sur ce
réseau.
La recommandation H.246 précise également les mécanismes qui
peuvent être mis en jeu pour obtenir un complément d'adresse
dénotant le destinataire dans le monde H.323, lors d'un appel RNIS
entrant. Une passerelle doit ainsi être capable de transmettre à
l'appelant une requête d'extension d'adresse (TCS-4), mais aussi de
jouer un message audio demandant un complément d'information
à l'usager et de décoder les tonalités (DTMF Dual Tone Multi Fre-
quency) composées par cet usager en réponse à cette demande.
1.1.3 Portiers ou gatekeepers
Un portier ou gatekeeper H.323 est une entité fournissant un
service de traduction d'adresses et un service de contrôle
d'accès aux ressources du réseau pour le compte de terminaux,
de passerelles, et d'unités de contrôle multipoint H.323. Un gate-
keeper peut également fournir d'autres types de services, tel la
gestion de la bande passante du réseau ou la localisation de pas-
serelles.
Le gatekeeper est un équipement optionnel qui fournit lorsqu'il
est présent un contrôle accru des autres équipements H.323 et des
communications qu'ils génèrent. Il est responsable d'une zone
administrative, qui peut englober par exemple le réseau interne
d'une entreprise. Chaque terminal, passerelle et MCU H.323 de la
zone doit se faire connaître du gatekeeper préalablement à toute
communication, au travers de requêtes RAS.
Le service de traduction d'adresse fourni par le gatekeeper per-
met la résolution d'adresses de/vers des alias H.323, des adresses
au sens de la numérotation du réseau téléphonique (E.164), ou
encore des adresses Internet. Le contrôle d'accès intègre l'authenti-
fication des terminaux et des passerelles ainsi que l'autorisation des
appels. La gestion de la bande passante est une fonctionnalité
IP 2 960 − 3
TÉLÉPHONIE INTERNET _________________________________________________________________________________________________________________
optionnelle qui est mise en œuvre par le jeu de requêtes RAS. Elle
permet au gatekeeper de contrôler le niveau d'utilisation de la
bande passante du réseau, et d'accepter ou de refuser l'établisse-
ment de nouvelles communications ainsi que la modification de
communications existantes, en fonction de critères non précisés par
la norme. Un service minimal est prévu, dans lequel le gatekeeeper
peut tout simplement autoriser systématiquement toutes les com-
munications.
De surcroît, le gatekeeper peut servir de « routeur » par lequel
vont transiter toutes les communications d'établissement d'appel et
d'établissement des flux média associés, dans un but de contrôle
strict des communications.
Un gatekeeper est en principe requis dès lors qu'un système
H.323 intègre une ou plusieurs passerelles, en raison des besoins de
traduction d'adresses soulevés par l'interconnexion de plusieurs
types de réseaux.
1.1.4 Contrôleurs multipoints
Un contrôleur multipoint H.323 assure le contrôle d'au mini-
mum trois terminaux prenant part à une même session de
communication.
Il peut par extension être utilisé pour interconnecter deux termi-
naux dans une session point-à-point, si cette dernière est suscepti-
ble d'évoluer dans le temps en intégrant de nouveaux participants.
Le contrôleur multipoint fournit aux terminaux un service de négo-
ciation de capacités, permettant d'aboutir au choix de capacités de
communication audio, vidéo, qui soient communes à tous les termi-
naux connectés. Il peut également offrir un contrôle des ressources
de la conférence. Le contrôleur n'est pas chargé du mélange
(mixage) ou de la commutation des informations audio, vidéo et
données téléinformatiques.
1.1.5 Processeurs multipoints
Un processeur multipoint H.323 est chargé de centraliser le
traitement des informations véhiculées par les flux de données
(audio, vidéo, data) dans une conférence multipoint.
Le processeur multipoint peut réaliser des opérations de mixage
(mélange des flux audio par exemple), de commutation (sélection
du flux vidéo retransmis aux participants) ou d'autres traitements
non précisés. Il opère sous la houlette d'un contrôleur multipoint et
peut être chargé d'un flux unique ou d'un ensemble de flux.
1.1.6 Unités de contrôle multipoint
Une unité de contrôle multipoint ou MCU est un équipement
d'extrémité qui fournit la possibilité à trois équipements H.323
au minimum de communiquer au sein d'une session multipoint.
La MCU est constituée d'une part d'un contrôleur multipoint (uni-
que) et d'autre part d'une collection, optionnelle, de processeurs
multipoints dotés de caractéristiques de traitement variées. Elle
peut être explicitement appelée lors de l'établissement de la confé-
rence, ou peut être invoquée de façon transparente par un gatekee-
per (par exemple lorsqu'une session point-à-point intègre de
nouveaux participants et se transforme en session multipoint).
Une session multipoint peut être centralisée (en étoile), auquel
cas tous les terminaux communiquent avec la MCU en mode point-
à-point, c'est-à-dire avec le contrôleur multipoint pour la partie
signalisation et contrôle de la session et avec un ou plusieurs pro-
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
IP 2 960 − 4 © Techniques de l’Ingénieur, traité Réseaux
Présentation Enregistrement Contrôle d'appel et
Applications
de transfert
Audio/vidéo admission de conférence
de données
H.245
H.225.0 H.225.0
RTP/RTCP ctrl média T.120
RAS ctrl appel
ctrl conf.
UDP TCP
IP / IP multicast
Figure 3 – Pile de protocoles H.323
cesseurs multipoints pour l'échange des médias (lorsque le réseau
sous-jacent dispose de capacités de diffusion, son exploitation est
possible en ce qui concerne les flux média ; le ou les processeurs
multipoints peuvent diffuser les données audio, vidéo à tous les ter-
minaux). Une session multipoint peut également être décentralisée,
auquel cas les terminaux qui en ont la capacité peuvent directement
utiliser la diffusion réseau pour transmettre leurs flux media aux
autres terminaux. Par contre, les informations de signalisation et de
contrôle sont toujours échangées en point-à-point entre chaque ter-
minal et le contrôleur multipoint. Des modes de transmission hybri-
des sont enfin possibles, où certains flux (par exemple audio) sont
diffusés et d'autres (flux vidéos) transmis en point-à-point.
1.2 Protocoles H.323
Nous décrivons maintenant plus en détails les divers composants
protocolaires des systèmes H.323. La figure 3 dénote la pile de pro-
tocoles de ces systèmes : les éléments grisés sont définis par les
recommandations du monde H.323, tandis que les éléments laissés
en clair, bien que partie prenante des systèmes H.323, sont soit défi-
nis par d'autres documentations, Requests for Comments (RFC) du
monde Internet et autres recommandations ITU-T, soit non précisés
et donc laissés au libre choix de l'implémenteur d'un système parti-
culier.
La recommandation H.225.0 concerne les communications de
signalisation de bas niveau entre des équipements H.323, destinées
en règle générale à l'initiation des appels. Elle se scinde en deux
sous-ensembles qui concernent respectivement :
— les fonctionnalités d'enregistrement, d'admission et de statut
(Registration, Admission, Status ou RAS) ;
— la signalisation d'appel, dérivée de la recommandation Q.931 du
RNIS.
1.2.1 H.225.0 RAS
Les messages RAS permettent un dialogue entre les équipements
d'extrémité (terminaux, passerelles, MCU) et leurs gatekeepers res-
pectifs. Par conséquent, ces messages ne sont pas utilisés dans une
configuration H.323 dépourvue de gatekeeper. Grâce à des échanges
du type requête/réponse, les équipements sont en mesure de
découvrir dynamiquement l'existence d'un gatekeeper dans leur
zone, de s'enregistrer auprès de ce gatekeeper, puis de requérir de
celui-ci l'autorisation d'établir un appel H.323. Lors de cette requête,
et plus tard pendant le déroulement de l'appel, un équipement peut
s'adresser à son gatekeeper, par le biais des messages RAS, au sujet
d'une ressource partagée, dont la gestion incombe au gatekeeper. Il
s'agit essentiellement de la bande passante disponible, qui peut être
placée sous le contrôle du gatekeeper dans un but de maîtrise de la
qualité de service. Les services de passerelles peuvent également
être gérés par le gatekeeper, auquel cas les terminaux souhaitant
établir un appel via une passerelle devront au préalable s'adresser à
_________________________________________________________________________________________________________________ TÉLÉPHONIE INTERNET
leur gatekeeper afin d'obtenir une autorisation d’usage. Par ailleurs,
un gatekeeper utilise activement les messages RAS pour s'enquérir
de l'état des composants H.323 dont il a la charge. Il requiert ainsi le
statut de chaque équipement, pour s'assurer de la disponibilité de
ceux-ci (passerelles) ou détecter des pannes silencieuses.
Les échanges de messages RAS se caractérisent par une requête
(ReQuest RQ) et une réponse positive (ConFirm CF) ou négative
(ReJect RJ). Les échanges suivants sont spécifiés par la recomman-
dation H.225.0 :
— découverte d'un gatekeeper (G) : mise en œuvre par la requête
GRQ transmise en multicast dans la zone de rattachement de l'équi-
pement, et qui recevra une réponse positive GCF ou négative GRJ ;
— enregistrement auprès du gatekeeper (Registration R) :
requête RRQ, réponse positive RCF ou négative RRJ ; pour cet
échange, un mécanisme d'obsolescence est possible, qui requiert
de l'équipement l'envoi périodique de requête RRJ ;
— suppression de cet enregistrement (Unregistration U) : requête
URQ, réponses positive UCF ou négative URJ ; si la suppression est
initiée par le gatekeeper, l'équipement supprimé n'a pas le droit
d'émettre URJ ;
— service de localisation (Location L) : requête LRQ (Location
ReQuest), réponses LCF ou LRJ : la réponse positive véhicule des
informations de localisation sur l'équipement géré : adresses des
canaux de signalisation, numérotation, extensions... ;
— admission, ou autorisation à initier un appel (Admission A) :
requête ARQ, transportant une valeur qui dénote la bande passante
totale requise, réponses ACF ou ARJ ; la réponse ACF peut modifier
la valeur demandée ;
— modification de bande passante (Bandwidth B) : requête BRQ,
transportant une valeur qui dénote le nouveau besoin de bande pas-
sante, à la hausse ou à la baisse ; réponse BCF ou BRJ ; si le gate-
keeper est l'instigateur de la modification, l'équipement destinataire
ne peut pas refuser ;
— information de statut (Information I) : requête IRQ, réponse
IRR ;
— message d'erreur XRS (Unknown Message Response) en
réponse à une requête inconnue.
Les messages RAS sont transportés par un protocole non fiable de
type UDP (User Datagram Protocol) ce qui nécessite la mise en place
d'un contrôle par numérotation en séquence et d'un mécanisme de
retransmission des messages perdus.
1.2.2 H.225.0 Signalisation d'appel
La signalisation d'appel H.225.0 reprend un sous-ensemble des
messages et des procédures qui furent définis pour le RNIS, dans la
recommandation Q.931. Des informations additionnelles, spécifiques
au monde H.323, sont transportées grâce à des éléments d'informa-
tion d'usager (User-User Information Element UUIE).
Cette signalisation comprend des requêtes d'établissement
d'appel, de l'appelant vers l'appelé, des messages intermédiaires
(requête transmise, appelé contacté, etc.), ainsi que les réponses
finales retournées à l'appelant (acceptation, rejet, redirection,
accompagnés de causes d'erreur). Les divers messages ainsi repris
de la recommandation Q.931 sont les suivants :
— établissement d'appel : SETUP, ALERTING, CONNECT, et de
façon optionnelle CALL, PROCEEDING, PROGRESS, SETUP
ACKNOWLEDGE ;
— fermeture d'appel : RELEASE COMPLETE ;
— invocation de services H.450 : FACILITY ;
— autres messages (optionnels) : USER INFORMATION, INFOR-
MATION, NOTIFY, STATUS INQUIRY.
Les services H.450 sont des services d'appel de plus haut niveau
et plus complexes que ceux mis en œuvre dans la signalisation de
base (transfert d'appel, redirection d'appel, etc.).
Tous les messages de signalisation d'appel H.225.0 sont transpor-
tés sur une connexion fiable (de type TCP), ce qui simplifie considé-
rablement le contrôle d'erreur pour ces échanges (et alourdit ces
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Réseaux
échanges par la même occasion). Dans la majeure partie des cas,
cette connexion n'est utilisée que pour l'établissement de l'appel, et
peut ensuite être fermée. Elle sera réouverte par l'une ou l'autre des
extrémités si une fonctionnalité de signalisation est invoquée en
cours d'appel.
1.2.3 H.245
La recommandation H.245 décrit les procédures qui permettent le
contrôle de la session de communication, en termes de contrôle des
flux media ainsi que de contrôle de conférence dans le cas du multi-
point. Cette recommandation est exploitée par plusieurs systèmes de
communication ITU-T ; de ce fait, son usage au sein d'un système
H.323 comporte certaines restrictions (en particulier sur les multiplex
de flux) et certains ajouts spécifiques à cette norme.
Un canal de contrôle H.245 séparé est établi entre les entités com-
muniquantes après la phase d'établissement d'appel (H.225.0). Les
messages d'établissement de type Q.931 véhiculent pour ce faire des
informations d'adressage. Ce canal de contrôle H.245 est exploité
pour la négociation et l'établissement des flux média. Les fonctionna-
lités H.245 sont les suivantes :
— détermination de rôle maître/esclave : les équipements utili-
sent cette fonctionnalité pour élire un système maître, ce qui permet
d'éviter certaines situations de blocage, par exemple lors de l'éta-
blissement de canaux bidirectionnels, ainsi que d'identifier l'équipe-
ment jouant le rôle de MCU dans une conférence multipoint ;
— échange de capacités d'émission et de réception : les équipe-
ments exploitent cette fonctionnalité pour décrire à leurs pairs leurs
possibilités de codage/décodage en termes d'algorithmes, de paramé-
trage et de formats, en émission et en réception ; cet échange de
capacités permet aux équipements de négocier un ensemble commun
de fonctionnalités, et peut avoir lieu à tout moment au cours d'un
appel, ce qui permet la renégociation en cours d'appel ;
— contrôle des flux média : ouverture et fermeture de canaux
logiques qui sont des abstractions représentant les media échan-
gés. L'émetteur d'un canal logique doit se conformer aux capacités
de réception du destinataire, telles que négociées dans la phase pré-
cédente. Un canal logique audio, vidéo ou de données est toujours
de type unidirectionnel, même s'il peut en réalité faire référence à
une transmission de données bidirectionnelle (une session RTP) ;
— contrôle de conférence : lors d'une session multipoint, la ges-
tion de la conférence est assurée par des mécanismes H.245 pour
déterminer un ensemble de capacités conjointement supportées par
tous les participants, pour établir le modèle de session (centralisée ou
décentralisée), ainsi que pour fournir un ensemble de fonctions
d'administration de la conférence (contrôle du tour de parole, contrô-
les associés au dirigeant de la conférence etc.).
En sus de ces fonctionnalités, H.245 fournit un service d'estima-
tion du délai d'aller-retour entre deux équipements, qui permet de
plus de vérifier le fonctionnement en continu de ceux-ci.
Une clause particulière de la recommandation H.323 définit le
mécanisme de Fast Connect, ou connexion rapide, afin de réduire le
délai d'établissement des flux media. Ce mécanisme prévoit d'adjoin-
dre à une requête d'établissement d'appel SETUP la description de
tous les canaux logiques prévus par l'appelant, en émission comme
en réception. Cette description constitue une proposition, qui peut
être acceptée ou refusée par l'appelé en fonction de ses capacités
propres. Dans cette proposition, la description des flux est établie par
préférence décroissante. L'appelé choisit dans cette liste un ensem-
ble de flux media qui correspondent à ses possibilités, et retourne son
choix dans une structure d'information jointe à un message Q.931 de
réponse au SETUP (CALL PROCEEDING, ALERTING ou CONNECT).
La réception par l'appelant de ce choix est une indication que les
données des flux media peuvent être transmises, immédiatement
ou après le traitement du CONNECT du niveau inférieur. Par la suite,
les procédures de traitement H.245 se poursuivent normalement.
La version 2 de la recommandation prévoit d'autre part la possibi-
lité d'utiliser la connexion TCP véhiculant la signalisation d'appel
IP 2 960 − 5
TÉLÉPHONIE INTERNET _________________________________________________________________________________________________________________
(H.225.0) pour transporter les messages H.245 (ce procédé est
nommé tunneling), ce qui permet de réduire le nombre de con-
nexions TCP utilisées globalement dans une session de communica-
tion ainsi que le délai d'établissement.
1.2.4 RTP et RTCP
Les données des flux média d'un système H.323 sont transportées
par le protocole RTP (Real-time Transport Protocol), défini par la
communauté Internet dans le document [5]. Il s'agit d'un protocole
de transport non fiable, dédié aux flux continus de données (audio,
vidéo principalement), et fonctionnant en point-à-point ou en multi-
point sur un réseau IP. L'intérêt majeur de RTP réside dans la défini-
tion de payloads, ou indications de formatage et d'encapsulation
des données en fonction de leur nature (algorithme et format de
codage utilisé). Les données audio ou vidéo ainsi morcelées sont
ensuite encapsulées dans RTP, et le paquet résultant soumis à UDP
pour transmission dans le réseau. Cette transmission étant non fia-
ble, ces paquets pourront être perdus, déséquencés, dupliqués, ou
simplement retardés. De ce fait, chaque paquet RTP renferme dans
son entête des informations de type numéro de séquence et estam-
pille temporelle, permettant au récepteur de détecter une perte ou
un retard trop important, et ainsi de jouer le flux de données à l'arri-
vée. Les estampilles temporelles sont utilisées à la fois pour la syn-
chronisation intra-flux, ou détermination des instants de jeu de
chaque paquet de données, et la synchronisation inter-flux, qui met
en jeu les relations temporelles existant entre plusieurs flux (syn-
chronisation de la voix et du mouvement des lèvres par exemple).
Par ailleurs certains formats de payloads définis dans le contexte
de RTP autorisent l'exploitation de mécanismes évolués de correction
d'erreur par anticipation ou de dissimulation d'erreurs à l'arrivée, qui
permettent une transmission correcte d'audio et de vidéo même dans
un réseau moyennement chargé où se produisent des pertes de
paquets.
Ce protocole est accompagné d'un protocole de contrôle, RTCP
(Real-time Transport Control Protocol), qui offre des fonctionnalités
d'observation des communications RTP par le biais d'échange pério-
dique de rapports de transmission (pour les sources) et de réception.
Ces rapports véhiculent de façon directe ou indirecte des informa-
tions statistiques sur les communications, en termes de pertes de
paquets, de délai d'aller-retour, de gigue d'interarrivée des paquets
etc., informations qui permettent aux sources d'adapter dynamique-
ment leur transmission aux conditions régnant dans le réseau.
1.3 Fonctionnement d'un système H.323
Dans le but d'expliciter le fonctionnement d'un système H.323,
nous étudions brièvement ci-après quelques cas de figure, en ren-
voyant le lecteur intéressé à la recommandation H.323, qui présente
de manière détaillée un ensemble de scénarios de fonctionnement, en
point-à-point ou multipoint, avec ou sans gatekeeper, au sein d'une
zone unique ou entre plusieurs zones distinctes, etc.
1.3.1 Appel point-à-point
Le scénario le plus simple est probablement un appel entre deux
terminaux dépourvus de gatekeepers. Dans ce contexte, aucun trafic
RAS n'est généré, et la communication H.225.0 débute par l'ouver-
ture d'une connexion TCP sur un port « bien connu » (le port 1720),
puis par l'émission d'une requête d'établissement Q.931 SETUP, qui
reçoit en première réponse un message ALERTING, indiquant que le
destinataire est convié à répondre, suivi d'un message CONNECT.
Ce premier échange permet aux entités de définir des ports dynami-
ques utilisés pour la connexion H.245, qui débute alors (à moins que
le mécanisme de Fast Connect n'ait été utilisé) et permet l'ouverture
des flux RTP (par échange d'adresses et de numéros de port pour ces
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
IP 2 960 − 6 © Techniques de l’Ingénieur, traité Réseaux
flux) et la transmission des données audio, vidéo, et/ou téléinformati-
ques.
Lorsqu'un gatekeeper est inclus dans le système, les équipements
terminaux précèdent le premier échange H.325.0 d'un dialogue RAS
avec ce gatekeeper, afin de s'enregistrer et d'obtenir autorisation
d'appel et bande passante nécessaire. Si le gatekeeper joue le rôle
de « routeur » pour la signalisation, les messages H.225.0 et/ou
H.245 transitent alors par lui, ce qui peut nécessiter éventuellement
la fermeture et la réouverture d'une tentative d'établissement. Cela
se produit par exemple lorsqu'un terminal émet un SETUP vers un
autre terminal qui est géré strictement par son gatekeeper. Dans ce
cas, le second terminal répond par un message FACILITY, indiquant
au premier de clore sa tentative et de se connecter plutôt au gate-
keeper pour le joindre.
1.3.2 Conférence multipoint
Une session multipoint est gérée de façon homogène par un MC
(Multipoint Controller), qu'elle ait été prévue à l'avance ou qu'elle
résulte d'un appel point-à-point élargi à de nouveaux participants :
— dans le premier cas, le MC est généralement situé dans un équi-
pement spécial (MCU ou gatekeeper particulier), chargé de gérer la
conférence. Les participants se connectent directement à cette
entité ;
— dans le second cas, le MC est l'équipement désigné par le jeu
des mécanismes d'élection H.245 ; ce MC a la capacité d'inviter de
nouveaux participants (éventuellement redirigés sur lui par les partici-
pants déjà présents recevant un appel).
L'établissement des communications dans un scénario multi-
point est analogue au cas point-à-point, en ce qui concerne le niveau
H.225.0 (chaque participant établit un appel avec le MC) ainsi que le
trafic RAS qui est local à chaque zone. En ce qui concerne les échan-
ges H.245, et dans le cas d'une session décentralisée, le MC est
chargé de distribuer des adresses multicast pour chacun des flux
media, et les terminaux ouvrent des canaux logiques vers le MC en
utilisant ces adresses multicast (adresses IP de classe D). Dans le cas
centralisé, les équipements terminaux négocient leurs canaux logi-
ques avec le MC uniquement.
1.4 Services avancés offerts par H.323
L'architecture H.323 intègre un certain nombre de fonctionnalités
de contrôle d'appel avancé, par le biais des recommandations
H.450.x. Le mécanisme d'acheminement des messages qui mettent
en œuvre ces fonctionnalités prévoit leur intégration dans les messa-
ges H.225.0 échangés, en utilisant le message FACILITY
lorsqu'aucune information H.225.0 particulière n'est à transmettre.
La recommandation H.450.1 présente ce mécanisme ainsi que plu-
sieurs paramètres génériques, utilisés dans la mise en œuvre des
services avances H.450.x. Ces derniers sont :
— service de transfert d'appel, où un usager A, appelé par B, trans-
fère l'appel vers un usager C ; applicable que les appels A ↔ B et A
↔ C soient déjà établis ou non (recommandation H.450.2) ;
— services de déviation d'appel : renvois d'appel inconditionnel,
sur occupation, sur absence de réponse, transfert d'appel (call
deflection) avant que l'appel ne soit établi (recommandation
H.450.3) ;
— service de mise en attente du correspondant ; il est possible de
lui fournir un message d'attente audio et/ou vidéo (recommandation
H.450.4) ;
— service complémentaire d'appel en attente (« signal d'appel »,
recommandation H.450.6) ;
— des services non normalisés, spécifiques à un fabricant.
_________________________________________________________________________________________________________________ TÉLÉPHONIE INTERNET
1.5 H.332 (large scale)
La recommandation H.332 est une adjonction récente au monde
H.323 qui répond au problème des conférences de grande échelle, où
le nombre de participants est très élevé. Son approche considère
qu'une telle conférence est en fait constituée d'un petit groupe de
participants formant un « noyau » de conférenciers, entouré par une
large audience formée de participants passifs. Le noyau est alors mis
en œuvre par les mécanismes traditionnels de H.323 pour les appels
multipoints, tandis que l'audience, arbitrairement grande, de specta-
teurs passifs, est gérée par H.332, qui suppose une communication
en multicast uniquement, et en écartant toute notion de négociation
de capacités. L'hypothèse de base est ici que ce type d'événement
est prévisible et par conséquent annoncé à l'avance. Il est alors envi-
sageable d'assortir cette annonce des informations sur la nature des
flux prévus, leur mode de codage etc. Toutes ces informations sont
par conséquent annoncées au préalable selon le format préconisé par
la communauté Internet, et décrit dans le protocole SDP (Session
Description Protocol).
1.6 H.235 (sécurité)
Autre ajout récent à l'éventail des normes H.323, la recommanda-
tion H.235 s'intéresse au domaine crucial de la sécurité, en fournis-
sant un cadre général pour la mise en œuvre de procédures
d'authentification, de certification, de chiffrement de la signalisation
et des données, etc. Ce cadre est applicable aux communications en
point-à-point ou en multipoint, et recouvre l'ensemble des phases
d'une communication H.323 :
— signalisation RAS : dans ce contexte, les algorithmes ISO
d'authentification peuvent être exploités, à condition qu'il existe un
secret partagé (un mot de passe) ou un mécanisme à clé publique
commune. Dans le cas contraire, un échange de type Diffie/Hellman
peut être mis en œuvre en vue d'établir une telle clé ;
— établissement et contrôle d'appel (H.225.0, Q.931) : la recom-
mandation H.235 propose l'utilisation des protocoles de sécurité
TLS (Transport Layer Security) [3] ou IPSEC (IP SECurity) [4] définis
par l'IETF. Ces protocoles peuvent alors fournir un service d'authen-
tification, de confidentialité et d'intégrité des messages Q.931 ;
— contrôle de média et de conférence (H.245) : les messages
H.245 peuvent également bénéficier des services de sécurité TLS ou
IPSEC. Les échanges H.245 permettent alors de négocier et d'échan-
ger des clés permettant le chiffrement des flux média. Cette dernière
opération est réalisée dans les flux RTP, ce qui permet une assez
grande flexibilité et de bonnes performances.
H.235 prévoit le rafraîchissement dynamique des clés, ce qui per-
met, dans le cadre d'une conférence multipoint, la résorption d'un
trou de sécurité, ainsi que l'expulsion d'un participant donné. Il faut
encore noter que la recommandation ne propose pas de choix préa-
lable (ou service par défaut) pour les mécanismes de sécurité, du
fait essentiellement de l'absence de consensus à l'échelle internatio-
nale. Tous les aspects de la sécurité H.323 sont de ce fait négociables
entre les équipements.
Qualité
Media Signalisation
de service
RSVP RTCP RTP RTSP SIP SDP/SAP
UDP TCP
IP + IP multicast
Figure 4 – Architecture de communication multimédia de l’IETF
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Réseaux
2. Approche Internet
À l'instar de l'ITU-T, la communauté Internet et plus précisément
l'Internet Engineering Task Force (IETF) avec son groupe de travail
Multimedia Multiparty Session Control (MMUSlC) a défini un cadre
général pour la communication multimédia dans le réseau Internet.
Ce cadre est présenté dans un document non encore finalisé [7].
L'approche est analogue à celle de l'ITU-T, au sens où l'architecture
préconisée (figure 4) dépasse le cadre de la téléphonie IP pour
englober les communications audiovisuelles, point-à-point et multi-
point, voire de diffusion massive, etc.
On retrouve dans cette architecture les protocoles RTP et RTCP,
exploités pour le transport de l'information audiovisuelle en point-à-
point ou en multipoint et présentés ci-avant (§ 1.2.4). L'aspect qua-
lité de service est couvert d'une part par RTCP, pour ses capacités à
mesurer les paramètres de performance d'une communication RTP
par le jeu des rapports d'émission et de réception, et d'autre part par
RSVP (Resource Reservation Protocol), qui est un protocole de
réservation de ressources, autorisant la fourniture de garanties de
service, strictes ou statistiques, pour une session de communication
particulière ou plus grossièrement pour un agrégat de communica-
tions. En matière de téléphonie sur IP, les protocoles les plus impor-
tants sont SIP (Session Initiation Protocol), SDP (Session
Description Protocol) et dans une moindre mesure RTSP (Real-Time
Stream control Protocol). Ces protocoles réalisent une fonction de
signalisation dans cette architecture, à l'instar des composantes
H.323 vues précédemment. RTSP, rattaché à cette même fonction,
est un protocole qui rend possible le contrôle à distance d'un ser-
veur audiovisuel (commandes de type magnétoscope sur un ser-
veur vidéo par exemple). À ce titre, il n'intéresse pas spécifiquement
le domaine de la téléphonie, mais peut cependant être exploité dans
ce cadre comme nous le verrons par la suite.
Il faut enfin noter que tous les protocoles mis en jeu dans cette
architecture ont été conçu par l'IETF dans une optique multipoint
aussi bien que point-à-point. De ce fait, la fourniture de services de
communication multimédia multipoints est intrinsèquement sup-
portée par cette architecture.
2.1 SIP
Le protocole SIP [8] découle d'une approche dédiée à la signalisa-
lion téléphonique sur Internet au sein du groupe MMUSIC. Il intègre
les fonctionnalités de transformation d'adresse, de localisation
d'usager, d'établissement et de gestion des appels (incluant la négo-
ciation de capacités analogues à H.323).
Ce protocole est détaillé dans l'article [IP 2 925], auquel nous
prions le lecteur de se reporter pour prendre connaissance des con-
cepts et des mécanismes mis en jeu par SIP.
2.2 SDP
Le protocole SIP spécifie les modalités de communication entre uti-
lisateurs en termes de localisation, de nommage et d'adressage, mais
par contre ne décrit pas directement les flux multimedia mis en jeu
par cette communication. Pour ce faire, il s'appuie sur SDP [9], pro-
tocole de description de session véhiculant les informations
suivantes :
— le nom de la session de communication ;
— son but (ou son objet) ;
— les dates et heures d'activité de cette session ;
— les divers flux audio, vidéo ou autres qui la composent ;
— tout paramètre caractérisant ces flux (adresses, ports, formats,
etc.) ;
IP 2 960 − 7
TÉLÉPHONIE INTERNET _________________________________________________________________________________________________________________
— de façon optionnelle, de l'information additionnelle, précisant
par exemple la bande passante requise ou une information de contact
de la personne responsable.
2.2.1 Spécification SDP
Une description de session SDP est une information textuelle, con-
sistant en lignes de caractères de la forme type = valeur. La descrip-
tion est structurée en deux zones successives, la première étant
dévolue à la session elle-même et la seconde détaillant les flux indivi-
duels qui la composent. Le champ type renferme un caractère unique
dont la signification dépend de la zone considérée. Le champ valeur
est une chaîne de caractère dont le format dépend du type d'infor-
mation.
Exemple : la figure 5 présente un exemple de spécification SDP. La
session décrite, en SDP version 1 (v=0), est initiée par l'utilisateur
Dupont (o pour owner) sur sa machine citrouille. La ligne débutant par
« c= » mentionne des paramètres applicables à tous les médias qui
suivent. Ceux-ci sont introduits par le type « m= ». Le premier flux
décrit est audio, il utilise le port 49170, le protocole RTP, et sera encodé
(ligne suivante) en PCM « µ-law » à 8 Ko/s. Le second flux est vidéo,
sur le port 51372, encodé en H.261 à 720 Kbit/s.
2.2.2 Usage dans le cadre SIP
Lorsqu'une spécification SDP est utilisée pour l'établissement
d'un appel SIP, elle permet la négociation de capacités entre l'appe-
lant et l'appelé. La description est insérée dans le corps de la
requête INVITE. Le destinataire l'exploite pour déterminer les flux
que souhaite établir l'appelant et la complète, en respectant l'ordre
de description des media (les lignes « m= »), avec ses propres
vœux.
Exemple : ainsi l'utilisateur Martin, recevant la description de la
figure 5, pourra retourner la description de la figure 6. Dans cet exem-
ple, Martin accepte le flux audio proposé par Dupont, et propose en
retour un flux audio codé en PCM « A-law » à 8 Ko/s. Il refuse par
ailleurs le flux vidéo, ce qui se traduit par le numéro de port mis à zéro
dans la description.
v=0
o=dupont 2890844526 2890844526 IN IP4 citrouille.client.net
s=exemple
e=dupont@client.net
c=IN IP4 citrouille.client.net
m=audio 49170 RTP/AVP O
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
Figure 5 – Spécification SDP
v=0
o=martin 2890842807 2890842807 IN IP4 vorace.filiale.com
s=exemple
e=martin@entreprise.com
c=IN IP4 vorace.filiale.com
m=audio 47920 RTP/AVP 0 1
a=rtpmap:0 PCMU/8000
a=rtpmap:1 PCMA/8000
m=video 0 RTP/AVP 31
Figure 6 – Spécification SDP en retour
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
IP 2 960 − 8 © Techniques de l’Ingénieur, traité Réseaux
2.3 RTSP
Le protocole RTSP (Real-Time Streaming Protocol) [6] vise à four-
nir à un site client des capacités de pilotage d'un serveur de contenu
distant. Dans le contexte de la téléphonie Internet, ces capacités ont
un intérêt dans deux cas :
— usage de boîtes vocales offrant une fonctionnalité analogue au
répondeur téléphonique, les fonctions pilotables par RTSP incluent
alors l'enregistrement et la consultation des messages vocaux stoc-
kés dans la boîte ;
— intégration de machines dans une communication, à des fins
de consultation (bases de connaissances), d'enregistrement (d'une
conférence téléphonique) ou des services encore à imaginer (tra-
duction et transcription simultanée...).
Les ressources qui peuvent être pilotées à distance au moyen de
RTSP sont identifiées grâce à une RTSP-URL, analogue aux SIP-URL
(cf. [Doc. IP 2 925]). Ainsi, la chaîne de caractères rtsp://ser-
veur.entreprise.com/prés/bilan décrit une ressource « bilan », qui
peut être composée d'audio, de vidéo et d'autres médias, et dont le
déroulement est contrôlable avec RTSP. À l'instar de SIP, RTSP est un
protocole où les messages sont textuels et d'un format assez proche
de HTTP. Il eût été possible en fait de mettre en œuvre ces fonction-
nalités avec HTTP ; cependant, les réflexions sur RTSP ont abouti à
mettre en évidence des différences notables, qui ont conduit à l'éla-
boration du protocole, distinct de HTTP. En premier lieu, bien qu'il
n'existe pas de notion de connexion dans RTSP, le serveur contrôlé
doit mettre en place un contexte de session (ou état). Ensuite, les
données sont transmises « hors-bandes », c'est-à-dire que le flux
d'informations contrôlé par RTSP et les données (requêtes/répon-
ses) de contrôle ne sont pas mélangés mais au contraire transmis
par des moyens distincts. Ce point améliore la versatilité des proto-
coles, en n'imposant pas, pour la transmission des données audio/
vidéo, l'usage d'un protocole précis. Enfin, RTSP introduit un certain
nombre de nouvelles requêtes, spécifiques à son activité, et qui ne
trouveraient donc pas leur place dans HTTP. Les principales requê-
tes sont les suivantes :
— DESCRIBE : requête envoyée pour obtenir une description
d'une ressource (media disponibles et leurs types, codage, ports...) ;
— ANNOUNCE : permet à un client d'enregistrer une ressource
auprès d'un serveur ; permet à un serveur de mettre à jour, dynami-
quement, la description d'une ressource auprès d'un client ;
— SETUP : initialise une session, en fournissant tous les paramè-
tres d'établissement des flux media ;
— PLAY : requête indiquant au serveur de débuter la transmis-
sion d'une ressource ; cette requête peut véhiculer une information
temporelle précisant quelle portion de la ressource doit être jouée ;
— PAUSE : interrompt la transmission d'une ressource ;
— TEARDOWN : stoppe la transmission d'une ressource et ferme
la connexion associée ;
— RECORD : requête indiquant au serveur de débuter l'enregis-
trement d'un flux, stocké sous la RTSP-URL mentionnée dans la
requête ;
— REDIRECT : informe un client qu'il trouvera la ressource spéci-
fiée sur un autre serveur.
2.4 MEGACO & IPTEL
Jusqu'à présent, la notion de passerelle n'a pas été abordée dans
le contexte SIP. Cette notion est en fait traitée par des groupes de tra-
vail distincts de MMUSIC, IPTEL, (IP Telephony) et MEGACO (Media
Gateway Control). Nous passons en revue ci-après les différents
aspects abordés par ces deux groupes.
_________________________________________________________________________________________________________________ TÉLÉPHONIE INTERNET

2.4.1 MEGACO MEGACO définit plusieurs protocoles permettant l'interopération

de ces composants, et particulièrement le contrôle distant des opé-
rations décrites sur la figure 7, en intégrant différentes signalisa-
Le groupe MEGACO a défini une architecture dans laquelle les tions issues de la téléphonie traditionnelle. Cette spécification est
différents composants d'une passerelle peuvent être physique- commune au groupe de travail MEGACO et à l'ITU-T, où elle consti-
ment disjoints (passerelle de signalisation, passerelle de media, tue une proposition de recommandation nommée H.248 [10].
contrôleur de passerelle ; le découpage est ici analogue à celui des
L’un de ces protocoles est MGCP, Media Gateway Control Proto-
passerelles H.323 (cf. § 1.1.2). L'intérêt premier de cette approche
col, qui met en place les procédures par lesquelles un contrôleur de
est de permettre une vision homogène d'un équipement qui peut
passerelle pilote une ou plusieurs passerelles. MGCP n’existe qu’à
prendre des formes très diverses. Une passerelle peut en effet être
l’état de draft (brouillon) et il est vraisemblable qu’il se trouve inté-
un équipement lourd, capable de router plusieurs dizaines de mil-
gré aux spécifications futures d’un MEGACOP (MEGACO Protocol),
liers de connexions simultanées, tout autant qu'un équipement
en cours d’élaboration.
très succinct, permettant par exemple l'accès au réseau Internet à
partir d'une ligne analogique (modem). Dans ce dernier cas, il est
souhaitable de dissocier les fonctionnalités de passerelles, afin par 2.4.2 TRIP
exemple de concentrer dans un équipement amont le contrôle de
plusieurs passerelles « légères ». Cette architecture définit princi- Proposé par le groupe de travail IPTEL, TRIP (Telephony Routing
palement deux notions : over IP) répond au problème de localisation d’une passerelle : étant
donné une adresse distante (numéro de téléphone, alias H.323, SIP-
— la notion de terminaisons, qui sont des points de connexion
URL...) et un ensemble d’attributs, qui sont autant de contraintes
avec un réseau et une signalisation particulière (H.323, réseau télé-
précisées par l’usager, trouver une passerelle capable de se connec-
phonique commuté, réseau numérique à intégration de service,
ter à cette adresse en satisfaisant aux contraintes. L’approche TRIP
réseau GSM...) ;
prévoit des serveurs de localisation, ayant connaissance des passe-
— la notion de contexte, qui représente une association entre relles disponibles dans un domaine administratif et des serveurs de
plusieurs terminaisons. signalisation, qui assurent la propagation et le routage de la signali-
sation d’appel (gatekeepers dans H.323, serveurs proxy pour SIP).
Nous illustrons ces notions avec la figure 7. Du point de vue TRIP vise à établir des tables de routage, par coopération entre les
d'une passerelle donnée (cas 1), un appel simple consiste en un serveurs de localisation de chaque domaine, de façon très sembla-
contexte associant deux terminaisons. La survenue d'une requête ble aux techniques de routage mises en œuvre dans l’internet (pro-
d'établissement génère la création d'un second contexte, dans tocole BGP, Border Gateway Protocol). En effet, l’établissement de
lequel cette requête est mise en attente, et qui suscite l'invocation routes pour les appels de téléphonie est analogue au calcul de route
d'un signal d'appel. L'usager choisit de prendre cet appel, ce qui pour les paquets IP, avec les distinctions suivantes :
provoque (cas 2) la mise en attente de son correspondant dans le
— les routes établies pour la téléphonie sont virtuelles, puisque
premier contexte et l'établissement de la communication dans le
c'est finalement le réseau IP qui achemine les paquets
second.
téléphoniques ; par conséquent, la topologie peut différer considé-
rablement de celle du réseau IP support ;
— le coût d'une route est très vraisemblablement plus complexe
dans le cas des appels téléphoniques, car il dépend du plus de para-
contexte 1 mètres que la simple métrique des réseaux IP (coût associé à une
Usager 1 liaison avec le RTC, coût du la qualité de service offerte, etc.) ;
terminaison T1 terminaison T2
Ligne RTC Flux RTP Usager 2 — on peut associer à une « route téléphonique » plusieurs attri-
signal buts la qualifiant, tels que les signalisations supportées, les services
d'appel avancés offerts à/par la destination, les formats de codage disponi-
bles à la destination, etc.
TRIP constitue une proposition de norme actuellement, succédant
contexte 2 en cela à GLP (Gateway Location Protocol).
terminaison T3
Ligne RTC Usager 3
2.4.3 Traduction d'adresses E.164
mise
Cas 1 en attente À l’étude, principalement dans le groupe de travail ENUM de
l’IETF, la traduction d’adresse E.164 est une tâche importante. Elle
consiste à intégrer la numérotation téléphonique traditionnelle,
lorsqu’elle se conforme au standard E.164 de l’ITU-T, au sein du ser-
vice de nommage de l’Internet (Domain Name Service, DNS).
L’usage majeur d’une telle intégration est de permettre à un appe-
contexte 1 lant d’identifier au préalable les services supportés par l’appelé.
terminaison T2 La norme E.164 définit la structure de la numérotation publique
Flux RTP Usager 2 sous forme hiérarchique. Un numéro de téléphone débute ainsi par
mise un code de pays, suivi d’une partie dont la signification est natio-
en attente nale, puis une sous-adresse. Le code pays peut comporter de un à
trois chiffres, le code national peut avoir une longueur arbitraire et la
longueur maximale d’un numéro de téléphone est de quinze chif-
contexte 2 fres.
Usager 1 terminaison T3
terminaison T1
Ligne RTC Ligne RTC Usager 3 L’insertion de cette numérotation dans le DNS passe par le décou-
page des numéros en chiffres, qui sont chacun traités comme un
identifiant de domaine DNS. Le résultat est ensuite préfixé à la
Cas 2 chaîne « e164.int », qui identifie le domaine de plus haut niveau
(figure 8). Le mécanisme de délégation propre au DNS permet de
Figure 7 – Exemple MEGACO confier des blocs de numéros aux divers acteurs qui les gèrent (opé-

Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Réseaux IP 2 960 − 9
TÉLÉPHONIE INTERNET _________________________________________________________________________________________________________________
Plus haut niveau du DNS :
1.e164.int. IN NS ns.NANP.phone.net. ; pour les USA
3.3.e164.int. IN NS ns.FR.phone.net. ; pour France
2.7.9.e164.int. IN NS ns.il.phone.net. ; pour Israël
...
En France :
0.3.3.e164.int IN NS ns.Fournisseur1.net ; pour l'opérateur qui gère le 0
1.3.3.e164.int IN NS ns.Fournisseur2.net ; pour l'opérateur qui gère le 1
...
Chez le fournisseur1 :
*.4.3.2.1.1.0.3.3.e164.int PTR Abonné1.com ; qui a les nos 01 12 34 xx xx
*.5.4.3.2.1.0.3.3.e164.int PTR Abonné2.com ; qui a les nos 01 23 45 xx xx
...
Requêtes DNS :
No de téléphone : 01 12 34 56 78
Requête pour un PTR sur le domaine 8.7.6.5.4.3.2.1.1.0.3.3.e164.int
Résultat : PTR = Abonné1.com
service "voicemail" recherché
Requête pour un SRV : voicemail.8.7.6.5.4.3.2.1.1.0.Abonné1.com
Résultat : SRV = ldap.Abonné1.net
Figure 8 – Numéro E.164 dans le DNS
rateurs, entreprises, voire particuliers), afin de renseigner les servi-
ces supportés par ces numéros.
Les requêtes DNS portant sur un numéro de téléphone peuvent
alors être effectuées en convertissant ce numéro comme indiqué ci-
dessus, puis en opérant une requête traditionnelle sur le domaine
ainsi identifié.
Le fait de traiter chaque chiffre comme un domaine DNS a plu-
sieurs avantages. En premier lieu, cela permet de s’affranchir de la
connaissance du découpage du numéro, en fonction des longueurs
de zones variables. Ensuite, il est possible d’opérer une recherche de
façon très efficace, ne nécessitant pas de balayage dans un ensem-
ble d’information. Enfin, une telle approche est robuste aux renumé-
rotations futures.
Ce premier mécanisme est complété par deux autres niveaux,
dans la proposition du groupe ENUM. Le premier niveau complé-
mentaire tire parti des enregistrements de type SRV (localisation de
service) dans le DNS pour obtenir de l’information sur les services
associés à un domaine. Ces enregistrements contiendront eux-
mêmes une référence à un service d’information externe (par exem-
ple LDAP, Lightweight Directory Access Protocol), qui constitue ainsi
le dernier niveau de la hiérarchie.
Puisque dans la proposition, le numéro de téléphone complet est
un domaine, il devient possible d’affecter des descriptions de servi-
ces à chaque numéro intégré dans le DNS. Dans la figure 8, les deux
premiers niveaux sont illustrés par deux requêtes DNS. La première
vise à identifier le serveur de nom susceptible de renfermer les
informations de service et la seconde interroge ce serveur au sujet
d’un service « voicemail ». L’enregistrement SRV permet enfin
d’interroger un serveur LDAP qui fournira les informations nécessai-
res à l’invocation du service, pour ce numéro de téléphone.
3. Comparaison H.323/SIP
Outre le fait que la technologie H.323 est actuellement beaucoup
plus répandue que celle de l’IETF, il existe de nombreux points de
comparaison entre les deux architectures.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
IP 2 960 − 10 © Techniques de l’Ingénieur, traité Réseaux
3.1 Philosophie des deux approches
Poursuivant un même but, en termes de signalisation d’appels
téléphoniques et plus généralement multimedias, les approches de
l’ITU-T et de l’IETF se différencient considérablement dans la philo-
sophie qu’elles adoptent.
La démarche de l’ITU-T, bien que fondée sur les normes qu’elle a
antérieurement définies dans le cadre du réseau numérique à inté-
gration de services, définit globalement un ensemble de nouveaux
protocoles, dédiés à la téléphonie Internet (au sens large), ainsi que
les équipements qui mettent en œuvre ces protocoles. Par con-
traste, l’approche de l’IETF est celle de la réutilisation maximale :
seul le protocole SIP est véritablement dédié à la signalisation
d’appels téléphoniques, et encore il reprend largement les concepts
définis antérieurement pour le World Wide Web, au travers de son
protocole HTTP. Les autres composants d’un système SIP (RTSP,
RTP, RTCP, SDP, RSVP...) proviennent de travaux connexes de l’IETF
et sont intégrés à l’architecture de communication globale élaborée
par la communauté Internet au même titre que SIP. L’approche SIP
vise en fait à fournir un nouveau composant dans une architecture
très modulaire, alors que l’approche H.323 spécifie une pile de pro-
tocoles implémentant totalement les fonctionnalités recherchées.
L’aspect communications multipoints est également traité diffé-
remment par ces deux approches. Dans le contexte H.323, des équi-
pements dédiés sont nécessaires (MC et MCU intégrés ou non aux
équipements physiques), alors que le système SIP est globalement
pensé en terme de multipoint, suivant en cela toute la démarche de
normalisation de l’IETF.
Sur le plan de la sécurité, les philosophies semblent s’inverser : là
où H.323 prône la réutilisation des technologies Internet, par exploi-
tation pure et simple des approches IPSEC ou TLS (sécurité de
niveau réseau ou transport), SIP met en place des techniques de
chiffrement de plus haut niveau (par coopération entre serveurs
adjacents), qui semblent nécessaires pour accroître la sécurité glo-
bale du système.
3.2 Points de comparaison
3.2.1 Complexité
Sur le plan technique, la différence la plus largement évoquée
entre les deux approches concerne leurs complexités relatives. Il
faut noter par exemple qu’en terme de volume de documentation,
H.323 totalise environ cinq fois plus de pages que l’approche SIP (en
y incluant des normes connexes). En termes opératoires, la com-
plexité associée à SIP est analogue à celle des technologies du Web
(technologie client-serveur), tandis que la complexité de mise en
œuvre d’H.323 est celle d’une pile de protocoles (cette complexité
associée à H.323 est particulièrement mise en évidence lors de réu-
nions Interop, visant à tester l’interopérabilité des développements
entrepris par divers acteurs : les implémentations présentées à cette
occasion sont très en retard sur la normalisation). Les messages,
nettement plus variés dans le monde H.323, sont encodés en ASN.1
(Abstract Syntax Notation 1), ce qui ajoute des procédures de traite-
ment assez lourdes en comparaison du traitement des messages
textuels de SIP. Qui plus est, les messages H.323 sont globalement
plus gros que leurs équivalents SIP, malgré la perte de place induite
par la syntaxe textuelle de ce dernier. La nécessité ou non de conser-
ver un contexte de communication est aussi un facteur de com-
plexité H.323, avec ses canaux de contrôle utilisant TCP, impose
essentiellement que chaque équipement conserve un contexte de la
connexion en cours, ce qui n’est pas le cas de SIP, où chaque tran-
saction (requête/réponse) est indépendante des autres.
_________________________________________________________________________________________________________________ TÉLÉPHONIE INTERNET
3.2.2 Flexibilité
Un système de téléphonie Internet, pensé pour un déploiement
mondial et l’émergence d’applications non encore envisagées, se
doit être flexible afin de suivre les évolutions probables des besoins.
L’évolution de H.323 passe par la définition de nouvelles versions
de la norme, ajoutant des fonctionnalités supplémentaires, offrant
des procédures simplifiant la signalisation, etc., tout en respectant
la compatibilité ascendante (une nouvelle version est compatible
avec les versions antérieures).
H.323 autorise l’intégration d’extensions propriétaires, grâce à
des champs « paramètre non standard » insérés dans la syntaxe
ASN.1, identifiés par un code de fabricant suivi du paramètre opa-
que qu’il souhaite ajouter. Ces extensions sont ainsi limitées aux
endroits dans la syntaxe ASN.1 où elles ont été prévues et la con-
trainte de compatibilité ascendante ne permet pas de modifier cette
syntaxe. Cela peut être problématique lorsque, par exemple, une
nouvelle valeur pour un paramètre existant est souhaitée, et
qu’aucun champ d’extension propriétaire n’est disponible. Par
ailleurs, l’opacité de ces champs limite considérablement les possi-
bilités d’interopération entre équipements hétérogènes. L’approche
de l’IETF est différente et passe par l’ajout de types de champs d’en-
têtes dans les messages. Le comportement par défaut étant d’igno-
rer un en-tête non reconnu, la compatibilité ascendante est automa-
tiquement préservée. Ces nouveaux en-têtes doivent être avalisés
par l’IANA (Internet Assigned Numbers Authority), ce qui procure
aux fabricants une moins grande liberté de manœuvre, mais permet
l’interopérabilité.
3.3 Services
Les services de téléphonie avancés offerts par H.323 et SIP sont
analogues, quoique plus complets dans le cadre H.450.x (l’ajout de
nouveaux service est constant dans les deux communautés, il est
donc difficile d’opérer une comparaison). Sur le plan de l’échange et
de la négociation de capacités, les fonctionnalités apportées par
H.323 sont nettement plus riches, grâce aux mécanismes de H.245,
plus aboutis que le simple usage de SDP.
Le contrôle d’appel par un tiers (usager A établissant et contrôlant
une communication entre deux usagers B et C) n’est disponible que
dans l’approche SIP.
Enfin, sur le plan de la qualité de service des flux audiovisuels
échangés, les deux approches font référence à des mécanismes
externes, tels que RSVP. Notons que la version 3 de H.323, non
encore finalisée, prévoit la négociation de paramètres de qualité de
service lors de l’établissement d’appel. Cette négociation qui n’est
pour l’instant pas prévue dans SIP pourrait être mise en œuvre au
moyen de SDP.
4. Enjeux de la téléphonie
Internet
Le domaine encore jeune de la téléphonie Internet reçoit une
attention considérable de la part de nombreux acteurs du secteur
des télécommunications. Le fait n’est pas surprenant dans la
mesure où ce domaine est considéré comme précurseur de nouvel-
les modalités de communications interpersonnelles assistées par
ordinateurs. Dans ce contexte, l’Internet constitue le medium le plus
naturel, car, réseau unique véhiculant tous types de données, il
répond au souci d’intégration de services et offre l’opportunité de
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Réseaux
réductions massives des coûts d’infrastructures. Sur le plan applica-
tif, l’usage d’Internet permet aisément de combiner communica-
tions vocales et autres modes de communication, synchrones ou
non : les navigateurs World Wide Web peuvent ainsi s’interfacer aux
applications de téléphonie pour permettre à un usager d’initier une
communication simplement en cliquant sur un hyperlien particulier
(appel d’un agent commercial pour un complément d’information
ou une commande par exemple). Les applications partagées, de
type travail coopératif, peuvent inclure des mécanismes similaires
permettant une synchronisation à géométrie variable de l’exécution
des tâches. Les applicatifs destinés à la surveillance en général
(monitoring) seront susceptibles de joindre un opérateur humain en
cas de besoin. L’ordinateur individuel (éventuellement réduit à un
produit nomade) pourra constituer, de par ses potentialités en terme
d’interface homme-machine, le point central du réseau de commu-
nications tissé par tout un chacun, filtrant les appels en leur assi-
gnant une priorité (fonction de l’appelant, du sujet, de la localisation
géographique, ou tout autre critère...), les routant vers une messa-
gerie texte, vocale ou vidéo, initiant des sessions de conférence à la
demande, invoquant un serveur de contenu, etc.
L’émergence et le succès de cet ensemble d’applications futures
requiert vraisemblablement de l’Internet qu’il évolue selon plu-
sieurs axes [2]. En premier lieu, la qualité globale, perçue par l’usa-
ger, des services de communication, doit tendre vers les standards
actuels de l’industrie téléphonique. Qualité perceptuelle du son, qui
découle du débit disponible et de ses variations, du taux d’erreurs
subi par la transmission, du délai d’acheminement des paquets de
données. Qualité au sens plus large aussi, englobant les notions de
disponibilité, de probabilité d’interruption d’une communication en
cours et de rejet ou de non aboutissement d’une requête d’établis-
sement de connexion, délai d’établissement, facilité d’adressage et
services d’annuaires associés, ou encore capacité du système à
trouver un correspondant sur le réseau s’il y est raccordé. Nombre
de ces critères sont du ressort de l’opérateur applicatif, mais cer-
tains peuvent bénéficier de l’adjonction à l’Internet actuel de méca-
nismes gérant la qualité de service au niveau réseau de paquets
(différentiation de services par exemple). La tarification de ce ser-
vice amélioré est également à mettre en place, puisqu’elle consti-
tuera vraisemblablement l’élément régulateur de la fourniture de
qualité de service. L’accroissement de la fiabilité de certains équipe-
ments dans le réseau peut aussi répondre à certains critères. Sur un
plan différent, il faut noter que de nombreuses applications de com-
munication interpersonnelle requièrent de l’usager qu’il soit joigna-
ble, c’est-à-dire connecté au réseau et susceptible de prendre un
appel, à tout instant. À l’heure actuelle, de nombreux usagers
d’Internet, utilisant un accès tarifé à la durée, ne rentrent pas dans
cette description, et il faut envisager une évolution des modalités
d’accès au réseau de paquets (accès forfaitaire illimité dans le
temps).
Les normes doivent elles aussi évoluer, pour intégrer des fonc-
tionnalités plus élaborées et s’ouvrir, en terme d’interopérabilité.
Dans le monde H.323, de nombreux axes sont actuellement à
l’étude ; citons le développement de protocoles pour l’interaction de
gatekeepers, intra ou inter-domaines, l’usage des technologies
H.323 dans les backbones ou cœurs de réseaux téléphoniques,
l’intégration de procédures pour le contrôle d’équipement à dis-
tance (pilotage d’une caméra, prise de contrôle d’une application...),
l’adjonction de transfert de document de type fax, ou encore la con-
ception de Management Information Bases (MIB) dédiées aux pro-
tocoles et aux systèmes H.323, et permettant leur administration à
l’aide d’outils standards de gestion de réseau. Côté SIP, les dévelop-
pements les plus intenses concernent la notion de passerelle, avec
MEGACO et IPTEL. L’aspect tarification est aussi à l’étude, de même
que le transport de la signalisation du réseau téléphonique com-
muté par un réseau IP (backbone IP).
IP 2 960 − 11