Auteur Sujet: iBloo: un nouveau FAI sur les DSP FTTH (Lu 38016 fois)

ludodo · « **Réponse #120 le:** 16 février 2021 à 10:55:47 »

merci bien pour le lien, c'est intéressant.
Comme je gère le réseau informatique à mon travail, je vais passer par la formation pro. J'ai prévu cette année de commencer par consolider mes connaissances sur TCP/IP (car je suis autodidacte) et l'année prochaine je plongerai sur IPV6, car à terme, notre infra pro devra aussi évoluer vers IPV6.

jd27370 · « **Réponse #121 le:** 16 février 2021 à 12:03:32 »

Oyez, Oyez, bonjour à tous :-)

Je viens ici pour indiquer que je viens de compléter mon dossier d'inscription iBloo sur le réseau Eure Numérique THD (opéré par Axione).
Comme je pense être le premier du forum à me signaler en tant que "futur et j'espère heureux" abonné iBloo sur le RIP du département de l'eure, je partagerais régulièrement mon expérience entre ce topic et celui dédié à mon département.

Pour le moment j'attends ma date d'installation pour la première quinzaine de mars.

Ayant pas mal utilisé le forum pour ma recherche d'info, il est tout naturel de retourner le service, donc si il y a besoin d'un retour spécifique ou de test, je ferai le nécessaire pour répondre à vos demandes.

Pour info, j'ai fais une synthèse qui m'a amené à choisir iBloo dans un topic dans le forum du département 27 https://lafibre.info/eure/amfreville-la-campagne-les-premiers-villages-seront-raccordes-dici-huit-mois/msg840926/#msg840926

Larcyat · « **Réponse #122 le:** 19 avril 2021 à 11:53:45 »

Bonjour,

Après quelques vicissitudes en 2020, 2021 se présente mieux pour l'instant, le service fonctionne très correctement et les bandes passantes sont au rendez vous, je fais le test entre 2 et trois fois par semaine avec le speddtest OOKLA.

Sur 28 test, le plus rapide est 929.80 et la moyenne 853.84 en descente, et 391.84 moyenne 380.5 en montée, ping 5ms en moyenne.

Je suis donc satisfait d'IBLOO avec un bon rapport qualité prix et un accueil très avenant du service client.

A suivre donc

jd27370 · « **Réponse #123 le:** 19 avril 2021 à 14:15:52 »

Bonjour à tous,

Pour ma part cela fait désormais une semaine que ma ligne iBloo est active et aucun dysfonctionnement à signaler.
Le raccordement avait eu lieu le vendredi en fin de journée et elle a été active le lundi dans l'après-midi.

Côté débit, j'ai un download oscillant entre 920 et 960 mbps et un upload entre 320 et 350 (tests réalisés avec navigateurs ookla et que choisir).

Je suis sur le réseau Eure Normandie THD (DSP Axione) et pour le moment satisfait d'avoir fait confiance à iBloo.
Le seul point à noter et une incompatibilité de mon téléphone avec le routeur.
Ils m'ont fait parvenir un téléphone mais le top c'est que je peux utiliser une appli sur mon mobile avec le compte SIP (après je n'ai presque pas d'usage de mon numéro de fixe).

vivien · « **Réponse #124 le:** 30 avril 2021 à 13:46:27 »

C'est quoi cette incompatibilité du téléphone avec le routeur, ce n'est pas une prise RJ11 comme sur les box grand public ?

Delphine · « **Réponse #125 le:** 30 avril 2021 à 17:16:03 »

Citation de: vivien le 30 avril 2021 à 13:46:27

C'est quoi cette incompatibilité du téléphone avec le routeur, ce n'est pas une prise RJ11 comme sur les box grand public ?

Nous rencontrons un certain nombre de problèmes dans la gestion du protocole SIP sur notre modèle de routeur actuel en IPv6 et avec certains opérateurs seulement. En conséquence, dans certains départements, il n’est pas possible de connecter un téléphone analogique sur le port RJ11 de nos routeurs.

iBloo propose un 1er contournement en mettant à disposition des clients un téléphone SIP. Au demeurant, d’autre solutions sont dores et déjà en cours d’investigation et permettront à nos clients de revenir à un fonctionnement plus classique avec des téléphones analogiques. Au demeurant, nous nous rendons compte que la mise à disposition de comptes SIP offre un certain nombre d'avantages et de souplesse que nous n’avions pas envisagé à l’origine. Il est probable que nous conservions cette option à l’avenir.

vivien · « **Réponse #126 le:** 30 avril 2021 à 17:41:58 »

Effectivement IPv6 est peu utilisé pour le SIP (en tout cas il y a 3 ans, quand il y a eu un régalement de différent entre Orange et Free sur la version IP à utiliser pour l’interconnexion SIP entre opérateur, Orange demandait IPv4 et Free IPv6. C'est le premier sujet IPv6 a aller devant la cour d'appel de Paris).

Quand il y du CG-Nat en IPv4, je vois bien l'avantage à monter le SIP en IPv6 pour éviter de passer par le CG-Nat. Moins on triture les paquets, mieux c'est.

Ce qui est étonnant, c'est que cela passe avec certains opérateur d'infrastructure et pas d'autre.

J'ai une suggestion : Ce ne serais pas une histoire de préfixe IPv6 différent ? Certains systèmes SIP ont des difficultés avec la simplification des bloc ":0000:" par "::". Je connais des opérateurs qui ont du modifier les IPv6 pour éviter ces problèmes.

Attention a gérer le risque de fraude, quand l'abonné à accès à son compte SIP. L'imagination des fraudeurs est sans limite et les montants peuvent être élevés, certaines fraudes arrivant a lancer plusieurs appels simultanés sur des numéros surtaxés, depuis une même ligne.

vivien · « **Réponse #127 le:** 30 avril 2021 à 18:23:32 »

Voici plus d'informations sur un problématique IPv6 SIP qui impacte un autre opérateur :

Une unique suite de un ou plusieurs groupes consécutifs de 16 bits tous nuls peut être omise, en conservant toutefois les signes : de chaque côté de la suite de chiffres omise, c'est-à-dire une paire de deux points ( :: ).
C’est peut-être ce point qui posait problème, si une IPv6 est constitué de plusieurs groupes non consécutifs de 16 bits tous nuls : Le "::" ne peut apparaître qu'une seule fois dans une adresse. Le "::" peut aussi être utilisé pour compresser les zéros de début ou de fin dans une adresse.
Le cas d’une IPv6 constitué de plusieurs groupes non consécutifs de 16 bits tous nuls est toutefois très rare dans la réalité, à moins de chercher spécifiquement à le rencontrer.

Un exemple est peut-être plus parlant :
L’IPv6 ABCD:EF01:2345:6789:0000:EF01:0000:6789
Peut-être écrit ABCD:EF01:2345:6789::EF01:0000:6789 ou ABCD:EF01:2345:6789:0000:EF01::6789

La RFC4219 est très claire :

1. The preferred form is x:x:x:x:x:x:x:x, where the 'x's are one to
four hexadecimal digits of the eight 16-bit pieces of the address.
Examples:

ABCD:EF01:2345:6789:ABCD:EF01:2345:6789

2001:DB8:0:0:8:800:200C:417A

Note that it is not necessary to write the leading zeros in an
individual field, but there must be at least one numeral in every
field (except for the case described in 2.).

2. Due to some methods of allocating certain styles of IPv6
addresses, it will be common for addresses to contain long strings
of zero bits. In order to make writing addresses containing zero
bits easier, a special syntax is available to compress the zeros.
The use of "::" indicates one or more groups of 16 bits of zeros.
The "::" can only appear once in an address. The "::" can also be
used to compress leading or trailing zeros in an address.

Certains SBC compressent la première série de 0000, alors que d'autres compressent la dernière série de 0000.

Les SBC n’interprètent pas ces adresses comme étant identiques.

Les solutions, outre demander un correctif constructeur est de changer les adresses des SBC de telle sorte qu’elles ne contiennent pas deux espaces « :0: »