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 devai
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 devai
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
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'es
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 d
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
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
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 composan
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
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é à plusi
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.
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).
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
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
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 w
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’e
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
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 devie
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
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
ienne 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 propositi
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 lo
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
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 un
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 r
oujours 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
Ob
ui 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, f
re 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 pollue
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.
P
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
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 responsabi
Pour ceux que cela intéresse voilà la com d'OVH
http://mj.ovh.com/lnk/AAOQIBAAARZrylAAAFlmiY0AAPiDvlwAFihtAAVMlQBa-wUyiluYDoEjRGWTTD_qsQggRAABHT4/1/cV-o3neJSH8uzaDa7FERdQ/aHR0cDovL21qLm92aC5jb20vbmwyLzVyN2wvMTJvaXQuaHRtbD9tPUFBQUFBQU9RSUJBQUFSWnJ5bEFBQUZsbWlZMEFBUGlEdmx3QUZpaHRBQVZNbFFCYS13VXl
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.
>
>
e 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, o
c : 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 m
: [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 dan
+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
+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 proj
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 quel
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
utô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]
> 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 i
ite 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 c
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 1
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 fi
> 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
> 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
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 discu
>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é su
>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 ses
>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ére
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éi
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
peering
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
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
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 év
60 matches
Mail list logo
