Téléphonie IP avec TAPI 3.0 (système d'exploitation Windows)

Sur cette page

Téléphonie IP avec TAPI 3.0
Résumé
Téléphonie IP
Présentation de l'interface TAPI 3.0
Pour effectuer un appel, procédez comme suit 
Pour répondre à un appel, procédez comme suit 
Téléphonie IP avec TAPI 3.0 (système d'exploitation Windows) - 2è partie
Téléphonie IP avec TAPI 3.0 (système d'exploitation Windows)- 3è partie

Téléphonie IP avec TAPI 3.0

Système d'exploitation Windows
Livre blanc

Résumé

TAPI 3.0 est une API évolutive qui permet la convergence de la téléphonie RTPC traditionnelle et de la téléphonie IP. Avec la téléphonie IP, qui réunit des technologies naissantes, il est désormais possible de collaborer, tant avec la voix qu'avec la vidéo ou les données, sur des réseaux locaux (LAN) et étendus (WAN) existants, ainsi que sur Internet. TAPI 3.0 active la téléphonie IP sur les systèmes d'exploitation Microsoft® Windows® en offrant des méthodes simples et génériques pour effectuer des connexions entre plusieurs ordinateurs, et accéder à n'importe quel flux média impliqué dans la connexion.

TAPI 3.0 prend en charge les protocoles de conférence standard H.323 et IP Multicast (multidiffusion IP). Cette interface utilise le service Active Directory du système d'exploitation Windows 2000 pour simplifier le déploiement au sein de l'entreprise. Elle intègre en outre un support QoS (qualité de service) pour améliorer la qualité des conférences et la souplesse de gestion du réseau.

Téléphonie IP

La téléphonie IP regroupe de nouvelles technologies qui permettent de collaborer, aussi bien avec la voix qu'avec la vidéo ou les données, sur des réseaux locaux (LAN) et étendus (WAN) IP existants, ainsi que sur Internet.

Plus précisément, la téléphonie IP utilise les standards IETF et UIT pour transporter des données multimédia sur n'importe quel réseau compatible IP, offrant ainsi aux utilisateurs une souplesse extrême, tant au niveau du support (lignes téléphoniques traditionnelles, ADSL, RNIS, lignes spécialisées, câble coaxial, satellite, paires torsadées…) que de l'emplacement physique. En conséquence, les réseaux utilisés actuellement pour le Web, le courrier électronique et les données peuvent servir à interconnecter les utilisateurs, les entreprises, les écoles et les gouvernements du monde entier.

TAPI 3.0 est une API évolutive qui permet la convergence de la téléphonie RTPC traditionnelle et de la téléphonie sur des réseaux IP.

La téléphonie IP permet aux entreprises et aux particuliers de réduire les coûts associés aux services existants, tels que la voix et la vidéo diffusée, tout en élargissant leur panoplie de moyens de communication en vue d'y inclure des outils de vidéoconférence, de partage d'applications et de tableau blanc.

Par le passé, les entreprises ont mis en place des réseaux distincts pour traiter le trafic vocal, les données et la vidéo, chacun présentant des exigences différentes au niveau du transport. Au final, ces réseaux se sont révélés extrêmement onéreux, tant sur le plan de l'installation que de la maintenance ou encore de la reconfiguration. De plus, ces réseaux étant physiquement indépendants, l'intégration était difficile, voire impossible, limitant par là-même leur utilité potentielle.

La téléphonie IP consacre la fusion de la voix, de la vidéo et des données en spécifiant un mode de transport commun. Les trois réseaux se fondent littéralement en un seul, architecturé autour de la technologie IP. Cela se traduit par une souplesse de gestion accrue, une diminution des coûts de support, une nouvelle génération d'outils de collaboration et une productivité accrue.

Les applications possibles de la téléphonie IP sont légion : télétravail, collaboration en temps réel sur des documents, télé-apprentissage, formation des employés, vidéoconférence, messagerie vidéo ou encore vidéo à la demande.

Figure 1 Convergence des médias : voix, données et vidéo

Présentation de l'interface TAPI 3.0

À mesure que la téléphonie et la commande d'appel se généralisent dans le monde de l'informatique personnelle, une interface de téléphonie générique s'avère nécessaire pour permettre aux applications d'accéder à l'ensemble des options de téléphonie disponibles sur tout ordinateur. Les médias ou données d'un appel doivent également être accessibles aux applications, et ce, d'une manière standardisée.

L'interface TAPI 3.0 offre des méthodes simples et génériques pour effectuer des connexions entre deux ordinateurs ou plus, et accéder à n'importe quel flux média impliqué dans la connexion. Elle résume la fonctionnalité de commande d'appel afin de permettre à des protocoles de communication différents, en apparence incompatibles, de présenter une interface commune aux applications.

La téléphonie IP est sur le point de connaître une croissance explosive, étant donné que les entreprises ont entamé la migration de leurs réseaux téléphoniques par commutation de circuits, onéreux et rigides, vers des réseaux IP intelligents, souples et bon marché. Microsoft a anticipé cette migration en créant une infrastructure de téléphonie informatique robuste. TAPI, c'est son nom, en est aujourd'hui à sa troisième version majeure. Cette infrastructure est parfaitement adaptée au développement rapide et aisé d'applications de téléphonie IP.

Figure 2 Convergence de la téléphonie IP et RTPC

TAPI 3.0 intègre le contrôle des flux multimédia dans la téléphonie classique. Cette version se veut en outre une évolution de l'API TAPI 2.1 vers le modèle COM, permettant ainsi d'écrire des applications TAPI dans n'importe quel langage, tel que C/C++ ou encore Microsoft® Visual Basic®.

Outre la compatibilité avec les opérateurs téléphoniques classiques, l'infrastructure TAPI 3.0 prend en charge la conférence H.323 standard et la conférence IP Multicast. TAPI 3.0 utilise le service Active Directory de Windows® 2000 afin de simplifier le déploiement au sein de l'entreprise. Elle intègre en outre un support QoS (qualité de service) pour améliorer la qualité des conférences et la souplesse de gestion du réseau.

Figure 3 Architecture TAPI

L'interface TAPI 3.0 est constituée de quatre composants majeurs :

• API COM TAPI 3.0

• Serveur TAPI

• Fournisseurs de services téléphoniques

• Fournisseurs de flux multimédia

Contrairement à TAPI 2.1, l'API TAPI 3.0 est implémentée sous la forme d'une suite d'objets COM. La migration de l'interface TAPI vers le modèle COM permet la mise à niveau matérielle de fonctionnalités TAPI. Cela permet en outre aux développeurs d'écrire des applications compatibles TAPI dans n'importe quel langage.

Le processus serveur TAPI (TAPISRV.EXE) extrait l'interface TSPI (TAPI Service Provider Interface) de TAPI 3.0 et TAPI 2.1, ce qui permet d'utiliser les fournisseurs de services téléphoniques TAPI 2.1 avec TAPI 3.0 tout en préservant l'état interne de TAPI.

Les fournisseurs de services téléphoniques (TSP) sont chargés de la résolution du modèle d'appel indépendant du protocole de TAPI dans les mécanismes de contrôle d'appel spécifique à un protocole. TAPI 3.0 offre une compatibilité ascendante avec les TSP TAPI 2.1. Par défaut, TAPI 3.0 est livré avec deux fournisseurs de services téléphoniques IP (et les MSP qui y sont associés) : le TSP H.323 et le TSP de conférence IP Multicast, lesquels sont décrits plus en détail ci-après.

TAPI 3.0 offre une méthode uniforme d'accès aux flux multimédia d'un appel, ce qui assure la prise en charge de l'API DirectShow™ comme gestionnaire principal de flux multimédia. Les fournisseurs de flux multimédia (MSP) TAPI implémentent les interfaces DirectShow pour un TSP déterminé. Leur présence est requise pour tout service de téléphonie faisant usage de la diffusion DirectShow. Les flux génériques sont traités par l'application.

Figure 4 Relations d'objets TAPI 3.0

L'API TAPI 3.0 est constituée de cinq objets :

• TAPI

• Address

• Terminal

• Call

• CallHub

L'objet TAPI **est le point d'entrée de l'application dans TAPI 3.0. Cet objet représente toutes les ressources téléphoniques auxquelles l'ordinateur local a accès. Il permet à une application d'énumérer toutes les adresses locales et distantes.

Un objet Address représente le point d'origine ou de destination d'un appel. Les fonctionnalités d'adressage, telles que la prise en charge du terminal ou du support, peuvent être récupérées à partir de cet objet. Une application peut attendre un appel d'objet Address ou créer un objet d'appel sortant à partir d'un objet Address.

Un objet Terminal représente le récepteur, ou convertisseur, situé au niveau du point d'origine ou de destination d'une connexion. L'objet Terminal peut pointer vers du matériel utilisé pour interagir avec l'utilisateur, tel qu'un téléphone ou un microphone. Il peut également s'agir d'un fichier ou de tout autre dispositif capable d'accepter une entrée ou de créer une sortie.

L'objet Call représente la connexion entre l'adresse locale et une ou plusieurs autres adresses (cette connexion peut être établie directement ou par le biais d'un CallHub). On peut concevoir cet objet comme étant la vue d'un appel téléphonique par le premier abonné. Le contrôle d'appel s'effectue intégralement par l'intermédiaire de l'objet Call. Il existe un objet Call pour chaque membre d'un CallHub.

L'objet CallHub représente un ensemble d'appels connexes. Ce type d'objet peut être créé directement par une application ; sa création est indirecte lors de la réception d'un appel par le biais de TAPI 3.0. L'utilisation d'un objet CallHub permet à un utilisateur de recenser les autres personnes ayant pris part à l'appel ou à la conférence et, éventuellement (en raison du caractère indépendant de l'emplacement du modèle COM), d'effectuer un contrôle d'appel sur les objets Call distants associés à ces utilisateurs, moyennant cependant certaines autorisations :

Figure 5 Relations des objets Call et CallHub

Pour effectuer un appel, procédez comme suit 

1. Créez et initialisez un objet TAPI.

2. Utilisez l'objet TAPI pour recenser tous les objets Address disponibles sur un ordinateur (cartes réseau, modems et lignes RNIS, par exemple).

3. Énumérez tous les types d'adresse pris en charge pour chaque objet Address (numéro de téléphone, adresse IP, etc.).

4. Sélectionnez un type d'objet en vous basant sur les requêtes de prise en charge des types d'adresse et de support (audio, vidéo, etc.) appropriés.

5. Utilisez la méthode CreateCall de l'objet Address pour créer un objet Call associé à une adresse déterminée.

6. Sélectionnez les terminaux appropriés sur l'objet Call.

7. Appelez la méthode Connect de l'objet Call pour établir l'appel.

Pour répondre à un appel, procédez comme suit 

1. Créez et initialisez un objet TAPI.

2. Utilisez l'objet TAPI pour recenser tous les objets Address disponibles sur un ordinateur (cartes réseau, modems et lignes RNIS, par exemple).

3. Énumérez tous les types d'adresse pris en charge pour chaque objet Address (numéro de téléphone, adresse IP, etc.).

4. Sélectionnez un type d'objet en vous basant sur les requêtes de prise en charge des types d'adresse et de support (audio, vidéo, etc.) appropriés.

5. Enregistrez un intérêt dans les types de support spécifiques avec l'objet Address approprié.

6. Enregistrez un gestionnaire d'appels (ce qui revient à implémenter une interface ITCallNotification) avec l'objet Address.

7. TAPI informe l'application d'un nouvel appel par le biais de l'interface ITCallNotification et crée un objet Call.

8. Sélectionnez les terminaux appropriés sur l'objet Call.

9. Appelez la méthode Connect de l'objet Call pour établir l'appel.

10. Appelez la méthode Answer de l'objet Call pour répondre à l'appel.

Le système d'exploitation Windows® met à votre disposition DirectShow, une infrastructure extensible permettant de contrôler et de manipuler efficacement du contenu multimédia diffusé en continu. Par l'intermédiaire de ses interfaces COM apparentes, DirectShow assure à TAPI 3.0 un contrôle unifié des flux.

DirectShow est architecturé autour d'un système modulaire de composants enfichables appelés "filtres". Ces filtres sont disposés dans une configuration que l'on nomme "graphique de filtre". Le gestionnaire du graphique de filtre est un composant chargé de superviser la connexion de ces filtres et de contrôler le débit de données du flux. Les fonctionnalités de chaque filtre sont décrites par un certain nombre d'interfaces COM spéciales appelées "broches". Chaque instance de broche peut utiliser ou générer des données de diffusion en continu, telles que du son numérique.

Alors que les objets COM sont généralement présentés dans des programmes en mode utilisateur, l'architecture de diffusion de DirectShow intègre une extension vers le modèle de gestionnaire de Windows ; extension qui permet la connexion directe des flux multimédia au niveau du gestionnaire de périphérique. La Figure 6 ci-dessous illustre une passerelle RTPC-IP simple : un flux vocal de 64 Kbits/s en provenance d'une ligne RNIS est compressé en un flux audio G.723, puis transmis à un gestionnaire de charge RTP en vue d'être envoyé sur le réseau.

Figure 6 Exemple de graphique de filtre DirectShow
avec composants en mode noyau et utilisateur

Ces extensions de diffusion performantes au modèle de gestionnaire de Windows évitent les transitions de mode utilisateur/noyau. Elles permettent en outre un acheminement efficace des flux de données entre les différents composants matériels au niveau du gestionnaire de périphérique. Chaque filtre de mode noyau est mis en miroir par un proxy correspondant en mode utilisateur, lequel simplifie l'établissement de la connexion et peut être utilisé pour contrôler les fonctionnalités spécifiques au matériel.

Les filtres réseau de DirectShow étendent l'architecture de diffusion aux ordinateurs connectés sur un réseau IP. Conçu pour le transport de données en temps réel sur des réseaux sans connexion, le protocole RTP (Real-time Transport Protocol) transporte les flux multimédia TAPI et fournit les données d'horodateur appropriées. TAPI 3.0 s'accompagne d'un filtre réseau RTP en mode noyau.

TAPI 3.0 utilise cette technologie afin de présenter une méthode d'accès unifiée pour les flux dans le cadre des appels multimédia. Les applications peuvent router ces flux en manipulant les graphiques de filtre correspondants. Il leur est en outre possible de se connecter aisément à des flux provenant de plusieurs appels, en vue d'offrir des fonctionnalités de conférence et de pontage.

Téléphonie IP avec TAPI 3.0 (système d'exploitation Windows) - 2è partie

Transmissions H.323 dans l'infrastructure TAPI 3.0
Conférence IP Multicast dans TAPI 3.0

Transmissions H.323 dans l'infrastructure TAPI 3.0

H.323 est une norme du l'Union internationale des télécommunications (UIT) portant sur les transmissions de contenu multimédia (voix, vidéo et données) sur des réseaux sans connexion n'offrant pas une qualité de service garantie, tels que les réseaux IP et Internet. Cette norme porte sur le contrôle d'appel, la gestion multimédia et la gestion de bande passante dans le cadre des conférences point à point et multipoint. La norme H.323 implique la prise en charge des codecs audio et vidéo standard. Elle assure en outre le support du partage de données via la norme T.120. La norme H.323 se distingue aussi par son indépendance, tant vis-à-vis des réseaux que des plates-formes ou des applications, ce qui permet donc à n'importe quel terminal compatible H.323 d'interopérer avec d'autres terminaux.

Figure 7 Architecture H.323

La norme H.323 permet la diffusion du contenu multimédia sur les réseaux à commutation de paquets existants. Pour pallier les effets de latence LAN, la norme H.323 utilise, comme moyen de transport, le protocole RTP (Real-time Transport Protocol), une norme de l'IETF conçue pour satisfaire aux exigences en matière de diffusion de contenu audio et vidéo en temps réel sur Internet.

La norme H.323 spécifie trois protocoles de commande et de contrôle :

• H.245 pour le contrôle des appels
• Q.931 pour la signalisation des appels
• La fonction de signalisation RAS (Enregistrement, Admissions et Statut)

Le canal de commande H.245 est responsable du contrôle des messages régissant le fonctionnement du terminal H.323, y compris les indications, les commandes et les échanges de capacités. Q.931 est utilisé pour établir une connexion entre deux terminaux, tandis que RAS régit les fonctions d'enregistrement, d'admission et de bande passante entre les points de terminaison et les opérateurs de contrôle d'appels (RAS n'est pas utilisé en l'absence d'opérateur de contrôle d'appels). Vous trouverez, plus loin dans ce chapitre, davantage d'informations sur les opérateurs de contrôle d'appels.

La norme H.323 définit quatre composants majeurs d'un système de communication à architecture H.323 :

• Terminaux
• Passerelles
• Opérateurs de contrôle d'appels
• Unités de contrôle multipoint (MCU)

Les terminaux sont les extrémités clientes sur le réseau. Tous les terminaux doivent prendre en charge les communications vocales ; la prise en charge des données et de la vidéo est optionnelle.

Une passerelle est un élément facultatif dans le cadre d'une conférence H.323. Les passerelles connectent les conférences H.323 à d'autres réseaux, protocoles de communication et formats multimédia. L'utilisation de passerelles n'est pas requise en l'absence de connexion vers d'autres réseaux ou terminaux non compatibles H.323.

Les opérateurs de contrôle d'appels remplissent deux fonctions importantes, qui permettent de préserver la robustesse du réseau : conversion d'adresses et gestion de la bande passante. Ces opérateurs établissent la correspondance entre les pseudonymes LAN et les adresses IP. Ils fournissent également des déterminations d'adresse lorsque cela s'avère nécessaire. Les opérateurs de contrôle d'appels exécutent en outre des fonctions de contrôle des appels afin de limiter le nombre de connexions H.323, ainsi que la bande passante totale utilisée par ces connexions, dans une zone H.323. La présence de ce type d'opérateur n'est pas requise au sein d'un système H.323. Cependant, s'il est présent, les terminaux doivent faire usage de ses services.

Figure 8 Composants de l'architecture H.323

Les unités de contrôle multipoint (MCU) prennent en charge les conférences entre deux points de terminaison, voire davantage. Une MCU est constituée d'un contrôleur multipoint (MC), composant obligatoire, et éventuellement de processeurs multipoint (MP). Le contrôleur multipoint se charge des négociations H.245 entre tous les terminaux afin de déterminer les fonctionnalités de traitement audio et vidéo communes. Le processeur multipoint, quant à lui, achemine les flux audio, vidéo et données entre les extrémités du terminal.

La prise en charge des normes suivantes est garantie pour tous les clients H.323 : H.261 et G.711. H.261 est un codec vidéo standard de l'UIT conçu pour transmettre du contenu vidéo compressé à une vitesse de 64 Kbits/s et une résolution de 176x44 pixels (QCIF). G.711 est un codec audio standard de l'UIT conçu pour transmettre du contenu audio MIC A-law et µ-law à des vitesses de 48, 56 et 64 Kbits/s.

Un client H.323 peut éventuellement prendre en charge des codecs supplémentaires : H.263 et G.723. H.263 est un codec vidéo standard de l'UIT basé sur la norme H.261 et compatible avec celle-ci. Elle offre une compression accrue par rapport à la norme H.261 et transmet du contenu vidéo à une résolution de 176 x 44 pixels (QCIF). G.723 est un codec audio standard de l'UIT conçu pour fonctionner à très faible débit.

Le fournisseur de service téléphonique H.323 (et le fournisseur de flux multimédia qui y est associé) permet aux applications compatibles TAPI d'établir des sessions multimédia avec tout terminal H.323 connecté au réseau local.

Le fournisseur de service téléphonique (TSP) H.323 implémente notamment la pile de signalisation H.323. Le TSP accepte un grand nombre de formats d'adressage, y compris des noms, noms d'ordinateur ou encore adresses électroniques.

Le MSP H.323 est, lui, responsable du développement du graphique de filtre DirectShow pour une connexion H.323 (y compris les filtres du convertisseur, récepteur, codec, gestionnaire de charge RTP et RTP).

Figure 9 Architecture TSP H.323

La téléphonie H.323 est rendue complexe en raison de l'extrême volatilité de l'adresse réseau de l'utilisateur (dans ce cas, l'adresse IP). Cette adresse change en effet d'une session H.323 à une autre. Le TSP TAPI H.323 utilise les services Active Directory de Windows 2000 pour effectuer une conversion d'adresses utilisateur-IP. Les informations de correspondance utilisateur-IP sont stockées et actualisées en permanence à l'aide de l'annuaire dynamique Internet Locator Service (ILS), un composant serveur en temps réel d'Active Directory.

Le scénario suivant illustre la résolution d'adresses IP dans le TSP H.323 :

1. Jean souhaite établir une conférence H.323 avec Alice, une autre utilisatrice du réseau local. Dès que l'application de vidéoconférence d'Alice a créé un objet Address et placé celui-ci en mode d'écoute, son adresse IP est ajoutée dans le service Active Directory de Windows 2000 par le TSP H.323. Ces informations ont une durée de vie déterminée (TTL, Time to Live) et sont actualisées régulièrement au moyen du protocole LDAP (Lightweight Directory Access Protocol) :

   

   Figure 10 Alice enregistre et actualise son adresse IP

2. Le TSP H.323 de Jean interroge ensuite le serveur ILS Dynamic Directory pour connaître l'adresse IP d'Alice. Jean lance une requête sur tous les objets RTPerson de l'annuaire associés à Alice :

   

   Figure 11 Jean lance une recherche sur l'adresse IP d'Alice

3. Une fois en possession de l'adresse IP actualisée d'Alice, Jean lance un appel H.323 vers l'ordinateur d'Alice. Il s'ensuit une sélection du média et une session de négociations H.323 entre les TSP analogues sur les deux ordinateurs. Aussitôt la négociation terminée, les deux MPS H.323 élaborent les graphiques de filtre DirectShow appropriés. Tous les flux multimédia sont transmis à DirectShow qui s'en voit confier le traitement. La conférence peut alors commencer.

   

   Figure 12 Une fois la négociation des capacités terminée, la conférence peut commencer.

Haut de page

Conférence IP Multicast dans TAPI 3.0

IP Multicast est une extension du protocole IP qui assure une communication de groupe efficace. IP Multicast est né de la nécessité de disposer d'une solution de conférence légère et évolutive capable de résoudre les problèmes liés au trafic en temps réel sur un réseau de type Best-Effort, en mode Datagram. La technologie IP Multicast offre de nombreux avantages : évolutivité, tolérance d'erreurs, robustesse et simplicité de configuration.

Le modèle de conférence IP Multicast présente les caractéristiques suivantes :

• Aucune coordination globale n'est nécessaire pour ajouter et supprimer des membres d'une conférence.

• Pour atteindre un groupe de multidiffusion (multicast), l'utilisateur envoie les données à une seule adresse IP de multidiffusion. Aucune information n'est requise sur les autres utilisateurs du groupe.

• Pour recevoir des données, les utilisateurs marquent leur intérêt dans une adresse IP de multidiffusion donnée avec un routeur compatible Multicast. Aucune information n'est requise sur les autres utilisateurs du groupe.

• Grâce aux routeurs, les informations d'implémentation multicast sont transparentes pour l'utilisateur.

  La conférence traditionnelle en mode connexion présente un certain nombre d'inconvénients :

  • Complexité pour les utilisateurs : Les utilisateurs doivent connaître l'emplacement de chaque utilisateur avec lequel ils souhaitent converser, ce qui limite l'évolutivité et la tolérance aux pannes. De plus, les utilisateurs éprouveront plus de difficultés pour prendre part ou se retirer d'une conférence.

  • Gaspillage de bande passante : Un utilisateur désireux de transmettre des données à n utilisateurs doit envoyer lesdites données à travers n connexions, comme le montre l'illustration suivante :

Figure 13 Topologie du réseau : perspective de l'émetteur

La bande passante totale requise pour des conférences où chaque participant envoie des données peut correspondre au carré du nombre de participants, entraînant de ce fait de sérieux problèmes d'évolutivité. La technologie IP Multicast exploite la topologie réseau réelle afin d'éliminer la transmission de données redondantes sur les mêmes lignes de communication.

Figure 14 Topologie réseau réelle

IP Multicast implémente un modèle de communication léger basé sur les sessions. Ce modèle se montre très peu contraignant pour les utilisateurs qui participent à la conférence. Avec cette technologie, les utilisateurs n'envoient qu'une seule copie de leurs informations à une adresse IP de groupe qui parvient à tous les destinataires. De par sa conception, IP Multicast évolue sans peine à mesure que le nombre de participants augmente ; concrètement, cela signifie que l'ajout d'un utilisateur n'occasionne pas l'ajout d'une quantité de bande passante correspondante. La technique de multidiffusion entraîne en outre une diminution considérable de la charge au niveau du serveur émetteur.

IP Multicast route efficacement ces flux de données de type un à plusieurs en construisant un arbre maximal dans lequel un seul chemin relie deux routeurs. La copie du flux s'opère uniquement si les chemins bifurquent :

Figure 15 Multidiffusion IP à l'aide d'un arbre maximal

En l'absence de multidiffusion, les mêmes informations doivent soit être transportées à plusieurs reprises sur le réseau, une fois pour chaque destinataire, soit être transmises à tous les utilisateurs du réseau, entraînant par là même un traitement excessif et une consommation superflue de la bande passante.

La multidiffusion IP utilise des adresses IP de Classe D pour spécifier les groupes hôte de multidiffusion ; cette plage d'adresses s'étend de 224.0.0.0 à 239.255.255.255. Les adresses de groupe temporaires et permanentes sont, toutes deux, prises en charge. Les adresses permanentes sont attribuées par l'IANA (Internet Assigned Numbers Authority). Elles comprennent 224.0.0.1, le groupe de tous les hôtes utilisé pour tous les hôtes de multidiffusion sur le réseau local, et 224.0.0.2, une adresse qui porte sur tous les routeurs du réseau. La plage d'adresses 224.0.0.0 - 224.0.0.255 est réservée aux protocoles de routage et à d'autres protocoles réseau de niveau inférieur. Les autres adresses et plages ont été réservées pour des applications. C'est le cas de la plage 224.0.13.000 à 224.0.13.255 qui a été réservée pour Net News (pour plus d'informations à ce sujet, consultez la RFC 1700, "Assigned Numbers" à l'adresse ftp://ftp.internic.net/rfc/rfc1700.txt).

Dans le cas de la multidiffusion IP, le protocole de transport se nomme RTP (Real-time Transport Protocol). Il fournit un en-tête multimédia standard comprenant des informations temporelles, une numérotation de séquences et des informations sur le format de charge.

Parmi les applications de la multidiffusion IP, citons l'audioconférence et la vidéoconférence, la réplication de sites Web et de bases de données, le télé-apprentissage, la diffusion de cotations boursières et l'informatique coopérative. Pour l'heure, le MBONE Internet (dorsale de multidiffusion) constitue la meilleure illustration des possibilités de la multidiffusion IP.

MBONE est un réseau de multidiffusion mondial expérimental placé par-dessus le réseau Internet physique. Il existe depuis environ cinq ans. Il sert actuellement à transmettre les réunions de l'IETF, les lancements des navettes spatiales de la NASA, de la musique, des concerts, ainsi que bien d'autres événements et manifestations en direct (pour plus d'informations à ce sujet, rendez-vous sur le site MBONE  .

Le TSP de conférence IP Multicast s'attelle principalement à résoudre les noms de conférence en adresses de multidiffusion IP. Pour ce faire, il a recours aux descripteurs de conférence SDP (Session Description Protocol) stockés dans le serveur de conférence Dynamic Directory ILS. Il est assisté par les commandes de conférence Rendezvous décrites ci-après.

Le MSP de conférence IP Multicast est responsable du développement d'un graphique de filtre DirectShow adapté à une connexion IP Multicast (y compris les filtres du convertisseur, récepteur, codec, gestionnaire de charge RTP et RTP).

Figure 16 Architecture de la conférence IP Multicast (multidiffusion)

TAPI 3.0 utilise le protocole de description de sessions standard de l'IETF pour annoncer des conférences IP Multicast au niveau de l'entreprise. Les descripteurs SDP sont stockés dans l'Active Directory de Windows 2000 (plus précisément, le serveur de conférence Dynamic Directory ILS). Ces descripteurs feront l'objet d'une description détaillée plus loin dans ce chapitre. Contrairement aux serveurs Dynamic Directory utilisés par le TSP H.323, il n'existe qu'un seul serveur de conférence ILS par entreprise. Cela s'explique par le fait que les annonces ne sont pas actualisées en permanence, d'où une faible consommation de la bande passante.

Le mécanisme de conférence IP Multicast de TAPI 3.0 est illustré dans le scénario suivant, où Jean souhaite lancer une conférence multidiffusion.

1. L'application compatible TAPI 3.0 utilisée par Jean a recours aux commandes Rendezvous (expliquées en détail plus loin dans ce chapitre) pour créer un descripteur de session SDP sur le serveur de conférence ILS. Le descripteur SDP contient, notamment, le nom de la conférence, les heures de début et de fin, l'adresse de multidiffusion IP de la conférence et les types de média utilisés pour cette conférence.

   

   Figure 17 Jean ajoute un descripteur de session SDP

2. Jacques interroge le serveur de conférence ILS afin de connaître les descripteurs SDP des conférences qui répondent à ses critères :

   

   Figure 18 Jacques interroge le serveur de conférence ILS

3. Marie et Alice exécutent des requêtes semblables et, sur la base des informations SDP reçues, décident de prendre part ou non à la conférence de Jean. Une fois en possession de l'adresse IP de multidiffusion de la conférence, elles rejoignent le groupe hôte de multidiffusion :

   

   Figure 19 Marie et Alice se joignent à la conférence

Les commandes Rendezvous sont des composants COM qui résument le concept d'annuaire de conférence. Elles offrent le mécanisme approprié pour annoncer de nouvelles conférences multidiffusion et détecter des conférences existantes. Elles fournissent un schéma commun (SDP) pour l'annonce de conférences, des interfaces définies par script, ainsi que des fonctions d'authentification, de cryptage et de contrôle d'accès.

Figure 20 Participation à une conférence à l'aide des commandes Rendezvous

Les commandes Rendezvous permettent à l'utilisateur d'ajouter, de supprimer et de recenser les conférences multidiffusion stockées sur un serveur de conférence ILS. Ces commandes manipulent les données de conférence par l'intermédiaire du protocole LDAP (Lightweight Directory Access Protocol).

La Figure 20 ci-dessus illustre la participation à une conférence. L'application de conférence utilise les commandes Rendezvous afin d'obtenir des descripteurs de session pour les conférences qui répondent aux critères de l'utilisateur (1,2). Les listes de contrôle d'accès (ACL) protègent chaque annonce de conférence stockée. La visibilité des annonces et leur accès dépendent des informations d'identification de l'utilisateur.

Dès qu'un utilisateur a choisi une conférence (3), son application recherche tous les objets Address prenant en charge le type d'adresse Nom de conférence multidiffusion. L'application utilise ensuite le nom de la conférence issu du descripteur SDP comme paramètre de la méthode CreateCall de l'objet Address approprié (4), transmet les objets Terminal appropriés à l'objet Call retourné et appelle Call->Connect.

Les commandes Rendezvous stockent les informations de conférence sur un serveur de conférence ILS dans un format défini par le protocole SDP (un standard IETF conçu pour l'annonce des conférences multimédia). L'objectif du protocole SDP est de divulguer suffisamment d'informations sur une conférence (heure, média et emplacement) pour permettre aux utilisateurs éventuels d'y prendre part. Conçu initialement pour s'exécuter sur le MBONE Internet (dorsale de multidiffusion IP), le protocole SDP a été intégré à l'Active Directory de Windows 2000 par TAPI 3.0, étendant ainsi ses fonctionnalités aux réseaux locaux.

Un descripteur SDP divulgue les informations suivantes sur une conférence :

Figure 21 Attributs SDP génériques

Une description de session est constituée de trois éléments : une Description de session unique, 0 ou plusieurs Descriptions temporelles et 0 ou plusieurs Descriptions de média. La Description de session contient des attributs généraux qui s'appliquent à l'ensemble de la conférence ou des flux multimédia. Les Descriptions temporelles contiennent des informations sur l'heure de début, de fin et de répétition de la conférence. Les Descriptions de média, pour leur part, contiennent des informations propres à un flux multimédia spécifique.

Alors que, sur le réseau MBONE, l'annonce des conférences IP Multicast traditionnelles s'effectuait à l'aide d'un modèle push basé sur le protocole SAP (Session Announcement Protocol), TAPI 3.0 a recours à une méthode de type pull axée sur les services Active Directory de Windows 2000. Cette approche offre de nombreux avantages, dont une préservation de la bande passante et une grande souplesse d'administration. Pour plus d'informations à ce sujet, consultez la section traitant de l'intégration avec les services Active Directory de Windows 2000.

Le système de sécurisation des conférences de TAPI 3.0 répond aux besoins suivants :

• Contrôler les utilisateurs habilités à créer, supprimer et visualiser des annonces de conférence.

• Empêcher toute écoute clandestine d'une conférence.

TAPI 3.0 utilise les fonctions de sécurité du protocole LDAP et des services Active Directory de Windows 2000 afin de sécuriser les conférences sur des réseaux non sécurisés, tels qu'Internet. Chaque objet de l'Active Directory peut être associé à une liste de contrôle d'accès (ACL) spécifiant les droits d'accès aux objets sur la base d'un utilisateur ou d'un groupe. L'association de listes ACL et de descripteurs de conférence SDP permet aux organisateurs de conférences de spécifier les utilisateurs habilités à énumérer et à visualiser les annonces de conférence. L'authentification des utilisateurs est assurée par le sous-système de sécurité de Windows 2000.

Figure 22 SDP et ACL

Les descripteurs de session sont transmis, sous forme cryptée et sur LDAP, entre le serveur de conférence ILS et l'utilisateur. Cette transmission s'opère sur une connexion SSL (Secure Sockets Layer), assurant ainsi au SDP une protection totale contre les "espions" :

Figure 23 Distribution du SDP

La multidiffusion IP ne prévoit aucune authentification des utilisateurs ; ainsi, tout utilisateur peut, sous couvert de l'anonymat, se joindre à un groupe hôte de multidiffusion. Pour préserver la confidentialité d'une conférence IP Multicast, TAPI 3.0 autorise son cryptage, la clé de chiffrement étant distribuée depuis l'intérieur même du descripteur de conférence. Seuls les utilisateurs disposant des autorisations nécessaires ont accès au descripteur SDP de la conférence et, partant, à la clé de cryptage de multidiffusion. Après avoir récupéré sa clé de cryptage, l'utilisateur authentifié peut prendre part à la conférence.

Figure 24 Flux de multidiffusion crypté

Haut de page

Téléphonie IP avec TAPI 3.0 (système d'exploitation Windows)- 3è partie

Qualité de service
Déploiement en entreprise de l'infrastructure de téléphonie IP TAPI 3.0
TAPI 3.0 et NetMeeting 2.0

Qualité de service

Contrairement au trafic de données traditionnel, les flux multimédia, tels que ceux utilisés dans le cadre de la vidéoconférence ou de la téléphonie IP, peuvent se montrer extrêmement sensibles aux retards ou à la bande passante disponible. Cela impose des exigences uniques en matière de qualité de service (QoS) sur les réseaux sous-jacents qui transportent ces flux. Malheureusement, le protocole IP, avec un modèle de diffusion Best-Effort sans connexion, ne garantit pas la livraison ordonnée et ponctuelle des paquets ; dans certains cas, la livraison n'est même pas garantie. Afin de déployer des applications en temps réel sur des réseaux IP avec un niveau de service acceptable, il convient de garantir et de respecter certaines exigences en matière de bande passante, de latence et d'instabilité. De cette manière, trafic multimédia et données traditionnelles pourront coexister sur un même réseau.

*Bande passante * : Les données multimédia, en particulier la vidéo, nécessitent plus de bande passante que ce que les réseaux traditionnels peuvent supporter. Ainsi, un flux vidéo NTSC non compressé peut exiger un flux ascendant de 250 Mbits/s. Même compressés, quelques flux multimédia peuvent complètement submerger tout autre trafic sur le réseau.

*Latence * : Le temps nécessaire à un paquet multimédia pour aller de la source à la destination (latence) a une incidence majeure sur la perception de la qualité de l'appel. De nombreux facteurs influent sur la latence : temps de transmission, mise en file d'attente des retards dans le matériel réseau, retards dans les piles de protocole hôte... Il importe de réduire la latence afin de préserver un certain niveau d'interactivité et d'éviter les pauses non naturelles dans la conversation.

*Instabilité * : Contrairement au trafic de données, les paquets multimédia en temps réel doivent arriver dans l'ordre et dans les temps, sans quoi ils ne seront d'aucune utilité pour le destinataire. Les variations dans l'heure d'arrivée d'un paquet (instabilité) doivent se situer sous un certain seuil afin d'éviter les paquets perdus (et, par là même, les cris et les temps morts dans la communication). En déterminant les tailles de tampon, l'instabilité affecte également la latence.

*Coexistence * : Comparé au trafic multimédia, le trafic de données se distingue par une transmission par rafales et par segments imprévisibles (par exemple, lorsqu'un utilisateur ouvre une page Web ou télécharge un fichier depuis un site FTP). L'agrégation de ces rafales est de nature à obstruer les routeurs et à provoquer des temps morts dans les conférences multimédia, laissant ainsi les appels à la merci de quiconque sur le réseau (y compris d'autres utilisateurs de la téléphonie IP). La bande passante multimédia doit donc être isolée du trafic de données, et inversement.

Les réseaux téléphoniques commutés publics garantissent une qualité de service minimale en allouant des circuits statiques pour chaque appel téléphonique. Facile à implémenter, ce type de méthode gaspille néanmoins de la bande passante, manque de robustesse et rend difficile l'intégration de la voix, de la vidéo et des données. En outre, il s'avère impossible de créer des chemins de données à commutation de circuits avec un réseau sans connexion tel que IP.

Le support QoS sur réseaux IP offre les avantages suivants :

• Prise en charge d'applications multimédia en temps réel.
• Transfert ponctuel garanti pour les grandes quantités de données.
• Possibilité de partager le réseau de telle sorte que les applications ne tombent plus à court de bande passante.

Dans l'infrastructure TAPI 3.0, la qualité de service est gérée par le biais du filtre RTP DirectShow, lequel négocie les capacités de bande passante avec le réseau. Cette négociation s'opère sur la base des exigences des codecs DirectShow associés à un flux multimédia spécifique. Ces exigences sont spécifiées au filtre RTP par les codecs par le biais de sa propre interface QoS. Le filtre RTP utilise ensuite les interfaces GQoS COM Winsock2 pour indiquer, sous une forme abrégée, ses propres exigences QoS aux fournisseurs de service QoS Winsock2 (QoS SP). Le QoS SP utilise, à son tour, plusieurs mécanismes QoS adaptés à l'application, aux médias sous-jacents et au réseau afin de garantir une qualité de service appropriée de bout en bout. Voici les mécanismes mis en œuvre :

• Protocole RSVP (Resource Reservation Protocol)

  Contrôle du trafic local :

  • Planification de paquets
  • 802.1p
  • Mécanismes de signalisation de couche 2 appropriés

• Type de service IP et paramètres d'en-tête DTR

Le protocole RSVP (Resource Reservation Protocol) est un standard de l'IETF conçu pour la prise en charge des réservations de ressources (la bande passante, par exemple) via des réseaux présentant des topologies et médias divers. Les requêtes QoS d'un utilisateur sont transmises, par le biais du protocole RSVP, à tous les routeurs situés sur le chemin de données, ce qui permet la reconfiguration automatique du réseau (à tous les niveaux) en vue de respecter le niveau de service voulu.

Le protocole RSVP engage des ressources réseau en créant des flux à l'échelle du réseau. Un flux est un chemin réseau auquel sont associés un ou plusieurs émetteurs, un ou plusieurs destinataires et une certaine qualité de service (QoS). Un hôte émetteur désireux d'envoyer des données exigeant une certaine qualité de service diffuse, par le biais d'un fournisseur de service Winsock compatible RSVP, des messages de chemin vers les destinataires voulus. Ces messages, qui décrivent les besoins en bande passante et les paramètres pertinents des données à envoyer, sont transmis à tous les routeurs intermédiaires situés sur le chemin.

Tout hôte récepteur intéressé par ces données confirme le flux (et le chemin réseau) en envoyant des messages de réservation sur le réseau. Ces messages décrivent les caractéristiques de bande passante des données qui seront envoyées par l'émetteur. Alors que les messages de réservation reprennent le chemin de l'émetteur, les routeurs intermédiaires décident, selon la capacité de la bande passante, s'il convient d'accepter ou de refuser la réservation proposée et, partant, d'affecter des ressources. Dans l'affirmative, les ressources sont allouées et les messages de réservation sont transmis au nœud suivant sur le chemin reliant la source à la destination.

*Planification de paquets * : Ce mécanisme peut être utilisé avec le protocole RSVP (si le réseau sous-jacent est compatible RSVP) ou sans. Le trafic est identifié comme appartenant à l'un ou l'autre flux. Quant aux paquets émanant de chaque flux, ils sont planifiés conformément aux paramètres de contrôle du trafic relatifs au flux. Ces paramètres comprennent généralement un débit planifié (paramètre token bucket) et une certaine indication de la priorité. Le débit est utilisé pour rythmer la transmission des paquets vers le réseau. Quant à l'indication de priorité, elle sert à déterminer l'ordre dans lequel les paquets doivent être envoyés vers le réseau en cas de congestion.

*801.2p * : Le contrôle de trafic peut également être utilisé en vue de déterminer la valeur Priorité utilisateur 802.1 (il s'agit d'un champ d'en-tête MAC utilisé pour indiquer une priorité de paquet relative) à associer à chaque paquet transmis. Les commutateurs compatibles 802.1p peuvent accorder un traitement de faveur à certains paquets, fournissant alors un support QoS supplémentaire au niveau de la couche liaison de données.

*Mécanismes de signalisation de niveau 2 * : En réponse aux API QoS Winsock 2, le fournisseur de service QoS peut recourir à des mécanismes de contrôle du trafic supplémentaires, en fonction de la couche de liaison de données sous-jacente spécifique. Il peut, par exemple, signaler un réseau ATM sous-jacent afin d'établir un circuit virtuel approprié pour chaque flux. Si le support sous-jacent est un réseau multimédia partagé 802 traditionnel, le fournisseur de service QoS peut étendre le mécanisme RSVP standard en vue de signaler un SBM (Subnet Bandwidth Manager). Le SBM assure une gestion centralisée de la bande passante sur les réseaux partagés.

Chaque paquet contient un champ Priorité de trois bits qui indique la priorité des paquets. L'ajout d'un autre champ est possible en vue d'indiquer au réseau une préférence de retard, de débit ou de fiabilité. On peut recourir au contrôle du trafic local pour définir ces bits dans les en-têtes IP des paquets sur des flux déterminés. En conséquence, les paquets appartenant à un flux seront traités convenablement, ultérieurement, par trois périphériques du réseau. Analogues aux paramètres de priorité 802.1p, ces champs sont cependant traités par des périphériques réseau de niveau supérieur.

Haut de page

Déploiement en entreprise de l'infrastructure de téléphonie IP TAPI 3.0

L'interface TAPI 3.0 a été conçue pour s'adapter aussi bien aux PME qu'aux grandes sociétés, et ce, tout en exploitant le service Active Directory de Windows 2000 afin d'intégrer la téléphonie IP au sein de l'entreprise.

La Figure 26 illustre la structure d'une entreprise type avec deux sites connectés via Internet. Comme nous l'avons expliqué précédemment, les serveurs Dynamic Directory ILS et le serveur de conférence Dynamic Directory ILS fournissent les fonctionnalités nécessaires pour organiser des conférences multipartites et point à point. Les clients de téléphonie IP peuvent utiliser un équipement de capture audio et vidéo. La prise en charge de téléphones classiques est également possible moyennant l'utilisation d'une carte d'extension RTPC.

La passerelle IP/RTPC numérise les appels vocaux analogiques entrants et les encapsule dans des flux H.323, et inversement, offrant ainsi aux utilisateurs la possibilité de passer et de recevoir des appels vocaux classiques via leur infrastructure de téléphonie en place.

Le proxy H.323 permet aux clients H.323 de bénéficier d'une connexion à Internet en redirigeant les flux H.323 à travers le pare-feu de l'entreprise. Cela permet la mise en place d'une connectivité de type business-to-business, Intranet et Internet H.323.

La fonction du proxy IP Multicast est, en gros, la même que celle du proxy H.323, à savoir : transmettre les paquets de conférence multidiffusion. Cependant, il offre également aux clients la possibilité de diffuser certaines annonces de conférence sur Internet.

Le proxy IP Multicast contrôle les annonces de conférence stockées sur le serveur de conférence Dynamic Directory ILS et diffuse des conférences sur Internet avec les attributs de sécurité et l'étendue appropriés. Pour ce faire, il a recours au protocole SAP (Session Announcement Protocol).

Inversement, le proxy IP Multicast guette les conférences appropriées parmi celles diffusées sur Internet et remplit le serveur de conférence Dynamic Directory ILS des annonces trouvées. En procédant de la sorte, le proxy IP Multicast permet aux utilisateurs de se connecter à des conférences sur Internet, tout en garantissant la confidentialité et la sécurité des conférences privées.

Ainsi qu'il a été mentionné précédemment, le TSP H.323 utilise les services du composant Dynamic Directory ILS d'Active Directory afin de dispenser l'utilisateur de l'opération de conversion du nom vers IP.

Au niveau du réseau, le modèle Active Directory de Windows 2000 considère une entreprise comme un ensemble de sites. Les sites sont des régions jouissant d'une bonne connectivité, telles que les sous-réseaux ou réseaux locaux (LAN). En règle générale, ils sont en relation avec des emplacements physiques locaux, tels que des campus.

Pour des raisons de performance et de bande passante, les serveurs ILS sont généralement répartis au sein de l'entreprise, un par site ; chaque serveur ILS (ou cluster de serveurs de réplication) est responsable de la gestion des correspondances utilisateur vers IP pour son propre site. Pour ne pas gaspiller la bande passante, ces correspondances volatiles ne sont pas répliquées parmi les sites.

TAPI 3.0 utilise Active Directory pour associer les utilisateurs à des serveurs ILS spécifiques. Les utilisateurs désireux de passer un appel téléphonique IP consultent tout d'abord le Catalogue global (il s'agit d'un sous-ensemble répliqué de l'Active Directory) à la recherche de l'objet Utilisateur de la personne qu'ils souhaitent contacter. Le conteneur Téléphonie de l'objet Utilisateur contient le nom du serveur ILS relatif au site de cet utilisateur. Une requête est ensuite effectuée pour retrouver l'adresse IP en question.

Le scénario suivant illustre le déploiement, en entreprise, de l'infrastructure d'annuaire TAPI 3.0. Dans cet exemple, Alice souhaite passer un appel H.323 à Jean.

1. Jean a déjà enregistré son nom de serveur ILS auprès du catalogue global Active Directory. Lors de l'initialisation, le TSP H.323 de Jean interroge le Catalogue global au sujet de l'objet Sous-réseau associé à son ordinateur et en déduit le site auquel appartiennent l'ordinateur et le sous-réseau de Jean. Le TSP récupère ensuite le nom du serveur ILS (ou groupe de serveurs de réplication) à partir des enregistrements DNS et stocke ces informations dans l'objet Utilisateur de Jean.

2. Par la suite, le TSP H.323 d'Alice recherche, dans sa copie locale du Catalogue global, le nom du serveur ILS de Jean :

3. Le TSP H.323 d'Alice interroge ensuite le serveur ILS de Jean au niveau du réseau étendu (WAN) pour connaître l'adresse IP actuelle de Jean :

4. Alice lance alors une session H.323 avec Jean :

L'abstraction d'appel inhérente à l'interface TAPI permet la mise en place transparente, tant pour l'utilisateur que pour l'application compatible TAPI 3.0, de cette interaction entre ILS et Active Directory.

Haut de page

TAPI 3.0 et NetMeeting 2.0

Microsoft NetMeeting est un outil de conférence et de collaboration conçu pour le réseau Internet ou un intranet. NetMeeting s'accompagne également d'un ensemble d'interfaces de programmation permettant d'agrémenter vos applications de fonctionnalités de conférence. Grâce à NetMeeting, les petites et les grandes entreprises peuvent profiter de l'envergure planétaire d'Internet ou de leur intranet pour collaborer ou établir des communications en temps réel en combinant fonctionnalités de conférence et de téléphonie IP. Se connecter à d'autres utilisateurs NetMeeting est un jeu d'enfant grâce au serveur ILS (Internet Locator Server) de Microsoft. Ce serveur permet aux participants de s'appeler à partir d'un annuaire dynamique depuis NetMeeting ou une page Web. Tout en étant connectés à Internet ou à l'intranet de la société, les participants peuvent communiquer de manière vocale et visuelle, collaborer sur pratiquement n'importe quelle application Windows, échanger ou annoter des graphiques sur un tableau blanc électronique, transférer des fichiers ou utiliser un programme de conversation texte. Pour plus d'informations sur Microsoft NetMeeting 2.0.

Microsoft NetMeeting 2.0 présente les caractéristiques suivantes :

Conférence audio et vidéo H.323 standard. La fonction d'audioconférence point à point et en temps réel sur Internet ou l'intranet de la société permet aux utilisateurs de passer des appels vocaux à leurs collègues et aux entreprises du monde entier. La fonction de vidéoconférence de NetMeeting offre de nombreuses fonctionnalités : prise en charge audio half-duplex et full-duplex pour les conversations en temps réel, réglage automatique du niveau de sensibilité du microphone afin d'assurer la clarté des communications entre les participants et fonction de silence du microphone, permettant aux utilisateurs de contrôler le signal audio envoyé en cours d'appel. Cette conférence vocale prend en charge les connexions TCP/IP.

La prise en charge du protocole H.323 permet une interopérabilité entre NetMeeting 2.0 et les autres clients vocaux compatibles H.323. Le protocole H.323 prend en charge les standards audio G.711 et G.723 de l'UIT, ainsi que les spécifications RTP et RTCP de l'IETF portant sur le contrôle du flux audio en vue d'améliorer la qualité vocale. Sur les ordinateurs optimisés pour le jeu d'instructions MMX, NetMeeting utilise les codecs vocaux optimisés pour améliorer les performances des algorithmes de compression et de décompression vocales. Cela se traduit par une utilisation réduite du processeur et une qualité vocale améliorée en cours d'appel.

NetMeeting 2.0 permet à un utilisateur d'échanger des images en temps réel avec un autre participant à la conférence. Il lui suffit, pour cela, d'utiliser une machine compatible avec la norme "Video for Windows". Le partage d'idées et d'informations peut s'effectuer visuellement, la caméra étant utilisée pour visualiser instantanément les objets, tels qu'un équipement ou un périphérique, que l'utilisateur choisit de placer devant l'objectif. En y associant les fonctionnalités vidéo et données de NetMeeting 2.0, un utilisateur pourra non seulement voir et entendre l'autre participant, mais aussi partager des informations et des applications. Cette technologie vidéo standard H.323 est en outre compatible avec les codecs vidéo H.261 et H.263.

Conférence de données multipoint à l'aide du standard T.120. Plusieurs utilisateurs peuvent communiquer et collaborer en temps réel comme s'ils formaient un groupe. Les participants peuvent partager des applications, échanger des informations au moyen d'un presse-papiers partagé, transférer des fichiers sur un tableau blanc partagé et utiliser une fonctionnalité de conversation en mode texte. La prise en charge du standard de conférence de données T.120 assure également une interopérabilité avec les autres services et produits compatibles T.120. La conférence de données multipoint se retrouve dans les fonctionnalités suivantes :

*Partage d'applications * : Un utilisateur peut partager un programme s'exécutant sur un ordinateur avec les autres participants à la conférence. Les participants peuvent consulter les mêmes données ou informations et visualiser les actions exécutées à mesure que la personne qui partage l'application travaille sur le programme (modification du contenu et défilement des informations, par exemple). Les participants peuvent partager des applications Windows en toute transparence sans pour autant connaître les fonctionnalités de l'application.

La personne qui partage l'application peut décider de collaborer avec d'autres participants. Les utilisateurs peuvent ainsi, à tour de rôle, modifier ou contrôler l'application. Le programme partagé doit uniquement être installé sur la plate-forme de la personne qui le partage.

Presse-papiers partagé : Le presse-papiers partagé permet à un utilisateur d'échanger son contenu avec d'autres participants en utilisant simplement des opérations de coupage, de copie et de collage. Ainsi, un participant peut copier des informations à partir d'un document local et coller le contenu dans une application partagée dans le cadre d'une application de groupe.

*Transfert de fichiers * : La fonctionnalité de transfert de fichiers permet à un utilisateur d'envoyer un fichier, en tâche de fond, à un ou à l'ensemble des participants. Lorsqu'un utilisateur fait glisser un fichier vers la fenêtre principale, celui-ci est envoyé automatiquement à chaque personne ayant pris part à la conférence ; les participants peuvent alors accepter ou refuser la réception. Cette fonction est entièrement compatible avec la norme T.127.

Tableau blanc : Plusieurs utilisateurs peuvent collaborer à l'aide du tableau blanc. Cette fonctionnalité leur permet de consulter, de créer et de mettre à jour des informations graphiques. Le tableau blanc est une fonction orientée objet (par opposition à une fonction orientée pixel), ce qui permet aux participants de manipuler le contenu en cliquant sur les objets et en les faisant glisser. Il est aussi possible d'utiliser un outil de surlignage ou un pointeur distant pour désigner un contenu spécifique ou certaines sections de pages partagées.

*Conversation * : Un utilisateur peut taper du texte en vue de partager des idées ou des sujets avec les autres participants, ou enregistrer des notes de réunion et des mots d'ordre dans le cadre d'un processus de collaboration. Les participants peuvent en outre utiliser la fonction de conversation (chat) pour communiquer en l'absence de support audio. Avec la fonction de "messe basse", un utilisateur peut converser en privé avec une autre personne durant une session de conversation en groupe.

Kit de développement logiciel NetMeeting 2.0. Ce kit SDK permet aux développeurs d'intégrer directement cette fonctionnalité de conférence dans leurs applications ou pages Web. Cet environnement de développement ouvert prend en charge les normes de conférence et de communication internationales. Il assure en outre une interopérabilité avec les produits et services proposés par différents constructeurs.

Le kit SDK NetMeeting s'accompagne également d'API, ce qui permet d'ajouter des codecs non standard et d'accéder aux serveurs ILS via LDAP. On y trouve également un contrôle ActiveX™, qui offre la possibilité d'ajouter aisément des fonctionnalités de conférence aux pages Web.

TAPI 3.0 et NetMeeting 2.0 prennent en charge les fonctionnalités de téléphonie IP de base. Chaque plate-forme offre des avantages uniques : TAPI 3.0 intègre en toute transparence les modes de téléphonie traditionnels et IP, ce qui donne une infrastructure de diffusion de données en continu et de contrôle d'appel COM indépendante du protocole. Le kit SDK de NetMeeting 2.0 prend en charge le partage d'applications et la conférence T.120 en plus de la téléphonie IP. Les applications qui utilisent TAPI 3.0 et l'API NetMeeting 2.0 interopèrent via le standard de conférence audiovisuelle H.323.

Étant donné que TAPI 3.0 et NetMeeting 2.0 prennent tous deux en charge les fonctionnalités de téléphonie IP de base (y compris le standard H.323), les développeurs peuvent, s'ils le souhaitent, se conformer aux directives suivantes lors de la sélection d'une API pour leurs applications de téléphonie IP :

TAPI 3.0. Utilisez cette API pour intégrer la téléphonie dans votre application. TAPI 3.0 se révèle particulièrement utile dans le cadre de l'intégration de la téléphonie client/serveur pour combiner téléphonies traditionnelle et IP, mais aussi pour la multidiffusion IP de données vocales et vidéo.

API NetMeeting 2.0. Utilisez cette API pour collaborer en temps réel et intégrer une fonction de conférence voix, vidéo et données dans votre application. L'API NetMeeting est particulièrement utile pour les applications désireuses d'intégrer une fonction de partage, un tableau blanc et un transfert de fichiers multipoint avec des sessions vocales et vidéo.

Les informations contenues dans ce document représentent l'opinion actuelle de Microsoft sur les points cités à la date de publication. Microsoft s'adapte aux conditions fluctuantes du marché et cette opinion ne doit pas être interprétée comme un engagement de la part de Microsoft ; de plus, Microsoft ne peut pas garantir la véracité de toute information présentée après la date de publication. Ce livre blanc est fourni pour information uniquement. MICROSOFT N'OFFRE AUCUNE GARANTIE, EXPRESSE OU IMPLICITE, DANS CE DOCUMENT. Microsoft, ActiveX, le logo BackOffice, DirectShow, Visual Basic, Windows et Windows NT sont soit des marques de Microsoft Corporation, soit des marques déposées de Microsoft Corporation aux États-Unis d'Amérique et/ou dans d'autres pays. Les autres noms de produits ou de sociétés mentionnés sont des marques de leurs propriétaires respectifs. Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 • États-Unis

Dernière mise à jour le lundi 28 février 2000

Haut de page