Visioconférence à l Université Paris Sud

Visioconférence à l’Université Paris Sud

Nicolas CAREL,

CRI – Université Paris Sud, Orsay

Résumé : Ce document présente le projet de visioconférence à l’Université Paris Sud dans tous ses aspects. Sont détaillés : les étapes du projet, l’architecture mise en place, les problèmes liés à la qualité de service du réseau, les méthodes d’exploitation, les coûts et la gestion de la facturation, la problématique d’un annuaire français des sites de visio conférence, le développement avec le CRU d’un système de réservation et, l’interopérabilité entre gatekeepers.

Introduction

Le projet de visioconférence a démarré en 1999 par la demande d’enseignants en médecine visant à faire intervenir des chirurgiens américains dans des cours d’urologie. Au moment de la demande, les crédits nécessaires à la mise en place d’un système de visioconférence n’étaient pas disponibles. La demande fut faite sur les budgets NTIC de l’Université. D’autres UFR et IUT avaient des projets du même ordre dans leurs cartons et ce fut l’occasion pour eux d’entamer le processus de concrétisation. Fin 1999, les budgets nécessaires ont été réservés par le conseil d’administration et la présidence subordonne la mise en place de la visioconférence à la conduite d’un projet par le CRI.

Parallèlement, le CRI s’est lancé dans une analyse précise du marché dans le but de rédiger un cahier des charges.

Il est ressorti rapidement de l’étude de marché la nécessité de s’adapter aux nouvelles technologies en matière de visioconférence. La visioconférence sur les réseaux IP (H.323¹) représente l’avenir. Cependant, il est absolument nécessaire de garder la compatibilité avec la base installée en RNIS (H.320²).

Les étapes du projet

Pour notre projet de visioconférence, nous avons opté pour un marché ouvert à bon de commande reconductible sur trois ans.

Le calendrier

• 1998-1999 : Émergence du besoin

• Octobre 1999 : Étude du marché

• Décembre 1999 : Réservation des crédits NTIC

• Mars 2000 : Rédaction du cahier des charges

• Juin 2000 : Lancement de l’appel d’offre

• Juillet 2000 : Visite des soumissionnaires

• Septembre 2000 : Ouverture des plis et analyse des réponses

• Octobre 2000 : Maquette de deux soumissionnaires en short list

• Novembre 2000 : Notification et commande Janvier 2001 : Début de l’installation

• Avril 2001 : Fin de l’installation

• Mai 2001 : Validation d’aptitude

1H.323 : Ensemble de protocoles normalisés définissant la signalisation et les encodages pour la voix et la vidéo sur IP.

2H.320 : Ensemble de protocoles normalisés définissant la signalisation et les encodages pour la voix et la vidéo sur RNIS.

Rédaction du cahier des charges

Le cahier des charges nécessite beaucoup d’attention, ce qui explique les trois mois nécessaires à sa rédaction. Des compétences mixtes entre l’informatique et l’audiovisuel sont nécessaires à son élaboration.

La vigilance s’impose quant à l’évolution des paramètres technologiques entre le moment de la rédaction et la première commande sur le marché.

Certaines normes sont implémentées et d’autres ont du retard. Nous avons été pris au dépourvu en ce qui concerne le protocole de commande à distance des caméras H.281, normalisé en H.320 (RNIS³) mais toujours en discussion en H.323 (IP). À l’époque de la rédaction du CCTP⁴, Netmeeting 2.11 était l’implémentation du marché pour le protocole T.120⁵. Nous constatons aujourd’hui un net virage vers Netmeeting 3.01. Les deux versions présentent des incompatibilités sur le partage applicatif.

Visite des soumissionnaires

Quinze entreprises sont venues visiter les lieux, conformément au cahier des charges. Ces visites permettent de se connaître, de cerner les besoins, de faire une proposition adaptée au terrain (surtout en ce qui concerne l’équipement des amphithéâtres). Certains soumissionnaires s’y sont pris à la dernière minute pour visiter. Avec du recul, il est nécessaire de fixer une date limite pour la visite des différents sites. Les visites ont demandé deux semaines à plein temps.

L’ouverture des plis et l’analyse des réponses

Dix entreprises seulement ont répondu. Six réponses furent rejetées par l’agent comptable pour défaut de signature de la liste de prix. Les réponses, à priori, les mieux classées n’ont donc pu être examinées. Sur les quatre restantes, deux entreprises ont fait une erreur de conception technique et ne répondaient pas à l’architecture décrite par le cahier des charges. Le choix s’est alors fait sur les deux restantes.

Maquette

La maquette est une phase importante de l’appel d’offre. Son but est de vérifier la concordance de la solution proposée par les soumissionnaires par rapports aux critères du cahier des charges. Elle a permis de mieux cerner les compétences d’intégration entre le monde informatique et le monde audiovisuel de chacun. Elle a permis de départager techniquement les deux soumissionnaires en short list.

Notification et commande

Le CRI a passé commande de ses équipements prioritaires (pont et passerelle) en même temps que la notification. L’UFR de médecine a suivi immédiatement. Le calendrier du projet a failli déraper car la limite comptable de commande était fixée fin novembre pour l’exercice budgétaire en cours. Il aurait mieux valu prévoir la notification du marché avant le mois d’août de l’année afin d’éviter les retards liés aux vacances et à la rentrée.

Déploiement et validation d’aptitude

Le déploiement doit être suivi de près afin d’éviter tout dérapage. La validation d’aptitude est un test identique à celui de la maquette permettant de certifier le bon fonctionnement du système après son installation. Cette validation d’aptitude déclenche le paiement des factures.

L’architecture technique

L’architecture technique retenue permet de satisfaire les besoins présents et d’envisager les évolutions à venir.

Le choix de la solution H.323

Pour la communication avec les salles existantes en H.320, deux optiques convergentes vers H.323 étaient envisageables :

1. équiper tous les sites en système mixte H.320 et H.323 en commandant les lignes RNIS pour chaque salle (3 lignes par équipement⁶).

2. équiper tous les sites en système H.323 en mettant en œuvre une passerelle H.320/H.323.

3 RNIS : Réseau Numérique à Intégration de Service. L’accès de base est composé de 2 canaux B à 64 Kbps et d’un canal de signalisation (D) à 16 Kbps. L’accès primaire est composé de 30 canaux à 64 Kbps et d’un canal de signalisation à 64 Kbps. Commercialisé en France sous le nom « Numéris ».

4 CCTP : Cahier des Clauses Techniques Particulières. Le CCTP est un des volets de l’appel d’offre.

5T.120 : Norme de partage applicatif. Permet de manipuler toute application de l’une des extrémités par l’ensemble des participants. Indispensable pour partager les diaporamas.

63 lignes à 2x64 Kbps permettent un débit de 384 Kbps (visioconférence de haute qualité).

Les critères de notre choix furent les suivants :

Aujourd’hui, 7 équipements sont en service (4 PictureTel 960 et 3 PictureTel 550).

Le coût d’investissement en francs est important, mais paradoxalement le budget NTIC est plus facile à obtenir.

La passerelle permet aussi de déplacer à souhait les systèmes de visioconférence. Elle permet l’intégration aisée de nouveaux équipements (du système de salle au Microsoft Netmeeting).

Schéma d’architecture

Nous avons donc retenu l’architecture suivante :

Description des éléments

La Gatekeeperréférence les services autorisés sur chacun des équipements, autorise les appels en fonction de la bande passante disponible, tient des journaux permettant de facturer la consommation des services.

La passerelleconvertit les codages audio et vidéo entre le monde H.323 et le monde H.320. Elle dispose d’une interface RNIS primaire (30 canaux de 64 Kbps). Elle effectue l’association des numéros directs (SDA7) avec les systèmes enregistrés par la Gatekeeper.

Le pontpermet à plusieurs systèmes de converser dans une même session. Il permet de mixer des appels de visioconférence à des appels téléphoniques. Sa capacité est de 15 participants à 128 Kbps et de 5 participants à 384 Kbps. Il dispose d’une interface Ethernet.

Le poste individuel, basé sur un CODEC⁸matériel ou logiciel, permet à un seul utilisateur d’entrer en réunion avec son poste de travail existant. Nous avons préféré un poste individuel « lourd » en privilégiant les CODECs matériel. Les logiciels du marché ne donnaient pas encore satisfaction en ce qui concerne l’interopérabilité avec les gatekeepers, ponts et passerelles. Aujourd’hui, la situation a changé et les WebCams sont accompagnées de logiciels qui tiennent la route.

La salle de réunion permet d’accueillir un groupe de 2 à 10 personnes. Nous avons souhaité pour cette configuration les modèles « set top box », c’est à dire un boîtier intégrant microphone et caméra, le tout se posant sur un moniteur de télévision. Ce boîtier peut accueillir un PC portable pour la connexion T.120, une caméra document et un magnétoscope.

7 SDA : Sélection Directe à l’Arrivée. L’opérateur transmet les 4 derniers chiffres du numéro composé pour que l’équipement aiguille lui-même l’appel.

8 CODEC : COdeur / DECodeur. Effectue la compression et décompression des flux audio et vidéo.

Un microprocesseur cadencé à 500 MHz est nécessaire pour effectuer les tâches d’un CODEC.

L’amphithéâtreaccueille une installation audiovisuelle lourde : vidéo-projecteur, deux caméras, moniteur de retour, table de mixage, enceintes, amplificateur et micros HF. Le système de visioconférence doit être basé sur un PC afin de servir de système local de projection de présentation et d’offrir une solution simple pour le partage applicatif.

Un réseau informatique à la norme IP permettant de faire circuler les flux de visioconférence en limitant la gigue, les délais de propagation, les collisions et les pertes de paquets.

Accessoires

Sur le marché, nous avons prévu les accessoires suivants :

• Tableau blanc interactif (permet de partager un tableau blanc de 2x2 mètres entre plusieurs sites)

• Banc titre (permet de transmettre un document, une radiographie, ou un petit objet)

• Magnétoscope Super VHS

• Sonorisation (table de mixage, ampli, enceintes)

• Vidéo-projecteur (avec ou sans optique de fond de salle)

• Caméra auxiliaire

• Moniteur auxiliaire

Les problèmes de qualité de service du réseau informatique

Introduction

Le réseau informatique doit être audité avant toute mise en place de matériel de visioconférence. L’absence d’un tel audit peut conduire à des échecs cuisants. A l’Université Paris Sud, nous avions fait un audit léger : Réseau commuté de bout en bout avec les liaisons WAN d’un minimum de 2 Mbps. Ces pré-requis n’ont pas suffit. La première liaison fut un échec en terme de qualité de service, le son était haché et l’image pixellisait. L’étude du trajet réalisé faisait apparaître deux problèmes majeurs :

• Un interconnexion de routeur à 10 Mbps

• Un problème de compatibilité Ethernet entre un routeur Cisco et un commutateur 3Com.

Il est donc nécessaire de définir les critères de qualité de service applicables à la visioconférence.

Calcul de la gigue et du délai de propagation

La gigue et le délai de propagation sont les deux éléments permettant de définir la qualité de service rendue par le réseau. Le délai de propagation est le temps aller-simple que met un paquet entre la machine source et la machine destination. La gigue est l’écart maximum entre le délai de propagation le plus court et le délai de propagation le plus long.

D’après les livres, le délai maximum de propagation des paquets doit être de 100 ms pour être dans les où l’être humain ne ressent aucune gène. Au delà, la distance se fait sentir et l’interactivité en pâtit. Dans le cas de liaisons européennes, un délai supérieur à 100 ms est problématique. Dans le cas d’une liaison avec les continents américains, on peut tolérer jusqu’à 200 ms. Les systèmes de visioconférence se mettent en erreur au dessus de 500 ms. Une traversée par satellite donne un délai d’environ 700 ms, des paramétrages spécifiques sont alors nécessaires.

La gigue est beaucoup plus visible sur les systèmes de visioconférence que le délai de propagation. Elle doit être inférieure à 30 ms quelques soient les systèmes en jeu.

L’utilitaire ping permet d’effectuer un premier niveau de test. Il permet de mettre en évidence les notoires. Certains essais concluants avec ce type de test n’ont pas donné lieu à des vidéoconférences de bonne qualité. Il est toujours nécessaire d’effectuer des tests avec des équipements de visioconférence qui affichent leurs statistiques de délai, de gigue et de perte.

Ce premier exemple montre la connexion avec l’Université de Nice Sophia Antipolis. Cette connexion possède un délai important pour un site hébergeant un NRD. Mais le pire se situe au niveau de la gigue (132.8-25.1=107.7ms). C’est inutilisable pour de la visioconférence.

[statadm@stat ~]$ ping -c 100 -s 790 ntic.unice.fr PING ad-ntic.unice.fr (134.59.53.83): 790 data bytes

798 bytes from 134.59.53.83: icmp_seq=0 ttl=56 time=34.6 ms 798 bytes from 134.59.53.83: icmp_seq=1 ttl=56 time=27.7 ms 798 bytes from 134.59.53.83: icmp_seq=2 ttl=56 time=33.1 ms […]798 bytes from 134.59.53.83: icmp_seq=97 ttl=56 time=110.6 ms 798 bytes from 134.59.53.83: icmp_seq=98 ttl=56 time=118.5 ms 798 bytes from 134.59.53.83: icmp_seq=99 ttl=56 time=120.1 ms

—- ad-ntic.unice.fr ping statistics —-

100 packets transmitted, 100 packets received, 0% packet loss round-trip min/avg/max = 25.1/62.4/132.8 ms

L’exemple suivant montre la connexion avec CALTECH (Los Angeles). Cette connexion possède un délai important (159.8 ms) mais avec une gigue faible (11.4 ms) et aucune perte. La visioconférence résultante a été de très bonne qualité. Le TTL⁹montre le nombre de routeurs traversés (256-233=23). Le test doit être fait à des heures différentes et avec un nombre de paquets supérieur à 100 et une taille de paquet de 790¹⁰octets.

[linux]$ ping -c 100 -s 790 gateway.astro.caltech.edu PING 131.215.102.1 (131.215.102.1): 790 data bytes

798 bytes from 131.215.102.1: icmp_seq=0 ttl=233 time=159.8 ms 798 bytes from 131.215.102.1: icmp_seq=1 ttl=233 time=160.4 ms […]

798 bytes from 131.215.102.1: icmp_seq=97 ttl=233 time=159.0 ms 798 bytes from 131.215.102.1: icmp_seq=98 ttl=233 time=159.6 ms 798 bytes from 131.215.102.1: icmp_seq=99 ttl=233 time=159.2 ms

—- 131.215.102.1 ping statistics —-

100 packets transmitted, 100 packets received, 0% packet loss round-trip min/avg/max = 158.6/159.8/170.0 ms

Problèmes rencontrés avec les interconnexions Ethernet 10 Mbps

Les liaisons Ethernet « classiques » fonctionnent suivant la règle CSMA/CD^11. C’est à dire qu’une trame RTP¹² devra attendre que le média soit libre avant d’être émise. Dans le cas d’une visioconférence à 384 Kbps, 64 trames sont émises par secondes avec une taille moyenne de 790 octets. Cela fait une trame toutes les 15 ms.

Ce trafic est perturbé par la réception du flux de l’équipement distant. Le média Ethernet est donc occupé avec un trafic de 768 Kbps en provenance de deux sources différentes. Il y a donc probabilité de collision.

Sur le réseau de l’Universite Paris Sud, l’interconnexion 10baseT du routeur Cisco 4000M bâtiment 510 débitait à 3 Mbps de flux continu. Les collisions étaient très fréquentes. Nous avons amélioré la situation en mettant deux interfaces à 10 Mbps en parallèles avec des poids OSPF¹³permettant d’en avoir une dédiée pour la réception et l’autre dédiée pour l’émission.

L’interconnexion 10 Mbps entre le routeur du Kremlin-Bicêtre et le Commutateur Ethernet 3Com LS1000 débitait environ 500 Kbps. Mais cette liaison présentait un défaut, il y avait des « late collision¹⁴ » sur le routeur. Le câble croisé (3m) a été changé sans succès. Il a fallu remplacer les 3Com LS1000 par des Catalyst Cisco.

Sur les routeurs, la qualité de service a été configurée afin de rendre prioritaires les trames des équipements de visioconférence.

9 TTL : Time To Live. Compteur inclus dans l’entête des paquets IP. Chaque traversée de routeur décrémente ce compteur. Le paquet est détruit si le TTL est à zéro. C’est une protection contre les bouclages de réseaux.

10La taille moyenne d’une trame de visioconférence est de 790 octets.

11 CSMA/CD : Carrier Sense Multiple Access / Carrier Detect. Le câble Ethernet est comme une fréquence radio. Une seule station peut émettre à la fois. Chaque station écoute le câble avant d’émettre. En cas d’émissions multiples, il y a brouillage. On parle alors de collision.

12RTP : Real Time Protocol. Protocole de communication pour les flux H.323. Fonctionne au dessus d’UDP.

Impact d’une collision

En cas de collision, les deux couches MAC¹⁵ émettent de nouveau leurs trames avec un délai d’attente aléatoire. Ces dernières sont déjà perdues pour les systèmes de visioconférence car elle sont en retard.

Résultat, les deux trames suivantes risquent elle aussi d’être en retard. Le système de visioconférence réagit à la perte en augmentant la profondeur du tampon anti-gigue. Cela peut être acceptable dans le cas d’un connexion entre une machine et un commutateur Ethernet. Dans le cas d’un hub, ou d’un coaxial, partagé par d’autres ordinateurs, la liaison visioconférence est inenvisageable.

Les collisions entraînent de la gigue et rendent la visioconférence inutilisable.

Réglages de la priorité sur les routeurs

Sur le routeur de sortie de l’Université Paris Sud, il est fréquent d’avoir quelques paquets en attentes dans les queues d’émission. L’absence de priorité des paquets de visioconférence entraîne de la gigue, voir de la perte, pour la liaison. Il est donc nécessaire de rendre prioritaires les paquets de visioconférence sur les routeurs et les commutateurs.

Voici la configuration d’un routeur connecté à des lignes de type Transfix : Version 11.3

!

hostname r510

!

interface Ethernet0

description Interface de reception

ip address 129.175.127.82 255.255.255.248 bandwidth 1024

no fair-queue

!

interface Ethernet1

description interface d’emission

ip address 129.175.127.98 255.255.255.248 bandwidth 10000

no fair-queue

!

interface Serial4

desription vers KB FH1

ip address 129.175.191.33 255.255.255.248 bandwidth 2048

priority-group 1

!

router ospf 1

network 129.175.127.80 0.0.0.7 area 0 network 129.175.127.96 0.0.0.7 area 0 network 129.175.191.32 0.0.0.7 area 0

!

! – ACL 90 : listes des adresses IP des systemes de visioconference — access-list 90 permit 129.175.132.0 0.0.0.255

access-list 90 permit 129.175.192.0 0.0.0.255 priority-list 1 protocol ip high list 90

! end

13OSPF : Open Short Path First. Protocole d’échange de table de routage basé sur des états de connexion. Converge rapi- dement et gère jusqu’à 4 chemins multiples vers une même destination.

14Late collision : Collision en retard par rapport à la propagation sur le câble. La trame n’est pas ré-émise contrairement à une collision classique. Ce type de collision indique une erreur de câblage ou d’ingénierie des équipements physiques.

15MAC : Medium Access Control, Microcode de la carte réseau.

Réseau actuel de l’Université Paris Sud

La nouvelle architecture du réseau de l’Université améliore nettement la situation pour la visioconférence.

Les coûts et la gestion de la facturation

Voici les tableaux de coût pour notre projet.

Coûts d’investissement

Coûts de fonctionnement

Temps passé

Pour l’envergure de ce projet, un demi-poste d’IE ou IR est nécessaire pendant 2 ans.

La publicité et la formation

• Dans le marché il est prévu une demie-journée de formation par site installé.

• Au mois de mai, une demie-journée d’information et démonstration pour une vingtaine de personnes.

La gestion de la facturation

Les services facturés sont exclusivement relatifs à des coûts de fonctionnement sur les équipements mutualisés. Les coûts d’investissement étant gérés par dotation budgétaire, ceux-ci ne sont pas pris en compte. Les coûts fixes sont répartis par moitié entre les télécommunications et l’entretien.

Les critères de facturation :

• Réservation de temps de communication sur pont et passerelle

• Communications téléphoniques : prix coûtant, prix avec ou sans marge d’exploitation.

• Réservation d’un numéro d’appel SDA (Sélection Directe à l’Arrivée)

Point de comparaison : Un abonnement Numéris de Base nécessaire pour une communication sur 2 canaux coûte 2500 Francs H.T. par an

La non facturation du pont est, à mon avis, une politique à conserver. Elle apporte plusieurs avantages :

• pas de coût de gestion de facturation (nationale et internationale)

• pas de frein psychologique au développement de la visioconférence multipoint.

En ce qui concerne les ressources “passerelle”, la politique d’utilisation est plus compliquée car elle implique des coûts fixes de télécommunication : location de canaux RNIS et location de numéros de téléphone SDA (Sélection Directe à l’Arrivée).

Deux méthodes peuvent être utilisées pour gérer la passerelle :

1.Interdiction d’appel sortant : l’utilisateur enregistré peut recevoir des appels H.320 mais ne peut pas en émettre.

Il reste alors les coûts fixes. Deux sous-variantes : Attribution d’un numéro SDA ou d’une ligne indirecte.

2.Autorisation d’appel sortant : il faut alors mettre en place une facturation de la ligne. Le rythme de facturation ne doit pas être trop élevé (tous les ans, tous les 6 mois). Le système de réservation doit permettre de conserver les coûts téléphoniques liés à un système de visioconférence. Le compte téléphonique doit être consultable facilement par l’utilisateur et il doit comporter un seuil d’alerte au delà duquel les responsables financiers de la salle recevrons une demande d’augmentation de crédit.

La première méthode s’appliquera à tous les systèmes extérieurs à l’établissement, ce qui évite de gérer des conventions.

Pour les systèmes à l’intérieur de l’établissement, il peut être nécessaire d’autoriser les appels sortants pour les systèmes uniquement H.323.

Annuaire et système de réservation

Le besoin

Trois individus souhaitent se réunir en vidéoconférence. Ils sont tous les trois dans une région différente. La durée prévue de la réunion est de 2 heures. Le premier participant possède un système H.320 (Venu 2000, par exemple). Le deuxième possède une ViewStation de Polycom connectée avec une prise RNIS à 128 K et une prise réseau sur Internet avec 100baseT. Le dernier possède un Kit PC PictureTel 550 avec uni- quement une prise réseau 100baseT.

La conférence nécessite 5 ressources : les 3 salles, un pont, une passerelle

Pour les salles, la réservation peut se faire localement via un secrétariat. Par contre pour le pont et la passerelle, il faut s’assurer du nombre de canaux de communication disponibles. L’utilisation d’un mécanisme de réservation manuel devient très fastidieuse dès lors qu’il y a plusieurs vidéoconférences par semaine.

Pour établir correctement cette visioconférence, les parties ont besoin d’avoir les informations techniques des autres parties. Ces informations comportent l’adresse d’appel (numéro IP, alias ou numéro de téléphone), le débit maximum utilisable, la possibilité d’avoir du partage applicatif, le numéro de téléphone du poste téléphonique de service (poste téléphonique “normal” présent dans la salle de visioconférence). Toutes ces informations devraient être disponibles dans un annuaire.

Un exemple : DCS¹⁶

La communauté de la physique des particules (IN2P3¹⁷) et le DOE (Department of Energy) américain utilisent depuis plus de 5 ans la vidéoconférence de manière hebdomadaire. Ces vidéoconférences utilisent la technologie H.320 (RNIS) avec un pont Accor basé à Berkeley. Ce pont a été acheté par la communauté La politique d’utilisation de ce pont implique la participation d’au moins une salle américaine, en contrepartie, l’utilisation des ressources du pont n’est pas facturée. DCS est un système de réservation de ressources centré autour du pont. Il possède un annuaire des salles participantes. Il gère la réservation d’une centaine de salles et des canaux de communication sur le pont. Il communique par e-mail les réservations aux différentes parties et programme le pont.

Ce système est bien pratique mais cependant limité :

• il ne gère qu’une seule ressource de type MCU¹⁸H.320

• il n’a aucune notion de H.323 et de T.120 Spécification d’un annuaire

L’annuaire des ressources de vidéoconférence doit avoir les caractéristiques suivantes :

• recenser les terminaux avec leurs paramètres et leurs conditions d’utilisation

• recenser les ponts et les passerelles

• recenser les gatekeepers

• recenser les contacts techniques

• recenser les contacts administratifs

Quelles sont les nécessités d’interconnexion de cet annuaire ?

• lié à un système de réservation

• lié à d’autres annuaires de vidéoconférence

• lié à des annuaires d’établissement Réalisation par le CRU dans l’annuaire ARES.

Spécification d’un système de réservation

Voici les différentes règles de gestion que nous avons posées lors de la phase d’analyse.

• Possibilité de réserver des conférences point à point et multipoint.

• Avertissement des participants : 24 h avant, 15 j avant, au moment de la réservation

• Gestion des ressources pont et passerelle.

• Granularité des réservations : une demie-heure maximum

• Gestion des utilisateurs : droit de poser une réservation sur des salles d’attachement.

• Réservation locale ou de groupe sans utilisation de pont.

• Multilingue

• Gestion des fuseaux horaires

16DCS : Digital Collaboration Services géré par ESNet : Energie Sciences Network. http://dcs.es.net/

17IN2P3 : Institut National de Physique Nucléaire et de Physique des Particules

18MCU : Multipoint Control Unit. C’est le terme anglais pour un pont H.323.

Développement d’un système de réservation

Nous avons eu la possibilité, fin juin, d’embaucher un stagiaire pendant les mois de juillet et août. Nous avons donc proposé au CRU le développement d’une première mouture d’un système de réservation.

La plate-forme de développement choisi est Apache¹⁹, PHP4²⁰et MySQL²¹sous Linux.

Pour le développement, vu le temps imparti, nous avons fait les restrictions suivantes : pas de gestion multilingue, pas de gestion des fuseaux horaires, pas d’effort particulier sur la présentation du site (reprise de la charte graphique du CRU).

L’accès au système de réservation se fait en mode connecté (login + password). Un formulaire permet d’obtenir un compte utilisateur, le mot de passe est envoyé à l’adresse mail indiquée. Un compte utilisateur permet de réserver des salles et de modifier la réservation au cours du temps. Un compte administrateur permet de créer, modifier, supprimer des salles. Il permet aussi d’ajouter les ressources pont et passerelle à une réservation.

Les notifications sont envoyées par courrier électronique au moment de la réservation.

Plan de numérotation et interopérabilité de Gatekeepers

Problématique

Les ressources pont et passerelle fonctionnent uniquement avec un gatekeeper. Les systèmes voulant communiquer avec l’extérieur en RNIS ou utiliser la visioconférence multipoint doivent donc être référencés par un gatekeeper.

Problème : utilisation du pont RENATER par un système de l’Université Paris Sud

Le pont EZENIA de RENATER doit connaître l’adresse IP du système appelant et de plus référencer un compte valide. Le pont EZENIA intègre son propre gatekeeper. Pour les systèmes de l’Université, il faut alors changer de gatekeeper pour utiliser le pont RENATER. C’est faisable à titre expérimental mais cela ne peut pas être une solution de production.

Un réseau de gatekeeper

Nous avons, dans le groupe visio, 5 gatekeepers pour expérimenter. Après plusieurs tâtonnements, nous avons réussi à faire fonctionner les équipements Cisco entre eux (IPVC et MCM). Les détails de configuration seront disponibles sur le site Web du CRU.

Nous n’avons pas encore réglé tous les problèmes liés à la sécurité : filtrage sur les routeurs, configuration figée des gatekeepers… Nous avons, par contre, défini un plan de numérotation permettant d’appeler les systèmes.

Plan de numérotation

Sur chaque gatekeeper, le code de sortie de zone est le « 0 ». Tous les gatekeepers possèdent des numéros à 5 chiffres issus du numéro de téléphone de l’établissement ou de la ligne reliée à la passerelle. Tous les systèmes possèdent un numéro à 4 chiffres.

Exemple : pour appeler mon poste personnel depuis l’intérieur de l’Université, je compose le 8013. Pour appeler ce même poste depuis un site partenaire, je compose le 0164868013. Mon système possède le même numéro d’appel en RNIS ou en ALIAS H.323. Sur mon équipement, il suffit juste de sélectionner le bon réseau de sortie RNIS ou IP.

19Apache : Serveur HTTP du domaine public.

20PHP4 : Langage interprété permettant d’interroger facilement une base de données et de générer du code

Conclusion

Les utilisations

A l’IUT de Cachanun certain nombre de stagiaires partent à l’étranger. La soutenance de stage était faite deux fois, une fois sur le lieu du stage avec les responsables de l’entreprise dans la langue du pays et une fois à l’IUT.

Le système de visioconférence permettrait d’économiser le déplacement du stagiaire et de lui « rendre visite » plus souvent.

A l’UFR de Médecine, la visioconférence permet l’intervention en amphithéâtre d’un spécialiste étranger.

A l’UFR de Droit et Sciences Economique : La visioconférence entre dans le projet CANEGE (Campus Numérique en Economie et Gestion, http://www.canege.org). Le but est de réunir sur les sites concernés les étudiants pour des cours en visioconférence. Les établissement partenaires sont : Paris-Dauphine, Pierre Mendès-France Grenoble 2, Nancy 3, Nice Sophia-Antipolis, Paris I Panthéon-Sorbonne, CNED et France-Télécom.

A l’UFR de Sciences, la visioconférence à été utilisée pour un colloque sur l’enseignement de l’optique en duplex avec Lannion, pour le projet Campus Numérique et pour l’institut d’astrophysique spatiale.

Prospectives

La base des systèmes installés est de plus de 300 000 unités en l’an 2000 et le marché de la visioconférence est en forte progression. Il est maintenant nécessaire d’acheter des systèmes mixtes ou des systèmes pur H.323 afin de suivre l’évolution technologique. La qualité de service dans les réseaux (site, régionaux, nationaux, internationaux) est à améliorer ou à mettre en place à tous les niveaux. Les investissements fait sur la qualité de service serviront au déploiement de la téléphonie sur IP. L’arrivée massive de WebCam dans les bureaux va nous pousser à organiser la sécurité de cette nébuleuse en formation...

Bibliographie et liens

• Les laboratoires multimédias, CNDP-DIE, septembre 1998

• WC Wizard Merlin, AC&E limited, juillet 2000

• DCS http://dcs.es.net/

• CRU http://www.cru.fr/

• VCON http://www.vcon.com/

• PictureTel : http://www.picturetel.com/

• La visioconférence : usages, stratégies, moyens, Gemme,http://gemme.univ-lyon1.fr/, juin 2000

• Présentation interne de la visioconférence, CRI Université Paris Sud, 31 mai 2001

• Visioconférence : les échanges multimédias en multipoint, CNDP-DIE, NT39, 6 juillet 1998

• Tout savoir sur la visioconférence Sony,

• CCTP Visioconférence, CRI Université Paris Sud, 22 mai 2000