date:20180515

RE: [FRnOG] [TECH] Serveur d'authentification

2018-05-15 Par sujet Michel Py

> Marcel Duregards a écrit :
> Auriez-vous des conseils concernant un serveur d'authentification radius (si 
> il fait tacacs en plus, c'est un avantage)
> pour l'authentification d'utilisateurs sur des devices (typiquement switch, 
> routeurs cisco, cpe divers, etc), qui puisse:

As-tu regardé freeradius ?  https://freeradius.org/  j'ai utilisé dans le 
passé, çà a marché pour moi.

> - le must (mais j'ai peur que ce soit propre ï¿½ tacacs), qui permettre de 
> changer le mdp ï¿½ la volï¿½e en se logguant sur
> la CLI cisco. p.e on se connecte ï¿½ un router cisco avec nos credentials, le 
> serveur radius donne son ack, mais impose le
> changement de mdp car il a expirï¿½ (le supplicant est forcï¿½ de changer son 
> mdp, via l'interface de l'authenticator)

Euh, c'est quelle page de code que tu utilises, là ? je suis le seul qui à eu 
les accents pas glop ?

Michel.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

2018-05-15 Par sujet Nicolas Bougues

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

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

2018-05-15 Par sujet Alexis Lameire

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
>

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

2018-05-15 Par sujet David Ponzone

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
> >

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

2018-05-15 Par sujet Alexis Lameire

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/

[FRnOG] [MISC] Quand c'est pas le jour (14/05) !

2018-05-15 Par sujet Xavier ROCA

https://www.ledauphine.com/savoie/2018/05/14/faits-divers

 

 

 


---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] [MISC] Panne Nationale voix Orange : quand le service client est magique

2018-05-15 Par sujet Michel Py

> David Ponzone a écrit :
> PS: t’étais tellement coupé du monde que t’as pas lu tes mails du jour ?

J'avais pas encore lu le fil :P

> PS2: va falloir sérieusement upgrader les routeurs, parce qu’on a déjà du mal 
> avec 600k routes :) #balancetonCisco6500

C'était un problème de taille de la table de routage ?

> Bon, ok, ça prendrait combien de RAM 10 millions de route ?

Si c'est du BGP, environ 1KO par route, parfois plus, donc 10 millions de 
routes = 10 GO à la louche.

Pas grand-chose aujourd'hui si c'est de la RAM, mais si c'est de la TCAM çà 
coute la peau du postérieur.
Un bit de TCAM çà prend 12 à 14 transistors si je comprends bien, au lieu de 6 
pour de la SRAM et 3 pour de la DRAM.

Chauffe Marcel.

Michel.


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Panne Nationale voix Orange : quand le service client est magique

2018-05-15 Par sujet David Ponzone

Oui mais comme cela a déjà été dit, cela revient à refaire un APNF.
Par contre APNF 2.0 ne demanderait pas une fortune pour avoir le droit de 
récupérer la liste des numéros portés/préfixe de porta .
Et on pourrait même y intégrer une DB associant le numéro long à un numéro 
d’urgence et un code INSEE donné. En mode dump ou webservice éventuellement.


On 15 mai 2018 19:01 +0200, Guillaume Barrot , 
wrote:
> Ben tous les opérateurs ont bien une DB avec l'ensemble de leurs clients, 
> numéro de tél etc, non ?
> Ah ben oui au hasard, ça s'appelle un HLR/HSS dans le monde mobile. Tu as les 
> MSC aussi qui ont la vue de l'intégralité de la table de routage voix ...
>
> Nan, bon, bref, ça se fait, c'est pas un pb technique, par contre aucune 
> norme n'a jamais pensé à ce que ça puisse 1) sortir du réseau d'un opérateur 
> 2) être ultra dynamique (nan mais un envoi de CSV et un délai de porta en 7j, 
> ça ira bien à tout le monde)
>
> > Le 15 mai 2018 à 18:56, David Ponzone  a écrit :
> > > Bon, ok, ça prendrait combien de RAM 10 millions de route ?
> > >
> > >
> > > On 15 mai 2018 18:54 +0200, Guillaume Barrot 
> > > , wrote:
> > > > PS1 : Nan mais ça a coupé, mais OSEF, j'étais pas impacté (je vends pas 
> > > > de voix, je suis pas fou).
> > > > PS2 : #ahahahjaipasdeciscojesuispasfounonplus
> > > >
> > > > > Le 15 mai 2018 à 18:49, David Ponzone  a 
> > > > > écrit :
> > > > > > PS: t’étais tellement coupé du monde que t’as pas lu tes mails du 
> > > > > > jour ?
> > > > > > PS2: va falloir sérieusement upgrader les routeurs, parce qu’on a 
> > > > > > déjà du mal avec 600k routes :) #balancetonCisco6500
> > > > > >
> > > > > > On 15 mai 2018 18:43 +0200, Guillaume Barrot 
> > > > > > , wrote:
> > > > > > > Reçu ce jour d'un opérateur dont je citerai le nom à propos de la 
> > > > > > > panne
> > > > > > > chez Orange
> > > > > > >
> > > > > > > "*Des solutions de contournement ont été mises en place hier soir 
> > > > > > > mais la
> > > > > > > panne s'est reproduite ce matin dans les mêmes conditions*."
> > > > > > >
> > > > > > > Voilà, donc comment dire ... si la panne s'est reproduite dans 
> > > > > > > les mêmes
> > > > > > > conditions ET que ça a a encore merdé ... c'est que les solutions 
> > > > > > > de
> > > > > > > contournement, en fait, elles contournaient pas grand chose en 
> > > > > > > fait ?
> > > > > > > Merci au service client de cet opérateur de nous confirmer qu'ils
> > > > > > > comprennent absolument pas comment ils ont gaulés la voix sur 
> > > > > > > leur réseau,
> > > > > > > et que bon en fait, l'archi c'est "on a un contrat chez Orange, 
> > > > > > > normalement
> > > > > > > ça marche".
> > > > > > > Grand moment de lolitude absolue.
> > > > > > >
> > > > > > > PS : y en a qui seraient intéressés par monter un "IX" mais 
> > > > > > > orienté voix ?
> > > > > > > PS2 : y en a qui seraient intéressés par faire une RFC pour 
> > > > > > > annoncer des
> > > > > > > SDA via une extension BGP ? (@Nico, si tu m'entends ...)
> > > > > > >
> > > > > > > ---
> > > > > > > Liste de diffusion du FRnOG
> > > > > > > http://www.frnog.org/
> > > >
> > > >
> > > >
> > > > --
> > > > Cordialement,
> > > >
> > > > Guillaume BARROT
>
>
>
> --
> Cordialement,
>
> Guillaume BARROT

---
Liste de diffusion du FRnOG
http://www.frnog.org/

RE: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

2018-05-15 Par sujet Xavier ROCA

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] Panne Nationale voix Orange : quand le service client est magique

2018-05-15 Par sujet Guillaume Barrot

Ben tous les opérateurs ont bien une DB avec l'ensemble de leurs clients,
numéro de tél etc, non ?
Ah ben oui au hasard, ça s'appelle un HLR/HSS dans le monde mobile. Tu as
les MSC aussi qui ont la vue de l'intégralité de la table de routage voix
...

Nan, bon, bref, ça se fait, c'est pas un pb technique, par contre aucune
norme n'a jamais pensé à ce que ça puisse 1) sortir du réseau d'un
opérateur 2) être ultra dynamique (nan mais un envoi de CSV et un délai de
porta en 7j, ça ira bien à tout le monde)

Le 15 mai 2018 à 18:56, David Ponzone  a écrit :

> Bon, ok, ça prendrait combien de RAM 10 millions de route ?
>
>
> On 15 mai 2018 18:54 +0200, Guillaume Barrot ,
> wrote:
>
> PS1 : Nan mais ça a coupé, mais OSEF, j'étais pas impacté (je vends pas de
> voix, je suis pas fou).
> PS2 : #ahahahjaipasdeciscojesuispasfounonplus
>
> Le 15 mai 2018 à 18:49, David Ponzone  a écrit :
>
>> PS: t’étais tellement coupé du monde que t’as pas lu tes mails du jour ?
>> PS2: va falloir sérieusement upgrader les routeurs, parce qu’on a déjà du
>> mal avec 600k routes :) #balancetonCisco6500
>>
>> On 15 mai 2018 18:43 +0200, Guillaume Barrot ,
>> wrote:
>>
>> Reçu ce jour d'un opérateur dont je citerai le nom à propos de la panne
>> chez Orange
>>
>> "*Des solutions de contournement ont été mises en place hier soir mais la
>> panne s'est reproduite ce matin dans les mêmes conditions*."
>>
>> Voilà, donc comment dire ... si la panne s'est reproduite dans les mêmes
>> conditions ET que ça a a encore merdé ... c'est que les solutions de
>> contournement, en fait, elles contournaient pas grand chose en fait ?
>> Merci au service client de cet opérateur de nous confirmer qu'ils
>> comprennent absolument pas comment ils ont gaulés la voix sur leur réseau,
>> et que bon en fait, l'archi c'est "on a un contrat chez Orange,
>> normalement
>> ça marche".
>> Grand moment de lolitude absolue.
>>
>> PS : y en a qui seraient intéressés par monter un "IX" mais orienté voix ?
>> PS2 : y en a qui seraient intéressés par faire une RFC pour annoncer des
>> SDA via une extension BGP ? (@Nico, si tu m'entends ...)
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>>
>
>
> --
> Cordialement,
>
> Guillaume BARROT
>
>


-- 
Cordialement,

Guillaume BARROT

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Panne Nationale voix Orange : quand le service client est magique

2018-05-15 Par sujet Guillaume Barrot

PS1 : Nan mais ça a coupé, mais OSEF, j'étais pas impacté (je vends pas de
voix, je suis pas fou).
PS2 : #ahahahjaipasdeciscojesuispasfounonplus

Le 15 mai 2018 à 18:49, David Ponzone  a écrit :

> PS: t’étais tellement coupé du monde que t’as pas lu tes mails du jour ?
> PS2: va falloir sérieusement upgrader les routeurs, parce qu’on a déjà du
> mal avec 600k routes :) #balancetonCisco6500
>
> On 15 mai 2018 18:43 +0200, Guillaume Barrot ,
> wrote:
>
> Reçu ce jour d'un opérateur dont je citerai le nom à propos de la panne
> chez Orange
>
> "*Des solutions de contournement ont été mises en place hier soir mais la
> panne s'est reproduite ce matin dans les mêmes conditions*."
>
> Voilà, donc comment dire ... si la panne s'est reproduite dans les mêmes
> conditions ET que ça a a encore merdé ... c'est que les solutions de
> contournement, en fait, elles contournaient pas grand chose en fait ?
> Merci au service client de cet opérateur de nous confirmer qu'ils
> comprennent absolument pas comment ils ont gaulés la voix sur leur réseau,
> et que bon en fait, l'archi c'est "on a un contrat chez Orange, normalement
> ça marche".
> Grand moment de lolitude absolue.
>
> PS : y en a qui seraient intéressés par monter un "IX" mais orienté voix ?
> PS2 : y en a qui seraient intéressés par faire une RFC pour annoncer des
> SDA via une extension BGP ? (@Nico, si tu m'entends ...)
>
> ---
> 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)

2018-05-15 Par sujet Guillaume Barrot

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] Panne Nationale voix Orange : quand le service client est magique

2018-05-15 Par sujet David Ponzone

PS: t’étais tellement coupé du monde que t’as pas lu tes mails du jour ?
PS2: va falloir sérieusement upgrader les routeurs, parce qu’on a déjà du mal 
avec 600k routes :) #balancetonCisco6500

On 15 mai 2018 18:43 +0200, Guillaume Barrot , 
wrote:
> Reçu ce jour d'un opérateur dont je citerai le nom à propos de la panne
> chez Orange
>
> "*Des solutions de contournement ont été mises en place hier soir mais la
> panne s'est reproduite ce matin dans les mêmes conditions*."
>
> Voilà, donc comment dire ... si la panne s'est reproduite dans les mêmes
> conditions ET que ça a a encore merdé ... c'est que les solutions de
> contournement, en fait, elles contournaient pas grand chose en fait ?
> Merci au service client de cet opérateur de nous confirmer qu'ils
> comprennent absolument pas comment ils ont gaulés la voix sur leur réseau,
> et que bon en fait, l'archi c'est "on a un contrat chez Orange, normalement
> ça marche".
> Grand moment de lolitude absolue.
>
> PS : y en a qui seraient intéressés par monter un "IX" mais orienté voix ?
> PS2 : y en a qui seraient intéressés par faire une RFC pour annoncer des
> SDA via une extension BGP ? (@Nico, si tu m'entends ...)
>
> ---
> 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)

2018-05-15 Par sujet Raphael Jacquot

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/

[FRnOG] [TECH] Verrouillage fibre optique

2018-05-15 Par sujet Christian ROLLAND


Bonjour,

Nous sommes à la recherche de retours d'expérience sur le 
verrouillage/la sécurisation de jarretières optique avec connecteurs SC 
lorsque les panneaux de brassage ne sont pas dans des baies fermées. 
Nous avons trouvé des produits pour du LC mais rien en SC. Si quelqu'un 
a une solution.


Merci d'avance,

Christian ROLLAND
--
Christian ROLLANDESRF
Network AdministratorEuropean Synchrotron Radiation Facility
Phone : +33 (0)476 88 20 69  71 avenue des Martyrs
Email : roll...@esrf.eu  38000 GRENOBLE - FRANCE



---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

2018-05-15 Par sujet Alain Bieuzent

+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)

2018-05-15 Par sujet David Ponzone

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)

2018-05-15 Par sujet Fabien H

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)

2018-05-15 Par sujet boite frnog

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)

2018-05-15 Par sujet David Ponzone

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)

2018-05-15 Par sujet Fabien H

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/

Fwd: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

2018-05-15 Par sujet boite frnog

 > 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é
>>>

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

2018-05-15 Par sujet boite frnog

 > 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é
>>>

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

2018-05-15 Par sujet Mickael Hubert

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

Re: [FRnOG] [ALERT] Problème interco orange

2018-05-15 Par sujet Mickael LE MOINE


Bonjour,

Voici le retour de Orange à 11h30 :

/Nous confirmons un incident technique impactant l’interconnexion fixe 
et mobile avec les autres opérateurs.///


///Il ne s’agit pas d’une panne mais bien d’un service fortement dégradé 
pour les interconnexions./


/Nous n'avons malheureusement pas de délai de rétablissement à vous 
communiquer pour le moment./


Très cordialement.

Le 15/05/2018 à 11:11, Mickael Hubert a écrit :

info de SFR à 10h47

"L¿incident ayant impactant les services Voix au niveau national (y compris
intra-SFR sur les services mobiles) le 14/05 10H a été corrigé par Orange
sur leur infrastructure hier à 16H45. Cependant, nous subissons une
nouvelle occurrence sur les services voix fixes ce jour depuis 10H. Nos
équipes techniques sont mobilisées avec l¿opérateur historique pour
résoudre ce problème."

Le 15 mai 2018 à 10:27, Thomas Raynal  a écrit :


Bonjour,

Même constat ici.
A noter que contrairement à hier, ils cassent les appels avec des "404 not
found" plutôt que des "408 timeouts".
Ce n'est pas vraiment le code d'erreur que j'aurai attendu s'ils avaient
mis en place un mécanisme de shaping pour protéger leurs équipements.
Quelque chose d'autre qui s'est effondré chez eux avec la montée en charge
ce matin?


Le 15/05/2018 à 10:15, Steeve BEAUVAIS - Société Serinya Telecom a écrit :


Bonjour,

On dirait bien que c'est reparti. Mon outils de supervision me remonte des
échecs d'appels.

Cordialement,

[image:
http://www.serinyatelecom.fr/signatures/signature-steeve-bea
uvais-serinya-telecom.jpg]





Le 15 mai 2018 à 10:12, Mickael Hubert  a écrit :

Un petit ENUM vite fait, c'est faisable, mais tu veux te passer de la TA

(taxe d'acheminement) ?
Bon, elle ne cesse de baisser, mais ça risque de faire grincer des dents.
mdr

Le 15 mai 2018 à 09:40, David Ponzone  a écrit
:

A priori rien chez nous pour le moment.

Mais possible que les clients comprennent que le problème n’est pas
terminé et n’appellent pas

Bon, qui met un petit ENUM en place vite fait, pour qu’on ait les appels
entre nous au moins ? :)


On 15 mai 2018 09:37 +0200, Mickael Hubert , wrote:

Bonjour à tous,


Et ça continue ;)
Ce matin 8h30 parfait, mais nous étions en période creuse.
9h - 9h30 de nouveau impacté.

Pouvez-vous nous donner une vision de votre coté svp ?

merci d'avance

Le 14 mai 2018 à 22:44, Julien OHAYON  a écrit :

C’est pour ça qu’on a aussi inventé les DNS.
On est archaïque :)

Une adresse mail pour appeler serait tellement mieux :)

Julien OHAYON
Directeur Technique
APPLIWAVE

Tel : 09.71.18.71.11

Le 14 mai 2018 à 22:39, David Ponzone  a écrit

:


Hmm s’il n’a jamais été possible de changer d’ISP en gardant son IPv4,

il y avait peut être une raison ? :)

Quelqu’un a une idée du nombre de numéros e164 portés ( les /32 de la

téléphonie), donc désagrégés, rien qu’en France ?


David Ponzone



Le 14 mai 2018 à 18:48, Jérôme Nicolle  a écrit :

Xavier,

Le 14/05/2018 à 18:34, Xavier ROCA a écrit :
Amis Opérateurs alternatifs faut vraiment faire évoluer l'interco VoIP

dans ce pays et se bouger de faire une norme type BGP Voix car cela


devient


un peu trop Merd à notre gout.


Presque facile, il suffit d'encoder E.164 en BCD (avec padding pour

certains préfixes), et de signer l'annonce avec un certificat délivré
par
l'attributaire de la tranche ou du numéro.


La principale difficulté c'est l'interception légale, pour laquelle il

faut un type de session particulier provoquant un mirroring de la SIG et


du


Media. Ça doit pouvoir s'envisager avec une communauté "well known",
tout
comme l'annonce des coûts d'acheminement pour avoir un LCR dynamique.


Le seul morceau que je ne visualise pas bien, c'est la localité de

signifiance d'une extension. Ça devrait pouvoir se déclarer avec des
route-maps de traduction, mais je n'en suis pas certain.


Ensuite on encapsule la SIG en SIP et/ou XMPP, et ça devrait rouler…

Non ?

--
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/



---
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/


---
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)

2018-05-15 Par sujet boite frnog

>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
>

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

2018-05-15 Par sujet boite frnog

>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)

2018-05-15 Par sujet Cedric Millet (pro)

 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

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

2018-05-15 Par sujet boite frnog

>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

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

2018-05-15 Par sujet Régis M

>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
> > >

Re: [FRnOG] [ALERT] Problème interco orange

2018-05-15 Par sujet Mickael Hubert

info de SFR à 10h47

"L¿incident ayant impactant les services Voix au niveau national (y compris
intra-SFR sur les services mobiles) le 14/05 10H a été corrigé par Orange
sur leur infrastructure hier à 16H45. Cependant, nous subissons une
nouvelle occurrence sur les services voix fixes ce jour depuis 10H. Nos
équipes techniques sont mobilisées avec l¿opérateur historique pour
résoudre ce problème."

Le 15 mai 2018 à 10:27, Thomas Raynal  a écrit :

> Bonjour,
>
> Même constat ici.
> A noter que contrairement à hier, ils cassent les appels avec des "404 not
> found" plutôt que des "408 timeouts".
> Ce n'est pas vraiment le code d'erreur que j'aurai attendu s'ils avaient
> mis en place un mécanisme de shaping pour protéger leurs équipements.
> Quelque chose d'autre qui s'est effondré chez eux avec la montée en charge
> ce matin?
>
>
> Le 15/05/2018 à 10:15, Steeve BEAUVAIS - Société Serinya Telecom a écrit :
>
>> Bonjour,
>>
>> On dirait bien que c'est reparti. Mon outils de supervision me remonte des
>> échecs d'appels.
>>
>> Cordialement,
>>
>> [image:
>> http://www.serinyatelecom.fr/signatures/signature-steeve-bea
>> uvais-serinya-telecom.jpg]
>>
>>
>> 
>>
>>
>> Le 15 mai 2018 à 10:12, Mickael Hubert  a écrit :
>>
>> Un petit ENUM vite fait, c'est faisable, mais tu veux te passer de la TA
>>> (taxe d'acheminement) ?
>>> Bon, elle ne cesse de baisser, mais ça risque de faire grincer des dents.
>>> mdr
>>>
>>> Le 15 mai 2018 à 09:40, David Ponzone  a écrit
>>> :
>>>
>>> A priori rien chez nous pour le moment.
 Mais possible que les clients comprennent que le problème n’est pas
 terminé et n’appellent pas

 Bon, qui met un petit ENUM en place vite fait, pour qu’on ait les appels
 entre nous au moins ? :)


 On 15 mai 2018 09:37 +0200, Mickael Hubert , wrote:

 Bonjour à tous,


 Et ça continue ;)
 Ce matin 8h30 parfait, mais nous étions en période creuse.
 9h - 9h30 de nouveau impacté.

 Pouvez-vous nous donner une vision de votre coté svp ?

 merci d'avance

 Le 14 mai 2018 à 22:44, Julien OHAYON  a écrit :

 C’est pour ça qu’on a aussi inventé les DNS.
 On est archaïque :)

 Une adresse mail pour appeler serait tellement mieux :)

 Julien OHAYON
 Directeur Technique
 APPLIWAVE

 Tel : 09.71.18.71.11

 Le 14 mai 2018 à 22:39, David Ponzone  a écrit

 :


 Hmm s’il n’a jamais été possible de changer d’ISP en gardant son IPv4,

 il y avait peut être une raison ? :)

 Quelqu’un a une idée du nombre de numéros e164 portés ( les /32 de la

 téléphonie), donc désagrégés, rien qu’en France ?


 David Ponzone



 Le 14 mai 2018 à 18:48, Jérôme Nicolle  a écrit :

 Xavier,

 Le 14/05/2018 à 18:34, Xavier ROCA a écrit :
 Amis Opérateurs alternatifs faut vraiment faire évoluer l'interco VoIP

 dans ce pays et se bouger de faire une norme type BGP Voix car cela

>>> devient
>>>
 un peu trop Merd à notre gout.


 Presque facile, il suffit d'encoder E.164 en BCD (avec padding pour

 certains préfixes), et de signer l'annonce avec un certificat délivré
 par
 l'attributaire de la tranche ou du numéro.


 La principale difficulté c'est l'interception légale, pour laquelle il

 faut un type de session particulier provoquant un mirroring de la SIG et

>>> du
>>>
 Media. Ça doit pouvoir s'envisager avec une communauté "well known",
 tout
 comme l'annonce des coûts d'acheminement pour avoir un LCR dynamique.


 Le seul morceau que je ne visualise pas bien, c'est la localité de

 signifiance d'une extension. Ça devrait pouvoir se déclarer avec des
 route-maps de traduction, mais je n'en suis pas certain.


 Ensuite on encapsule la SIG en SIP et/ou XMPP, et ça devrait rouler…

 Non ?

 --
 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/



 ---
 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/
>

---
Liste de

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

2018-05-15 Par sujet 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" 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)

2018-05-15 Par sujet Alain Bieuzent

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)

2018-05-15 Par sujet Fabien H

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)

2018-05-15 Par sujet boite frnog

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)

2018-05-15 Par sujet Alain Bieuzent

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/

Re: [FRnOG] [ALERT] Problème interco orange

2018-05-15 Par sujet Thomas Raynal


Bonjour,

Même constat ici.
A noter que contrairement à hier, ils cassent les appels avec des "404 
not found" plutôt que des "408 timeouts".
Ce n'est pas vraiment le code d'erreur que j'aurai attendu s'ils avaient 
mis en place un mécanisme de shaping pour protéger leurs équipements. 
Quelque chose d'autre qui s'est effondré chez eux avec la montée en 
charge ce matin?



Le 15/05/2018 à 10:15, Steeve BEAUVAIS - Société Serinya Telecom a écrit :

Bonjour,

On dirait bien que c'est reparti. Mon outils de supervision me remonte des
échecs d'appels.

Cordialement,

[image:
http://www.serinyatelecom.fr/signatures/signature-steeve-beauvais-serinya-telecom.jpg]




Le 15 mai 2018 à 10:12, Mickael Hubert  a écrit :


Un petit ENUM vite fait, c'est faisable, mais tu veux te passer de la TA
(taxe d'acheminement) ?
Bon, elle ne cesse de baisser, mais ça risque de faire grincer des dents.
mdr

Le 15 mai 2018 à 09:40, David Ponzone  a écrit :


A priori rien chez nous pour le moment.
Mais possible que les clients comprennent que le problème n’est pas
terminé et n’appellent pas

Bon, qui met un petit ENUM en place vite fait, pour qu’on ait les appels
entre nous au moins ? :)


On 15 mai 2018 09:37 +0200, Mickael Hubert , wrote:

Bonjour à tous,


Et ça continue ;)
Ce matin 8h30 parfait, mais nous étions en période creuse.
9h - 9h30 de nouveau impacté.

Pouvez-vous nous donner une vision de votre coté svp ?

merci d'avance

Le 14 mai 2018 à 22:44, Julien OHAYON  a écrit :

C’est pour ça qu’on a aussi inventé les DNS.
On est archaïque :)

Une adresse mail pour appeler serait tellement mieux :)

Julien OHAYON
Directeur Technique
APPLIWAVE

Tel : 09.71.18.71.11

Le 14 mai 2018 à 22:39, David Ponzone  a écrit

:


Hmm s’il n’a jamais été possible de changer d’ISP en gardant son IPv4,

il y avait peut être une raison ? :)

Quelqu’un a une idée du nombre de numéros e164 portés ( les /32 de la

téléphonie), donc désagrégés, rien qu’en France ?


David Ponzone



Le 14 mai 2018 à 18:48, Jérôme Nicolle  a écrit :

Xavier,

Le 14/05/2018 à 18:34, Xavier ROCA a écrit :
Amis Opérateurs alternatifs faut vraiment faire évoluer l'interco VoIP

dans ce pays et se bouger de faire une norme type BGP Voix car cela

devient

un peu trop Merd à notre gout.


Presque facile, il suffit d'encoder E.164 en BCD (avec padding pour

certains préfixes), et de signer l'annonce avec un certificat délivré par
l'attributaire de la tranche ou du numéro.


La principale difficulté c'est l'interception légale, pour laquelle il

faut un type de session particulier provoquant un mirroring de la SIG et

du

Media. Ça doit pouvoir s'envisager avec une communauté "well known", tout
comme l'annonce des coûts d'acheminement pour avoir un LCR dynamique.


Le seul morceau que je ne visualise pas bien, c'est la localité de

signifiance d'une extension. Ça devrait pouvoir se déclarer avec des
route-maps de traduction, mais je n'en suis pas certain.


Ensuite on encapsule la SIG en SIP et/ou XMPP, et ça devrait rouler…

Non ?

--
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/



---
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] [ALERT] Problème interco orange

2018-05-15 Par sujet David Ponzone

Bon, Class-action ? :)

Et puis on met l’ARCEP devant sa responsabilité: 20 ans de régulation et Orange 
est toujours l’intermédiaire pour la quasi-totalité des appels offnet (sauf 
entre opérateurs mobile)

On 15 mai 2018 10:20 +0200, Alain Bieuzent , wrote:
> Défaut confirmé par les équipes d'Orange depuis 10h05
>
> Le 15/05/2018 10:19, « Florian Pougheon »  f...@flojpg.fr> a écrit :
>
> Idem pour moi !
>
> L'agrume commence à me faire monter la moutarde au nez !
>
> Florian P
>
>
> Le 15/05/2018 à 10:15, Steeve BEAUVAIS - Société Serinya Telecom a écrit :
> > Bonjour,
> >
> > On dirait bien que c'est reparti. Mon outils de supervision me remonte des
> > échecs d'appels.
> >
> > Cordialement,
> >
> > [image:
> > http://www.serinyatelecom.fr/signatures/signature-steeve-beauvais-serinya-telecom.jpg]
> >
> >
> >  >
> > Le 15 mai 2018 à 10:12, Mickael Hubert  a écrit :
> >
> > > Un petit ENUM vite fait, c'est faisable, mais tu veux te passer de la TA
> > > (taxe d'acheminement) ?
> > > Bon, elle ne cesse de baisser, mais ça risque de faire grincer des dents.
> > > mdr
> > >
> > > Le 15 mai 2018 à 09:40, David Ponzone  a écrit :
> > >
> > > > A priori rien chez nous pour le moment.
> > > > Mais possible que les clients comprennent que le problème n’est pas
> > > > terminé et n’appellent pas
> > > >
> > > > Bon, qui met un petit ENUM en place vite fait, pour qu’on ait les appels
> > > > entre nous au moins ? :)
> > > >
> > > >
> > > > On 15 mai 2018 09:37 +0200, Mickael Hubert , wrote:
> > > >
> > > > Bonjour à tous,
> > > >
> > > >
> > > > Et ça continue ;)
> > > > Ce matin 8h30 parfait, mais nous étions en période creuse.
> > > > 9h - 9h30 de nouveau impacté.
> > > >
> > > > Pouvez-vous nous donner une vision de votre coté svp ?
> > > >
> > > > merci d'avance
> > > >
> > > > Le 14 mai 2018 à 22:44, Julien OHAYON  a écrit :
> > > >
> > > > C’est pour ça qu’on a aussi inventé les DNS.
> > > > On est archaïque :)
> > > >
> > > > Une adresse mail pour appeler serait tellement mieux :)
> > > >
> > > > Julien OHAYON
> > > > Directeur Technique
> > > > APPLIWAVE
> > > >
> > > > Tel : 09.71.18.71.11
> > > >
> > > > Le 14 mai 2018 à 22:39, David Ponzone  a écrit
> > > >
> > > > :
> > > >
> > > >
> > > > Hmm s’il n’a jamais été possible de changer d’ISP en gardant son IPv4,
> > > >
> > > > il y avait peut être une raison ? :)
> > > >
> > > > Quelqu’un a une idée du nombre de numéros e164 portés ( les /32 de la
> > > >
> > > > téléphonie), donc désagrégés, rien qu’en France ?
> > > >
> > > >
> > > > David Ponzone
> > > >
> > > >
> > > >
> > > > Le 14 mai 2018 à 18:48, Jérôme Nicolle  a écrit :
> > > >
> > > > Xavier,
> > > >
> > > > Le 14/05/2018 à 18:34, Xavier ROCA a écrit :
> > > > Amis Opérateurs alternatifs faut vraiment faire évoluer l'interco VoIP
> > > >
> > > > dans ce pays et se bouger de faire une norme type BGP Voix car cela
> > > devient
> > > > un peu trop Merd à notre gout.
> > > >
> > > >
> > > > Presque facile, il suffit d'encoder E.164 en BCD (avec padding pour
> > > >
> > > > certains préfixes), et de signer l'annonce avec un certificat délivré 
> > > > par
> > > > l'attributaire de la tranche ou du numéro.
> > > >
> > > >
> > > > La principale difficulté c'est l'interception légale, pour laquelle il
> > > >
> > > > faut un type de session particulier provoquant un mirroring de la SIG et
> > > du
> > > > Media. Ça doit pouvoir s'envisager avec une communauté "well known", 
> > > > tout
> > > > comme l'annonce des coûts d'acheminement pour avoir un LCR dynamique.
> > > >
> > > >
> > > > Le seul morceau que je ne visualise pas bien, c'est la localité de
> > > >
> > > > signifiance d'une extension. Ça devrait pouvoir se déclarer avec des
> > > > route-maps de traduction, mais je n'en suis pas certain.
> > > >
> > > >
> > > > Ensuite on encapsule la SIG en SIP et/ou XMPP, et ça devrait rouler…
> > > >
> > > > Non ?
> > > >
> > > > --
> > > > 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/
> > > >
> > > >
> > > >
> > > > ---
> > > > 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
>

[FRnOG] [MISC] Peering SIP (was Problème interco orange)

2018-05-15 Par sujet boite frnog

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/

Re: [FRnOG] [ALERT] Problème interco orange

2018-05-15 Par sujet Alain Bieuzent

Défaut confirmé par les équipes d'Orange depuis 10h05

Le 15/05/2018 10:19, « Florian Pougheon »  a écrit :

Idem pour moi !

L'agrume commence à me faire monter la moutarde au nez !

Florian P


Le 15/05/2018 à 10:15, Steeve BEAUVAIS - Société Serinya Telecom a écrit :
> Bonjour,
>
> On dirait bien que c'est reparti. Mon outils de supervision me remonte des
> échecs d'appels.
>
> Cordialement,
>
> [image:
> 
http://www.serinyatelecom.fr/signatures/signature-steeve-beauvais-serinya-telecom.jpg]
>
>
> 
>
> Le 15 mai 2018 à 10:12, Mickael Hubert  a écrit :
>
>> Un petit ENUM vite fait, c'est faisable, mais tu veux te passer de la TA
>> (taxe d'acheminement) ?
>> Bon, elle ne cesse de baisser, mais ça risque de faire grincer des dents.
>> mdr
>>
>> Le 15 mai 2018 à 09:40, David Ponzone  a écrit :
>>
>>> A priori rien chez nous pour le moment.
>>> Mais possible que les clients comprennent que le problème n’est pas
>>> terminé et n’appellent pas
>>>
>>> Bon, qui met un petit ENUM en place vite fait, pour qu’on ait les appels
>>> entre nous au moins ? :)
>>>
>>>
>>> On 15 mai 2018 09:37 +0200, Mickael Hubert , wrote:
>>>
>>> Bonjour à tous,
>>>
>>>
>>> Et ça continue ;)
>>> Ce matin 8h30 parfait, mais nous étions en période creuse.
>>> 9h - 9h30 de nouveau impacté.
>>>
>>> Pouvez-vous nous donner une vision de votre coté svp ?
>>>
>>> merci d'avance
>>>
>>> Le 14 mai 2018 à 22:44, Julien OHAYON  a écrit :
>>>
>>> C’est pour ça qu’on a aussi inventé les DNS.
>>> On est archaïque :)
>>>
>>> Une adresse mail pour appeler serait tellement mieux :)
>>>
>>> Julien OHAYON
>>> Directeur Technique
>>> APPLIWAVE
>>>
>>> Tel : 09.71.18.71.11
>>>
>>> Le 14 mai 2018 à 22:39, David Ponzone  a écrit
>>>
>>> :
>>>
>>>
>>> Hmm s’il n’a jamais été possible de changer d’ISP en gardant son IPv4,
>>>
>>> il y avait peut être une raison ? :)
>>>
>>> Quelqu’un a une idée du nombre de numéros e164 portés ( les /32 de la
>>>
>>> téléphonie), donc désagrégés, rien qu’en France ?
>>>
>>>
>>> David Ponzone
>>>
>>>
>>>
>>> Le 14 mai 2018 à 18:48, Jérôme Nicolle  a écrit :
>>>
>>> Xavier,
>>>
>>> Le 14/05/2018 à 18:34, Xavier ROCA a écrit :
>>> Amis Opérateurs alternatifs faut vraiment faire évoluer l'interco VoIP
>>>
>>> dans ce pays et se bouger de faire une norme type BGP Voix car cela
>> devient
>>> un peu trop Merd à notre gout.
>>>
>>>
>>> Presque facile, il suffit d'encoder E.164 en BCD (avec padding pour
>>>
>>> certains préfixes), et de signer l'annonce avec un certificat délivré 
par
>>> l'attributaire de la tranche ou du numéro.
>>>
>>>
>>> La principale difficulté c'est l'interception légale, pour laquelle il
>>>
>>> faut un type de session particulier provoquant un mirroring de la SIG et
>> du
>>> Media. Ça doit pouvoir s'envisager avec une communauté "well known", 
tout
>>> comme l'annonce des coûts d'acheminement pour avoir un LCR dynamique.
>>>
>>>
>>> Le seul morceau que je ne visualise pas bien, c'est la localité de
>>>
>>> signifiance d'une extension. Ça devrait pouvoir se déclarer avec des
>>> route-maps de traduction, mais je n'en suis pas certain.
>>>
>>>
>>> Ensuite on encapsule la SIG en SIP et/ou XMPP, et ça devrait rouler…
>>>
>>> Non ?
>>>
>>> --
>>> 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/
>>>
>>>
>>>
>>> ---
>>> 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/




---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] Problème interco orange

2018-05-15 Par sujet Florian Pougheon


Idem pour moi !

L'agrume commence à me faire monter la moutarde au nez !

Florian P


Le 15/05/2018 à 10:15, Steeve BEAUVAIS - Société Serinya Telecom a écrit :

Bonjour,

On dirait bien que c'est reparti. Mon outils de supervision me remonte des
échecs d'appels.

Cordialement,

[image:
http://www.serinyatelecom.fr/signatures/signature-steeve-beauvais-serinya-telecom.jpg]




Le 15 mai 2018 à 10:12, Mickael Hubert  a écrit :


Un petit ENUM vite fait, c'est faisable, mais tu veux te passer de la TA
(taxe d'acheminement) ?
Bon, elle ne cesse de baisser, mais ça risque de faire grincer des dents.
mdr

Le 15 mai 2018 à 09:40, David Ponzone  a écrit :


A priori rien chez nous pour le moment.
Mais possible que les clients comprennent que le problème n’est pas
terminé et n’appellent pas

Bon, qui met un petit ENUM en place vite fait, pour qu’on ait les appels
entre nous au moins ? :)


On 15 mai 2018 09:37 +0200, Mickael Hubert , wrote:

Bonjour à tous,


Et ça continue ;)
Ce matin 8h30 parfait, mais nous étions en période creuse.
9h - 9h30 de nouveau impacté.

Pouvez-vous nous donner une vision de votre coté svp ?

merci d'avance

Le 14 mai 2018 à 22:44, Julien OHAYON  a écrit :

C’est pour ça qu’on a aussi inventé les DNS.
On est archaïque :)

Une adresse mail pour appeler serait tellement mieux :)

Julien OHAYON
Directeur Technique
APPLIWAVE

Tel : 09.71.18.71.11

Le 14 mai 2018 à 22:39, David Ponzone  a écrit

:


Hmm s’il n’a jamais été possible de changer d’ISP en gardant son IPv4,

il y avait peut être une raison ? :)

Quelqu’un a une idée du nombre de numéros e164 portés ( les /32 de la

téléphonie), donc désagrégés, rien qu’en France ?


David Ponzone



Le 14 mai 2018 à 18:48, Jérôme Nicolle  a écrit :

Xavier,

Le 14/05/2018 à 18:34, Xavier ROCA a écrit :
Amis Opérateurs alternatifs faut vraiment faire évoluer l'interco VoIP

dans ce pays et se bouger de faire une norme type BGP Voix car cela

devient

un peu trop Merd à notre gout.


Presque facile, il suffit d'encoder E.164 en BCD (avec padding pour

certains préfixes), et de signer l'annonce avec un certificat délivré par
l'attributaire de la tranche ou du numéro.


La principale difficulté c'est l'interception légale, pour laquelle il

faut un type de session particulier provoquant un mirroring de la SIG et

du

Media. Ça doit pouvoir s'envisager avec une communauté "well known", tout
comme l'annonce des coûts d'acheminement pour avoir un LCR dynamique.


Le seul morceau que je ne visualise pas bien, c'est la localité de

signifiance d'une extension. Ça devrait pouvoir se déclarer avec des
route-maps de traduction, mais je n'en suis pas certain.


Ensuite on encapsule la SIG en SIP et/ou XMPP, et ça devrait rouler…

Non ?

--
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/



---
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] [ALERT] Problème interco orange

2018-05-15 Par sujet Jérôme Nicolle



Le 14/05/2018 à 21:33, Gregoire Huet a écrit :
> proof of stack.

*Stake*

-- 
Jérôme Nicolle
06 19 31 27 14


---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] Problème interco orange

2018-05-15 Par sujet Steeve BEAUVAIS - Société Serinya Telecom

Bonjour,

On dirait bien que c'est reparti. Mon outils de supervision me remonte des
échecs d'appels.

Cordialement,

[image:
http://www.serinyatelecom.fr/signatures/signature-steeve-beauvais-serinya-telecom.jpg]




Le 15 mai 2018 à 10:12, Mickael Hubert  a écrit :

> Un petit ENUM vite fait, c'est faisable, mais tu veux te passer de la TA
> (taxe d'acheminement) ?
> Bon, elle ne cesse de baisser, mais ça risque de faire grincer des dents.
> mdr
>
> Le 15 mai 2018 à 09:40, David Ponzone  a écrit :
>
> > A priori rien chez nous pour le moment.
> > Mais possible que les clients comprennent que le problème n’est pas
> > terminé et n’appellent pas
> >
> > Bon, qui met un petit ENUM en place vite fait, pour qu’on ait les appels
> > entre nous au moins ? :)
> >
> >
> > On 15 mai 2018 09:37 +0200, Mickael Hubert , wrote:
> >
> > Bonjour à tous,
> >
> >
> > Et ça continue ;)
> > Ce matin 8h30 parfait, mais nous étions en période creuse.
> > 9h - 9h30 de nouveau impacté.
> >
> > Pouvez-vous nous donner une vision de votre coté svp ?
> >
> > merci d'avance
> >
> > Le 14 mai 2018 à 22:44, Julien OHAYON  a écrit :
> >
> > C’est pour ça qu’on a aussi inventé les DNS.
> > On est archaïque :)
> >
> > Une adresse mail pour appeler serait tellement mieux :)
> >
> > Julien OHAYON
> > Directeur Technique
> > APPLIWAVE
> >
> > Tel : 09.71.18.71.11
> >
> > Le 14 mai 2018 à 22:39, David Ponzone  a écrit
> >
> > :
> >
> >
> > Hmm s’il n’a jamais été possible de changer d’ISP en gardant son IPv4,
> >
> > il y avait peut être une raison ? :)
> >
> > Quelqu’un a une idée du nombre de numéros e164 portés ( les /32 de la
> >
> > téléphonie), donc désagrégés, rien qu’en France ?
> >
> >
> > David Ponzone
> >
> >
> >
> > Le 14 mai 2018 à 18:48, Jérôme Nicolle  a écrit :
> >
> > Xavier,
> >
> > Le 14/05/2018 à 18:34, Xavier ROCA a écrit :
> > Amis Opérateurs alternatifs faut vraiment faire évoluer l'interco VoIP
> >
> > dans ce pays et se bouger de faire une norme type BGP Voix car cela
> devient
> > un peu trop Merd à notre gout.
> >
> >
> > Presque facile, il suffit d'encoder E.164 en BCD (avec padding pour
> >
> > certains préfixes), et de signer l'annonce avec un certificat délivré par
> > l'attributaire de la tranche ou du numéro.
> >
> >
> > La principale difficulté c'est l'interception légale, pour laquelle il
> >
> > faut un type de session particulier provoquant un mirroring de la SIG et
> du
> > Media. Ça doit pouvoir s'envisager avec une communauté "well known", tout
> > comme l'annonce des coûts d'acheminement pour avoir un LCR dynamique.
> >
> >
> > Le seul morceau que je ne visualise pas bien, c'est la localité de
> >
> > signifiance d'une extension. Ça devrait pouvoir se déclarer avec des
> > route-maps de traduction, mais je n'en suis pas certain.
> >
> >
> > Ensuite on encapsule la SIG en SIP et/ou XMPP, et ça devrait rouler…
> >
> > Non ?
> >
> > --
> > 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/
> >
> >
> >
> > ---
> > 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] [ALERT] Problème interco orange

2018-05-15 Par sujet Mickael Hubert

Un petit ENUM vite fait, c'est faisable, mais tu veux te passer de la TA
(taxe d'acheminement) ?
Bon, elle ne cesse de baisser, mais ça risque de faire grincer des dents.
mdr

Le 15 mai 2018 à 09:40, David Ponzone  a écrit :

> A priori rien chez nous pour le moment.
> Mais possible que les clients comprennent que le problème n’est pas
> terminé et n’appellent pas
>
> Bon, qui met un petit ENUM en place vite fait, pour qu’on ait les appels
> entre nous au moins ? :)
>
>
> On 15 mai 2018 09:37 +0200, Mickael Hubert , wrote:
>
> Bonjour à tous,
>
>
> Et ça continue ;)
> Ce matin 8h30 parfait, mais nous étions en période creuse.
> 9h - 9h30 de nouveau impacté.
>
> Pouvez-vous nous donner une vision de votre coté svp ?
>
> merci d'avance
>
> Le 14 mai 2018 à 22:44, Julien OHAYON  a écrit :
>
> C’est pour ça qu’on a aussi inventé les DNS.
> On est archaïque :)
>
> Une adresse mail pour appeler serait tellement mieux :)
>
> Julien OHAYON
> Directeur Technique
> APPLIWAVE
>
> Tel : 09.71.18.71.11
>
> Le 14 mai 2018 à 22:39, David Ponzone  a écrit
>
> :
>
>
> Hmm s’il n’a jamais été possible de changer d’ISP en gardant son IPv4,
>
> il y avait peut être une raison ? :)
>
> Quelqu’un a une idée du nombre de numéros e164 portés ( les /32 de la
>
> téléphonie), donc désagrégés, rien qu’en France ?
>
>
> David Ponzone
>
>
>
> Le 14 mai 2018 à 18:48, Jérôme Nicolle  a écrit :
>
> Xavier,
>
> Le 14/05/2018 à 18:34, Xavier ROCA a écrit :
> Amis Opérateurs alternatifs faut vraiment faire évoluer l'interco VoIP
>
> dans ce pays et se bouger de faire une norme type BGP Voix car cela devient
> un peu trop Merd à notre gout.
>
>
> Presque facile, il suffit d'encoder E.164 en BCD (avec padding pour
>
> certains préfixes), et de signer l'annonce avec un certificat délivré par
> l'attributaire de la tranche ou du numéro.
>
>
> La principale difficulté c'est l'interception légale, pour laquelle il
>
> faut un type de session particulier provoquant un mirroring de la SIG et du
> Media. Ça doit pouvoir s'envisager avec une communauté "well known", tout
> comme l'annonce des coûts d'acheminement pour avoir un LCR dynamique.
>
>
> Le seul morceau que je ne visualise pas bien, c'est la localité de
>
> signifiance d'une extension. Ça devrait pouvoir se déclarer avec des
> route-maps de traduction, mais je n'en suis pas certain.
>
>
> Ensuite on encapsule la SIG en SIP et/ou XMPP, et ça devrait rouler…
>
> Non ?
>
> --
> 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/
>
>
>
> ---
> 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] [ALERT] Problème interco orange

2018-05-15 Par sujet Alain Bieuzent

Pareil, mes SDA quasi sont injoignable depuis les opérateurs tiers à ORANGE 

Le 15/05/2018 10:07, « Olivier Lange »  a écrit :

Impacté aussi, ca fait 2 fois que je tente de joindre un 04 depuis mon
portable Bouygue... Super!

Le 15 mai 2018 à 09:40, David Ponzone  a écrit :

> A priori rien chez nous pour le moment.
> Mais possible que les clients comprennent que le problème n’est pas
> terminé et n’appellent pas
>
> Bon, qui met un petit ENUM en place vite fait, pour qu’on ait les appels
> entre nous au moins ? :)
>
>
> On 15 mai 2018 09:37 +0200, Mickael Hubert , wrote:
> > Bonjour à tous,
> >
> >
> > Et ça continue ;)
> > Ce matin 8h30 parfait, mais nous étions en période creuse.
> > 9h - 9h30 de nouveau impacté.
> >
> > Pouvez-vous nous donner une vision de votre coté svp ?
> >
> > merci d'avance
> >
> > Le 14 mai 2018 à 22:44, Julien OHAYON  a écrit :
> >
> > > C’est pour ça qu’on a aussi inventé les DNS.
> > > On est archaïque :)
> > >
> > > Une adresse mail pour appeler serait tellement mieux :)
> > >
> > > Julien OHAYON
> > > Directeur Technique
> > > APPLIWAVE
> > >
> > > Tel : 09.71.18.71.11
> > >
> > > > Le 14 mai 2018 à 22:39, David Ponzone  a
> écrit
> > > :
> > > >
> > > > Hmm s’il n’a jamais été possible de changer d’ISP en gardant son
> IPv4,
> > > il y avait peut être une raison ? :)
> > > > Quelqu’un a une idée du nombre de numéros e164 portés ( les /32 de 
la
> > > téléphonie), donc désagrégés, rien qu’en France ?
> > > >
> > > > David Ponzone
> > > >
> > > >
> > > >
> > > > > Le 14 mai 2018 à 18:48, Jérôme Nicolle  a écrit :
> > > > >
> > > > > Xavier,
> > > > >
> > > > > > Le 14/05/2018 à 18:34, Xavier ROCA a écrit :
> > > > > > Amis Opérateurs alternatifs faut vraiment faire évoluer
> l'interco VoIP
> > > dans ce pays et se bouger de faire une norme type BGP Voix car cela
> devient
> > > un peu trop Merd à notre gout.
> > > > >
> > > > > Presque facile, il suffit d'encoder E.164 en BCD (avec padding 
pour
> > > certains préfixes), et de signer l'annonce avec un certificat délivré
> par
> > > l'attributaire de la tranche ou du numéro.
> > > > >
> > > > > La principale difficulté c'est l'interception légale, pour
> laquelle il
> > > faut un type de session particulier provoquant un mirroring de la SIG
> et du
> > > Media. Ça doit pouvoir s'envisager avec une communauté "well known",
> tout
> > > comme l'annonce des coûts d'acheminement pour avoir un LCR dynamique.
> > > > >
> > > > > Le seul morceau que je ne visualise pas bien, c'est la localité de
> > > signifiance d'une extension. Ça devrait pouvoir se déclarer avec des
> > > route-maps de traduction, mais je n'en suis pas certain.
> > > > >
> > > > > Ensuite on encapsule la SIG en SIP et/ou XMPP, et ça devrait
> rouler…
> > > > >
> > > > > Non ?
> > > > >
> > > > > --
> > > > > 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/
> > >
> > >
> > > ---
> > > 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] [ALERT] Problème interco orange

2018-05-15 Par sujet Olivier Lange

Impacté aussi, ca fait 2 fois que je tente de joindre un 04 depuis mon
portable Bouygue... Super!

Le 15 mai 2018 à 09:40, David Ponzone  a écrit :

> A priori rien chez nous pour le moment.
> Mais possible que les clients comprennent que le problème n’est pas
> terminé et n’appellent pas
>
> Bon, qui met un petit ENUM en place vite fait, pour qu’on ait les appels
> entre nous au moins ? :)
>
>
> On 15 mai 2018 09:37 +0200, Mickael Hubert , wrote:
> > Bonjour à tous,
> >
> >
> > Et ça continue ;)
> > Ce matin 8h30 parfait, mais nous étions en période creuse.
> > 9h - 9h30 de nouveau impacté.
> >
> > Pouvez-vous nous donner une vision de votre coté svp ?
> >
> > merci d'avance
> >
> > Le 14 mai 2018 à 22:44, Julien OHAYON  a écrit :
> >
> > > C’est pour ça qu’on a aussi inventé les DNS.
> > > On est archaïque :)
> > >
> > > Une adresse mail pour appeler serait tellement mieux :)
> > >
> > > Julien OHAYON
> > > Directeur Technique
> > > APPLIWAVE
> > >
> > > Tel : 09.71.18.71.11
> > >
> > > > Le 14 mai 2018 à 22:39, David Ponzone  a
> écrit
> > > :
> > > >
> > > > Hmm s’il n’a jamais été possible de changer d’ISP en gardant son
> IPv4,
> > > il y avait peut être une raison ? :)
> > > > Quelqu’un a une idée du nombre de numéros e164 portés ( les /32 de la
> > > téléphonie), donc désagrégés, rien qu’en France ?
> > > >
> > > > David Ponzone
> > > >
> > > >
> > > >
> > > > > Le 14 mai 2018 à 18:48, Jérôme Nicolle  a écrit :
> > > > >
> > > > > Xavier,
> > > > >
> > > > > > Le 14/05/2018 à 18:34, Xavier ROCA a écrit :
> > > > > > Amis Opérateurs alternatifs faut vraiment faire évoluer
> l'interco VoIP
> > > dans ce pays et se bouger de faire une norme type BGP Voix car cela
> devient
> > > un peu trop Merd à notre gout.
> > > > >
> > > > > Presque facile, il suffit d'encoder E.164 en BCD (avec padding pour
> > > certains préfixes), et de signer l'annonce avec un certificat délivré
> par
> > > l'attributaire de la tranche ou du numéro.
> > > > >
> > > > > La principale difficulté c'est l'interception légale, pour
> laquelle il
> > > faut un type de session particulier provoquant un mirroring de la SIG
> et du
> > > Media. Ça doit pouvoir s'envisager avec une communauté "well known",
> tout
> > > comme l'annonce des coûts d'acheminement pour avoir un LCR dynamique.
> > > > >
> > > > > Le seul morceau que je ne visualise pas bien, c'est la localité de
> > > signifiance d'une extension. Ça devrait pouvoir se déclarer avec des
> > > route-maps de traduction, mais je n'en suis pas certain.
> > > > >
> > > > > Ensuite on encapsule la SIG en SIP et/ou XMPP, et ça devrait
> rouler…
> > > > >
> > > > > Non ?
> > > > >
> > > > > --
> > > > > 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/
> > >
> > >
> > > ---
> > > 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] [ALERT] Problème interco orange

2018-05-15 Par sujet David Ponzone

A priori rien chez nous pour le moment.
Mais possible que les clients comprennent que le problème n’est pas terminé et 
n’appellent pas

Bon, qui met un petit ENUM en place vite fait, pour qu’on ait les appels entre 
nous au moins ? :)


On 15 mai 2018 09:37 +0200, Mickael Hubert , wrote:
> Bonjour à tous,
>
>
> Et ça continue ;)
> Ce matin 8h30 parfait, mais nous étions en période creuse.
> 9h - 9h30 de nouveau impacté.
>
> Pouvez-vous nous donner une vision de votre coté svp ?
>
> merci d'avance
>
> Le 14 mai 2018 à 22:44, Julien OHAYON  a écrit :
>
> > C’est pour ça qu’on a aussi inventé les DNS.
> > On est archaïque :)
> >
> > Une adresse mail pour appeler serait tellement mieux :)
> >
> > Julien OHAYON
> > Directeur Technique
> > APPLIWAVE
> >
> > Tel : 09.71.18.71.11
> >
> > > Le 14 mai 2018 à 22:39, David Ponzone  a écrit
> > :
> > >
> > > Hmm s’il n’a jamais été possible de changer d’ISP en gardant son IPv4,
> > il y avait peut être une raison ? :)
> > > Quelqu’un a une idée du nombre de numéros e164 portés ( les /32 de la
> > téléphonie), donc désagrégés, rien qu’en France ?
> > >
> > > David Ponzone
> > >
> > >
> > >
> > > > Le 14 mai 2018 à 18:48, Jérôme Nicolle  a écrit :
> > > >
> > > > Xavier,
> > > >
> > > > > Le 14/05/2018 à 18:34, Xavier ROCA a écrit :
> > > > > Amis Opérateurs alternatifs faut vraiment faire évoluer l'interco VoIP
> > dans ce pays et se bouger de faire une norme type BGP Voix car cela devient
> > un peu trop Merd à notre gout.
> > > >
> > > > Presque facile, il suffit d'encoder E.164 en BCD (avec padding pour
> > certains préfixes), et de signer l'annonce avec un certificat délivré par
> > l'attributaire de la tranche ou du numéro.
> > > >
> > > > La principale difficulté c'est l'interception légale, pour laquelle il
> > faut un type de session particulier provoquant un mirroring de la SIG et du
> > Media. Ça doit pouvoir s'envisager avec une communauté "well known", tout
> > comme l'annonce des coûts d'acheminement pour avoir un LCR dynamique.
> > > >
> > > > Le seul morceau que je ne visualise pas bien, c'est la localité de
> > signifiance d'une extension. Ça devrait pouvoir se déclarer avec des
> > route-maps de traduction, mais je n'en suis pas certain.
> > > >
> > > > Ensuite on encapsule la SIG en SIP et/ou XMPP, et ça devrait rouler…
> > > >
> > > > Non ?
> > > >
> > > > --
> > > > 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/
> >
> >
> > ---
> > 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] [ALERT] Problème interco orange

2018-05-15 Par sujet Alexis Lameire

pareil chez nous,

Pas de bol !

Le 15 mai 2018 à 09:44, BASSAGET Cédric  a
écrit :

> A première vue pas d'impact ici
>
> Le 15 mai 2018 à 09:37, Mickael Hubert  a écrit :
>
> > Bonjour à tous,
> >
> >
> > Et ça continue ;)
> > Ce matin 8h30 parfait, mais nous étions en période creuse.
> > 9h - 9h30 de nouveau impacté.
> >
> > Pouvez-vous nous donner une vision de votre coté svp ?
> >
> > merci d'avance
> >
> > Le 14 mai 2018 à 22:44, Julien OHAYON  a écrit :
> >
> > > C’est pour ça qu’on a aussi inventé les DNS.
> > > On est archaïque :)
> > >
> > > Une adresse mail pour appeler serait tellement mieux :)
> > >
> > > Julien OHAYON
> > > Directeur Technique
> > > APPLIWAVE
> > >
> > > Tel : 09.71.18.71.11
> > >
> > > > Le 14 mai 2018 à 22:39, David Ponzone  a
> > écrit
> > > :
> > > >
> > > > Hmm s’il n’a jamais été possible de changer d’ISP en gardant son
> IPv4,
> > > il y avait peut être une raison ? :)
> > > > Quelqu’un a une idée du nombre de numéros e164 portés ( les /32 de la
> > > téléphonie), donc désagrégés, rien qu’en France ?
> > > >
> > > > David Ponzone
> > > >
> > > >
> > > >
> > > >> Le 14 mai 2018 à 18:48, Jérôme Nicolle  a écrit :
> > > >>
> > > >> Xavier,
> > > >>
> > > >>> Le 14/05/2018 à 18:34, Xavier ROCA a écrit :
> > > >>> Amis Opérateurs alternatifs faut vraiment faire évoluer l'interco
> > VoIP
> > > dans ce pays et se bouger de faire une norme type BGP Voix car cela
> > devient
> > > un peu trop Merd à notre gout.
> > > >>
> > > >> Presque facile, il suffit d'encoder E.164 en BCD (avec padding pour
> > > certains préfixes), et de signer l'annonce avec un certificat délivré
> par
> > > l'attributaire de la tranche ou du numéro.
> > > >>
> > > >> La principale difficulté c'est l'interception légale, pour laquelle
> il
> > > faut un type de session particulier provoquant un mirroring de la SIG
> et
> > du
> > > Media. Ça doit pouvoir s'envisager avec une communauté "well known",
> tout
> > > comme l'annonce des coûts d'acheminement pour avoir un LCR dynamique.
> > > >>
> > > >> Le seul morceau que je ne visualise pas bien, c'est la localité de
> > > signifiance d'une extension. Ça devrait pouvoir se déclarer avec des
> > > route-maps de traduction, mais je n'en suis pas certain.
> > > >>
> > > >> Ensuite on encapsule la SIG en SIP et/ou XMPP, et ça devrait rouler…
> > > >>
> > > >> Non ?
> > > >>
> > > >> --
> > > >> 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/
> > >
> > >
> > > ---
> > > 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] [ALERT] Problème interco orange

2018-05-15 Par sujet BASSAGET Cédric

A première vue pas d'impact ici

Le 15 mai 2018 à 09:37, Mickael Hubert  a écrit :

> Bonjour à tous,
>
>
> Et ça continue ;)
> Ce matin 8h30 parfait, mais nous étions en période creuse.
> 9h - 9h30 de nouveau impacté.
>
> Pouvez-vous nous donner une vision de votre coté svp ?
>
> merci d'avance
>
> Le 14 mai 2018 à 22:44, Julien OHAYON  a écrit :
>
> > C’est pour ça qu’on a aussi inventé les DNS.
> > On est archaïque :)
> >
> > Une adresse mail pour appeler serait tellement mieux :)
> >
> > Julien OHAYON
> > Directeur Technique
> > APPLIWAVE
> >
> > Tel : 09.71.18.71.11
> >
> > > Le 14 mai 2018 à 22:39, David Ponzone  a
> écrit
> > :
> > >
> > > Hmm s’il n’a jamais été possible de changer d’ISP en gardant son IPv4,
> > il y avait peut être une raison ? :)
> > > Quelqu’un a une idée du nombre de numéros e164 portés ( les /32 de la
> > téléphonie), donc désagrégés, rien qu’en France ?
> > >
> > > David Ponzone
> > >
> > >
> > >
> > >> Le 14 mai 2018 à 18:48, Jérôme Nicolle  a écrit :
> > >>
> > >> Xavier,
> > >>
> > >>> Le 14/05/2018 à 18:34, Xavier ROCA a écrit :
> > >>> Amis Opérateurs alternatifs faut vraiment faire évoluer l'interco
> VoIP
> > dans ce pays et se bouger de faire une norme type BGP Voix car cela
> devient
> > un peu trop Merd à notre gout.
> > >>
> > >> Presque facile, il suffit d'encoder E.164 en BCD (avec padding pour
> > certains préfixes), et de signer l'annonce avec un certificat délivré par
> > l'attributaire de la tranche ou du numéro.
> > >>
> > >> La principale difficulté c'est l'interception légale, pour laquelle il
> > faut un type de session particulier provoquant un mirroring de la SIG et
> du
> > Media. Ça doit pouvoir s'envisager avec une communauté "well known", tout
> > comme l'annonce des coûts d'acheminement pour avoir un LCR dynamique.
> > >>
> > >> Le seul morceau que je ne visualise pas bien, c'est la localité de
> > signifiance d'une extension. Ça devrait pouvoir se déclarer avec des
> > route-maps de traduction, mais je n'en suis pas certain.
> > >>
> > >> Ensuite on encapsule la SIG en SIP et/ou XMPP, et ça devrait rouler…
> > >>
> > >> Non ?
> > >>
> > >> --
> > >> 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/
> >
> >
> > ---
> > 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] [ALERT] Problème interco orange

2018-05-15 Par sujet Alain Bieuzent

Je viens de recevoir une plainte client, j'attends plus d'info pour te confirmer

Le 15/05/2018 09:37, « Mickael Hubert »  a écrit :

Bonjour à tous,


Et ça continue ;)
Ce matin 8h30 parfait, mais nous étions en période creuse.
9h - 9h30 de nouveau impacté.

Pouvez-vous nous donner une vision de votre coté svp ?

merci d'avance

Le 14 mai 2018 à 22:44, Julien OHAYON  a écrit :

> C’est pour ça qu’on a aussi inventé les DNS.
> On est archaïque :)
>
> Une adresse mail pour appeler serait tellement mieux :)
>
> Julien OHAYON
> Directeur Technique
> APPLIWAVE
>
> Tel : 09.71.18.71.11
>
> > Le 14 mai 2018 à 22:39, David Ponzone  a écrit
> :
> >
> > Hmm s’il n’a jamais été possible de changer d’ISP en gardant son IPv4,
> il y avait peut être une raison ? :)
> > Quelqu’un a une idée du nombre de numéros e164 portés ( les /32 de la
> téléphonie), donc désagrégés, rien qu’en France ?
> >
> > David Ponzone
> >
> >
> >
> >> Le 14 mai 2018 à 18:48, Jérôme Nicolle  a écrit :
> >>
> >> Xavier,
> >>
> >>> Le 14/05/2018 à 18:34, Xavier ROCA a écrit :
> >>> Amis Opérateurs alternatifs faut vraiment faire évoluer l'interco VoIP
> dans ce pays et se bouger de faire une norme type BGP Voix car cela 
devient
> un peu trop Merd à notre gout.
> >>
> >> Presque facile, il suffit d'encoder E.164 en BCD (avec padding pour
> certains préfixes), et de signer l'annonce avec un certificat délivré par
> l'attributaire de la tranche ou du numéro.
> >>
> >> La principale difficulté c'est l'interception légale, pour laquelle il
> faut un type de session particulier provoquant un mirroring de la SIG et 
du
> Media. Ça doit pouvoir s'envisager avec une communauté "well known", tout
> comme l'annonce des coûts d'acheminement pour avoir un LCR dynamique.
> >>
> >> Le seul morceau que je ne visualise pas bien, c'est la localité de
> signifiance d'une extension. Ça devrait pouvoir se déclarer avec des
> route-maps de traduction, mais je n'en suis pas certain.
> >>
> >> Ensuite on encapsule la SIG en SIP et/ou XMPP, et ça devrait rouler…
> >>
> >> Non ?
> >>
> >> --
> >> 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/
>
>
> ---
> 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] [ALERT] Problème interco orange

2018-05-15 Par sujet Mickael Hubert

Bonjour à tous,


Et ça continue ;)
Ce matin 8h30 parfait, mais nous étions en période creuse.
9h - 9h30 de nouveau impacté.

Pouvez-vous nous donner une vision de votre coté svp ?

merci d'avance

Le 14 mai 2018 à 22:44, Julien OHAYON  a écrit :

> C’est pour ça qu’on a aussi inventé les DNS.
> On est archaïque :)
>
> Une adresse mail pour appeler serait tellement mieux :)
>
> Julien OHAYON
> Directeur Technique
> APPLIWAVE
>
> Tel : 09.71.18.71.11
>
> > Le 14 mai 2018 à 22:39, David Ponzone  a écrit
> :
> >
> > Hmm s’il n’a jamais été possible de changer d’ISP en gardant son IPv4,
> il y avait peut être une raison ? :)
> > Quelqu’un a une idée du nombre de numéros e164 portés ( les /32 de la
> téléphonie), donc désagrégés, rien qu’en France ?
> >
> > David Ponzone
> >
> >
> >
> >> Le 14 mai 2018 à 18:48, Jérôme Nicolle  a écrit :
> >>
> >> Xavier,
> >>
> >>> Le 14/05/2018 à 18:34, Xavier ROCA a écrit :
> >>> Amis Opérateurs alternatifs faut vraiment faire évoluer l'interco VoIP
> dans ce pays et se bouger de faire une norme type BGP Voix car cela devient
> un peu trop Merd à notre gout.
> >>
> >> Presque facile, il suffit d'encoder E.164 en BCD (avec padding pour
> certains préfixes), et de signer l'annonce avec un certificat délivré par
> l'attributaire de la tranche ou du numéro.
> >>
> >> La principale difficulté c'est l'interception légale, pour laquelle il
> faut un type de session particulier provoquant un mirroring de la SIG et du
> Media. Ça doit pouvoir s'envisager avec une communauté "well known", tout
> comme l'annonce des coûts d'acheminement pour avoir un LCR dynamique.
> >>
> >> Le seul morceau que je ne visualise pas bien, c'est la localité de
> signifiance d'une extension. Ça devrait pouvoir se déclarer avec des
> route-maps de traduction, mais je n'en suis pas certain.
> >>
> >> Ensuite on encapsule la SIG en SIP et/ou XMPP, et ça devrait rouler…
> >>
> >> Non ?
> >>
> >> --
> >> 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/
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] [JOBS] Poste Leader technique backbone - Toulouse

2018-05-15 Par sujet Luc DUBOIS

Bonjour à tous,

Je suis responsable d'étude télécoms chez Infomil à Toulouse et je
recherche un leader technique backbone opérateur pour se positionner comme
référent auprès de mon équipe actuelle.

Infomil est la filiale Informatique du mouvement E.Leclerc et est également
opérateur télécom. Depuis 2012, nous avons mis en service notre propre
backbone national qui nous permet de déployer des solutions télécoms Haut
débit (fibre optique, FH...) pour l'ensemble des entités E.Leclerc.

Je recherche une personne experte dans ce domaine pour faire des études sur
les évolutions des infrastructures backbone, le référencement technique et
l'expertise WAN/MPLS.
Bref, un poste qui vous permettrait d'être au cœur de l'expertise technique
et d'évoluer sur des projets d'ampleur nationale.

Pour plus de détails, n'hésitez pas à consulter l'annonce en ligne ou me
contacter.
http://www.infomil.com/offres-emplois-stages.html


Luc DUBOIS

---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] [ALERT] Problème interco orange

2018-05-15 Par sujet Alain Bieuzent

Bonjour la liste,

Est-ce que l'un d'entre vous a reçu une communication "officielle" de la part 
de l'agrume ?

Merci

Le 14/05/2018 18:35, « Xavier ROCA »  a écrit :

Selon deux médias (je sais pas qui cite qui déjà...), 
Le parisien et ZDNet Orange a reconnu sa responsabilité mais rien pour 
citer la source de l'info ou la communication officiel 

Amis Opérateurs alternatifs faut vraiment faire évoluer l'interco VoIP dans 
ce pays et se bouger de faire une norme type BGP Voix car cela devient un peu 
trop Merd à notre gout.

Amis de l'ARCEP, il serait temps d'envisager clairement une interco directe 
entre opérateur ou déjà de donner la possibilité d'un secours via un second 
intermédiaire pour les appels entrants.

Je penses que l'on est pas passé loin de la catastrophe.
Ils seraient temps de voir que l'on a eu une belle alarme aujourd'hui, si 
c'est fini !
Car il y a juste une baisse notable du trafic en cette soirée mais c'est 
tout.
Est-ce qu'en charge demain sera meilleur qu'aujourd'hui...



-Message d'origine-
De : Steeve BEAUVAIS - Société Serinya Telecom 
 
Envoyé : lundi 14 mai 2018 17:33
À : Jeremy SPIESSER 
Cc : frnog@frnog.org
Objet : Re: [FRnOG] [ALERT] Problème interco orange

Je n'ai plus de remontés clientes de mon côté et mon taux d'aboutissement 
des appels est revenu à la normale.

J'attends une com de mon transitaire SIP.

Cordialement,

[image:

http://www.serinyatelecom.fr/signatures/signature-steeve-beauvais-serinya-telecom.jpg]




Le 14 mai 2018 à 16:49, Jeremy SPIESSER  a écrit :

> C'est à Orange de communiquer tout du moins à ses clients opérateurs 
> qu'il puisse savoir à minima et répondre a leurs clients ..
>
> Des améliorations?  la SIG a l'air de mieux passer mais il y a pas 
> d’audio sur la plupart des appels..
>
>
> Le 14/05/2018 à 16:36, Guillaume LAPOUGE a écrit :
> > Un mieux en début d'aprés midi mais ca remerde depuis 16h00
> >
> > 
> > De : frnog-requ...@frnog.org  de la part de
> Francois Prems 
> > Envoyé : lundi 14 mai 2018 16:35:04
> > À : frnog@FRnOG.org
> > Objet : Re: [FRnOG] [ALERT] Problème interco orange
> >
> > Je reste très surpris de l'absence totale de communication des gros 
> > opérateurs sur un incident de cette ampleur qui touche tout le 
> > monde, et manifestement sur tous les services...
> >
> > Certains d'entre vous constatent-ils une amélioration ?
> >
> > ---
> > 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/




---
Liste de diffusion du FRnOG
http://www.frnog.org/

53 matches

Mail list logo