Téléphonie sur Internet : quelles perspectives?

Transcription

1 Téléphonie sur Internet : quelles perspectives? Patrice Collet Michel Dudet Olivier Hersent Etienne Turpin Patrice Collet, X65, ENST 70 est directeur des architectures et de la planification à la Branche Réseaux. Auparavant, il a dirigé le centre Lannion A du 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érieure de Physique (1980), chef de département au sein du groupement services de courrier électronique du SEPT de Caen, responsable du pôle de compétence Internet du CNET. Il a commencé sa carrière au CNET Lannion en 1982 sur les systèmes de transmission numérique. Olivier Hersent, X91, ENST 96 a débuté au CNET en 1995 en se spécialisant sur les évolutions des réseaux IP, notamment la mise en œuvre des services temps réel et sur la multidiffusion. Il est l auteur de plusieurs communications sur la téléphonie IP. Etienne Turpin, X71, ENSAE, est chef du Service des études Economiques et Technico-économiques du CNET, Branche Développement, service chargé des études sur les coûts et la rentabilité des produits et techniques innovants. Il est professeur associé à l ENST, et membre du Conseil national de l Information Statistique. 31

2 Téléphonie sur Internet : quelles perspectives? La téléphonie sur Internet trouve sa finalité dans l intégration de services en temps réel. Mais encore faut-il s orienter dans la jungle des normes et maîtriser la complexité des protocoles. la seconde, celle des Services, est marquée par l accélération de l innovation, la multiplication des services et la pluralité des réseaux. Introduction Les technologies de l information apportent régulièrement leur lot d innovations ouvrant de nouvelles possibilités de communication. Si l on conçoit bien les avantages qu elles peuvent nous apporter en 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 encore l année du groupware sera t-elle l année de la téléphonie sur Internet? Cette question cache en fait de multiples enjeux majeurs susceptibles chacun de bouleverser la donne. Enjeux commerciaux : le support Internet est perçu comme gratuit par l utilisateur. Mais qui supporte réellement les coûts d un service et quels sont-ils? Quels sont les différents modèles économiques et chaînes de valorisation (ex. le flat rate est-il viable)? Quel rapport qualité/prix les utilisateurs souhaitent-ils : tout comme le Web est traité de World-Wide Wait, la téléphonie Internet risque-t-elle de devenir cacophonie sur Internet? Enjeux réglementaires : un opérateur de services vocaux sur Internet doit-il être considéré comme un opérateur d interconnexion téléphonique et respecter en temps que tel la réglementation du pays concerné? Enjeux d usages : quelle ergonomie est acceptable par les utilisateurs, quel est l impact des PC multimédia, utilisation privative ou professionnelle? Enjeux techniques, enfin : délais dus à la nature du codage et du réseau qui empêchent un véritable mode conversationnel, traitement de l écho, procédures d acheminement, annuaires, interopérabilité, couverture géographique, etc. Après avoir brièvement rappelé le contexte technico-économique qui a favorisé l éclosion de la téléphonie IP, le présent document s attache à clarifier de quels services on veut parler car le concept de téléphonie sur réseaux IP peut prendre en fait de multiples formes : c est l objet du chapitre sur Quels service pour un opé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 constructeurs peuvent envisager d autres types produits. Le reste du document se concentre sur les enjeux techniques, (chapitre sur les Problèmes techniques à résoudre ) et les solutions d architecture proposées pour les résoudre en se concentrant sur les équipements terminaux et serveurs (chapitre sur l Architecture ). Les techniques des réseaux IP pour le transport de flux temps-réel sont ensuite brièvement abordées dans le chapitre traitant de l Impact majeur des infrastructures réseaux. Enfin le dernier chapitre présente quelques éléments d analyse économique. 32

3 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 sont apparues depuis le début des années 80 : un réseau disposant d une bonne bande passante (e.g. un réseau Ethernet à 10 Mbit/s peu chargé) allié à la puissance d une station de travail effectuant le codage permet des échanges audio/vidéo. C est sur ce créneau que commence à se développer le savoir faire de petits éditeurs de logiciels spécialisés. Essor du CTI En parallèle, on assiste à la naissance d une industrie liée à l intégration de la téléphonie et de l informatique : cartes à processeurs spécialisés pour la commande d appel à partir d un microordinateur, l intégration de boîtes de messagerie vocale, etc. (gourmands en bande passante) que de destinataires : la solution consistait à regrouper les flux qui empruntent une même route puis à les expanser dans des routeurs multicast au fur et à mesure que les routes divergent pour joindre le destinataire final. Depuis 1993, le Mbone a constitué un terrain d expérimentation naturel pour les protocoles de transmission temps-réel ainsi qu au sein du groupe IETF créé spécialement à cet effet : Audio-Vidéo Transport Working Group (AVT-WG). Les codeurs à bas débit (tableau 1) Les codeurs de parole utilisés dans les logiciels de téléphonie IP peuvent être classés suivant trois grandes techniques de codage : techniques temporelles (débits compris entre 16 et 64 kbit/s), techniques paramétriques (débits entre 2.4 et 4.8 kbit/s), techniques par analyse et synthèse (débits entre 5 et 16 kbit/s ). Les deux dernières catégories présentent l 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. chapitre annexe pour plus de détails sur les codeurs). 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 suivant cinq catégories : 1 = Mauvais, 2 = Médiocre, 3 = Moyen assez bon, 4 = Bon, 5 = Excellent, pour des conditions sans bruit de fond (clean speech), de complexité de réalisation (en MIPS DSP 16 bit fixe) et de retard de codage/décodage. Mbone Le développement d applications de voix et vidéo sur Internet est lié à celui du réseau Mbone dont le nom correspond à la contraction de Multicast Backbone. Il s agit d un réseau de diffusion mutipoint créé à l origine pour un besoin interne de l IETF qui désirait pouvoir diffuser en visioconférence ses réunions afin de pouvoir joindre ses correspondants empêchés de se déplacer. La technique Mbone fut conçue au Xerox Parc sous la conduite de Steeve Deering puis adoptée à l IETF mi Il s agit en fait d un réseau superposé au réseau Internet classique ou les paquets multicast sont encapsulés dans des paquets IP classiques, puis traités dans les routeurs capables de les exploiter. Ce réseau était techniquement nécessaire pour éviter de saturer le réseau classique en envoyant autant de flux audio/vidéo Codeur Temporel Temporel Analyse/Synthèse Analyse/Synthèse Paramétrique PCM MICDA RPE-LTP CELP LPC Standard/norme G.711 G.726 ETSI GSM DOD FS1016 DOD LPC10 FS1015 Débit 64 kbit/s 32 kbit/s 13 kbit/s 4.8 kbit/s 2.4 kbit/s Qualité de parole (MOS) Retard codeur+décodeur 125 s 300 s 50 ms 50 ms 50 ms Complexité Mips Codeur Analyse/Synthèse Analyse/Synthèse Analyse/Synthèse LD-CELP CS-ACELP MP-MLQ-ACELP Standard/norme G.728 G.729 G Débit 16 kbit/s 8 kbit/s 6.3 et 5.3 kbit/s Qualité de parole (MOS) /3.7 Retard codeur+décodeur 3 ms 30 ms 90 ms Complexité Mips Tableau 1 - Caractéristiques des codeurs de parole pour la téléphonie IP. 33

4 L apparition des standards La première application d audioconférence sur Mbone, dénommée Visual Audio Tool (VAT) a été développée par Van Jacobson au Lawrence Berkeley National Laboratory (LBLN) : c est à l occasion de ces travaux qu à été défini et testé le protocole de transport temps réel RTP (cf. description détaillée plus loin). RTP est approuvé fin 1995 comme proposition de standard IETF, puis début 1996 comme standard. Cette stabilisation du protocole déclenche l adhésion des grands éditeurs dont Netscape, Microsoft et le pionnier Vocaltec. 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éservation de ressources dans les routeurs, RSVP, laisse précisément entrevoir des possibilité de réserver l équivalent d un circuit virtuel sur les réseaux IP, garantissant ainsi un transfert temps-réel fiable. Enfin, un standard complet de service apparaît avec la finalisation par l UIT-T de la Recommandation H.323, adaptation des normes de visioconférence RNIS aux réseaux locaux sans connexion. Cette norme et vigoureusement promue par Microsoft et Intel début 1997 pour l imposer comme standard d échange temps réel sur Internet, entraînant dans leur sillage une majorité d éditeurs de logiciels. La promotion par des forums L année 1996 voit en outre se créer plusieurs forums traitant d applications temps-réel sur IP : Création par le MIT d un consortium visant à étudier les conditions techniques et économiques de mise en place de la téléphonie sur Internet et de lancer des expérimentations à l échelle internationale. Mise en place de la coalition Voice On the Net (VON) des nouveaux offreurs de produits et de services de téléphonie sur internet et le dépôt auprès de la FCC américaine d une plainte pour concurrence déloyale par l association des opérateurs longue distances ACTA. Le forum Voice over IP, similaire à VON, a fusionné en novembre 96 avec l IMTC (International Multimedia Teleconferencing Consortium), forum bien connu dans le domaine de la visioconférence, pour créer un groupe spécial d activité autour de la téléphonie IP : il regroupe les principaux offreurs de produits de téléphonie IP (dont Microsoft, Nortel et Cisco). Début 1997, l ETSI crée un projet spécifique, TIPHON, étudiant l intégration de la téléphonie IP avec les réseaux publics commutés (RTC, RNIS, GSM). L apparition des produits Logiciels pour PC L explosion d Internet avec le Web début 1995, conjuguée à la montée en puissance considérable des processeurs pour PC (loi de Moore oblige) conduit les éditeurs de logiciels disposant d un savoir-faire sur LAN à proposer des produits pour Internet, relayés bientôt par les poids lourds du marché imposant le standard H.323. L utilisation de ces logiciels par quelques utilisateurs pionniers relève alors d un comportement assimilable à ceux des radios amateurs : on rentre en relation avec des correspondants inconnus à l autre bout du monde au prix de manipulations pointues. Passerelles Mais c est l apparition de passerelles avec le réseau téléphonique standard qui consacre l avènement du concept de voix sur Internet : elle permet en effet de s appuyer sur le parc des téléphones ordinaires. On s adresse ainsi au plus grand nombre, tout en bénéficiant à la marge de la connectivité quasi-gratuite d Internet. Ces passerelles sont généralement basées sur des cartes DSP (Digital Signal Processor) développées à l origine par les industriels du domaine CTI. Ces cartes, implantées en général sur des systèmes de 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 par machine). Les premiers services Avec l apparition des passerelles, plusieurs opérateurs de callback ou de revente de capacité se lancent dans des services de téléphonie IP en déployant des points de présence à l International dans des grandes villes. Aux USA, on assiste également à la valorisation d infrastructures alternatives avec ce type de service (e.g. réseau de fibres optiques d un transporteur ferroviaire). 34

5 Quels services pour un opérateur Pour bien analyser le phénomène de la téléphonie IP, il convient tout d abord de classifier les différents services possibles. Toutefois une telle démarche peut donner des résultats différents suivant le point de vue où l on se place : éditeur de logiciels, fabriquant de périphériques, constructeur d équipements de télécommunications, SSII, opérateurs de services à valeur ajoutée, etc. La démarche qui suit se place du point de vue d un opérateur de télécommunications. Figure - 1 Communication directe de PC à PC. Internet Annuaire 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-duplex pour une conversation simultanée), d un modem 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 logique du 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 97 sont apparus les premiers standards autour des éléments H.323 et T.120 conçus à l origine par l Union Internationale des Télécommunications (UIT) pour la visioconférence sur réseau local informatique. Tous les logiciels ont tendance à s aligner désormais sur ces standards. Ces logiciels sont véritablement multimédia, c est-à-dire que la voix et la vidéo sont intégrées à un ensemble d applications de données comme le transfert de fichier, la messagerie, etc. Ils permettent également de prendre le contrôle d une application sur le PC distant, ce qui ouvre un champ important d utilisations possibles comme le télé-enseignement, la maintenance à distance, etc. Les principales limitations pour ce type d utilisation sont dues à l incapacité du réseau Internet à garantir un transfert fiable et rapide de l information, provoquant une piètre qualité d écoute (il reste toutefois possible de mieux contrôler les liens de transit vers des fournisseurs d accès partenaires par des accords bilatéraux). L utilisation des annuaires en ligne s avère également problématique lorsque la population d utilisateurs croît. Le marché de ce type de service s adresse aux clients des fournisseurs d accès Internet (comme Wanadoo) qui sont assez naturellement équipés d un PC multimédia (cf. récente explosion des ventes en France). Le moteur est essentiellement le gain de coût pour les utilisateurs : il est particulièrement fort pour les communications internationales. PC multimédia sur Intranet Dans ce cas, le réseau intranet de l entreprise vient se substituer à Internet et les limitations précédentes sont en partie levées. La gestion des routeurs et le dimensionnement du réseau sont alors sous le contrôle d un seul opérateur pour les besoins d une entreprise, permettant ainsi de mieux gérer les problèmes de congestion et de file d attente propres à IP. Il faut savoir en effet que le temps de transfert d un paquet IP dans un routeur est fonction du volume de données global que celui-ci doit écouler. Plus un réseau est chargé, et plus le temps de transfert sera long. Afin d éviter un effet d avalanche, le protocole IP prévoit ainsi de se débarrasser automatiquement des paquets qui ont séjourné trop longtemps dans le réseau. Ce contrôle d un réseau intranet a un coût. La logique qui prédomine ici n est donc plus de réduire les coûts, mais d offrir de nouvelles fonctionnalités grâce aux 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 de travail complet. A noter toutefois que la traversée des pare-feu de l entreprise (firewalls) peut s avérer problématique, d une part parce que ces derniers introduisent des retards dus à l analyse des paquets, d autre part parce que le standard H.323 utilise des ports UDP établis de façon dynamique (voir plus loin), souvent incompatibles avec la gestion des tables de contrôle d accès des pare-feu. Le marché est ici celui des applications Intranet et le moteur est le gain de productivité des entreprises mettant en œuvre cette nouvelle forme d échange. 35

6 Service téléphonique IP (fig. 2) Tout le monde n étant pas forcément équipé d un PC, une évolution importante du premier type de service est apparue lorsque le codage/décodage de la voix sur IP a été mis en œuvre sur des serveurs (et non plus sur des terminaux PC) assurant une fonction de passerelle avec les réseaux téléphoniques classiques. Cette configuration permet aux utilisateurs de 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 chapitre consacré à Quelques éléments d analyse économique ). L opérateur du service constitue un réseau dont les passerelles forment des points de présence locaux. Elles sont reliées entre elles par un réseau sous contrôle de l opérateur permettant le respect des débits et des délais. Le marché est celui des communications téléphoniques internationales et le moteur principal est le coût pour le client. Les points critiques concernent l acceptabilité du service par l utilisateur final : rapport qualité-complexité/coût (en particulier il n est pas rare dans les produits actuels d avoir à numéroter plus de 30 chiffres), le traitement de l écho, la mise en place de nouvelles procédures de gestion et facturation du service adaptées aux nouveaux marchés et usages induits par Internet, l évolution lente des passerelles vers des standards d interopérabilité et la prise en compte de la télécopie qui ne supporte pas les mêmes règles de codage (voir plus loin). PBX Paris Télécopieur RTC Passerelle Figure 2 - Service téléphonique sur IP. Réseaux voix-données d entreprise (fig. 3) Ce type d offre correspond à la transposition sur intranet des services de réseaux voix/données d entreprise existants déjà sur d autres types d infrastructure (ex. liaisons spécialisées ou relais de trames). Les passerelles sont raccordées aux PBX des entreprises (certains constructeurs PBX Passerelle Paris Intranet Domaine opérateur Intranet Passerelle New-York ou Tokyo RTC PBX prévoient même une offre intégrée au PBX) en leur permettant d écouler leur trafic téléphonique inter-site et leurs données sur 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 de contrôle de flux dans le réseau, la gestion de plans de numérotation cohérents et la traversée des pare-feu. Passerelle Marseille ou New-York PBX Site 1 Site 2 Figure 3 - Réseau voix-données d entreprise. 36

7 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 termes d applications. Notamment en associant des équipements traditionnels des centres d appels (les Automatic Call Distributors, sorte de PBX spécialisés) avec une passerelle du même type que celle utilisée dans le service précédent mais en fonctionnement net to phone, on permet aux utilisateurs du Web de rentrer directement en contact avec un service clients. Les applications sont nombreuses, tant dans le domaine grand-public avec le commerce électronique et l après-vente que dans le domaine de l entreprise et son système d information (assistance informatique, annuaire appelant, etc.). France Télécom est déjà présent sur le cré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 seront menées en 1998 en interne en les appliquant à l Entreprise France Télécom elle-même afin de mieux appréhender les usages et les techniques et en faire bénéficier ses clients. 1 Réseau IP Web Figure 4 - Intégration téléphonie et Web. Problèmes techniques à résoudre Délai de transmission Celui-ci est très important pour bénéficier d un véritable mode conversationnel et minimiser la perception d écho (similaire aux désagréments causés par les conversations par satellites désormais largement remplacées par des câbles pour ce type d usage). 2 Passerelle PBX ACD Synthèse vocale Agent Centre d appels Or la durée de traversée d un réseau IP est dépendante du nombre de routeurs traversés, le temps de traversée d un routeur étant lui même fonction de la charge de ce dernier qui fonctionne par file d attente. Les chiffres suivants (tirés de la recommandation UIT-T G.114) sont donnés à titre indicatif pour préciser les classes de qualité et d interactivité en fonction du retard de transmission dans une conversation téléphonique (tableau 2). Classe n retard par sens commentaires 1 0 à 150 ms acceptable pour la plupart des conversations ; seules quelques tâches hautement interactives peuvent souffrir à 300 ms acceptable pour des communications faiblement interactives (voir satellite 250 ms par bond) à 700 ms devient pratiquement une communication half duplex 4 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. 37

8 Ces chiffres peuvent être complétés par un indice de difficulté de communication en fonction du retard par sens : Retard par sens Difficulté de communication Passerelle Réseau Internet RTC Allo Allo CAA Allo 200 ms 28 % 450 ms 35 % 700 ms 46 % PC multimédia (non générateur d écho électrique) Abonné perturbé par l écho créé à l autre bout. Passage 2 fils/4fils Téléphone analogique 2 fils (générateur d écho électrique) Abonné non perturbé par l écho électrique. Pour des conversations téléphoniques dès 25 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 hors temps de transmission pour les systèmes de codage). Perte de paquets Lorsque les routeurs IP sont congestionnés, ils libèrent automatiquement de la bande passante en se débarrassant d une certaine proportion des paquets entrants en fonction de seuils prédéfinis. Cela permet également d envoyer un signal implicite aux sources TCP qui diminue d autant leur débit au vu d acquittements négatifs émis par le destinataire qui ne reçoit plus les paquets (algorithme Random Early Detection - RED). Gigue La gigue correspond à une variation du délai de transmission de l information. Elle est due au mode de mise en paquets par les codeurs, à l encapsulation des paquets IP dans des protocoles support tels que le Frame Relay ou l ATM, et à la variation 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 la gigue, on utilise des mémoires tampons qui présentent l inconvénient de rallonger d autant le temps de traversée global du signal et contribue à empêcher un mode conversationnel normal. Figure 5 - Perturbation de la téléphonie sur IP par le phénomène d écho. Echo Les passerelles doivent également traiter l écho électrique généré localement par le passage 2 fils vers 4 fils (rupture d 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 service sera inutilisable avec des postes analogiques classiques. En France le phénomène est d ailleurs particulièrement préoccupant puisque 50 % des lignes analogiques produisent un signal d écho affaibli seulement de 15 db par rapport au signal originel. Or, avec un tel affaiblissement, la qualité de la communication (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 de téléphonie IP utilisés en mode full duplex intégral posent aussi des problèmes graves d échos acoustiques lorsque l on utilise le microphone branché sur la carte son et les enceintes acoustiques multimédia couramment fournies. Certains logiciels proposent un contrôle de l écho en jouant sur le seuil de déclenchement de la parole et le niveau de suppression d écho. Mais ils consomment de la puissance processeur supplémentaires et commencent à être supplanté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 leurs modems supporte mal un codage avec compression. En pratique l offre existante prend en compte 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éphonique ou d une télécopie. Deux types de services existent pour la télécopie : transmission en store & forward au même titre qu une messagerie qui permet une certaine souplesse (ex. gestion de listes de diffusion sur la passerelle) mais présente l inconvénient d avoir à gérer des accusés de réception dont les utilisateurs de 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 ) ; 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. 38

9 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. UDP Les communications de téléphonie sur réseaux IP n utilisent pas la couche de transport TCP (équivalent du transport défini par l ISO) mais la couche UDP (User Datagram Protocol) qui fonctionne en 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 un transfert fiable (réenvoi des paquets IP en cas d erreur) mais est malheureusement incompatible avec un flux temps-réel dans la mesure ou les mécanismes de TCP prévoient une réduction automatique du débit accordé à l émetteur en cas de congestion du réseau et une remontée lente vers le débit nominal (ceci afin de protéger le réseau de soubresauts d émetteurs qui chercheraient tous en même temps à tirer parti de la bande passante disponible). UDP est un protocole sans correction d erreur (donc non fiable) dont la fonction essentielle consiste à différencier les différents services applicatifs comme la messagerie, le transfert de fichiers, le Web, la voix, la vidéo, etc. en les aiguillant vers le bon module de traitement logiciel à l arrivée. Cet aiguillage s effectue en associant un numéro de port à chaque application. Ceci n est pas sans incidence sur le passage au travers des équipements de contrôle d accès utilisés sur les intranet/extranet appelés communément gardes barrières (firewalls) : à la différence des services précités qui impliquent des communications de type client/serveur, les logiciels de téléphonie font intervenir des communications client/client en utilisant des numéros de port disponibles de façon dynamique (voir présentation de H.323 ci-après). Or le filtrage des pare-feux (firewalls) les plus 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 inter entreprises. RTP/RTCP Pourquoi RTP/RTCP? RTP a pour but de fournir un moyen uniforme de transmettre sur IP des données soumises à des contraintes de temps réel, par exemple des flux audio ou vidéo. Sous le nom global RTP on désigne en fait les protocoles RTP et RTCP. RTP permet d identifier le type de l information transportée, d y ajouter des marqueurs temporels et des numéros de séquence et de contrôler l arrivée à destination des paquets. RTP n a pas été conçu pour effectuer des réservations de ressources où contrôler la qualité de service. RTCP est un protocole de contrôle des flux RTP, permettant de véhiculer des informations basiques sur les participants d 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 envoie l information du micro en blocs de 20 ms le ou les autres destinataires. 1 er problème : chacun pourrait utiliser un format de codage différent : on indique donc le type de codage dans le header (ADPCM, PCM, GSM...), cela permet aussi de réagir aux indications de congestion du réseau. 2 e problème : on ne peut traiter chaque paquet reçu comme il arrive, car Internet ne garantit ni ordre ni délai : il faut donc ajouter un marqueur temporel à chaque paquet pour reconstituer une séquence audio intelligible. De cette manière on peut aussi voir combien de paquets ont été perdus. 3 e problème : comment indiquer que des participants arrivent où s en vont? Pour cela on envoie également en multicast des informations de contrôle sur qui arrive et qui part ( RTCP). Cela évite de parler tout seul! Par cette voie un participant peut aussi indiquer 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 et transport sous jacentes. Sur IP, RTP utilise un port pair et RTCP le port suivant (impair). Fonctionnement de RTP RTP permet l acheminement de bout en bout de données avec des caractéristiques temps réel. RTP peut être véhiculé par des paquets multicast afin d acheminer des conversations vers des destinataires multiples. Le rôle principal de RTP consiste à mettre en œuvre des numéros de séquence de paquets IP pour reconstituer les informations de voix ou vidéo même si le réseau sous-jacent change l ordre des paquets, ce qui est susceptible de se produire dans la mesure où le fonctionnement d Internet ne garantit pas que deux paquets successifs empruntent la même route. Cela permet, par exemple pour des applications vidéo, de décoder et placer au bon endroit sur l écran chaque paquet sans attendre ses prédécesseurs et pour des applications de voix de reconstituer les échantillons de parole. Le rôle de RTP reste donc limité : RTP ne garantit pas que le paquet va arriver, RTP n assure pas que le paquet va arriver à temps, RTP n assure pas que chaque paquet va arriver en séquence. RTCP permet de vérifier la qualité de service et de transmettre des informations sur les participants. RTP en lui même n est pas un standard définissant le type de codage employé pour l information transportée. Cette information est décrite dans des descriptions de profils (donnant des codes identifiant des formats standards) et des descriptions de formats. En particulier 39

10 certaines applications peuvent définir pour leur profil des champs de données obligatoires qu elles considèrent comme des extensions de l en-tête. Mais pour RTP ces champs supplémentaires sont considérés comme faisant partie de l information transportée. Eléments d architecture de RTP Les principaux éléments qui rentrent en compte dans le fonctionnement de RTP sont les suivants. Payload : les données temps réel transportées par RTP dans un paquet (le format du contenu lui même n est pas défini par RTP). RTP packet : un paquet de données constitué de l en-tête RTP fixe, d une liste de sources participant au flux, et enfin du payload. RTCP packet : un paquet de contrôle constitué 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). Plusieurs paquets 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. Port : abstraction permettant de distinguer différentes destinations des paquets sur une même machine. Grâce à ceux-ci on multiplexe les différents paquets des sessions RTP/RTCP. Adresse de Transport : combinaison d 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). Session RTP : association d un ensemble de participants communicant via RTP. Pour chaque participant la session est définie par une paire d adresses de transport (adresse réseau + un port pour RTP + un port pour RTCP). Dans le cas du multicast l adresse transport peut être la même pour tous. Dans une session multimédia, chaque média a sa propre session RTP et ses propres paquets RTCP identifiés par des ports et/ou adresses multicast différentes. 40 Source de synchronisation (Synchronization source SSRC) : Source d un flux de paquets RTP, identifiée par 32 bits dans le header RTP. Tous les paquets ayant même SSRC ont une même référence temporelle et de séquencement. Le lien entre SSRC et participants est fait via RTCP. Source contributive (Contributing source CSRC) : Source d un flux de paquets RTP qui a contribué au flux de sortie d un mixeur. Le mixeur insère une liste d identifiants de SSRC de chaque source contributive à chaque header RTP du flux résultant de la combinaison en sortie du mixeur, liste appelée CSRC. RTCP RTCP transmet périodiquement des paquets de contrôle aux participants, utilisant les mêmes moyens de diffusion que RTP, simplement avec un numéro de port différent. RTCP permet de recevoir des informations de retour des participants, grâce aux messages sender report et receiver report. RTCP diffuse un identificateur pour chaque source RTP, appelé CNAME, c est cet identificateur qui permet d attribuer les flux RTP à tel ou tel participant, car les SSRC peuvent changer (redémarrage de programme, conflit...). Cela permet aussi de synchroniser des flux audio et vidéo venant d un même participant. Il existe différents types de paquets RTCP pour chaque type d information : SR : Sender report, statistiques de transmission et de réception pour les participants qui sont des émetteurs actifs. Receiver report, statistiques de réception pour les participants qui ne sont pas des émetteurs actifs. SDES : Source description. Descripteurs de source, dont les CNAME. BYE : fin d une participation. APP : Fonctions spécifiques à une application. Le protocole sous-jacent (TCP) peut concaté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 la Commission d Etudes 16 de l UIT-T comme variante de la norme H.320 de visiophonie sur RNIS adaptée dans ce cas aux réseaux locaux de données de type Ethernet fonctionnant en mode sans connexion et sans garantie de qualité de service (i.e. pas de correction d erreurs). L adoption et la promotion de H.323 comme standard pour les produits de voix/vidéo sur Internet et intranets par Microsoft et Intel, entraînant dans leur sillage des dizaines de petits éditeurs, a propulsé cette norme comme standard incontournable de la téléphonie sur Internet. Le standard s applique désormais à tous les réseaux de paquets, et non plus seulement aux réseaux locaux. La jungle des normes RTP/RTCP était un cadre général d implémentation de protocole de transport de données temps réel, où de nombreux paramètres restent à préciser pour une utilisation concrète. H.323 précise justement 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 corrigeant des points de détail. Elle fixe les types de contenu audio et vidéo des paquets RTP créés par une application H.323, et arbitre certains conflits entre RTCP et le protocole de contrôle défini par H.323 (sous-ensemble H.245).

11 H.323 décrit entièrement un système de visiotéléphonie sur LAN, y compris des fonctions 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 un tel système : Les terminaux H.323. Les passerelles vers des réseaux classiques (RTC, RNIS,...). Les gardes-barrières (Gatekeepers en Anglais), sortes de centres de gestion et d enregistrement qui contrôlent également l accès des terminaux au réseau IP. Les MCU (Multipoint Conference Unit), MC (Multipoint Controller) et MP (Multipoint Processor) chargés du mixage des flux et de la gestion de conférence multipoints. La Commission d Etudes 16 de l UIT-T est responsable de l évolution des normes H.323. Cependant les industriels du domaine se sont rassemblés au sein du forum VoIP (Voice over IP) lui-même sous-groupe de l IMTC (International Multimedia Teleconference Consortium) pour clarifier et compléter H.323 en contexte 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 Le travail de l IMTC est peu à peu repris par l UIT-T, notamment dans la version 2. Depuis peu l ETSI a mis en place un groupe de travail TIPHON (Telecommunication & IP Harmonization Over Networks), qui regroupe en fait tous les acteurs de l IMTC et les opérateurs télécoms et se concentre sur la standardisation des passerelles vers les réseaux publics (RTC, RNIS, GSM). Structure de H.323 Lors d une connexion, plusieurs canaux sont ouverts avec chacun une adresse propre (port UDP ou TCP suivant le type de 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 de média échangé et pour chaque sens de communication, un canal RTP est établi ainsi qu un canal de contrôle RTCP (au dessus du protocole UDP). Il est également possible d échanger des données sur un canal spécifique selon la norme T.120 (au dessus du protocole de transport fiable TCP) : cette propriété permet notamment de partager des applications entre deux micro ordinateurs comme un traitement de texte, un tableur ou un logiciel de présentation, ce qui s 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 de maniè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 canal supporte les opérations d enregistrement, d admisssion et de demande de statut auprès du garde-barrière. Au total, un PC multimédia désirant établir une connexion voix et données avec un autre PC au travers d un réseau IP devra donc établir les canaux suivant : TERMINAL A Alias : n Tél, ... Canaux de données Canaux Audio RTP : UDP RTCP : UDP 7771 RTCP : UDP Canaux Vidéo Canal de signalisation d appel TCP 1720 H.245 Canal de contrôle TCP Canal RAS Canal RTP audio de A vers B Rapport de réception RTCP Rapport d émission RTCP Initialisation Sonnerie Connexion Capacités du Terminal Capacités du Terminal OK Ouvrir Canal Logique Ouvrir Canal Logique OK canal d émission pour un flux son (sur UDP/RTP), canal de réception pour un flux son (sur UDP/RTP), canal de réception des informations de contrôle son (sur UDP/RTCP), canal d émission des informations de contrôle son (sur UDP/RTCP), canal d émission de données (sur TCP/T.120), canal de réception des données (sur TCP/T.120), canal de signalisation d appel, canal de contrôle et d échange des capacités des terminaux, canal d enregistrement, d admission auprè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 et un de contrôle pour chaque sens). Les canaux d échange de média sont optionnels : il pourrait aussi y avoir plusieurs canaux de données, pas de canal vidéo, un seul canal son par exemple. Par contre le canal de contrôle et d échange des capacités des terminaux est toujours présent pour chaque appel. La figure ci-dessous reproduit ces différents composants pour une communication bilatérale. TERMINAL B Alias : n Tél, ... Canaux de données Canaux Audio RTP : UDP 9344 RTCP : UDP RTCP : UDP 9345 Canaux Vidéo Canal de signalisation d appel TCP 1720 H.245 Canal de contrôle TCP Canal RAS Tableau 3 - Séquence type d une conversation entre deux postes H

12 Séquence type d une conversation entre 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 : Taux de transfert demandé au réseau, type de codage... Un bloc d information USER to USER avec un identificateur de protocole, l identité H.323 de la source (une chaîne de caractères), le type de la source (ici un poste LAN), l identificateur de conférence si celle-ci est en cours et si l on veut la rejoindre, 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 de canal 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 éventuellement l adresse H.245 que A devrait utiliser pour se connecter sur B, et émet encore optionnellement un message Sonnerie pour indiquer que l utilisateur B est en train d être alerté. Enfin B termine par un message Connexion qui comprend notamment : la référence de l appel (identificateur unique de cet appel). Les capacités de transfert requises selon la norme RNIS I.231 (Taux de transfert demandé au réseau, type de codage...), informations obligatoires seulement lors d un appel vers une passerelle donnant accès au RTC ou au RNIS. Indicateur de progrès. Date/ Heure. Un bloc d information User avec l adresse de transport H.245 que A doit employer pour négocier les capacités, le Type de Destinataire, l éventuel numéro d identificateur de conférence. Première communication et échange de 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 est unique pour chaque appel d un terminal à l autre, même si cet appel met en jeux plusieurs flux audio (langues) et/ou vidéo. Le numéro logique H.245 de ce canal est toujours 0. Soit ce canal H.245 est ouvert par B lorsqu il reçoit le message Initialisation, soit il est ouvert par A lors de la réception du message Sonnerie ou Traitement d appel en cours. L adresse et le port à employer ont été donnés dans l un de ces messages. Le premier message H.245 envoyé est Capacités du terminal, qui comprend notamment les informations suivantes : un numéro de séquence, les capacités de multiplexage de flux (Capacités Multiplex). Table de capacités : contient les possibilités d échange et de compression audio ou vidéo, de chiffrement et d échange de données : par exemple type de codages vidéo acceptés, types de codage audio, paramètre de la norme d é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 message Capacités du terminal OK. Ils déterminent ensuite 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 (Multipoint Controller) ou à ouvrir l un vers l autre et simultanément un canal bidirectionnel. Etablissement de la communication audiovisuelle Les paquets de données voix et image vont circuler dans plusieurs canaux logiques H.245. Sauf pour les éventuelles données T.120, ces canaux sont unidirectionnels. A ouvre donc un canal logique vers B pour le son. Il envoie pour cela un message H.245 OuvrirCanalLogique qui contient le numéro qui sera attribué au canal H.245 à ouvrir et les paramètres correspondant (numéro de port, type de données (audio g711), et les paramètres additionnels que sont, par exemple pour des données H.225.0, le numéro de session RTP, l adresse de transport pour les données de retour RTCP (IP+port) unicast ou multicast, le type de données RTP, et si l émetteur cesse d émettre pendant les silences). B renvoie OuvrirCanalLogiqueOK pour ce numéro de canal H.245, il y mentionne le port UDP où A peut envoyer ses données RTP, 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 établis précédemment selon le protocole RTP/RTCP repris par H Plus précisément, les données RTP circulent vers le numéro de port précisé dans OuvrirCanalLogique, et les données RTCP sur le port suivant. Fin Celui qui raccroche ferme son/ses canaux logiques grâce au message H.245 FermerCanalLogique correspondant au numéro de canal ouvert, acquitté par un message FermerCanalLogiqueOK. Il envoie un message H.245 FinSessionCommande, attend de recevoir le 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. 42

13 Cas plus complexe : appel d un poste sur le LAN à destination d un usager du téléphone classique On suppose ici que sur le LAN se trouve un GateKeeper chargé de contrôler les accè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 le réseau, qui les facture. Enfin, il sait résoudre les alias H.323 en adresses IP. Le monde H.323 compte également des contrôleurs multipoint (MC/MCU) qui interviennent lors des conférences pour synchroniser les participants et assurer le mixage des flux... Première phase : où est le Gatekeeper? Tout gatekeeper doit écouter l adresse multicast sur le port UDP Le terminal envoie un message UDP Gatekeeper Request (GRQ) vers cette adresse et ce port. Décrit dans H.225.0, le message GRQ comprend notamment : L adresse/port RAS utilisée par ce terminal et sur lequel doivent parvenir les réponses. Le type de terminal. Un ou plusieurs gatekeepers répondent alors par un message Gatekeeper Confirm (GCF) à destination du port RAS du terminal ; ce message comprend : Le nom du gatekeeper. L adresse/port RAS utilisée par ce gatekeeper. Le terminal choisit son gatekeeper et s enregistre auprès de lui grâce au message Registration Request (RRQ) envoyé vers l adresse du gatekeeper choisi sur le port UDP Ce message apporte les mêmes infos que GRQ. Le gatekeeper répond par le message Registration Confirm (RCF) toujours vers le port RAS spécifié par le terminal où l on trouve : une adresse/port H.225 pour les messages de contrôle d appel à envoyer vers ce gatekeeper, RNIS T2 PASSERELLE Alias : n Tél., ... Canaux de données Canaux audio/vidéo Signalisation d appel Canal de contrôle H.245 Canal RAS Figure 6 - Etapes d un appel complexe. 1 Découverte du GK (GRQ) - Adresse RAS pour réponse - Alias - Type de Terminal GK répond avec l adresse de son canal RAS (RCF) 3 Demande d admission Type d appel (1 vers 1) Bande passante demandée Destination GK répond avec l adresse Signalisation d appel à utiliser éventuellement un alias ( Numéro E164, Chaîne...) par lequel ce terminal sera connu en dehors du LAN, un identificateur unique que le terminal devra rappeler lors des messages suivants. Deuxième phase : trouver le destinataire On suppose que les destinataires téléphoniques ont un alias de la même forme qu un numéro téléphonique standard (adressage selon la norme E.164 de l UIT-T). Le terminal envoie sur le port UDP 1719 (ou sur le port 1718 de ) du gatekeeper un message Location Request (LRQ) où il indique l alias de son correspondant et l adresse où il souhaite la réponse. Le gatekeeper répond sur le port indiqué et donne l adresse de transport IP et le port où contacter le correspondant pour envoyer les messages de signalisation d appel Q.931.0, ainsi que le couple IP/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 7 RTP/RTCP 4 Setup 5 Connect 6 H.245 GATEKEEPER Adresse Multicast de découverte UDP171 Canal RAS (1719 en G al ) Signalisation d appel Canal de contrôle H Enregistrement (RRQ) GK répond en assignant un UID au terminal TERMINAL Alias : n Tél., ... Canaux de données Canaux audio/vidéo Signalisation d appel Canal de contrôle H.245 Canal RAS un autre gatekeeper) car il souhaite s intercaler, par exemple pour faire de la réservation de ressources RSVP entre lui et le distant, soit il indique directement l adresse du distant, ici la passerelle IP/RTC. Troisième phase : demande d admission Le terminal envoie alors un messages RAS Admission Request (ARQ) à son gatekeeper qui comprend notamment : le numéro séquentiel de la demande, le type d appel (Point à Point, un vers N, N vers un, N vers N), le modèle d appel (Direct ou Via Gatekeeer), l identificateur unique du terminal appelant (attribué plus haut par le message RCF), l adresse du terminal de destination (adresse E.164 ou ID H.323 : celle que B a enregistré auprès de son gatekeeper), l adresse E.164 ou H.323 de la source, la bande passante bidirectionnelle en multiples de 100 bit/s ( par exemple 2*64 kbit/s pour une conversation G.711). 43

14 Le gatekeeper répond par un message AdmissionConfirm (ACF) où il alloue une bande passante maximum (peut-être moins que demandé) et si il veut router l appel ou non. Il indique l adresse signalisation d appel à utiliser pour la signalisation Q.931, selon le routage la sienne 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 veut pas router l appel, le terminal envoie un message de Initialisation sur l adresse/port (1720 sauf si le gatekeeper a indiqué autre chose) que le gatekeeper vient de lui indiquer pour son correspondant. Dans notre cas c est la passerelle IP vers le réseau téléphonique. Le message initialisation contient les informations suivantes : capacité de transport, éventuellement le numéro E.164 de l appelant. le numéro E.164 de l appelé, et un champ User To User mentionnant l adresse de transport H.245 que le terminal voudrait utiliser (facultatif), l identité H.323 de la source, le type du terminal appelant (gâterai ou non), l adresse de destination de l appel si pas fait dans la partie Q.931, 44 éventuellement l identificateur de conférence, et la raison de l appel (invitation, début de conf...), le type d appel (PointToPoint). La passerelle, avant de répondre, demande elle-même une autorisation d admission à son gatekeeper (ARQ/ACF). Dans le message initialisation reçu de la passerelle se trouve le numéro E.164 à appeler, qui sert à la numérotation après transformation en fonction du lieu où se trouve la passerelle, l IMTC recommande l usage d un préfixe de sortie, comme pour un PBX d entreprise. En attendant que le distant décroche, la passerelle envoie régulièrement sur le port 1720 de l appelant des messages Sonnerie et Traitement d Appel en Cours (au moins toutes les 4 secondes selon IMTC pour indiquer la progression de l appel. Enfin, au décrochage du distant, la passerelle envoie vers le terminal du LAN un message Connexion (précédé éventuellement de Traitement d Appel en Cours, Sonnerie..., comme décrit dans Q.931 annexe D et les documents de IMTC...) où il donne notamment son adresse/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 plusieurs garde-barrières coopérants permet d envisager des services de type réseau intelligent transposés dans le contexte de la téléphonie IP comme le montrent les deux exemples suivants. Transfert d appel Le transfert d appel est un service supplémentaire qui permet à un utilisateur de transférer un appel en cours vers un autre correspondant. Ici A et B sont en conversation, et A décide de transférer l appel à un correspondant C. Transfert aveugle Dans ce type de transfert A ne laisse pas B vérifier que C est joignable avant de se déconnecter. On est en pleine conversation, établie comme vu précédemment. A envoie un message Facility, dont le champ FacilityReason est de type calltransfer et contient un élément CallTransfertInvoke informant B de l 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 de l 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 B envoie le message Facility (CallTransferResult=success ou failure). En fonction du résultat, il se déconnecte alors de B comme précédemment ou continue la conversation avec B Transfert avec consultation A (par exemple un secrétariat) veut demander à C si il souhaite prendre l appel avant de le mettre en communication avec B. A envoie alors à B un message H.225 Hold, B répond par HoldAck, et la conversation est suspendue.

15 A établit un appel avec C (message Setup avec 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 le message Facility comme précédemment. Plan de numérotation privée H.225 possède la capacité de supporter un plan de numérotation privée selon la norme ISO/IEC Sur le LAN, le garde-barrière devra donc être capable de traduire en adresses de Transport aussi bien des adresses E.164, des Ids H.323 que des adresses ISO/IEC Pour ajouter ce support, la partie Called Party Number et Calling Party Number du message Initialisation est modifiée : les bits qui indiquent le plan de numérotation utilisé 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 pour pouvoir indiquer la capacité à numéroter selon un Plan de numérotation privé. Garde-barrière et agent intelligent personnel Lorsqu on utilise le garde-barrière pour router les appels (et non pas seulement pour la résolution nom ou numéro téléphonique E.164 vers adresse IP), il devient possible de piloter des services de redirection d appels complexes gérés par un agent intelligent personnel. Ce module logiciel peut assez facilement être paramétré par l utilisateur final à l aide de formulaires Web : cette tendance à utiliser le Web est en fait assez générale dans le domaine des systèmes de gestion de réseaux. Un tel agent personnel permet de gérer les conditions de reroutage des appels vers un 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 toutes les possibilités de services et d intégration d applications d Internet / intranet. L impact majeur des infrastructures réseau Comme on l a vu précédemment, le transport de la voix sur un réseau IP reste essentiellement non fiable du fait des faiblesses inhérentes au protocole de transport RTP : ce protocole reconstitue les séquences de paquets mais ne garantit pas que les paquets vont arriver et encore moins qu ils vont arriver à temps pour être exploitables compte-tenu des contraintes de délai imposées par un conversation humaine (300 ms maximum). Toute l architecture précédente est donc remise en cause si le réseau IP lui même n est pas en mesure d apporter des garanties de qualité de service en termes de débits et de délais. Les constructeurs de routeurs et l IETF ont défini un certain nombre de mécanismes permettant de contrôler la qualité de service (QdS) en réservant des ressources réseau, ce qui revient à considérer que le fonctionnement du réseau IP se rapproche alors de celui d un réseau de circuits commutés comme le réseau téléphonique! Le protocole de réservation de ressources RSVP RSVP (Resource reservation Protocol) n est pas en lui même un protocole de routage particulier mais seulement un protocole de commande qui DEMANDE la réservation des ressources en vue d obtenir une certaine qualité de service du réseau. Il doit être complété par des mécanismes de réservation effective de ressources dans les routeurs présentés au paragraphe consacré aux Mécanismes gestion 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 par l émetteur, mais il doit alors gérer la réservation pour chaque arrivée ou départ d un récepteur dans le groupe, ce qui est un travail important lorsque le groupe s élargit. De plus une telle réservation, qui serait uniforme pour chaque récepteur, devrait s aligner sur la route à plus faible bande passante. RSVP est donc un protocole de réservation initiée et maintenue par le récepteur. Pour la réservation de ressources, on penserait d emblée à indiquer une valeur moyenne de trafic, et une bande passante pour les liaisons. En fait ce n est qu une partie du problème : la majorité des problèmes rencontrés par les applications temps réel sur IP viennent des délais rencontrés sur le réseau comme on l a déjà souligné précédemment. Il y a encore d autres caractéristiques importantes à prendre en compte : ainsi un trafic très régulier est plus simple à transporter qu un trafic très sporadique avec 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 augmente de 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, un port et un protocole). Le récepteur commence par se connecter au port (supposé connu) de l application de 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és messages Path (routés normalement par le protocole unicast ou multicast sous-jacent, et avec les mêmes adresses d émetteur/destinataire que les données pour permettre le passage transparent dans les zones non-rsvp). 45

16 Ces messages (fig. 7) contiennent les caractéristiques de trafic que l émetteur va générer : un filter spec utilisable pour reconnaître les paquets de cet émetteur ainsi que les caractéristiques de son futur flot de données ( Tspec ) et intègrent comme paramètre l adresse IP du dernier routeur RSVP traversé, mise à jour par chaque routeur RSVP traversé (les routeurs non-rsvp ne touchent pas à ce paramètre). Ces données des messages Path sont stockées par chaque routeur RSVP 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 machine connaît son prédécesseur RSVP). Il peut exister plusieurs styles de Resv : on peut demander une réservation distincte pour chaque source (vidéo), ou bien une réservation collective pour toutes les sources (cas où l on parle à tour de rôle). On peut aussi préciser quelles sources on sélectionne ou envoyer un joker pour sélectionner toutes les sources. Différents types de réservations sont supportés au cas ou il y a plusieurs sources : lorsqu on s attend à ce que les sources parlent en alternance on fait de la réservation partagée, sinon on fait de la réservation exclusive. Le message Resv comprend des informations de Flowspec spécifiant la QdS demandée, et de Filter Spec identifiant les paquets de données pour lesquels cette réservation s applique. A chaque routeur RSVP traversé le message Recv du protocole RSVP interagit avec des entités appelés packet classifier et packet scheduler. Le packet classifier est responsable du routage du message et de la détermination de la catégorie de QdS demandée le packet scheduler (un par interface réseau) se charge de passer les demandes de réservation à la couche liaison si elle est capable de gérer la Qualité de Service. La demande de QdS est : soit refusée si les modules d admission (A-t-on les ressources suffisantes pour la QdS demandée?) ou de contrôle du routeur ( Policy control : droits administratifs) ne peuvent prendre en compte la demande (ce refus est signalé à l application demandeuse par un message d erreur) ; soit acceptée en fixant les paramètres du packet scheduler à l aide des informations du flowspec, et les paramètres du packet classifier à l aide du filter spec. Puis on propage la demande vers l émetteur. Cette propagation, en cas de succès, s arrête lorsqu un nœud a déjà réservé des ressources suffisantes. Chaque message Resv comprend un temporisateur au delà duquel toute mesure de réservation prise est effacée : c est donc à l émetteur et au récepteur de rafraîchir périodiquement ces informations. Au cas ou un nœud reçoit plusieurs demandes de réservation pour une même session, il réserve en amont la plus grande demandée (intérêt du multicast). Le récepteur peut demander une confirmation de la réservation, auquel cas cette demande Automate RSVP Application Packet Classifier Ordinateur Policy control Admission control Packet Scheduler RSVP données est propagée jusqu à un nœud qui a déjà réservé la bonne bande passante, et envoie l acquittement, même si on a traversé une zone de routeurs ne sachant pas traiter RSVP. Les données RSVP sont véhiculées sur IP par de simples datagrammes dont le numéro de protocole est 46. L état de réservation des routeurs est périssable ( Soft State ), RSVP envoie donc des messages de rafraîchissement périodiques le long des chemins de réservation, en l absence desquels la réservation disparaît. C est le récepteur qui 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 Path suivent alors la nouvelle route et les paquets Resv sur leur retour réalisent les nouvelles réservations. Les états associés aux routes précédentes disparaissent car ils ne sont plus rafraîchis (on peut aussi envoyer un message spécifique de fin de session). Automate RSVP Application Packet Classifier Routeur Policy control Admission control Packet Scheduler Figure 7 - Protocole de réservation des ressoures RSVP. 46

17 Mécanismes gestion des ressources dans les routeurs Mécanismes RED/WRED Le mécanisme RED (Random Early Detection), au même titre que le mécanisme WFQ présenté ensuite, n est activable que sur les files d attente en sortie des routeurs. Il fonctionne de la manière suivante : spécification d un seuil minimal et d un seuil maximal, généralement exprimés en nombre de datagrammes, et tels que : quand le nombre n de datagrammes reste inférieur à la valeur du seuil minimal, tous les datagrammes seront transmis ; quand n est supérieur à la valeur du seuil maximal, tous les datagrammes seront détruits ; lorsque n est compris entre les deux valeurs, l algorithme RED calcule la longueur moyenne instantanée de la file d attente (notion d average queue size ), puis détermine la probabilité de marquage des paquets, probabilité d autant plus grande que la valeur de la longueur moyenne 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 de décongestionner les routeurs par un contrôle implicite des sources TCP. En effet, TCP comporte un algorithme conçu par Van Jacobson qui réduit le rythme d émission de la source lorsque les accusés de réception émis par le destinataire indiquent un perte de paquets. La nature aléatoire de RED permet d agir d abord sur les sources générant le plus de paquets. En complément à ce mode de fonctionnement classique, il est possible de définir une valeur de taille de paquets IP en deçà de laquelle tous les datagrammes seront systématiquement transmis. Le mécanisme WRED (Weighted Random Early Detection) consiste à pondérer la probabilité de marquage des datagrammes caractéristique du mécanisme RED par l 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 sur une seule file d attente dans laquelle est stockée l intégralité des datagrammes, quelle que soit la valeur affectée aux bits precedence consignés dans le champ TOS des différents en-têtes. Mécanisme WFQ Le mécanisme WFQ (Weighted Fair Queuing) est un moyen de gérer l allocation des ressources en bande passante sur un lien d interconnexion donné, en fonction des profils clients définis (notion de WFQ class-based ). Cet algorithme présente les caractéristiques fonctionnelles suivantes : 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 ; aucune source de trafic n obtient plus de ressources qu elle n en a demandé (ce qui permet en particulier d assurer une fonction de police assez efficace pour le trafic des sources réputées non réactives, telles que les sources de trafic UDP) ; les sources de trafic dont les demandes d allocation de ressources n ont pu être satisfaites se voient attribuer une part des ressources restantes qui sera pondérée par le poids qui caractérisent le profil du client. L algorithme WFQ assure une fonction de gestion temporelle des files d attente dans lesquelles sont stockés les datagrammes en fonction de leur coloration donc en fonction du profil client, assez comparable à un mécanisme de multiplexage temporel. Chacune des files d attente est traitée d une manière cyclique, et un datagramme est traité de la manière suivante : le routeur détermine s il y a déjà un datagramme de la même nature dans l une des files d attente. Si c est le cas, le paquet est stocké dans la file d attente approprié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 W c de la file en cours de traitement (le poids W c est évidemment caractéristique du profil client) ; lorsqu un datagramme issu d une file d attente donnée est en cours de transmission (i.e. que le routeur transmet ce datagramme au travers de l interface de sortie correspondante), la file d attente de ce datagramme pourra dès lors être utilisée par l algorithme WFQ si un nouveau datagramme présentant les mêmes caractéristiques est parvenu dans le routeur. Dans ce cas, WFQ stocke ce nouveau datagramme dans la file d attente correspondante, et le routeur ne traitera ce datagramme que dans un temps caractéristique du poids W c. Les mécanismes WRED et WFQ class-based sont donc complémentaires, en ce sens que le mécanisme WRED applique une politique de destruction des datagrammes en cas de congestion détectée sur l interface de sortie du routeur sur laquelle le mécanisme est activé, tandis que le mécanisme WFQ assure une gestion temporelle du stockage des datagrammes dans les files d attente caractéristiques des différents profils clients définis sur la même interface, et à la manière d un mécanisme de multiplexage temporel. 47

18 Mécanisme CAR Le mécanisme CAR (Committed Access Rate) consiste à définir le comportement du routeur face à l arrivée d un trafic donné, 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). Le mécanisme s appuie sur les ressources d un algorithme de type token bucket ( seau à jetons ), dont le fonctionnement est le suivant : le seau à jetons est défini par sa profondeur, caractérisée par l argument normal burst size exprimée en octets, et par le nombre de jetons que le seau est susceptible de contenir en fonction de sa profondeur (le nombre de jetons est un multiple de 8 kbit/s) ; Arrivée des paquets Réserve de jetons (Taille b) Générateur de jetons r octets/s Paquets avec un jeton Figure 8 - Mécanisme du seau à jetons. il y aura autant de seaux à jetons distincts que de CAR spécifiés ; pour un CAR donné, un trafic est de type conform lorsqu il subsiste un nombre suffisant de jetons pour traiter l ensemble des datagrammes correspondant à ce trafic. Ce traitement est alors défini par la spécification d une conform action qui peut prendre 5 valeurs (transmettre, détruire, modifier la valeur des bits precedence du champ TOS de chaque datagramme puis transmettre, modifier la valeur des bits precedence du champ TOS de chaque datagramme puis associer ce trafic au CAR immédiatement consécutif), ou associer le trafic au CAR immédiatement consécutif (actions de type continue ). De la même façon, un trafic sera de type exceed lorsqu il n y aura plus suffisamment de jetons dans le seau associés au volume total du trafic. Ce trafic fera aussi l objet d un traitement défini par la spécification d une exceed action, dont les valeurs sont celles possibles pour les conform action ; la configuration d un CAR suppose la spécification systématique des actions de type conform et de type exceed ; enfin, un CAR peut être défini pour un trafic entrant, mais aussi pour un trafic sortant. Intégration et dimensionnement L intégration de RSVP et des mécanismes de gestion de files d attentes dans les routeurs fait l objet de mises en œuvres particulières suivant les constructeurs : cela rend difficile leur mise en œuvre dans des réseaux hétérogènes du fait notamment d interprétations différentes de la signification du champ TOS. De plus, les techniques de gestion de files d attentes permet de rendre des flux plus prioritaires que d autres, ce qui apporte des garanties statistiques de bande passante, mais en aucun cas de garantir de façon absolue un débit. Des calculs trop complexes pour être exposés ici montrent cependant que la garantie statistique de bande passante permet néanmoins de maintenir le délai de bout en bout entre deux limites sur une chaîne de routeurs RSVP et c est ce qui importe pour des services temps réel sur IP comme la téléphonie. Néanmoins le dimensionnement des réseaux capables de gérer la qualité de service reste problématique : en effet la nécessité de maintenir un état pour chaque flux et la complexité des mécanismes précédents ne permet de réaliser des réseaux RSVP que sur des intranets comportant quelques dizaines à quelques centaines de routeurs. En aucun cas il n est possible de mettre directement en œuvre ces solutions dans le 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 orientent donc vers des architectures de réseaux à plusieurs niveaux : des réseaux d accès et de concentration mettant en œuvre RSVP et des cœurs de réseau haut-débit agré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éseaux IP est loin d être négligeable (liaisons et routeurs) ce qui impacte sensiblement les scénarios de téléphonie sur IP économique. 48

19 Quelques éléments d analyse économique La technologie IP peut-elle dans le futur servir de base à l établissement de réseaux concurrents du bon vieux Réseau Téléphonique Commuté (RTC) 1? Avant de s intéresser aux réductions de coût de fourniture du service téléphonique que pourrait engendrer IP, rappelons qu il ne s agit pas réellement du même service. Par rapport à la très grande qualité du service téléphonique actuel, qualité auquel le consommateur est attaché, y a-t-il réellement place pour l ersatz 2 que représente IP? Il n y a pas bien sûr pas de réponse absolue à cette question et tout dépendra de l économie produite par l éventuel réseau IP. Pour examiner celle-ci, nous nous limiterons au mode non connecté. Nous ne nous intéresserons donc pas au compromis technique que repré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 causes relativement distinctes. En premier lieu, dans le réseau IP, la fonction d aiguillage des commutateurs est assurée par les routeurs. Or les commutateurs sont des machines extrêmement sophistiquées produites par des équipementiers dans un cadre peu concurrentiel pour des réseaux nationaux très spécifiques 3. Ils sont aussi plus performants en termes de temps de transfert que les routeurs, ce qui a évidemment un coût. Les routeurs sont au contraire des ordinateurs; ils bénéficient donc des énormes économies d échelle et de la forte concurrence régnant dans ce secteur 4. En second lieu, la compression du signal en 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 un facteur dix des capacités de transmission nécessaire. Il ne faudrait cependant pas en conclure que les coûts de transmission sont réduits d autant car les réseaux de transmission grâce à la fibre optique présentent d importantes économies d échelle. En poussant le raisonnement à l extrême, on pourrait même dire que si France Télécom décidait aujourd hui de passer demain à l IP, il n y aurait guère d économies à court terme puisque les fibres optiques du réseau de transmission suffisent largement à écouler le trafic prévisible, d autant que les infrastructures alternatives (SNCF) reprendront une partie de celui-ci. L économie la plus forte est évidemment réalisée dans le cadre d un réseau de micro-ordinateur à micro-ordinateur ( Net-To-Net ). Mais les contraintes sur l usage sont fortes alors que la tendance en téléphonie est plutôt au sans fil et à la mobilité. Plus gênant encore est l effet de parc. Un des atouts majeurs du réseau téléphonique est de pouvoir joindre l ensemble de la planète (au moins les citoyens des pays développés) ; les restrictions à cette communication universelle qu engendrent l absence de micros dans la majorité des foyers pour encore pas mal d années ainsi que l éventuelle incompatibilité des différents logiciels 5, nous semblent donc rédhibitoires (voir plus loin le cas des entreprises). Un réseau IP se greffant sur les lignes d abonnés et les terminaux téléphoniques déjà existants (réseau dit Phone-To-phone ) semble donc plus crédible ; mais il requiert des passerelles entre le réseau IP et les commutateurs d abonnés. Les économies sont alors bien moindres car le coût global de celles-ci est important 6. Dans ce dernier contexte, le service local n a pas de sens. Restent donc l interurbain, l international et la téléphonie d entreprise. Dans le premier domaine, comme les études économiques menées sur ce sujet au CNET l ont montré, la téléphonie sur IP ne fait pas une différence suffisamment sensible pour compenser ses inconvénients, en particulier parce que les coûts essentiels sont dans la boucle locale à laquelle le nouveau système n apporte rien puisque la ligne d abonné est dédiée à celui-ci 7. Ces coûts se refléteraient dans la charge d interconnexion que l opérateur IP aurait de toutes façons à payer à l opérateur de la boucle locale (France Télécom dans la plupart des cas). En international, le système tarifaire est complexe et les tarifs sont aujourd hui notoirement trop élevés par suite de l inertie 1. Qui évolue lui aussi. Le CNET réfléchit aujourd hui avec la BRX à la transition vers l ATM, qui pour beaucoup d experts est aussi le concept vers lequel converge Internet. De même, on peut envisager de comprimer le signal en transmission longue distance c est déja le cas en interurbain aux 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 le contexte concurrentiel actuel, il est clair de toutes façons que les potentialités de réduction des coûts qu offrent ces techniques seront plus intensément exploitées qu auparavant. Il est donc prévisible que les frontières entre les concepts 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 évoluer rapidement ; mais elle se reflète dans les coûts actuels du RTC. 4. Même si le marché des routeurs à proprement parler 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çais actuel, où la passerelle ne peut s interfacer directement sur le répartiteur. 7. On peut observer qu il en serait autrement dans d 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 Fiber Coaxial-). Dans ce dernier cas, évolution des réseaux câblés actuels, il peut être intéressant d économiser de la bande passante dans la partie de 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. 49

20 des mécanismes de compensation entre opérateurs (les taxes de répartition ). Il y a donc là réellement place pour l IP. Mais les réseaux traditionnels pourraient aussi réduire notablement leurs coûts en faisant une utilisation plus large de la compression. En outre, tout le système des taxes de répartition est en refonte rapide. Difficile dans ces conditions pour un entrant de construire un business-plan bien étayé. Enfin, en entreprise, le concept Net-To-Net reprend de la valeur puisque l effet de parc 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-ordinateur bureautisé. 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 en entreprise et compense en partie ses défauts déjà évoqués 8. Enfin, le réseau IP de téléphonie ne servira que lors des heures chargées de la journée ; il pourrait donc basculer le soir ou lors de la pause méridienne vers d autres applications (sauvegarde ; transferts de données en temps différé ; téléchargements d applications utilisables le lendemain). L étude de cas concrets de réseaux d entreprises montre cependant que la solution 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 entreprise n est pas trop saisonnier. Sinon le réseau dimensionné pour les mois les plus forts sera sous-utilisé la plupart du temps. Le remède est alors à chercher dans l intégration de services avec un réseau Intranet voix-données en protocole RSVP afin 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éseau d 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-être dans le contexte de pays émergents. Conclusion S il reste sans doute un marché de niche de type Friends and Family pour des communications vocales internationales de basse qualité sur Internet, les véritables opportunités économiques devraient se situer au niveau des réseaux intranets (i.e. sous le contrôle complet d un opérateur) par la mutualisation de la voix et des données sur ce même réseau. Mais à plus long-terme, lorsque les usages auront complètement banalisé l utilisation du PC multimédia pour les applications de données, c est surtout vers l intégration de services (e.g. travail collaboratif, commerce électronique) et l intelligence de ces services que devrait s orienter le marché des applications temps réel sur réseaux IP. Il reste que l acceptabilité de ces nouveaux services, leur coût de mise en œuvre sur des infrastructures encore assez 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 le terrain tels que ceux qui ont été présentés au chapitre consacré à Quels services pour un opérateur : c est le but que se fixe France Télécom pour 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 par impulsion et codage (MIC) où le signal et échantillonné puis l amplitude quantifiées suivant des standards de compression non linéaire (loi A ou µ) : c est le codage RNIS/RTC à 64 kbits/s selon la Recommandation G.711 de l UIT. Les codeurs de type ADPCM (Adaptive Differential Pulse Code Modulation où l on tire parti des propriétés de corrélation de la voix en codant les échantillons de manière différentielle avec une composante estimée par extrapolation des valeurs intervenues précédemment) ou SB-ADPCM (Sub Band ADPCM où la source est découpée en sous-bandes codées chacune séparément) sont des codeurs de parole à plus bas débit comme le MICDA à 32 kbit/s (Rec. G.726 ou 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 vite quand 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 de parole à la source, et de les transmettre sous forme numérique au récepteur qui se charge de reconstituer un signal proche du signal initial. Cette technique ne conserve pas la forme temporelle du signal mais préserve le spectre à court terme reproduit à l arrivée grâce à un circuit d excitation et un filtre prenant en compte les paramètres en question. 8. Ne peut-on envisager que les deux modes de téléphonie coexistent comme aujourd hui le courrier, le fax et la messagerie? 50