Diffuser du contenu Multimédia : les visioconférences

Attention, ceci est un document en cours de réalisation.

Plan

Les contraintes technologiques

Nous sommes dans le cas où une source émet des données multimédias (audio et vidéo) vers un nombre assez d'élevé d'auditeurs. Chaque auditeur reçoit la même chose en même temps (nous ne sommes pas dans le cas de vidéo à la demande). Afin de d'avoir une qualité d'image (bien au-dessus d'une webcam) et de son convenable, les données à véhiculer doivent être conséquentes. Dans le monde de l'Unicast, la source devrait envoyer en temps réel le contenu multimédia vers chaque auditeur. On comprend très bien que, dès que ce nombre d'auditeurs devient élevé, la puissance d'émission de la source devient irréalisable.
De plus, chaque auditeur pourrait devenir une source pour par exemple poser une question.
Il faut également assurer une Qualité de services afin que chacun des auditeurs possède à tous moments une bonne liaison car il n'est pas envisageable de recevoir un son ou une vidéo hachés.
Les limites de l'Unicast étant largement dépassées pour ce genre de transmission, nous allons exposer ici le multicast qui permet de faire de telles conférences.

Multicasting IP

Le principe

Le multicast permet de répartir les multiplications d'échanges de données sur le réseau. La source qui doit émettre envers de nombreux auditeurs, émet un unique flux vers une adresse de groupe (de classe D c'est à dire dont le premier quad oscille entre 224 et 239 et non vers une adresse IP individuelle comme en Unicast). Ce flux va être ensuite multiplié afin d'atteindre tous les auditeurs. Ces copies seront effectuées par les différents routeurs multicast.

Le Protocole IGMP:
IGMP est implémenté dans le module IP : les messages IGMP sont encapsulés dans les datagrammes IP. Il permet de connaître les adhésions de groupe. Il gère ainsi l'abonnement/le désabonnement des auditeurs via les différents groupes.
Les routeurs multicast envoient périodiquement des messages de requêtes (query) vers le groupe commun des hôtes. Chaque hôte doit donc répondre via un message de comptes-rendus (report). Il existe des techniques afin d'éviter une surcharge du réseau (Reporting).
Dans le cas d'un premier membre d'un nouveau groupe, cet hôte doit envoyer un report (sans avoir reçu de query).
Inversement, un hôte peut quitter un groupe via ce protocole. Si cet hôte était le seul du groupe, une technique d'élagage devra être initialisée par le protocole DVMRP afin de ne plus diffuser vers ce groupe privé d'auditeurs.
Référence : RFC 1112 -Host Extension for IP Multicasting-

Le Protocole RSVP: Ressource ReServation Protocol
Après s'être abonné à un groupe via IGMP, l'hôte envoie des messages RSVP afin de réserver des ressources tout au long de la route d'acheminement (entre le routeur de groupe et lui-même).
Attention, ce protocole permet uniquement une réservation de bande passante afin de garantir une QoS et laisse au protocole de routage la façon dont les paquets seront transmis.
RSVP opère au sommet d'IP v4 ou v6 (niveau transport dans le modèle OSI) dans le cas de communication uni ou multicast.
Référence : RFC 1633 -XXXXXX-
RFC 2210 -Structure et contenu des paramètres de QoS-, développé par l'Integrated Services Working Group
RFC 1633 -Objectif et justification générale du design RSVP-

Le Protocole RTP: Real-Time Protocol
RTP permet de le transport (uni ou multicast)de données (audio, vidéo) à caractère temps réel.
RTP réordonne la séquence et le timing induite par l'émetteur (et ne pouvant être assurés par les réseaux de paquets comme l'Internet).
RTP peut aussi intervenir dans le cas d'un auditeur se trouvant derrière un Firewall et ne pouvant pas être joint directement en multicast (utilisation de Translator).
RTP n'assurant aucune QoS, le protocole RTCP (Real-time Transport Control Protocol) peut être utilisé sur un autre port afin d'assurer une qualité de service.

Le Protocole DVMRP: Distance Vector Multicast Routing protocol
Ce protocole permet de gérer la distribution des paquets aux différents groupes. C'est un protocole de routage.
Il construit des arbres d'acheminement grâce à la technique RPM (Reverse Path Multicasting). Ces arborescences sont qualifiées de dynamiques à cause de la possibilité d'abonnement (greffe) d'un nouvel hôte entraînant l'apparition d'un nouveau routeur multicast (techniquement, on rajoute dans la table de routage du routeur multicast le plus proche l'adresse IP de classe D du nouveau routeur) ou l'élagage (pruning) d'un autre routeur "feuille" (dernier routeur multicast, relié aux auditeurs par des réseaux Unicast) car son dernier auditeur s'est désabonné.
DVMRP détermine donc les meilleures routes entre une source de traffic multicast et lui-même grâce aux métriques (générés par RIP). Référence : RFC 1075 -DVMRP v1-

Le Protocole PIM: Protocol Independent Multicast
PIM est un protocole de routage au même titre de DVMRP. Il est cependant plus simple et supporté par les routeurs CISCO récents (le MBone utilise à 100% PIM).
PIM existe en deux versions PIM-DM (Dense Mode) et PIM-SM (Sparse Mode)
A la différence de DVMRP, PIM ne dépend d'aucun protocole de routage.
PIM peut envoyer et recevoir des messages Prune vers toutes les interfaces alors que DVMRP n'envoie que vers l'interface amont dans l'arbre Source-Groupe et n'en reçoit que vers des interfaces en aval.

Visualisation du réseau (si vous êtes connecté en multicast!)
Vue du réseau via MVIEW (visualisation graphique des fonctions systèmes multicast comme mroute, mtrace).
Une démonstration de cet outil de gestion du trafic est disponible sur http://sydney.cssi.recherche.fr/multicast/.

Exemple d'application

DIM, qui est un projet permettant à plusieurs universités (Evry, Jussieu, Valenciennes, Dakar au Sénégal, INT d'Evry) d'avoir des cours en commun via la visioconférence. Nous utilisons le réseau multicast Renater.
Pour plus d'informations, cliquez sur le lien suivant: http://aristote1.aristote.asso.fr/DIM

Les réseaux en cours de développement

Orienté pour la recherche

ABILEM :Réseau américain d'Internet2 qui relie 150 universités en multicast.
CANET : idem mais au Canada.
GEANT : Réseau au niveau européen de 1Gbit/s qui devrait atteindre 100Gbit/s d'ici deux ans. Une interconnexion des réseaux de recherches (recherch peering) notamment via Startap (point d'entrée situé à Chicago sur l'internet2 Abylème par l'homologue de FT qui loue ces services).
ATHENA : raccord avec l'Afrique via le Sénégal avec l'université de Dakar et ESMT, grande école des télécoms qui a la particularité d'être multinationale (Bénin, Togo...). Lionel David, étudiant partenaire du projet DIM en alternance avec le GIP Renater s'occupe de ce projet.
RENATER : REseau NAtional [francais] TE Recherche.
NOROPALE : Réseau Régional du Nord (Valencienne...)
RERIF : Réseaux régionaux d'Ile de France.
REVE : Réseau multicast reliant les centre de recherches et de formations de la ville nouvelle d'Evry.
SFINX : Passerelle entre le réseau accadémique Renater et les différents opérateurs commerciaux

Le matériel nécessaire ; mise en place d'une visioconférence

Dans le cas d'une réunion de télé-travail, chaque participant pourra utiliser une webcam (500 à 1 000 F). Il faut souligner que les webcams sont quasiment toutes en USB (et donc non reconnues par Windows NT 4). Les webcams ne disposent pas d'une résolution très grande mais cela peut suffire dans de telles conditions. Cependant, dans le cas de cours à distance, de conférences..., il faut absolument investir dans une caméra spécialisée (zoom, télémanipulation) comme la Sony EVI D31 (8 000 FHT) ou un camescope numérique (zoom plus performant mais non télécommandable) dont les prix oscillent entre 7 000 et 20 000 F. Le fait que la caméra soit numérique garantit seulement une qualité convenable (l'outil de transmission vidéo multicast VIC ne supporte pas de données numériques).
Exceptée la webcam qui ne provoque pas de surcoût, tout ce matériel dispose d'une sortie S-VHS que l'on branchera sur ordinateur via un boîtier d'aquisition vidéo (USB) ou une carte interne (environ 600FHT).

Devant les bruits parasites environnants (auditeurs en présentiel, ventilateur des ordinateurs, vidéoprojecteurs) un microphone cravate mono dont la bande passante devrait s'étaler entre 50 à 10 000 Hz est recommandée.

Des hauts-parleurs de qualité musicale (presque 1 000 FTTC)ou un casque sont recommandés. Il est possible cependant de trouver des hauts-parleurs à 500 FTTC qui fonctionnent correctement (tout dépend aussi de la surface à couvrir).

Il faut aussi noter qu'il ne faut pas émettre du son avec un portable relié au réseau par une carte PCMCIA. En effet ce port complexe véhicule les données de façon très irrégulière. On obtient un son haché car VIC (l'outil multicast dédié à l'audio) supprime les paquets qui comportent des giges (irrégularités) ce qui entraîne de nombreuses micro-coupures.

Les causeries du FMBone traitant de ce sujet

Accédez aux causeries du FMBone sur le Multicasting IP
(Ces présentations sont bien évidemment réalisées en SMIL. De nombreuses autres sont disponibles en vidéo à la demande via le serveur web de Renater ou d'Aristote)

Draft 0.5  
Dernière MAJ : 18 novembre 2001  
Contact : Cédric Carbone