Vous êtes sur la page 1sur 11

Tlphonie Internet

par

Franois TOUTAIN
Docteur s sciences
Ingnieur de recherche
cole Nationale Suprieure des Tlcommunications de Bretagne

1.
1.1
1.2
1.3
1.4
1.5
1.6

Normes de l'ITU-T ....................................................................................


Recommandation H.323..............................................................................
Protocoles H.323 ..........................................................................................
Fonctionnement d'un systme H.323 ........................................................
Services avancs offerts par H.323 ............................................................
H.332 (large scale) .......................................................................................
H.235 (scurit) ............................................................................................

2.
2.1
2.2
2.3
2.4

Approche Internet....................................................................................
SIP .................................................................................................................
SDP ...............................................................................................................
RTSP .............................................................................................................
MEGACO & IPTEL ........................................................................................

7
7
7
8
8

3.
3.1
3.2
3.3

Comparaison H. 323/SIP ........................................................................


Philosophie des deux approches................................................................
Points de comparaison................................................................................
Services ........................................................................................................

10
10
10
11

4.

Enjeux de la tlphonie Internet..........................................................

11

Pour en savoir plus ...........................................................................................

IP 2 960 - 2

Doc. IP 2 960

ne des principales ides-force l'uvre dans le secteur des tlcommunications depuis plus de quinze ans est l'intgration de services. Ce concept
vise permettre, dans un rseau de communication unifi, la coexistence de
communications htrognes aussi bien en terme de contenu qu'en terme de
contraintes de transmission (dbits, dlais, pertes, critres de fiabilit, critres
de trafics...) et a t le prlude aux technologies du RNIS (rseau numrique
intgration de services) ou de l'ATM (Asynchronous Transfer Mode). Le domaine
en pleine expansion de la tlphonie Internet s'inscrit dans cette optique,
puisqu'il cherche reproduire (et tendre) le service fourni par le rseau tlphonique traditionnel sur un rseau commutation de paquets, muni des protocoles du monde Internet, et donc destin de prime abord la transmission
asynchrone de donnes informatiques. Ce service de tlphonie se caractrise
par des transmissions temps-rel de flux de donnes audio entre deux usagers ou plus (dans le cas des confrences tlphoniques) ainsi que par l'change
des informations requises pour contrler ces transmissions, ou donnes de
signalisation. Son extension passe par l'ajout d'autres modes de communication, flux vidos, donnes textuelles ou graphiques et autres partages d'applications, ainsi que par l'volution des procdures de signalisation, autorisant de
nouvelles fonctionnalits de gestion d'appels, de reroutage, d'intgration des
applications informatiques...
Nous passons en revue dans cet article les deux grandes approches de la tlphonie Internet, l'une issue de l'International Telecommunication Union (ITU) et
dont les diverses composantes sont regroupes sous l'appellation H.323 ;
l'autre propose par la communaut Internet au travers de l'Internet Engineering
Task Force (IETF), regroupe sous le nom de systme SIP (cf. article Protocole

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur, trait Rseaux

IP 2 960 1

TLPHONIE INTERNET

_________________________________________________________________________________________________________________

SIP de ce trait). Ces approches ont en commun la dfinition de procdures de


signalisation permettant l'tablissement, le contrle et le relchement d'appels
tlphoniques et par extension, multimdias. De tels appels sont des communications entre deux interlocuteurs (point--point) ou plus (confrences multipoint), qui interconnectent des quipements terminaux et d'autres offrant des
fonctionnalits de passerelle (interface avec un rseau non IP) et d'administration au sens large.
Quelle que soit l'approche utilise, l'avantage immdiat procur par la tlphonie Internet, en l'tat actuel du rseau, se traduit par une rduction des cots due
la tarification particulire qui prvaut pour l'Internet, ainsi qu'aux cots artificiellement levs des communications tlphoniques. La nature des rseaux IP
et des mcanismes de transport qu'ils proposent font plus long terme l'intrt
de la tlphonie Internet, en facilitant l'intgration des communications de type
tlphonique au sein de services varis.

1. Normes de l'ITU-T
L'International Telecommunication Union (ITU), organisme successeur du CCITT (comit consultatif international tlphonie et
tlgraphie), a propos au travers de son secteur de standardisation
ITU-T un ensemble de recommandations applicables la tlphonie
Internet. Ces documents sont rfrencs dans la srie H, qui
concerne les systmes audiovisuels et multimedias et plus prcisment s'intresse aux aspects d'infrastructure et d'quipements terminaux dans le contexte de services audiovisuels.

1.1 Recommandation H.323

quipement
vido

Codecs vido

quipement
audio

Codecs audio

Compensation
dlai et gigue

Applications
T.120

Unit de contrle

Interface
d'accs
au rseau
H.225.0

Contrle d'appel
Interface
usager

Signalisation d'appel
Contrle d'admission

La recommandation H.323 [1] constitue le point d'entre oblig de


cette srie de normes, en cela qu'elle est une introduction l'approche prconise par l'ITU-T et aux autres recommandations. Elle
dcrit plusieurs entits fournissant collectivement un service de
communication multimedia au-dessus de rseaux 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 dbit allou,
dlai de transmission de bout en bout et pertes de paquets, est du
type best-effort ( au mieux ). Cette recommandation est actuellement disponible en version 2, approuve en fvrier 1998 et supplantant la version 1 qui fut adopte en 1996. La version 2 tend le
champ de comptence de la norme, en englobant a priori tous les
rseaux commutation de paquets, qu'ils soient locaux, rseau
d'entreprise, rseau mtropolitain ou tendus (intranet, Internet), ou
encore connexions tablies au-dessus du rseau tlphonique ou
RNIS, qu'ils offrent des mcanismes de gestion de qualit de service
ou non. Par contraste, la version 1 se focalisait uniquement sur des
rseaux locaux de type best-effort.
Les entits dcrites doivent obligatoirement proposer un service
de communication audio, tandis que la transmission de vido et de
donnes est optionnelle. Elles peuvent tre intgres des microordinateurs par le biais de complments matriels et logiciels, ou
mises en uvre en tant qu'quipements autonomes, l'instar de
visiophones. Ces entits sont exploites en configuration point
point ou multipoint cette dernire configuration ouvrant la voie
aux applications de type confrences et sont conues de faon
pouvoir interoprer d'une part entre elles, pour dterminer des
types de media communs, et d'autre part avec un ensemble de terminaux audiovisuels dfinis par un certain nombre de recommandations ITU-T de la srie H (H.320 pour le RNIS, H.321 pour le RNIS
large bande, c'est--dire la technologie ATM, H.322 pour les terminaux oprant sur des rseaux locaux avec garanties de qualit de
service, etc.).

IP 2 960 2

Figure 1 Architecture dun terminal H.323

Les entits H.323 sont des composants d'un systme de communication multimdia H.323. La recommandation distingue les terminaux (terminals), les passerelles (gateways), les portiers,
(gatekeepers), les contrleurs multipoint (multipoint controllers ou
MC), les processeurs multipoint (multipoint processors ou MP) et
les units de contrle multipoint (multipoint control units ou MCU).
Ces entits peuvent constituer un quipement part entire, ou tre
intgres au sein d'une mme machine. La recommandation dcrit
enfin les procdures et les messages qui permettent ces entits de
communiquer.

1.1.1 Terminaux
Un terminal H.323 est un quipement d'extrmit fournissant
un service de communication temps-rel bidirectionnelle avec
un autre terminal, une passerelle ou une unit de contrle multipoint.
Ces communications se composent de donnes de contrle et
d'indication, ainsi que de donnes multimdia de type audio, vido,
et/ou donnes tl-informatiques. Un terminal peut offrir des capacits de communication audio uniquement, audio et donnes, audio
et vido, ou encore audio, vido et donnes.
L'architecture d'un terminal H.323 est donne en figure 1.
Un terminal H.323 renferme :
une unit de contrle, qui se dcompose en trois sousensembles ; le contrle d'appel, explicit par la recommandation

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur, trait Rseaux

_________________________________________________________________________________________________________________ TLPHONIE INTERNET

Facturation

Contrle d'appel global

Gestionnaire d'appel H.323

RTP

RTCP

H.225.0
RAS

H.225
signal.
Appel

H.245
signal.
Contrl

Signalisation
Q.931
Contrle lien
LAPD

Protocoles transport & interface rseau

Interface physique

ct H.323

ct RNIS

Figure 2 Architecture dune passerelle H.323

H.245, la signalisation d'appel (drive de la norme Q.931) et le


contrle d'admission (RAS pour Registration, Admission, Status),
tous deux dcrits 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 faon optionnelle un ou plusieurs codecs vido. Ces codecs
se conformant aux recommandations H.261 et H.263 ;
de faon optionnelle une interface pour la transmission de
donnes, conforme la recommandation T.120, et permettant
l'change de fichiers et d'images, l'accs distant des bases de donnes, l'accs des applications partages... ;
un mcanisme de compensation de dlai et de gigue, permettant une synchronisation fine des flux audio et vido reus ;
une interface pour l'accs au rseau commutation de
paquets. Cette interface est en fait hors de la recommandation
H.323, mais doit nanmoins tre conforme la description donne
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'oprer de faon asymtrique, en utilisant un codec donn
pour l'mission et un autre codec pour la rception. Lorsqu'un terminal est destin une utilisation sur un rseau faible dbit, en
de du minimum requis pour le codec G.711, la norme prconise
que ce terminal intgre le codec G.729. Lorsqu'un terminal comporte un ou plusieurs codecs vido, 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 service de communication temps-rel bidirectionnelle entre un terminal H.323 situ sur un rseau commutation de paquets et un
autre quipement. Celui-ci peut tre un terminal ITU localis sur
un rseau 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 interconnects par la passerelle ; sur la partie gauche sont regroups les
composants du monde H.323, se comportant l'image d'un terminal mais avec un module de contrle d'appel particulier, tandis

qu'en partie droite se trouvent les composants du rseau commutation de circuits, ici le RNIS.
La passerelle H.323 est fonctionnellement constitue de trois
sous-ensembles :
une passerelle de signalisation (signalling gateway), qui comprend les terminaisons des rseaux de signalisation et opre la
mdiation de la signalisation (traduction et retransmission des messages, confidentialit, tenue de statistiques) ;
une passerelle mdia (media gateway), constitue des terminaisons de rseau pour les flux audio/vido/donnes, y compris les
codecs ; la passerelle media excute des traitements de conditionnement de flux (transcodage, suppression de silence, annulation
d'cho, conversion des squences DTMF...) et peut superviser les
aspects scurit (confidentialit des donnes) ;
un contrleur de passerelle media (media gateway controller),
charg de la logique de traitement des appels (routage, authentification, slection de la qualit de service, facturation des appels, collecte d'informations statistiques...), du contrle d'admission des
flux de donnes et d'aspects relatifs la scurit.
La passerelle H.323 est donc charge d'abstraire les caractristiques des rseaux qu'elle interconnecte, tant sur le plan de la signalisation d'appel qu'au niveau des flux de donnes eux-mmes. Les
aspects de mdiation de la signalisation sont traits 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 ct la signalisation du
RNIS (Q.931), de l'autre la signalisation d'appel H.225.0. Cette dernire tant un sous-ensemble de la Q.931, le document prcise les
rgles d'adaptation et de retransmission des messages de signalisation. Ainsi un message d'tablissement (SETUP), reu du ct H.323,
entrane la gnration d'un message analogue sur le rseau RNIS,
tandis que la rception d'un message de fin d'appel RELEASE COMPLETE ct H.323 initialise la dconnexion en RNIS, procdure plus
complte impliquant l'change de plusieurs messages sur ce
rseau.
La recommandation H.246 prcise galement les mcanismes qui
peuvent tre mis en jeu pour obtenir un complment d'adresse
dnotant le destinataire dans le monde H.323, lors d'un appel RNIS
entrant. Une passerelle doit ainsi tre capable de transmettre
l'appelant une requte d'extension d'adresse (TCS-4), mais aussi de
jouer un message audio demandant un complment d'information
l'usager et de dcoder les tonalits (DTMF Dual Tone Multi Frequency) composes par cet usager en rponse 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 contrle
d'accs aux ressources du rseau pour le compte de terminaux,
de passerelles, et d'units de contrle multipoint H.323. Un gatekeeper peut galement fournir d'autres types de services, tel la
gestion de la bande passante du rseau ou la localisation de passerelles.
Le gatekeeper est un quipement optionnel qui fournit lorsqu'il
est prsent un contrle accru des autres quipements H.323 et des
communications qu'ils gnrent. Il est responsable d'une zone
administrative, qui peut englober par exemple le rseau interne
d'une entreprise. Chaque terminal, passerelle et MCU H.323 de la
zone doit se faire connatre du gatekeeper pralablement toute
communication, au travers de requtes RAS.
Le service de traduction d'adresse fourni par le gatekeeper permet la rsolution d'adresses de/vers des alias H.323, des adresses
au sens de la numrotation du rseau tlphonique (E.164), ou
encore des adresses Internet. Le contrle d'accs intgre l'authentification des terminaux et des passerelles ainsi que l'autorisation des
appels. La gestion de la bande passante est une fonctionnalit

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur, trait Rseaux

IP 2 960 3

TLPHONIE INTERNET

_________________________________________________________________________________________________________________

optionnelle qui est mise en uvre par le jeu de requtes RAS. Elle
permet au gatekeeper de contrler le niveau d'utilisation de la
bande passante du rseau, et d'accepter ou de refuser l'tablissement de nouvelles communications ainsi que la modification de
communications existantes, en fonction de critres non prciss par
la norme. Un service minimal est prvu, dans lequel le gatekeeeper
peut tout simplement autoriser systmatiquement toutes les communications.
De surcrot, le gatekeeper peut servir de routeur par lequel
vont transiter toutes les communications d'tablissement d'appel et
d'tablissement des flux mdia associs, dans un but de contrle
strict des communications.
Un gatekeeper est en principe requis ds lors qu'un systme
H.323 intgre une ou plusieurs passerelles, en raison des besoins de
traduction d'adresses soulevs par l'interconnexion de plusieurs
types de rseaux.

1.1.4 Contrleurs multipoints


Un contrleur multipoint H.323 assure le contrle d'au minimum trois terminaux prenant part une mme session de
communication.
Il peut par extension tre utilis pour interconnecter deux terminaux dans une session point--point, si cette dernire est susceptible d'voluer dans le temps en intgrant de nouveaux participants.
Le contrleur multipoint fournit aux terminaux un service de ngociation de capacits, permettant d'aboutir au choix de capacits de
communication audio, vido, qui soient communes tous les terminaux connects. Il peut galement offrir un contrle des ressources
de la confrence. Le contrleur n'est pas charg du mlange
(mixage) ou de la commutation des informations audio, vido et
donnes tlinformatiques.

1.1.5 Processeurs multipoints


Un processeur multipoint H.323 est charg de centraliser le
traitement des informations vhicules par les flux de donnes
(audio, vido, data) dans une confrence multipoint.
Le processeur multipoint peut raliser des oprations de mixage
(mlange des flux audio par exemple), de commutation (slection
du flux vido retransmis aux participants) ou d'autres traitements
non prciss. Il opre sous la houlette d'un contrleur multipoint et
peut tre charg d'un flux unique ou d'un ensemble de flux.

Prsentation
Audio/vido

Enregistrement
admission

RTP/RTCP

H.225.0
RAS

Contrle d'appel et
de confrence

H.225.0
ctrl appel

H.245
ctrl mdia
ctrl conf.

UDP

Applications
de transfert
de donnes

T.120

TCP
IP / IP multicast

Figure 3 Pile de protocoles H.323

cesseurs multipoints pour l'change des mdias (lorsque le rseau


sous-jacent dispose de capacits de diffusion, son exploitation est
possible en ce qui concerne les flux mdia ; le ou les processeurs
multipoints peuvent diffuser les donnes audio, vido tous les terminaux). Une session multipoint peut galement tre dcentralise,
auquel cas les terminaux qui en ont la capacit peuvent directement
utiliser la diffusion rseau pour transmettre leurs flux media aux
autres terminaux. Par contre, les informations de signalisation et de
contrle sont toujours changes en point--point entre chaque terminal et le contrleur multipoint. Des modes de transmission hybrides sont enfin possibles, o certains flux (par exemple audio) sont
diffuss et d'autres (flux vidos) transmis en point--point.

1.2 Protocoles H.323


Nous dcrivons maintenant plus en dtails les divers composants
protocolaires des systmes H.323. La figure 3 dnote la pile de protocoles de ces systmes : les lments griss sont dfinis par les
recommandations du monde H.323, tandis que les lments laisss
en clair, bien que partie prenante des systmes H.323, sont soit dfinis par d'autres documentations, Requests for Comments (RFC) du
monde Internet et autres recommandations ITU-T, soit non prciss
et donc laisss au libre choix de l'implmenteur d'un systme particulier.
La recommandation H.225.0 concerne les communications de
signalisation de bas niveau entre des quipements H.323, destines
en rgle gnrale l'initiation des appels. Elle se scinde en deux
sous-ensembles qui concernent respectivement :
les fonctionnalits d'enregistrement, d'admission et de statut
(Registration, Admission, Status ou RAS) ;
la signalisation d'appel, drive de la recommandation Q.931 du
RNIS.

1.1.6 Units de contrle multipoint


1.2.1 H.225.0 RAS
Une unit de contrle multipoint ou MCU est un quipement
d'extrmit qui fournit la possibilit trois quipements H.323
au minimum de communiquer au sein d'une session multipoint.
La MCU est constitue d'une part d'un contrleur multipoint (unique) et d'autre part d'une collection, optionnelle, de processeurs
multipoints dots de caractristiques de traitement varies. Elle
peut tre explicitement appele lors de l'tablissement de la confrence, ou peut tre invoque de faon transparente par un gatekeeper (par exemple lorsqu'une session point--point intgre de
nouveaux participants et se transforme en session multipoint).
Une session multipoint peut tre centralise (en toile), auquel
cas tous les terminaux communiquent avec la MCU en mode point-point, c'est--dire avec le contrleur multipoint pour la partie
signalisation et contrle de la session et avec un ou plusieurs pro-

IP 2 960 4

Les messages RAS permettent un dialogue entre les quipements


d'extrmit (terminaux, passerelles, MCU) et leurs gatekeepers respectifs. Par consquent, ces messages ne sont pas utiliss dans une
configuration H.323 dpourvue de gatekeeper. Grce des changes
du type requte/rponse, les quipements sont en mesure de
dcouvrir dynamiquement l'existence d'un gatekeeper dans leur
zone, de s'enregistrer auprs de ce gatekeeper, puis de requrir de
celui-ci l'autorisation d'tablir un appel H.323. Lors de cette requte,
et plus tard pendant le droulement de l'appel, un quipement peut
s'adresser son gatekeeper, par le biais des messages RAS, au sujet
d'une ressource partage, dont la gestion incombe au gatekeeper. Il
s'agit essentiellement de la bande passante disponible, qui peut tre
place sous le contrle du gatekeeper dans un but de matrise de la
qualit de service. Les services de passerelles peuvent galement
tre grs par le gatekeeper, auquel cas les terminaux souhaitant
tablir un appel via une passerelle devront au pralable s'adresser

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur, trait Rseaux

_________________________________________________________________________________________________________________ TLPHONIE INTERNET

leur gatekeeper afin d'obtenir une autorisation dusage. Par ailleurs,


un gatekeeper utilise activement les messages RAS pour s'enqurir
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 dtecter des pannes silencieuses.
Les changes de messages RAS se caractrisent par une requte
(ReQuest RQ) et une rponse positive (ConFirm CF) ou ngative
(ReJect RJ). Les changes suivants sont spcifis par la recommandation H.225.0 :
dcouverte d'un gatekeeper (G) : mise en uvre par la requte
GRQ transmise en multicast dans la zone de rattachement de l'quipement, et qui recevra une rponse positive GCF ou ngative GRJ ;
enregistrement auprs du gatekeeper (Registration R) :
requte RRQ, rponse positive RCF ou ngative RRJ ; pour cet
change, un mcanisme d'obsolescence est possible, qui requiert
de l'quipement l'envoi priodique de requte RRJ ;
suppression de cet enregistrement (Unregistration U) : requte
URQ, rponses positive UCF ou ngative URJ ; si la suppression est
initie par le gatekeeper, l'quipement supprim n'a pas le droit
d'mettre URJ ;
service de localisation (Location L) : requte LRQ (Location
ReQuest), rponses LCF ou LRJ : la rponse positive vhicule des
informations de localisation sur l'quipement gr : adresses des
canaux de signalisation, numrotation, extensions... ;
admission, ou autorisation initier un appel (Admission A) :
requte ARQ, transportant une valeur qui dnote la bande passante
totale requise, rponses ACF ou ARJ ; la rponse ACF peut modifier
la valeur demande ;
modification de bande passante (Bandwidth B) : requte BRQ,
transportant une valeur qui dnote le nouveau besoin de bande passante, la hausse ou la baisse ; rponse BCF ou BRJ ; si le gatekeeper est l'instigateur de la modification, l'quipement destinataire
ne peut pas refuser ;
information de statut (Information I) : requte IRQ, rponse
IRR ;
message d'erreur XRS (Unknown Message Response) en
rponse une requte inconnue.
Les messages RAS sont transports par un protocole non fiable de
type UDP (User Datagram Protocol) ce qui ncessite la mise en place
d'un contrle par numrotation en squence et d'un mcanisme 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 procdures qui furent dfinis pour le RNIS, dans la
recommandation Q.931. Des informations additionnelles, spcifiques
au monde H.323, sont transportes grce des lments d'information d'usager (User-User Information Element UUIE).
Cette signalisation comprend des requtes d'tablissement
d'appel, de l'appelant vers l'appel, des messages intermdiaires
(requte transmise, appel contact, etc.), ainsi que les rponses
finales retournes l'appelant (acceptation, rejet, redirection,
accompagns 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
faon optionnelle CALL, PROCEEDING, PROGRESS, SETUP
ACKNOWLEDGE ;
fermeture d'appel : RELEASE COMPLETE ;
invocation de services H.450 : FACILITY ;
autres messages (optionnels) : USER INFORMATION, INFORMATION, 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 transports sur une connexion fiable (de type TCP), ce qui simplifie considrablement le contrle d'erreur pour ces changes (et alourdit ces

changes par la mme occasion). Dans la majeure partie des cas,


cette connexion n'est utilise que pour l'tablissement de l'appel, et
peut ensuite tre ferme. Elle sera rouverte par l'une ou l'autre des
extrmits si une fonctionnalit de signalisation est invoque en
cours d'appel.

1.2.3 H.245
La recommandation H.245 dcrit les procdures qui permettent le
contrle de la session de communication, en termes de contrle des
flux media ainsi que de contrle de confrence dans le cas du multipoint. Cette recommandation est exploite par plusieurs systmes de
communication ITU-T ; de ce fait, son usage au sein d'un systme
H.323 comporte certaines restrictions (en particulier sur les multiplex
de flux) et certains ajouts spcifiques cette norme.
Un canal de contrle H.245 spar est tabli entre les entits communiquantes aprs la phase d'tablissement d'appel (H.225.0). Les
messages d'tablissement de type Q.931 vhiculent pour ce faire des
informations d'adressage. Ce canal de contrle H.245 est exploit
pour la ngociation et l'tablissement des flux mdia. Les fonctionnalits H.245 sont les suivantes :
dtermination de rle matre/esclave : les quipements utilisent cette fonctionnalit pour lire un systme matre, ce qui permet
d'viter certaines situations de blocage, par exemple lors de l'tablissement de canaux bidirectionnels, ainsi que d'identifier l'quipement jouant le rle de MCU dans une confrence multipoint ;
change de capacits d'mission et de rception : les quipements exploitent cette fonctionnalit pour dcrire leurs pairs leurs
possibilits de codage/dcodage en termes d'algorithmes, de paramtrage et de formats, en mission et en rception ; cet change de
capacits permet aux quipements de ngocier un ensemble commun
de fonctionnalits, et peut avoir lieu tout moment au cours d'un
appel, ce qui permet la rengociation en cours d'appel ;
contrle des flux mdia : ouverture et fermeture de canaux
logiques qui sont des abstractions reprsentant les media changs. L'metteur d'un canal logique doit se conformer aux capacits
de rception du destinataire, telles que ngocies dans la phase prcdente. Un canal logique audio, vido ou de donnes est toujours
de type unidirectionnel, mme s'il peut en ralit faire rfrence
une transmission de donnes bidirectionnelle (une session RTP) ;
contrle de confrence : lors d'une session multipoint, la gestion de la confrence est assure par des mcanismes H.245 pour
dterminer un ensemble de capacits conjointement supportes par
tous les participants, pour tablir le modle de session (centralise ou
dcentralise), ainsi que pour fournir un ensemble de fonctions
d'administration de la confrence (contrle du tour de parole, contrles associs au dirigeant de la confrence etc.).
En sus de ces fonctionnalits, H.245 fournit un service d'estimation du dlai d'aller-retour entre deux quipements, qui permet de
plus de vrifier le fonctionnement en continu de ceux-ci.
Une clause particulire de la recommandation H.323 dfinit le
mcanisme de Fast Connect, ou connexion rapide, afin de rduire le
dlai d'tablissement des flux media. Ce mcanisme prvoit d'adjoindre une requte d'tablissement d'appel SETUP la description de
tous les canaux logiques prvus par l'appelant, en mission comme
en rception. Cette description constitue une proposition, qui peut
tre accepte ou refuse par l'appel en fonction de ses capacits
propres. Dans cette proposition, la description des flux est tablie par
prfrence dcroissante. L'appel choisit dans cette liste un ensemble de flux media qui correspondent ses possibilits, et retourne son
choix dans une structure d'information jointe un message Q.931 de
rponse au SETUP (CALL PROCEEDING, ALERTING ou CONNECT).
La rception par l'appelant de ce choix est une indication que les
donnes des flux media peuvent tre transmises, immdiatement
ou aprs le traitement du CONNECT du niveau infrieur. Par la suite,
les procdures de traitement H.245 se poursuivent normalement.
La version 2 de la recommandation prvoit d'autre part la possibilit d'utiliser la connexion TCP vhiculant la signalisation d'appel

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur, trait Rseaux

IP 2 960 5

TLPHONIE INTERNET

_________________________________________________________________________________________________________________

(H.225.0) pour transporter les messages H.245 (ce procd est


nomm tunneling), ce qui permet de rduire le nombre de connexions TCP utilises globalement dans une session de communication ainsi que le dlai d'tablissement.

1.2.4 RTP et RTCP


Les donnes des flux mdia d'un systme H.323 sont transportes
par le protocole RTP (Real-time Transport Protocol), dfini par la
communaut Internet dans le document [5]. Il s'agit d'un protocole
de transport non fiable, ddi aux flux continus de donnes (audio,
vido principalement), et fonctionnant en point--point ou en multipoint sur un rseau IP. L'intrt majeur de RTP rside dans la dfinition de payloads, ou indications de formatage et d'encapsulation
des donnes en fonction de leur nature (algorithme et format de
codage utilis). Les donnes audio ou vido ainsi morceles sont
ensuite encapsules dans RTP, et le paquet rsultant soumis UDP
pour transmission dans le rseau. Cette transmission tant non fiable, ces paquets pourront tre perdus, dsquencs, dupliqus, ou
simplement retards. De ce fait, chaque paquet RTP renferme dans
son entte des informations de type numro de squence et estampille temporelle, permettant au rcepteur de dtecter une perte ou
un retard trop important, et ainsi de jouer le flux de donnes l'arrive. Les estampilles temporelles sont utilises la fois pour la synchronisation intra-flux, ou dtermination des instants de jeu de
chaque paquet de donnes, et la synchronisation inter-flux, qui met
en jeu les relations temporelles existant entre plusieurs flux (synchronisation de la voix et du mouvement des lvres par exemple).
Par ailleurs certains formats de payloads dfinis dans le contexte
de RTP autorisent l'exploitation de mcanismes volus de correction
d'erreur par anticipation ou de dissimulation d'erreurs l'arrive, qui
permettent une transmission correcte d'audio et de vido mme dans
un rseau moyennement charg o se produisent des pertes de
paquets.
Ce protocole est accompagn d'un protocole de contrle, RTCP
(Real-time Transport Control Protocol), qui offre des fonctionnalits
d'observation des communications RTP par le biais d'change priodique de rapports de transmission (pour les sources) et de rception.
Ces rapports vhiculent de faon directe ou indirecte des informations statistiques sur les communications, en termes de pertes de
paquets, de dlai d'aller-retour, de gigue d'interarrive des paquets
etc., informations qui permettent aux sources d'adapter dynamiquement leur transmission aux conditions rgnant dans le rseau.

1.3 Fonctionnement d'un systme H.323


Dans le but d'expliciter le fonctionnement d'un systme H.323,
nous tudions brivement ci-aprs quelques cas de figure, en renvoyant le lecteur intress la recommandation H.323, qui prsente
de manire dtaille un ensemble de scnarios 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 scnario le plus simple est probablement un appel entre deux
terminaux dpourvus de gatekeepers. Dans ce contexte, aucun trafic
RAS n'est gnr, et la communication H.225.0 dbute par l'ouverture d'une connexion TCP sur un port bien connu (le port 1720),
puis par l'mission d'une requte d'tablissement Q.931 SETUP, qui
reoit en premire rponse un message ALERTING, indiquant que le
destinataire est convi rpondre, suivi d'un message CONNECT.
Ce premier change permet aux entits de dfinir des ports dynamiques utiliss pour la connexion H.245, qui dbute alors ( moins que
le mcanisme de Fast Connect n'ait t utilis) et permet l'ouverture
des flux RTP (par change d'adresses et de numros de port pour ces

IP 2 960 6

flux) et la transmission des donnes audio, vido, et/ou tlinformatiques.


Lorsqu'un gatekeeper est inclus dans le systme, les quipements
terminaux prcdent 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 ncessaire. Si le gatekeeper joue le rle
de routeur pour la signalisation, les messages H.225.0 et/ou
H.245 transitent alors par lui, ce qui peut ncessiter ventuellement
la fermeture et la rouverture d'une tentative d'tablissement. Cela
se produit par exemple lorsqu'un terminal met un SETUP vers un
autre terminal qui est gr strictement par son gatekeeper. Dans ce
cas, le second terminal rpond par un message FACILITY, indiquant
au premier de clore sa tentative et de se connecter plutt au gatekeeper pour le joindre.

1.3.2 Confrence multipoint


Une session multipoint est gre de faon homogne par un MC
(Multipoint Controller), qu'elle ait t prvue l'avance ou qu'elle
rsulte d'un appel point--point largi de nouveaux participants :
dans le premier cas, le MC est gnralement situ dans un quipement spcial (MCU ou gatekeeper particulier), charg de grer la
confrence. Les participants se connectent directement cette
entit ;
dans le second cas, le MC est l'quipement dsign par le jeu
des mcanismes d'lection H.245 ; ce MC a la capacit d'inviter de
nouveaux participants (ventuellement redirigs sur lui par les participants dj prsents recevant un appel).
L'tablissement des communications dans un scnario multipoint 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 changes H.245, et dans le cas d'une session dcentralise, 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 ngocient leurs canaux logiques avec le MC uniquement.

1.4 Services avancs offerts par H.323


L'architecture H.323 intgre un certain nombre de fonctionnalits
de contrle d'appel avanc, par le biais des recommandations
H.450.x. Le mcanisme d'acheminement des messages qui mettent
en uvre ces fonctionnalits prvoit leur intgration dans les messages H.225.0 changs, en utilisant le message FACILITY
lorsqu'aucune information H.225.0 particulire n'est transmettre.
La recommandation H.450.1 prsente ce mcanisme ainsi que plusieurs paramtres gnriques, utiliss 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, transfre l'appel vers un usager C ; applicable que les appels A B et A
C soient dj tablis ou non (recommandation H.450.2) ;
services de dviation d'appel : renvois d'appel inconditionnel,
sur occupation, sur absence de rponse, 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 vido (recommandation
H.450.4) ;
service complmentaire d'appel en attente ( signal d'appel ,
recommandation H.450.6) ;
des services non normaliss, spcifiques un fabricant.

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur, trait Rseaux

_________________________________________________________________________________________________________________ TLPHONIE INTERNET

1.5 H.332 (large scale)

2. Approche Internet

La recommandation H.332 est une adjonction rcente au monde


H.323 qui rpond au problme des confrences de grande chelle, o
le nombre de participants est trs lev. Son approche considre
qu'une telle confrence est en fait constitue d'un petit groupe de
participants formant un noyau de confrenciers, entour par une
large audience forme de participants passifs. Le noyau est alors mis
en uvre par les mcanismes traditionnels de H.323 pour les appels
multipoints, tandis que l'audience, arbitrairement grande, de spectateurs passifs, est gre par H.332, qui suppose une communication
en multicast uniquement, et en cartant toute notion de ngociation
de capacits. L'hypothse de base est ici que ce type d'vnement
est prvisible et par consquent annonc l'avance. Il est alors envisageable d'assortir cette annonce des informations sur la nature des
flux prvus, leur mode de codage etc. Toutes ces informations sont
par consquent annonces au pralable selon le format prconis par
la communaut Internet, et dcrit dans le protocole SDP (Session
Description Protocol).

l'instar de l'ITU-T, la communaut Internet et plus prcisment


l'Internet Engineering Task Force (IETF) avec son groupe de travail
Multimedia Multiparty Session Control (MMUSlC) a dfini un cadre
gnral pour la communication multimdia dans le rseau Internet.
Ce cadre est prsent dans un document non encore finalis [7].
L'approche est analogue celle de l'ITU-T, au sens o l'architecture
prconise (figure 4) dpasse le cadre de la tlphonie IP pour
englober les communications audiovisuelles, point--point et multipoint, voire de diffusion massive, etc.

1.6 H.235 (scurit)


Autre ajout rcent l'ventail des normes H.323, la recommandation H.235 s'intresse au domaine crucial de la scurit, en fournissant un cadre gnral pour la mise en uvre de procdures
d'authentification, de certification, de chiffrement de la signalisation
et des donnes, 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 exploits, condition qu'il existe un
secret partag (un mot de passe) ou un mcanisme 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 contrle d'appel (H.225.0, Q.931) : la recommandation H.235 propose l'utilisation des protocoles de scurit
TLS (Transport Layer Security) [3] ou IPSEC (IP SECurity) [4] dfinis
par l'IETF. Ces protocoles peuvent alors fournir un service d'authentification, de confidentialit et d'intgrit des messages Q.931 ;
contrle de mdia et de confrence (H.245) : les messages
H.245 peuvent galement bnficier des services de scurit TLS ou
IPSEC. Les changes H.245 permettent alors de ngocier et d'changer des cls permettant le chiffrement des flux mdia. Cette dernire
opration est ralise dans les flux RTP, ce qui permet une assez
grande flexibilit et de bonnes performances.
H.235 prvoit le rafrachissement dynamique des cls, ce qui permet, dans le cadre d'une confrence multipoint, la rsorption d'un
trou de scurit, ainsi que l'expulsion d'un participant donn. Il faut
encore noter que la recommandation ne propose pas de choix pralable (ou service par dfaut) pour les mcanismes de scurit, du
fait essentiellement de l'absence de consensus l'chelle internationale. Tous les aspects de la scurit H.323 sont de ce fait ngociables
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 multimdia de lIETF

On retrouve dans cette architecture les protocoles RTP et RTCP,


exploits pour le transport de l'information audiovisuelle en point-point ou en multipoint et prsents ci-avant ( 1.2.4). L'aspect qualit de service est couvert d'une part par RTCP, pour ses capacits
mesurer les paramtres de performance d'une communication RTP
par le jeu des rapports d'mission et de rception, et d'autre part par
RSVP (Resource Reservation Protocol), qui est un protocole de
rservation de ressources, autorisant la fourniture de garanties de
service, strictes ou statistiques, pour une session de communication
particulire ou plus grossirement pour un agrgat de communications. En matire de tlphonie sur IP, les protocoles les plus importants sont SIP (Session Initiation Protocol), SDP (Session
Description Protocol) et dans une moindre mesure RTSP (Real-Time
Stream control Protocol). Ces protocoles ralisent une fonction de
signalisation dans cette architecture, l'instar des composantes
H.323 vues prcdemment. RTSP, rattach cette mme fonction,
est un protocole qui rend possible le contrle distance d'un serveur audiovisuel (commandes de type magntoscope sur un serveur vido par exemple). ce titre, il n'intresse pas spcifiquement
le domaine de la tlphonie, 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 conu par l'IETF dans une optique multipoint
aussi bien que point--point. De ce fait, la fourniture de services de
communication multimdia multipoints est intrinsquement supporte par cette architecture.

2.1 SIP
Le protocole SIP [8] dcoule d'une approche ddie la signalisalion tlphonique sur Internet au sein du groupe MMUSIC. Il intgre
les fonctionnalits de transformation d'adresse, de localisation
d'usager, d'tablissement et de gestion des appels (incluant la ngociation de capacits analogues H.323).
Ce protocole est dtaill dans l'article [IP 2 925], auquel nous
prions le lecteur de se reporter pour prendre connaissance des concepts et des mcanismes mis en jeu par SIP.

2.2 SDP
Le protocole SIP spcifie les modalits de communication entre utilisateurs en termes de localisation, de nommage et d'adressage, mais
par contre ne dcrit pas directement les flux multimedia mis en jeu
par cette communication. Pour ce faire, il s'appuie sur SDP [9], protocole de description de session vhiculant 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, vido ou autres qui la composent ;
tout paramtre caractrisant ces flux (adresses, ports, formats,
etc.) ;

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur, trait Rseaux

IP 2 960 7

TLPHONIE INTERNET

_________________________________________________________________________________________________________________

de faon optionnelle, de l'information additionnelle, prcisant


par exemple la bande passante requise ou une information de contact
de la personne responsable.

2.2.1 Spcification SDP


Une description de session SDP est une information textuelle, consistant en lignes de caractres de la forme type = valeur. La description est structure en deux zones successives, la premire tant
dvolue la session elle-mme et la seconde dtaillant les flux individuels qui la composent. Le champ type renferme un caractre unique
dont la signification dpend de la zone considre. Le champ valeur
est une chane de caractre dont le format dpend du type d'information.
Exemple : la figure 5 prsente un exemple de spcification SDP. La
session dcrite, en SDP version 1 (v=0), est initie par l'utilisateur
Dupont (o pour owner) sur sa machine citrouille. La ligne dbutant par
c= mentionne des paramtres applicables tous les mdias qui
suivent. Ceux-ci sont introduits par le type m= . Le premier flux
dcrit 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 vido,
sur le port 51372, encod en H.261 720 Kbit/s.

2.2.2 Usage dans le cadre SIP


Lorsqu'une spcification SDP est utilise pour l'tablissement
d'un appel SIP, elle permet la ngociation de capacits entre l'appelant et l'appel. La description est insre dans le corps de la
requte INVITE. Le destinataire l'exploite pour dterminer les flux
que souhaite tablir l'appelant et la complte, en respectant l'ordre
de description des media (les lignes m= ), avec ses propres
vux.
Exemple : ainsi l'utilisateur Martin, recevant la description de la
figure 5, pourra retourner la description de la figure 6. Dans cet exemple, 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 vido, ce qui se traduit par le numro de port mis zro
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 Spcification 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 Spcification SDP en retour

IP 2 960 8

2.3 RTSP
Le protocole RTSP (Real-Time Streaming Protocol) [6] vise fournir un site client des capacits de pilotage d'un serveur de contenu
distant. Dans le contexte de la tlphonie Internet, ces capacits ont
un intrt dans deux cas :
usage de botes vocales offrant une fonctionnalit analogue au
rpondeur tlphonique, les fonctions pilotables par RTSP incluent
alors l'enregistrement et la consultation des messages vocaux stocks dans la bote ;
intgration de machines dans une communication, des fins
de consultation (bases de connaissances), d'enregistrement (d'une
confrence tlphonique) ou des services encore imaginer (traduction et transcription simultane...).
Les ressources qui peuvent tre pilotes distance au moyen de
RTSP sont identifies grce une RTSP-URL, analogue aux SIP-URL
(cf. [Doc. IP 2 925]). Ainsi, la chane de caractres rtsp://serveur.entreprise.com/prs/bilan dcrit une ressource bilan , qui
peut tre compose d'audio, de vido et d'autres mdias, et dont le
droulement est contrlable avec RTSP. l'instar de SIP, RTSP est un
protocole o les messages sont textuels et d'un format assez proche
de HTTP. Il et t possible en fait de mettre en uvre ces fonctionnalits avec HTTP ; cependant, les rflexions sur RTSP ont abouti
mettre en vidence des diffrences notables, qui ont conduit l'laboration du protocole, distinct de HTTP. En premier lieu, bien qu'il
n'existe pas de notion de connexion dans RTSP, le serveur contrl
doit mettre en place un contexte de session (ou tat). Ensuite, les
donnes sont transmises hors-bandes , c'est--dire que le flux
d'informations contrl par RTSP et les donnes (requtes/rponses) de contrle ne sont pas mlangs mais au contraire transmis
par des moyens distincts. Ce point amliore la versatilit des protocoles, en n'imposant pas, pour la transmission des donnes audio/
vido, l'usage d'un protocole prcis. Enfin, RTSP introduit un certain
nombre de nouvelles requtes, spcifiques son activit, et qui ne
trouveraient donc pas leur place dans HTTP. Les principales requtes sont les suivantes :
DESCRIBE : requte envoye pour obtenir une description
d'une ressource (media disponibles et leurs types, codage, ports...) ;
ANNOUNCE : permet un client d'enregistrer une ressource
auprs d'un serveur ; permet un serveur de mettre jour, dynamiquement, la description d'une ressource auprs d'un client ;
SETUP : initialise une session, en fournissant tous les paramtres d'tablissement des flux media ;
PLAY : requte indiquant au serveur de dbuter la transmission d'une ressource ; cette requte peut vhiculer une information
temporelle prcisant quelle portion de la ressource doit tre joue ;
PAUSE : interrompt la transmission d'une ressource ;
TEARDOWN : stoppe la transmission d'une ressource et ferme
la connexion associe ;
RECORD : requte indiquant au serveur de dbuter l'enregistrement d'un flux, stock sous la RTSP-URL mentionne dans la
requte ;
REDIRECT : informe un client qu'il trouvera la ressource spcifie sur un autre serveur.

2.4 MEGACO & IPTEL


Jusqu' prsent, la notion de passerelle n'a pas t aborde dans
le contexte SIP. Cette notion est en fait traite par des groupes de travail distincts de MMUSIC, IPTEL, (IP Telephony) et MEGACO (Media
Gateway Control). Nous passons en revue ci-aprs les diffrents
aspects abords par ces deux groupes.

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur, trait Rseaux

_________________________________________________________________________________________________________________ TLPHONIE INTERNET

2.4.1 MEGACO
Le groupe MEGACO a dfini une architecture dans laquelle les
diffrents composants d'une passerelle peuvent tre physiquement disjoints (passerelle de signalisation, passerelle de media,
contrleur de passerelle ; le dcoupage est ici analogue celui des
passerelles H.323 (cf. 1.1.2). L'intrt premier de cette approche
est de permettre une vision homogne d'un quipement qui peut
prendre des formes trs diverses. Une passerelle peut en effet tre
un quipement lourd, capable de router plusieurs dizaines de milliers de connexions simultanes, tout autant qu'un quipement
trs succinct, permettant par exemple l'accs au rseau Internet
partir d'une ligne analogique (modem). Dans ce dernier cas, il est
souhaitable de dissocier les fonctionnalits de passerelles, afin par
exemple de concentrer dans un quipement amont le contrle de
plusieurs passerelles lgres . Cette architecture dfinit principalement deux notions :
la notion de terminaisons, qui sont des points de connexion
avec un rseau et une signalisation particulire (H.323, rseau tlphonique commut, rseau numrique intgration de service,
rseau GSM...) ;
la notion de contexte, qui reprsente une association entre
plusieurs terminaisons.
Nous illustrons ces notions avec la figure 7. Du point de vue
d'une passerelle donne (cas 1), un appel simple consiste en un
contexte associant deux terminaisons. La survenue d'une requte
d'tablissement gnre la cration d'un second contexte, dans
lequel cette requte est mise en attente, et qui suscite l'invocation
d'un signal d'appel. L'usager choisit de prendre cet appel, ce qui
provoque (cas 2) la mise en attente de son correspondant dans le
premier contexte et l'tablissement de la communication dans le
second.

Usager 1

contexte 1
terminaison T1
terminaison T2
Ligne RTC
Flux RTP

Usager 2

contexte 2
terminaison T3
Ligne RTC

Usager 3

signal
d'appel

MEGACO dfinit plusieurs protocoles permettant l'interopration


de ces composants, et particulirement le contrle distant des oprations dcrites sur la figure 7, en intgrant diffrentes signalisations issues de la tlphonie traditionnelle. Cette spcification est
commune au groupe de travail MEGACO et l'ITU-T, o elle constitue une proposition de recommandation nomme H.248 [10].
Lun de ces protocoles est MGCP, Media Gateway Control Protocol, qui met en place les procdures par lesquelles un contrleur de
passerelle pilote une ou plusieurs passerelles. MGCP nexiste qu
ltat de draft (brouillon) et il est vraisemblable quil se trouve intgr aux spcifications futures dun MEGACOP (MEGACO Protocol),
en cours dlaboration.

2.4.2 TRIP
Propos par le groupe de travail IPTEL, TRIP (Telephony Routing
over IP) rpond au problme de localisation dune passerelle : tant
donn une adresse distante (numro de tlphone, alias H.323, SIPURL...) et un ensemble dattributs, qui sont autant de contraintes
prcises par lusager, trouver une passerelle capable de se connecter cette adresse en satisfaisant aux contraintes. Lapproche TRIP
prvoit des serveurs de localisation, ayant connaissance des passerelles disponibles dans un domaine administratif et des serveurs de
signalisation, qui assurent la propagation et le routage de la signalisation dappel (gatekeepers dans H.323, serveurs proxy pour SIP).
TRIP vise tablir des tables de routage, par coopration entre les
serveurs de localisation de chaque domaine, de faon trs semblable aux techniques de routage mises en uvre dans linternet (protocole BGP, Border Gateway Protocol). En effet, ltablissement de
routes pour les appels de tlphonie est analogue au calcul de route
pour les paquets IP, avec les distinctions suivantes :
les routes tablies pour la tlphonie sont virtuelles, puisque
c'est finalement le rseau IP qui achemine les paquets
tlphoniques ; par consquent, la topologie peut diffrer considrablement de celle du rseau IP support ;
le cot d'une route est trs vraisemblablement plus complexe
dans le cas des appels tlphoniques, car il dpend du plus de paramtres que la simple mtrique des rseaux IP (cot associ une
liaison avec le RTC, cot du la qualit de service offerte, etc.) ;
on peut associer une route tlphonique plusieurs attributs la qualifiant, tels que les signalisations supportes, les services
avancs offerts /par la destination, les formats de codage disponibles la destination, etc.
TRIP constitue une proposition de norme actuellement, succdant
en cela GLP (Gateway Location Protocol).

2.4.3 Traduction d'adresses E.164


mise
en attente

Cas 1

contexte 1
terminaison T2
Flux RTP

Usager 2

mise
en attente

Usager 1

contexte 2
terminaison T3
terminaison T1
Ligne RTC
Ligne RTC

Cas 2
Figure 7 Exemple MEGACO

Usager 3

ltude, principalement dans le groupe de travail ENUM de


lIETF, la traduction dadresse E.164 est une tche importante. Elle
consiste intgrer la numrotation tlphonique traditionnelle,
lorsquelle se conforme au standard E.164 de lITU-T, au sein du service de nommage de lInternet (Domain Name Service, DNS).
Lusage majeur dune telle intgration est de permettre un appelant didentifier au pralable les services supports par lappel.
La norme E.164 dfinit la structure de la numrotation publique
sous forme hirarchique. Un numro de tlphone dbute ainsi par
un code de pays, suivi dune partie dont la signification est nationale, 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 dun numro de tlphone est de quinze chiffres.
Linsertion de cette numrotation dans le DNS passe par le dcoupage des numros en chiffres, qui sont chacun traits comme un
identifiant de domaine DNS. Le rsultat est ensuite prfix la
chane e164.int , qui identifie le domaine de plus haut niveau
(figure 8). Le mcanisme de dlgation propre au DNS permet de
confier des blocs de numros aux divers acteurs qui les grent (op-

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur, trait Rseaux

IP 2 960 9

TLPHONIE 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 Isral
...
En France :
0.3.3.e164.int
1.3.3.e164.int
...

IN NS ns.Fournisseur1.net ; pour l'oprateur qui gre le 0


IN NS ns.Fournisseur2.net ; pour l'oprateur qui gre le 1

Chez le fournisseur1 :
*.4.3.2.1.1.0.3.3.e164.int PTR Abonn1.com ; qui a les nos 01 12 34 xx xx
*.5.4.3.2.1.0.3.3.e164.int PTR Abonn2.com ; qui a les nos 01 23 45 xx xx
...
Requtes DNS :
No de tlphone : 01 12 34 56 78
Requte pour un PTR sur le domaine 8.7.6.5.4.3.2.1.1.0.3.3.e164.int
Rsultat : PTR = Abonn1.com
service "voicemail" recherch
Requte pour un SRV : voicemail.8.7.6.5.4.3.2.1.1.0.Abonn1.com
Rsultat : SRV = ldap.Abonn1.net
Figure 8 Numro E.164 dans le DNS

rateurs, entreprises, voire particuliers), afin de renseigner les services supports par ces numros.
Les requtes DNS portant sur un numro de tlphone peuvent
alors tre effectues en convertissant ce numro comme indiqu cidessus, puis en oprant une requte traditionnelle sur le domaine
ainsi identifi.
Le fait de traiter chaque chiffre comme un domaine DNS a plusieurs avantages. En premier lieu, cela permet de saffranchir de la
connaissance du dcoupage du numro, en fonction des longueurs
de zones variables. Ensuite, il est possible doprer une recherche de
faon trs efficace, ne ncessitant pas de balayage dans un ensemble dinformation. Enfin, une telle approche est robuste aux renumrotations futures.
Ce premier mcanisme est complt par deux autres niveaux,
dans la proposition du groupe ENUM. Le premier niveau complmentaire tire parti des enregistrements de type SRV (localisation de
service) dans le DNS pour obtenir de linformation sur les services
associs un domaine. Ces enregistrements contiendront euxmmes une rfrence un service dinformation externe (par exemple LDAP, Lightweight Directory Access Protocol), qui constitue ainsi
le dernier niveau de la hirarchie.
Puisque dans la proposition, le numro de tlphone complet est
un domaine, il devient possible daffecter des descriptions de services chaque numro intgr dans le DNS. Dans la figure 8, les deux
premiers niveaux sont illustrs par deux requtes DNS. La premire
vise identifier le serveur de nom susceptible de renfermer les
informations de service et la seconde interroge ce serveur au sujet
dun service voicemail . Lenregistrement SRV permet enfin
dinterroger un serveur LDAP qui fournira les informations ncessaires linvocation du service, pour ce numro de tlphone.

3. Comparaison H.323/SIP
Outre le fait que la technologie H.323 est actuellement beaucoup
plus rpandue que celle de lIETF, il existe de nombreux points de
comparaison entre les deux architectures.

IP 2 960 10

3.1 Philosophie des deux approches


Poursuivant un mme but, en termes de signalisation dappels
tlphoniques et plus gnralement multimedias, les approches de
lITU-T et de lIETF se diffrencient considrablement dans la philosophie quelles adoptent.
La dmarche de lITU-T, bien que fonde sur les normes quelle a
antrieurement dfinies dans le cadre du rseau numrique intgration de services, dfinit globalement un ensemble de nouveaux
protocoles, ddis la tlphonie Internet (au sens large), ainsi que
les quipements qui mettent en uvre ces protocoles. Par contraste, lapproche de lIETF est celle de la rutilisation maximale :
seul le protocole SIP est vritablement ddi la signalisation
dappels tlphoniques, et encore il reprend largement les concepts
dfinis antrieurement pour le World Wide Web, au travers de son
protocole HTTP. Les autres composants dun systme SIP (RTSP,
RTP, RTCP, SDP, RSVP...) proviennent de travaux connexes de lIETF
et sont intgrs larchitecture de communication globale labore
par la communaut Internet au mme titre que SIP. Lapproche SIP
vise en fait fournir un nouveau composant dans une architecture
trs modulaire, alors que lapproche H.323 spcifie une pile de protocoles implmentant totalement les fonctionnalits recherches.
Laspect communications multipoints est galement trait diffremment par ces deux approches. Dans le contexte H.323, des quipements ddis sont ncessaires (MC et MCU intgrs ou non aux
quipements physiques), alors que le systme SIP est globalement
pens en terme de multipoint, suivant en cela toute la dmarche de
normalisation de lIETF.
Sur le plan de la scurit, les philosophies semblent sinverser : l
o H.323 prne la rutilisation des technologies Internet, par exploitation pure et simple des approches IPSEC ou TLS (scurit de
niveau rseau ou transport), SIP met en place des techniques de
chiffrement de plus haut niveau (par coopration entre serveurs
adjacents), qui semblent ncessaires pour accrotre la scurit globale du systme.

3.2 Points de comparaison


3.2.1 Complexit
Sur le plan technique, la diffrence la plus largement voque
entre les deux approches concerne leurs complexits relatives. Il
faut noter par exemple quen terme de volume de documentation,
H.323 totalise environ cinq fois plus de pages que lapproche SIP (en
y incluant des normes connexes). En termes opratoires, la complexit associe SIP est analogue celle des technologies du Web
(technologie client-serveur), tandis que la complexit de mise en
uvre dH.323 est celle dune pile de protocoles (cette complexit
associe H.323 est particulirement mise en vidence lors de runions Interop, visant tester linteroprabilit des dveloppements
entrepris par divers acteurs : les implmentations prsentes cette
occasion sont trs en retard sur la normalisation). Les messages,
nettement plus varis dans le monde H.323, sont encods en ASN.1
(Abstract Syntax Notation 1), ce qui ajoute des procdures de traitement 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 ncessit ou non de conserver un contexte de communication est aussi un facteur de complexit H.323, avec ses canaux de contrle utilisant TCP, impose
essentiellement que chaque quipement conserve un contexte de la
connexion en cours, ce qui nest pas le cas de SIP, o chaque transaction (requte/rponse) est indpendante des autres.

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur, trait Rseaux

_________________________________________________________________________________________________________________ TLPHONIE INTERNET

3.2.2 Flexibilit
Un systme de tlphonie Internet, pens pour un dploiement
mondial et lmergence dapplications non encore envisages, se
doit tre flexible afin de suivre les volutions probables des besoins.
Lvolution de H.323 passe par la dfinition de nouvelles versions
de la norme, ajoutant des fonctionnalits supplmentaires, offrant
des procdures simplifiant la signalisation, etc., tout en respectant
la compatibilit ascendante (une nouvelle version est compatible
avec les versions antrieures).
H.323 autorise lintgration dextensions propritaires, grce
des champs paramtre non standard insrs dans la syntaxe
ASN.1, identifis par un code de fabricant suivi du paramtre opaque quil souhaite ajouter. Ces extensions sont ainsi limites aux
endroits dans la syntaxe ASN.1 o elles ont t prvues et la contrainte de compatibilit ascendante ne permet pas de modifier cette
syntaxe. Cela peut tre problmatique lorsque, par exemple, une
nouvelle valeur pour un paramtre existant est souhaite, et
quaucun champ dextension propritaire nest disponible. Par
ailleurs, lopacit de ces champs limite considrablement les possibilits dinteropration entre quipements htrognes. Lapproche
de lIETF est diffrente et passe par lajout de types de champs denttes dans les messages. Le comportement par dfaut tant dignorer un en-tte non reconnu, la compatibilit ascendante est automatiquement prserve. Ces nouveaux en-ttes doivent tre avaliss
par lIANA (Internet Assigned Numbers Authority), ce qui procure
aux fabricants une moins grande libert de manuvre, mais permet
linteroprabilit.

3.3 Services
Les services de tlphonie avancs offerts par H.323 et SIP sont
analogues, quoique plus complets dans le cadre H.450.x (lajout de
nouveaux service est constant dans les deux communauts, il est
donc difficile doprer une comparaison). Sur le plan de lchange et
de la ngociation de capacits, les fonctionnalits apportes par
H.323 sont nettement plus riches, grce aux mcanismes de H.245,
plus aboutis que le simple usage de SDP.
Le contrle dappel par un tiers (usager A tablissant et contrlant
une communication entre deux usagers B et C) nest disponible que
dans lapproche SIP.
Enfin, sur le plan de la qualit de service des flux audiovisuels
changs, les deux approches font rfrence des mcanismes
externes, tels que RSVP. Notons que la version 3 de H.323, non
encore finalise, prvoit la ngociation de paramtres de qualit de
service lors de ltablissement dappel. Cette ngociation qui nest
pour linstant pas prvue dans SIP pourrait tre mise en uvre au
moyen de SDP.

4. Enjeux de la tlphonie
Internet
Le domaine encore jeune de la tlphonie Internet reoit une
attention considrable de la part de nombreux acteurs du secteur
des tlcommunications. Le fait nest pas surprenant dans la
mesure o ce domaine est considr comme prcurseur de nouvelles modalits de communications interpersonnelles assistes par
ordinateurs. Dans ce contexte, lInternet constitue le medium le plus
naturel, car, rseau unique vhiculant tous types de donnes, il
rpond au souci dintgration de services et offre lopportunit de

rductions massives des cots dinfrastructures. Sur le plan applicatif, lusage dInternet permet aisment de combiner communications vocales et autres modes de communication, synchrones ou
non : les navigateurs World Wide Web peuvent ainsi sinterfacer aux
applications de tlphonie pour permettre un usager dinitier une
communication simplement en cliquant sur un hyperlien particulier
(appel dun agent commercial pour un complment dinformation
ou une commande par exemple). Les applications partages, de
type travail coopratif, peuvent inclure des mcanismes similaires
permettant une synchronisation gomtrie variable de lexcution
des tches. Les applicatifs destins la surveillance en gnral
(monitoring) seront susceptibles de joindre un oprateur humain en
cas de besoin. Lordinateur individuel (ventuellement rduit un
produit nomade) pourra constituer, de par ses potentialits en terme
dinterface homme-machine, le point central du rseau de communications tiss par tout un chacun, filtrant les appels en leur assignant une priorit (fonction de lappelant, du sujet, de la localisation
gographique, ou tout autre critre...), les routant vers une messagerie texte, vocale ou vido, initiant des sessions de confrence la
demande, invoquant un serveur de contenu, etc.
Lmergence et le succs de cet ensemble dapplications futures
requiert vraisemblablement de lInternet quil volue selon plusieurs axes [2]. En premier lieu, la qualit globale, perue par lusager, des services de communication, doit tendre vers les standards
actuels de lindustrie tlphonique. Qualit perceptuelle du son, qui
dcoule du dbit disponible et de ses variations, du taux derreurs
subi par la transmission, du dlai dacheminement des paquets de
donnes. Qualit au sens plus large aussi, englobant les notions de
disponibilit, de probabilit dinterruption dune communication en
cours et de rejet ou de non aboutissement dune requte dtablissement de connexion, dlai dtablissement, facilit dadressage et
services dannuaires associs, ou encore capacit du systme
trouver un correspondant sur le rseau sil y est raccord. Nombre
de ces critres sont du ressort de loprateur applicatif, mais certains peuvent bnficier de ladjonction lInternet actuel de mcanismes grant la qualit de service au niveau rseau de paquets
(diffrentiation de services par exemple). La tarification de ce service amlior est galement mettre en place, puisquelle constituera vraisemblablement llment rgulateur de la fourniture de
qualit de service. Laccroissement de la fiabilit de certains quipements dans le rseau peut aussi rpondre certains critres. Sur un
plan diffrent, il faut noter que de nombreuses applications de communication interpersonnelle requirent de lusager quil soit joignable, cest--dire connect au rseau et susceptible de prendre un
appel, tout instant. lheure actuelle, de nombreux usagers
dInternet, utilisant un accs tarif la dure, ne rentrent pas dans
cette description, et il faut envisager une volution des modalits
daccs au rseau de paquets (accs forfaitaire illimit dans le
temps).
Les normes doivent elles aussi voluer, pour intgrer des fonctionnalits plus labores et souvrir, en terme dinteroprabilit.
Dans le monde H.323, de nombreux axes sont actuellement
ltude ; citons le dveloppement de protocoles pour linteraction de
gatekeepers, intra ou inter-domaines, lusage des technologies
H.323 dans les backbones ou curs de rseaux tlphoniques,
lintgration de procdures pour le contrle dquipement distance (pilotage dune camra, prise de contrle dune application...),
ladjonction de transfert de document de type fax, ou encore la conception de Management Information Bases (MIB) ddies aux protocoles et aux systmes H.323, et permettant leur administration
laide doutils standards de gestion de rseau. Ct SIP, les dveloppements les plus intenses concernent la notion de passerelle, avec
MEGACO et IPTEL. Laspect tarification est aussi ltude, de mme
que le transport de la signalisation du rseau tlphonique commut par un rseau IP (backbone IP).

Toute reproduction sans autorisation du Centre franais dexploitation du droit de copie est strictement interdite.
Techniques de lIngnieur, trait Rseaux

IP 2 960 11