Hello,
Le 2018-05-17 12:08, Mickael Hubert a écrit :
Bonjour à tous,
Le 17 mai 2018 à 11:19, Richard DEMONGEOT <rich...@demongeot.biz> a
écrit :
Hello,
Toutes les idées a base de BGP sont très sexy, et intéressantes, mais
il
reste un problème de base. Comment chaque opérateur va devoir
implémenter
un composant liant BGP / Voix.
Cependant, comme évoqué à plusieurs reprises, pas de modifications
incessantes de la table de routage voix.
*Pour ma part le composant de routage pour la voix devrait-être le DNS
(ENUM), je sais j'insiste sur ce point ;) , mais devoir trouver /
développer un composant "gateway" entre BGP et voix pour gérer du
trafic de
prod me semble hasardeux.*
*Bon, ce composant existe peut-être déjà, je ne sais pas...*
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
;)
)*
On est bien d'accord.
Cordialement,
--
Richard
---------------------------
Liste de diffusion du FRnOG
http://www.frnog.org/
