Bonjour,

J'en profite pour citer https://nrenum.net/ qui est un ENUM qui marche pour la 
recherche.
Tout semble exister pour répondre au besoin, ENUM, son implementations dans les 
softs et de la vrai prod.

Je cite également http://enumdata.org/#33 qui montre que la question de 
l'utilisation de e164.arpa à été étudié par l'ART à l'époque (avec Orange et 
SFR notamment)
Il y avait donc des gens qui y voyais un intérêt il y a 15ans, si ca n'a pas 
donné suite à l'époque, il y a peut être des choses à relancer avec l'ARCEP.

En attendant pour les intéressés, contacter les gens de nrenum.net pour avoir 
des info sur leur implementation serait surement enrichissant!

Cordialement,


> On 16 May 2018, at 08:16, Philippe Bourcier <phili...@frnog.org> wrote:
> 
> 
> Bonjour,
> 
> Un peu de top-posting pour la peine...
> 2 remarques basiques d'un point de vue (relativement) extérieur :
> 
> 1 - traiter la désagrégation de l'annuaire :
>    Votre besoin c'est un storage clé-valeur persistant. La clé c'est le 
> numéro de tel... la valeur c'est l'info de routage, codec, etc... le tout 
> dans un joli petit json, pratique à parser et à debugger. Franchement, avec 3 
> serveurs corrects blindés de RAM (répliqués sur un autre DC, histoire 
> d'assurer) et une solution type redis ou mieux (pour ce besoin précis), 
> couchbase, on peut faire tenir tous les numéros FR en désagrégé sans aucun 
> problème. Le tout avec une latence de moins de 10 ms par requête, réseau (sur 
> Paris) compris... bref, un truc totalement invisible au niveau téléphonie. 
> Ensuite on peut mettre cette data dispo via DNS (pdns backend) ou n'importe 
> quel autre système et/ou API...
> 
> 2 - le métier de l'interco (téléphonique, ici), ça me rappelle aussi le 
> métier d'IX :
>    Pourquoi une asso existante, tel France-IX, ne pourrait pas prendre le 
> problème à son compte et travailler sur cette question ? Après tout, c'est 
> une diversification économique intéressante (on peut imaginer un fixed-fee 
> mensuel pour accéder à ce service). Bien sure, son concurrent Equinix-IX 
> Paris pourrait faire de même, mais je crois qu'ils sont moins staffés... et, 
> pour le coup, avoir 2 systèmes opérés par 2 entités différentes, aurait un 
> certain intérêt en terme de redondance.
> 
> 
> Cordialement,
> Philippe Bourcier
> 
> On 2018-05-16 00:09, Nicolas Bougues wrote:
>> Bonsoir à tous,
>> 
>> Ca doit bien faire 10 ans que je n'ai pas posté ici mais j'ai déjà pas mal
>> réfléchi sur ce sujet d'interco SIP multi latérale.
>> 
>> Je me permets donc de vous exposer en quelques mots les principaux points
>> sur lesquels j'ai un avis.
>> 
>> D'un point de vue technique, ça tournerait autour de :
>> 
>>   - une poignée de proxys SIP, genre Kamailio par exemple, installés de
>>   façon géographiquement / topologiquement diversifiée, adressés en
>>   round-robin / failover
>>   - ces machines ne géreraient que la signalisation; le media serait routé
>>   directement entre les SBCs des opérateurs reliés; il serait donc laissé à
>>   l'appréciation de chaque opérateur s'il lui parait pertinent de se
>>   contenter, pour parler avec chaque opérateur, d'une interco publique,
>>   privée ou d'un hybride (VLAN sur un GIX, whatever)
>>   - la signalisation serait basée sur les specs SIP FFT (qui sont
>>   maintenant à peu près complètes et bien supportées), avec des
>>   recommendations plus étendues en ce qui concerne le media (codecs audio
>>   variés, video, T38...). Le SDP permet une négo pourquoi s'en priver ?
>>   - bien évidemment un filtrage d'IPs serait réalisé, chaque opérateur
>>   membre publiant sa liste d'IPs in/out pour sig et media, publication qui
>>   serait utilisée par les proxies pour filtrer en input et forwarder les
>>   appels, et diffusée aux membres pour accepter les flux media
>> 
>> En ce qui concerne le routage :
>> 
>>   - pour répondre à ce que j'ai vu plus haut dans la discussion, il semble
>>   difficile de "penser BGP" : la notion d'aggrégation (qui préside pourtant à
>>   l'attribution de tranches de 1000 ou 10000 numéros aux opérateurs par
>>   l'ARCEP) est complètement annihilée par la portabilité et autres exceptions
>>   (liste de numéros en routage TDM par exemple)
>>   - on est donc à peu près obligé d'avoir d'un côté un routage par défaut
>>   suivant l'opérateur attributaire de la tranche, avec un lookup unitaire sur
>>   une (voire des) base(s) d'exceptions; c'est de toute façon ce que font
>>   aujourd'hui tous les opérateurs (ne serait-ce que parce que le préfixage
>>   des numéros portés est facturable s'il n'est pas fait par l'opérateur
>>   appelant)
>>   - ces informations (tranches, portas...) sont aujourd'hui publiées sous
>>   forme de fichiers CSV ou de web services par l'APNF, qui le fait très bien
>>   - en ce qui concerne ENUM, c'est une belle idée sur le papier, mais j'ai
>>   plusieurs réserves :
>>      - ça nécessite la mise en place chez chaque acteur d'un DNS  précis
>>      et disponible; ça ne fait pas partie des choses "bien connues" chez les
>>      opérateurs telecom, même s'ils font de la VoIP
>>      - ça nécessite d'être mis à jour en temps réel et avec exactitude par
>>      l'attributaire d'un numéro lors d'une porta sortante; or il n'est pas
>>      exceptionnel qu'un attributaire ne réalise pas correctement leur part 
>> des
>>      portas sortantes (c'est-à-dire le reroutage vers le préfixe 
>> destination);
>>      dans un tel cas, une publication APNF par le prenant permet de régler
>>      l'essentiel du problème à l'échelle de 24h et sans le concours du 
>> cèdant;
>>      difficile d'imaginer revenir à un routage indirect seulement
>>      - Numérobis, en 2002, ça rappelle quelque chose à quelqu'un ? ;)
>>      - ma conclusion, c'est qu'il ne faut pas baser un tel projet sur
>>      ENUM, en tous cas au départ, et que si ENUM il devait y avoir,
>> une version
>>      centralisée (gérée par l'APNF ou sur la base des données APNF) serait
>>      sûrement souhaitable
>>   - en attendant, on peut donc simplement se dire que chaque opérateur
>>   émettant un appel vers la plate-forme est responsable d'avoir fait son
>>   homework et d'avoir déterminé si l'opérateur qu'il cherche à joindre est
>>   membre ou non
>> 
>> En ce qui concerne l'APNF :
>> 
>>   - je connais assez bien l'APNF c'est une petite équipe de bonne volonté,
>>   mais qui est "contrainte" dans le cadre de ses principaux membres, que sont
>>   Orange, SFR, Bouygues et Free. Quand je parle de contrainte, cela concerne
>>   aussi bien le scope des sujets sur lesquels ils travaillent (si ça
>>   n'intéresse pas les gros, il est peu probable que ça arrive) que la façon
>>   dont les sujets sont traités (je veux dire, sur un sujet potentiellement
>>   assez délicat comme celui-là, de discussions nombreuses, de spécifications
>>   détaillées, des consultants, de nouvelles discussions, d'appels d'offres,
>>   etc.)... Simplement à l'image de la façon dont les choses se passent chez
>>   ces gros opérateurs.
>>   - j'y ai déjà évoqué un tel projet, de façon très informelle; l'idée
>>   n'est pas nouvelle, mais c'est clairement hors du cadre de réflexion
>>   - néanmoins, il me parait indispensable d'éviter de dupliquer les
>>   efforts, et d'être notamment en mesure de s'appuyer sur le référentiel de
>>   données géré par l'APNF
>>   - or ces données ne sont pas publiques. Pour, il me semble, des raisons
>>   bonnes (éviter de divulguer des listes d'abonnés, par ex.) et moins bonnes
>>   (parfois un certain goût de l'entre-soi)
>>   - on pourrait donc imaginer une association alternative, qui serait
>>   elle-même membre de l'APNF (si les statuts de cette dernière le permettent,
>>   à voir), ou même, simplement, que tous les opérateurs concernés soient
>>   membres de l'APNF (on parle de 1000 EUR/an pour une adhésion de base),
>>   s'ils ne le sont pas déjà.
>> 
>> En ce qui concerne les considérations économiques d'un tel effort :
>> 
>>   - tout coûte !
>>   - dès lors qu'on sortirait de simples débats (ça, ça ne coûte que du
>>   temps!), il faudrait donc un modèle de financement pérenne
>>   - il me semble que la "clef" la plus juste serait le nombre de setups
>>   d'appels; c'est en effet à la fois :
>>      - représentatif de l'activité d'un membre (et donc du bénéfice qu'il
>>      tire de la plate-forme)
>>      - "orienté coûts", si on parle de machines qui ne gèrent que de la
>>      signalisation
>>      - incitatif à la qualité (ASR élevé, filtrer correctement les appels
>>      destinés à la plate-forme en amont) puisque on compterait aussi bien les
>>      appels qui aboutissent que ceux qui échouent
>>   - last but not least, il me semble utile, au moins dans un premier
>>   temps, de s'affranchir de toute notion économique inter-membres (la fameuse
>>   TA), pour des raisons de simplicité. Cela veut donc dire d'exclure les
>>   numéros SVA
>> 
>> Pour ce qui concerne l'ARCEP, je pense qu'il ne faut pas attendre d'eux (et
>> à raison) d'effort particulier; ils sont d'abord là pour réguler, autrement
>> dit s'assurer que le marché va dans le sens attendu (c'est-à-dire,
>> essentiellement, d'assurer une saine concurrence). Je ne sais pas quel
>> regard ils auraient sur une telle initiative; il faudrait simplement
>> s'assurer de ne rien faire qui contrevienne aux diverses Décisions qui
>> réglementent l'interconnexion (dont je ne suis pas un éminent spécialiste).
>> 
>> Enfin, c'est une évidence, un tel projet n'a de sens que s'il permet, à
>> terme, d'agréger un volume significatif de trafic, et donc d'acteurs. On
>> peut supposer que les opérateurs qui ont des "divop" ne seront pas très
>> chauds (puisque ce serait une partie de leur marché, le transit
>> inter-opérateur, qui disparaît). Mais je pense que la potentielle économie
>> de TA+transit (on parle de 0.0025 EUR/minute en moyenne) peut, à un certain
>> point, représenter une motivation financière suffisante. Après, il n'y a
>> plus qu'à amorcer la pompe ;)
>> 
>> Voilà mes 0.02cts et un peu plus.
>> 
>> Pour aller de l'avant, si Xavier peut nous mettre en place une ML, ça
>> serait super. Moi je peux héberger toute réunion sur Courbevoie, s'il y a
>> des parisiens motivés.
>> 
>> Enfin, je serai demain matin au séminaire OWF à la Bourse, peut-être
>> certains d'entre vous aussi ?
>> 
>> Le 15 mai 2018 à 13:58, Xavier ROCA <x.r...@sipleo.com> a écrit :
>> 
>>> Bonjour,
>>> 
>>> J'ai déjà évoqué le sujet en off avec certains d'entre vous qui sont dans
>>> la même logique.
>>> Et je me rappelle une discussion d'y a bien longtemps avec Franck SIMON.
>>> En échangeant sur ce que l'on faisait et une de nos envies, il a
>>> immédiatement dit ce serait pas mal qui y est une sorte IX pour la voix.
>>> 
>>> Je vois que l'idée que l'on traine depuis bientôt huit ou neuf ans a de
>>> l'écho et j'en suis ravi.
>>> Je souhaiterai que le début de flamme devienne un vrai feu, je me propose
>>> de structurer le début si cela vous semble pas illégitime.
>>> 
>>> En interne, on a déjà pensé plusieurs fois à cela.
>>> Cette après-midi, j'ai réorganisé nos plannings en interne pour regarder
>>> les propositions déjà faite depuis hier soir et de réfléchir aussi a fon
>>> sur ce sujet.
>>> 
>>> Il y a déjà dans la discussion de nombreuses tête bien faite et des gens
>>> plein de bon sens.
>>> il serait bien d'avoir avec nous un spécialiste des RFC comme un certains
>>> Stéphane Bortzmeyer (en plus on ne voit pas bien qui a écrit l'exemple enum
>>> sur wiki 😊) pour nous aider dans le formalisme et nous faire profiter de
>>> sa super connaissance autour de cela.
>>> 
>>> Déjà première étape structure le groupe de travail.
>>> Je propose de faire un Email en prive avec [IAV]  pour
>>> "Interco_Voix_Alternative" en balise pour en faciliter le traitement.
>>> On mettra en place une ML; xwiki et autres selon vos suggestions ça le
>>> sujet qui risque de prendre un peu de place et ce n'est peut-être pas la
>>> peine de polluer cette liste qui est très utiles pour pas mal d'autres
>>> sujets.
>>> 
>>> J'ai bien pensé a invité tout ce qui le souhaiterait à Faire un Boot Camp
>>> sur le sujet et d'organiser cela.
>>> Avec pauses et animations, faut pas abuser de trop non plus eau ou bière
>>> dans le Goblet ! (ou rosé si on veut du local)
>>> On a de la place pour cela mais on est juste en peu loin de certains après
>>> le coin est plutôt sympa (83)
>>> Si l'idée du format tente faut trouver la période et si on fait cela un
>>> week-end ou en semaine.
>>> 
>>> Xavier
>>> 
>>> -----Message d'origine-----
>>> De : boite frnog <mailbox.fr...@gmail.com>
>>> Envoyé : mardi 15 mai 2018 10:24
>>> À : frnog@frnog.org
>>> Objet : [FRnOG] [MISC] Peering SIP (was Problème interco orange)
>>> 
>>> Bonjour à tous,
>>> 
>>> Je me permets de créer un nouveau sujet. En effet, je pense que Xavier a
>>> raison, il est temps de faire bouger les choses. La crise d'hier est
>>> critique sur plein de plans, combien d'appels d'urgence n'ont pas été
>>> routés hier ? Mais sans aller aussi loin, c'est vrai que ça n'a pas évolué
>>> depuis un bout de temps...
>>> 
>>> J'ai cependant plusieurs questions à la liste.
>>> 
>>> Pourquoi ne pas faire du peering SIP, suivant le modèle du France XI (un
>>> France SIPIX ?) ? Est-ce que cette question a déjà été soulevée et si oui
>>> quels ont été les freins ?
>>> 
>>> Par modèle j'entends à la fois technique, mais aussi associatif.
>>> 
>>> C'est à dire un SBC centralisé joignable en interco IP sur TH2 permettant
>>> le routage entre opérateurs, mais aussi la proxyfication du RTP et pourquoi
>>> pas un nouveau modèle de billing.
>>> 
>>> DNS a été soulevé, c'est bien, mais quand bien même il inutile d'imaginer
>>> résoudre et faire du P2P entre les SBC des "petits opérateurs" pour pleins
>>> de raisons (notamment sécu, qualité de l'interco)...
>>> 
>>> Mais alors, comment échanger (annoncer) ses tranches SDA ? Je ne connais
>>> pas SIP-I mais je ne crois pas qu'une notion d'annonce existe...
>>> 
>>> Faudrait-il créer ce protocole (vecteurs) ? Après tout, les solutions
>>> opensource sont là.
>>> 
>>> Mais beaucoup plus simplement, est-ce qu’une base de données gérée par un
>>> tiers de confiance (l'asso) ne suffirait-elle pas à redistribué à ses
>>> membres les tranches connues par ce service ?
>>> 
>>> Charge aux opérateurs de monter ce second trunk et d'envoyer son trafic
>>> selon ses routes mises à jour dynamiquement sur son SBC...
>>> 
>>> Non ?
>>> 
>>> ---------------------------
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
>>> 
>>> 
>>> 
>>> ---------------------------
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org/
>>> 
> 
> -- 
> Philippe Bourcier
> web : http://sysctl.org/
> blog : https://www.linkedin.com/today/author/philippebourcier
> 
> 
> ---------------------------
> Liste de diffusion du FRnOG
> http://www.frnog.org/


---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/

Répondre à