Bonjour à tous,
Le 17 mai 2018 à 11:19, Richard DEMONGEOT <rich...@demongeot.biz> a écrit :
Hello,
Toutes les idées a base de BGP sont très sexy, et intéressantes, mais il
reste un problème de base. Comment chaque opérateur va devoir implémenter
un composant liant BGP / Voix.
Cependant, comme évoqué à plusieurs reprises, pas de modifications
incessantes de la table de routage voix.
*Pour ma part le composant de routage pour la voix devrait-être le DNS
(ENUM), je sais j'insiste sur ce point ;) , mais devoir trouver /
développer un composant "gateway" entre BGP et voix pour gérer du trafic de
prod me semble hasardeux.*
*Bon, ce composant existe peut-être déjà, je ne sais pas...*
Pour la table de routage internationale, OSEF dans un IX. (ou alors, c'est
un GIE, donc avec plusieurs fournisseurs, et c'est plus complexe). Dans
tous les cas, les changements sur les non-membres : on s'en fout. (porta
depuis / vers les membres à gérer uniquement). Exemple : porta orange / sfr
: quel impact vu qu'a moyen terme aucun des deux ne sera dessus? Pire,
belgacom / proxymus?
Pour moi, le plus simple, sur, rapide, fonctionnel reste :
Un IX dédié à la voix (qu'on peut multiplier à souhaits).
Sur cet IX :
- Chaque membre qui s'y connecte doit y mettre un ou plusieurs SBC;
- L'association fourni un ou plusieurs proxy SIP - en guise de voice route
server.
Coût pour l'association :
1 switch (1G/10G de préférence);
3 serveurs (db + proxy).
Le cheminement serai alors le suivant :
Le SBC du client envoie son INVITE SIP, sur le / l'un des proxy.
Le proxy intérroge la DB, fournie par l'APNF, et route sur le bon membre.
=> Si c'est pas sur un membre, alors plusieurs cas sont possibles :
A/ L'association renvoi un code retour temporaire ou permanent sur ce
numéro (pas routable sur l'IX);
B/ L'association étant un GIE, et disposant de contrat de terminaison SIP
peut router le numéro. ==> Quid de la facturation/re-facturation? Par
contre, économie d'échelle si les contrats sont mutualisés.
=> Si le membre ne réponds pas (SIP option réguliers) alors on réponds une
erreur temporaire. (ou on load balance sur moins d'IP si le membre a
plusieurs SBC)
*Chaque provider connecté au X doit avoir une réplication de la DB. Car si
tout est géré (au niveau routage voix par le X) nous nous retrouverons dans
le même cas (plantage d'Orange) si celui-ci plante.*
*De plus, cela engendre du trafic SIP (et des réponses) pour pas grand
chose.*
*Je voyais cela plutôt:*
*- lors de l'import de la DB APNF chez le provider, celui-ci sait qui se
trouve connecté sur tel ou tel X et donc créé sa propre DB avec tel préfixe
vers tel X (donc telle IP), puis tel préfixe vers l'autre X, etc ... (cela
peut-être automatisé, voir même si on parle d'asso en plus de l'APNF,
celle-ci pourrait fournir une DB modifiée avec les préfixes quelle gère)*
*- lors d'un appel vers tel numéro hors de son réseau, la DB chez le
provider sait où envoyer au plus proche*
*- Sinon on envoie par défaut sur son transitaire voix (du genre Orange ;)
)*
Dans les deux cas, ralentissement de l'établissement de quelques
milli-secondes pour le SBC appelant, c'est largement acceptable pour
fall-back sur un autre fournisseur.
Dans le modèle IX, je préfère l'option A, qui simplifie le boulot pour
l'asso.
Et pour la croissance me direz vous?
Là encore, deux options :
A/ On déploie un IX dans chaque DC, en se moquant complètement de
l'interco, c'est à dire que chaque POP est stand-alone; (coûts multipliés
par le nombre de POP)
B/ On déploie un réseau multi DC (donc plus complexe), et les membres de
l'interco Lyon peuvent taper sur des ressources Bordeaux. Pour les SBC des
clients, c'est simple, ils mettent une interface en /28 sur le POP, et une
route vers la /22. (coût qui ne sont pas proportionnels au nombre de POP,
mais besoin d'équipement L3 pour gérer le backbone).
Point bonus de la solution B, le proxy peut être anycasté entre plusieurs
POP.
Dans tous les cas, l'asso ne gère pas de transcoding (les membres envoient
le RTP de pair à pair);
Tant que tous les membres respectent un critère simple, supporter au moins
le G.711, tout est inter-opérable;
Si deux membres veulent jouer avec de la visio, ou des codec de plus haute
qualité, ça n'a aucun impact sur les autres.
Les membres n'ont pas à avoir de connaissances BGP (je sais, on est sur
frnog, le BGP c'est simple)
*100% d'accord le X ne doit pas s'embêter avec du temps réel et du
transcoding.*
*chaque provider est assez grand pour se mettre d'accord avec son
destinataire (vive le SDP)*
Avec juste le proxy sur les invite (donc initiation d'appel), l'asso ne
peut pas influer sur la qualité de la voix (mono POP).
Celle-ci est garantie, vue que les SBC parlent entre eux sur le même
subnet. Dans le cas d'un réseau multi-pop, c'est plus complexe.
Côté revenus de l'association, les options seraient :
- coût au port d'interconnexion - fixe;
- coût à la BP réellement utilisée;
- coût d'initiation (ie par appel - mais complètement incohérent pour moi).
Et pour moi, l'asso est gérée par ses membres, avec une évolution vers un
GIE à terme :
Besoin de quelques SBC propres à l'association, de contrats de transit
Orange / SFR / BICS / ... et LCR vers ces destinations
Cordialement,
Le 2018-05-16 09:48, David Ponzone a écrit :
Je balance une idée en l’air entre 2 tartines.
Si on prenait quelques octets en plus devant le numéro de téléphone
pour y mettre le préfixe de porta (celui de l’ARCEP si l’opérateur en
a un, sinon un attribué par l’association).
Ainsi, le SBC de l’opérateur a toutes les infos dans la route.
L’AS et le next-hop, c’est celui du RS de l’IX-Voix de toute façon,
car pour moi c’est un IX dont les membres peerent seuleement avec le
RS, qui est un tiers de confiance qui envoie une information
contrôlée.
Le SBC de l’opérateur peut alors récupérer le préfixe de porta dans la
route.
Si le prefixe de porta est 10000 par exemple, il cherche dans une
table interne ou alors il fait un lookup DNS pour avoir les champs TXT
par exemple de la zone 10000.domain.gtld, qui vont contenir les
différentes IP des SBC auxquels il faut envoyer l’appel (soit les SBC
de l’autre opérateur, soit ceux de l’IX, en fonction du modèle
technico-économique choisi).
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
