Skip to content

WebRTC

WebRTC Digest – Week of 6/3 – IE, Hype, and Security

WebRTC dans IE ?

A article de blog et certains tweets Les propos tenus lors d'une conférence pour développeurs Microsoft semblaient indiquer que Microsoft progressait sur WebRTC dans IE (du moins dans le contexte de Exécution de Lync sans pluginIl ne semble pas y avoir de détails concernant la version de CU-WebRTC ou la version standard. WebRTC, ou quelque chose de complètement différent.

Hype Recheck

Cisco a continué de republier l'article de la semaine dernière intitulé “ La réalité de WebRTC… Simple effet de mode ? ” plusieurs À plusieurs reprises, Tsahi Levent-Levi a publié une réponse déclarant :

WebRTC est la technologie la plus disruptive dans le domaine de la VoIP à ce jour. Non pas parce qu'elle repose sur une nouvelle technologie, mais parce qu'elle permet la mise en œuvre de nouveaux cas d'utilisation.

Sécurité et WebRTC

Actualités récentes a suscité un débat sur la sécurité et la confidentialité de WebRTC. Justin Uberti, responsable de l'équipe Chrome WebRTC a partagé une publication, écrit par Adam Roach, employé de Mozilla, qui offre un bon aperçu des problèmes : “WebRTC : Sécurité et confidentialité”Cullen Jennings, employé de Cisco et coprésident de RTCWeb, a été l'un des nombreux contributeurs à un rapport récemment rédigé soulignant les dangers de l'ajout points d'écoute téléphonique aux services Internet.

Tunneling WebRTC over TCP (and why it matters)

Il y a quelques semaines, nous avons discrètement activé la prise en charge du tunneling TCP bilatéral dans le cloud vLine, devenant ainsi les premiers fournisseur d'infrastructure WebRTC pour permettre la connexion à travers les pare-feu bloquant le protocole UDP. Cela peut paraître anodin, mais c'est ce qui fait toute la différence entre un service qui “ se connecte généralement ” et un service qui “ fonctionne tout simplement ”. Explications :

L'un des nombreux avantages de WebRTC est sa relative simplicité de prise en main. Il suffit de lancer une instance de apprtc Pour le backend de signalisation, copiez-collez du JavaScript, et voilà, vous pouvez passer des appels vidéo dans votre application (en réalité, c'est un peu plus compliqué que cela, mais un bon développeur web peut facilement mettre en place une démonstration de chat vidéo en un jour ou deux).

Malheureusement, le passage de la démo à un service opérationnel peut s'avérer plus complexe (et plus coûteux !) que prévu. Voici comment cela se déroule généralement : 

Niveau 1 : Étourdissement

Vous commencez par passer vos premiers appels sur un réseau local, et tout fonctionne à merveille. Hourra ! Ensuite, vous essayez d'appeler quelqu'un en dehors de votre pare-feu, et deux choses peuvent se produire.

1) Si vous avez copié-collé par erreur l'adresse du serveur STUN de Google depuis le code source d'apprtc, votre appel aboutira et vous serez ravi (même si vous pourriez avoir quelques doutes quant à la pertinence d'utiliser un service non documenté pour lequel Google n'a pas explicitement autorisé les développeurs tiers). Notez le silence de Google à ce sujet. ce fil de discussion).

2) Si vous n'avez pas configuré de serveur STUN, votre appel échouera. Une petite recherche vous montrera que STUN est un protocole Le navigateur utilise cette adresse pour déterminer son adresse IP publique et tenter de contourner le pare-feu. Par conséquent, pour se connecter malgré un pare-feu, un serveur STUN est nécessaire. Quelques heures plus tard, votre serveur open source est opérationnel sur EC2. Une petite instance suffit amplement (1 TP42T43,92 par mois), mais il est conseillé d'en exécuter au moins deux pour garantir la disponibilité, de préférence dans des régions différentes (comptez alors 1 TP42T87,84 par mois).

Niveau 2 : TOUR

Vous effectuez quelques appels tests supplémentaires, et ils fonctionnent tous. Tout semble bien se dérouler. Puis vous tentez d'établir un appel entre deux réseaux d'entreprise, et là, ça ne marche pas. Grrr. Pendant vos recherches sur STUN, vous avez lu… un autre protocole appelé TURN Ce protocole sert à relayer les données lorsque le navigateur ne parvient pas à établir une connexion directe. Vous n'étiez pas certain de son utilité, mais des recherches complémentaires indiquent que STUN ne suffit que pour environ 801 041 téléphones. Si cela ne vous suffit pas (et c'est probablement le cas), vous aurez besoin d'un serveur TURN.

Quelques fils de discussion de la liste de diffusion Plus tard, vous aurez un serveur TURN opérationnel sur votre instance EC2. En réalité, le débit réseau sur une petite instance peut être assez imprévisible si d'autres utilisateurs partagent votre interface réseau. Il est donc conseillé d'opter pour une instance plus puissante. Une instance moyenne ($87,84 par mois) convient parfaitement, mais pour une prévisibilité optimale et une gigue minimale, il vous faudra une instance extra-large ($351,36 par mois), qui vous offrira…“performances réseau élevées”En fait, il s'agit plutôt de deux ($703.52 par mois), pour des raisons de disponibilité.

Bien sûr, puisque vous diffusez de la vidéo, vous devrez également prendre en compte les coûts de bande passante. Le prix de base d'EC2 est de : $0,12 par Go. Pendant que vous faites vos calculs, vous vous demandez peut-être ce qui empêche quelqu'un d'autre d'utiliser ce serveur public que vous venez de configurer et de faire exploser votre facture de bande passante. Voici une bonne explication. fil de discussion de la liste de diffusion À ce sujet. En résumé : il n’existe pas de solution idéale pour empêcher cela étant donné le fonctionnement du protocole TURN et le fait que les identifiants TURN doivent être présents dans votre code JavaScript, où n’importe qui peut les trouver.

Mais ne nous attardons pas sur les détails financiers. Vous pouvez désormais appeler vos amis travaillant dans d'autres entreprises technologiques. Génial ! Puis vous essayez d'appeler quelqu'un dans une grande entreprise traditionnelle, et ça ne marche pas. Zut ! Vous pensiez que TURN avait pensé à tout.

Vingt minutes plus tard, après quelques recherches supplémentaires, vous découvrez que l'implémentation d'allocation TURN de Chrome ne prend en charge que le relais des paquets UDP. Chrome 28 ajoutera la prise en charge de allouer Un serveur TURN utilise TCP, mais les paquets seront toujours relayés via UDP. Zut ! Cela ne résout toujours pas votre problème lorsque le pare-feu bloque le trafic UDP. 

Niveau 3 : Nuage vLine

C'est là que notre nouvelle prise en charge du tunneling TCP entre en jeu. Elle ne dépend pas de l'implémentation TURN de Chrome et fonctionne donc dès aujourd'hui. De plus, elle fonctionne même si les deux parties sont protégées par des pare-feu bloquant le protocole UDP. Il suffit d'un accès à Internet via le port 443 (le port HTTPS), autorisé par la grande majorité des pare-feu.

Vous n'avez rien de particulier à faire pour activer le tunneling TCP dans votre service vLine. Utilisez simplement vline.js pour créer votre application, et nous nous connecterons en utilisant la meilleure méthode disponible pour chaque appel. Nous exécutons un réseau mondial de serveurs à haute disponibilité, Nous garantissons ainsi la meilleure qualité d'appel possible à tous vos utilisateurs, partout dans le monde, même derrière des pare-feu bloquant tout trafic autre que TCP sur le port HTTPS. Pour information, nous utilisons toujours le protocole DTLS de bout en bout : nos serveurs n'ont donc jamais accès à vos flux multimédias non chiffrés.

Notre objectif est un taux de connexion de 100%. Si vous rencontrez des problèmes de connexion sur votre réseau, veuillez nous contacter. Faites-nous savoir.

Note 1 : Si vous souhaitez tester cela vous-même en bloquant UDP sur votre pare-feu, n'oubliez pas de laisser le port DNS (53) ouvert.

Note 2 : Certains pare-feu ultra-restrictifs effectuant une inspection dynamique des paquets peuvent bloquer les connexions car, même si le navigateur utilise le port HTTPS, il n’établit pas de connexion SSL/TLS (nous n’avons jamais rencontré de pare-feu de ce type en conditions réelles, mais ils existent). Chrome prendra bientôt en charge les connexions WebRTC via TLS ; nous pourrons alors également contourner ces pare-feu.

WebRTC + Chromebox = Système de téléprésence HD $400

WebRTC Digest – Week of 5/27 – Flow Charts, FUD, and T-Shirts

Les explications détaillées et pertinentes de WebRTC restent rares. Heureusement, Anant Narayanan de Firebase (et auparavant l'équipe WebRTC de Mozilla) a apporté une contribution importante au panel de présentations la semaine dernière avec son exposé intitulé « Introduction pratique à WebRTC » lors de la conférence Fluent.

N'oubliez pas de consulter les diapositives pour obtenir l'ensemble le plus complet de schémas de signalisation WebRTC disponibles sur le Web (utilisez la flèche vers le bas sur diapositive 7Sérieusement. Si vous voulez comprendre ce qui se passe en coulisses lorsque vous cliquez sur “ Démarrer l'appel ” dans une application WebRTC, vous devez consulter les organigrammes. On vous attend.

FUDdy-duddy

WebRTC était au cœur des préoccupations chez No Jitter la semaine dernière, avec pas moins de trois articles consacrés au sujet. Irwin Lazar Nemertes Research a débuté par un article positif intitulé WebRTC : Pourquoi les entreprises devraient-elles s’y intéresser ?

L'une des possibilités les plus intéressantes est peut-être celle d'intégrer directement des applications voix/vidéo aux interfaces web des applications CRM ou ERP. […] Imaginez une équipe de personnes travaillant toute la journée dans une application de gestion des processus métier et pouvant communiquer par chat, appel ou visioconférence. […] Là encore, les possibilités sont infinies pour les développeurs d'applications afin d'étendre les communications et la collaboration à tous les environnements.

Puis Laurent Philonenko, vice-président et directeur général de l'unité commerciale Clients et Mobilité de Cisco, a douché les espoirs placés en WebRTC avec son article intitulé « La réalité de WebRTC… Tout du battage médiatique ? »

WebRTC n'est pas encore tout à fait prêt pour une utilisation à grande échelle. En clair, les normes ne sont pas finalisées. Supposons que la finalisation des normes WebRTC prenne encore un an, et qu'il faille six mois à Chrome et Firefox pour proposer un navigateur intégrant ces normes ; il faut également ajouter le temps nécessaire aux utilisateurs pour mettre à jour leurs navigateurs. Nous verrons des implémentations préliminaires d'ici là, mais je dirais qu'il faudra au moins deux ans avant que cette technologie ne soit largement déployée sur le marché.

Dave Michels a conclu avec un petit bilan de WebRTC, expliquant gentiment qu'il n'y a rien à voir et que vous devriez passer votre chemin.

WebRTC n'est pas une technologie de rupture. […] WebRTC n'offre ni nouvelles fonctionnalités, ni économies significatives par rapport aux autres technologies peer-to-peer. On pourrait décrire plus justement WebRTC comme une technologie évolutive, qui apporte concrètement des fonctionnalités en temps réel au navigateur, remplaçant ainsi le recours à des plugins et téléchargements ponctuels.

Pour l'instant, nous préférons ne rien dévoiler, mais vous en saurez plus à ce sujet ici, sur le blog vLine. En attendant, nous finalisons le design de notre nouvelle gamme de t-shirts “ WebRTC est prêt ”.

Sérieusement. Écrivez-nous si vous en voulez un.

GitTogether: Video Chat for GitHub (powered by WebRTC)

en bref

  1. Allez à se réunir et connectez-vous avec GitHub.
  2. Consultez la liste des personnes que vous suivez sur GitHub, ainsi que les membres de vos équipes et organisations, dans vos contacts.
  3. Si les personnes avec lesquelles vous souhaitez discuter ne sont pas en ligne ou ne figurent pas dans votre liste de contacts, envoyez-leur votre URL GitTogether (gittogether GitHub).
  4. Discutez sans modération !

Arrière-plan

Il est difficile de savoir si votre plateforme est performante tant que vous ne l'avez pas utilisée pour créer une véritable application, de préférence une application que vous utilisez vous-même au quotidien. C'est pourquoi, lorsque nous avons commencé à développer… Plateforme vLine et l'API il y a deux ans, nous avons également commencé à développer une application par-dessus.

Comme nos vies sont essentiellement tournées vers GitHub, nous avons décidé de créer un outil de communication qui en fasse autant. Nous l'avons appelé GitTogether, nous l'avons doté d'une connexion GitHub et nous avons alimenté la liste de contacts avec les personnes que vous suivez ou avec lesquelles vous travaillez sur GitHub.

Aujourd'hui, nous disposons d'une application performante que nous utilisons en interne comme principal outil de communication depuis plus d'un an. Notre objectif principal étant d'apprendre de notre expérience de développement et d'utilisation, nous ne l'avons pas beaucoup diffusée. Cependant, suffisamment de personnes l'ont découverte et trouvée utile pour que nous décidions de lui consacrer enfin un peu plus de temps.

Au cours des prochaines semaines, nous publierons une série d'articles de blog expliquant son fonctionnement interne, les enseignements tirés de son développement et comment créer des applications aux fonctionnalités similaires. En attendant, bonne lecture !

WebRTC Digest – Week of 5/20 – Chrome 27, Temporal Scalability & Hardware Acceleration

Chrome 27

Chrome 27 était sortie officielle. UN liste des modifications liées à WebRTC est disponible sur la liste de diffusion discuss-webrtc. L'un des changements les plus visibles pour l'utilisateur final est la possibilité de Sélectionnez la caméra et le microphone. depuis l“” Omnibox » plutôt que de fouiller dans les paramètres de Chrome.

Évolutivité temporelle

Il y avait un discussion intéressante Sur la liste de diffusion, une discussion portait sur la scalabilité temporelle et sur la possibilité d'exposer des commandes pour celle-ci dans WebRTC via SDP, notamment pour une utilisation avec la visioconférence/le mixage. La scalabilité temporelle est une méthode d'encodage d'un flux vidéo dans un format permettant de le décoder à plusieurs fréquences d'images (par exemple, 30 FPS ou 15 FPS) au prix d'une surcharge d'encodage accrue. Blog LifeSize fournit une description intéressante dans le contexte du codec H264, et la liste de diffusion WebM propose une description technique plus détaillée. Comment cela fonctionne-t-il dans VP8 ?.

Accélération matérielle

L'accélération matérielle VP8 est de plus en plus prise en charge par les plateformes, comme le démontre nVidia avec cette démonstration de visioconférence 1080p à 30 images par seconde sur Tegra 4. Le Tegra 4 intégrera une prise en charge matérielle de l'encodage et du décodage VP8, avec pour objectif affiché :

Offrir la meilleure expérience WebRTC sur Android, Chrome OS et Google TV.

WebRTC Digest – Week of 5/13 – BB10, Firefox 22 & Google IO

WebRTC sur Blackberry 10

Nos amis de Crochet La semaine a débuté par l'annonce de la prise en charge de WebRTC sur Blackberry 10. Erik Lagerway a ensuite… sur webrtc-discuss:

Je voulais simplement vous informer que nous avons terminé le portage intégral de la pile multimédia WebRTC de Google vers QNX / Blackberry 10. Actuellement disponible dans notre dépôt GitHub Open Peer, nous prévoyons de la réintégrer à Google, si ce dernier l'accepte.

Justin Uberti, responsable technique de WebRTC, a salué cette nouvelle et a défini les règles de base pour les ports ajoutés :

Erik, merci de nous avoir prévenus. C'est toujours un plaisir de voir quelqu'un contribuer à l'expansion de l'écosystème WebRTC !

Si le portage respecte nos directives de style et nos pratiques pour le code spécifique à chaque plateforme, nous pouvons vous aider à le finaliser. Seul bémol : nous ne pourrons pas assurer un support complet via nos robots de test. En cas d'échec de la compilation, il vous incombera de le corriger.

Firefox 22 Hits Beta

Mardi, Firefox 21 a été libéré, Il ne reste donc plus qu'une version avant que WebRTC ne soit activé par défaut. La sortie de Firefox 22 est actuellement prévue pour le 24 juin.Si vous êtes impatient, vous pouvez obtenir un aperçu dans Firefox Beta., Aurore, ou si vous êtes vraiment courageux, Chaque nuit.

Jon Fingas, écrivant pour Engadget, contient plus d'informations sur Firefox 22:

Bien que Mozilla défende depuis longtemps WebRTC pour les conversations vidéo et vocales sans plugin, l'entreprise n'était pas encore prête à activer le protocole complet dans Firefox de manière automatique. Elle se montre plus confiante depuis cette semaine…

Google IO

Justin Uberti et Sam Dutton ont clôturé la semaine par une présentation sur WebRTC lors de la conférence Google I/O. Les diapositives et le vidéo sont désormais disponibles pour votre plus grand plaisir.

Janko Roetgers Les points saillants de la session ont été abordés. pour GigaOm :

WebRTC, la nouvelle technologie qui permet des conversations vocales et vidéo sans plugin directement dans le navigateur, devrait être disponible sur plus d'un milliard de terminaux uniques (navigateurs de bureau et appareils mobiles) “ d'ici une semaine ”, selon Justin Uberti, responsable de l'ingénierie WebRTC chez Google.

Points d'extrémité++

Enfin, Tsahi Levent-Levi a quelques suggestions à faire aux fournisseurs et clients de communications unifiées dans notre Article préféré de la semaine :

Tous les systèmes et terminaux de salle que vous installez ? Assurez-vous qu’ils soient entièrement compatibles WebRTC : utilisez un navigateur HTML5 et laissez JavaScript gérer le reste. Votre propre solution doit également adopter ce type de déploiement. Vos produits existants ? Mettez en place une passerelle pour leur permettre d’accéder au système.

+1 pour ça.

WebRTC Digest – Week of May 6

Ici, au siège de vLine, nous avons une liste de diffusion interne que nous utilisons pour partager des liens vers des articles, des messages de la liste de diffusion, des mises à jour de code et d'autres informations intéressantes concernant WebRTC.

Maintenant que nous avons enfin un blog, nous avons pensé qu'il serait sympa de partager ces liens avec vous, cher lecteur (coucou maman !). Alors, rendez-vous ici chaque lundi pour découvrir une nouvelle sélection d'actualités WebRTC de la semaine (en temps réel, non ?). Sans plus attendre, voici notre première édition :

Explosion des points de terminaison et des araignées

Kelly Teal, dans un article pour Channel Partners, pose la question : « Qu’est-ce que WebRTC ? » et interroge quelques analystes pour obtenir des réponses :

En matière de collaboration vidéo, tout le monde parle de WebRTC. Mais qu'est-ce que WebRTC et qu'est-ce que cela signifie pour les partenaires ?

 …

“ Ce que fait WebRTC, c'est créer le potentiel d'une explosion de points de terminaison vidéo basés sur navigateur, qui ne se connecteront qu'à d'autres points de terminaison utilisant la même norme ”, a déclaré Bill Haskins, analyste chez Wainhouse Research, à Channel Partners.

Nous sommes tout à fait d'accord sur l'explosion des points de terminaison basés sur les navigateurs. Genband, Ils ont toutefois contesté l'idée qu'ils ne communiqueraient qu'avec d'autres utilisateurs de la même norme en annonçant SPiDR, une nouvelle passerelle entre les systèmes traditionnels et WebRTC. Gary Audin, de NoJitter, relate l'événement :

SPiDR se situe à la périphérie du réseau de l'opérateur. Il fournit des API ouvertes et orientées web qui permettent aux développeurs d'applications de créer des services de communication riches via le réseau, notamment la voix, la vidéo, la présence, un carnet d'adresses partagé, l'historique des appels, la messagerie instantanée et la collaboration. 

Google IO 411

Le rapport annuel de Google fête des développeurs arrive en ville plus tard cette semaine, et le responsable technique WebRTC Justin Uberti Il sera de retour sur scène pour une nouvelle session qui promet d'être à guichets fermés sur notre stack en temps réel préféré (si vous avez manqué sa session de l'année dernière, vous pouvez visionner la vidéo ici).

Cette année, il co-présentera avec Chrome Developer Advocate et Contributeur de HTML5 Rocks Sam Dutton. Les deux intervenants animeront également un atelier de programmation pratique pour aider les heureux détenteurs de billets à traduire le jargon technique des API et protocoles WebRTC en applications web attrayantes.

Dans cet atelier pratique, nous vous aiderons à maîtriser les API et technologies fondamentales de WebRTC : – MediaStream (alias getUserMedia) : qu’est-ce que c’est et comment l’utiliser ? – RTCPeerConnection : quelle est l’importance de l’API la plus puissante de WebRTC ? – RTCDataChannel : comment configurer une communication en temps réel de données arbitraires ? – la signalisation : qu’est-ce que c’est et comment la configurer ? – les serveurs : de quoi ai-je besoin pour la signalisation, STUN et TURN ?

Nourriture pour oiseaux

En parlant de gourmandises, Justin s'est mis en appétit pour IO en offrant un trio de petits plats très attendus destinés à Chrome Canary sur le discuter-webrtc liste de diffusion. Mercredi, il insinué Des canaux de données fiables arrivent bientôt (si vous voulez être parmi les premiers informés de leur lancement, vous pouvez commencer à suivre). Numéro 1493).

Puis, vendredi, il a illuminé notre semaine en annonce Vous pourrez bientôt utiliser l'API getStats() pour découvrir les serveurs ICE sélectionnés par votre navigateur. Plus besoin de tcpdump ni de journaux détaillés pour savoir si vous utilisez un serveur relais ! Vous êtes aussi impatients que nous ?

Enfin, et surtout, il a confirmé que Canary est désormais capable de répartir la charge entre plusieurs serveurs TURN. Voir le fil de discussion complet. ici.

Richard Mentor Johnson ?

Enfin, voici quelques informations concernant les codecs. Matt Frost, chef de produit WebM et ancien PDG par intérim d'On2, a publié que Le VP9 est presque terminé.. Nous ne savons pas ce qui nous enthousiasme le plus : la prise en charge des canaux de profondeur (webcams 3D + cartes de profondeur + WebGL = ???) ou la guerre des codecs VP9 contre H.265.

Puisqu'il semble peu probable que les fournisseurs de navigateurs s'accordent sur un codec intégré commun au cours de cette décennie, la volonté de Mozilla de développer un codec entièrement JavaScript paraît de plus en plus raisonnable. Dans la continuité des travaux de Brendan Eich… Aujourd'hui, j'ai vu l'avenir Dans un article concernant ORBX.js, Peter Bright a écrit un belle pièce Pour Ars Technica, avec plus de détails techniques :

Pour les navigateurs tels qu'Internet Explorer 10 et Safari sur iOS, ORBX est utilisé en mode I-frame uniquement. Pour les autres navigateurs, notamment Firefox et Chrome, il utilise un mode mixte plus classique. En effet, ce mode mixte repose en partie sur WebGL pour son décodage. Les I-frames peuvent être entièrement encodées en JavaScript, tandis que les P-frames nécessitent l'utilisation de shaders en raison de leur plus grande complexité. Internet Explorer 10 et Safari sur iOS ne prenant pas en charge WebGL, il est impossible d'y exécuter des shaders. Par conséquent, ils consomment environ deux fois plus de bande passante pour une qualité vidéo équivalente.

Malheureusement, aucune démo publique pour le moment. Mais nous avons hâte de l'essayer sur nos iPhone 12.

Free vLine/WebRTC Consulting and Training

L'une de nos principales priorités est de simplifier au maximum la prise en main de WebRTC et de la plateforme vLine. C'est pourquoi nous offrons cinq journées complètes de formation et de conseil gratuites aux développeurs travaillant sur des projets utilisant WebRTC et vLine qui seront mis en production d'ici le 30 juin.

Pour les développeurs situés aux États-Unis (hors Alaska et Hawaï), nous nous déplaçons dans vos bureaux, travaillons à vos côtés et mettons tout en œuvre pour assurer le succès de votre projet. Pour ceux situés ailleurs dans le monde, nous proposons la même prestation par visioconférence et partage d'écran.

Si cela vous intéresse, veuillez envoyer un courriel à [email protected] en nous expliquant ce que vous construisez et comment vous comptez utiliser le temps de consultation.

Le 10 mai, nous examinerons les candidatures et sélectionnerons les cinq développeurs. La priorité sera accordée aux projets pour lesquels des ressources de développement ont déjà été allouées et qui seront lancés prochainement.

Nous avons hâte d'avoir de vos nouvelles !

vLine Just Got Easier

Nous sommes heureux d'annoncer une étape majeure pour la plateforme vLine : vous pouvez désormais créer un service de chat vidéo en marque blanche en une minute environ, sans écrire une seule ligne de code.

Et pour faciliter encore davantage l'intégration à votre site web, nous offrons cinq journées complètes de consultation et de formation sur site aux projets éligibles (détails complets). ici).

Pour créer votre service de chat vidéo, rendez-vous sur vline.com Cliquez ensuite sur le gros bouton ‘ Commencer ’. Ou, pour voir comment cela fonctionne, regardez cette vidéo :