Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
Bof, ca s'automatise a tous les niveaux si vous filez des API bien foutus. Trunk, plans de num etc... Le 18/05/2018 à 13:55, David Ponzone a écrit : > Moyennement gérable s’il y a 30/40 acteurs quand même… > > > On 18 mai 2018 13:54 +0200, Sébastien Lesimple > , wrote: >> Hello, >> >> Si je devais remonter ma solution tech, la seule chose dont j'aurais >> besoin, c'est le plan de num de chaque membre en fichier à plat dans un >> SFTP (avec sa fréquence de mise a jour) et un trunk vers le membre >> détenteur de ND. Les SLA et les CAPS de chacun pour pas bastonner trop >> fort et c'est tout... >> >> En fait c'est déjà comme cela que je faisais en 2006, rien de nouveau. >> Les usines a gaz ou je maitrise pas la terminaison, j'ai vécu avec >> Viatel... >> Merci, mais non merci! >> >> Seb. >> >> Le 17/05/2018 à 12:08, Mickael Hubert a écrit : >>> Bonjour à tous, >>> >>> Le 17 mai 2018 à 11:19, Richard DEMONGEOT 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 si
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
Encore plus simple, l'info de routage envoyée dans le SIP URI pour indiquer ou envoyer le trafic et roulez bolides... Pas besoin de tripatouiller le RTC, vous traitez uniquement la SIG comme il se doit, rien d'autre. Seb. Le 18/05/2018 à 13:53, Sébastien Lesimple a écrit : > Hello, > > Si je devais remonter ma solution tech, la seule chose dont j'aurais > besoin, c'est le plan de num de chaque membre en fichier à plat dans un > SFTP (avec sa fréquence de mise a jour) et un trunk vers le membre > détenteur de ND. Les SLA et les CAPS de chacun pour pas bastonner trop > fort et c'est tout... > > En fait c'est déjà comme cela que je faisais en 2006, rien de nouveau. > Les usines a gaz ou je maitrise pas la terminaison, j'ai vécu avec Viatel... > Merci, mais non merci! > > Seb. > > Le 17/05/2018 à 12:08, Mickael Hubert a écrit : >> Bonjour à tous, >> >> Le 17 mai 2018 à 11:19, Richard DEMONGEOT 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). >>> >>> Poin
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
Moyennement gérable s’il y a 30/40 acteurs quand même… On 18 mai 2018 13:54 +0200, Sébastien Lesimple , wrote: > Hello, > > Si je devais remonter ma solution tech, la seule chose dont j'aurais > besoin, c'est le plan de num de chaque membre en fichier à plat dans un > SFTP (avec sa fréquence de mise a jour) et un trunk vers le membre > détenteur de ND. Les SLA et les CAPS de chacun pour pas bastonner trop > fort et c'est tout... > > En fait c'est déjà comme cela que je faisais en 2006, rien de nouveau. > Les usines a gaz ou je maitrise pas la terminaison, j'ai vécu avec Viatel... > Merci, mais non merci! > > Seb. > > Le 17/05/2018 à 12:08, Mickael Hubert a écrit : > > Bonjour à tous, > > > > Le 17 mai 2018 à 11:19, Richard DEMONGEOT 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). > > > >
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
Hello, Si je devais remonter ma solution tech, la seule chose dont j'aurais besoin, c'est le plan de num de chaque membre en fichier à plat dans un SFTP (avec sa fréquence de mise a jour) et un trunk vers le membre détenteur de ND. Les SLA et les CAPS de chacun pour pas bastonner trop fort et c'est tout... En fait c'est déjà comme cela que je faisais en 2006, rien de nouveau. Les usines a gaz ou je maitrise pas la terminaison, j'ai vécu avec Viatel... Merci, mais non merci! Seb. Le 17/05/2018 à 12:08, Mickael Hubert a écrit : > Bonjour à tous, > > Le 17 mai 2018 à 11:19, Richard DEMONGEOT 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é,
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
sauf que d'un point de vue opérateur de transit, c'est pas dans leur intérêt de te donner les informations de LCR de façon clair. La communauté pour la factu est utile, mais ne sera pas en pratique utilisé par ceux chez qui celà serait utile. D'un point de vue LCR horaire on a le soucis du temps de convergance BGP, on peut se retrouver sur des périodes de quelques minute a faire passer les appels sur un LCR pas approprié. Pour régler ce soucis il faut deux communauté : une communauté pour la plage actuelle et une communauté pour la plage suivante avec le timestamp de début. Ca permet de palier le temps de convergence. Cordialement Le 17 mai 2018 à 22:09, Jérôme Nicolle a écrit : > David, > > Le 15/05/2018 à 20:18, David Ponzone a écrit : > >> Ce qui me dérange, c’est que vous semblez oublier qu’une plage de numéros >> client c’est par exemple un /36 dans ton exemple (ZABPQMCD), mais il arrive >> souvent qu’un numéro ait été sorti pour une ligne analogique (fax) donc ton >> /36 devient 9 /40. >> Difficile d’évaluer le nombre de routes que ça représente, probablement >> gérable entre opérateurs petits, mais si un SFR ou Free se pointe, ça va >> faire mal (les particuliers ont tous un /40, et rien à aggréger). >> > > Dans le cas du routage voix on a pas du tout le même problème qu'avec l'IP > : le lookup ne doit être fait qu'une fois par session, et il peut prendre > quelques ms. Du coup le nombre de préfixe n'est qu'un problème de RAM sur > le speaker MP-BGP, qui va de toute façon pousser ses updates dans une "FIB" > à base de SQL ou d'ENUM en fonction des implémentations. > > On a donc pas de problème à gérer les 48 bits que requièrent le codage > d'un numéro E.164, même si on devait les désagréger dans de très nombreux > cas. > > Si on confirme la piste d'utiliser MP-BGP pour les annonces de préfixes et > portabilités, alors on aurait à définir des communautés pour l'encodage de > la tarification d'acheminement. Cela règlerait une fois pour toute la > problématique d'implémentation d'un Least Cost Routing dynamique. > > En outre, les modifications temporelles de routage sont faciles à gérer, > puisqu'il suffit d'un update MP-BGP à chaque changement de plage horaire. > > Globalement ça semble permettre de traiter en amont tout le merdier de > redirections d'aboutement. > > @+ > > -- > Jérôme Nicolle > +33 6 19 31 27 14 > > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
David, Le 15/05/2018 à 20:18, David Ponzone a écrit : Ce qui me dérange, c’est que vous semblez oublier qu’une plage de numéros client c’est par exemple un /36 dans ton exemple (ZABPQMCD), mais il arrive souvent qu’un numéro ait été sorti pour une ligne analogique (fax) donc ton /36 devient 9 /40. Difficile d’évaluer le nombre de routes que ça représente, probablement gérable entre opérateurs petits, mais si un SFR ou Free se pointe, ça va faire mal (les particuliers ont tous un /40, et rien à aggréger). Dans le cas du routage voix on a pas du tout le même problème qu'avec l'IP : le lookup ne doit être fait qu'une fois par session, et il peut prendre quelques ms. Du coup le nombre de préfixe n'est qu'un problème de RAM sur le speaker MP-BGP, qui va de toute façon pousser ses updates dans une "FIB" à base de SQL ou d'ENUM en fonction des implémentations. On a donc pas de problème à gérer les 48 bits que requièrent le codage d'un numéro E.164, même si on devait les désagréger dans de très nombreux cas. Si on confirme la piste d'utiliser MP-BGP pour les annonces de préfixes et portabilités, alors on aurait à définir des communautés pour l'encodage de la tarification d'acheminement. Cela règlerait une fois pour toute la problématique d'implémentation d'un Least Cost Routing dynamique. En outre, les modifications temporelles de routage sont faciles à gérer, puisqu'il suffit d'un update MP-BGP à chaque changement de plage horaire. Globalement ça semble permettre de traiter en amont tout le merdier de redirections d'aboutement. @+ -- Jérôme Nicolle +33 6 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
Le 17 mai 2018 à 14:00, Alexis 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 5Go > 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 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 (do
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
Hello, Le 2018-05-17 12:08, Mickael Hubert a écrit : Bonjour à tous, Le 17 mai 2018 à 11:19, Richard DEMONGEOT 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...* On est bien d'accord sur ce point. A ma connaissance, le connecteur n'existe pas, et serai assez lourd à faire. 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.* Pas tout à fait. A partir du moment ou cet IX n'est qu'une optimisation, sa perte fait basculer par les fournisseurs de terminaison officielle. Donc léger ralentissement, mais pas de coupure franche. *De plus, cela engendre du trafic SIP (et des réponses) pour pas grand chose.* Pourquoi plus de SIP? ça génère un message à traiter par l'IX. Soit le destinataire est sur l'IX, et c'est la même chose, soit le destinataire n'y est pas, et en effet, il y a un ré-essai. Mais comme quand ton fournisseur te rejette l'appel pour une raison X ou Y. *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)* Donc chacun dois être membre de l'APNF, et chacun dois implémenter une partie de l'algo de routage. Quid si l'asso fourni un lookup ENUM, remplis selon l'APNF, avec les peers mettons au hasard : - Pseudo IX - EquinixIX - France-IX ? Il faut faire des lookups de chaque IX. Et cela impose à chaque membre d'autoriser les IPs des SBC partenaires sur leurs SBC. Donc ils ne sont plus privés, et pour certains c'est compliqué. Exemple, mon SBC est dans une VRF voix, je ne veut pas le rendre public. Le mettre sur un IX "voix", oui et router tout le /22 ça ne me choque pas. Les ACL sont simples. Par contre, addresser du France-IX ou du tartempion Telecom sur une IP publique c'est beaucoup plus génant. La bonne idée pourrai être, de mutualiser les deux. D'un coté le proxy SIP sur l'IX, qui permet de router en direct, et de l'autre, de fournir un lookup enum à jour (basé sur l'APNF). Comme ça, le SBC client peut faire le lookup, si c'est sur l'IX, alors envoyer, sinon ne pas essayer :). Certes la logique de routage est "mono entité", mais une entité qui n'est pas un mastodonte sur le quel on a aucun pouvoir. Certes il y a un risque de panne, à mon sens contournable par le fait qu'il existe les transit. Comme pour le peering BGP, aucun scrupule a couper si il y a le moindre doute. *- 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
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
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 5Go 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. 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. 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 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 client
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
Bonjour à tous, Le 17 mai 2018 à 11:19, Richard DEMONGEOT 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 : > -
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
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 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) 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) 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 1 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 1.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). On 16 mai 2018 09:08 +0200, Alexis Lameire , wrote: Raphaël, Ta remarque est pertinente sauf que ton plan de num est différent selon le pays, donc c'est
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
Re, On est déjà dans MISC, donc je me permets une digression "software". Backend sur une base repliquée / shardée type MongoDB, un truc du genre, et ça doit pouvoir scaller des milliards de mapping. MongoDB : At scale, y en a qu'ont essayé... ils ont eut des problèmes (et pas qu'un peu). La version (3.41) qui a priori ne perd plus systématiquement de data (embêtant pour une db) et fonctionne enfin correctement date de (seulement) fin Décembre 2016... (on est à la 3.6)... avant cela nombre d'utilisateurs ont eu de très très gros problèmes (google it...) avec ce bout de code faussement "open-source". En effet, la boîte qui édite le soft n'en avait rien à faire des problèmes évidents (pendant des années... les premiers rapports de problèmes sérieux que tu peux trouver datent de 2013) qui lui ont été reportés, même par leurs clients... et cela même quand ceux-ci proposaient des patchs pour résoudre les problèmes en question (du coup ca sert à quoi de se prétendre open-source ?). IMHO, les mecs ont fini par fournir leur db "dans le cloud", peut-être parce qu'ils sont les seuls à avoir réussi à la faire tourner "at scale" (on parle de centaines et milliers de serveurs). Le minimum que tu puisses exiger d'un système en cluster c'est de pouvoir auto-scaler en mode "fire and forget"... Hors, la majorité de leurs témoignages clients c'est sur du use-case "embedded" avec un framework JS... donc sans aucun cluster. Alors certes, ce qu'ils ont fait dans le passé ne présage pas la qualité de leur travail actuel, mais donne une bonne idée de l'état d'esprit. Du coup c'est pour cela que j'ai plutôt parlé précédemment de redis et couchbase qui eux ont un track record sans tâches d'huiles, pour faire la même chose, mieux (multi-master, répli cross-DC...) et avec de meilleurs perfs (de par leur historique "in-memory"). Et côté devs couchbase = devs de memcached + couchdb et redis = antirez, auteur de hping... :) Par contre, comme toi, je confirme qu'avec quelques serveurs, tu peux faire tenir largement toute la db FR sans problème de perf (surtout vu le très faible nombre de writes/sec)... et avec quelques centaines de serveurs, toute la db worldwide des numéros de téléphones de la planète. En plus, ce qui est cool avec une db sans schéma/NoSQL, c'est que tu peux ajouter une feature (un record dans chaque json) en mettant à jour au fil de l'eau et sans rien casser sur les softs existants... C'était la minute software/NoSQL at scale... Cordialement, -- Philippe Bourcier web : http://sysctl.org/ blog : https://www.linkedin.com/today/author/philippebourcier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
Sinon, il reste LISP. On prend l'e164 en EID, et une @IPv6 en RLOC (ça ne marchera que pour la VoIP) ou bien l'adresse SS7 (pour le legacy). C'est un système à base de mapping, donc de la grosse DB, et là, c'est quand même carrément statique le bordel (on swappe pas de n° de tel tous les jours, et les IPv6 pour 99% des besoins non plus, vu que de l'extérieur, l'IPv6 sera surement celle du PxTR et non celle du device final, donc un truc stable dans le temps). Backend sur une base repliquée / shardée type MongoDB, un truc du genre, et ça doit pouvoir scaller des milliards de mapping. Et puis pour une fois qu'on pourrait trouver une application concrète à ce protocole :D Le 16 mai 2018 à 18:27, Guillaume Barrot a écrit : > D'où mon analogie à EVPN. On summarise pas les @Macs. Depuis les > portabilités de n°, on ne peut plus summariser les routes SS7 non plus :). > Bref, c'est bien du routage de "/32" pour n millions de clients, mais ça > reste ultra statique. > > Le 15 mai 2018 à 20:18, David Ponzone a écrit : > >> Ce qui me dérange, c’est que vous semblez oublier qu’une plage de numéros >> client c’est par exemple un /36 dans ton exemple (ZABPQMCD), mais il arrive >> souvent qu’un numéro ait été sorti pour une ligne analogique (fax) donc ton >> /36 devient 9 /40. >> Difficile d’évaluer le nombre de routes que ça représente, probablement >> gérable entre opérateurs petits, mais si un SFR ou Free se pointe, ça va >> faire mal (les particuliers ont tous un /40, et rien à aggréger). >> >> J’ai raté un truc ? >> >> On 15 mai 2018 20:07 +0200, Alexis Lameire , >> wrote: >> > Hello frnog, >> > >> > Je ne suis pas un spécialiste voix, mais je suis aussi convaincu qu'il >> y a >> > des choses a faire avec une extensions à BGP. Je vais rajouter my 2 >> cent au >> > schmilblick >> > >> > qu'est ce qui fait que BGP c'est le bien : >> > * l'aggrégation des prefix >> > * l'algo dee routage déjà tout fait >> > * la responsabilité du routage laissé à chaque acteurs de la boucle >> > * l'ouverture a d'autre protocole. >> > >> > Déjà premier truc dont je suis pas d'accord, la RFC sur l'EVPN me semble >> > pas trop adapté, j’aurais tendance à me basé sur l'extension vpnv4. >> > >> > On a besoin en premier lieux de définir des zones cloisonnées de >> routages, >> > avec un numéro d'identification par pays. Dans ce cadre la, le country >> code >> > peut être utiliser. >> > Ensuite chaque entité à besoin d'être identifié à la fois de façon >> globale >> > et de façon locale. L'identité sur internet me semble être un numéro >> d'AS >> > enregistrer auprès d'un RIR il n'y a pas à tortiller mille an. Par >> contre >> > d'un point de vue local cela dépend de l'entité administrative locale. >> Dans >> > le cadre de la france, l'ARCEP. On pourrait par exemple concevoir le >> numéro >> > d'enregistrement auprès de l'ARCEP comme une bonne variable >> > d'identification. Mais il s'agit d'un champ de taille fixe dépendant du >> > pays. >> > >> > Le second élément à prendre en compte est l’agrégation. Nous avons un >> > soucis avec tous les plan de numérotation c'est qu'ils sont conçu en >> base >> > 10 et non dans une puissance de 2. Il faut donc trouver un codage >> > intelligent. Je propose de coder les routes et les masques en >> > BCD[1] >> > >> > ainsi la EZABPQ 011234 se code avec : >> > un prefix binaire représenté en hexa : 01:12:34:00:00 >> > un masque binaire représenté en hexa : FF:FF:FF:00:00 >> > >> > On peut ainsi employer la notation CIDR en 01:12:34:00:00/24 les routes >> > spécifique étant en /40 >> > >> > Il faut maintenant fournir les services d'un serveur de route auprès des >> > différents opérateur. Un bon serveur de route se doit : >> > * de vérifier la validité de ses membres : on peut ici utiliser RPKI, il >> > faut simplement héberger les clef au niveau de l'APNF ou avoir une >> > procédure auprès de l'iX pour vérifier la validité du peer. >> > * de vérifier les bogon : comme certains transitaire vont vérifier les >> > bases des RIR, la ressource de numérotion peut être vérifié auprès de >> > l'APNF. >> > * de vérifier la sécurité des annonce : on a une RFC qui est récente : >> > BGPSEC >> > >> > La ou ça s'arete, c'est qu'en pratique les règle d'interco peuvent >> différer >> > d'un opérateur à l'autre et il faut pouvoir prendre en compte ces >> > changement. Les informations de numérotation sont ainsi à fournir à la >> > brique du backbone de l'opérateur téléphonique qui gére le LCR (pas la >> NUM, >> > on a toujours le cas des numéro d'urgence qui sont à réencoder et qui ne >> > sont pas adapté à BGP (le cas des numéros qui changent selon l'heure)). >> > C'est aussi nécessaire par ce que l'opérateur doit être en mesure >> > d'appliquer des mesures anti fraude avant de transférer le trafic à >> > l'I-SBC. >> > >> > Pour gérer l'interco au niveau du SBC il faut aussi prévoir deux champ >> > obligatoire avec l'addresse du peer sur l'IX ainsi que la norme >> d'interco >> > suivie. Ceci est nécessaire par ce
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
D'où mon analogie à EVPN. On summarise pas les @Macs. Depuis les portabilités de n°, on ne peut plus summariser les routes SS7 non plus :). Bref, c'est bien du routage de "/32" pour n millions de clients, mais ça reste ultra statique. Le 15 mai 2018 à 20:18, David Ponzone a écrit : > Ce qui me dérange, c’est que vous semblez oublier qu’une plage de numéros > client c’est par exemple un /36 dans ton exemple (ZABPQMCD), mais il arrive > souvent qu’un numéro ait été sorti pour une ligne analogique (fax) donc ton > /36 devient 9 /40. > Difficile d’évaluer le nombre de routes que ça représente, probablement > gérable entre opérateurs petits, mais si un SFR ou Free se pointe, ça va > faire mal (les particuliers ont tous un /40, et rien à aggréger). > > J’ai raté un truc ? > > On 15 mai 2018 20:07 +0200, Alexis Lameire , > wrote: > > Hello frnog, > > > > Je ne suis pas un spécialiste voix, mais je suis aussi convaincu qu'il y > a > > des choses a faire avec une extensions à BGP. Je vais rajouter my 2 cent > au > > schmilblick > > > > qu'est ce qui fait que BGP c'est le bien : > > * l'aggrégation des prefix > > * l'algo dee routage déjà tout fait > > * la responsabilité du routage laissé à chaque acteurs de la boucle > > * l'ouverture a d'autre protocole. > > > > Déjà premier truc dont je suis pas d'accord, la RFC sur l'EVPN me semble > > pas trop adapté, j’aurais tendance à me basé sur l'extension vpnv4. > > > > On a besoin en premier lieux de définir des zones cloisonnées de > routages, > > avec un numéro d'identification par pays. Dans ce cadre la, le country > code > > peut être utiliser. > > Ensuite chaque entité à besoin d'être identifié à la fois de façon > globale > > et de façon locale. L'identité sur internet me semble être un numéro d'AS > > enregistrer auprès d'un RIR il n'y a pas à tortiller mille an. Par contre > > d'un point de vue local cela dépend de l'entité administrative locale. > Dans > > le cadre de la france, l'ARCEP. On pourrait par exemple concevoir le > numéro > > d'enregistrement auprès de l'ARCEP comme une bonne variable > > d'identification. Mais il s'agit d'un champ de taille fixe dépendant du > > pays. > > > > Le second élément à prendre en compte est l’agrégation. Nous avons un > > soucis avec tous les plan de numérotation c'est qu'ils sont conçu en base > > 10 et non dans une puissance de 2. Il faut donc trouver un codage > > intelligent. Je propose de coder les routes et les masques en > > BCD[1] > > > > ainsi la EZABPQ 011234 se code avec : > > un prefix binaire représenté en hexa : 01:12:34:00:00 > > un masque binaire représenté en hexa : FF:FF:FF:00:00 > > > > On peut ainsi employer la notation CIDR en 01:12:34:00:00/24 les routes > > spécifique étant en /40 > > > > Il faut maintenant fournir les services d'un serveur de route auprès des > > différents opérateur. Un bon serveur de route se doit : > > * de vérifier la validité de ses membres : on peut ici utiliser RPKI, il > > faut simplement héberger les clef au niveau de l'APNF ou avoir une > > procédure auprès de l'iX pour vérifier la validité du peer. > > * de vérifier les bogon : comme certains transitaire vont vérifier les > > bases des RIR, la ressource de numérotion peut être vérifié auprès de > > l'APNF. > > * de vérifier la sécurité des annonce : on a une RFC qui est récente : > > BGPSEC > > > > La ou ça s'arete, c'est qu'en pratique les règle d'interco peuvent > différer > > d'un opérateur à l'autre et il faut pouvoir prendre en compte ces > > changement. Les informations de numérotation sont ainsi à fournir à la > > brique du backbone de l'opérateur téléphonique qui gére le LCR (pas la > NUM, > > on a toujours le cas des numéro d'urgence qui sont à réencoder et qui ne > > sont pas adapté à BGP (le cas des numéros qui changent selon l'heure)). > > C'est aussi nécessaire par ce que l'opérateur doit être en mesure > > d'appliquer des mesures anti fraude avant de transférer le trafic à > > l'I-SBC. > > > > Pour gérer l'interco au niveau du SBC il faut aussi prévoir deux champ > > obligatoire avec l'addresse du peer sur l'IX ainsi que la norme d'interco > > suivie. Ceci est nécessaire par ce qu'on ne souhaite pas que les RR gére > le > > dataplane. > > > > Ceci clos la partie purement voix. Pour gérer l'interco sur l'IX et > éviter > > le L2 il faudra aussi prévoir une interco BGP classique sur le routeur en > > aval du I-SBC pour redistribuer les routes pour joindre les SBC des > copain. > > Mais rien de bien complexe. > > > > Enfin, d'un point de vue facturation, ayant dans les annonces BGP le > numero > > d'enregistrement auprès de l'APNF il est facile de mettre ça dans les CDR > > pour se refacturer entre copain. On pourrait même concevoir que l'IX > > fournisse la liste des adresse de facturation de ses membre pour > simplifier > > les choses voir pour les plus petit prenne en charge la refacturation > > contre quelques % des sommes dues. > > > > C'était un long pavé, mais je veux bien vos avis :) > > Cordialement
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
Xavier, je suis intéressé pour faire partie de la ML PS : d’après ton 1er email : " [IAV] pour "Interco_Voix_Alternative" " , c'est donc la balise IVA pas IAV ;) 2018-05-16 10:04 GMT+02:00 Radu-Adrian Feurdean < fr...@radu-adrian.feurdean.net>: > On Tue, May 15, 2018, at 20:18, David Ponzone wrote: > > Ce qui me dérange, c’est que vous semblez oublier qu’une plage de > > numéros client c’est par exemple un /36 dans ton exemple (ZABPQMCD), > > mais il arrive souvent qu’un numéro ait été sorti pour une ligne > > analogique (fax) donc ton /36 devient 9 /40. > > Difficile d’évaluer le nombre de routes que ça représente, probablement > > gérable entre opérateurs petits, mais si un SFR ou Free se pointe, ça va > > faire mal (les particuliers ont tous un /40, et rien à aggréger). > > J'i des doutes que je suis le seul a faire trainer des milliers (bientot > dizaines de milliers) de /32 dans mon (MP-)iBGP. Plus autant de /128 et > encore autant de /56 ou /48 > Donc cote scalabilite, je vois pas de probleme 1.2M routes sur mon RR, > et ce n'est pas le pire que ca puisse exister > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
Je m’auto-corrige: 10 ou 20 fois la table de routage globale pour juste les E164 en France…. On 16 mai 2018 10:13 +0200, David Ponzone , wrote: > C’est rassurant. > Je remontais juste ce point car le nombre de routes en téléphonie peut être > de l’ordre de 10 ou 20 fois ce qu’on a en IPv4. > C’est difficile à prédire, mais à priori plus le temps passe, plus ça se > désagrège. > Evidememnt, ce BGP orienté E164 pourrait être fait par des routeurs soft, > blindés en RAM et qui monte des sessions multihop-BGP avec le RS de l'IX , > puisqu’il n’y a nul besoin de se reposer sur les routeurs IPv4 existants pour > ce BGP là. > > On 16 mai 2018 10:04 +0200, Radu-Adrian Feurdean > , wrote: > > On Tue, May 15, 2018, at 20:18, David Ponzone wrote: > > > Ce qui me dérange, c’est que vous semblez oublier qu’une plage de > > > numéros client c’est par exemple un /36 dans ton exemple (ZABPQMCD), > > > mais il arrive souvent qu’un numéro ait été sorti pour une ligne > > > analogique (fax) donc ton /36 devient 9 /40. > > > Difficile d’évaluer le nombre de routes que ça représente, probablement > > > gérable entre opérateurs petits, mais si un SFR ou Free se pointe, ça va > > > faire mal (les particuliers ont tous un /40, et rien à aggréger). > > > > J'i des doutes que je suis le seul a faire trainer des milliers (bientot > > dizaines de milliers) de /32 dans mon (MP-)iBGP. Plus autant de /128 et > > encore autant de /56 ou /48 > > Donc cote scalabilite, je vois pas de probleme 1.2M routes sur mon RR, > > et ce n'est pas le pire que ca puisse exister > > > > > > --- > > Liste de diffusion du FRnOG > > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
C’est rassurant. Je remontais juste ce point car le nombre de routes en téléphonie peut être de l’ordre de 10 ou 20 fois ce qu’on a en IPv4. C’est difficile à prédire, mais à priori plus le temps passe, plus ça se désagrège. Evidememnt, ce BGP orienté E164 pourrait être fait par des routeurs soft, blindés en RAM et qui monte des sessions multihop-BGP avec le RS de l'IX , puisqu’il n’y a nul besoin de se reposer sur les routeurs IPv4 existants pour ce BGP là. On 16 mai 2018 10:04 +0200, Radu-Adrian Feurdean , wrote: > On Tue, May 15, 2018, at 20:18, David Ponzone wrote: > > Ce qui me dérange, c’est que vous semblez oublier qu’une plage de > > numéros client c’est par exemple un /36 dans ton exemple (ZABPQMCD), > > mais il arrive souvent qu’un numéro ait été sorti pour une ligne > > analogique (fax) donc ton /36 devient 9 /40. > > Difficile d’évaluer le nombre de routes que ça représente, probablement > > gérable entre opérateurs petits, mais si un SFR ou Free se pointe, ça va > > faire mal (les particuliers ont tous un /40, et rien à aggréger). > > J'i des doutes que je suis le seul a faire trainer des milliers (bientot > dizaines de milliers) de /32 dans mon (MP-)iBGP. Plus autant de /128 et > encore autant de /56 ou /48 > Donc cote scalabilite, je vois pas de probleme 1.2M routes sur mon RR, et > ce n'est pas le pire que ca puisse exister > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
On Tue, May 15, 2018, at 20:18, David Ponzone wrote: > Ce qui me dérange, c’est que vous semblez oublier qu’une plage de > numéros client c’est par exemple un /36 dans ton exemple (ZABPQMCD), > mais il arrive souvent qu’un numéro ait été sorti pour une ligne > analogique (fax) donc ton /36 devient 9 /40. > Difficile d’évaluer le nombre de routes que ça représente, probablement > gérable entre opérateurs petits, mais si un SFR ou Free se pointe, ça va > faire mal (les particuliers ont tous un /40, et rien à aggréger). J'i des doutes que je suis le seul a faire trainer des milliers (bientot dizaines de milliers) de /32 dans mon (MP-)iBGP. Plus autant de /128 et encore autant de /56 ou /48 Donc cote scalabilite, je vois pas de probleme 1.2M routes sur mon RR, et ce n'est pas le pire que ca puisse exister --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
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 1 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 1.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). On 16 mai 2018 09:08 +0200, Alexis Lameire , wrote: > Raphaël, > Ta remarque est pertinente sauf que ton plan de num est différent selon le > pays, donc c'est 3digit + padding + num. On a besoin de mettre le padding à > cette endroit pour que la notion de masque reste valide (et profiter de > l’agrégation). > > L'identification d'un opérateur ne peut se faire uniquement avec le numéro > d'AS, il y a toujours/souvent un enregistrement local complémentaire qui > est nécessaire à la vérification de la validité du plan de num annoncé. Il > faut donc le recevoir dans l'annonce BGP. On pourrais utiliser le vpnv6 > mais utiliser la notion de vrf pour coder l'identification de l'opérateur > c'est pas crédible. On souhaite isoler les plan de num par pays et non par > opérateur (dont le numéro pourrait se recouvrir sur deux pays différent) > > On peut sinon concevoir de transférer l'information d'identification ARCEP > via l'utilisation d'un bloc de communauté well know et rester dans les > clous. Comme ça on rajoute le moins de truc au protocole. > > Le seul truc sur lequel il faut pas transiger, c'est l'utilisation > mémoire/tcam. Et donc il faut définir une extension pour router des bloc de > 64bit avec prefix. > > Alexis > > Le 16 mai 2018 à 08:46, Raphaël Jacquot a écrit : > > > > > > > On 15/05/2018 20:07, Alexis Lameire wrote: > > > > ainsi la EZABPQ 011234 se code avec : > > > un prefix binaire représenté en hexa : 01:12:34:00:00 > > > un masque binaire représenté en hexa : FF:FF:FF:00:00 > > > > > > On peut ainsi employer la notation CIDR en 01:12:34:00:00/24 les routes > > > spécifique étant en /40 > > > > > > > STOP right there... > > > > je pense qu'une solution est possible sans même ajouter d'extension a > > BGP... > > > > * une adresse IPv6 est composée de 128 bits, soit 32 blocs de 4 bits. > > * d'après https://en.wikipedia.org/wiki/Telephone_numbering_plan > > un numéro de téléphone, au niveau mondial, a 15 caracteres BCD > > > > Il serait donc extremement simple, et le plus naturel du monde, de mapper > > tout ca sur un seul /64, > > * le code pays est sur 3 digits > > * le reste du numéro sur les 13 digits restants > > > > ce qui simplifierai grandement les tables de routages au niveau > > international > > > > Raphaël > > > > > > > > > > > > > > --- > > 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/
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
On 05/16/2018 09:35 AM, Sébastien Lesimple wrote: > Bref, ce n'est pas un problème d'ingés mais un problème business et le > modèle associatif à la FranceIX ne fonctionne pas quand on aborde le > business de la voix. il va bien y avoir un moment ou un des acteurs un peu kamikaze va se décider a disrupter ce business model bien huilé depuis une bonne centaine d'années... Raphaël --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
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 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 1 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 chose
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
Cela doit bien faire 20 ans que j'entends ce genre d'échange. Ca a commencé à l'époque de la présélection, puis de la démocratisation de l'interco C7, puis du SIP mais rien n'a jamais aboutis. Toutes les tentatives se sont traduites par un échec. L'investissement pour atteindre cet objectif est lourds en temps/RH/ressources. De plus il sous-entendrait de maintenir une interco avec l'ensemble des opérateurs "puissants" afin de fournir une "route" aux plus modestes et compenser les trous dans la raquette, parce-que hormis Orange qui a une vraie ODR, les autres, c'est la valse du grand n'importe quoi... Bref, ce n'est pas un problème d'ingés mais un problème business et le modèle associatif à la FranceIX ne fonctionne pas quand on aborde le business de la voix. Seb. Le 15/05/2018 à 15:40, Mickael Hubert a écrit : > +1 pour participer a ce type de discussion passionnante ! > > Il est vrai que les obstacles sont nombreux, mais si on ne commence pas, ça > n'avancera jamais ;) Et se faire un POC n'engage a rien (contractuellement > parlant). > Et au final c'est quoi ? => Mettre au goût du jour un techno vieillissante. > Il y a bien l'annonce de "la fin" du RTC pour le end user pourquoi pas > l'annonce de "la fin" du SS7 pour les opérateurs (ok, je m'avance un peu ;) > ) ? > > ++ > > > > Le 15 mai 2018 à 15:30, Alain Bieuzent a écrit : > >> +1 avec David, pas de problème pour discuter et/ou boire un bière a >> l'occase et encore mieux si on peut effectivement faire mieux que les >> "gros" et notamment de la HD >> >> Le 15/05/2018 15:27, « David Ponzone » > de david.ponz...@gmail.com> a écrit : >> >> Moi je suis comme Fabien, extrêmement sceptique sur la viabilité du >> projet, mais je ne suis pas contre participer aux débats :) >> Il y a par contre un argument qui pourrait pousser des acteurs moyens >> à se joindre au projet, c’est de pouvoir (enfin) utiliser des codec HD et >> video, donc fournir quelque chose qui n’est pas dispo (ou pas complètement) >> pour le moment quand Orange est intermédiaire. >> >> On 15 mai 2018 14:56 +0200, Fabien H , wrote: >> > Effectivement, on va arrêter de polluer la liste mais une dernière >> chose : >> > >> > sans vouloir faire le pessimiste, il y'a quand même 2 gros freins >> pour ce >> > projet qui ont été évoqués : >> > >> > - Le fait que s'il n'y a pas de gros dans le projet, le trafic >> échangé sera >> > négligeable, donc le gain négligeable >> > - Le fait qu'il faut des interco de qualité pour la voix avec des >> liens >> > d'interco garantis et de qualité (+ QOS, ..) et cela ça a un cout, >> qui sera >> > à multiplier par le nombre d'opérateurs dans le projet. Et du coup, >> la >> > viabilité purement financière sera surement limite, voire au final >> cela >> > coutera cher, par rapport à terminer chez son fournisseur de >> terminaison >> > habituel (Orange ou autre), sur lequel on a investit au niveau >> interco, et >> > qui lui garantit "normalement" le transport dans des conditions >> > excellentes. >> > Sinon solution best effort, on peut toujours passer par le transit >> "par >> > défaut", mais sur le long terme, on n'est jamais à l'abri d'un >> problème de >> > qualité de voix, et c'est je pense ce que la plupart ici ne veulent >> pas. >> > >> > --- >> > 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/
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
On 16/05/2018 09:08, Alexis Lameire wrote: Raphaël, Ta remarque est pertinente sauf que ton plan de num est différent selon le pays, donc c'est 3digit + padding + num. On a besoin de mettre le padding à cette endroit pour que la notion de masque reste valide (et profiter de l’agrégation). ca n'était qu'une hypothèse qui peut être effectivement raffinée en fonction des besoins. On pourrait décider d'affecter un /16 a la téléphonie, et etre plus large dans le découpage en blocs (ca laisserait 28 chiffres BCD à découper...) Raphaël --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
Raphaël, Ta remarque est pertinente sauf que ton plan de num est différent selon le pays, donc c'est 3digit + padding + num. On a besoin de mettre le padding à cette endroit pour que la notion de masque reste valide (et profiter de l’agrégation). L'identification d'un opérateur ne peut se faire uniquement avec le numéro d'AS, il y a toujours/souvent un enregistrement local complémentaire qui est nécessaire à la vérification de la validité du plan de num annoncé. Il faut donc le recevoir dans l'annonce BGP. On pourrais utiliser le vpnv6 mais utiliser la notion de vrf pour coder l'identification de l'opérateur c'est pas crédible. On souhaite isoler les plan de num par pays et non par opérateur (dont le numéro pourrait se recouvrir sur deux pays différent) On peut sinon concevoir de transférer l'information d'identification ARCEP via l'utilisation d'un bloc de communauté well know et rester dans les clous. Comme ça on rajoute le moins de truc au protocole. Le seul truc sur lequel il faut pas transiger, c'est l'utilisation mémoire/tcam. Et donc il faut définir une extension pour router des bloc de 64bit avec prefix. Alexis Le 16 mai 2018 à 08:46, Raphaël Jacquot a écrit : > > > On 15/05/2018 20:07, Alexis Lameire wrote: > > ainsi la EZABPQ 011234 se code avec : >> un prefix binaire représenté en hexa : 01:12:34:00:00 >> un masque binaire représenté en hexa : FF:FF:FF:00:00 >> >> On peut ainsi employer la notation CIDR en 01:12:34:00:00/24 les routes >> spécifique étant en /40 >> > > STOP right there... > > je pense qu'une solution est possible sans même ajouter d'extension a > BGP... > > * une adresse IPv6 est composée de 128 bits, soit 32 blocs de 4 bits. > * d'après https://en.wikipedia.org/wiki/Telephone_numbering_plan > un numéro de téléphone, au niveau mondial, a 15 caracteres BCD > > Il serait donc extremement simple, et le plus naturel du monde, de mapper > tout ca sur un seul /64, > * le code pays est sur 3 digits > * le reste du numéro sur les 13 digits restants > > ce qui simplifierai grandement les tables de routages au niveau > international > > Raphaël > > > > > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
On 15/05/2018 20:07, Alexis Lameire wrote: ainsi la EZABPQ 011234 se code avec : un prefix binaire représenté en hexa : 01:12:34:00:00 un masque binaire représenté en hexa : FF:FF:FF:00:00 On peut ainsi employer la notation CIDR en 01:12:34:00:00/24 les routes spécifique étant en /40 STOP right there... je pense qu'une solution est possible sans même ajouter d'extension a BGP... * une adresse IPv6 est composée de 128 bits, soit 32 blocs de 4 bits. * d'après https://en.wikipedia.org/wiki/Telephone_numbering_plan un numéro de téléphone, au niveau mondial, a 15 caracteres BCD Il serait donc extremement simple, et le plus naturel du monde, de mapper tout ca sur un seul /64, * le code pays est sur 3 digits * le reste du numéro sur les 13 digits restants ce qui simplifierai grandement les tables de routages au niveau international Raphaël --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
Merci Nicolas pour ton retour et ta participation, Perso pas sur Paris, j'ai réduit au max les déplacements (trains et avions) ces derniers temps, on se demanderait presque pourquoi On a pas mal de point en commun avec ta réflexion. Je fais un retour dès que je penses que tous ceux qui souhaitent traiter le sujet on fait signe de la main. Donc ceux qui ont déjà posté mais non pas expressément dit qu'il voulait se joindre merci de lever la main. De préférence sur mon mail avec la balise [IAV] pour des questions de traitements automatique des mails ce serait sympa. En plus avec le 25/05 qui arrive a grand pas il serait bien d'avoir votre consentement explicite :) On n'a pas forcément nom et prénom via vos mails ce serait aussi très bien de nous communiquer les informations comme : L'email sur lequel on va diffuser (si différent de celui identifié dans votre mail), un pro si possible Le nom de la boite, si c'est possible mais on comprendra très bien que certains ne soit pas strictement dans le cadre pro de la boite sur ce sujet donc pas obligatoire. C'est juste bien de voir avec qui on va travailler. Le poste idem c'est toujours intéressant mais pas obligatoire. Xavier PS1 : H-1 pour le début de la montée en charge à suivre PS2 : qui a eu une RFO (Reason For Outage) de la part d'Orange ? -Message d'origine- De : Nicolas Bougues Envoyé : mercredi 16 mai 2018 02:09 À : frnog@frnog.org Objet : Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange) 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 1 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 ch
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
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 1 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
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
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 1 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 d
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
Il y a aussi le cas des porta. IMAO on a déjà la réponse dans les algo de routage une route spécifique :) donc un /36 et un /40. Ceci permet aussi de prendre en compte le cas des porta. L'APNF alloue des /24, et lors des porta l'opérateur destinataire de la porta annonce les routes spécifiques. Par contre, c'est peut être moi qui ai loupé un truc cette fois. Le 15 mai 2018 à 20:18, David Ponzone a écrit : > Ce qui me dérange, c’est que vous semblez oublier qu’une plage de numéros > client c’est par exemple un /36 dans ton exemple (ZABPQMCD), mais il arrive > souvent qu’un numéro ait été sorti pour une ligne analogique (fax) donc ton > /36 devient 9 /40. > Difficile d’évaluer le nombre de routes que ça représente, probablement > gérable entre opérateurs petits, mais si un SFR ou Free se pointe, ça va > faire mal (les particuliers ont tous un /40, et rien à aggréger). > > J’ai raté un truc ? > > On 15 mai 2018 20:07 +0200, Alexis Lameire , > wrote: > > Hello frnog, > > Je ne suis pas un spécialiste voix, mais je suis aussi convaincu qu'il y a > des choses a faire avec une extensions à BGP. Je vais rajouter my 2 cent au > schmilblick > > qu'est ce qui fait que BGP c'est le bien : > * l'aggrégation des prefix > * l'algo dee routage déjà tout fait > * la responsabilité du routage laissé à chaque acteurs de la boucle > * l'ouverture a d'autre protocole. > > Déjà premier truc dont je suis pas d'accord, la RFC sur l'EVPN me semble > pas trop adapté, j’aurais tendance à me basé sur l'extension vpnv4. > > On a besoin en premier lieux de définir des zones cloisonnées de routages, > avec un numéro d'identification par pays. Dans ce cadre la, le country code > peut être utiliser. > Ensuite chaque entité à besoin d'être identifié à la fois de façon globale > et de façon locale. L'identité sur internet me semble être un numéro d'AS > enregistrer auprès d'un RIR il n'y a pas à tortiller mille an. Par contre > d'un point de vue local cela dépend de l'entité administrative locale. Dans > le cadre de la france, l'ARCEP. On pourrait par exemple concevoir le numéro > d'enregistrement auprès de l'ARCEP comme une bonne variable > d'identification. Mais il s'agit d'un champ de taille fixe dépendant du > pays. > > Le second élément à prendre en compte est l’agrégation. Nous avons un > soucis avec tous les plan de numérotation c'est qu'ils sont conçu en base > 10 et non dans une puissance de 2. Il faut donc trouver un codage > intelligent. Je propose de coder les routes et les masques en > BCD[1] > > ainsi la EZABPQ 011234 se code avec : > un prefix binaire représenté en hexa : 01:12:34:00:00 > un masque binaire représenté en hexa : FF:FF:FF:00:00 > > On peut ainsi employer la notation CIDR en 01:12:34:00:00/24 les routes > spécifique étant en /40 > > Il faut maintenant fournir les services d'un serveur de route auprès des > différents opérateur. Un bon serveur de route se doit : > * de vérifier la validité de ses membres : on peut ici utiliser RPKI, il > faut simplement héberger les clef au niveau de l'APNF ou avoir une > procédure auprès de l'iX pour vérifier la validité du peer. > * de vérifier les bogon : comme certains transitaire vont vérifier les > bases des RIR, la ressource de numérotion peut être vérifié auprès de > l'APNF. > * de vérifier la sécurité des annonce : on a une RFC qui est récente : > BGPSEC > > La ou ça s'arete, c'est qu'en pratique les règle d'interco peuvent différer > d'un opérateur à l'autre et il faut pouvoir prendre en compte ces > changement. Les informations de numérotation sont ainsi à fournir à la > brique du backbone de l'opérateur téléphonique qui gére le LCR (pas la NUM, > on a toujours le cas des numéro d'urgence qui sont à réencoder et qui ne > sont pas adapté à BGP (le cas des numéros qui changent selon l'heure)). > C'est aussi nécessaire par ce que l'opérateur doit être en mesure > d'appliquer des mesures anti fraude avant de transférer le trafic à > l'I-SBC. > > Pour gérer l'interco au niveau du SBC il faut aussi prévoir deux champ > obligatoire avec l'addresse du peer sur l'IX ainsi que la norme d'interco > suivie. Ceci est nécessaire par ce qu'on ne souhaite pas que les RR gére le > dataplane. > > Ceci clos la partie purement voix. Pour gérer l'interco sur l'IX et éviter > le L2 il faudra aussi prévoir une interco BGP classique sur le routeur en > aval du I-SBC pour redistribuer les routes pour joindre les SBC des copain. > Mais rien de bien complexe. > > Enfin, d'un point de vue facturation, ayant dans les annonces BGP le numero > d'enregistrement auprès de l'APNF il est facile de mettre ça dans les CDR > pour se refacturer entre copain. On pourrait même concevoir que l'IX > fournisse la liste des adresse de facturation de ses membre pour simplifier > les choses voir pour les plus petit prenne en charge la refacturation > contre quelques % des sommes dues. > > C'était un long pavé, mais je veux bien vos avis :) > Cordialement > Alexis Lameire > > [1] https://fr.wikipedia.org/wiki/D
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
Ce qui me dérange, c’est que vous semblez oublier qu’une plage de numéros client c’est par exemple un /36 dans ton exemple (ZABPQMCD), mais il arrive souvent qu’un numéro ait été sorti pour une ligne analogique (fax) donc ton /36 devient 9 /40. Difficile d’évaluer le nombre de routes que ça représente, probablement gérable entre opérateurs petits, mais si un SFR ou Free se pointe, ça va faire mal (les particuliers ont tous un /40, et rien à aggréger). J’ai raté un truc ? On 15 mai 2018 20:07 +0200, Alexis Lameire , wrote: > Hello frnog, > > Je ne suis pas un spécialiste voix, mais je suis aussi convaincu qu'il y a > des choses a faire avec une extensions à BGP. Je vais rajouter my 2 cent au > schmilblick > > qu'est ce qui fait que BGP c'est le bien : > * l'aggrégation des prefix > * l'algo dee routage déjà tout fait > * la responsabilité du routage laissé à chaque acteurs de la boucle > * l'ouverture a d'autre protocole. > > Déjà premier truc dont je suis pas d'accord, la RFC sur l'EVPN me semble > pas trop adapté, j’aurais tendance à me basé sur l'extension vpnv4. > > On a besoin en premier lieux de définir des zones cloisonnées de routages, > avec un numéro d'identification par pays. Dans ce cadre la, le country code > peut être utiliser. > Ensuite chaque entité à besoin d'être identifié à la fois de façon globale > et de façon locale. L'identité sur internet me semble être un numéro d'AS > enregistrer auprès d'un RIR il n'y a pas à tortiller mille an. Par contre > d'un point de vue local cela dépend de l'entité administrative locale. Dans > le cadre de la france, l'ARCEP. On pourrait par exemple concevoir le numéro > d'enregistrement auprès de l'ARCEP comme une bonne variable > d'identification. Mais il s'agit d'un champ de taille fixe dépendant du > pays. > > Le second élément à prendre en compte est l’agrégation. Nous avons un > soucis avec tous les plan de numérotation c'est qu'ils sont conçu en base > 10 et non dans une puissance de 2. Il faut donc trouver un codage > intelligent. Je propose de coder les routes et les masques en > BCD[1] > > ainsi la EZABPQ 011234 se code avec : > un prefix binaire représenté en hexa : 01:12:34:00:00 > un masque binaire représenté en hexa : FF:FF:FF:00:00 > > On peut ainsi employer la notation CIDR en 01:12:34:00:00/24 les routes > spécifique étant en /40 > > Il faut maintenant fournir les services d'un serveur de route auprès des > différents opérateur. Un bon serveur de route se doit : > * de vérifier la validité de ses membres : on peut ici utiliser RPKI, il > faut simplement héberger les clef au niveau de l'APNF ou avoir une > procédure auprès de l'iX pour vérifier la validité du peer. > * de vérifier les bogon : comme certains transitaire vont vérifier les > bases des RIR, la ressource de numérotion peut être vérifié auprès de > l'APNF. > * de vérifier la sécurité des annonce : on a une RFC qui est récente : > BGPSEC > > La ou ça s'arete, c'est qu'en pratique les règle d'interco peuvent différer > d'un opérateur à l'autre et il faut pouvoir prendre en compte ces > changement. Les informations de numérotation sont ainsi à fournir à la > brique du backbone de l'opérateur téléphonique qui gére le LCR (pas la NUM, > on a toujours le cas des numéro d'urgence qui sont à réencoder et qui ne > sont pas adapté à BGP (le cas des numéros qui changent selon l'heure)). > C'est aussi nécessaire par ce que l'opérateur doit être en mesure > d'appliquer des mesures anti fraude avant de transférer le trafic à > l'I-SBC. > > Pour gérer l'interco au niveau du SBC il faut aussi prévoir deux champ > obligatoire avec l'addresse du peer sur l'IX ainsi que la norme d'interco > suivie. Ceci est nécessaire par ce qu'on ne souhaite pas que les RR gére le > dataplane. > > Ceci clos la partie purement voix. Pour gérer l'interco sur l'IX et éviter > le L2 il faudra aussi prévoir une interco BGP classique sur le routeur en > aval du I-SBC pour redistribuer les routes pour joindre les SBC des copain. > Mais rien de bien complexe. > > Enfin, d'un point de vue facturation, ayant dans les annonces BGP le numero > d'enregistrement auprès de l'APNF il est facile de mettre ça dans les CDR > pour se refacturer entre copain. On pourrait même concevoir que l'IX > fournisse la liste des adresse de facturation de ses membre pour simplifier > les choses voir pour les plus petit prenne en charge la refacturation > contre quelques % des sommes dues. > > C'était un long pavé, mais je veux bien vos avis :) > Cordialement > Alexis Lameire > > [1] https://fr.wikipedia.org/wiki/D%C3%A9cimal_cod%C3%A9_binaire > > Le 15 mai 2018 à 19:05, Xavier ROCA a écrit : > > > Pour ceux que cela intéresse voilà la com d'OVH > > > > http://mj.ovh.com/lnk/AAOQIBAAARZrylAAAFlmiY0AAPiDvlwAFihtAAVMlQBa- > > wUyiluYDoEjRGWTTD_qsQggRAABHT4/1/cV-o3neJSH8uzaDa7FERdQ/ > > aHR0cDovL21qLm92aC5jb20vbmwyLzVyN2wvMTJvaXQuaHRtbD9tPUFBQUFB > > QU9RSUJBQUFSWnJ5bEFBQUZsbWlZMEFBUGlEdmx3QUZpaHRBQVZNbFFCYS13 > > VXlpbHVZRG9FalJHV1RURF9x
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
Hello frnog, Je ne suis pas un spécialiste voix, mais je suis aussi convaincu qu'il y a des choses a faire avec une extensions à BGP. Je vais rajouter my 2 cent au schmilblick qu'est ce qui fait que BGP c'est le bien : * l'aggrégation des prefix * l'algo dee routage déjà tout fait * la responsabilité du routage laissé à chaque acteurs de la boucle * l'ouverture a d'autre protocole. Déjà premier truc dont je suis pas d'accord, la RFC sur l'EVPN me semble pas trop adapté, j’aurais tendance à me basé sur l'extension vpnv4. On a besoin en premier lieux de définir des zones cloisonnées de routages, avec un numéro d'identification par pays. Dans ce cadre la, le country code peut être utiliser. Ensuite chaque entité à besoin d'être identifié à la fois de façon globale et de façon locale. L'identité sur internet me semble être un numéro d'AS enregistrer auprès d'un RIR il n'y a pas à tortiller mille an. Par contre d'un point de vue local cela dépend de l'entité administrative locale. Dans le cadre de la france, l'ARCEP. On pourrait par exemple concevoir le numéro d'enregistrement auprès de l'ARCEP comme une bonne variable d'identification. Mais il s'agit d'un champ de taille fixe dépendant du pays. Le second élément à prendre en compte est l’agrégation. Nous avons un soucis avec tous les plan de numérotation c'est qu'ils sont conçu en base 10 et non dans une puissance de 2. Il faut donc trouver un codage intelligent. Je propose de coder les routes et les masques en BCD[1] ainsi la EZABPQ 011234 se code avec : un prefix binaire représenté en hexa : 01:12:34:00:00 un masque binaire représenté en hexa : FF:FF:FF:00:00 On peut ainsi employer la notation CIDR en 01:12:34:00:00/24 les routes spécifique étant en /40 Il faut maintenant fournir les services d'un serveur de route auprès des différents opérateur. Un bon serveur de route se doit : * de vérifier la validité de ses membres : on peut ici utiliser RPKI, il faut simplement héberger les clef au niveau de l'APNF ou avoir une procédure auprès de l'iX pour vérifier la validité du peer. * de vérifier les bogon : comme certains transitaire vont vérifier les bases des RIR, la ressource de numérotion peut être vérifié auprès de l'APNF. * de vérifier la sécurité des annonce : on a une RFC qui est récente : BGPSEC La ou ça s'arete, c'est qu'en pratique les règle d'interco peuvent différer d'un opérateur à l'autre et il faut pouvoir prendre en compte ces changement. Les informations de numérotation sont ainsi à fournir à la brique du backbone de l'opérateur téléphonique qui gére le LCR (pas la NUM, on a toujours le cas des numéro d'urgence qui sont à réencoder et qui ne sont pas adapté à BGP (le cas des numéros qui changent selon l'heure)). C'est aussi nécessaire par ce que l'opérateur doit être en mesure d'appliquer des mesures anti fraude avant de transférer le trafic à l'I-SBC. Pour gérer l'interco au niveau du SBC il faut aussi prévoir deux champ obligatoire avec l'addresse du peer sur l'IX ainsi que la norme d'interco suivie. Ceci est nécessaire par ce qu'on ne souhaite pas que les RR gére le dataplane. Ceci clos la partie purement voix. Pour gérer l'interco sur l'IX et éviter le L2 il faudra aussi prévoir une interco BGP classique sur le routeur en aval du I-SBC pour redistribuer les routes pour joindre les SBC des copain. Mais rien de bien complexe. Enfin, d'un point de vue facturation, ayant dans les annonces BGP le numero d'enregistrement auprès de l'APNF il est facile de mettre ça dans les CDR pour se refacturer entre copain. On pourrait même concevoir que l'IX fournisse la liste des adresse de facturation de ses membre pour simplifier les choses voir pour les plus petit prenne en charge la refacturation contre quelques % des sommes dues. C'était un long pavé, mais je veux bien vos avis :) Cordialement Alexis Lameire [1] https://fr.wikipedia.org/wiki/D%C3%A9cimal_cod%C3%A9_binaire Le 15 mai 2018 à 19:05, Xavier ROCA a écrit : > Pour ceux que cela intéresse voilà la com d'OVH > > http://mj.ovh.com/lnk/AAOQIBAAARZrylAAAFlmiY0AAPiDvlwAFihtAAVMlQBa- > wUyiluYDoEjRGWTTD_qsQggRAABHT4/1/cV-o3neJSH8uzaDa7FERdQ/ > aHR0cDovL21qLm92aC5jb20vbmwyLzVyN2wvMTJvaXQuaHRtbD9tPUFBQUFB > QU9RSUJBQUFSWnJ5bEFBQUZsbWlZMEFBUGlEdmx3QUZpaHRBQVZNbFFCYS13 > VXlpbHVZRG9FalJHV1RURF9xc1FnZ1JBQUJIVDQmYj1hMGNhNzI2OCZlPTlk > Mjg3NTA3JmVtYWlsPW92aEBzZGkuZnI > > Même si ce n'est pas super réglementaire certains on bien compris que > l'échange strictement privé a une part de bon sens. > Mais apparemment SFR n'a pas traité tout le monde de la même manière > aujourd'hui donc ca reste du SFR... > > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
Pour ceux que cela intéresse voilà la com d'OVH http://mj.ovh.com/lnk/AAOQIBAAARZrylAAAFlmiY0AAPiDvlwAFihtAAVMlQBa-wUyiluYDoEjRGWTTD_qsQggRAABHT4/1/cV-o3neJSH8uzaDa7FERdQ/aHR0cDovL21qLm92aC5jb20vbmwyLzVyN2wvMTJvaXQuaHRtbD9tPUFBQUFBQU9RSUJBQUFSWnJ5bEFBQUZsbWlZMEFBUGlEdmx3QUZpaHRBQVZNbFFCYS13VXlpbHVZRG9FalJHV1RURF9xc1FnZ1JBQUJIVDQmYj1hMGNhNzI2OCZlPTlkMjg3NTA3JmVtYWlsPW92aEBzZGkuZnI Même si ce n'est pas super réglementaire certains on bien compris que l'échange strictement privé a une part de bon sens. Mais apparemment SFR n'a pas traité tout le monde de la même manière aujourd'hui donc ca reste du SFR... --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
Le dataplane ça peut surement être un Freeswitch ou un ensemble de Freeswitch hébergés à Paris sur une infra type IX (pour le RTP, à moins qu'on fasse les fifous avec RTP proxy obligatoire et du transcodage dans tous les sens ? ahhh oui, fouette moi avec une pelle, casse moi la bouche bad boy ...). Mais bon le control plane de cette merdasse de VoIP ça reste de l'envoi de fichier de CSV ? Juste, on est en 2018. On sait router des @IPs, des @Macs ... faudrait peut être penser à moderniser le control plane VoIP. A mon avis, on fait copier coller de la RFC EVPN, un petit control-h pour swapper "@mac" par "numero de téléphone" et le tour est joué... Le 15 mai 2018 à 16:31, Raphael Jacquot a écrit : > On 05/15/2018 10:24 AM, boite frnog wrote: > > > 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. > > troll du mardi: > > pourquoi ne pas faire ca directement chez Thales, dans les locaux de la > PNIJ, ca simplifierai plein de choses ;-) > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > -- Cordialement, Guillaume BARROT --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
On 05/15/2018 10:24 AM, boite frnog wrote: > 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. troll du mardi: pourquoi ne pas faire ca directement chez Thales, dans les locaux de la PNIJ, ca simplifierai plein de choses ;-) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
Oui tes arguments sont bons aussi ! S'il il y'a déjà des moyens interessés, c'est déjà une bonne chose .Et puis avec le temps, on va bien arriver à grignoter des plus gros pour que les petits deviennent moyens effectivement ! Le 15 mai 2018 à 15:48, Xavier ROCA a écrit : > Je comprends bien Fabien ton scepticisme, pour autant : > > > > Dans les gros, il y en a qui ne sont pas forcément les plus connu mais qui > pèse quand même. > > Il y en a déjà un avec qui est partant. > > Et les moyens y viendront surement si on fait quelque chose d’intelligent > mais n’y seront pas forcément au départ car trop de sujet à traiter pour > eux. > > Comme les cite Arnaud par exemple JN et Open IP les deux patrons sont des > gens très bien donc j’y crois. > > Mais le mieux c’est que Kevin qui est souvent présent ici donne son avis > sur cela. > > > > Pour le second point, cela va effectivement dépendre de la complexité du > montage. > > On réfléchit a quelques choses d’assez simple mais forcément il y aura des > frais même si on réduit au mieux (en restant intelligent). > > Et accessible même au tout petit > > A nous d’utiliser au maximum les possibilités des ressources présentes > pour la plupart d’entre nous. > > Après moi je vois que ce type de problème devient très pénibles pour nos > clients donc pour notre Image ou notre CA. > > Conclusion : pas contre mettre des KEuros pour faire mieux. > > > > > > *De :* Fabien H > *Envoyé :* mardi 15 mai 2018 14:56 > *À :* boite frnog > *Cc :* Xavier ROCA ; frnog@frnog.org > *Objet :* Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange) > > > > Effectivement, on va arrêter de polluer la liste mais une dernière chose : > > sans vouloir faire le pessimiste, il y'a quand même 2 gros freins pour ce > projet qui ont été évoqués : > > - Le fait que s'il n'y a pas de gros dans le projet, le trafic échangé > sera négligeable, donc le gain négligeable > > - Le fait qu'il faut des interco de qualité pour la voix avec des liens > d'interco garantis et de qualité (+ QOS, ..) et cela ça a un cout, qui sera > à multiplier par le nombre d'opérateurs dans le projet. Et du coup, la > viabilité purement financière sera surement limite, voire au final cela > coutera cher, par rapport à terminer chez son fournisseur de terminaison > habituel (Orange ou autre), sur lequel on a investit au niveau interco, et > qui lui garantit "normalement" le transport dans des conditions > excellentes. > Sinon solution best effort, on peut toujours passer par le transit "par > défaut", mais sur le long terme, on n'est jamais à l'abri d'un problème de > qualité de voix, et c'est je pense ce que la plupart ici ne veulent pas. > > > > > > --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
David, Excellente idée d'intégrer des Codecs HD et Vidéo pour ceux qui souhaiterait. Ce qui veut dire aussi un peu plus de BP a prévoir mais bon ce serait assez sympa ! -Message d'origine- De : David Ponzone Envoyé : mardi 15 mai 2018 15:22 À : boite frnog ; Fabien H Cc : Xavier ROCA ; frnog@frnog.org Objet : Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange) Moi je suis comme Fabien, extrêmement sceptique sur la viabilité du projet, mais je ne suis pas contre participer aux débats :) Il y a par contre un argument qui pourrait pousser des acteurs moyens à se joindre au projet, c’est de pouvoir (enfin) utiliser des codec HD et video, donc fournir quelque chose qui n’est pas dispo (ou pas complètement) pour le moment quand Orange est intermédiaire. On 15 mai 2018 14:56 +0200, Fabien H , wrote: > Effectivement, on va arrêter de polluer la liste mais une dernière chose : > > sans vouloir faire le pessimiste, il y'a quand même 2 gros freins pour > ce projet qui ont été évoqués : > > - Le fait que s'il n'y a pas de gros dans le projet, le trafic échangé > sera négligeable, donc le gain négligeable > - Le fait qu'il faut des interco de qualité pour la voix avec des > liens d'interco garantis et de qualité (+ QOS, ..) et cela ça a un > cout, qui sera à multiplier par le nombre d'opérateurs dans le projet. > Et du coup, la viabilité purement financière sera surement limite, > voire au final cela coutera cher, par rapport à terminer chez son > fournisseur de terminaison habituel (Orange ou autre), sur lequel on a > investit au niveau interco, et qui lui garantit "normalement" le > transport dans des conditions excellentes. > Sinon solution best effort, on peut toujours passer par le transit > "par défaut", mais sur le long terme, on n'est jamais à l'abri d'un > problème de qualité de voix, et c'est je pense ce que la plupart ici ne > veulent pas. > > --- > 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/
RE: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
Je comprends bien Fabien ton scepticisme, pour autant : Dans les gros, il y en a qui ne sont pas forcément les plus connu mais qui pèse quand même. Il y en a déjà un avec qui est partant. Et les moyens y viendront surement si on fait quelque chose d’intelligent mais n’y seront pas forcément au départ car trop de sujet à traiter pour eux. Comme les cite Arnaud par exemple JN et Open IP les deux patrons sont des gens très bien donc j’y crois. Mais le mieux c’est que Kevin qui est souvent présent ici donne son avis sur cela. Pour le second point, cela va effectivement dépendre de la complexité du montage. On réfléchit a quelques choses d’assez simple mais forcément il y aura des frais même si on réduit au mieux (en restant intelligent). Et accessible même au tout petit A nous d’utiliser au maximum les possibilités des ressources présentes pour la plupart d’entre nous. Après moi je vois que ce type de problème devient très pénibles pour nos clients donc pour notre Image ou notre CA. Conclusion : pas contre mettre des KEuros pour faire mieux. De : Fabien H Envoyé : mardi 15 mai 2018 14:56 À : boite frnog Cc : Xavier ROCA ; frnog@frnog.org Objet : Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange) Effectivement, on va arrêter de polluer la liste mais une dernière chose : sans vouloir faire le pessimiste, il y'a quand même 2 gros freins pour ce projet qui ont été évoqués : - Le fait que s'il n'y a pas de gros dans le projet, le trafic échangé sera négligeable, donc le gain négligeable - Le fait qu'il faut des interco de qualité pour la voix avec des liens d'interco garantis et de qualité (+ QOS, ..) et cela ça a un cout, qui sera à multiplier par le nombre d'opérateurs dans le projet. Et du coup, la viabilité purement financière sera surement limite, voire au final cela coutera cher, par rapport à terminer chez son fournisseur de terminaison habituel (Orange ou autre), sur lequel on a investit au niveau interco, et qui lui garantit "normalement" le transport dans des conditions excellentes. Sinon solution best effort, on peut toujours passer par le transit "par défaut", mais sur le long terme, on n'est jamais à l'abri d'un problème de qualité de voix, et c'est je pense ce que la plupart ici ne veulent pas. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
+1 pour participer a ce type de discussion passionnante ! Il est vrai que les obstacles sont nombreux, mais si on ne commence pas, ça n'avancera jamais ;) Et se faire un POC n'engage a rien (contractuellement parlant). Et au final c'est quoi ? => Mettre au goût du jour un techno vieillissante. Il y a bien l'annonce de "la fin" du RTC pour le end user pourquoi pas l'annonce de "la fin" du SS7 pour les opérateurs (ok, je m'avance un peu ;) ) ? ++ Le 15 mai 2018 à 15:30, Alain Bieuzent a écrit : > +1 avec David, pas de problème pour discuter et/ou boire un bière a > l'occase et encore mieux si on peut effectivement faire mieux que les > "gros" et notamment de la HD > > Le 15/05/2018 15:27, « David Ponzone » de david.ponz...@gmail.com> a écrit : > > Moi je suis comme Fabien, extrêmement sceptique sur la viabilité du > projet, mais je ne suis pas contre participer aux débats :) > Il y a par contre un argument qui pourrait pousser des acteurs moyens > à se joindre au projet, c’est de pouvoir (enfin) utiliser des codec HD et > video, donc fournir quelque chose qui n’est pas dispo (ou pas complètement) > pour le moment quand Orange est intermédiaire. > > On 15 mai 2018 14:56 +0200, Fabien H , wrote: > > Effectivement, on va arrêter de polluer la liste mais une dernière > chose : > > > > sans vouloir faire le pessimiste, il y'a quand même 2 gros freins > pour ce > > projet qui ont été évoqués : > > > > - Le fait que s'il n'y a pas de gros dans le projet, le trafic > échangé sera > > négligeable, donc le gain négligeable > > - Le fait qu'il faut des interco de qualité pour la voix avec des > liens > > d'interco garantis et de qualité (+ QOS, ..) et cela ça a un cout, > qui sera > > à multiplier par le nombre d'opérateurs dans le projet. Et du coup, > la > > viabilité purement financière sera surement limite, voire au final > cela > > coutera cher, par rapport à terminer chez son fournisseur de > terminaison > > habituel (Orange ou autre), sur lequel on a investit au niveau > interco, et > > qui lui garantit "normalement" le transport dans des conditions > > excellentes. > > Sinon solution best effort, on peut toujours passer par le transit > "par > > défaut", mais sur le long terme, on n'est jamais à l'abri d'un > problème de > > qualité de voix, et c'est je pense ce que la plupart ici ne veulent > pas. > > > > --- > > 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/
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
+1 avec David, pas de problème pour discuter et/ou boire un bière a l'occase et encore mieux si on peut effectivement faire mieux que les "gros" et notamment de la HD Le 15/05/2018 15:27, « David Ponzone » a écrit : Moi je suis comme Fabien, extrêmement sceptique sur la viabilité du projet, mais je ne suis pas contre participer aux débats :) Il y a par contre un argument qui pourrait pousser des acteurs moyens à se joindre au projet, c’est de pouvoir (enfin) utiliser des codec HD et video, donc fournir quelque chose qui n’est pas dispo (ou pas complètement) pour le moment quand Orange est intermédiaire. On 15 mai 2018 14:56 +0200, Fabien H , wrote: > Effectivement, on va arrêter de polluer la liste mais une dernière chose : > > sans vouloir faire le pessimiste, il y'a quand même 2 gros freins pour ce > projet qui ont été évoqués : > > - Le fait que s'il n'y a pas de gros dans le projet, le trafic échangé sera > négligeable, donc le gain négligeable > - Le fait qu'il faut des interco de qualité pour la voix avec des liens > d'interco garantis et de qualité (+ QOS, ..) et cela ça a un cout, qui sera > à multiplier par le nombre d'opérateurs dans le projet. Et du coup, la > viabilité purement financière sera surement limite, voire au final cela > coutera cher, par rapport à terminer chez son fournisseur de terminaison > habituel (Orange ou autre), sur lequel on a investit au niveau interco, et > qui lui garantit "normalement" le transport dans des conditions > excellentes. > Sinon solution best effort, on peut toujours passer par le transit "par > défaut", mais sur le long terme, on n'est jamais à l'abri d'un problème de > qualité de voix, et c'est je pense ce que la plupart ici ne veulent pas. > > --- > 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/
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
Moi je suis comme Fabien, extrêmement sceptique sur la viabilité du projet, mais je ne suis pas contre participer aux débats :) Il y a par contre un argument qui pourrait pousser des acteurs moyens à se joindre au projet, c’est de pouvoir (enfin) utiliser des codec HD et video, donc fournir quelque chose qui n’est pas dispo (ou pas complètement) pour le moment quand Orange est intermédiaire. On 15 mai 2018 14:56 +0200, Fabien H , wrote: > Effectivement, on va arrêter de polluer la liste mais une dernière chose : > > sans vouloir faire le pessimiste, il y'a quand même 2 gros freins pour ce > projet qui ont été évoqués : > > - Le fait que s'il n'y a pas de gros dans le projet, le trafic échangé sera > négligeable, donc le gain négligeable > - Le fait qu'il faut des interco de qualité pour la voix avec des liens > d'interco garantis et de qualité (+ QOS, ..) et cela ça a un cout, qui sera > à multiplier par le nombre d'opérateurs dans le projet. Et du coup, la > viabilité purement financière sera surement limite, voire au final cela > coutera cher, par rapport à terminer chez son fournisseur de terminaison > habituel (Orange ou autre), sur lequel on a investit au niveau interco, et > qui lui garantit "normalement" le transport dans des conditions > excellentes. > Sinon solution best effort, on peut toujours passer par le transit "par > défaut", mais sur le long terme, on n'est jamais à l'abri d'un problème de > qualité de voix, et c'est je pense ce que la plupart ici ne veulent pas. > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
Effectivement, on va arrêter de polluer la liste mais une dernière chose : sans vouloir faire le pessimiste, il y'a quand même 2 gros freins pour ce projet qui ont été évoqués : - Le fait que s'il n'y a pas de gros dans le projet, le trafic échangé sera négligeable, donc le gain négligeable - Le fait qu'il faut des interco de qualité pour la voix avec des liens d'interco garantis et de qualité (+ QOS, ..) et cela ça a un cout, qui sera à multiplier par le nombre d'opérateurs dans le projet. Et du coup, la viabilité purement financière sera surement limite, voire au final cela coutera cher, par rapport à terminer chez son fournisseur de terminaison habituel (Orange ou autre), sur lequel on a investit au niveau interco, et qui lui garantit "normalement" le transport dans des conditions excellentes. Sinon solution best effort, on peut toujours passer par le transit "par défaut", mais sur le long terme, on n'est jamais à l'abri d'un problème de qualité de voix, et c'est je pense ce que la plupart ici ne veulent pas. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
Xavier, Comme évoqué dans mon 1er mail, je ne fais que reprendre ton idée, qui je pense est excellente ! La voix a bien évolué durant ces dernières années, c'est peut être le bon moment pour ce genre d'initiative !!! Il serait effectivement souhaitable que des experts interviennent plus en profondeur, et pas forcément que voix, et surtout si des gros passent par là par hasard... Bonne idée pour le groupe de travail, les sujets sont trop nombreux, on va polluer la liste si on continue, il faut s'organiser. Je te suis ! Le 15 mai 2018 à 13:58, Xavier ROCA 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 > 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/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
> Sur le principe de faire un meetme de type FranceIX oui, par contre faire passer du SIP ou du flux RTP via un GIX, c'est assez moyen .. Bah ouais, alors un AS privé ? > A la limite, oui la signalisation pourrait être centralisée et passer par un ou deux proxy SIP d'une asso, et ensuite la SIG initie/reinvite le RTP entre l'operateur A et B via leurs IP d'interco sans repasser par le proxy SIP central . Mais du coup si AS privé, il serait sans doute préférable de proxyfier le RTP, et gérer ainsi la voix de bout en bout (SBC à SBC via SBC central). > Donc au final, c'est juste une histoire de base de routage de numéro décentralisée chez chaque opérateur (avec système de MAJ) + interco voix entre chaque opérateur interessé. Tu as tout compris de ce que je voulais dire !!! > Mais effectivement comme indique "boite frnog", le projet sera/serait surement tué dans l'oeuf faute de gros souhaitant rentrer et donc peu d'intérêt pour les petits Oui, enfin par gros, des moyens peuvent être pas mal, comme Jaguar, OVH, openIP... Et tu peux m'appeler Arnaud ;) Le 15 mai 2018 à 13:35, Fabien H a écrit : > L'histoire du DNS, oui c'est intéressant mais il faut que le DNS soit > privé ou filtré pour éviter de divulger des informations qui pourraient > mettre en péril la "securité nationale". > > Oui, comme le FranceIX finalement. Un AS, des équipements à TH2, et tout >> le monde se rejoint à la meetme. Donc finalement au niveau IP avons-nous >> besoin de tout cela, le FranceIX le fait très bien ? Peut-être qu'il soit >> pleinement séparé de la data ? Ce n’est pas idiot non plus... >> > Sur le principe de faire un meetme de type FranceIX oui, par contre faire > passer du SIP ou du flux RTP via un GIX, c'est assez moyen .. > > > >> Pour faire simple (je vulgarise beaucoup), Fabien , Alain, demain on se >> dit on met un serveur SIP (un peu un route-serveur finalement) à TH2, on >> monte chacun nos Trunk vers ce serveur, et comme on se connait bien et >> qu'on a confiance entre nous on s'échange par mail nos SDA, charge à chacun >> de mettre à jour ses routes. Sur le papier rien de compliqué... Faut juste >> un peu automatiser les choses, avoir un garant de confiance, et on n'embête >> personne... >> > > A la limite, oui la signalisation pourrait être centralisée et passer par > un ou deux proxy SIP d'une asso, et ensuite la SIG initie/reinvite le RTP > entre l'operateur A et B via leurs IP d'interco sans repasser par le proxy > SIP central . > > Mais cela fait malgré tout un SPOF sur la signalisation. Alors que si > chaque opérateur maintient quotidiennement sa base de SDA à jour localement > (via un système de batch) et ses interco réseau+voix avec les autres > opérateurs, il n'y a plus de SPOF, chaque opérateur reste maitre de son > infra. (ça ressemble quand même beaucoup au système APNF actuel .. :-) ) > > Donc au final, c'est juste une histoire de base de routage de numéro > décentralisée chez chaque opérateur (avec système de MAJ) + interco voix > entre chaque opérateur interessé. > > Mais effectivement comme indique "boite frnog", le projet sera/serait > surement tué dans l'oeuf faute de gros souhaitant rentrer et donc peu > d'intérêt pour les petits > > > > > > --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
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 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/
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
J’allais le dire. Sans au moins un SFR et/ou Free et/ou Bouygues, ca va échanger même pas 1% des appels cette usine à gaz. Et ils ne viendront pas, c’est quasi-sûr. C’est déjà la raison pour laquelle une tentative de ce genre (lancé par un ex-NeoTelecoms je crois) avait échoué. On 15 mai 2018 13:36 +0200, Fabien H , wrote: > Mais effectivement comme indique "boite frnog", le projet sera/serait > surement tué dans l'oeuf faute de gros souhaitant rentrer et donc peu > d'intérêt pour les petits > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
L'histoire du DNS, oui c'est intéressant mais il faut que le DNS soit privé ou filtré pour éviter de divulger des informations qui pourraient mettre en péril la "securité nationale". Oui, comme le FranceIX finalement. Un AS, des équipements à TH2, et tout le > monde se rejoint à la meetme. Donc finalement au niveau IP avons-nous > besoin de tout cela, le FranceIX le fait très bien ? Peut-être qu'il soit > pleinement séparé de la data ? Ce n’est pas idiot non plus... > Sur le principe de faire un meetme de type FranceIX oui, par contre faire passer du SIP ou du flux RTP via un GIX, c'est assez moyen .. > Pour faire simple (je vulgarise beaucoup), Fabien , Alain, demain on se > dit on met un serveur SIP (un peu un route-serveur finalement) à TH2, on > monte chacun nos Trunk vers ce serveur, et comme on se connait bien et > qu'on a confiance entre nous on s'échange par mail nos SDA, charge à chacun > de mettre à jour ses routes. Sur le papier rien de compliqué... Faut juste > un peu automatiser les choses, avoir un garant de confiance, et on n'embête > personne... > A la limite, oui la signalisation pourrait être centralisée et passer par un ou deux proxy SIP d'une asso, et ensuite la SIG initie/reinvite le RTP entre l'operateur A et B via leurs IP d'interco sans repasser par le proxy SIP central . Mais cela fait malgré tout un SPOF sur la signalisation. Alors que si chaque opérateur maintient quotidiennement sa base de SDA à jour localement (via un système de batch) et ses interco réseau+voix avec les autres opérateurs, il n'y a plus de SPOF, chaque opérateur reste maitre de son infra. (ça ressemble quand même beaucoup au système APNF actuel .. :-) ) Donc au final, c'est juste une histoire de base de routage de numéro décentralisée chez chaque opérateur (avec système de MAJ) + interco voix entre chaque opérateur interessé. Mais effectivement comme indique "boite frnog", le projet sera/serait surement tué dans l'oeuf faute de gros souhaitant rentrer et donc peu d'intérêt pour les petits --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
> je me suis sûrement mal exprimé, mais il faudrait des peering X spécifique à la voix. Pas en créer un, mais réalisé une "extension" de ceux existants, mais cette fois-ci avec de la QOS (SIP => precedence 3 / RTP => 5) etc ... Cela simplifierais le modèle, mais il faut pouvoir garantir une qualité parfaite des liens, une QoS aux petits oignons, pour un "traceroute" nickel, on parle d'un flux UDP, pas question de se faire écraser. D'où l'interco privée voix, comme n'importe qu'elle fournisseur voix t'imposes. >De plus, au niveau sécu, le client final ne peut pas discuter avec n'importe qui, il discute avec ton SBC dans ton propre réseau. >Puis, ton SBC discute avec le peering (ton SBC est trusté sur ce peering). Ah oui, là d'accord, je pensais que tu évoquais du P2P entre deux téléphones par exemple... D'où le fait que tu devrais accepter tout ce qui vient, le transcodage merdique qui irait avec etc... > Sujet véritablement énorme à traiter et certainement pas qu'entre provider... il faut un / des organismes de régulation et de confiance. Ouais, et je pense aussi qu'il faut surtout "un gros" en plus des petits dès le début, sinon assez pas de trafic pour viabilisé la chose. Sauf que les "gros" ont absolument tout à y perdre. Le 15 mai 2018 à 11:50, Mickael Hubert a écrit : > Justement non. > je me suis sûrement mal exprimé, mais il faudrait des peering X spécifique > à la voix. Pas en créer un, mais réalisé une "extension" de ceux existants, > mais cette fois-ci avec de la QOS (SIP => precedence 3 / RTP => 5) etc ... > De plus, au niveau sécu, le client final ne peut pas discuter avec > n'importe qui, il discute avec ton SBC dans ton propre réseau. > Puis, ton SBC discute avec le peering (ton SBC est trusté sur ce peering). > > Ex: > DATA: > CPE --> PE --> backbone IP --> transitaires IP ou peering X ou ... > > VOIP: > IPBX / E-SBC --> SBC --> backbone Voix --> transitaires Voix ou peering X > > Sujet véritablement énorme à traiter et certainement pas qu'entre > provider... il faut un / des organismes de régulation et de confiance. > > Le 15 mai 2018 à 11:21, boite frnog a écrit : > >> >1) j'ai un appel à destination du 0101010101, je demande déjà à mon DNS >> >interne (ENUM) si je connais, est-ce mon réseau ? >> >2) oui, je balance dans mon réseau ==> SBC interne qui gère le client, >> >pourquoi pas le client en direct... >> >3) non je ne gère pas ce numéro, a qui dois-je le balancer ? ==> soit sur >> >une interco directe que j'ai avec tel ou tel provider, soit au peering X, >> >soit ma route par défaut mon transitaire voix. >> >> Si l'idée oui, mais la voix est tellement sensible qu'il faut je pense >> plus s'appuyer sur des conversations uniquement entre SBC, et sur des >> interco IP très fiable. >> >> Tu vas également perdre le contrôle de ton flux si tu laisse le client >> discuter librement avec n'importe qui, et niveau sécu... >> >> >> Le 15 mai 2018 à 11:06, Mickael Hubert a écrit : >> >>> Il n'avait pas été question, il y a quelques temps, lors d'une réunion >>> FRNOG justement d'un SIP...X ? Il est vrai que d'interconnecter >>> l’ensemble >>> des petits entre eux est vain, mais les peering X sont là pour ça (au >>> niveau IP). >>> je n'ai sûrement pas tout les tenants et aboutissant, mais pourquoi >>> réinventer la roue ? Le DNS fonctionne très bien (avec peut-être un peu >>> plus de sécu à envisager), ENUM a été créé pour cela, pourquoi ne pas >>> s’appuyer la dessus. >>> >>> Je vous balance ça pêle-mêle, et c'est une vision trop minimaliste, mais >>> si >>> on prend exemple sur le BGP et les peering X: >>> >>> 1) j'ai un appel à destination du 0101010101, je demande déjà à mon DNS >>> interne (ENUM) si je connais, est-ce mon réseau ? >>> 2) oui, je balance dans mon réseau ==> SBC interne qui gère le client, >>> pourquoi pas le client en direct... >>> 3) non je ne gère pas ce numéro, a qui dois-je le balancer ? ==> soit sur >>> une interco directe que j'ai avec tel ou tel provider, soit au peering X, >>> soit ma route par défaut mon transitaire voix. >>> >>> A la différence de "l'internet", le plus réaliste serait que ces échanges >>> DNS ne soient autorisés qu'entre les providers déclarés ARCEP et que les >>> mises à jour ne proviennent que d'un point central et certifié (Ex: APNF) >>> De plus, pas d'automatisme de création des tables de routage d'appel >>> comme >>> BGP. Il faudrait que chaque provider puisse savoir quelle est la route la >>> plus "courte" pour joindre tel ou tel numéro en prenant en compte ses >>> propres interco à dispo. >>> >>> Bon c'est facile à dire... >>> >>> >>> Le 15 mai 2018 à 10:24, boite frnog a écrit : >>> >>> > 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é >>> > d
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
Justement non. je me suis sûrement mal exprimé, mais il faudrait des peering X spécifique à la voix. Pas en créer un, mais réalisé une "extension" de ceux existants, mais cette fois-ci avec de la QOS (SIP => precedence 3 / RTP => 5) etc ... De plus, au niveau sécu, le client final ne peut pas discuter avec n'importe qui, il discute avec ton SBC dans ton propre réseau. Puis, ton SBC discute avec le peering (ton SBC est trusté sur ce peering). Ex: DATA: CPE --> PE --> backbone IP --> transitaires IP ou peering X ou ... VOIP: IPBX / E-SBC --> SBC --> backbone Voix --> transitaires Voix ou peering X Sujet véritablement énorme à traiter et certainement pas qu'entre provider... il faut un / des organismes de régulation et de confiance. Le 15 mai 2018 à 11:21, boite frnog a écrit : > >1) j'ai un appel à destination du 0101010101, je demande déjà à mon DNS > >interne (ENUM) si je connais, est-ce mon réseau ? > >2) oui, je balance dans mon réseau ==> SBC interne qui gère le client, > >pourquoi pas le client en direct... > >3) non je ne gère pas ce numéro, a qui dois-je le balancer ? ==> soit sur > >une interco directe que j'ai avec tel ou tel provider, soit au peering X, > >soit ma route par défaut mon transitaire voix. > > Si l'idée oui, mais la voix est tellement sensible qu'il faut je pense > plus s'appuyer sur des conversations uniquement entre SBC, et sur des > interco IP très fiable. > > Tu vas également perdre le contrôle de ton flux si tu laisse le client > discuter librement avec n'importe qui, et niveau sécu... > > > Le 15 mai 2018 à 11:06, Mickael Hubert a écrit : > >> Il n'avait pas été question, il y a quelques temps, lors d'une réunion >> FRNOG justement d'un SIP...X ? Il est vrai que d'interconnecter l’ensemble >> des petits entre eux est vain, mais les peering X sont là pour ça (au >> niveau IP). >> je n'ai sûrement pas tout les tenants et aboutissant, mais pourquoi >> réinventer la roue ? Le DNS fonctionne très bien (avec peut-être un peu >> plus de sécu à envisager), ENUM a été créé pour cela, pourquoi ne pas >> s’appuyer la dessus. >> >> Je vous balance ça pêle-mêle, et c'est une vision trop minimaliste, mais >> si >> on prend exemple sur le BGP et les peering X: >> >> 1) j'ai un appel à destination du 0101010101, je demande déjà à mon DNS >> interne (ENUM) si je connais, est-ce mon réseau ? >> 2) oui, je balance dans mon réseau ==> SBC interne qui gère le client, >> pourquoi pas le client en direct... >> 3) non je ne gère pas ce numéro, a qui dois-je le balancer ? ==> soit sur >> une interco directe que j'ai avec tel ou tel provider, soit au peering X, >> soit ma route par défaut mon transitaire voix. >> >> A la différence de "l'internet", le plus réaliste serait que ces échanges >> DNS ne soient autorisés qu'entre les providers déclarés ARCEP et que les >> mises à jour ne proviennent que d'un point central et certifié (Ex: APNF) >> De plus, pas d'automatisme de création des tables de routage d'appel comme >> BGP. Il faudrait que chaque provider puisse savoir quelle est la route la >> plus "courte" pour joindre tel ou tel numéro en prenant en compte ses >> propres interco à dispo. >> >> Bon c'est facile à dire... >> >> >> Le 15 mai 2018 à 10:24, boite frnog a écrit : >> >> > 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...
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
>un des points à traiter est de définir les services téléphoniques que ces >intercos doivent supporter : >- que les appels ? >- du RCS, du UUS (user to user signaling), fax, voLTE, modem ... ? >- apres il y a les cas à traiter ayant des impacts techniques : appels >d'urgence, masquage d'identité sur des appels en arrivée depuis >l'international sans que le réseau n'est fourni un PAI/NDI, bref une >identité fiable... il faut se focaliser uniquement sur la notion de peering d'interco. Il n'est pas question de VoLTE, d'appel d'urgence, ou d'appel depuis ou vers l'int. Ce sont des sujets bien distincts. Je bien parler d'appel de peering entre opérateurs consentants :) A la façon d'SS7, finalement, on se contente de faire du SIP, du RTP, et du codec standard. Libre à toi de faire sur ton SBC du SIP=>VoLTE >Juste un exemple simple (qui se gère facilement mais donné à titre >d'illustration) : rien que les DTMF t'as 3 facons de le faire. >T'as aussi le fameux PRACK nécessaire pour l'early media, prôner par Free >mais pas prôner par la normalisation FFT... >Donc là on vient sur le sujet normalisation du transport SIP. Il faut aussi >se mettre d'accord sur la normalisation du media (RTP + RTCP) + RTCP-XR. >Qui dit interco veut dire aussi indicateurs/KPI à se mettre d'accord pour >débuguer, diagnostiquer, que chacun doit supporter Faut suivre ce qui existe, la FFT a de très bon document, il faut se calquer sur par exemple, les stats d'interco SIPI de grands... >Alors que faire ? Le plus petit dénominateur commun, qui est donc limitant >pour les services, ou au contraire faire le plus exhaustif et du coup qui >transcode/ fait l'adaptation de sig ? selon quelles regles (comprendre qui >favorise qui) ? >Je ne dis pas que c'est pas faisable, je dis juste que ca soulève de >nombreux points. Que les principaux intéressés sont les petits opérateurs >(les grands/gros aiment bien le cout du service transit comme déjà évoqué >par Mickael Hubert ( TA taxe d'acheminement). D'où l'assos, il faut des règles strictes. Autre point le billing, mais c'est aussi un autre sujet, tout est remis en cause avec la notion peering. Cela revient à évoquer le financement de la dîtes asso, mais encore un tout autre sujet. Mais je pense que le modèle doit être viable vue le cout des interco, mais fortement fonction des volumes. >Mickael dans ton dernier post, les etapes 1 à 3, le principe de routage (je >regarde en local et sinon je sors) c'est déjà ce que tu fais sans base ENUM. >Et comme tu le dis/ soulève, le probleme c'est la notion de fiabilité de >l'information. car si un petit malin se greffe, annonce des numeros qui ne >sont pas à lui (volontairement ou non), comment savoir qui a raison ? Il faut un tiers de confiance, et un mecanisme de confiance, cela me parait évident, mais rien d'impossible. Le 15 mai 2018 à 11:19, Cedric Millet (pro) a écrit : > Quand tu sais pas avec qui tu vas parler, si t'envoies des appels vers une > interco non définie, comment tu garantis que tel ou tel service va > fonctionner. C'est pour ca que dans la base ENUM tu dois aussi gérer aussi > la notion de services associés à un numéro/interco. > > un des points à traiter est de définir les services téléphoniques que ces > intercos doivent supporter : > - que les appels ? > - du RCS, du UUS (user to user signaling), fax, voLTE, modem ... ? > - apres il y a les cas à traiter ayant des impacts techniques : appels > d'urgence, masquage d'identité sur des appels en arrivée depuis > l'international sans que le réseau n'est fourni un PAI/NDI, bref une > identité fiable... > Juste un exemple simple (qui se gère facilement mais donné à titre > d'illustration) : rien que les DTMF t'as 3 facons de le faire. > T'as aussi le fameux PRACK nécessaire pour l'early media, prôner par Free > mais pas prôner par la normalisation FFT... > > Donc là on vient sur le sujet normalisation du transport SIP. Il faut aussi > se mettre d'accord sur la normalisation du media (RTP + RTCP) + RTCP-XR. > Qui dit interco veut dire aussi indicateurs/KPI à se mettre d'accord pour > débuguer, diagnostiquer, que chacun doit supporter > > Alors que faire ? Le plus petit dénominateur commun, qui est donc limitant > pour les services, ou au contraire faire le plus exhaustif et du coup qui > transcode/ fait l'adaptation de sig ? selon quelles regles (comprendre qui > favorise qui) ? > Je ne dis pas que c'est pas faisable, je dis juste que ca soulève de > nombreux points. Que les principaux intéressés sont les petits opérateurs > (les grands/gros aiment bien le cout du service transit comme déjà évoqué > par Mickael Hubert ( TA taxe d'acheminement). > > La base de numérotation centrale est nécessaire déjà évoquée avec l'échange > précédent quand on a parlé d'ENUM. > La base APNF ne contient que les sda portées. pas les tranches natives (aka > base GNUM). ou alors j'ai loupé un truc. > > > Mickael dans ton dernier post, les etapes 1 à 3, le principe de routage (je > regarde en local et sinon
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
>1) j'ai un appel à destination du 0101010101, je demande déjà à mon DNS >interne (ENUM) si je connais, est-ce mon réseau ? >2) oui, je balance dans mon réseau ==> SBC interne qui gère le client, >pourquoi pas le client en direct... >3) non je ne gère pas ce numéro, a qui dois-je le balancer ? ==> soit sur >une interco directe que j'ai avec tel ou tel provider, soit au peering X, >soit ma route par défaut mon transitaire voix. Si l'idée oui, mais la voix est tellement sensible qu'il faut je pense plus s'appuyer sur des conversations uniquement entre SBC, et sur des interco IP très fiable. Tu vas également perdre le contrôle de ton flux si tu laisse le client discuter librement avec n'importe qui, et niveau sécu... Le 15 mai 2018 à 11:06, Mickael Hubert a écrit : > Il n'avait pas été question, il y a quelques temps, lors d'une réunion > FRNOG justement d'un SIP...X ? Il est vrai que d'interconnecter l’ensemble > des petits entre eux est vain, mais les peering X sont là pour ça (au > niveau IP). > je n'ai sûrement pas tout les tenants et aboutissant, mais pourquoi > réinventer la roue ? Le DNS fonctionne très bien (avec peut-être un peu > plus de sécu à envisager), ENUM a été créé pour cela, pourquoi ne pas > s’appuyer la dessus. > > Je vous balance ça pêle-mêle, et c'est une vision trop minimaliste, mais si > on prend exemple sur le BGP et les peering X: > > 1) j'ai un appel à destination du 0101010101, je demande déjà à mon DNS > interne (ENUM) si je connais, est-ce mon réseau ? > 2) oui, je balance dans mon réseau ==> SBC interne qui gère le client, > pourquoi pas le client en direct... > 3) non je ne gère pas ce numéro, a qui dois-je le balancer ? ==> soit sur > une interco directe que j'ai avec tel ou tel provider, soit au peering X, > soit ma route par défaut mon transitaire voix. > > A la différence de "l'internet", le plus réaliste serait que ces échanges > DNS ne soient autorisés qu'entre les providers déclarés ARCEP et que les > mises à jour ne proviennent que d'un point central et certifié (Ex: APNF) > De plus, pas d'automatisme de création des tables de routage d'appel comme > BGP. Il faudrait que chaque provider puisse savoir quelle est la route la > plus "courte" pour joindre tel ou tel numéro en prenant en compte ses > propres interco à dispo. > > Bon c'est facile à dire... > > > Le 15 mai 2018 à 10:24, boite frnog a écrit : > > > 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/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
Quand tu sais pas avec qui tu vas parler, si t'envoies des appels vers une interco non définie, comment tu garantis que tel ou tel service va fonctionner. C'est pour ca que dans la base ENUM tu dois aussi gérer aussi la notion de services associés à un numéro/interco. un des points à traiter est de définir les services téléphoniques que ces intercos doivent supporter : - que les appels ? - du RCS, du UUS (user to user signaling), fax, voLTE, modem ... ? - apres il y a les cas à traiter ayant des impacts techniques : appels d'urgence, masquage d'identité sur des appels en arrivée depuis l'international sans que le réseau n'est fourni un PAI/NDI, bref une identité fiable... Juste un exemple simple (qui se gère facilement mais donné à titre d'illustration) : rien que les DTMF t'as 3 facons de le faire. T'as aussi le fameux PRACK nécessaire pour l'early media, prôner par Free mais pas prôner par la normalisation FFT... Donc là on vient sur le sujet normalisation du transport SIP. Il faut aussi se mettre d'accord sur la normalisation du media (RTP + RTCP) + RTCP-XR. Qui dit interco veut dire aussi indicateurs/KPI à se mettre d'accord pour débuguer, diagnostiquer, que chacun doit supporter Alors que faire ? Le plus petit dénominateur commun, qui est donc limitant pour les services, ou au contraire faire le plus exhaustif et du coup qui transcode/ fait l'adaptation de sig ? selon quelles regles (comprendre qui favorise qui) ? Je ne dis pas que c'est pas faisable, je dis juste que ca soulève de nombreux points. Que les principaux intéressés sont les petits opérateurs (les grands/gros aiment bien le cout du service transit comme déjà évoqué par Mickael Hubert ( TA taxe d'acheminement). La base de numérotation centrale est nécessaire déjà évoquée avec l'échange précédent quand on a parlé d'ENUM. La base APNF ne contient que les sda portées. pas les tranches natives (aka base GNUM). ou alors j'ai loupé un truc. Mickael dans ton dernier post, les etapes 1 à 3, le principe de routage (je regarde en local et sinon je sors) c'est déjà ce que tu fais sans base ENUM. Et comme tu le dis/ soulève, le probleme c'est la notion de fiabilité de l'information. car si un petit malin se greffe, annonce des numeros qui ne sont pas à lui (volontairement ou non), comment savoir qui a raison ? de nombreux sujets donc 2018-05-15 11:06 GMT+02:00 Mickael Hubert : > Il n'avait pas été question, il y a quelques temps, lors d'une réunion > FRNOG justement d'un SIP...X ? Il est vrai que d'interconnecter l’ensemble > des petits entre eux est vain, mais les peering X sont là pour ça (au > niveau IP). > je n'ai sûrement pas tout les tenants et aboutissant, mais pourquoi > réinventer la roue ? Le DNS fonctionne très bien (avec peut-être un peu > plus de sécu à envisager), ENUM a été créé pour cela, pourquoi ne pas > s’appuyer la dessus. > > Je vous balance ça pêle-mêle, et c'est une vision trop minimaliste, mais > si on prend exemple sur le BGP et les peering X: > > 1) j'ai un appel à destination du 0101010101, je demande déjà à mon DNS > interne (ENUM) si je connais, est-ce mon réseau ? > 2) oui, je balance dans mon réseau ==> SBC interne qui gère le client, > pourquoi pas le client en direct... > 3) non je ne gère pas ce numéro, a qui dois-je le balancer ? ==> soit sur > une interco directe que j'ai avec tel ou tel provider, soit au peering X, > soit ma route par défaut mon transitaire voix. > > A la différence de "l'internet", le plus réaliste serait que ces échanges > DNS ne soient autorisés qu'entre les providers déclarés ARCEP et que les > mises à jour ne proviennent que d'un point central et certifié (Ex: APNF) > De plus, pas d'automatisme de création des tables de routage d'appel comme > BGP. Il faudrait que chaque provider puisse savoir quelle est la route la > plus "courte" pour joindre tel ou tel numéro en prenant en compte ses > propres interco à dispo. > > Bon c'est facile à dire... > > > Le 15 mai 2018 à 10:24, boite frnog a écrit : > >> 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"
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
>L'APNF est une asso aussi :-) Je trouve qu'elle répondrait au besoin sur >l'aspect "traduction de numéro". Oui de toute façon il ne serait pas question de retirer la légitimité de l'APNF sur ce sujet. Mais une fois encore pour vulgariser la chose : ce n'est pas le RIPE qui va te configurer ta session BGP... Faudrait-il imaginer une extension de l'APNF ? >Il faudrait ensuite trouver un système >simple et sécurisé (filtrage IP, ..) pour que les différents petits/grands >opérateurs s'interconnectent en SIP entre eux (sur le même principe que >peering@operateur pour initier un "peering SIP"). Chacun est libre ensuite >au niveau IP d'ajouter la redondance et le transport L2 qu'il souhaite. Oui, comme le FranceIX finalement. Un AS, des équipements à TH2, et tout le monde se rejoint à la meetme. Donc finalement au niveau IP avons-nous besoin de tout cela, le FranceIX le fait très bien ? Peut-être qu'il soit pleinement séparé de la data ? Ce n’est pas idiot non plus... >Le prix de l'adhesion APNF de base n'est pas énorme pour un petit >opérateur. >Mais pour avoir accès à la base APNF pour interroger sur un ND donné ou >pour aller faire des annonces (donc en écriture) dans cette base, c'est >beaucoup plus cher. Et là c'est un autre aspect où cela peut coincer.. Mais >à un moment donné, il faut bien financer aussi l'asso qui héberge la base >de données (ou alors il faut décentraliser) Oui tout à fait, mais pourquoi passer par l'APNF ? Pour moi ce serait plus le rôle de l'"assos" de vérifier la cohérence des annonces avec la base APNF, seul et unique base légitime, évitant ainsi toute fraude. Pour faire simple (je vulgarise beaucoup), Fabien , Alain, demain on se dit on met un serveur SIP (un peu un route-serveur finalement) à TH2, on monte chacun nos Trunk vers ce serveur, et comme on se connait bien et qu'on a confiance entre nous on s'échange par mail nos SDA, charge à chacun de mettre à jour ses routes. Sur le papier rien de compliqué... Faut juste un peu automatiser les choses, avoir un garant de confiance, et on n'embête personne... Le 15 mai 2018 à 11:01, Fabien H a écrit : > L'APNF est une asso aussi :-) Je trouve qu'elle répondrait au besoin sur > l'aspect "traduction de numéro". Il faudrait ensuite trouver un système > simple et sécurisé (filtrage IP, ..) pour que les différents petits/grands > opérateurs s'interconnectent en SIP entre eux (sur le même principe que > peering@operateur pour initier un "peering SIP"). Chacun est libre ensuite > au niveau IP d'ajouter la redondance et le transport L2 qu'il souhaite. > > Le prix de l'adhesion APNF de base n'est pas énorme pour un petit > opérateur. > > Mais pour avoir accès à la base APNF pour interroger sur un ND donné ou > pour aller faire des annonces (donc en écriture) dans cette base, c'est > beaucoup plus cher. Et là c'est un autre aspect où cela peut coincer.. Mais > à un moment donné, il faut bien financer aussi l'asso qui héberge la base > de données (ou alors il faut décentraliser) > > > > Le 15 mai 2018 à 10:51, boite frnog a écrit : > > > J'entends bien... Mais je pensais à quelque chose de plus simple. Il faut > > bien que tu saches si tu envoies ton appel à ton transitaire, ou si tu > > envoies ton appel à ton SBC de peering SIP depuis ton SBC. > > > > Ce qui implique que finalement (et je vais sans doute en choquer plus > d'un > > sur cette liste) tu t'en moques de la base APNF, puisque soit tu check > > d'abord la base de la supposée asso et si ton SDA de destination n'est > pas > > dedans, tu envoies à ton transitaire voix. > > > > > > Le 15 mai 2018 à 10:41, Alain Bieuzent a écrit > : > > > > > La base de données existe déjà et elle est gérée par l'APNF. Elle > permet > > > de savoir à un instant T vers quel opérateur doit ont routé un SDA. > > > > > > Le 15/05/2018 10:25, « boite frnog » de > > > mailbox.fr...@gmail.com> a écrit : > > > > > > 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'i
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
>Il faudrait ensuite trouver un système >simple et sécurisé (filtrage IP, ..) pour que les différents petits/grands >opérateurs s'interconnectent en SIP entre eux (sur le même principe que >peering@operateur pour initier un "peering SIP"). Chaque opérateur est identifié par un code, et a un référent. On pourrait rebasculer sur le domaine de l'email du référent pour aller chercher un enregistrement DNS TXT ou apnf. pour avoir l'IP du SBC de chaque opérateur une fois qu'on a l'opérateur qui gère numéro (porté ou non). > Le prix de l'adhesion APNF de base n'est pas énorme pour un petit >opérateur. Cool, bon à savoir. :) >L'APNF est une asso aussi :-) Je trouve qu'elle répondrait au besoin sur >l'aspect "traduction de numéro" Je suis pour aussi, pour éviter les multi-hosting, etc.. L'APNF est déjà très bien placée pour cela et je pense que globalement, ca marche. A quand une API dispo à interroger en lecture :) (opendata) ? Sinon quelqu'un sait si le système existe dans d'autres pays ? Régis Le 15 mai 2018 à 11:01, Fabien H a écrit : > L'APNF est une asso aussi :-) Je trouve qu'elle répondrait au besoin sur > l'aspect "traduction de numéro". Il faudrait ensuite trouver un système > simple et sécurisé (filtrage IP, ..) pour que les différents petits/grands > opérateurs s'interconnectent en SIP entre eux (sur le même principe que > peering@operateur pour initier un "peering SIP"). Chacun est libre ensuite > au niveau IP d'ajouter la redondance et le transport L2 qu'il souhaite. > > Le prix de l'adhesion APNF de base n'est pas énorme pour un petit > opérateur. > > Mais pour avoir accès à la base APNF pour interroger sur un ND donné ou > pour aller faire des annonces (donc en écriture) dans cette base, c'est > beaucoup plus cher. Et là c'est un autre aspect où cela peut coincer.. Mais > à un moment donné, il faut bien financer aussi l'asso qui héberge la base > de données (ou alors il faut décentraliser) > > > > Le 15 mai 2018 à 10:51, boite frnog a écrit : > > > J'entends bien... Mais je pensais à quelque chose de plus simple. Il faut > > bien que tu saches si tu envoies ton appel à ton transitaire, ou si tu > > envoies ton appel à ton SBC de peering SIP depuis ton SBC. > > > > Ce qui implique que finalement (et je vais sans doute en choquer plus > d'un > > sur cette liste) tu t'en moques de la base APNF, puisque soit tu check > > d'abord la base de la supposée asso et si ton SDA de destination n'est > pas > > dedans, tu envoies à ton transitaire voix. > > > > > > Le 15 mai 2018 à 10:41, Alain Bieuzent a écrit > : > > > > > La base de données existe déjà et elle est gérée par l'APNF. Elle > permet > > > de savoir à un instant T vers quel opérateur doit ont routé un SDA. > > > > > > Le 15/05/2018 10:25, « boite frnog » de > > > mailbox.fr...@gmail.com> a écrit : > > > > > > 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
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
Il n'avait pas été question, il y a quelques temps, lors d'une réunion FRNOG justement d'un SIP...X ? Il est vrai que d'interconnecter l’ensemble des petits entre eux est vain, mais les peering X sont là pour ça (au niveau IP). je n'ai sûrement pas tout les tenants et aboutissant, mais pourquoi réinventer la roue ? Le DNS fonctionne très bien (avec peut-être un peu plus de sécu à envisager), ENUM a été créé pour cela, pourquoi ne pas s’appuyer la dessus. Je vous balance ça pêle-mêle, et c'est une vision trop minimaliste, mais si on prend exemple sur le BGP et les peering X: 1) j'ai un appel à destination du 0101010101, je demande déjà à mon DNS interne (ENUM) si je connais, est-ce mon réseau ? 2) oui, je balance dans mon réseau ==> SBC interne qui gère le client, pourquoi pas le client en direct... 3) non je ne gère pas ce numéro, a qui dois-je le balancer ? ==> soit sur une interco directe que j'ai avec tel ou tel provider, soit au peering X, soit ma route par défaut mon transitaire voix. A la différence de "l'internet", le plus réaliste serait que ces échanges DNS ne soient autorisés qu'entre les providers déclarés ARCEP et que les mises à jour ne proviennent que d'un point central et certifié (Ex: APNF) De plus, pas d'automatisme de création des tables de routage d'appel comme BGP. Il faudrait que chaque provider puisse savoir quelle est la route la plus "courte" pour joindre tel ou tel numéro en prenant en compte ses propres interco à dispo. Bon c'est facile à dire... Le 15 mai 2018 à 10:24, boite frnog a écrit : > 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/
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
Dommage de créer une deuxième base alors que les infos dont on aurait besoin sont déjà présente et mise à jour coté APNF. De plus pour ceux qui utilise déjà la base APNF, cela fera deux requêtes pour chaque appel, pour ceux qui ont de gros volumes ça peut poser un souci. Le 15/05/2018 10:52, « boite frnog » a écrit : J'entends bien... Mais je pensais à quelque chose de plus simple. Il faut bien que tu saches si tu envoies ton appel à ton transitaire, ou si tu envoies ton appel à ton SBC de peering SIP depuis ton SBC. Ce qui implique que finalement (et je vais sans doute en choquer plus d'un sur cette liste) tu t'en moques de la base APNF, puisque soit tu check d'abord la base de la supposée asso et si ton SDA de destination n'est pas dedans, tu envoies à ton transitaire voix. Le 15 mai 2018 à 10:41, Alain Bieuzent a écrit : > La base de données existe déjà et elle est gérée par l'APNF. Elle permet > de savoir à un instant T vers quel opérateur doit ont routé un SDA. > > Le 15/05/2018 10:25, « boite frnog » mailbox.fr...@gmail.com> a écrit : > > 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/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
L'APNF est une asso aussi :-) Je trouve qu'elle répondrait au besoin sur l'aspect "traduction de numéro". Il faudrait ensuite trouver un système simple et sécurisé (filtrage IP, ..) pour que les différents petits/grands opérateurs s'interconnectent en SIP entre eux (sur le même principe que peering@operateur pour initier un "peering SIP"). Chacun est libre ensuite au niveau IP d'ajouter la redondance et le transport L2 qu'il souhaite. Le prix de l'adhesion APNF de base n'est pas énorme pour un petit opérateur. Mais pour avoir accès à la base APNF pour interroger sur un ND donné ou pour aller faire des annonces (donc en écriture) dans cette base, c'est beaucoup plus cher. Et là c'est un autre aspect où cela peut coincer.. Mais à un moment donné, il faut bien financer aussi l'asso qui héberge la base de données (ou alors il faut décentraliser) Le 15 mai 2018 à 10:51, boite frnog a écrit : > J'entends bien... Mais je pensais à quelque chose de plus simple. Il faut > bien que tu saches si tu envoies ton appel à ton transitaire, ou si tu > envoies ton appel à ton SBC de peering SIP depuis ton SBC. > > Ce qui implique que finalement (et je vais sans doute en choquer plus d'un > sur cette liste) tu t'en moques de la base APNF, puisque soit tu check > d'abord la base de la supposée asso et si ton SDA de destination n'est pas > dedans, tu envoies à ton transitaire voix. > > > Le 15 mai 2018 à 10:41, Alain Bieuzent a écrit : > > > La base de données existe déjà et elle est gérée par l'APNF. Elle permet > > de savoir à un instant T vers quel opérateur doit ont routé un SDA. > > > > Le 15/05/2018 10:25, « boite frnog » > mailbox.fr...@gmail.com> a écrit : > > > > 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/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
J'entends bien... Mais je pensais à quelque chose de plus simple. Il faut bien que tu saches si tu envoies ton appel à ton transitaire, ou si tu envoies ton appel à ton SBC de peering SIP depuis ton SBC. Ce qui implique que finalement (et je vais sans doute en choquer plus d'un sur cette liste) tu t'en moques de la base APNF, puisque soit tu check d'abord la base de la supposée asso et si ton SDA de destination n'est pas dedans, tu envoies à ton transitaire voix. Le 15 mai 2018 à 10:41, Alain Bieuzent a écrit : > La base de données existe déjà et elle est gérée par l'APNF. Elle permet > de savoir à un instant T vers quel opérateur doit ont routé un SDA. > > Le 15/05/2018 10:25, « boite frnog » mailbox.fr...@gmail.com> a écrit : > > 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/
Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)
La base de données existe déjà et elle est gérée par l'APNF. Elle permet de savoir à un instant T vers quel opérateur doit ont routé un SDA. Le 15/05/2018 10:25, « boite frnog » a écrit : 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/
