Discussion:WebRTC

Bonjour,

Je suis étudiant en master informatique à l'université de Lille1, et dans le cadre de notre formation, mon binôme et moi avons le devoir de réaliser un état de l'art sur les WebRTC sur wikipédia.

Notre document est encore au stade de brouillon et est accessible ici: Utilisateur:Feyd-Aran/Brouillon. Merci de ne pas y toucher pour l'instant, étant donné que nous devons encore être évalué dessus dans les semaines qui suivent. Par contre, toute remarque est la bienvenue dans la section discussion du brouillon.

Le but final est de fusionner les deux articles pour obtenir le meilleur possible.

Cordialement, Kath-rx (discuter) 2 décembre 2013 à 13:00 (CET)

Fusion d'articles

Bonjour,

je compte procéder à la fusion de l'article actuel sur WebRTC avec cet article https://fr.wikipedia.org/wiki/Utilisateur:Feyd-Aran/Brouillon d'ici 2 à 3 jours en suivant cette aide : Aide:Fusion

Si vous avez des remarques, questions ou protestations d'ici là, n'hésitez pas!

Cordialement, Feyd-Aran

Bonjour,

Merci à vous deux d'améliorer sensiblement la partie technique de l'article. Voici mes remarques:

• 1/ Liens internes

Il serait bénéfique de mettre les bons liens internes lorsque vous utilisez les abréviations: quand on a 4 choix différents dont 2 liés à internet, cela ne devient pas évident. J'ai relevé:

RTP pour https://fr.wikipedia.org/wiki/Real-time_transport_protocol

SCTP pour https://fr.wikipedia.org/wiki/Stream_Control_Transmission_Protocol

SRTP n' as pas de liens interne dans votre brouillon. https://fr.wikipedia.org/wiki/SRTP

Normalement, c'est corrigé (il se peut que certains m'aient encore échappé).

• 2/ Schémas

Au niveau de vos schémas https://commons.wikimedia.org/wiki/File:Pile_de_protocoles_d%27%C3%A9change_de_donn%C3%A9es_WebRTC.svg et https://commons.wikimedia.org/wiki/File:Pile_de_protocoles_d%27%C3%A9change_de_m%C3%A9dias_WebRTC.svg => l'utilisation d'une barre noir pour séparer les différents protocoles (NAT, Data channel, Media Channel) rend moins lisible le fait que tous utilise comme socle les couches IP et UDP. Lors de ma première lecture, je pensais que le NAT avait juste 2 jolies cases vertes.

Je pense que pour ces couches des lignes en pointillée serais mieux ou bien basculer le nom des protocoles au dessus et arrêter les lignes à la couche UDP.

Schémas corrigés (8 janvier)

• 3/ Compatibilité avec l'existant au niveau audio

Dans votre brouillon, vous ne parlez pas du souhait du groupe de travail de pouvoir converser avec les matériel utilisant SIP. Cela se voit notamment au niveau des codec audio choix de PCMA/PCMU et du codec G.711 (en plus le codec est dans le domaine public, sauf erreur) et du DTMF. Le choix d'un consensus sur un codec plus moderne comme Opus ne rentre pas dans ce cadre. Des industriels comme Cisco savent qui ne vendront pas de matériel WebRTC si ceux-ci ne peuvent pas communiquer avec les matériels de VoIP utilisant SIP. Cela explique le geste de Cisco d'offrir le codec OpenH26 à Mozilla pour solutionner le problème de l'héritage vidéo des VoIP.

• 4/ Internet explorer et Safari

Il me semble faux d'affirmer Cependant Microsoft a déjà exprimé sa volonté de proposer le support du standard pour une future version d'Internet Explorer là MS a crée un autre standard: le CU-RTC-WEB. Je ne sais plus si il est présent dans la version 11 (il y a eu une démo avec la version 10): http://html5labs.interoperabilitybridges.com/prototypes/cu-rtc-web/cu-rtc-web/info http://html5labs.interopbridges.com/prototypes/cu-rtc-web/cu-rtc-web/faq http://blogs.msdn.com/b/interoperability/archive/2013/03/14/new-cu-rtc-web-html5labs-prototype-from-ms-open-tech-demonstrates-roaming-between-cellular-and-wi-fi-connections.aspx

MS a acheté très cher Skype. Skype est une référence mondiale (on verra si cela va se maintenir avec la suppression du p2p par MS). Mais je doute qu'un protocole de Visio/Audio conférence qui passe pas un site web fasse les affaires de MS : cela risque de rendre leur achat peu intéressant. Mon avis est que si MS a proposé CU-RTC-WEB, c'est juste pour brouiller les cartes.

Quant à Apple, Facetime permet de communiquer entre Mac OS, iPad et iPhone, la situation doit convenir à Apple. Les autres ne sont pas leur clients (je sais c'est un troll gratuit).

Apple n'a en effet pas montré signe d'intêret pour WebRTC pour l'instant, cependant la position de microsoft avait été rapidement abordée dans un papier de 2011 (qu'il me semble avoir ajouté en référence). Je viens de faire une recherche rapide et en effet Microsoft n'envisage pas de proposer d'implémentations de WebRTC pour l'instant, ce qui colle avec l'apparition de CU-RTC-WEB

• 5/ Premières implémentations

Je rajouterais: https://talky.io/ (que vous avez cités pour lister les différents navigateurs), https://bistri.com/

Mis à jour le 7 janvier.

• 6/ Et les autres navigateurs

Comme je l'ai dit précédemment, certains participants au WebRTC sont intéresser pour intégrer WebRTC à leur matériel. Cisco et Ercicson ont fait des démonstrations à ce sujet avec des navigateurs maisons. Cela est resté au stade de démo. Mais on peux supposer que certains matériels d'Ericsson et de Cisco intégrerons un navigateur minimaliste pour gérer le WebRTC, l'utilisateur ne sachant pas que c'est un navigateur.

• 7/ Historique

Si vous parlez de ce qui se faisaient avant (Flash, Java & Co), vous ne donnez pas de dates sur la création du brouillons (mai 2011), les débuts de l'intégration au sein des navigateurs cf https://fr.wikipedia.org/wiki/WebRTC#Navigateurs_web De plus, je pense qu'il serait bon d'établir un lien avec SIP et avec XMPP: le webRTC s'inspirant en partie des acquis de ces technologies.

• 8/ Codec vidéo

Votre brouillon, détaillés au niveau de l'architecture réseau, développe peu les choix fait au niveau des codecs. Actuellement, le débat fait rage pour le codec vidéo: http://webrtchacks.com/webrtc-video-codec-discussion/ http://webrtchacks.com/ietf-finally-made-decision-mandatory-implement-mti-video-codec-webrtc/ http://webrtchacks.com/infographic-webrtc-mandatory-implement-video-codec-nutshell/ Les annonces prochaines de Google sur le VP9 ne sont pas à mettre qu'au crédit du 4k: http://www.electronista.com/articles/14/01/03/19.hardware.partners.lined.up.to.support.standard.for.youtube/

Pour le brouillon, nous nous sommes beaucoup appuyé sur des publications scientifiques issues du IEEE ou des ACM, en évitant d'utiliser les draft. Les publis ne faisant pas état des codecs choisis pour l'instant (ou très très peu), il n'en était pas fait mention. La fusion étant faite, je vais creuser un peu plus le sujet.

Merci encore de votre travail

Et merci pour la relecture!

80.215.196.34 (discuter) 4 janvier 2014 à 15:09 (CET)

J'ai pour l'instant procédé à une fusion globale des deux articles en n'ajoutant pas les parties qui me semblaient être des redites. J'ai lu les remarques au dessus et je ferais les modifications au fur et à mesure pour "affiner" l'article.

Feyd-Aran

Relecture Master TIIR

Bonjour, Je refait une relecture de l'article fusionné. Voici des remarques sur la première partie que je viens de réalisée (la suite demain). Les sources me semble bonnes. Elles répondent aux besoin de l'article. Cependant j'ai un peu de mal dans l'articulation des idées. Je pense que l'article ne traite pas assez des enjeux du WebRTC et comment cela va se passer en terme d'interopérabilité. Un point sur les usages me semble nécessaire. L'article ne traite pas non plus de la gestion des identités qui sera nécessaire pour mettre en relation des communications. Qu'en pensez vous ?

Sinon j'ai remarqué un problèmes avec vos références. Les liens doivent être présents dans la section Bibliographie et non Références. Vous pouvez regarder comment nous avons géré ce type de lien sur notre article Consommation énergétique d'un smartphone. J'ai noté aussi un problème avec la référence 30 qui s'appelle "2012". Mettre les références sur 4 colonnes, les rendra plus lisibles.

1/ Remarques d'ordres générales :

• Pour les listes à puces, elles doivent se finir par des « ; » est non des « , ». Le dernier de la liste doit se finir par un « . »;

Corrigé le 18 / 01 (Feyd-Aran)

• J'ai noté pour l'instant trois liens qui pointent vers une page d'homonymie : iServeur, API, contexte.
• Il faut éviter l'utilisation du futur. Préférez au maximum l'utilisation du présent

2/ Résumé introductif : Le résumé introductif doit reprendre les grandes lignes du sommaire. Il faut, en le lisant, que l'on comprenne le plan de l’article et son articulation. Il n’est pas besoin de sourcer le résumé introductif car c’est dans le détail de l’article que l’on doit retrouver le développement des idées et les sources associées.

Corrigé le 18 / 01 (Feyd-Aran)

3/ Section Historique :

• Problème avec la référence 6. Real Time Media Flow Protocol renvoi vers le Real Time Media Flow Protocol. Mettre plutôt une note pour la traduction de Real Time Media Flow Protocol;

Corrigé le 18 / 01 : ajout d'un lien interne wikipédia (pour l'instant uniquement en anglais) et traduction en note (Feyd-Aran)

• Traduisez directement en français le « drag and drop » (glissez déposer) dans l’article et mettez une note pour identifier que c’est traduit de l’anglais « drag and drop » si cela à du sens pour vous. Il existe également une page wiki pour glisser-déposer;

Corrigé le 18 / 01 (Feyd-Aran)

• Je ne comprends pas l’argumentaire : les discussions techniques sur les canaux d'échanges de données (quels qu'ils soient) entre particuliers.

Ce bout vient de la page anglaise de wikipédia, peut-être une mauvaise traduction. --80.215.134.183 (discuter) 17 janvier 2014 à 18:26 (CET)

Après recherche, cela semble venir de cette page: http://lists.w3.org/Archives/Public/public-media-capture/2012Dec/att-0159/RecordingProposal.html

The Media Capture Task Force expects this specification to evolve significantly based on:

• Privacy issues that arise when capturing media.
• Technical discussions within the task force.
• Experience gained through early experimentations.
• Feedback received from other groups and individuals. --80.215.205.228 (discuter) 25 janvier 2014 à 12:14 (CET)

4/ Section Description générale de la norme

• Agrandir l’image pour qu’elle soit lisible;

Corrigé le 18 / 01, l'image a été agrandie pour être rendue lisible. (Feyd-Aran)

• Vous utilisez la notion de navigateur A et navigateur B pour étayer votre description. C’est très bien, mais on ne retrouve pas la notion A et B dans l’illustration proposée. Si l’image est là pour apporter un soutien au texte, Je pense qu’il faut trouver les termes utilisés dans le texte dans le schéma, comme également l’objet PeerConnection. A contrario, il y a des sigles dans le schéma que je ne trouve pas dans le texte. (DTLS/SRTP, ICE, SCTP/DTLs, STUN, TURN)

D’ordre général, il faut que le schéma illustre au mieux le propos de l’article. De plus de quelles sources tirez vous ces informations ? La figure 3 de la p72 de Loreto (Real-Time Communications in the Web) me semble une bonne illustration pour un exemple simple;

En effet, l'image est trop détaillée pour le propos auquel elle se rapporte. Je demanderais à Kath-RX D'en faire une plus parlante lundi (je suis nul pour les illustrations). Donc image qui sera modifiée le 20/01 (Feyd-Aran)

Kath a fait une image supplémentaire qui a été intégrée à l'article pour illustrer l'établissement d'une session webrtc. J'espère qu'elle est assez parlante.(Feyd-Aran)

• Il manque le lien pour accéder à la doc : P2P media streaming with HTML5 and WebRTC.

Je n'avais pas trouvé de lien doi ou de lien direct vers la publication. J'essaie de corriger ça dès que j'en trouve un. (Feyd-Aran)

5/ Section Spécification Techniques

• J’ai du mal à comprendre l’articulation des différents paragraphes entre la section Spécification Techniques et la sous section PeerConnection. cela ne doit il pas être dans une sous section ? comme par exemple, Codecs Audio, et Codecs Vidéo ? Que voulez vous mettre en valeur et expliquer ? A noter qu’ il faut éviter d’utiliser le futur.

J'ai passé "spécifications techniques" en sous section avec au passage une réorganisation de la section pour plus de cohérences. Les derniers points de la liste étant une reprise des explications au dessus, elles ont été déplacées pour ne pas être une redite. Je pense renommer la sous section "codecs utilisés" pour mieux illustrer ce qui est développé dans le corps du texte. Le temps a été corrigé pour le présent(Feyd-Aran).

• Le lien wiki vers Février et 2013 ne semble pas nécessaire.

Supprimé pour plus de cohérence (Feyd-Aran).

6/ Sous section Peer Connection :

• La phrase « habituellement une autre instance de l'application JavaScript tournant sur le client » ne me semble pas clair;

J'ai modifié la formulation pour être plus compréhensible (Feyd-Aran).

• UDP, SDP et JSEP : mettre une note pour expliquer les acronymes;

Corrigé le 18/01 (Feyd-Aran).

• Mettre le lien wiki anglais pour SDP;

Corrigé le 18/01 (Feyd-Aran).

• J’ai du mal à comprendre la phrase : « Afin d'assurer le passage au travers des NAT ». Le NAT n’est pas un équipement, mais un mécanisme qui permet de faire correspondre une @IP privé à une @IP publique. Ce point mérite à mon sens un éclaircissement.

L'idée était que NAT est un mécanisme qui agit comme une barrière entre un réseau interne et externe (typiquement internet). Tout ce qui transite entre ces réseaux passe par le NAT, qui est donc une sorte de filtre logiciel. Ma formulation peut en effet faire penser qu'il s'agit d'un équipement, je modifie en conséquence(Feyd-Aran).

Fait le 18/01. Si cela vous semble toujours malaisé à comprendre, n'hésitez pas à le signaler(Feyd-Aran).

7/ Sous section Data Streams :

• Le titre ne serait il pas plutôt « Data Channel » ?;

Le terme utilisé dans la littérature est bien "data stream". A priori, l'accent est plutôt mis sur l'idée de "flux" que de canal. J'ai préféré garder cette formulation pour être cohérent avec la sous section suivante(Feyd-Aran).

Je me permet d'insister, dans vos références que vous utilisez pour la sous section, cela parle de Data Channel, de plus dans votre rédaction, vous parlez de Data Channel, dans les schémas aussi. Je ne trouve pas la notion de Data Streams. Pouvez vous me préciser vos sources pour que je puisse recouper l'information ?--Aurel asm (discuter) 22 janvier 2014 à 11:16 (CET)

J'ai relu la publication Real-Time Communications in the web et en effet, bien que le mot stream soit utilisé dans le point concernant les data channels il semblerait que data channel soit bien plus approprié. My bad.(Feyd-Aran)

Merci, je pense même qu'il faut traduire data channel et Media stream, par Canal de données et Flux média, car vous devez éviter les anglicismes. Désolé pour cette remarque tardive --Aurel asm (discuter) 23 janvier 2014 à 08:58 (CET)

Je comprends l'idée d'éviter les anglicismes mais je ne suis pas tout à fait convaincu de la nécessité et même de la pertinence de traduire Data channel et Media Stream. Ce sont des concepts spécifiques à WebRTC qui peuvent être rapidement rattachés à l'API si une personne interessée creuse un peu plus. Peut être est ce un point qu'il faudrait débattre avec la communauté wikipédienne ? (Feyd-Aran)

• SCTP, DTLS, SRTP : mettre une note pour expliquer les acronymes;

Fait le 18 / 01 (Feyd-Aran)

• Je ne comprends pas le sens de cette phrase : « Cette solution permet une interaction aisée avec les flux médias encapsulés parallèlement et le partage de la même couche transport par le même numéro de port. ».

J'ai reformulé. C'est vrai qu'avec du recul, j'ai du moi aussi m'y reprendre à plusieurs fois pour la comprendre... 18 / 01 (Feyd-Aran)

8/ Sous section Média Streams :

• Agrandir un peu le schéma;

Fait le 18 / 01 (Feyd-Aran)

• Utiliser des notes pour les acronymes qui n’ont pas encore été définis.
• source intéressante pour le média Stream : http://www.w3.org/TR/mediacapture-streams/#mediastream

Je lis ça le 19 / 01 et je compléterais la section en conséquence(Feyd-Aran)

9/ Sous Section Multiplexage media / data

• Je ne comprends pas la tournure de phrase : « par exemple qu'un paquet média ne soit bloqué alors qu'un paquet de données ne puisse passer »

J'ai reformulé en espérant que ce soit plus compréhensible (Feyd-Aran).

Je fait un retour sur le reste demain. Dans l'ensemble, les sources et le contenu sont là mais j'ai du mal à tout saisir lié je pense à des problèmes de tournures de phrases et d'articulation.

Bon courage ! dernière ligne droite :)

--Aurel asm (discuter) 13 janvier 2014 à 17:53 (CET)

Relecture Master TIIR suite

1/ Sous Section Sécurité.

• Vous ne citez qu’une seule source. J’ai trouvé d’autres sources sur la sécurité, notamment celle-ci : http://tools.ietf.org/html/draft-ietf-rtcweb-security-05 de Rescorla 2013 qui me semble apporter des compléments.

Je lis ça et j'intègre demain (19/01) je pense. (Feyd-Aran)

2/ Sous Section Gérer la perte de paquets

• Je la nommerai plus "Gestion de la perte de paquets"

Modifié le 18/01 (Feyd-Aran).

• Les liens vers UDP et TCP renvoient vers une page d'homonymie

Modifié le 18/01 (Feyd-Aran).

• Les liens wiki vers NACK et FEC ne me semble pas appropriés, peut être mettre plutôt les liens anglais s'ils existent

Modifié le 18/01 (Feyd-Aran).

• utiliser les notes pour définir les acronymes
• Évitez les anglicismes comme "layer"

corrigé pour "controles temporels", à défaut de mieux (Feyd-Aran).

• Manque référence pour la phrase : "En outre, le calcul de FEC étant la partie la plus longue du processus, l'optimisation de flux permet d'en varier la fréquence, créant ainsi une FEC/NACK adaptative qui répond au mieux aux problèmes rencontrés durant la transmission."

Je rajoute la référence dès que je l'ai retrouvée (Feyd-Aran).

3/ Sous Section Transiter au travers d'un firewall

• Vous n'utilisez de nouveau qu'une seule source, alors que plusieurs sources que vous avez déjà dans votre bibliographie parle de cette problématique.

Je fais une relecture rapide de ma biblio demain (19/01) pour ajouter d'autres sources (Feyd-Aran).

• Évitez les anglicismes comme "man-in-the-middle"

Modifié le 18/01 (Feyd-Aran).

• On reste toujours dans la même source que la sous section précédente

4 / Section Integration Les sous sections ne sont pas rédigées, on est dans l'énumération. Je ne comprends pas la sous section "Autres", le nom de la sous section n'est pas adapté et donne l'impression d'une sous section inclassable.

Il semble que wikipédia n'aime pas l'énumération cherchant à faire une liste exhaustive d'une situation à moins qu'elle ne soient sur une page, peut-être il faudrait le faire ici. La partie navigateur fait le point de l'intégration dans les différents navigateurs. La partie autres, fait une chronologie sur l'état de l'avancement du webRTC par les différents acteurs. --80.215.134.183 (discuter) 17 janvier 2014 à 18:30 (CET)

Si ça convient à tout le monde, j'essaierais de rédiger un peu mieux la section et de lui trouver un titre adapté ("avancement actuel"?, "Etat de la norme"?) (Feyd-Aran).

Oui je trouverai ça plus pertinent.--Aurel asm (discuter) 20 janvier 2014 à 17:34 (CET)

--Aurel asm (discuter) 14 janvier 2014 à 17:06 (CET)

J'ai rédigé toute la partie sus citée, en la renommant. J'ai aussi supprimé un item de la liste qui avait un beau refnec après avoir cherché plus d'infos sur google qui m'a ressorti que 7 liens dont 6 internes à wikipédia... Je la garde sous le coude au cas où quelqu'un trouve une référence:

* En décembre 2012, EC2LT lance sa première application sur le WebRTC^{[réf. nécessaire]}

(Feyd-Aran)

Problème avec les références

Faites attention, vous avez toujours un problème avec les références. A mon sens vous mélangez notes, références et bibliographie. Cela serait plus lisible si les liens Internet étaient dans Bibliographie.(cf Wikipédia:Conventions bibliographiques Il faut aussi créer une section note pour y mettre les descriptifs des acronymes. (cf Aide:Note)

Merci d'avoir pris en compte mes remarques Au plaisir de vous voir la semaine prochaine

--Aurel asm (discuter) 20 janvier 2014 à 17:41 (CET)

Je modifie ca demain soir (22//01) Feyd-Aran

Manque Source

Il reste des paragraphes où il manque des références. Je vous avez déjà signalé ce point lors de ma première relecture lorsque l'article n'était pas encore fusionné Discussion utilisateur:Feyd-Aran/Brouillon. Il faut mettre aussi les sources pour les titres des schémas. Par exemple, Section historique, y a deux paragraphes qui ne sont pas sourcés. J'ai bien compris que c'était la source numéro 17 à la fin du troisième paragraphe, mais cela fait trop de contenu pour une seule source, il faut donc préciser au début du premier paragraphe que c'est selon Nurminen.

voici le liste des phrases où il manque la référence

Section Historique

• le respect de la vie privée : des intrusions pouvant se faire en accédant à des parties locales de l'ordinateur (caméra, micro, ...) ou en espionnant depuis l'extérieur les données échangées ;
• les retours d'expériences venant d'autres groupes et individus.
• les échanges d'entrées/sorties au sein du groupe RTCWEB d'IETF pour définir les protocoles pouvant permettre les communications en temps-réel au sein des différents navigateurs web. Il y a une référence au milieu de la phrase mais pas à la fin
• Une fois cette connexion pair à pair établie, chaque parti peut établir des MediaStreams ou DataStreams l'utilisant.Manque référence

Je viens d'ajouter une source d'où vient ce paragraphe --80.215.131.233 (discuter) 4 février 2014 à 11:34 (CET)

Section Description générale de la norme

• A partir de "Afin d'établir une connexion utilisant le standard WebRTC,", pas de référence sur 3 paragraphes

Section PeerConnection

• Ce processus utilisant SDP permet la négociation à la fois pour RTP (transport de médias) et pour SCTP (permettant le transport de données)
• Une fois cette connexion pair à pair établie, chaque parti peut établir des MediaStreams ou DataStreams l'utilisant.

Section Data channels

• Cette solution permet au flux de données d'être intégré dans le même paquet que les flux de médias et donc de partager le même numéro de port pour les échanges
• Afin d'assurer la confidentialité et l'authenticité des paquets SCTP échangés, chaque flux repose sur le protocole DTLS
• Au sein d'un canal de données, les applications peuvent transmettre des messages de façon ordonnée ou désordonnée
• L'ordre de remise est préservé uniquement dans le cas d'une transmission de paquets ordonnés envoyés sur le même lien de données

Section Media Streams

• L'API MediaStream gére les flux audio et vidéo et indique à l'application qu'elle doit donner accès à la webcam, aux haut-parleurs et au microphone ; Si la référence est la 37, la mettre en fin de phrase
• Les flux médias sont transportés par le biais du protocole RTP, utilisable sur tout protocole de transport implémentant une abstraction de datagram (UDP par exemple). La confidentialité, authentification des messages et la protection contre les répétitions est apportée par l'utilisation sécurisée de RTP, SRTP  : Si la référence est la 38, la mettre en fin de phrase
• La gestion des clés pour SRTP est assurée par DTLS et donc le flux de données. Il est donc impossible d'avoir un flux média indépendant d'un flux de données là où l'inverse est envisageable

Section Multiplexage media / data

• Une valeur de 0 ou 1 indique un paquet STUN, une valeur entre 20 et 63 indique un paquet DTLS une valeur de 128 à 191 indique un paquet SRTP.

Section Sécurité des applications

• Si c'est la même source, préciser que c'est selon Jennings. Mais je vous ai donné une autre source pour la sécurité

Section Gestion de la perte des paquets

• En outre, le calcul de FEC étant la partie la plus longue du processus, l'optimisation de flux permet d'en varier la fréquence, créant ainsi une FEC/NACK adaptative qui répond au mieux aux problèmes rencontrés durant la transmission

Section Transiter au travers d'un firewall

• Idem, uniquement la source 46.

Section Alternative

• La proposition de Google s'appuie sur le codec VP8 non soumis à des redevances de brevets, tandis que la proposition de Micrososft utilise le standard ISO/IEC H.264, très répandu mais soumis à la redevance de nombreux brevets. : manque la source

Je viens d'en ajouter --80.215.131.233 (discuter) 4 février 2014 à 11:21 (CET)

Voilà c'est fini mes remarques, je ferai une dernière relecture une fois vos modifs faite, mais si vous mettez bien les sources, l'article est lisible et compréhensible. Merci d'avoir ajouté la schéma sur l'appel entre A et B. --Aurel asm (discuter) 23 janvier 2014 à 17:00 (CET)

Visio à plusieurs

Cet article parle beaucoup d'échange de un avec un. Mais quand est-il des échanges entre un groupe de plusieurs personnes ?? Notamment dans le cas de la visio. La norme parle de ce genre de cas ??