31

Téléphonie sur Internet :quelles perspectives ?

Patrice ColletMichel DudetOlivier HersentEtienne Turpin

Patrice Collet, X65, ENST 70 est directeur des architectures et de la planification à la BrancheRéseaux. Auparavant, il a dirigé le centre Lannion Adu CNET et avait été l’un des principaux acteurs à l’origine du concept de Réseau Intelligent.

Michel Dudet, diplômé de l’Ecole Nationale Supérieurede Physique (1980), chef de département au sein du groupement “services de courrier électronique” duSEPT de Caen, responsable du pôle de compétence“Internet” du CNET. Il a commencé sa carrière au CNETLannion en 1982 sur les systèmes de transmissionnumérique.

Olivier Hersent, X91, ENST 96 a débuté au CNET en 1995 en se spécialisant sur les évolutions desréseaux IP, notamment la mise en œuvre des servicestemps réel et sur la multidiffusion. Il est l’auteur deplusieurs communications sur la téléphonie IP.

Etienne Turpin, X71, ENSAE, est chef du Service des études Economiques et Technico-économiquesdu CNET, Branche Développement, service chargédes études sur les coûts et la rentabilité des produitset techniques innovants. Il est professeur associé àl’ENST, et membre du Conseil national del’Information Statistique.

32

La téléphonie sur Internettrouve sa finalité dans l’intégration de servicesen temps réel.

Mais encore faut-il s’orienterdans la jungle des normes et maîtriser la complexitédes protocoles.

n la seconde, celle des Services, est marquéepar l’accélération de l’innovation, la multiplicationdes services et la pluralitédes réseaux.

Introduction

Les technologies de l’information apportentrégulièrement leur lot d’innovationsouvrant de nouvelles possibilités de communication. Si l’on conçoit bien lesavantages qu’elles peuvent nous apporteren théorie, il est cependant délicat de planifier concrètement leur impact sur les produits et services du marché. Ainsi,l’année de la messagerie électronique a-t-elle été longtemps annoncée avant que ce mode d’échange ne commence à passer dans les mœurs, ou encorel’année du “groupware”.

1998 sera t-elle l’année de la téléphoniesur Internet ?

Cette question cache en fait de multiplesenjeux majeurs susceptibles chacun debouleverser la donne.

Enjeux commerciaux : le support Internetest perçu comme “gratuit” par l’utilisateur.Mais qui supporte réellement les coûtsd’un service et quels sont-ils ? Quels sontles différents modèles économiques etchaînes de valorisation (ex. le “flat rate”est-il viable) ? Quel rapport qualité/prixles utilisateurs souhaitent-ils : tout commele Web est traité de “World-Wide Wait”, latéléphonie Internet risque-t-elle de devenir“cacophonie sur Internet” ?

Enjeux réglementaires : un opérateur deservices vocaux sur Internet doit-il êtreconsidéré comme un opérateur d’interconnexion téléphonique et respecteren temps que tel la réglementation dupays concerné ?

Enjeux d’usages : quelle ergonomie est acceptable par les utilisateurs, quelest l’impact des PC multimédia, utilisationprivative ou professionnelle ?

Enjeux techniques, enfin : délais dus à la nature du codage et du réseau quiempêchent un véritable mode conversationnel, traitement de l’écho, procédures d’acheminement, annuaires, interopérabilité, couverturegéographique, etc.

Après avoir brièvement rappelé le contextetechnico-économique qui a favorisé l’éclosion de la téléphonie IP, le présentdocument s’attache à clarifier de quelsservices on veut parler car le concept de“téléphonie sur réseaux IP” peut prendreen fait de multiples formes : c’est l’objetdu chapitre sur “Quels service pour unopérateur” qui se place délibérément du point de vue d’un opérateur de télécommunications, sachant que des éditeurs de logiciels ou des constructeurspeuvent envisager d’autres types produits.

Le reste du document se concentre surles enjeux techniques, (chapitre sur les“Problèmes techniques à résoudre”) et les solutions d’architecture proposéespour les résoudre en se concentrant surles équipements terminaux et serveurs (chapitre sur l’“Architecture”). Les techniques des réseaux IP pour le transport de flux temps-réel sont ensuitebrièvement abordées dans le chapitre traitant de l’“Impact majeur des infrastructures réseaux”. Enfin le dernierchapitre présente quelques élémentsd’analyse économique.

Téléphonie sur Internet : quelles perspectives ?

33

Génèse de la téléphonie IP

Les composantes du succès

Temps réel sur LAN

Les applications temps réel sur LAN sontapparues depuis le début des années 80 :un réseau disposant d’une bonne bandepassante (e.g. un réseau Ethernet à 10 Mbit/s peu chargé) allié à la puissanced’une station de travail effectuant lecodage permet des échangesaudio/vidéo.

C’est sur ce créneau que commence à sedévelopper le savoir faire de petits éditeursde logiciels spécialisés.

Essor du CTI

En parallèle, on assiste à la naissanced’une industrie liée à l’intégration de latéléphonie et de l’informatique : cartes àprocesseurs spécialisés pour la commande d’appel à partir d’un micro-ordinateur, l’intégration de boîtes de messagerie vocale, etc.

Mbone

Le développement d’applications de voixet vidéo sur Internet est lié à celui duréseau Mbone dont le nom correspond à la contraction de Multicast Backbone. Il s’agit d’un réseau de diffusion mutipointcréé à l’origine pour un besoin interne de l’IETF qui désirait pouvoir diffuser envisioconférence ses réunions afin de pouvoir joindre ses correspondants empêchés de se déplacer. La techniqueMbone fut conçue au Xerox Parc sous laconduite de Steeve Deering puis adoptéeà l’IETF mi-1992.

Il s’agit en fait d’un réseau superposé auréseau Internet classique ou les paquetsmulticast sont encapsulés dans despaquets IP classiques, puis traités dansles routeurs capables de les exploiter. Ce réseau était techniquement nécessairepour éviter de saturer le réseau classiqueen envoyant autant de flux audio/vidéo

(gourmands en bande passante) que dedestinataires : la solution consistait àregrouper les flux qui empruntent unemême route puis à les expanser dans desrouteurs “multicast” au fur et à mesureque les routes divergent pour joindre ledestinataire final.

Depuis 1993, le Mbone a constitué un terrain d’expérimentation naturel pour lesprotocoles de transmission temps-réelainsi qu’au sein du groupe IETF créé spécialement à cet effet : Audio-VidéoTransport Working Group (AVT-WG).

Les codeurs à bas débit (tableau 1)

Les codeurs de parole utilisés dans leslogiciels de téléphonie IP peuvent êtreclassés suivant trois grandes techniquesde codage :n techniques temporelles (débits comprisentre 16 et 64 kbit/s),n techniques paramétriques (débits entre2.4 et 4.8 kbit/s),n techniques par analyse et synthèse(débits entre 5 et 16 kbit/s ).

Les deux dernières catégories présententl’avantage de faibles débits, mais plus le taux de compression est fort, plus le retard induit par le processus de traitement est important (cf. chapitreannexe pour plus de détails sur lescodeurs).

Les tableaux suivants regroupent, pour la majorité des codeurs mentionnés précédemment, les caractéristiques principales en terme de débit, de qualitéde parole en MOS (Mean Opinion Score) :la note moyenne d’opinion MOS est établie de manière standardisée suivantcinq catégories : 1 = Mauvais, 2 = Médiocre, 3 = Moyen assez bon, 4 = Bon, 5 = Excellent, pour des conditions sans bruit de fond (cleanspeech), de complexité de réalisation (en MIPS DSP 16 bit fixe) et de retard de codage/décodage.

Codeur Temporel Temporel Analyse/Synthèse Analyse/Synthèse ParamétriquePCM MICDA RPE-LTP CELP LPC

Standard/norme G.711 G.726 ETSI GSM 06-10 DOD FS1016 DOD LPC10FS1015

Débit 64 kbit/s 32 kbit/s 13 kbit/s 4.8 kbit/s 2.4 kbit/s

Qualité de parole (MOS) 4.2 4.0 3.6 3.5 2.3

Retard codeur+décodeur 125 ms 300 ms 50 ms 50 ms 50 ms

Complexité Mips 0.1 12.0 2.5 16.0 7.0

Codeur Analyse/Synthèse Analyse/Synthèse Analyse/SynthèseLD-CELP CS-ACELP MP-MLQ-ACELP

Standard/norme G.728 G.729 G.723.1

Débit 16 kbit/s 8 kbit/s 6.3 et 5.3 kbit/s

Qualité de parole (MOS) 4.0 4.0 3.9/3.7

Retard codeur+décodeur 3 ms 30 ms 90 ms

Complexité Mips 33.0 20.0 16.0

Tableau 1 - Caractéristiques des codeurs de parole pour la téléphonie IP.

34

L’apparition des standardsLa première application d’audioconférencesur Mbone, dénommée Visual Audio Tool(VAT) a été développée par Van Jacobsonau Lawrence Berkeley National Laboratory(LBLN) : c’est à l’occasion de ces travauxqu’à été défini et testé le protocole detransport temps réel RTP (cf. descriptiondétaillée plus loin). RTP est approuvé fin1995 comme proposition de standardIETF, puis début 1996 comme standard.Cette stabilisation du protocole déclenchel’adhésion des grands éditeurs dontNetscape, Microsoft et le pionnierVocaltec.

Mais RTP assure seulement un moyen de reconstituer des flux temps réel sur IP(voir le paragraphe sur le “RTP/RTCP”), il ne garantit pas la fiabilité du transport, ni encore moins un véritable service.

La définition d’un protocole de réservationde ressources dans les routeurs, RSVP,laisse précisément entrevoir des possibilitéde réserver l’équivalent d’un circuit virtuelsur les réseaux IP, garantissant ainsi untransfert temps-réel fiable.

Enfin, un standard complet de serviceapparaît avec la finalisation par l’UIT-T dela Recommandation H.323, adaptationdes normes de visioconférence RNIS auxréseaux locaux sans connexion. Cettenorme et vigoureusement promue parMicrosoft et Intel début 1997 pour l’imposer comme standard d’échangetemps réel sur Internet, entraînant dansleur sillage une majorité d’éditeurs de logiciels.

La promotion par des forumsL’année 1996 voit en outre se créer plusieurs forums traitant d’applicationstemps-réel sur IP :

n Création par le MIT d’un consortiumvisant à étudier les conditions techniqueset économiques de mise en place de latéléphonie sur Internet et de lancer desexpérimentations à l’échelle internationale.

n Mise en place de la coalition “Voice Onthe Net” (VON) des nouveaux offreurs de produits et de services de téléphoniesur internet et le dépôt auprès de la FCCaméricaine d’une plainte pour concurrencedéloyale par l’association des opérateurslongue distances ACTA .

n Le forum Voice over IP, similaire à VON,a fusionné en novembre 96 avec l’IMTC(International Multimedia TeleconferencingConsortium), forum bien connu dans ledomaine de la visioconférence, pour créerun groupe spécial d’activité autour de latéléphonie IP : il regroupe les principauxoffreurs de produits de téléphonie IP (dontMicrosoft, Nortel et Cisco).

n Début 1997, l’ETSI crée un projet spécifique, TIPHON, étudiant l’intégrationde la téléphonie IP avec les réseauxpublics commutés (RTC, RNIS, GSM).

L’apparition des produits

Logiciels pour PCL’explosion d’Internet avec le Web début1995, conjuguée à la montée en puissanceconsidérable des processeurs pour PC (loi de Moore oblige) conduit les éditeursde logiciels disposant d’un savoir-faire sur LAN à proposer des produits pourInternet, relayés bientôt par les poidslourds du marché imposant le standardH.323. L’utilisation de ces logiciels parquelques utilisateurs pionniers relève alors d’un comportement assimilable àceux des radios amateurs : on rentre en relation avec des correspondantsinconnus à l’autre bout du monde au prixde manipulations pointues.

PasserellesMais c’est l’apparition de passerelles avec le réseau téléphonique standard quiconsacre l’avènement du concept de voixsur Internet : elle permet en effet des’appuyer sur le parc des téléphones ordinaires. On s’adresse ainsi au plusgrand nombre, tout en bénéficiant à lamarge de la connectivité quasi-gratuited’Internet.

Ces passerelles sont généralementbasées sur des cartes DSP (Digital SignalProcessor) développées à l’origine par lesindustriels du domaine CTI. Ces cartes,implantées en général sur des systèmesde type PC WindowsNT ou dans des routeurs d’accès, permettent de gérer un grand nombre de voies téléphoniques(typiquement jusqu’à une centaine parmachine).

Les premiers services Avec l’apparition des passerelles, plusieursopérateurs de “callback” ou de revente de capacité se lancent dans des servicesde téléphonie IP en déployant des pointsde présence à l’International dans desgrandes villes.

Aux USA, on assiste également à la valorisation d’infrastructures alternativesavec ce type de service (e.g. réseau de fibresoptiques d’un transporteur ferroviaire).

35

Quels services pour un opérateur

Pour bien analyser le phénomène de latéléphonie IP, il convient tout d’abord declassifier les différents services possibles.Toutefois une telle démarche peut donnerdes résultats différents suivant le point devue où l’on se place : éditeur de logiciels,fabriquant de périphériques, constructeurd’équipements de télécommunications, SSII,opérateurs de services à valeur ajoutée, etc.La démarche qui suit se place du point devue d’un opérateur de télécommunications.

PC multimédia sur Internet

Il suffit de posséder un PC multimédiaéquipé au moins d’un micro, d’un haut-parleur, d’une carte son (full-duplexpour une conversation simultanée), d’unmodem et de disposer d’un abonnement à un fournisseur d’accès Internet. La communication est directe de PC à PC : il faut donc connaître l’adresse IP du destinataire (codée sur 4 octets numériques)et non pas seulement son adresse logiquedu type “Dupont@reseau.fr”. Pour ce faire,on utilise un serveur d’annuaire en ligne oùl’on s’enregistre à chaque communication.

Les premiers logiciels étaient incompatibles entre-eux, mais début 97sont apparus les premiers standardsautour des éléments H.323 et T.120conçus à l’origine par l’Union Internationaledes Télécommunications (UIT) pour la visioconférence sur réseau local informatique. Tous les logiciels ont tendance à s’aligner désormais sur cesstandards.

Ces logiciels sont véritablement multimédia,c’est-à-dire que la voix et la vidéo sontintégrées à un ensemble d’applications de données comme le transfert de fichier,la messagerie, etc.

Ils permettent également de prendre lecontrôle d’une application sur le PC distant, cequi ouvre un champ important d’utilisationspossibles comme le télé-enseignement, la maintenance à distance, etc.

Les principales limitations pour ce typed’utilisation sont dues à l’incapacité duréseau Internet à garantir un transfertfiable et rapide de l’information, provoquant une piètre qualité d’écoute (il reste toutefois possible de mieuxcontrôler les liens de transit vers des fournisseurs d’accès partenaires par desaccords bilatéraux). L’utilisation desannuaires en ligne s’avère également problématique lorsque la population d’utilisateurs croît.

Le marché de ce type de services’adresse aux clients des fournisseursd’accès Internet (comme Wanadoo) quisont assez naturellement équipés d’un PCmultimédia (cf. récente explosion desventes en France). Le moteur est essentiellement le gain de coût pour lesutilisateurs : il est particulièrement fortpour les communications internationales.

PC multimédia surIntranet

Dans ce cas, le réseau intranet de l’entreprise vient se substituer à Internetet les limitations précédentes sont en partie levées. La gestion des routeurs etle dimensionnement du réseau sont alorssous le contrôle d’un seul opérateur pourles besoins d’une entreprise, permettantainsi de mieux gérer les problèmes decongestion et de file d’attente propres à IP.

Il faut savoir en effet que le temps detransfert d’un “paquet” IP dans un routeurest fonction du volume de données globalque celui-ci doit écouler. Plus un réseauest chargé, et plus le temps de transfertsera long. Afin d’éviter un effet d’avalanche, le protocole IP prévoit ainside se débarrasser automatiquement despaquets qui ont séjourné trop longtempsdans le réseau.

Ce contrôle d’un réseau intranet a un coût. La logique qui prédomine ici n’estdonc plus de réduire les coûts, maisd’offrir de nouvelles fonctionnalités grâceaux capacités d’IP d’intégrer voix, vidéo et données, et à l’avènement des PCs multimédia permettant aux utilisateurs de partager virtuellement un espace detravail complet.

A noter toutefois que la traversée despare-feu de l’entreprise (firewalls) peuts’avérer problématique, d’une part parceque ces derniers introduisent des retardsdus à l’analyse des paquets, d’autre partparce que le standard H.323 utilise desports UDP établis de façon dynamique(voir plus loin), souvent incompatiblesavec la gestion des tables de contrôled’accès des pare-feu.

Le marché est ici celui des applicationsIntranet et le moteur est le gain de productivité des entreprises mettant en œuvre cette nouvelle forme d’échange.

Internet

Annuaire

Figure - 1Communicationdirecte de PC à PC.

36

Service téléphonique IP(fig. 2)

Tout le monde n’étant pas forcémentéquipé d’un PC, une évolution importantedu premier type de service est apparuelorsque le codage/décodage de la voixsur IP a été mis en œuvre sur des serveurs (et non plus sur des terminauxPC) assurant une fonction de passerelleavec les réseaux téléphoniques classiques.

Cette configuration permet aux utilisateursde terminaux téléphoniques (ou de télécopieurs) de bénéficier des bas prix du transfert de données sur les réseaux IP.L’avantage est donc économique, surtoutà l’international (cf. plus loin le chapitreconsacré à ”Quelques éléments d’analyseéconomique”).

L’opérateur du service constitue un réseaudont les passerelles forment des pointsde présence locaux. Elles sont reliéesentre elles par un réseau sous contrôle de l’opérateur permettant le respect desdébits et des délais.

Le marché est celui des communicationstéléphoniques internationales et le moteurprincipal est le coût pour le client.

Les points critiques concernent l’acceptabilité du service par l’utilisateurfinal : rapport qualité-complexité/coût (en particulier il n’est pas rare dans lesproduits actuels d’avoir à numéroter plusde 30 chiffres), le traitement de l’écho, la mise en place de nouvelles procéduresde gestion et facturation du service adaptées aux nouveaux marchés etusages induits par Internet, l’évolutionlente des passerelles vers des standardsd’interopérabilité et la prise en compte de la télécopie qui ne supporte pas lesmêmes règles de codage (voir plus loin).

Réseaux voix-donnéesd’entreprise (fig. 3)

Ce type d’offre correspond à la transposition sur intranet des services de réseaux voix/données d’entrepriseexistants déjà sur d’autres types d’infrastructure (ex. liaisons spécialiséesou relais de trames).

Les passerelles sont raccordées aux PBXdes entreprises (certains constructeurs

prévoient même une offre intégrée au PBX)en leur permettant d’écouler leur trafictéléphonique inter-site et leurs donnéessur un même réseau (gain économique).

La encore, les principales difficultés techniques concernent la perception de la qualité par rapport au coût engendrépar la mise en place de mécanismes decontrôle de flux dans le réseau, la gestionde plans de numérotation cohérents et latraversée des pare-feu.

Intranet

RTC

RTCPasserelle

Passerelle

Domaine opérateur

Télécopieur

PBX

Paris

PBX

New-Yorkou Tokyo

Site 1 Site 2

Paris

Marseille ou

New-York

Intranet

Passerelle Passerelle

PBX PBX

Figure 2 - Service téléphonique sur IP.

Figure 3 - Réseau voix-donnéesd’entreprise.

37

Intégration téléphonie et Web (fig. 4)

Les fortes capacités d’intégration de service apportées par IP ont donné lieu à un mariage réussi avec le Web.

Les débouchés sont très divers en termesd’applications.

Notamment en associant des équipementstraditionnels des centres d’appels (lesAutomatic Call Distributors, sorte de PBXspécialisés) avec une passerelle du mêmetype que celle utilisée dans le service précédent mais en fonctionnement “net to phone”, on permet aux utilisateurs duWeb de rentrer directement en contactavec un service clients. Les applicationssont nombreuses, tant dans le domainegrand-public avec le commerce électronique et l’après-vente que dans le domaine de l’entreprise et son systèmed’information (assistance informatique,annuaire appelant, etc.).

France Télécom est déjà présent sur lecréneau des centres d’appels et répond à des appels d’offre sur mesure.

En ce qui concerne la déclinaison “intranet” du Web et de la téléphonie IP,des expérimentations diverses serontmenées en 1998 en interne en les appliquant à l’Entreprise France Télécomelle-même afin de mieux appréhender lesusages et les techniques et en fairebénéficier ses clients.

Problèmes techniquesà résoudre

Délai de transmission

Celui-ci est très important pour bénéficierd’un véritable mode conversationnel etminimiser la perception d’écho (similaireaux désagréments causés par les conversations par satellites désormais largement remplacées par des câblespour ce type d’usage).

Or la durée de traversée d’un réseau IPest dépendante du nombre de routeurstraversés, le temps de traversée d’un routeur étant lui même fonction de lacharge de ce dernier qui fonctionne parfile d’attente.

Les chiffres suivants (tirés de la recommandation UIT-T G.114) sont donnés à titre indicatif pour préciser lesclasses de qualité et d’interactivité enfonction du retard de transmission dansune conversation téléphonique (tableau 2).

Réseau IP

Web

1

2

Passerelle

PBX

ACD

Synthèsevocale

Agent

Centre d’appels

Classe n° retard par sens commentaires

1 0 à 150 ms acceptable pour la plupart des conversations ;seules quelques tâches hautement interactives peuvent souffrir

2 150 à 300 ms acceptable pour des communications faiblement interactives(voir satellite 250 ms par bond)

3 300 à 700 ms devient pratiquement une communication half duplex4 au delà de 700 ms inutilisable sans une bonne pratique de la conversation half duplex (militaire)

Tableau 2 - Classes de qualité UIT pour les retards de transmission.

Figure 4 - Intégration téléphonie et Web.

38

Ces chiffres peuvent être complétés parun indice de difficulté de communicationen fonction du retard par sens :

Echo

Les passerelles doivent également traiterl’écho électrique généré localement par le passage 2 fils vers 4 fils (ruptured’impédance) afin de ne pas perturber le terminal distant.

Il faut en effet savoir que si aucun traitement d’écho n’est effectué, le servicesera inutilisable avec des postes analogiques classiques. En France le phénomène est d’ailleurs particulièrementpréoccupant puisque 50 % des lignes analogiques “produisent” un signal d’échoaffaibli seulement de 15 dB par rapport au signal originel. Or, avec un tel affaiblissement, la qualité de lacommunication (au sens qualité téléphonique) devient inacceptable si le délai de transmission et de commutation excède 25 ms par sens(recommandation G.131 de l’UIT) (fig. 5).

Les retards importants des logiciels detéléphonie IP utilisés en mode full duplexintégral posent aussi des problèmesgraves d’échos acoustiques lorsque l’onutilise le microphone branché sur la carteson et les enceintes acoustiquesmultimédia couramment fournies. Certainslogiciels proposent un contrôle de l’écho en jouant sur le seuil dedéclenchement de la parole et le niveaude suppression d’écho. Mais ils consomment de la puissance processeursupplémentaires et commencent à êtresupplantés par des cartes DSP spécifiques.

Traitement des télécopies

Les télécopieurs ordinaires nécessitent un traitement particulier dans la mesure où le signal analogique émis par leursmodems supporte mal un codage avec compression.

En pratique l’offre existante prend encompte ce type de trafic par des passerelles spécifiques, l’utilisateur appelant la passerelle qui convient, suivant qu’il s’agit d’un appel téléphoniqueou d’une télécopie.

Deux types de services existent pour latélécopie :

n transmission en “store & forward” aumême titre qu’une messagerie qui permetune certaine souplesse (ex. gestion delistes de diffusion sur la passerelle) maisprésente l’inconvénient d’avoir à gérer desaccusés de réception dont les utilisateursde messagerie savent ce que cela représente en complexité et responsabilitépour l’exploitant ; ce premier mode est largement le plus utilisé dans les passerelles existantes (en double numérotation) et pour les terminaux de type PC (expériences de “remote printing”) ;

n transmission avec traitement temps réel des flux ; cela suppose des performances (donc des coûts) accrues,mais l’accusé de réception est géré directement de terminal à terminal, ce qui répond à l’usage courant de la télécopie.

Retard par sens Difficultéde communication

200 ms 28 %450 ms 35 %700 ms 46 %

Pour des conversations téléphoniques dès25 ms par sens, des phénomènes d’échos(électriques) peuvent devenir gênants(l’UIT-T recommande pour un réseau national de ne pas dépasser 50 ms horstemps de transmission pour les systèmesde codage).

Perte de paquets

Lorsque les routeurs IP sont congestionnés,ils “libèrent” automatiquement de la bandepassante en se débarrassant d’une certaine proportion des paquets entrants enfonction de seuils prédéfinis. Cela permetégalement d’envoyer un signal impliciteaux sources TCP qui diminue d’autant leurdébit au vu d’acquittements négatifs émispar le destinataire qui ne reçoit plus lespaquets (algorithme Random EarlyDetection - RED).

Gigue

La gigue correspond à une variation dudélai de transmission de l’information. Elle est due au mode de mise en paquetspar les codeurs, à l’encapsulation despaquets IP dans des protocoles supporttels que le Frame Relay ou l’ATM, et à lavariation de routes dans le réseau :chaque paquet est en effet susceptible de transiter par des combinaisons différentes de routeurs entre la source et la destination. Pour compenser lagigue, on utilise des mémoires tamponsqui présentent l’inconvénient de rallongerd’autant le temps de traversée global dusignal et contribue à empêcher un modeconversationnel normal.

PC multimédia (non générateur d’écho électrique)Abonné perturbé par l’écho créé à l’autre bout.

Téléphone analogique 2 fils (générateur d’écho électrique)Abonné non perturbé par l’écho électrique.

PasserelleRéseau Internet RTC Allo

AlloAllo

CAA

Passage 2 fils/4fils

Figure 5 - Perturbation de la téléphonie sur IP par le phénomène d’écho.

39

Architecture

Après une période de produits propriétaires, les communications voix (et vidéo) sur IP sont désormais basées sur des protocoles standards suivant une architecture en couches.

UDPLes communications de téléphonie surréseaux IP n’utilisent pas la couche de transport TCP (équivalent du transportdéfini par l’ISO) mais la couche UDP (User Datagram Protocol) qui fonctionneen mode non-connecté, c’est-à-dire en envoyant des datagrammes traités de manière indépendante par le réseau.

TCP présente l’avantage de gérer untransfert fiable (réenvoi des paquets IP encas d’erreur) mais est malheureusementincompatible avec un flux temps-réel dansla mesure ou les mécanismes de TCP prévoient une réduction automatique dudébit accordé à l’émetteur en cas decongestion du réseau et une remontéelente vers le débit nominal (ceci afin de protéger le réseau de soubresautsd’émetteurs qui chercheraient tous enmême temps à tirer parti de la bande passante disponible).

UDP est un protocole sans correctiond’erreur (donc non fiable) dont la fonctionessentielle consiste à différencier les différents services applicatifs comme lamessagerie, le transfert de fichiers, le Web,la voix, la vidéo, etc. en les aiguillant vers lebon module de traitement logiciel à l’arrivée.Cet aiguillage s’effectue en associant unnuméro de port à chaque application.

Ceci n’est pas sans incidence sur le passageau travers des équipements de contrôled’accès utilisés sur les intranet/extranetappelés communément “gardes barrières”(firewalls) : à la différence des servicesprécités qui impliquent des communicationsde type client/serveur, les logiciels de téléphonie font intervenir des communicationsclient/client en utilisant des numéros deport disponibles de façon dynamique (voirprésentation de H.323 ci-après).

Or le filtrage des pare-feux (firewalls) lesplus récents repose non seulement sur les adresses IP mais aussi sur le type de service identifié par son numéro de port :les applications de téléphonie IP communiquent donc assez mal en interentreprises.

RTP/RTCP

Pourquoi RTP/RTCP ?RTP a pour but de fournir un moyen uniforme de transmettre sur IP des donnéessoumises à des contraintes de tempsréel, par exemple des flux audio ou vidéo.Sous le nom global RTP on désigne en faitles protocoles RTP et RTCP. RTP permetd’identifier le type de l’information transportée, d’y ajouter des marqueurstemporels et des numéros de séquence et de contrôler l’arrivée à destination despaquets. RTP n’a pas été conçu poureffectuer des réservations de ressourcesoù contrôler la qualité de service.

RTCP est un protocole de contrôle desflux RTP, permettant de véhiculer desinformations basiques sur les participantsd’une session, et sur la qualité de service.Pour une application particulière, il peutêtre nécessaire de compléter RTCP par un autre protocole de contrôle.

Exemple d’une audio conférence

L’application de chaque participant envoiel’information du micro en blocs de 20 msle ou les autres destinataires.

1er problème : chacun pourrait utiliser unformat de codage différent : on indiquedonc le type de codage dans le header(ADPCM, PCM, GSM...), cela permet ausside réagir aux indications de congestion du réseau.

2e problème : on ne peut traiter chaquepaquet reçu comme il arrive, car Internetne garantit ni ordre ni délai : il faut doncajouter un marqueur temporel à chaquepaquet pour reconstituer une séquenceaudio intelligible. De cette manière on peutaussi voir combien de paquets ont été perdus.

3e problème : comment indiquer que desparticipants arrivent où s’en vont ? Pourcela on envoie également en multicast desinformations de contrôle sur qui arrive et quipart ( RTCP). Cela évite de parler tout seul !

Par cette voie un participant peut aussiindiquer sa qualité de réception, permettantà l’émetteur d’adapter son émission.

Le design de RTP et RTCP a été fait pourêtre indépendant des couches réseau ettransport sous jacentes. Sur IP, RTP utiliseun port pair et RTCP le port suivant (impair).

Fonctionnement de RTP

RTP permet l’acheminement de bout enbout de données avec des caractéristiquestemps réel. RTP peut être véhiculé pardes paquets multicast afin d’acheminerdes conversations vers des destinatairesmultiples.

Le rôle principal de RTP consiste à mettreen œuvre des numéros de séquence depaquets IP pour reconstituer les informations de voix ou vidéo même si le réseau sous-jacent change l’ordre despaquets, ce qui est susceptible de se produire dans la mesure où le fonctionnement d’Internet ne garantit pasque deux paquets successifs empruntentla même route. Cela permet, par exemplepour des applications vidéo, de décoderet placer au bon endroit sur l’écran chaquepaquet sans attendre ses prédécesseurset pour des applications de voix dereconstituer les échantillons de parole.

Le rôle de RTP reste donc limité : n RTP ne garantit pas que le paquet vaarriver, RTP n’assure pas que le paquet va arriver à temps, RTP n’assure pas quechaque paquet va arriver en séquence.n RTCP permet de vérifier la qualité deservice et de transmettre des informationssur les participants.n RTP en lui même n’est pas un standarddéfinissant le type de codage employépour l’information transportée. Cette information est décrite dans des descriptions de profils (donnant des codesidentifiant des formats standards) et desdescriptions de formats. En particulier

40

certaines applications peuvent définir pour leur profil des champs de donnéesobligatoires qu’elles considèrent commedes extensions de l’en-tête. Mais pour RTP ces champs supplémentaires sontconsidérés comme faisant partie de l’information transportée.

Eléments d’architecture de RTP

Les principaux éléments qui rentrent encompte dans le fonctionnement de RTPsont les suivants.

n “Payload” : les données temps réeltransportées par RTP dans un paquet (le format du contenu lui même n’est pasdéfini par RTP).

n RTP packet : un paquet de donnéesconstitué de l’en-tête RTP fixe, d’une listede sources participant au flux, et enfin du“payload”.

n RTCP packet : un paquet de contrôleconstitué par une en-tête fixe similaire àcelle de RTP, suivie par des éléments qui dépendent du type de paquet RTCP(formats définis plus loin). Plusieurspaquets RTCP peuvent être envoyés simultanément par le protocole sous-jacent,grâce à l’information de longueur de l’en-tête RTCP de chaque paquet RTCP.

n Port : abstraction permettant de distinguer différentes destinations despaquets sur une même machine. Grâce à ceux-ci on multiplexe les différentspaquets des sessions RTP/RTCP.

n Adresse de Transport : combinaisond’une adresse réseau et d’un port permettant d’identifier un point de terminaison au niveau transport(par exemple port UDP et adresse IP).

n Session RTP : association d’un ensemblede participants communicant via RTP.Pour chaque participant la session estdéfinie par une paire d’adresses de transport (adresse réseau + un port pourRTP + un port pour RTCP). Dans le cas du multicast l’adresse transport peut êtrela même pour tous. Dans une session multimédia, chaque média a sa propresession RTP et ses propres paquets RTCPidentifiés par des ports et/ou adressesmulticast différentes.

n Source de synchronisation(Synchronization source SSRC) : Sourced’un flux de paquets RTP, identifiée par 32 bits dans le header RTP. Tous lespaquets ayant même SSRC ont une mêmeréférence temporelle et de séquencement.Le lien entre SSRC et participants est faitvia RTCP.

n Source contributive (Contributing source CSRC) : Source d’un flux depaquets RTP qui a contribué au flux desortie d’un mixeur. Le mixeur insère uneliste d’identifiants de SSRC de chaquesource contributive à chaque header RTPdu flux résultant de la combinaison en sortie du mixeur, liste appelée CSRC.

RTCPRTCP transmet périodiquement despaquets de contrôle aux participants, utilisant les mêmes moyens de diffusionque RTP, simplement avec un numéro de port différent.

RTCP permet de recevoir des informationsde retour des participants, grâce aux messages “sender report” et “receiverreport”.

RTCP diffuse un identificateur pour chaquesource RTP, appelé CNAME, c’est cetidentificateur qui permet d’attribuer lesflux RTP à tel ou tel participant, car lesSSRC peuvent changer (redémarrage deprogramme, conflit ...). Cela permet ausside synchroniser des flux audio et vidéovenant d’un même participant.

Il existe différents types de paquets RTCPpour chaque type d’information :n SR : Sender report, statistiques detransmission et de réception pour les participants qui sont des émetteurs actifs.n Receiver report, statistiques de réception pour les participants qui ne sontpas des émetteurs actifs.n SDES : Source description.Descripteurs de source, dont les CNAME.n BYE : fin d’une participation.n APP : Fonctions spécifiques à une application.

Le protocole sous-jacent (TCP) peutconcaténer plusieurs paquets RTCP. A cette fin chaque paquet RTCP est composé d’un header fixe (comme RTP),suivi d’éléments fixes toujours alignés sur 32 bits. Parmi ces paquets RTCP, on inclura toujours un paquet RR ou SR,ainsi qu’un SDES CNAME.

H.323

Introduction

H.323 a été défini à l’origine par laCommission d’Etudes 16 de l’UIT-Tcomme variante de la norme H.320 devisiophonie sur RNIS adaptée dans ce casaux réseaux locaux de données de typeEthernet fonctionnant en mode sansconnexion et sans garantie de qualité deservice (i.e. pas de correction d’erreurs).

L’adoption et la promotion de H.323comme standard pour les produits devoix/vidéo sur Internet et intranets parMicrosoft et Intel, entraînant dans leursillage des dizaines de petits éditeurs, a propulsé cette norme comme standardincontournable de la téléphonie surInternet. Le standard s’applique désormaisà tous les réseaux de paquets, et non plusseulement aux réseaux locaux.

La jungle des normesRTP/RTCP était un cadre général d’implémentation de protocole de transportde données temps réel, où de nombreuxparamètres restent à préciser pour une utilisation concrète. H.323 précisejustement les choses dans le cadre d’un sous-ensemble ayant sa propre référence : H.225.

Cette norme reprend entièrement le standard IETF sur RTP/RTCP en corrigeantdes points de détail. Elle fixe les types decontenu audio et vidéo des paquets RTPcréés par une application H.323, etarbitre certains conflits entre RTCP et leprotocole de contrôle défini par H.323(sous-ensemble H.245).

41

H.323 décrit entièrement un système devisiotéléphonie sur LAN, y compris desfonctions avancées comme la conférence,le contrôle d’accès ou le mixage des flux.H.323 décrit toutes les unités qui interagissent lors du fonctionnement d’untel système :

n Les terminaux H.323.

n Les passerelles vers des réseaux classiques (RTC, RNIS, ...).

n Les “gardes-barrières” (Gatekeepers en Anglais), sortes de centres de gestionet d’enregistrement qui contrôlent également l’accès des terminaux auréseau IP.

n Les MCU (Multipoint Conference Unit),MC (Multipoint Controller) et MP (MultipointProcessor) chargés du mixage des flux etde la gestion de conférence multipoints.

La Commission d’Etudes 16 de l’UIT-T est responsable de l’évolution des normesH.323. Cependant les industriels dudomaine se sont rassemblés au sein duforum VoIP (Voice over IP) lui-même sous-groupe de l’IMTC (InternationalMultimedia Teleconference Consortium)pour clarifier et compléter H.323 encontexte IP, notamment sur les annuaires.Le “profil” RTP de VoIP définit des compressions additionnelles par rapport à H.323, notamment le codage défini pour les téléphones mobiles GSM 6.10.Le travail de l’IMTC est peu à peu reprispar l’UIT-T, notamment dans la version 2.

Depuis peu l’ETSI a mis en place ungroupe de travail TIPHON(Telecommunication & IP HarmonizationOver Networks), qui regroupe en fait tousles acteurs de l’IMTC et les opérateurstélécoms et se concentre sur lastandardisation des passerelles vers lesréseaux publics (RTC, RNIS, GSM).

Structure de H.323

Lors d’une connexion, plusieurs canauxsont ouverts avec chacun une adressepropre (port UDP ou TCP suivant le typede canal).

H.323 est défini pour la visioconférence :il est donc possible d’échanger du son ou

de l’image vidéo. Pour chaque type demédia échangé et pour chaque sens decommunication, un canal RTP est établiainsi qu’un canal de contrôle RTCP (audessus du protocole UDP).

Il est également possible d’échanger desdonnées sur un canal spécifique selon lanorme T.120 (au dessus du protocole detransport fiable TCP) : cette propriété permet notamment de partager des applications entre deux micro ordinateurscomme un traitement de texte, un tableurou un logiciel de présentation, ce quis’avère très utile en pratique pour les travaux de collaboration à distance.

Deux autres canaux sont liés à la signalisation d’appel (qui reprend demanière adaptée la signalisation Q.931 du RNIS) et au contrôle des communications.

Enfin un dernier type de canal est lié àl’échange facultatif avec un “garde barrière” (Gatekeeper) régissant les accès des terminaux au réseau. Ce canalsupporte les opérations d’enregistrement,d’admisssion et de demande de statutauprès du garde-barrière.

Au total, un PC multimédia désirant établirune connexion voix et données avec unautre PC au travers d’un réseau IP devradonc établir les canaux suivant :

n canal d’émission pour un flux son (sur UDP/RTP),n canal de réception pour un flux son (sur UDP/RTP),n canal de réception des informations de contrôle son (sur UDP/RTCP),n canal d’émission des informations de contrôle son (sur UDP/RTCP),n canal d’émission de données (sur TCP/T.120),n canal de réception des données (sur TCP/T.120),n canal de signalisation d’appel, n canal de contrôle et d’échange descapacités des terminaux,n canal d’enregistrement, d’admissionauprès d’un garde-barrière.

Il faudrait établir quatre canaux supplémentaires si l’on veut ajouter unéchange vidéo (un canal d’information etun de contrôle pour chaque sens).Les canaux d’échange de média sontoptionnels : il pourrait aussi y avoir plusieurs canaux de données, pas decanal vidéo, un seul canal son par exemple.Par contre le canal de contrôle etd’échange des capacités des terminauxest toujours présent pour chaque appel.

La figure ci-dessous reproduit ces différents composants pour une communication bilatérale.

Canal RTP audio de A vers B

Rapport de réception RTCP

Rapport d’émission RTCP

Initialisation

SonnerieConnexion

Capacités du Terminal

Capacités du Terminal OK

Ouvrir Canal Logique

Ouvrir Canal Logique OK

TERMINAL A

Alias : n° Tél, Email ...

Canaux de donnéesCanaux Audio RTP : UDP RTCP : UDP 7771 RTCP : UDPCanaux Vidéo

Canal de signalisationd’appel TCP 1720

H.245 Canal de contrôleTCP

Canal RAS

TERMINAL B

Alias : n° Tél, Email ...

Canaux de donnéesCanaux Audio RTP : UDP 9344 RTCP : UDP RTCP : UDP 9345Canaux Vidéo

Canal de signalisationd’appel TCP 1720

H.245 Canal de contrôleTCP

Canal RAS

Tableau 3 - Séquence type d’une conversation entre deux postes H.323.

42

Séquence type d’une conversationentre deux postes H.323

Initialisation de l’appel

Le premier poste A envoie vers le port“Canal de signalisation d’appel” (port standard TCP 1720) du poste B un message “Initialisation”. Ce message comprend notamment les informations suivantes :

n Taux de transfert demandé au réseau,type de codage ... n Un bloc d’information USER to USERavec un identificateur de protocole, l’identité H.323 de la source (une chaînede caractères), le type de la source (ici unposte LAN), l’identificateur de conférencesi celle-ci est en cours et si l’on veut larejoindre, la créer ou y inviter quelqu’un,et le type d’appel (par défaut point à point).“A” peut aussi indiquer ici une adresse decanal de contrôle (H.245) où B pourraéventuellement décider de se connecter.

B répond optionnellement par un message“Traitement d’appel en cours” pour indiquer que la demande d’appel a étéenregistrée qui comprend éventuellementl’adresse H.245 que A devrait utiliser pour se connecter sur B, et émet encoreoptionnellement un message “Sonnerie”pour indiquer que l’utilisateur B est entrain d’être alerté.

Enfin B termine par un message“Connexion” qui comprend notamment :n la référence de l’appel (identificateurunique de cet appel).n Les capacités de transfert requisesselon la norme RNIS I.231 (Taux de transfert demandé au réseau, type decodage ...), informations obligatoires seulement lors d’un appel vers une passerelle donnant accès au RTC ou au RNIS.n Indicateur de progrès.n Date/ Heure.n Un bloc d’information User avecl’adresse de transport H.245 que A doitemployer pour négocier les capacités, leType de Destinataire, l’éventuel numérod’identificateur de conférence.

Première communication et échangede capacités

A ouvre un canal de contrôle H.245 vers B(Ou B vers A en utilisant l’adresse du message Initialisation). Ce canal estunique pour chaque appel d’un terminal à l’autre, même si cet appel met en jeuxplusieurs flux audio (langues) et/ou vidéo.Le numéro logique H.245 de ce canal esttoujours 0.

Soit ce canal H.245 est ouvert par Blorsqu’il reçoit le message Initialisation,soit il est ouvert par A lors de la réceptiondu message Sonnerie ou Traitementd’appel en cours. L’adresse et le port àemployer ont été donnés dans l’un de cesmessages.

Le premier message H.245 envoyé estCapacités du terminal, qui comprendnotamment les informations suivantes :n un numéro de séquence,n les capacités de multiplexage de flux(Capacités Multiplex). n Table de capacités : contient les possibilités d’échange et de compressionaudio ou vidéo, de chiffrement etd’échange de données : par exemple type de codages vidéo acceptés, types de codage audio, paramètre de la normed’échange de données T.120.Chaque terminal envoie ce message àl’autre. A la réception du message, A et B accusent réception par un messageCapacités du terminal OK. Ils déterminentensuite qui sera le maître dans la conversation grâce à un échange de messages H.245 DeterminationMaître-Esclave/DeterminationMaître-EsclaveOK.Cela sert à résoudre les conflits au cas ou les deux terminaux chercheraient simultanément à devenir MC (MultipointController) ou à ouvrir l’un vers l’autre etsimultanément un canal bidirectionnel.

Etablissement de la communicationaudiovisuelle

Les paquets de données voix et image vontcirculer dans plusieurs “canaux logiques”H.245. Sauf pour les éventuelles donnéesT.120, ces canaux sont unidirectionnels.

A ouvre donc un canal logique vers B pourle son. Il envoie pour cela un messageH.245 OuvrirCanalLogique qui contient lenuméro qui sera attribué au canal H.245 à ouvrir et les paramètres correspondant(numéro de port, type de données (audiog711), et les paramètres additionnels que sont, par exemple pour des donnéesH.225.0, le numéro de session RTP,l’adresse de transport pour les données deretour RTCP (IP+port) unicast ou multicast,le type de données RTP, et si l’émetteurcesse d’émettre pendant les silences).

B renvoie OuvrirCanalLogiqueOK pour cenuméro de canal H.245, il y mentionne leport UDP où A peut envoyer ses donnéesRTP, et le port TCP où A peut envoyer ses données de contrôle RTCP.

B ouvre à son tour un canal et A confirme.

Dialogue

A et B “parlent”, les paquets sont échangés sur les canaux virtuels établisprécédemment selon le protocoleRTP/RTCP repris par H.225.0. Plus précisément, les données RTP circulentvers le numéro de port précisé dansOuvrirCanalLogique, et les données RTCPsur le port suivant.

Fin

Celui qui raccroche ferme son/ses canauxlogiques grâce au message H.245FermerCanalLogique correspondant aunuméro de canal ouvert, acquitté par unmessage FermerCanalLogiqueOK.

Il envoie un message H.245FinSessionCommande, attend de recevoirle même message de son interlocuteur et ferme le canal de contrôle H.245.

Si un canal de signalisation d’appel a étéouvert, chaque terminal doit envoyer un message ArrêtComplet avant de le fermer.

43

Cas plus complexe : appel d’un poste sur le LAN à destinationd’un usager du téléphone classiqueOn suppose ici que sur le LAN se trouveun “GateKeeper ” chargé de contrôler lesaccès au réseau (suivant une certaine politique d’allocation de ressources). C’est lui qui enregistre les terminaux présents dans sa zone, qui les autorise ou non à utiliser des ressources sur leréseau, qui les facture. Enfin, il saitrésoudre les alias H.323 en adresses IP.Le monde H.323 compte également descontrôleurs multipoint (MC/MCU) qui interviennent lors des conférences poursynchroniser les participants et assurer le mixage des flux...

Première phase : où est le Gatekeeper ?

Tout gatekeeper doit écouter l’adressemulticast 224.0.1.41 sur le port UDP 1718.

Le terminal envoie un message UDP“Gatekeeper Request” (GRQ) vers cetteadresse et ce port. Décrit dans H.225.0,le message GRQ comprend notamment :n L’adresse/port RAS utilisée par ce terminal et sur lequel doivent parvenir lesréponses.n Le type de terminal.

Un ou plusieurs gatekeepers répondentalors par un message “GatekeeperConfirm” (GCF) à destination du port RASdu terminal ; ce message comprend : n Le nom du gatekeeper.n L’adresse/port RAS utilisée par ce gatekeeper.Le terminal choisit son gatekeeper ets’enregistre auprès de lui grâce au message “Registration Request” (RRQ)envoyé vers l’adresse du gatekeeperchoisi sur le port UDP 1719. Ce messageapporte les mêmes infos que GRQ.Le gatekeeper répond par le message“Registration Confirm”(RCF) toujours versle port RAS spécifié par le terminal où l’on trouve :n une adresse/port H.225 pour les messages de contrôle d’appel à envoyervers ce gatekeeper,

n éventuellement un alias ( Numéro E164,Chaîne ...) par lequel ce terminal seraconnu en dehors du LAN,n un identificateur unique que le terminaldevra rappeler lors des messages suivants.

Deuxième phase : trouver le destinataireOn suppose que les destinataires téléphoniques ont un alias de la mêmeforme qu’un numéro téléphonique standard (adressage selon la normeE.164 de l’UIT-T).Le terminal envoie sur le port UDP 1719(ou sur le port 1718 de 224.0.1.41) dugatekeeper un message “LocationRequest” (LRQ) où il indique l’alias de soncorrespondant et l’adresse où il souhaitela réponse.Le gatekeeper répond sur le port indiquéet donne l’adresse de transport IP et leport où contacter le correspondant pourenvoyer les messages de “signalisationd’appel” Q.931.0, ainsi que le coupleIP/Port pour les message RAS à destination du correspondant. Deux possibilités pour la signalisation d’appel :soit le gatekeeper s’indique lui-même (ou

un autre gatekeeper) car il souhaite s’intercaler, par exemple pour faire de laréservation de ressources RSVP entre luiet le distant, soit il indique directementl’adresse du distant, ici la passerelleIP/RTC.

Troisième phase : demande d’admission

Le terminal envoie alors un messages RAS “Admission Request” (ARQ) à songatekeeper qui comprend notamment :n le numéro séquentiel de la demande,n le type d’appel (Point à Point, un vers N,N vers un, N vers N),n le modèle d’appel (Direct ou ViaGatekeeer),n l’identificateur unique du terminal appelant (attribué plus haut par le message RCF),n l’adresse du terminal de destination(adresse E.164 ou ID H.323 : celle que Ba enregistré auprès de son gatekeeper),n l’adresse E.164 ou H.323 de la source,n la bande passante bidirectionnelle en multiples de 100 bit/s ( par exemple2*64 kbit/s pour une conversation G.711).

PASSERELLE

Alias : n° Tél., Email ...

Canaux de données

Canaux audio/vidéo

Signalisation d’appel

Canal de contrôle H.245Canal RAS

TERMINAL

Alias : n° Tél., Email ...

Canaux de données

Canaux audio/vidéo

Signalisation d’appel

Canal de contrôle H.245Canal RAS

3 Demande d’admission

Type d’appel (1 vers 1)Bande passante demandéeDestinationGK répond avec l’adresseSignalisation d’appel à utiliser

2 Enregistrement (RRQ)

GK répond en assignant unUID au terminal

GATEKEEPERAdresse Multicast de découverte224.0.1.41 UDP171 Canal RAS (1719 en Gal)Signalisation d’appelCanal de contrôle H.245

7 RTP/RTCP

4 Setup

5 Connect6 H.245

1 Découverte du GK (GRQ)

- Adresse RAS pour réponse- Alias- Type de TerminalGK répond avec l’adresse deson canal RAS (RCF)

RNIST2

Figure 6 - Etapes d’un appel complexe.

44

Le gatekeeper répond par un messageAdmissionConfirm (ACF) où il alloue unebande passante maximum (peut-êtremoins que demandé) et si il veut routerl’appel ou non. Il indique l’adresse “signalisation d’appel” à utiliser pour lasignalisation Q.931, selon le routage lasienne ou celle du terminal appelé B, ainsi que la fréquence éventuelle des messages IRR à envoyer au gatekeeper.

Quatrième phase : message de connexion

On suppose que le gatekeeper ne veutpas router l’appel, le terminal envoie un message de Initialisation surl’adresse/port (1720 sauf si le gatekeepera indiqué autre chose) que le gatekeepervient de lui indiquer pour son correspondant. Dans notre cas c’est lapasserelle IP vers le réseau téléphonique.Le message initialisation contient les informations suivantes :n capacité de transport,n éventuellement le numéro E.164 del’appelant.n le numéro E.164 de l’appelé,n et un champ User To User mentionnantl’adresse de transport H.245 que le terminal voudrait utiliser (facultatif),n l’identité H.323 de la source,n le type du terminal appelant (gâterai ou non),n l’adresse de destination de l’appel sipas fait dans la partie Q.931,

n éventuellement l’identificateur de conférence, et la raison de l’appel (invitation, début de conf...),n le type d’appel (PointToPoint).La passerelle, avant de répondre,demande elle-même une autorisationd’admission à son gatekeeper (ARQ/ACF).Dans le message initialisation reçu de lapasserelle se trouve le numéro E.164 àappeler, qui sert à la numérotation aprèstransformation en fonction du lieu où setrouve la passerelle, l’IMTC recommandel’usage d’un préfixe de sortie, commepour un PBX d’entreprise.En attendant que le distant décroche, la passerelle envoie régulièrement sur leport 1720 de l’appelant des messagesSonnerie et Traitement d’Appel en Cours(au moins toutes les 4 secondes selonIMTC pour indiquer la progression del’appel.Enfin, au décrochage du distant, la passerelle envoie vers le terminal du LANun message Connexion (précédé éventuellement de Traitement d’Appel enCours, Sonnerie ..., comme décrit dansQ.931 annexe D et les documents deIMTC...) où il donne notamment sonadresse/port H.245 ou devra s’établir le canal de contrôle de l’appel.

Début de communication et conversation

Ces phases reprennent la séquence “LAN à LAN” décrites précédemment.

Vers des services “Intelligents”Le routage au travers d’un ou plusieursgarde-barrières coopérants permet d’envisager des services de type réseauintelligent transposés dans le contexte de la téléphonie IP comme le montrent les deux exemples suivants.

Transfert d’appelLe transfert d’appel est un service supplémentaire qui permet à un utilisateurde transférer un appel en cours vers unautre correspondant. Ici A et B sont enconversation, et A décide de transférerl’appel à un correspondant C.

Transfert aveugle

Dans ce type de transfert A ne laisse pasB vérifier que C est joignable avant de se déconnecter.On est en pleine conversation, établiecomme vu précédemment.A envoie un message Facility, dont lechamp FacilityReason est de typecallTransfer et contient un élémentCallTransfertInvoke informant B del’adresse de C.A envoie un message H.245 Close, puis Release Complete, terminant ainsi sa conversation avec B.B envoie un message Initialisation à C(le Call ID de cet appel reste celui del’appel avec A).

Transfert sûr

A n’envoie pas immédiatement le message H.245 close après avoir envoyéle message CallTransfer, il attend que Benvoie le message Facility(CallTransferResult=success ou failure).En fonction du résultat, il se déconnectealors de B comme précédemment oucontinue la conversation avec B

Transfert avec consultation

A (par exemple un secrétariat) veutdemander à C si il souhaite prendre l’appelavant de le mettre en communication avec B.A envoie alors à B un message H.225Hold, B répond par HoldAck, et la conversation est suspendue.

45

A établit un appel avec C (message Setupavec le même ID, Connect, etc ...).A peut faire des va-et-vient entre B et C à l’aide des messages Hold et Retrieve.A transfère définitivement l’appel avec lemessage Facility comme précédemment.

Plan de numérotation privée

H.225 possède la capacité de supporterun plan de numérotation privée selon lanorme ISO/IEC 11571.

Sur le LAN, le garde-barrière devra doncêtre capable de traduire en adresses deTransport aussi bien des adresses E.164,des Ids H.323 que des adresses ISO/IEC11571.

Pour ajouter ce support, la partie “CalledParty Number” et “Calling Party Number”du message Initialisation est modifiée : lesbits qui indiquent le plan de numérotationutilisé ne sont plus 0001 (Plan de numérotation RNIS E.164) mais 1001(Private Numbering Plan).

Certains messages d’échange de capacités sont également affectés pourpouvoir indiquer la capacité à numéroterselon un Plan de numérotation privé.

Garde-barrière et “agent intelligent” personnelLorsqu’on utilise le garde-barrière pourrouter les appels (et non pas seulementpour la résolution nom ou numéro téléphonique E.164 vers adresse IP), ildevient possible de piloter des servicesde redirection d’appels complexes géréspar un “agent intelligent” personnel.

Ce module logiciel peut assez facilementêtre paramétré par l’utilisateur final à l’aidede formulaires Web : cette tendance à utiliser le Web est en fait assez généraledans le domaine des systèmes de gestionde réseaux.

Un tel agent personnel permet de gérer lesconditions de reroutage des appels versun téléphone, un GSM, une boîte vocale,etc. en fonction de l’émetteur, de la date,de l’heure, etc. en bénéficiant ainsi de toutesles possibilités de services et d’intégrationd’applications d’Internet / intranet.

L’impact majeur des infrastructuresréseau

Comme on l’a vu précédemment, le transport de la voix sur un réseau IP resteessentiellement non fiable du fait des faiblesses inhérentes au protocole de“transport” RTP : ce protocole reconstitueles séquences de paquets mais ne garantit pas que les paquets vont arriveret encore moins qu’ils vont arriver àtemps pour être exploitables compte-tenudes contraintes de délai imposées par un conversation humaine (300 ms maximum).

Toute l’architecture précédente est doncremise en cause si le réseau IP lui mêmen’est pas en mesure d’apporter des garanties de qualité de service en termesde débits et de délais.

Les constructeurs de routeurs et l’IETF ontdéfini un certain nombre de mécanismespermettant de contrôler la qualité de service (QdS) en réservant des ressourcesréseau, ce qui revient à considérer que le fonctionnement du réseau IP se rapproche alors de celui d’un réseau decircuits commutés comme le réseau téléphonique !

Le protocole de réservation de ressources RSVPRSVP (Resource reSerVation Protocol)n’est pas en lui même un protocole de routage particulier mais seulement un protocole de commande qui DEMANDEla réservation des ressources en vued’obtenir une certaine qualité de servicedu réseau. Il doit être complété par desmécanismes de réservation effective deressources dans les routeurs présentésau paragraphe consacré aux “Mécanismesgestion des ressources dans les routeurs”.

RSVP est conçu dès le départ pour s’adapter à la communication de groupe(conférences, diffusion) : la réservation

des ressources aurait pu être initiée parl’émetteur, mais il doit alors gérer la réservation pour chaque arrivée ou départd’un récepteur dans le groupe, ce qui estun travail important lorsque le groupe s’élargit. De plus une telle réservation, quiserait uniforme pour chaque récepteur,devrait s’aligner sur la route à plus faiblebande passante.RSVP est donc un protocole de réservationinitiée et maintenue par le récepteur.

Pour la réservation de ressources, on penserait d’emblée à indiquer une valeurmoyenne de trafic, et une bande passantepour les liaisons. En fait ce n’est qu’unepartie du problème : la majorité des problèmes rencontrés par les applicationstemps réel sur IP viennent des délais rencontrés sur le réseau comme on l’adéjà souligné précédemment.

Il y a encore d’autres caractéristiquesimportantes à prendre en compte : ainsiun trafic très régulier est plus simple àtransporter qu’un trafic très sporadiqueavec de grandes pointes (ce qui est souvent le cas des applications de données qui empruntent un réseau IP).Pour de tels trafics les routeurs doiventêtre capables de stocker de manière temporaire des quantités importantes de données pour ne rien perdre en cas de congestion en aval, ce qui augmentede manière significative leur coût.

RSVP est un protocole de réservation simplex (i.e le sens montant est distinct du sens descendant) qui gère des sessions (définies par une adresse IP unicast ou multicast de destination, unport et un protocole).

Le récepteur commence par se connecterau port (supposé connu) de l’applicationde l’émetteur qui implémente RSVP. A partir de ce moment il reçoit des messages périodiques envoyés par l’émetteur à tous ses récepteurs, appelésmessages “Path” (routés normalement par le protocole unicast ou multicast sous-jacent, et avec les mêmes adressesd’émetteur/destinataire que les donnéespour permettre le passage transparentdans les zones non-RSVP).

46

Ces messages (fig. 7) contiennent les caractéristiques de trafic que l’émetteurva générer : un “filter spec” utilisable pourreconnaître les paquets de cet émetteurainsi que les caractéristiques de son futurflot de données (“Tspec”) et intègrentcomme paramètre l’adresse IP du dernierrouteur RSVP traversé, mise à jour parchaque routeur RSVP traversé (les routeurs non-RSVP ne touchent pas à ceparamètre). Ces données des messagesPath sont stockées par chaque routeurRSVP traversé.

Le récepteur envoie alors un message de réservation “Resv” vers l’émetteur (ou chaque émetteur) en inversant l’information de routage contenue dans les messages Path (chaque machineconnaît son prédécesseur RSVP). Il peutexister plusieurs “styles” de Resv : on peut demander une réservation distinctepour chaque source (vidéo), ou bien uneréservation collective pour toutes lessources (cas où l’on parle à tour de rôle).On peut aussi préciser quelles sources on sélectionne ou envoyer un “joker” poursélectionner toutes les sources. Différentstypes de réservations sont supportés aucas ou il y a plusieurs sources : lorsqu’ons’attend à ce que les sources “parlent” en alternance on fait de la réservation partagée, sinon on fait de la réservationexclusive.

Le message Resv comprend des informations de “Flowspec” spécifiant la QdS demandée, et de “Filter Spec” identifiant les paquets de données pourlesquels cette réservation s’applique.

A chaque routeur RSVP traversé le message“Recv” du protocole RSVP interagit avecdes entités appelés “packet classifier” et“packet scheduler”. Le “packet classifier”est responsable du routage du messageet de la détermination de la catégorie de QdS demandée le “packet scheduler”(un par interface réseau) se charge depasser les demandes de réservation à lacouche liaison si elle est capable de gérerla Qualité de Service.

La demande de QdS est :

n soit refusée si les modules d’admission(A-t-on les ressources suffisantes pour laQdS demandée ?) ou de contrôle du routeur (“Policy control” : droits administratifs) ne peuvent prendre encompte la demande (ce refus est signalé à l’application demandeuse par un message d’erreur) ; n soit acceptée en fixant les paramètresdu “packet scheduler” à l’aide des informations du “flowspec”, et les paramètres du “packet classifier” à l’aidedu “filter spec”. Puis on propage lademande vers l’émetteur. Cette propagation, en cas de succès, s’arrêtelorsqu’un nœud a déjà réservé des ressources suffisantes. Chaque messageResv comprend un temporisateur au delàduquel toute mesure de réservation priseest effacée : c’est donc à l’émetteur et aurécepteur de rafraîchir périodiquementces informations. Au cas ou un nœudreçoit plusieurs demandes de réservationpour une même session, il réserve enamont la plus grande demandée (intérêtdu multicast). Le récepteur peut demander une confirmation de la réservation, auquel cas cette demande

est propagée jusqu’à un nœud qui a déjàréservé la bonne bande passante, etenvoie l’acquittement, même si on a traversé une zone de routeurs ne sachantpas traiter RSVP.

Les données RSVP sont véhiculées sur IPpar de simples datagrammes dont lenuméro de protocole est 46.

L’état de réservation des routeurs estpérissable (“Soft State”), RSVP envoiedonc des messages de rafraîchissementpériodiques le long des chemins de réservation, en l’absence desquels laréservation disparaît. C’est le récepteurqui a la charge, en plus de l’initiation de la réservation, de la maintenir, ce qui dispense le réseau de contrôler en permanence la validité des réservation.

En outre cela présente l’avantage de pouvoir supporter simplement les changements de route : les paquets Pathsuivent alors la nouvelle route et lespaquets Resv sur leur retour réalisent lesnouvelles réservations. Les états associésaux routes précédentes disparaissent carils ne sont plus rafraîchis (on peut aussienvoyer un message spécifique de fin de session).

Automate RSVP

Application

Policy control

Admission control

Packet SchedulerPacket Classifier

Automate RSVP

Application

Policy control

Admission control

Packet SchedulerPacket Classifier

données

RSVP

Ordinateur Routeur

Figure 7 - Protocole de réservation des ressoures RSVP.

47

Mécanismes gestion des ressources dans les routeurs

Mécanismes RED/WRED

Le mécanisme RED (Random EarlyDetection), au même titre que le mécanisme WFQ présenté ensuite, n’estactivable que sur les files d’attente en sortie des routeurs. Il fonctionne de lamanière suivante :

n spécification d’un seuil minimal et d’un seuil maximal, généralement exprimés en nombre de datagrammes, et tels que :

n quand le nombre n de datagrammesreste inférieur à la valeur du seuil minimal,tous les datagrammes seront transmis ;

n quand n est supérieur à la valeur duseuil maximal, tous les datagrammesseront détruits ;

n lorsque n est compris entre les deuxvaleurs, l’algorithme RED calcule la longueur moyenne instantanée de la filed’attente (notion “d’average queue size”),puis détermine la probabilité de marquagedes paquets, probabilité d’autant plusgrande que la valeur de la longueurmoyenne de la file d’attente calculée est proche de la valeur du seuil maximal.Cette probabilité de marquage correspond pratiquement à une destruction du datagramme ainsi marqué.

Le mécanisme RED permet ainsi dedécongestionner les routeurs par uncontrôle implicite des sources TCP. En effet, TCP comporte un algorithmeconçu par Van Jacobson qui réduit lerythme d’émission de la source lorsqueles accusés de réception émis par le destinataire indiquent un perte depaquets. La nature aléatoire de RED permet d’agir d’abord sur les sourcesgénérant le plus de paquets.

En complément à ce mode de fonctionnement classique, il est possiblede définir une valeur de taille de paquetsIP en deçà de laquelle tous les datagrammes seront systématiquementtransmis.

Le mécanisme WRED (Weighted RandomEarly Detection) consiste à pondérer laprobabilité de marquage des datagrammescaractéristique du mécanisme RED parl’analyse de la valeur affectée aux bits precedence du champ TOS de l’en-tête IP.

Contrairement à ce que l’on serait tentéde croire, ce mécanisme s’applique surune seule file d’attente dans laquelle eststockée l’intégralité des datagrammes,quelle que soit la valeur affectée aux bitsprecedence consignés dans le champTOS des différents en-têtes.

Mécanisme WFQLe mécanisme WFQ (Weighted FairQueuing) est un moyen de gérer l’allocationdes ressources en bande passante sur unlien d’interconnexion donné, en fonctiondes profils clients définis (notion de WFQ“class-based”). Cet algorithme présente lescaractéristiques fonctionnelles suivantes :n les ressources en bande passante sont allouées dans l’ordre croissant de la demande, moyennant un poids caractéristique du profil client associé à chaque demande ;n aucune source de trafic n’obtient plusde ressources qu’elle n’en a demandé (ce qui permet en particulier d’assurer unefonction de police assez efficace pour letrafic des sources réputées non réactives,telles que les sources de trafic UDP) ;n les sources de trafic dont les demandesd’allocation de ressources n’ont pu êtresatisfaites se voient attribuer une part desressources restantes qui sera pondérée parle poids qui caractérisent le profil du client.

L’algorithme WFQ assure une fonction degestion temporelle des files d’attente danslesquelles sont stockés les datagrammesen fonction de leur coloration – donc enfonction du profil client –, assez

comparable à un mécanisme de multiplexage temporel. Chacune des filesd’attente est traitée d’une manièrecyclique, et un datagramme est traité dela manière suivante :n le routeur détermine s’il y a déjà undatagramme de la même nature dansl’une des files d’attente. Si c’est le cas, le paquet est stocké dans la file d’attenteappropriée, selon une classique mécanique FIFO. Si ce n’est pas le cas, le paquet est stocké dans la file temporellement éloignée d’un poids Wcde la file en cours de traitement (le poidsWc est évidemment caractéristique du profil client) ;n lorsqu’un datagramme issu d’une filed’attente donnée est en cours de transmission (i.e. que le routeur transmetce datagramme au travers de l’interfacede sortie correspondante), la file d’attentede ce datagramme pourra dès lors êtreutilisée par l’algorithme WFQ si un nouveau datagramme présentant lesmêmes caractéristiques est parvenu dansle routeur. Dans ce cas, WFQ stocke cenouveau datagramme dans la file d’attentecorrespondante, et le routeur ne traiterace datagramme que dans un temps caractéristique du poids Wc.

Les mécanismes WRED et WFQ“class-based” sont donc complémentaires,en ce sens que le mécanisme WREDapplique une politique de destruction des datagrammes en cas de congestiondétectée sur l’interface de sortie du routeur sur laquelle le mécanisme estactivé, tandis que le mécanisme WFQassure une gestion temporelle du stockage des datagrammes dans les filesd’attente caractéristiques des différentsprofils clients définis sur la même interface, et à la manière d’un mécanismede multiplexage temporel.

48

Mécanisme CARLe mécanisme CAR (Committed AccessRate) consiste à définir le comportementdu routeur face à l’arrivée d’un traficdonné, qui peut être caractérisé de différentes manières (adresse destination,identifiant du port TCP ou UDP, trafic arrivant sur une interface donnée). Lemécanisme s’appuie sur les ressourcesd’un algorithme de type “token bucket”(“seau à jetons”), dont le fonctionnementest le suivant :

n le seau à jetons est défini par sa profondeur, caractérisée par l’argument“normal burst size” exprimée en octets, etpar le nombre de jetons que le seau estsusceptible de contenir en fonction de saprofondeur (le nombre de jetons est unmultiple de 8 kbit/s) ;

associer le trafic au CAR immédiatementconsécutif (actions de type “continue”). De la même façon, un trafic sera de type“exceed” lorsqu’il n’y aura plus suffisammentde jetons dans le seau associés au volumetotal du trafic. Ce trafic fera aussi l’objetd’un traitement défini par la spécificationd’une “exceed action”, dont les valeurs sontcelles possibles pour les “conform action” ;

n la configuration d’un CAR suppose laspécification systématique des actions de type “conform” et de type “exceed” ;

n enfin, un CAR peut être défini pour untrafic entrant, mais aussi pour un traficsortant.

Intégration et dimensionnement

L’intégration de RSVP et des mécanismesde gestion de files d’attentes dans les routeurs fait l’objet de mises en œuvresparticulières suivant les constructeurs :cela rend difficile leur mise en œuvre dans des réseaux hétérogènes du faitnotamment d’interprétations différentes de la signification du champ TOS.

De plus, les techniques de gestion de filesd’attentes permet de rendre des flux plusprioritaires que d’autres, ce qui apportedes garanties statistiques de bande passante, mais en aucun cas de garantirde façon absolue un débit.

Des calculs trop complexes pour êtreexposés ici montrent cependant que lagarantie statistique de bande passantepermet néanmoins de maintenir le délai de bout en bout entre deux limites sur une chaîne de routeurs RSVP et c’est cequi importe pour des services temps réelsur IP comme la téléphonie.

Néanmoins le dimensionnement desréseaux capables de gérer la qualité deservice reste problématique : en effet la nécessité de maintenir un état pourchaque flux et la complexité des mécanismes précédents ne permet deréaliser des réseaux “RSVP” que sur desintranets comportant quelques dizaines à quelques centaines de routeurs.

Arrivée despaquets

Paquets avecun jeton

Réserve de jetons(Taille b)

Générateur de jetonsr octets/s

n il y aura autant de seaux à jetons distincts que de CAR spécifiés ;

n pour un CAR donné, un trafic est detype “conform” lorsqu’il subsiste unnombre suffisant de jetons pour traiterl’ensemble des datagrammes correspondant à ce trafic. Ce traitementest alors défini par la spécification d’une“conform action” qui peut prendre 5 valeurs (transmettre, détruire, modifierla valeur des bits precedence du champTOS de chaque datagramme puis transmettre, modifier la valeur des bitsprecedence du champ TOS de chaquedatagramme puis associer ce trafic au CAR immédiatement consécutif), ou

En aucun cas il n’est possible de mettredirectement en œuvre ces solutions dansle cadre de grands réseaux, ce qui est le cas d’Internet et des réseaux privés virtuels de données gérés par des opérateurs comme France Télécom.

Les travaux les plus récents s’oriententdonc vers des architectures de réseaux à plusieurs niveaux : des réseaux d’accèset de concentration mettant en œuvreRSVP et des cœurs de réseau haut-débitagrégeant les différents flux en un nombre plus limité de flux génériques dont la qualité est supportée par la surcapacité de ces cœurs de réseau.

Notons enfin le coût de mise en œuvre de la qualité de service dans les réseauxIP est loin d’être négligeable (liaisons etrouteurs) ce qui impacte sensiblement les scénarios de téléphonie sur IP “économique”.

Figure 8 - Mécanisme du “seau à jetons”.

49

Quelques élémentsd’analyse économique

La technologie IP peut-elle dans le futurservir de base à l’établissement deréseaux concurrents du bon vieux RéseauTéléphonique Commuté (RTC)1 ?

Avant de s’intéresser aux réductions decoût de fourniture du service téléphoniqueque pourrait engendrer IP, rappelons qu’ilne s’agit pas réellement du même service.Par rapport à la très grande qualité du service téléphonique actuel, qualité auquelle consommateur est attaché, y a-t-il réellement place pour l’ersatz2 que représente IP ? Il n’y a pas bien sûr pas de réponse absolue à cette question ettout dépendra de l’économie produite parl’éventuel réseau IP. Pour examiner celle-ci,nous nous limiterons au mode nonconnecté. Nous ne nous intéresseronsdonc pas au compromis technique quereprésente le protocole RSVP ; son économie est encore mal connue, mais il est clair que les gains issus de la commutation “en vrac” des paquets disparaissent.

L’avantage compétitif d’IP a deux causesrelativement distinctes. En premier lieu,dans le réseau IP, la fonction d’aiguillagedes commutateurs est assurée par lesrouteurs. Or les commutateurs sont desmachines extrêmement sophistiquées produites par des équipementiers dans uncadre peu concurrentiel pour des réseauxnationaux très spécifiques3. Ils sont aussiplus performants en termes de temps de transfert que les routeurs, ce qui a évidemment un coût. Les routeurs sont aucontraire des ordinateurs; ils bénéficientdonc des énormes économies d’échelle et de la forte concurrence régnant dansce secteur4.

En second lieu, la compression du signalen IP (le débit variable tourne entre 4 et 8 kbit/s alors que le RTC code la parole à 64 kbit/s) conduit à une réduction d’unfacteur dix des capacités de transmissionnécessaire. Il ne faudrait cependant pasen conclure que les coûts de transmission

sont réduits d’autant car les réseaux detransmission – grâce à la fibre optique –présentent d’importantes économiesd’échelle. En poussant le raisonnement à l’extrême, on pourrait même dire que siFrance Télécom décidait aujourd’hui depasser demain à l’IP, il n’y aurait guèred’économies à court terme puisque lesfibres optiques du réseau de transmissionsuffisent largement à écouler le trafic prévisible, d’autant que les infrastructuresalternatives (SNCF) reprendront une partiede celui-ci.

L’économie la plus forte est évidemmentréalisée dans le cadre d’un réseau demicro-ordinateur à micro-ordinateur (“Net-To-Net”) . Mais les contraintes surl’usage sont fortes alors que la tendanceen téléphonie est plutôt au sans fil et à lamobilité. Plus gênant encore est l’effet deparc. Un des atouts majeurs du réseautéléphonique est de pouvoir joindrel’ensemble de la planète (au moins lescitoyens des pays développés) ; les restrictions à cette communication universelle qu’engendrent l’absence demicros dans la majorité des foyers pourencore pas mal d’années ainsi que l’éventuelle incompatibilité des différentslogiciels5, nous semblent donc rédhibitoires (voir plus loin le cas desentreprises).

Un réseau IP se greffant sur les lignesd’abonnés et les terminaux téléphoniquesdéjà existants (réseau dit “Phone-To-phone”)semble donc plus crédible ; mais il requiertdes passerelles entre le réseau IP et lescommutateurs d’abonnés. Les économiessont alors bien moindres car le coût global de celles-ci est important6.

Dans ce dernier contexte, le service local n’a pas de sens. Restent donc l’interurbain, l’international et la téléphonied’entreprise. Dans le premier domaine,comme les études économiques menéessur ce sujet au CNET l’ont montré, la téléphonie sur IP ne fait pas une différencesuffisamment sensible pour compenserses inconvénients, en particulier parce queles coûts essentiels sont dans la bouclelocale à laquelle le nouveau système

n’apporte rien puisque la ligne d’abonnéest dédiée à celui-ci7. Ces coûts se refléteraient dans la charge d’interconnexion que l’opérateur IP auraitde toutes façons à payer à l’opérateur de la boucle locale (France Télécom dansla plupart des cas).

En international, le système tarifaire estcomplexe et les tarifs sont aujourd’huinotoirement trop élevés par suite de l’inertie

1. Qui évolue lui aussi. Le CNET réfléchitaujourd’hui avec la BRX à la transition vers l’ATM,qui pour beaucoup d’experts est aussi le conceptvers lequel converge Internet. De même, on peutenvisager de comprimer le signal en transmissionlongue distance – c’est déja le cas en interurbainaux USA ou en international sur les câbles transatlantiques –, ou même dans la boucle locale– les réseaux GSM qui sont comprimés à 16, voire à 8 kbit/s, ne sont après tout qu’un prolongement du réseau général –. Dans lecontexte concurrentiel actuel, il est clair de toutes façons que les potentialités de réductiondes coûts qu’offrent ces techniques seront plusintensément exploitées qu’auparavant. Il est donc prévisible que les frontières entre lesconcepts de téléphonie sur IP et sur RTC s’amenuiseront dans un futur proche.2. Même si, comme on l’a vu précédemment, la téléphonie sur IP peut aussi apporter des compléments intéressants telles que visiophonie,groupware, consultation en ligne de bases de données.3. Cette situation est, on le sait, en train d’évoluerrapidement ; mais elle se reflète dans les coûtsactuels du RTC.4. Même si le marché des routeurs à proprementparler est en fait dominé par une entreprise, Cisco (57 % du marché en 95).5. Mais, comme on l’a vu, des efforts de standardisation sont en cours.6. Cela resterait vrai dans un contexte réglementaire différent du contexte françaisactuel, où la passerelle ne peut s’interfacer directement sur le répartiteur.7. On peut observer qu’il en serait autrement dansd’autres technologies, quelles soient hertziennes(mais le GSM code déjà la parole à 8 kbit/s), ou à base de fibre optique partagée (FTTB/FTTC -Fiber-To-The-Building/Curb et HFC -Hybrid FiberCoaxial-). Dans ce dernier cas, évolution desréseaux câblés actuels, il peut être intéressantd’économiser de la bande passante dans la partiede la boucle locale la plus proche du commutateur(appelée “transport”) ; car les artères sont partagées par l’ensemble des clients de la zone.

50

des mécanismes de compensation entreopérateurs (les “taxes de répartition”).Il y a donc là réellement place pour l’IP.Mais les réseaux traditionnels pourraientaussi réduire notablement leurs coûts en faisant une utilisation plus large de lacompression. En outre, tout le systèmedes taxes de répartition est en refonterapide. Difficile dans ces conditions pourun entrant de construire un business-planbien étayé. Enfin, en entreprise, le concept “Net-To-Net”reprend de la valeur puisque l’effet deparc ne joue plus ; dans beaucoup d’entreprises, les postes de travail de “col blanc”, pour lesquels le terminal téléphonique est un outil de travail, sontégalement dotés d’un micro-ordinateurbureautisé. La décision sur le logiciel àretenir peut être prise de façon centralisée.Les nouvelles fonctionnalités qu’apporte IP sont particulièrement attractives enentreprise et compense en partie sesdéfauts déjà évoqués8. Enfin, le réseau IPde téléphonie ne servira que lors desheures chargées de la journée ; il pourraitdonc basculer le soir ou lors de la pauseméridienne vers d’autres applications (sauvegarde ; transferts de données entemps différé ; téléchargements d’applications utilisables le lendemain). L’étude de cas concrets de réseauxd’entreprises montre cependant que lasolution Intranet dédié à la téléphonie n’est viable par rapport aux solutions oùl’on paye en fonction du trafic comme le service Colisée-Numéris actuel, que si le trafic téléphonique de l’entreprisen’est pas trop saisonnier. Sinon le réseaudimensionné pour les mois les plus fortssera sous-utilisé la plupart du temps. Le remède est alors à chercher dans l’intégration de services avec un réseauIntranet voix-données en protocole RSVPafin de garantir un niveau de qualité suffisant. La conclusion économique est donc claire.IP présente un réel intérêt pour un réseaud’entreprise ainsi qu’en international. Cette solution n’est en revanche pas pertinente en local et n’est guère attractive en interurbain, sauf peut-êtredans le contexte de pays émergents.

Conclusion

S’il reste sans doute un marché de nichede type “Friends and Family” pour descommunications vocales internationalesde basse qualité sur Internet, les véritables opportunités économiquesdevraient se situer au niveau des réseauxintranets (i.e. sous le contrôle completd’un opérateur) par la mutualisation de lavoix et des données sur ce même réseau.

Mais à plus long-terme, lorsque les usagesauront complètement banalisé l’utilisationdu PC multimédia pour les applications de données, c’est surtout vers l’intégrationde services (e.g. travail collaboratif, commerce électronique) et l’intelligencede ces services que devrait s’orienter lemarché des applications temps réel surréseaux IP.

Il reste que l’acceptabilité de ces nouveaux services, leur coût de mise enœuvre sur des infrastructures encoreassez difficilement “modélisables” ne saurait être clarifiés complètement sur le papier ou dans les laboratoires.

La réponse à ces questions passe par des expérimentations de services sur leterrain tels que ceux qui ont été présentésau chapitre consacré à “Quels servicespour un opérateur” : c’est le but que sefixe France Télécom pour 1998.

Annexe : les techniques de codage audio

La technique temporelle consiste à préserver la forme d’onde du signal.Différents types de codage entrent dans cette catégorie. La modulation parimpulsion et codage (MIC) où le signal etéchantillonné puis l’amplitude quantifiéessuivant des standards de compressionnon linéaire (loi A ou µ) : c’est le codageRNIS/RTC à 64 kbits/s selon laRecommandation G.711 de l’UIT. Lescodeurs de type ADPCM (AdaptiveDifferential Pulse Code Modulation où l’on tire parti des propriétés de corrélationde la voix en codant les échantillons de manière différentielle avec une composante estimée par extrapolationdes valeurs intervenues précédemment)ou SB-ADPCM (Sub Band ADPCM où lasource est découpée en sous-bandescodées chacune séparément) sont descodeurs de parole à plus bas débitcomme le MICDA à 32 kbit/s (Rec. G.726ou G.721) utilisés dans les PCME, DCME,DECT, BeBop et POINTEL. Des variantes à 16, 24 et 40 kbit/s existent mais la qualité de parole se dégrade très vitequand le débit chute à 16 kbit/s.

La technique paramétrique consiste àmodéliser sous forme simplifiée à l’aide de paramètres pertinents le signal deparole à la source, et de les transmettresous forme numérique au récepteur qui se charge de reconstituer un signalproche du signal initial. Cette technique ne conserve pas la forme temporelle dusignal mais préserve le spectre à courtterme reproduit à l’arrivée grâce à un circuit d’excitation et un filtre prenant encompte les paramètres en question.

8. Ne peut-on envisager que les deux modes de téléphonie coexistent comme aujourd’hui lecourrier, le fax et la messagerie ?

51

Dans cette classe, les codeurs de typeLPC (Linear Predictive Coding) utilisentune excitation mixte : train d’impulsionspour les signaux voisés et bruit blanc pourles signaux non voisés selon notammentla norme LPC 10 FS1015 du Départementde la Défense américain (DOD). Si cettetechnique permet en pratique des débitstrès bas (2,4 kbit/s) elle peut effectivementrecevoir le qualificatif de “militaire” car la parole reproduite n’est pas très fidèle(surtout pour les voix féminines) et présente une caractéristique synthétique(phénomène de voix métallique).Les codeurs par analyse et synthèsesont à l’heure actuelle les plus performants et les plus utilisés : ils utilisent de façoncomplémentaire les avantages des techniques temporelles et des techniquesparamétriques pour obtenir des faiblesdébits tout en préservant la qualité de restitution. Différentes sous-classes dans cette technique correspondent à la méthode de représentation du signald’excitation du circuit de sortie.Les codeurs CELP (Code Excited LinearPredictive Coder) sont les plus nombreuxaujourd’hui dans cette classe. Le meilleurcodeur CELP (qualité équivalente à un MIC7 bits) est sans aucun doute le LD-CELP(Low Delay-Code Excited Linear PredictiveCoder) correspondant à la RecommandationUIT G.728 à 16 kbit/s : ce codeur CELPest le seul actuellement à transmettre correctement la musique et tous les bruitsde fond.Les autres codeurs CELP sont plus orientés codage de la parole seule. Lescodeurs UIT G.729 et G.723.1 sont descodeurs récents qui se distinguent parleur débit, retard de transmission, par leurqualité de parole et par leur gammed’applications :

n le codeur UIT-T G.729 CS-ACELP(Conjugate-Structure Algebraic-Code-Excited Linear-Prediction de NTT/FT-CNET/USH/AT&T) à 8 kbit/s est uncodeur multi-usages pour des applicationsde radios mobiles numériques (au JAPONnotamment) et de DCME (Digital CircuitMultiplication Equipment) et PCME (PacketCircuit Multiplication Equipment, voir UITG.764) ,

n le codeur UIT-T G.723.1 qui se déclineen MP-MLQ (Multipulse MaximumLikelihood Quantization pour l’excitation à 6.3 kbit/s d’origine AudioCodes/DSPGroup) et ACELP (Algebraic CodebookExcited Linear Prediction pour excitation à 5.3 kbit/s d’origine FranceTélécom/Université de Sherbrooke) a étésélectionné pour les visiophones sur RTCconformes à la Recommandation UITH.324 et prévue dans la déclinaisonH.323 sur réseaux en mode datagramme.Les codeurs RPE-LTP (Regular PulseExcited-Long Term Predictor) comme celuiutilisé dans les radio mobiles numériquesde type GSM à 13 kbit/s (norme ETSIGSM 06-10) sont les plus anciens, les plussimples et certainement les plus utilisésde cette classe de codeurs par les logiciels de téléphonie IP.

52

Glossaire

ACELP : Algebraic Code Excited Linear PredictionACD : Automatic Call DistributorACTA : American Carriers Telecommunication AssociationADPCM : Adaptive Differential Pulse Code ModulationATM : Asynchronous Transfer ModeCAA : Commutateur à Autonomie d’AcheminementCAR : Committed Access RateCTI : Computer Telephony IntegrationCELP : Code Excited Linear PredictiveCS-ACELP : Conjugate Structure Algebraic Code Excited

Linear PredictionDCME : Digital Circuit Multiplexing EquipmentDOD : Department Of DefenseDSP : Digital Signal ProcessorETSI : European Telecommunications Standard InstituteFCC : Federal Communications CommissionFIFO : First In First OutGSM : Groupe Spécial MobilesIETF : Internet Engineering Task ForceIMTC : International Multimedia Teleconferencing ConsortiumIP : Internet ProtocolISO : International Standard OrganisationLAN : Local Area NetworkLD-CELP : Low Delay CELPLPC : Linear Predictive CodingPBX : Private Branch eXchangePCME : Packet Circuit Multiplexing EquipmentMC : Multipoint ControllerMCU : Multipoint Conference UnitMICDA : Modulation par Impulsion et Codage Différentiel AdaptéMIT : Massachusett Institute of TechnologyMP : Multipoint ProcessorMP-MLQ : MultiPulse Maximum Likelihood QuantizationQdS : Qualité de ServiceRAS : Registration, Admission, StatusRED : Random Early DetectionRNIS : Réseau Numérique à Intégration de ServicesRPE-LTP : Regular Pulse Excited-Long Term PredictorRSVP : Resource reSerVation ProtocolRTC : Réseau Téléphonique CommutéRTCP : Real-time Transport Control ProtocolRTP : Real-time Transport ProtocolSB-ADPCM : Sub Band ADPCMTCP : Transport Control Protocol

TIPHON : Telecommunications & IP Harmonization Over the NetTOS : Type Of ServiceUDP : User Datagram ProtocolUIT : Union Internationale des TélécommunicationsVAT : Visual Audio ToolVoIP : Voice over IPVON : Voice On the NetWFQ : Weighted Fair QueuingWRED : Weighted RED