Via un point d'accès, possible. Mais sinon il me semble facile via l'application mobile de séparer.

(et c'est - je crois - la réponse qui m'avait été faite quand j'avais soulevé la même question que toi)

On avait évoqué la techno Streamroot ici et là mais c'était aussi pour TF1.

Tu as vérifié que c'était le cas en 4G ?

Normalement, WebRTC peut utiliser deux méthodes successives pour contourner les NAT ; une fois avoir obtenu les adresses IP publiques et privées de chaque utilisateur en utilisant le protocole STUN, il les échange en utilisant un canal auxiliaire comme une suite de requêtes HTTP ou un échange Websocket, puis essaie soit :

• de simuler une connexion UDP factice du côté de chaque pair en utilisant la technique nommée UDP hole punching, qui consiste à envoyer de chaque côté des paquets UDP vers des ports dynamiques déterminés à l'avance, afin de tromper la table de routage temporaire du NAT : chaque client doit faire croire à son NAT qu'il parle à un socket serveur situé de l'autre côté, alors qu'il parle en fait à un socket client (sachant qu'UDP ne permet pas de faire la distinction). S'il y a une translation dynamique du port source, alors cette technique n'a pas toutes les chances de marcher ;
• si ça ne marche pas, il va utiliser par défaut à 100 % un proxy public (Mozilla et Google en fournissent, mais il est possible d'en configurer d'autres dynamiquement) à travers le protocole nommé TURN.

On peut penser qu'on tombera probablement sur du TURN si on est en présence d'un CG-NAT, et que la bibliothèque utilisée est peut-être configurée pour éviter d'èmettre des flux pair-à-pair lorsque le TURN est utilisé. On peut aussi présumer que si elle est bien faîte, elle effectuera des tests de bande passante basique avant d'utiliser le flux montant de l'utilisateur (l'upload d'une une ligne ADSL2+ est facilement saturé, elle préférera sûrement les flux VDSL2 ou fibre) et la possibilité d'un filtrage par plage d'adresse n'est pas à exclure non plus. Tous ces points sont à vérifier.

Skype, l'un des logiciels ayant disposé dans le passé d'un mécanisme de répartition des flux pair-à-pair les plus répandus, effectuait de nombreux tests sur la solidité des connexions avant de choisir d'utiliser un PC comme nœud pour partager la charge de ses flux, et seules les connexions les plus solides (en général d'entreprise) étaient sélectionnées. En dehors de ces vérifications, WebRTC reprend de nombreux points de fonctionnement de l'ancien protocole de Skype.

C'est bizarre qu'il y est des clients hors France, car normalement c'est bloqué non ?

Ca fait plaisir. C’est quand même un peu l’idée de base d’internet d’arriver à décentraliser


MyCANAL qui plantait des qu’un gros match était à l’affiche, c’était vraiment pénible. Et on a beau avoir des architectures scalables suivant la charge, cela a du sens de décentraliser les ressources.

Ca fait plaisir. C’est quand même un peu l’idée de base d’internet d’arriver à décentraliser

c'est mieux quand on est que client.......................