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/
