Antoine Delley, EIA-FR, dpartement des technologies de linformation, delley@eif.ch
es rseaux de tlcommunications reprsentent
lpine dorsale informationnelle des entreprises et, par extension, de lconomie. En raison de la forte concurrence qui rgne dans le domaine des tlcommunications, loffre en technologies daccs et en services est trs large. Malheureusement, elle pche souvent par manque de transparence. Du 18 au 22 octobre 2002, un symposium international destin aux responsables de la planification et de lexploitation dinfrastructures publiques de tlcommunications a livr un aperu de la situation. Des reprsentants de plus de trente pays, invits par lUnion internationale des tlcommunications (www.itu.org), ont particip ce symposium mis sur pied par ICTnet (www.ictnet.ch) et lEIA-FR (www.eif.ch).
Architecture du rseau Le rseau peut tre subdivis en deux parties distinctes, le rseau de transit et le rseau daccs (fig. 1). Les exigences poses par les applications ont une incidence directe sur les technologies qui seront mises en uvre, aussi bien au niveau de lpine dorsale que sur laccs dusager.
Un rseau universel doit satisfaire un faisceau dexigences, souvent contradictoires. Le principal dilemme est la priorisation des applications en temps rel par rapport au transfert de donnes. La tlphonie et les applications multimdias de communication synchrone requirent des caractristiques temps rel. Le temps total de transfert de linformation entre deux interfaces dusagers ne devrait pas dpasser 200 ms sur une liaison intercontinentale, codage de linformation compris. Cette exigence ne peut pas tre satisfaite par les rseaux IP conventionnels, sans mcanisme de contrle de la qualit de service. De telles applications fonctionnent gnralement avec un dbit constant (p. ex. 64 kbit/s pour la parole code selon G.711). Elles tolrent sans difficult un temps dtablissement de la communication de plusieurs centaines de ms. Le transfert de donnes et les applications Internet traditionnelles sont beaucoup plus tolrantes eu gard la transparence temporelle. Elles gnrent des dbits variables, de quelques bits/s plusieurs Mbits/s. Elles sont, par contre, trs sensibles au temps dtablissement de la communication.
fiig.1 Architecture du rseau
FI 1 - 21 janvier 2003 page 3
Rseaux IP voix et multimdia sur IP
Diffrentes qualits de service peuvent tre implmentes sur les rseaux IP. La version la plus simple est la qualit Best effort, cest--dire, sans gestion aucune de la qualit. Ce cas est le plus rpandu dans les Intranets et il est gnralis sur lInternet. A lautre extrme, les rseaux IP peuvent offrir un service garanti, avec rservation des ressources.
La communication multimdia est possible sur divers
types de rseaux. Afin dassurer la compatibilit entre applications, lUIT (Union Internationale des Tlcommunications) et lIETF (Internet Engineering Task Force) ont labor des familles de standards regroups sous les appellations gnriques H.32x, SIP (Session Initiation Protocol) et MGCP (Media Gateway Control Protocol).
Concept VoIP bas sur H.323
Avec H.323, lUIT a spcifi un environnement complet de protocoles de communication multimdias pour les rseaux IP. Linterfonctionnement avec les autres rseaux est garanti car des standards apparents ont t conus: H.320 pour le RNIS et H.324 pour le rseau tlphonique analogique. H.323 est support par la quasi-totalit des constructeurs. Il est, pour cette raison, trs largement utilis comme protocole dinterfonctionnement.
fig. 2 types de qualits de service dans les rseaux IP
La figure 2 livre une vue densemble des diverses qualits de service et des mcanismes mis en uvre pour y parvenir. Ce tableau donne un aperu rducteur. Il naborde que les mcanismes mis en uvre tout au travers du rseau, entre ses points dextrmit. En plus, pour offrir une qualit de service donne, il ne suffit pas de mettre en place un mcanisme une seule couche. A titre dexemple, la mise en uvre de services synchrones pour des applications en temps rel, comme la tlphonie, requiert non seulement lusage des protocoles RTP/RTCP, mais galement des mcanismes de priorisation et de rservation des ressources dans les couches infrieures.
Voix et multimdia sur IP
Jusque vers le milieu des annes 90, les organismes de normalisation ont tent de transmettre les donnes de manire toujours plus efficace sur des rseaux conus pour la tlphonie. A partir de cette date, il y a eu changement de paradigme. Cest sur les rseaux de donnes, en particulier sur lInternet, que lon sest vertu convoyer la parole. Il a donc fallu dvelopper des algorithmes de codage audio plus tolrants et introduire des mcanismes de contrle de la qualit de service dans les rseaux de donnes.
fig. 3 topologie dun rseau VoIP (Voice over IP)
FI 1 - 21 janvier 2003 page 4
fig. 4 architecture des protocoles selon H.323
Dans un environnement H.323, ltablissement de la communication est effectu au moyen du protocole Q.931, le mme que dans le RNIS. Le protocole RAS (Registration, Admission and Status) sert lenregistrement des quipements terminaux et au contrle dadmission la communication. H.245 permet de commander les applications de bout en bout. Les applications de donnes se servent de T.120, alors que laudio et la vido disposent de plusieurs types de codecs. La figure 5 illustre la procdure dtablissement dune communication multimdia point point dans un environnement IP. La premire phase se sert du protocole H.225/RAS. Le terminal qui lance ltablissement requiert, au pralable, lautorisation de la part du portier. Ensuite, par lintermdiaire du protocole Q.931, il ouvre la connexion vers le partenaire. Le partenaire doit galement demander son admission au portier, avant de confirmer ltablissement de connexion. Lorsque les deux terminaux ont achev la phase de connexion, une phase dchange de paramtres, base sur H.245, se droule. Aussitt que le canal logique est disponible, la communication audio et vido peut dbuter. Elle utilise les protocoles RTP (Real Time Protocol) et RTCP (Real Time Control Protocol). La libration de connexion H.323 dbute par une phase de dconnexion entre points dextrmits. Ensuite, chaque terminal informe le portier de la fin de la communication. Les ressources du rseau sont, ds lors, nouveau disponibles pour lensemble des usagers.
Rseaux IP voix et multimdia sur IP
Concept VoIP bas sur SIP (Session Initiation
Protocol) Lchange des messages de signalisation et de contrle du protocole SIP est effectu sous la forme de transactions. Il est apparent au protocole HTTP. Une transaction est compose dune requte et dune rponse. Les requtes sont toujours mises par un client et les rponses par un serveur. Cette mme structure client-serveur va se retrouver dans les terminaux, le serveur denregistrement, le proxy et le serveur de re-direction.
fiig. 7 architecture des protocoles selon SIP
fig. 5:tablissement de connexion au moyen du protocole
H.323
fig. 6 libration de connexion dans H.323
fig. 8 tablissement et libration dune connexion au moyen du protocole SIP FI 1 - 21 janvier 2003 page 5
Rseaux IP voix et multimdia sur IP
Dans la figure 8, la demande dtablissement contient les adresses de destination et de source en format SIP, de mme que les paramtres c et m. Le paramtre c dfinit les coordonnes pour le flux audio qui sera mis vers lusager Frey. Ce flux sera transmis au moyen du protocole IP version 4, vers ladresse IP 172.190.30.24. Le paramtre m indique quil sagit dun flux audio qui utilisera le port UDP 49150 et le protocole RTP. Il requiert lalgorithme de codage audio G.723.1 (valeur 4). Dans le sens oppos, le codage audio est de type GSM (valeur 0).
tue au moyen des messages DLCX (Delete Connection) et
ACK, pour le protocole MGCP, et de REL (Release) et RLC (Release Complete), pour le SS7.
Concept VoIP bas sur MGCP (Media Gateway
Control Protocol) Le protocole MGCP sert lchange de message de signalisation entre un contrleur de passerelles de mdias et des passerelles rparties dans un rseau IP. Pour ltablissement et la libration des connexions, MGCP se sert de signaux et dvnements. La standardisation de MGCP a t stoppe pour faire place MEGACO/H.248 (MEdia GAteway COntrol protocol), protocole labor en collaboration entre lIETF et lUIT. Ce nouveau standard ntant pas driv de MGCP, la migration vers MEGACO/H.248 semble trs difficile.
fig.10 tablissement et libration de connexion au moyen du
protocole MGCP
fig 9 architecture des protocoles selon MGCP
Dans lexemple de la figure 10, une connexion entre deux rseaux RNIS transite par un rseau IP. Le contrleur de passerelles contient galement la fonctionnalit de passerelle de signalisation. Les passerelles de mdias convertissent les flux de paquets IP contenant le signal audio en des flux synchrones 64 kbit/s, et inversement. La signalisation mise en uvre entre le RNIS et la passerelle de signalisation est base sur le systme de signalisation no 7 (SS7). La commande des passerelles de mdias est faite au moyen du protocole MGCP. Suite au message dtablissement IAM (Initial Address Message) du protocole SS7, le contrleur de passerelles ordonne louverture dune connexion avec les messages CRCX (Create Connection) et transmet le message IAM vers sa destination. Louverture de connexion est confirme avec les messages ACK (Acknowledge). Le message MDCX (Modify Connection) permet de transmettre la passerelle de gauche le numro de port UDP choisi par la passerelle de droite. Les messages ACM (Address Complete) et ANM (Answer Message) du SS7 permettent dindiquer de bout en bout que la sonnerie retentit, respectivement, que lusager appel a rpondu. La libration de la connexion est effecFI 1 - 21 janvier 2003 page 6
Dans un prochain article, nous dcrirons et comparerons
les diffrentes technologies d'accs aux rseaux (RNIS, xDSL, cble TV, cbles d'nergie, UMTS, boucle locale radio, LAN sans fil public, satellite,).
Erratum Larticle Dploiement dune grille de calcul lEPFL: vers un plan durbanisme du 17 dcembre 2002 donnait ladresse du site e-scale pour lchange dinformations destin aux personnes qui sintressent ce type de dveloppement. Une faute de frappe sest malencontreusement glisse dans le texte, nous vous redonnons ici ladresse exacte : http://www2.epfl.ch/e-scale. Avec nos excuses. Marie-christine.Sawley@epfl.ch
