Tout à fait le multcast se propage d'équipement en équipement.

IGMP n'est pas suffisamment strict dans sa norme pour que deux équipements qui respectent la norme génèrent des pertes de paquets quand il y a un IGMP General Query suivit immédiatement d'un client qui résilie une flux.

Cela entraîne des problèmes complexes à tester et à reproduire en lab.

Concernant la TV, le fait d'être obligé de changer de chaîne pour que l'image revienne, cela semble visiblement un problème IGMP.

Je vais donner quelques conseils à Wibox, ayant déjà travaillé sur cette problématique.

4 éléments peuvent à l'origine de ce problème : La Set Top Box, la Wibox, le switch du SIEA qui possède les fonctions IGMP proxy, le routeur qui diffuse les flux ou une incompatibilité entre plusieurs de ces équipements.
Des problèmes d'interopérabilité peuvent survenir si une partie des équipements fonctionnent en IGMP snooping v2 et d'autres en IGMP snooping v3. Certaines box font des requêtes en v2  et en cas de non réponse passent ensuite en v3, bref il est préférable du forcer le même protocole partout (généralement IGMP v2)

Pour avancer, il faut des captures Wireshark. Je déconseille de mettre un switch avec port miroring, mon expérience que ces équipements actifs peuvent interférer sur les requêtes IGMP transmises même quand IGMP proxy est désactivé (je pense au matériel linksys / cisco). Je conseille de mettre deux PC linux avec chacun deux interfaces réseau et un pont pour relier les deux interfaces (tutoriel).

|---------|    |----------|    |-------|    |----------|    |----------------|
|   STB   |----| PC Linux |----| Wibox |----| PC Linux |----| CPE RESO-LIAin |----Fibre
|---------|    |----------|    |-------|    |----------|    |----------------|

Il faut vérifier la liste des paquets IGMP reçus et envoyés avant la coupure.
L'idéal serais d'avoir des captures Wireshark plus en amont, sur le réseau du SIEA.


Il faut voir en cas de coupure de flux où à été coupé le flux : C'est le switch du SIEA qui a arrété d'envoyer le flux à la Wibox ou c'est la Wibox qui a arrété d'envoer le flux vers la STB alors qu'elle reçoit toujours le flux de son port Wan ?

Toutes les deux minutes le switch de RESO-LIAin et la Wibox envoi un "IGMP General Query" afin que chaque équipement lui donne la liste des flux auquel il s'est abonné. Un "Query Response Interval" est alors positionné à 10 secondes. Afin de ne pas surcharger le switch, les équipements répondent après un temps d'attente aléatoire qui est entre 0s et 10s. Le switch, lui, va attendre 10 secondes + une petite marge de sécurité avant de couper les flux multicast pour lesquels il n'aura pas reçu de réponse. Il faut donc vérifier si la réponse a été émise juste avant l’expiration du délais, cela pourrait être une cause de coupure de flux.

Le "Query Response Interval" est généralement de 10 secondes pour un "IGMP General Query" mais de 1 seconde pour un "IGMP group-specific Query", envoyé quand un autre port du switch demande de quitter un flux multicast "IGMP Leave IP flux". Il est possible d'avoir des problèmes plus complexe, lié a ces différents timer.

Un exemple de bug difficile a tracer entraînant dans des cas particuliers une coupure de flux pour le client à tord :
- T 0 : La box chez le client est abonné au flux 225.0.0.5 et reçois un "IGMP General Query" avec un délai de réponse de 10 secondes. La box décide de répondre après 9 secondes (c'est un délai aléatoire entre 0 et 10sec).
- T 0 + 1 sec : Le switch de la SIEA à reçu un demande de résiliation du flux 225.0.0.5 (Leave Group message) d'un autre client. Le switch coupe le flux pour ce client et envoi un "IGMP group-specific Query" pour 225.0.0.5. Ce type de demande possède normalement un "Query Response Interval" interval de 1 seconde.
La box chez le premier client reçoit cette demande mais elle à déjà une réponse IGMP qui est en attente d'être envoyée et son mécanisme ne permet pas de répondre à plusieurs requêtes à la fois. (Tout ne sort pas de mon invention, des problèmes de ce type ont déjà existé chez certains opérateurs)
- T 0 + 2 sec : expiration du délai de 1 seconde pour le "IGMP group-specific Query". Le switch considère donc que la box n'est plus d'abonnés à ce flux et coupe le flux 225.0.0.5.
- T 0 + 9 sec : La box répond au "IGMP General Query" avec les 9 secondes d'attente. Le switch s'aperçois que la box est abonné à 225.0.0.5 et lui remet le flux.

Total pour le client : 7 secondes de coupure de flux.
Un P+ / P- permet bien sur d'envoyer une nouvelle demande d'abonnement et donc de retrouver le flux immédiatement.

Ce type de bug devrait ne pas être trop impactant pour le client car il faut plusieurs circonstances pour le re-produire : query general qui coïncide avec une réponse tardive et un autre client qui résilie la même chaîne au début de l'interval de temps. Plus le nombre de client augmente et plus on se met sur une chaîne populaire, plus les demandes de leave sont importantes et plus ce type de bug risque d'arriver si la box ignore les autres requêtes IGMP pendant le temps où la réponse est mise en attente. Je pense donc que ce n'est pas ce bug qui gêne les clients Wibox, c'est plus pour montrer qu'il est possible d'avoir des bug complexes avec IGMP v2 partout.

Concernant les bug liés à l'utilisaiton d'IGMPv2 et v3 sur le même réseau certains fabricants (huawei) ont décidés de forcer le choix d'un protocole. Si on choisit IGMP v2 les requêtes IGMP v3 seront ignorées. Cette modification provoque une coupure complète de flux multicast chez les client IGMPv3 ce qui est en fait préférable à avoir un bug lié a la cohabitaiton v2 et v3 qui est difficilement reproductible en lab.

Salut Hugues, et bonne année à toi.

Techniquement, comment ça se passe? Vous sous-traitez ça à un gentil opérateur ami? Orne-THD au hasard?

Leon.

Oui, mais seulement une partie. Sur cette partie, on a négocié dans nos conventions de reprise avec les chaines, la possibilité qu'on soit un relai à titre gracieux pour d'autres structures publiques (comme des régies autour de moi) ou associatives. Donc non seulement ils ont le flux original (je dois être transparent et ne pas modifier le flux) et c'est gratuit.

Pour le reste, ils se débrouillent.

Oui, mais seulement une partie. Sur cette partie, on a négocié dans nos conventions de reprise avec les chaines, la possibilité qu'on soit un relai à titre gracieux pour d'autres structures publiques (comme des régies autour de moi) ou associatives. Donc non seulement il a le flux original (je dois être transparent et ne pas modifier le flux) et c'est gratuit.

Pour le reste, il se débrouille.

Propre !

Ça dépend des chaines, soit c'est du flux direct (qui peut aller jusqu'à 35mbps), soit c'est du flux sat, donc un peu moins compressé que la TNT, mais pas bien loin non plus

toucher les particuliers

Peut-être, mais est-ce qu'on en a vraiment envie ? Coté support et relationnel c'est pas du tout pareil...

Je pense honnetement qu'il manquait qq chose entre des opérateurs privés grand public et des opérateurs associatifs comme FDN ou Milky, mais réservés à une niche car faisant que du net.

Là Milky commence à bosser sur du dual-play, c'est pas mal, ça permet d'adresser plus de monde effectivement.

Peut-être, mais est-ce qu'on en a vraiment envie ? Coté support et relationnel c'est pas du tout pareil...

Yep mais tu restes sur la ligne du : je te fournis les paroles, à toi de faire la musique. Ca séduit un certain public.