Hello, On a fini ce soir de personnaliser le Tiki wiki. Ce n'est pas une volonté de faire super propres mais on a trouvé trois bugs dans la solution open source utilisé. Et un peu gênante : L'expédition de l'email pour valider l'inscription comporté plusieurs fois le SUBJECT. L'autre, le message tout pourri que l'on reçoit en Fran anglais. Et pour le trouver ça était un casse-tête car plus de synchro avec les fichiers de ressources langues. Bref on a fait en dur ... Faudra plus avoir d'inscription après une maj
Donc je lance les inscriptions ce soir et demain matin. La, je mets juste un petit sondage pour que vous votiez sur le logo qui vous plait le plus sur les cinq proposés. C'est juste pour le côté Fun et si un artiste a mieux on prend aussi. Jérôme tu pourra alimenter tout cela dedans, je commence par toi :) Xavier -----Message d'origine----- De : Jérôme Nicolle <jer...@ceriz.fr> Envoyé : vendredi 1 juin 2018 14:24 À : frnog@frnog.org Objet : [FRnOG] [TECH] Quelques idées et questions pour le peering voix Plop, Je n'ai pas encore rejoint le workgroup IAV, mais j'ai un peu réfléchi au sujet et j'ai plein de questions, étant plutôt novice en voix. Ma première idée était intuitivement d'utiliser un mécanisme proche à celui de BGP pour annoncer la joignabilité de numéros ou préfixes E.164. C'est une vielle idée qui a été spécifiée dans TRIP (RFC3219), dont plus aucune implémentation n'existe et qui semble n'avoir jamais été utilisé. Une autre possibilité est d'utiliser ENUM (RFC6116) qui, reposant sur le DNS, permet de gérer les délégations de zones pour matérialiser l'attribution d'un numéro, et les mises à jour en totale autonomie des possibilité de joindre ledit numéro. Il y a alors à gérer les horizons pour, par exemple, publier différentes préférences de joignabilité en fonction du point d'entrée de la requête (PNI, Voice-IX ou réseau public). Pour ENUM, on utiliserait dans ce cas un domaine racine différent du e164.arpa (3.3.e164.arpa pour la France) afin de ne pas perturber une éventuelle reprise du projet (voir http://enumdata.org/#33) qui serait alors susceptible de remplacer le système actuellement géré par l'APNF. En terme de sécurité, on peut probablement envisager que DNS-SEC soit utilisé pour valider les délégations ENUM, et que RPKI soit adapté à une version modernisée de TRIP. En imbriquant ces deux mécanismes, un Voice-IX proposerait donc - un Route Server BGP pour annoncer les DNS, gateway SIP et media sur l'IX - un Route Server TRIPv2 pour échanger les méta-données de routage d'appel (Préférence, multi-homing, TA…) voire les préfixes attribués pour constituer la zone ENUM - un serveur DNS pour la zone ENUM locale de l'IX, à défaut d'une zone publique - un routeur SIP optionnel pour la corrélation des CDR, surtout si le Voice-IX gère le clearing entre ses membres, façon Hopus J'ai rien oublié ? Ça vous parait cohérent ? Quelques questions du coup : - Avec un tel schéma d'interconnexion, comment est ce qu'on gèrerait les interceptions légales ? Je dirais que c'est au niveau de chaque porteur de numéro, pas au niveau IX, mais ça reste à clarifier - S'il y a valorisation des aboutements, est ce qu'on doit pouvoir permettre une fluctuation des prix pour permettre la spéculation sur les routes ? - Si oui, à quel endroit doit s'effectuer la prise de décision de LCR ? Route server ? Pair TRIPv2 ? - ENUM permet une méthode mailto:, est ce que ça peut signifier que l'opérateur de l'appelant peut gérer l'enregistrement d'un voicemail et son envoi par mail ? - Puisque ENUM repose sur le DNS, est ce qu'on peut envisager d'ajouter des enregistrements de localisation pour gérer la PFLAU ? - Est ce qu'on doit envisager un IRR-like pour les routes voix ? Dans le DNS ou en whois avec un RPSL-like ? - Qui porte la charge de certification des ressources ? Peut-on la déléguer de façon hiérarchique ? - Est ce qu'on doit établir un mapping ASN-ITAD (équivalent dans TRIP) ? - Si on gère le PDAU et la PFLAU au niveau ENUM, est ce qu'on a pas intérêt à demander au régulateur ou au ministère de l'intérieur de rendre le peering obligatoire au moins pour les appels d'urgences ? - Quid du caractère privé des enregistrement LOC s'ils sont inclus dans ENUM ? Whitelist des requérants ? Et pour les mobiles, on reste au domicile du souscripteur ou on fait établir des passerelles HLR -> ENUM ? - En combinant ENUM et TRIP toujours, on devrait permettre le multi-homing voix jusqu'à l'utilisateur final. Ça représente beaucoup de potentiel d'affaire et pourrait être indispensable pour les services d'urgence. Est ce qu'on doit le considérer comme un but ou une option ? Discussion ouverte, merci d'avance pour vos commentaires et réponses ! @+ -- Jérôme Nicolle 06 19 31 27 14 --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
