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
> ,
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
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
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
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
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
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
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
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
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.
>
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.
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,
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
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
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
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
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
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
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
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).
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
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
.
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 <nico...@bougues.net>
Envoyé : mercredi 16 mai 2018 02:09
À : frnog@frnog.org
Objet : Re: [FRnOG] [MISC] P
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,
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
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.
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
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
Pour ceux que cela intéresse voilà la com d'OVH
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
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.
>
>
+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
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
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
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
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
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
> 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
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
>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é
>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 ? ==>
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
>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
>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
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
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, «
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
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)
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
49 matches
Mail list logo