Visio-Conférence

La DRI déploie techniquement une solution de visio-conférence basée sur du matériel Polycom VSX7800, VSX7000 et V500 à la demande du Programme 4 en appui aux projets de FOAD.

Polycom vient de sortir un nouveau modèle, le VSX5000 qui est plus "léger" que le 7000 tout en étant plus performant que le V500. Par ailleurs le VSX7000 est désormais en deux versions : VSX7000s avec caméra intégrée ou VSX7000e avec caméra séparée. Etude et cotations en cours (par ThomasNoel) Apparement le VSX5000 est disponible aux environs de 3000€ HT --TN

Documentations Polycom

Le site de base : http://www.polycom.com/ . Ce site est très lent car il possède apparement une limite de 4 connexions par client !... Toute la documentation pour tous leurs matériels de visio est là : http://www.polycom.com/resource_center/1,1454,pw-26-483,FF.html

Note : Je (Thomas) trouve les traductions françaises des documentations de qualité moyenne, préférez les versions anglaises si vous êtes à l'aise avec cette langue.

Documentation pour le V500 :

• http://www.polycom.com/resource_center/1,1454,pw-26-483-6575,FF.html

• Cliquez sur "Other Language documentation" pour les versions françaises

Documentation pour le VSX7000 :

• http://www.polycom.com/resource_center/1,1454,pw-26-483-4363,FF.html

• Cliquez sur "Other Language documentation" pour les versions françaises

Documentation pour le VSX7800 :

• http://www.polycom.com/resource_center/1,1454,pw-26-483-7054,FF.html

• Cliquez sur "Other Language documentation" pour les versions françaises
• NB : la plupart des docs sont identiques à celles du VSX7000. Le VSX7800 est un effet un VSX7000 avec quelques extensions supplémentaires :
  • o multi-point : extension logicielle permettant de se connecter à 3 sites en même temps o Visual Concert : boitier d'extension qui permet d'envoyer des images sorties d'un PC (VGA) o second écran : un adaptateur qui permet de brancher un écran informatique (VGA) pour recevoir en qualité VGA les infos d'un visual concert o des enceintes acoustiques

Installation

Pour des premiers tests, placez votre système sur une IP routable non filtrée. Cela évitera les soucis de réseau, le protocole h323 utilisant des ports dynamiques cela passe très mal les pare-feux.

Plus tard vous pourrez configurer un gatekeeper sur une machine reliée à la DMZ et au(x) réseau(x) privés afin de pouvoir placer votre système n'importe où dans votre réseau.

Utilisation d'un gatekeeper

Un gatekeeper est un logiciel qui se place sur une machine ayant une patte en IP publique et une autre en IP privée (voir les discussions plus bas). Un gatekeeper ainsi installé permet de gérer les accès à autant de systèmes que vous le désirez sur votre réseau local, et permet réciproquement aux visios du réseau local d'accéder aux visios sur Internet (ou sur d'autres gatekeeper...).

Sur Debian Sarge on trouve gnugk (GNU GateKeeper?) qui fait partie de la suite OpenH323?, donc est basé sur le protocole H323. Il semble qu'un autre protocole émerge actuellement : SIP. C'est peut-être par là qu'il faudra aussi creuser, même si avoir un gatekeeper H323 reste la solution la plus interropérable pour l'instant.

Des tests de gnugk ont déjà été effectués à Dakar et à Paris avec succès (gnugk sur une Debian Sarge dans les deux cas). Contactez ThomasNoel ou JeromeSantini pour plus d'info.

Note sur l'installation de gnugk (à détailler plus tard) : mettre CallSignalPort=1720 au lieu de 1721 par défaut...

pour le moment, je (Jérôme) laisse tomber gnugk pour repasser en ip publiques + bricolages. trop de problèmes 'bizarres' avec gnugk

Même chose à Paris (Jeff+TN), gnugk ne gère pas tout à 100%, par exemple le forwarding de connexion, des trucs comme ça... abandon, Paris passe ses visio en ip publiques

Autres systèmes de visio

Les développeurs de Videolan (http://www.videolan.org) travaillent actuellement à des extensions pour faire de la visio. Cependant il est clair que même avec des pentium 4 très puissants il sera difficile de transmettre des images plus grosses que des timbres postes... les algorithmes de compression type MPEG4 (h.264 & compagnie) sont très complexes.

Pour de la visio "compatible Netmeeting" sur Linux : Gnomemeeting. Note : Gnomemeeting ne semble pas super compatible avec les Polycom (affichage par gros blocs, problème de codec ? A vérifier après upgrade des Polycom en 7.5).

Pour tout ce qui est h323, notamment les systèmes permettant de faire du "netmeeting multipoint" ou les gatekeeper, allez voir du coté de OpenH323 : http://www.openh323.org/

Enfin, l'avenir semble clairement plus du coté de SIP que de h323. Mais des clients audio+video SIP qui fonctionnent vraiment, pour l'instant on n'en a pas trouvé.

Annexes

Liens

Un bouquin qui fait le point sur les techniques de téléphonie IP, qui incluent en fait tout ce qui est visio. Vous y trouverez une description des protocoles et des systèmes mis en jeu. C'est bien détaillé et très technique. http://www.terena.nl/library/IPTELEPHONYCOOKBOOK/contents1.html

nstallation d'une machine en IP publique dans un réseau privé

L'idée est de pouvoir installer le système de visio sur n'importe quelle prise du réseau privée (192.168.x.x ou même 10.x.x.x) sans avoir à ajouter de gatekeeper un peu complexe.

Si vous avez à votre disposition des adresses ip publiques, voici ce que nous avons fait à Ouagadougou: - Sur le pare-feu, ouverture complète pour l'ip publique de la visio (FORWARD destination et source). - Sur le serveur, on ajoute une interface virtuelle (eth1:1) pour la patte interne (192.168.x.x ou 10.x.x.x) sur une seconde ip publique qui servira de passerelle (212.52.136.13 à Ouaga) à la visio. - Puis on utilise un publication ARP (Adress Resolution Protocol) afin que la patte publique du serveur reçoive les paquets pour le système de visio, comme ceci : arp -Ds -i eth0 212.52.136.14 eth0 pub - On peut vérifier avec cette commande que tout va bien: arp -an | grep 212.52.136.14 On obtient quelque chose comme: ? (212.52.136.14) at * PERM PUP on eth0 - Sur le matériel de visio, on configure l'ip publique (212.52.136.14) ainsi que la passerelle publique (212.52.136.13) - On peut vérifier que ce soit sur le serveur ou le pare feu qu'on arrive bien à pinguer le système de visio. Si tout est ok, on ajoute la publication ARP dans le fichier /etc/network/interfaces afin de ne pas retaper les commandes à chaque redémarrage (coupure de courant). Faire un test, ca fonctionne. -- MatthieuSchneider

Attention : cela rend également votre réseau interne sensible au moindre bogue sur le polycom, qui est un système propriétaire... et pour peu que le polycom soit sur le RPV, cela pourrait également ouvrir une brèche vers le RPV entier. -- ProgFou

Discussions

Choix de la machine sur laquelle installer le gatekeeper

• exemple : le firewall, mais pour les tests mieux vaut installer une machine en parallèle -- TN
• même en production, vu la complexité du soft, je ne crois pas que le coller sur le firewall soit une bonne idée -- J.

• je suis d'accord avec J. sur le plan sécurité, cependant, dans des petites implantations, la multiplication des passerelles n'est pas non plus une solution ; ce logiciel peut-il tourner en chroot/setuid ? -- ProgFou

• ce soft fait essentiellement des accés réseau. il tourne par défaut sous un user "gnugk" dans la version Debian. Je crois que ça ne devrait pas être difficile de le lancer dans un chroot. Mais pourquoi sur une passerelle forcement ? Le choix que j'ai fait à Dakar est de l'installer sur la DMZ, et de désactiver le NAT pour le port/machine correspondant. Je trouve plus logique de lancer les services sur les serveurs que sur les routeurs (mais je reconnais qu'on pourrait avoir l'argument inverse, en disant que gnugk fait du routage d'appels) -- J.
• la problématique technique est : comment le faire tourner dans des implantations n'ayant qu'une seule IP avec des serveurs en DNAT ? Si on met gnugk sur la passerelle, c'est bon. Mais sinon, est-ce que ça peut tourner sur une machine en DNAT ? Connaisssant h323, j'en suis pas sûr du tout... -- TN

• faire passer gnugk derrière du DNAT nécessiterait d'installer un module ip_nat_h323, ce qui enlèverait alors une grande partie de l'intérêt d'utiliser gnugk, ÀMHA. -- ProgFou

• la réponse est donc assez claire pour les sites à une seule IP publique (ou à petit nombre d'IP publiques). En revanche, pour les autres, le choix reste possible... tout en sachant que pour l'instant gnugk ne tourne pas sur une Woody (pas de backport existant, compilation délirante) -- TN

A propos de l'Installation d'une machine en IP publique dans un réseau privé

• Attention : cela rend également votre réseau interne sensible au moindre bogue sur le polycom, qui est un système propriétaire... et pour peu que le polycom soit sur le RPV, cela pourrait également ouvrir une brèche vers le RPV entier. -- ProgFou

• Est ce qu'en tapant: $arp -Ds -i eth0 212.52.136.14 eth0 juste après utilisation de la visio cela règle le problème? Visio éteinte, l'ip n'est pas utilisable, car réservée et non publiable/public (?) comme j'ai pu voir avec jérôme... Ainsi on active la visio et on réserve son ip lorsqu'elle n'est pas utilisé, personne ne peut dans ce cas prendre cette identité par la suite. -- MatthieuSchneider

• Oui, déconfigurer le bricolage aprés chaque utilisation limiterait le probléme (mais augmente le risque de fausses manip'). La situation actuelle est peu satisfaisante, mais temporaire : je prefererai plutôt qu'on passe rapidement vers un gatekeeper. Je suis en train de regarder si openh323gk, package woody, ne ferait pas l'affaire en attendant sarge. -- J.