Le 17 mai 2018 à 14:00, Alexis <a...@gen-ip.fr> a écrit : > J'approuve également. DNS et ENUM répondent parfaitement à la demande > technique pour moi. Et un serveur DNS, on sait en faire depuis les débuts > d'internet, on sait que ça tourne, c'est fiable, robuste, basique. Tout le > monde peut en avoir chez soit sans avoir besoin d'un serveur avec 50000Go > de RAM pour tenir 100 millions de routes BGP. Ça répond juste au "KISS" : > keep it simple and stupid. > > D'ailleurs, je ne suis pas expert DNS, mais on peut pas juste avoir > quelque chose du genre "l'APNF met un serveur DNS master et déclare les IP > des serveurs DNS des opérateurs autorisés a avoir des DNS escalves du > serveur de l'APNF. Chaque opérateur interroge son serveur enum esclave > local, copie exacte du DNS master de l'APNF" ? C'est du très basique, > minimaliste et ça évite aux opérateurs frileux/pas transparents de publier > dans un annuaire public les numéros qu'ils gèrent. >
*Dans tout les cas ce type de DNS ne devront jamais être publics à mon sens (même si l'idée d'origine d'ENUM est de s'ouvrir sur l'INTERNET ;) )* *Si on pousse l'idée en effet le mieux serait d'avoir des DNS autoritaires chez l'asso, puis des résolveurs dans les réseaux internes des providers.* > > Par contre, ça laisse toujours des questions administratives. Quid des > appels d'urgence ? De la validation des demandes d'ajout dans le domaine > enum ? De la facturation inter-opérateurs (taxe d'acheminement ... vraiment > utile de la conserver, franchement ?) ? Dispo uniquement sur un France-IX > like avec QoS ? etc. > *- Numéros d'urgence: ça ne change rien pour moi, il faut les traduire puis envoyer comme un SDA "normal".* *- la TA est importante pour certains et beaucoup moins pour d'autres et la population intéressée par ce type de projet seront les "autres",ok , mais c'est sensible quand même ;)* *- QOS: il faudra dans tout les cas passer par un réseau IP avec QOS entre provider, donc oui QOS obligatoire* > > Alexis Prodhomme > Support Technique Gen-IP > email : supp...@gen-ip.fr > tel : 02.90.75.30.50 > > Le 17/05/2018 à 12:08, Mickael Hubert a écrit : > >> Bonjour à tous, >> >> Le 17 mai 2018 à 11:19, Richard DEMONGEOT <rich...@demongeot.biz> a >> écrit : >> >> Hello, >>> >>> Toutes les idées a base de BGP sont très sexy, et intéressantes, mais il >>> reste un problème de base. Comment chaque opérateur va devoir implémenter >>> un composant liant BGP / Voix. >>> Cependant, comme évoqué à plusieurs reprises, pas de modifications >>> incessantes de la table de routage voix. >>> >>> >> *Pour ma part le composant de routage pour la voix devrait-être le DNS >> (ENUM), je sais j'insiste sur ce point ;) , mais devoir trouver / >> développer un composant "gateway" entre BGP et voix pour gérer du trafic >> de >> prod me semble hasardeux.* >> *Bon, ce composant existe peut-être déjà, je ne sais pas...* >> >> >> >> Pour la table de routage internationale, OSEF dans un IX. (ou alors, c'est >>> un GIE, donc avec plusieurs fournisseurs, et c'est plus complexe). Dans >>> tous les cas, les changements sur les non-membres : on s'en fout. (porta >>> depuis / vers les membres à gérer uniquement). Exemple : porta orange / >>> sfr >>> : quel impact vu qu'a moyen terme aucun des deux ne sera dessus? Pire, >>> belgacom / proxymus? >>> >>> Pour moi, le plus simple, sur, rapide, fonctionnel reste : >>> >>> Un IX dédié à la voix (qu'on peut multiplier à souhaits). >>> Sur cet IX : >>> - Chaque membre qui s'y connecte doit y mettre un ou plusieurs SBC; >>> - L'association fourni un ou plusieurs proxy SIP - en guise de voice >>> route >>> server. >>> >>> Coût pour l'association : >>> 1 switch (1G/10G de préférence); >>> 3 serveurs (db + proxy). >>> >>> Le cheminement serai alors le suivant : >>> Le SBC du client envoie son INVITE SIP, sur le / l'un des proxy. >>> Le proxy intérroge la DB, fournie par l'APNF, et route sur le bon membre. >>> => Si c'est pas sur un membre, alors plusieurs cas sont possibles : >>> A/ L'association renvoi un code retour temporaire ou permanent sur ce >>> numéro (pas routable sur l'IX); >>> B/ L'association étant un GIE, et disposant de contrat de terminaison SIP >>> peut router le numéro. ==> Quid de la facturation/re-facturation? Par >>> contre, économie d'échelle si les contrats sont mutualisés. >>> => Si le membre ne réponds pas (SIP option réguliers) alors on réponds >>> une >>> erreur temporaire. (ou on load balance sur moins d'IP si le membre a >>> plusieurs SBC) >>> >>> >> *Chaque provider connecté au X doit avoir une réplication de la DB. Car si >> tout est géré (au niveau routage voix par le X) nous nous retrouverons >> dans >> le même cas (plantage d'Orange) si celui-ci plante.* >> >> >> *De plus, cela engendre du trafic SIP (et des réponses) pour pas grand >> chose.* >> >> *Je voyais cela plutôt:* >> >> *- lors de l'import de la DB APNF chez le provider, celui-ci sait qui se >> trouve connecté sur tel ou tel X et donc créé sa propre DB avec tel >> préfixe >> vers tel X (donc telle IP), puis tel préfixe vers l'autre X, etc ... (cela >> peut-être automatisé, voir même si on parle d'asso en plus de l'APNF, >> celle-ci pourrait fournir une DB modifiée avec les préfixes quelle gère)* >> >> *- lors d'un appel vers tel numéro hors de son réseau, la DB chez le >> provider sait où envoyer au plus proche* >> *- Sinon on envoie par défaut sur son transitaire voix (du genre Orange ;) >> )* >> >> >> >> >> Dans les deux cas, ralentissement de l'établissement de quelques >>> milli-secondes pour le SBC appelant, c'est largement acceptable pour >>> fall-back sur un autre fournisseur. >>> >>> Dans le modèle IX, je préfère l'option A, qui simplifie le boulot pour >>> l'asso. >>> >>> Et pour la croissance me direz vous? >>> Là encore, deux options : >>> A/ On déploie un IX dans chaque DC, en se moquant complètement de >>> l'interco, c'est à dire que chaque POP est stand-alone; (coûts multipliés >>> par le nombre de POP) >>> >>> B/ On déploie un réseau multi DC (donc plus complexe), et les membres de >>> l'interco Lyon peuvent taper sur des ressources Bordeaux. Pour les SBC >>> des >>> clients, c'est simple, ils mettent une interface en /28 sur le POP, et >>> une >>> route vers la /22. (coût qui ne sont pas proportionnels au nombre de POP, >>> mais besoin d'équipement L3 pour gérer le backbone). >>> >>> Point bonus de la solution B, le proxy peut être anycasté entre plusieurs >>> POP. >>> >>> Dans tous les cas, l'asso ne gère pas de transcoding (les membres >>> envoient >>> le RTP de pair à pair); >>> Tant que tous les membres respectent un critère simple, supporter au >>> moins >>> le G.711, tout est inter-opérable; >>> Si deux membres veulent jouer avec de la visio, ou des codec de plus >>> haute >>> qualité, ça n'a aucun impact sur les autres. >>> Les membres n'ont pas à avoir de connaissances BGP (je sais, on est sur >>> frnog, le BGP c'est simple) >>> >>> >> *100% d'accord le X ne doit pas s'embêter avec du temps réel et du >> transcoding.* >> >> *chaque provider est assez grand pour se mettre d'accord avec son >> destinataire (vive le SDP)* >> >> >> Avec juste le proxy sur les invite (donc initiation d'appel), l'asso ne >>> peut pas influer sur la qualité de la voix (mono POP). >>> Celle-ci est garantie, vue que les SBC parlent entre eux sur le même >>> subnet. Dans le cas d'un réseau multi-pop, c'est plus complexe. >>> >>> Côté revenus de l'association, les options seraient : >>> - coût au port d'interconnexion - fixe; >>> - coût à la BP réellement utilisée; >>> - coût d'initiation (ie par appel - mais complètement incohérent pour >>> moi). >>> >>> Et pour moi, l'asso est gérée par ses membres, avec une évolution vers un >>> GIE à terme : >>> Besoin de quelques SBC propres à l'association, de contrats de transit >>> Orange / SFR / BICS / ... et LCR vers ces destinations >>> >>> Cordialement, >>> >>> >>> Le 2018-05-16 09:48, David Ponzone a écrit : >>> >>> Je balance une idée en l’air entre 2 tartines. >>>> >>>> Si on prenait quelques octets en plus devant le numéro de téléphone >>>> pour y mettre le préfixe de porta (celui de l’ARCEP si l’opérateur en >>>> a un, sinon un attribué par l’association). >>>> Ainsi, le SBC de l’opérateur a toutes les infos dans la route. >>>> L’AS et le next-hop, c’est celui du RS de l’IX-Voix de toute façon, >>>> car pour moi c’est un IX dont les membres peerent seuleement avec le >>>> RS, qui est un tiers de confiance qui envoie une information >>>> contrôlée. >>>> Le SBC de l’opérateur peut alors récupérer le préfixe de porta dans la >>>> route. >>>> Si le prefixe de porta est 10000 par exemple, il cherche dans une >>>> table interne ou alors il fait un lookup DNS pour avoir les champs TXT >>>> par exemple de la zone 10000.domain.gtld, qui vont contenir les >>>> différentes IP des SBC auxquels il faut envoyer l’appel (soit les SBC >>>> de l’autre opérateur, soit ceux de l’IX, en fonction du modèle >>>> technico-économique choisi). >>>> >>>> --------------------------- >>>> Liste de diffusion du FRnOG >>>> http://www.frnog.org/ >>>> >>>> >>> --------------------------- >>> Liste de diffusion du FRnOG >>> http://www.frnog.org/ >>> >>> --------------------------- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ >> > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
