[FRnOG] [TECH] VOIP MAN Stir and Shaken avec prefixe de portabilité

[Mickael Hubert]

Bonjour à tous,
je me permets de vous écrire afin de vous faire part d'une "petite
subtilité" qui peut nous prendre la tête lors de l'implémentation du MAN.
J'ai réalisé une mise en prod du MAN avec un de nos transitaires (sur 25%
de notre trafic) et celui-ci nous livre des appels préfixés de notre
préfixe de portabilité (Ex: +33*10999*123456789).
Je précise que ce transitaire réalise la collecte sur nos tranches et de la
portabilité en notre nom.

Le problème étant qu'il signe l'appel avec le numéro préfixé.
Ex d'un appel porté et livré sur notre interco:
RURI: +3310999123456789
TO: +3310999123456789
Dans le JWT de l'Identity header, le dest est aussi sous la forme
3310999123456789.
"dest": { "tn": [ "3310999123456789" ] },

Cela pose un problème dans notre module stir and shaken (nous utilisons
OpenSIPS), car le format ne respecte pas E164 (> 15 digits).

Après avoir envoyé une bouteille à la mer sur la mailing list OpenSIPS j'ai
pu obtenir quelques réponses m'expliquant que ce transitaire doit respecter
la norme E164 comme indiqué dans les doc du MAN.
A contrario, ce transitaire m'explique qu'il a le droit de signer avec le
préfixe.

Souhaitant en avoir le cœur net, je contacte l'APNF qui me précise qu'en
effet ce transitaire à raison, il peut signer avec le préfixe donc sans
respecter le format E164.
De plus, une personne travaillant chez ce transitaire a eu la gentillesse
de me transmettre le projet de modification de la documentation MAN qui est
très clair.

Image ci-dessous:
[image: unnamed.png]

Donc, oui, en France un provider peut signer avec un préfixe de portabilité
sans respecter E164 (est-ce peut-être juste temporaire...)
Je tenais à diffuser l'info, ça peut toujours aider.
Pour ma part, rien de compliqué j'ai patché le module stir and shaken
d'OpenSIPS, mais j'imagine que ça ne sera malheureusement pas simple pour
tout le monde.

Très bonne journée

Re: [FRnOG] [TECH] VOIP MAN Stir/Shaken

[Mickael Hubert]

Bonjour à tous,
Vu qu'on c'est bientôt les vacances et qu'on ne coupera pas les appels de
suite, voici ma PR concernant les tests de vérification stir and shaken,
ces tests suivent le doc
MAN_Mode_operatoire_Mecanisme_de_Confiance_v1.7_20230616.pdf (page
59)
Ils utilisent SIPssert (l'outil de test unitaire développé par OpenSIPS, et
bien entendu OpenSIPS lui-même).
Comme je l'avais déjà expliqué, il y a pas mal de changements à réaliser
pour se rendre compliant avec le MAN, mais cette configuration (
stir_shaken_verify.cfg) devrait couvrir 80% des reco du MAN.

lien vers la PR: https://github.com/OpenSIPS/sipssert-opensips-tests/pull/5
lien de la branche du repo source:
https://github.com/Mickaelh51/sipssert-opensips-tests/tree/stir_and_shaken_verify
pour chaque scénario, vous avez une petite doc:
Ex:
-
https://github.com/Mickaelh51/sipssert-opensips-tests/blob/stir_and_shaken_verify/stir-shaken/11.verify-error-436-no-info/README.md
-
https://github.com/Mickaelh51/sipssert-opensips-tests/blob/stir_and_shaken_verify/stir-shaken/07.verify-error-400-wrong-from-no-kill-call/README.md
Celle-ci vous indiquera aussi de quelle ligne du tableau des erreur sip il
s'agit:
*Test
from MAN_Mode_operatoire_Mecanisme_de_Confiance_v1.7_20230616.pdf (P59 /
line 5)*
j'utilise toujours la même configuration qui se trouve ici:
https://github.com/Mickaelh51/sipssert-opensips-tests/blob/stir_and_shaken_verify/stir-shaken/04.verify-200/stir_shaken_verify.cfg

Pour ceux qui utilisent ou voudraient utiliser OpenSIPS, n'hésitez pas à
participer, pour le moment il y a 26 tests:
01.auth-simple
02.auth-diverted-cached
03.auth-issue-bypass-token
04.verify-200
05.verify-200-anonymous
06.verify-error-400-wrong-from
07.verify-error-400-wrong-from-no-kill-call
08.verify-error-403-wrong-date
09.verify-error-403-wrong-iat
10.verify-error-428-no-identity
11.verify-error-436-no-info
12.verify-error-436-token-no-4-params
13.verify-error-436-x5u-diff-info
14.verify-error-437-no-alg
15.verify-error-437-wrong-alg
16.verify-error-437-wrong-header-alg
17.verify-error-437-wrong-header-typ
18.verify-error-437-cert-expired
19.verify-error-437-cert-in-future
20.verify-error-438-identity-more-4-params
21.verify-error-438-no-ppt
22.verify-error-438-wrong-ppt
23.verify-error-438-wrong-header-ppt
24.verify-error-438-wrong-attest
25.verify-error-438-orig-diff-from
26.verify-error-438-dest-diff-to

Pour utiliser SIPssert <https://github.com/OpenSIPS/SIPssert> ce n'est pas
bien compliqué
Ex:
sipssert /myhome/sipssert-opensips-tests/stir-shaken
-t 26.verify-error-438-dest-diff-to

ça vous monte l'ensemble des conteneurs (car oui c'est 100% conteneurs), ça
utilise sipp en uac et uas
Après le test, vous avez un répertoire logs avec... vos les logs et une
capture pcap
moi# ls logs/latest/stir-shaken/26.verify-error-438-dest-diff-to
capture.pcap   OpenSIPS.log   OpenSIPS.status  'SIPP UAC.log'  'SIPP
UAC.status'

Pour lire la capture rapido:
sngrep -I
logs/latest/stir-shaken/26.verify-error-438-dest-diff-to/capture.pcap

Bonnes vacances !

++


Le mer. 28 juin 2023 à 11:43, Greg  a écrit :

> Opensips c'est un super outil, nous avons créé le module call center
> https://opensips.org/html/docs/modules/2.2.x/call_center.html ça date un
> peu ce bon vieux temps.
> En tout cas super travail pour opensips félicitations.
> Je me pose la question en ce moment comment mieux générer les appels avec
> les défauts.
> Par ex absence de TN, ou lien vers signature invalide etc, avez vous une
> idée ?
> Nous avons bien implémenté l'ensemble des vérifications d'identity mais
> pour tester l'ensemble des cas sans le trafic réel c'est pas si simple.
>
>
>
>
> вт, 27 июн. 2023 г. в 21:06, Mickael Hubert :
>
>> Pardon, ma PR officielle est ici:
>> https://github.com/OpenSIPS/sipssert-opensips-tests/pull/2
>>
>> Tu as le projet sipssert en lui-même, ou j'ai aussi poussé un PR pour la
>> partie vérification.
>> Et tu as le projet avec les scénarios de bases réalisés par opensips
>> sipssert-opensips-testsw avec ma PR qui ajoute les scénarios pour
>> l'authentification et d'ici peu les scénarios pour la vérification comme
>> expliqué dans mon précédent email.
>>
>> Bonne soirée
>>
>> Le mar. 27 juin 2023 à 21:01, Mickael Hubert  a
>> écrit :
>>
>>> Bonjour
>>> Nous utilisons opensips pour réaliser le MAN.
>>> Ça fonctionne parfaitement (en staging).
>>> Pour info je pousse en opensource le travail que nous réalisons ici:
>>> https://github.com/Mickaelh51/SIPssert/tree/add-sipp-stir-and-shaken
>>>
>>> Sipssert c'est le framework de tests unitaires développé par opensips.
>>>
>>> Pour le moment je n'ai poussé que la partie authentification (ajout du
>>> header), car la partie vérification (check du header) est vraiment
>>> différente de la version

Re: [FRnOG] [TECH] VOIP MAN Stir/Shaken

[Mickael Hubert]

Pardon, ma PR officielle est ici:
https://github.com/OpenSIPS/sipssert-opensips-tests/pull/2

Tu as le projet sipssert en lui-même, ou j'ai aussi poussé un PR pour la
partie vérification.
Et tu as le projet avec les scénarios de bases réalisés par opensips
sipssert-opensips-testsw avec ma PR qui ajoute les scénarios pour
l'authentification et d'ici peu les scénarios pour la vérification comme
expliqué dans mon précédent email.

Bonne soirée

Le mar. 27 juin 2023 à 21:01, Mickael Hubert  a écrit :

> Bonjour
> Nous utilisons opensips pour réaliser le MAN.
> Ça fonctionne parfaitement (en staging).
> Pour info je pousse en opensource le travail que nous réalisons ici:
> https://github.com/Mickaelh51/SIPssert/tree/add-sipp-stir-and-shaken
>
> Sipssert c'est le framework de tests unitaires développé par opensips.
>
> Pour le moment je n'ai poussé que la partie authentification (ajout du
> header), car la partie vérification (check du header) est vraiment
> différente de la version US. Et oui, les codes retours ne sont pas les
> mêmes ;)
>
> Déjà dans auth, mon scénario va demander à opensips de générer l'identity,
> et un script python avec pyjwt va check si ce que génère opensips est
> cohérent.
>
> Mais d'ici fin de semaine pro je devrais avoir poussé l'ensemble de mes
> scénarios de tests (auth + verify).
> En gros ça reprend le tableau du MAN sur quand on doit balancer un 4xx,
> etc... Et je simule ça dans des scénarios puis le framework teste si tout
> est OK.
>
> Tu peux utiliser opensips pour qu'il te balance l'identity dans un 302 de
> mémoire (pas testé).
>
> Si tu souhaites plus d'info, avec plaisir.
>
> Bonne soirée
>
>
> Le mar. 27 juin 2023 à 17:24, Greg  a écrit :
>
>> Oui je confirme et je ne peux que donner une recommandation pour
>> telcobridges.
>>
>> вт, 27 июн. 2023 г. в 17:06, David Ponzone :
>>
>> > Ouais c’est ça, c’est une solution basée sur ProSBC et ClearIP de
>> > Tansnexus, et ClearIP utilise SIP pour prévenir le SBC de ce qu’il faut
>> > faire: 302 Divert avec Identity/503 Allow/603 Block.
>> > C’est pas non plus ce que je préfère comme architecture, mais c’est pas
>> > complètement con.
>> >
>> > En tout cas, les gens de TelcoBridges que j’avais rencontrés sont super
>> > sympas et accessibles donc tant qu’à filer des thunes pour une solution
>> > commerciale, autant que ça soit eux.
>> >
>> >
>> > > Le 27 juin 2023 à 11:23, Greg  a écrit :
>> > >
>> > > Bonjour, nous avons réalisé notre projet en mode WebService API avec
>> le
>> > > SBC, le SBC nous communique l'information pour la signature de
>> l'appel ou
>> > > Identity pour la vérification de signature, ensuite notre backbone
>> > effectue
>> > > le travail demandé et communique les résultats au SBC.
>> > > Le backbone c'est un process REST > NodeJs en docker conçu de
>> fonctionner
>> > > sans la base des données pour plus de fiabilité, du coup il est
>> possible
>> > de
>> > > multiplier les instances pour la haute disponibilité.
>> > > Il ne faut pas oublier également toute la partie backend reporting /
>> > > renouvellement, gestion des certificats, et dépose de reporting en
>> sftp.
>> > > Notre constructeur c'est Telcobridges, pour info David Ponzone
>> > Telcobridges
>> > > ont travaillé avec la signature via SIP uniquement et non via
>> > > Rest/webservice pour la zone US / CANADA, puisque nous étions déjà
>> avec
>> > > telcobridges sur la partie sip nous avons travaillé avec eu pour
>> > développer
>> > > cette partie.
>> > >
>> > >
>> > > вт, 27 июн. 2023 г. в 09:57, Arnaud Willem :
>> > >
>> > >> Salut Teddy,
>> > >>
>> > >> La partie STI-AS et -VS répond déjà à une spec type “REST”
>> > (ATIS-182,
>> > >> parmi d'autres), ton SBC peut donc intercepter le header Identity et
>> le
>> > >> passer au STI-VS pour validation, de même pour générer ton token
>> avec le
>> > >> STI-AS, c’est (comme le dit David dans son mail) le format retenu par
>> > une
>> > >> majorité de presta SaaS pour cela.
>> > >>
>> > >> Après, du STI-AS/VS libre/opensource, j’ai pas encore sourcé, à part
>> > >> `libstirshaken`, mais je suis aussi preneur de retours des uns et des
>> > >> autres.
>> > >>
>> > >> En commercial, chaque éditeur y va maintenant de son offre intégrée

Re: [FRnOG] [TECH] VOIP MAN Stir/Shaken

[Mickael Hubert]

Bonjour
Nous utilisons opensips pour réaliser le MAN.
Ça fonctionne parfaitement (en staging).
Pour info je pousse en opensource le travail que nous réalisons ici:
https://github.com/Mickaelh51/SIPssert/tree/add-sipp-stir-and-shaken

Sipssert c'est le framework de tests unitaires développé par opensips.

Pour le moment je n'ai poussé que la partie authentification (ajout du
header), car la partie vérification (check du header) est vraiment
différente de la version US. Et oui, les codes retours ne sont pas les
mêmes ;)

Déjà dans auth, mon scénario va demander à opensips de générer l'identity,
et un script python avec pyjwt va check si ce que génère opensips est
cohérent.

Mais d'ici fin de semaine pro je devrais avoir poussé l'ensemble de mes
scénarios de tests (auth + verify).
En gros ça reprend le tableau du MAN sur quand on doit balancer un 4xx,
etc... Et je simule ça dans des scénarios puis le framework teste si tout
est OK.

Tu peux utiliser opensips pour qu'il te balance l'identity dans un 302 de
mémoire (pas testé).

Si tu souhaites plus d'info, avec plaisir.

Bonne soirée


Le mar. 27 juin 2023 à 17:24, Greg  a écrit :

> Oui je confirme et je ne peux que donner une recommandation pour
> telcobridges.
>
> вт, 27 июн. 2023 г. в 17:06, David Ponzone :
>
> > Ouais c’est ça, c’est une solution basée sur ProSBC et ClearIP de
> > Tansnexus, et ClearIP utilise SIP pour prévenir le SBC de ce qu’il faut
> > faire: 302 Divert avec Identity/503 Allow/603 Block.
> > C’est pas non plus ce que je préfère comme architecture, mais c’est pas
> > complètement con.
> >
> > En tout cas, les gens de TelcoBridges que j’avais rencontrés sont super
> > sympas et accessibles donc tant qu’à filer des thunes pour une solution
> > commerciale, autant que ça soit eux.
> >
> >
> > > Le 27 juin 2023 à 11:23, Greg  a écrit :
> > >
> > > Bonjour, nous avons réalisé notre projet en mode WebService API avec le
> > > SBC, le SBC nous communique l'information pour la signature de l'appel
> ou
> > > Identity pour la vérification de signature, ensuite notre backbone
> > effectue
> > > le travail demandé et communique les résultats au SBC.
> > > Le backbone c'est un process REST > NodeJs en docker conçu de
> fonctionner
> > > sans la base des données pour plus de fiabilité, du coup il est
> possible
> > de
> > > multiplier les instances pour la haute disponibilité.
> > > Il ne faut pas oublier également toute la partie backend reporting /
> > > renouvellement, gestion des certificats, et dépose de reporting en
> sftp.
> > > Notre constructeur c'est Telcobridges, pour info David Ponzone
> > Telcobridges
> > > ont travaillé avec la signature via SIP uniquement et non via
> > > Rest/webservice pour la zone US / CANADA, puisque nous étions déjà avec
> > > telcobridges sur la partie sip nous avons travaillé avec eu pour
> > développer
> > > cette partie.
> > >
> > >
> > > вт, 27 июн. 2023 г. в 09:57, Arnaud Willem :
> > >
> > >> Salut Teddy,
> > >>
> > >> La partie STI-AS et -VS répond déjà à une spec type “REST”
> > (ATIS-182,
> > >> parmi d'autres), ton SBC peut donc intercepter le header Identity et
> le
> > >> passer au STI-VS pour validation, de même pour générer ton token avec
> le
> > >> STI-AS, c’est (comme le dit David dans son mail) le format retenu par
> > une
> > >> majorité de presta SaaS pour cela.
> > >>
> > >> Après, du STI-AS/VS libre/opensource, j’ai pas encore sourcé, à part
> > >> `libstirshaken`, mais je suis aussi preneur de retours des uns et des
> > >> autres.
> > >>
> > >> En commercial, chaque éditeur y va maintenant de son offre intégrée /
> > son
> > >> partenariat avec un SaaS, ou encore de son offre OPTV et OPTS pour les
> > >> opérateurs de transit voix.
> > >>
> > >> My two cents,
> > >>
> > >> Arnaud
> > >>
> > >>
> > >>> On 27 Jun 2023, at 09:25, Teddy DOURE  wrote:
> > >>>
> > >>> Hello,
> > >>>
> > >>> Le sujet MAN est devenu un sujet assez prioritaire.
> > >>> On prend le train un peu en marche et on se pose quelques questions.
> > >>> Entre les différentes solutions commerciales et la volonté
> > >> d'internaliser ce processus en interne.
> > >>>
> > >>> Le MAN consistant à intégrer dans la trame SIP un header avec une
> > >> signature en tant qu'appelant et à vérifier cette signature en tant
> que
> > >> destinataire.
> > >>> Je me pose donc la question suivante :
> > >>>
> > >>> Serait-t-il viable d'intégrer cela en mode webservice couplé au SBC
> > avec
> > >> un service qui tournerai localement, qui ferait les manipulations
> > >> nécessaires pour renvoyer simplement les bons headers dans la trame
> SIP
> > ?
> > >>> Nous le faisons déjà avec nos SBC pour faire tout un tas de
> > >> vérifications sur les numéros appelant, appelés et intégrer des custom
> > >> header notamment pour la facturation par exemple.
> > >>>
> > >>> Ou alors faut-il vraiment s'interconnecter avec des solutions
> > >> "certifiées" ou existe-t-il des solutions opensource ?
> > >>>
> > >>> Merci d'avance 
> > >>>
> > >>>
> 

[FRnOG] [TECH] MAN (stir and shaken) et MTU

[Mickael Hubert]

Bonjour à tous,
Comme la plupart des opérateurs, nous travaillons à mettre en place le
projet MAN (stir and shaken).
J'aimerais soulever un point ici, sur le fait que MAN va ajouter pas mal
d'info dans le paquet INVITE et on va dépasser la MTU de 1500, donc
fragmentation UDP.
Surtout que le paquet INVITE est déjà plutôt volumineux avec toutes les
préco FFT.

J'avoue que je n'arrive pas a trouver de l'info correcte ou non
contradictoire, sur comment gérer correctement ce cas de fragmentation.
Car la RFC nous dit: au-dessus de 1300, passez en TCP, et la FFT nous dit:
"restez en UDP". Enfin si, on peut passer en TCP, mais est-ce la majorité
des interco SIP d'être en TCP ?

Sur de l'interco direct ou LAN, ça va, il ne devrait pas y avoir de perte
de paquet ou même des paquets dans le désordre. Mais par Internet, c'est
peut-être un chouilla plus risqué je pense...

Qnn aurait-il des billes sur ce sujet ?

merci d'avance
++


*Extrait RFC:*

If a request is within 200 bytes of the path MTU, or if it is larger
   than 1300 bytes and the path MTU is unknown, the request MUST be sent
   using an RFC 2914 
[43 ] congestion
controlled transport protocol, such
   as TCP.


*Extrait FFT (Architecture Principes et recommandations): *

Note 1 : dans le cas d’un paquet UDP dont la taille est supérieure au
MTU, il est fortement recommandé
d’utiliser la fragmentation UDP au lieu de la bascule en TCP.

...

Note 2 : sur accord bilatéral, il est possible d’utiliser TCP à
l’interconnexion.
Note 3 : L’implémentation d’un mécanisme d’attestation et de
vérification du numéro appelant peut conduire
à une augmentation significative de la taille des paquets IP. C’est
d’autant plus critique pour les paquets
VoLTE qui sont déjà de taille conséquente.

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

[TECH] Re: [FRnOG] Discussion technique : gestion gigue serveur VOIP | [TECH] || frnog-t...@frnog.org

[Mickael Hubert]

Bonjour Christophe,
Je ne sais pas si tu as eu ta réponse depuis le temps...
Si ton flux passe par l'Internet, c'est mort, tu n'auras pas de QOS de bout
en bout, car le tag QOS sera forcément cassé par les X providers qu'il va
traverser.
Mais d'après ce que tu décris, le problème m'a l'air global à l'ensemble de
tes clients, ce qui suppose que le problème provient plus d'un goulot
d'étranglement (ta liaison WAN) et pas les X liens de tes clients.
Sais-tu si le prob est plutôt en upload ou en download ou les deux sur ton
WAN ?
Car pour l'upload, tu pourrais y faire qqch, mais en download ce n'est pas
possible, car on parle de flux RTP donc UDP.

Sinon sur de la VoIP, je fais de la QOS type CBQ, avec des queues et le
truc sympa avec cette QOS c'est que c'est dynamique.

Bonne fin de journée


Le jeu. 2 févr. 2023 à 00:35, Christophe DABADIE <
christophe.daba...@recom.fr> a écrit :

> Bonjour,
>
> Nous hébergeons des serveurs VOIP (environ 150 VM) dans un Datacenter
> (infra haute dispo sous Vmware Esx).
> Notre FAI fournit une liaison fibre 1 Gb.
>
> Nous gérons la QoS sur la VoIP sur nos firewalls au datacenter et sur le
> réseau LAN de l'infra des serveurs VoIP.
> Par contre, notre FAI ne permet pas de gérer la QoS sur leur routeur fibre
> côté WAN.
>
> Environ 1000 utilisateurs (multisites) sont reliés aux serveurs VoIP pour
> environ 400 communications SIP simultanées.
> Nous rencontrons de plus en plus de dégradations sur la qualité des
> communications VoIP (mauvaise qualité et décalage voix, blanc, etc..)
>
> Après analyse de nos équipements et investigations, nous pensons que cela
> peut être lié à la gestion de la QoS coté WAN ainsi que la gigue et la
> latence.
>
> Existe-t-il des solutions pour optimiser la gigue et la latence ?
>
> Merci pour votre retour d'expérience.
>
> Cordialement,
>
> Christophe Dabadie
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

[FRnOG] [MISC] Authentification des numéros : où en sont les Etats-Unis ? Où en est la France ?

[Mickael Hubert]

Bonjour à tous,
article très intéressant sur STIR/Shaken, US vs la France

https://eu-etc.com/fr/2022/06/20/authentification-des-numeros-ou-en-sont-les-etats-unis-ou-en-est-la-france/

Bonne journée

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

Re: [FRnOG] [TECH] Statistiques d'utilisation de la RFC1918

[Mickael Hubert]

Bonsoir,
merci pour vos retours
il y a une tipo c'est 100.64.0.0/10 et pas /8

le subnet 100.64 n'est pas compatible chez mon client, car c'est un
opérateur et qu'il utilise déjà ce subnet sur son réseau (surement pour du
CGN)

Je vais lui proposer la 198.18.0.0/15, mais j'ai bien l'impression qu'il ne
souhaite pas sortir de la RFC1918

Encore merci


Le mar. 5 avr. 2022 à 17:46, Wallace  a écrit :

> Curiosité pourquoi le 100.64 ne marche pas? Un équipement pas
> compatible? Si oui lequel?
>
> Sinon le 198.18 au cas où à essayer.
>
> Le 05/04/2022 à 17:35, Mickael Hubert a écrit :
> > Bonjour à tous,
> > je dois monter un VPN avec un client (sans NAT), mais le réseau que
> > j'utilise avec mes autres clients (RFC6598 100.64.0.0/8, pour du CGN et
> > très très peu utilisé chez les clients) n'est pas compatible chez lui...
> la
> > loose
> >
> > Je cherche donc une info sur quelles plages IP de la RFC1918 sont
> > statistiquement les moins utilisées. Dans une ancienne vie j'avais l'info
> > du 172.27.50.0/24, trouvée sur un obscure forum. Va savoir comment ces
> > stats sont faites, mais bon...
> > PS:Pas d'overlap IP possible.
> >
> > Si jamais vous avez l'info qqpart, je suis preneur.
> >
> > En vous remerciant
> > ++
> >
> > ---
> > 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] [TECH] Statistiques d'utilisation de la RFC1918

[Mickael Hubert]

Bonjour à tous,
je dois monter un VPN avec un client (sans NAT), mais le réseau que
j'utilise avec mes autres clients (RFC6598 100.64.0.0/8, pour du CGN et
très très peu utilisé chez les clients) n'est pas compatible chez lui... la
loose

Je cherche donc une info sur quelles plages IP de la RFC1918 sont
statistiquement les moins utilisées. Dans une ancienne vie j'avais l'info
du 172.27.50.0/24, trouvée sur un obscure forum. Va savoir comment ces
stats sont faites, mais bon...
PS:Pas d'overlap IP possible.

Si jamais vous avez l'info qqpart, je suis preneur.

En vous remerciant
++

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

[FRnOG] [MISC] Re: Donne baie informatique

[Mickael Hubert]

Ça a été rapide, j'ai trouvé preneur ;)
++

Le jeu. 24 juin 2021 à 15:10, Mickael Hubert  a écrit :

> Bonjour à tous,
> ma société déménage et donne une bien jolie baie info 42U, 19 pouces. Elle
> est neuve, voici les photos: https://photos.app.goo.gl/68eDdSjv9Qiut3i96
>
> A venir chercher obligatoirement avant lundi 28 midi, dans le 8ème.
> (Adresse précise fournie au premier qui ira la chercher ;) )
>
> Bonne journée
>

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

[FRnOG] [MISC] Donne baie informatique

[Mickael Hubert]

Bonjour à tous,
ma société déménage et donne une bien jolie baie info 42U, 19 pouces. Elle
est neuve, voici les photos: https://photos.app.goo.gl/68eDdSjv9Qiut3i96

A venir chercher obligatoirement avant lundi 28 midi, dans le 8ème.
(Adresse précise fournie au premier qui ira la chercher ;) )

Bonne journée

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

Re: [FRnOG] [TECH] 2FA, avec ou sans bastion ?

[Mickael Hubert]

Salut,
un grand merci à vous pour toutes vos réponses !
Cela va grandement nous aider à avancer.
++

Le mar. 13 avr. 2021 à 20:06, Vincent Bernat  a écrit :

>  ❦ 13 avril 2021 18:28 +02, Will van Gulik:
>
> > De ce que j'ai lu dans le man et en re-regardant ma conf, j'utilise le
> > forwarding-agent dans ma config, et je me connecte à un host (final) via
> > un bastion. Dans ce cas, j'ai une clef pour mon bastion, et des
> clefs/une clef pour mes
> > serveurs derrière, et je ne stocke pas de clef sur le bastion, en toute
> > logique. Dans mon fichier ssh j'utilise les paramèẗres ProxyCommand et
> > ForwardAgent .
>
> Pas besoin de ForwardAgent du coup.
> --
> Don't sacrifice clarity for small gains in "efficiency".
> - The Elements of Programming Style (Kernighan & Plauger)
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

[FRnOG] [TECH] 2FA, avec ou sans bastion ?

[Mickael Hubert]

Bonjour à tous,
Actuellement pour prendre la main sur nos serveurs (SSH), nous nous
connectons à des accès VPN, il y a X profils (Ex: admin, développeurs, etc
..) et chaque profil n'a accès qu'à ce qu'il a besoin.
Mais dans le cadre de notre compliance PCI-DSS, il nous manque 2 points à
valider, l'un d'eux est la mise en place du 2FA sur nos accès SSH
justement.
Bon le truc, c'est qu'on ouvre 1001 fenêtres quand on travaille sur un
serveur ;)
Si je dois à chaque fois taper le 2FA ça va vite devenir chiant... sans
parler du timeout d'inactivité de la session SSH.

Auriez-vous des solutions "plus user friendly" ?
J'avais imaginer mettre en place un bastion, mais bon ouvrir 1001 sessions
avec 2FA sur le bastion ou sur les serveurs en direct, ça revient au même
pour moi.
A moins qu'il existe un bastion qui te demande le 2FA à la première
connexion, puis plus après pour les autres sessions que tu pourrais ouvrir
...
Peut-être du 2FA en hard (avec une clé)...

merci d'avance pour votre aide
++

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

[FRnOG] [TECH] Sessions TCP restant ouvertes après un switch BGP

[Mickael Hubert]

Bonjour à tous,
j'ai un petit souci de sessions TCP restant actives après un switch de BGP.
Pour infos ces 2 sessions sont à l'intérieur de tunnels IPSEC VTI.
Je ne parle pas des sessions TCP du BGP en lui-même, mais de trafic TCP
classique en fait.

L'infra :
[image: network interco (VPN) + BGP (FRNOG).png]

Il y a 2 sessions BGP (1 par DC), les 2 connectées, avec une route map pour
forcer le trafic a passer par un des 2 tunnels.
Le failover BGP se fait très bien, un nouveau trafic passera correctement
par le tunnel encore UP (standy -> active).
Mais les sessions TCP déjà ouvertes entre le serveur C et les serveurs A ou
B restent actives sur le serveur C. Pourtant, le routeur VPN C voit bien
les sessions TCP comme closed.

Il faut attendre un timeout sur le serveur C pour qu'il initie de nouvelles
sessions TCP, mais c'est 8 mins de downtime  chaud pour du failover ...

Pour info le serveur C c'est un SBC Oracle qui fait du SIP TCP (pas
possible de repasser en SIP UDP, trop facile ;) )...
Le routeur VPN C c'est du Juniper.

Avez-vous déjà vu ce genre de phénomène ? J'imagine bien qu'il faut
changer  le timer TCP sur l'Oracle, mais c'est à priori chaud pour mon
client.
N'y a-t'il pas un moyen sur un Juniper de balancer du TCP/RST lors d'une
coupure de VPN ou autre palliatif ?

Merci d'avance pour votre aide !

++

Re: [FRnOG] [TECH] Retour d'expériences AWS

[Mickael Hubert]

Bonjour à tous et merci pour vos réponses, cela va bien nous aider.
Je préciserai que je suis 100% d'accord pour consommer Français, mais comme
dirait un "autre" copain à moi (qui se reconnaîtra):
"Une entreprise n'est pas une démocratie et tu fais ce qu'on te demande" ;)

++

Le mar. 24 nov. 2020 à 09:50, Wallace  a écrit :

>
> Le 23/11/2020 à 23:31, Raphael Mazelier a écrit :
> >
> > Par exemple : LB , pas de problème il s'agit de reverse proxy https
> > classiques, RDS(aws) pour Mysql/Postgres, pas trop de problème puisque
> > c'est standard et que tu peux re-migrer tes datas sur du Mysql/Maria à
> > toi. Pareil avec ElastiCache qui est compatible Redis. S3 est un as
> > plus intéressant, car utiliser un cloud publique sans utiliser son
> > object storage c'est se passer d'une ressource plus qu'avantageuse.
> > L'ennui c'est que S3 est devenu un standard de facto (voir Minio par
> > exemple) mais pas disponible partout (notamment sur Azure). Résultat
> > ma recommandation la dessus serait de l'utiliser mais avec une petite
> > couche d'abstraction. Pour le reste des autres services types DynamoDB
> > (pourtant bien pratiques) ou SNS/SQS j'essayerais de m'en passer, car
> > c'est en effet trop se locker.
> >
> Déployer un haproxy / nginx reverse ssl / traefik c'est pas bien
> compliqué pour un faire un LB. Les bases de données pour moi c'est nogo
> tout est en clair ils ont toutes tes données, tu ne pourra jamais être
> certifiable et pour assurer une protection rgpd bon courage.
>
> Pour l'object storage oui c'est à utiliser et on en trouve sur tous les
> clouds et sur openstack donc rien à redire là dessus si ce n'est faites
> gaffe à ce que vous mettez dessus :)
>
> Quand on déploie pour des clients dans ces clouds on fait que des
> instances sur lesquels les disques sont chiffrés et on déploie les
> services voulu, ça n'empêche pas d'être elastic à la charge mais
> l'intelligence est gérée dans les CI/CD de notre côté pas côté cloud. Y
> a aussi les containers pour être élastic.
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

[FRnOG] [TECH] Retour d'expériences AWS

[Mickael Hubert]

Bonjour à tous,
j'aimerais vous demander un retour d'expérience de l'hébergeur AWS. Car il
se peut qu'une éventualité arrive pour qu'un copain (pas moi ;) ) doive
migrer toute ou partie de ses services chez AWS.

déjà niveau réseau, comment cela s'organise ? Actuellement, nous avons 2 DC
avec du L2 et avons créé notre propre L3 avec routage OSPF, BGP pour les
interco client, QOS entre les 2 DC, etc ...

Interco L2 avec des clients c'est possible ? Si on a du L2 remontant de TH2
par exemple, il y a moyen de remonter ce L2 en cross-co chez AWS ou un
partenaire à eux (j'ai peur de votre réponse ...) ?

Peut-on gérer ses accès VPN, ses plages d'IP (Ex: ne gérant pas l'overlap
IP, on a fait le choix de bosser avec la RFC 6598 pour éviter les conflits
avec les subnets de nos clients) peut-on attribuer n'importe quel subnet à
nos VM ?

A-t-on le choix de son routeur (on bosse pas mal avec FRR), encore faut-il
pouvoir router soi-même ... ?

Côté VoIP, j'imagine que ça "marche", car de mémoire twilio sont full AWS.
Mais côté NAT etc... ça marche comment ? Je crois savoir qu'on a jamais
d'IP publique au cul de sa VM, mais que c'est du NAT 1/1. Ça se passe bien ?

Merci d'avance pour votre aide !

++

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

Re: [FRnOG] [MISC] Question PCI-DSS -> traitement d'enregistrements audio avec conversation bancaire

[Mickael Hubert]

Merci à tous pour vos réponses !
cela va grandement nous aider.
je n'hésiterai pas à revenir vers vous pour vous faire part de nos avancées.

Très bonne journée
++

Le mar. 20 oct. 2020 à 08:27, David Cheniclet  a
écrit :

> Bonjour,
>
> Dans le cadre PCI-DSS il y a deux environnements qui sont audités :
> - CDE : là où transite et où sont stocké les éléments des CB.
> - CCDE : tous les équipements qui sont connectés au CDE (par ex, la
> supervision, les backups, dns, ntp, etc...).
>
> Pour avoir subit quelques audits PCI, je te conseil de passer par un
> presta qui est déjà certifié car le temps passer à documenter et maintenir
> une infra PCI est vraiment énorme.
>
> Cordialement,
> David
>

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

[FRnOG] [MISC] Question PCI-DSS -> traitement d'enregistrements audio avec conversation bancaire

[Mickael Hubert]

Bonjour à tous,
j'ai une petite question dont je ne trouve pas encore la réponse.

Nous allons bientôt traiter des appels bancaire sous forme d'enregistrement
audio. Le traitement sera une transcription complète de l'appel (STT), dont
les données bancaires (Ex: numéros de carte bleue dictés lors de l'appel).
Notre client nous demande d'être PCI-DSS pour pouvoir travailler avec, mais
quel service doit-être PCI-DSS ?
J'imagine que le stockage à plat de ces audios lui doit-être PCI-DSS, mais
les serveurs de transcription doivent-ils l'être ?
En fait, j'ai entendu dire qu'une donnée bancaire qui ne faisait que
transiter pendant quelques millisecondes par un serveur, celui-ci n'avait
pas besoin d'être PCI.
A partir du moment ou ces traitements sont enfermés dans un vlan 100% privé
(genre DMZ).

Auriez-vous des infos sur ce type de sujet s'il vous plaît ?
L'idée serait de passer par un hébergeur PCI-DSS, mais bien entendu de
mettre le moins possible chez lui, au vu de la différence de prix de ce
type d'hébergement.

Un grand merci d'avance pour votre aide !
++

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

[FRnOG] [ALERT] Re: Perte de paquets sur OVH Roubaix

[Mickael Hubert]

Tout est revenu à la normal.
surement un problème très localisé.
++

Le mar. 21 juil. 2020 à 12:11, Mickael Hubert  a écrit :

> Bonjour,
> constatez-vous des pertes de paquets dans le VRACK sur OVH Roubaix svp ?
> de mon côté environ 25% de perte.
> Côté WAN ça m'a l'air d'aller.
>
> merci d'avance pour le coup de main.
>
> ++
>

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

[FRnOG] [ALERT] Perte de paquets sur OVH Roubaix

[Mickael Hubert]

Bonjour,
constatez-vous des pertes de paquets dans le VRACK sur OVH Roubaix svp ?
de mon côté environ 25% de perte.
Côté WAN ça m'a l'air d'aller.

merci d'avance pour le coup de main.

++

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

Re: [FRnOG] [MISC] Provider VoIP PCI-DSS

[Mickael Hubert]

Bonjour David,
merci beaucoup. je vais me lancer dans la lecture de ce doc qui doit-être
passionnant ;)
++

Le ven. 27 mars 2020 à 16:05, David Ponzone  a
écrit :

> Ca peut t’aider, si tu l’as pas déjà vu:
>
>
> https://www.pcisecuritystandards.org/documents/Protecting_Telephone_Based_Payment_Card_Data_v3-0_nov_2018.pdf
>
> Le 27 mars 2020 à 16:03, Mickael Hubert  a écrit :
>
> Bonjour à tous,
> dans le cadre d'un projet voix demandant d'être PCI-DSS, nous sommes à la
> recherche d'un provider Français VoIP (SIP) ayant la certif PCI-DSS. L'idée
> c'est que ce provider puisse nous fournir de la collecte (numéros FR et US)
> et de la terminaison avec la contrainte de certification PCI-DSS.
>
> Quelqu'un a-t-il une un retour d'expérience dans ces domaines (VoIP /
> PCI-DSS), toute info est bonne a prendre.
> Du genre coté peering, passer par Internet sans chiffrement, heu .. c'est
> mort...
> Plutôt tunnel chiffré, sip / rtp chiffré, interco directe en datacenter...
> ?
>
> Merci d'avance
> Et bon courage à tous pour le confinement !
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>
>

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

[FRnOG] [MISC] Provider VoIP PCI-DSS

[Mickael Hubert]

Bonjour à tous,
dans le cadre d'un projet voix demandant d'être PCI-DSS, nous sommes à la
recherche d'un provider Français VoIP (SIP) ayant la certif PCI-DSS. L'idée
c'est que ce provider puisse nous fournir de la collecte (numéros FR et US)
et de la terminaison avec la contrainte de certification PCI-DSS.

Quelqu'un a-t-il une un retour d'expérience dans ces domaines (VoIP /
PCI-DSS), toute info est bonne a prendre.
Du genre coté peering, passer par Internet sans chiffrement, heu .. c'est
mort...
Plutôt tunnel chiffré, sip / rtp chiffré, interco directe en datacenter... ?

Merci d'avance
Et bon courage à tous pour le confinement !

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

Re: [FRnOG] [TECH] HAProxy multi DC

[Mickael Hubert]

Nous avons plusieurs services derrières ces Haproxy, certes du web, qui ne
m'inquiète pas vraiment, un downtime d'1h est acceptable...
Notre coeur de business c'est la reco vocale, donc le point critique c'est
notre API de reco (en websocket).
Des choix stratégiques ont été fait chez un hébergeur et nous ne pouvons
pas en changer (sans que cela nous coûte 2 bras, 2 jambes)... Et cet
hébergeur (dont je tairais le nom), n'a pas "encore" la possibilité de
switcher ses annonces BGP entre ses DC.

En tout cas des solutions et infos très intéressantes ! merci

Le jeu. 5 mars 2020 à 09:51, Laurent Fabre  a écrit :

> Hello,
>
> Je pensais la solution HS mais comme on propose cloudflare...
>
> Tu mets un 3ème HAProxy en frontal pour distribuer vers tes 2x autres LB
>
> HAP sait facilement tester tout les serveurs fils pour les éjecter du RRB
> Si tout est en panne tu peux même servir une page d’excuse.
>
> La charge ?
> HAProxy c’est lite et ça ne fatiguera pas avant que tu ai assez de traffic
> pour te payer autre chose.
>
> Le débit ?
> Tout les bon CMS on un plugin CDN pour gérer des url média en direct une
> fois sur un des Web serveur
>
> Resilience du HAP frontal ?
> Un nux barebone avec juste HAP, Bein ça plante pas.
> En tout ça pas entre changement de noyaux ici. Et ca marche très bien en
> cluster HAP
>
> Tu ne sais pas configurer tout ça ?
> HAP est écrit par des français monsieurs.
> Ils drive aussi la société ALOHA ces gens.
> Support payant mais en français et conf au click
>
> Trop cher ALOHA ?
> Soit tu aprends a le faire
> Soit il existe un partenaire HAP conçurent de ALOHA pas cher.
> Il y a même des graphes pour tout le cluster pour illustrer le rapport de
> copil client :-)
> Je ne donne pas le nom car je soutiens la Frenchtek ;-P
> tip: c’est une organisation éponyme au sujet
>
> Sinon nous on fait du bgp et du L2 inter DC mais c’est pas BIZ ici ;-)
>
> My 2 cents
>
> Laurent-Charles FABRE
> Envoyé depuis mon mobile
>
>
> > Le 5 mars 2020 à 00:52, Jonathan Leroy - Inikup via frnog <
> frnog@frnog.org> a écrit :
> >
> > Le mer. 4 mars 2020 à 23:04, Philippe Bourcier  a
> écrit :
> >> Utiliser des cookies, en 2020 ? ... :)
> >> Web Storage, JWT, sessionless... ?
> >
> > Web Storage n'est pas fait pour stocker des infos de session
> > (n'importe quel script tiers sur la page peut accéder à son contenu).
> > JWT est une horreur à éviter à tout prix
> > (
> https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid
> ).
> > Dans les faits le sessionless quasiment impossible pour une app web
> > sans utiliser JWT.
> >
> > Donc oui, les cookies sont nécessaires en 2020. :)
> >
> > Pour répondre à la question initiale :
> > - Vraie solution propre : si tu as besoin d'un failover sur un DC
> > secondaire, c'est que ton business est critique et que toute coupure
> > te coûte une somme non négligeable. Donc il te faut demander un /24
> > (ainsi qu'un /48, car nous sommes en 2020) à un LIR et l'annoncer en
> > BGP. Ton hébergeur n'est pas capable de faire ça ? Qu'il change de
> > métier (ou à défaut, tu peux changer d'hébergeur).
> >
> > - Solution pas trop sale alternative : Cloudflare propose un LB dans
> > le cloud qui fait ça très bien et pour pas cher. Ça check les serveurs
> > de ton pool toutes les 15 seconds et il y a même une API.
> >
> > --
> > Jonathan Leroy
> >
> >
> > ---
> > 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] [TECH] HAProxy multi DC

[Mickael Hubert]

Un grand merci à tous pour vos retours !
BGP pas possible coté hébergeur, ses IP arrivent de façon indépendantes sur
ses 2 DC, pas possible d'annoncer le subnet du DC A sur le DC B en cas de
perte du DC A.
J'ai bien un L2 entre les 2 DC, mais il ne me servirait que pour le côté
privé. Et d'ailleurs ça casserait mon design L3 (car j'ai remonté un L3 au
dessus du L2 fourni par l'hébergeur)
En gros c'est DNS, à faire soi-même ou à déléguer, mais pas le choix
d'avoir un TTL très court ...

Si vous avez d'autres idées, faites vous plaisir ;)

++


Le mar. 3 mars 2020 à 13:06, Michel 'ic' Luczak  a
écrit :

> Hello,
>
> > On 3 Mar 2020, at 11:15, Mickael Hubert  wrote:
> >
> > Bonjour à tous,
> > nous devons réaliser du HA (et si possible du loadbalancing) entre 2
> > instances HAProxy, ces 2 Haproxy doivent-être hébergés dans 2 DC
> différents.
> > Pas possible de réaliser du VRRP car nous ne pouvons pas switcher l'IP
> > publique de l'un à l'autre des DC.
> >
> > La solution la plus simple serait de réaliser du round robin DNS pour
> > pointer sur les 2 IP publiques des 2 HAproxy. Mais avant de se lancer
> tête
> > baissée dans le truc, je souhaitais savoir si vous auriez d'autre
> solutions
> > à me proposer ?
>
> Je fais ça pour faire du “cdn lite” pour des clients avec du varnish sur 2
> serveurs dédiés. Chacun porte aussi un gdnsd avec un healthcheck des deux
> serveurs. Les deux sont configurés comme NS du sous domaine “static.”. En
> situation normale, les deux renvoient l’IP des deux, si un des deux tombe
> (niveau varnish) pour une raison ou une autre, une seule IP est renvoyée.
> Si une des deux machines tombe complètement, un seul DNS fonctionne (c’est
> suffisant) et ne renvoie que l’IP de la survivante.
>
> ++ ic
>
>

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

[FRnOG] [TECH] HAProxy multi DC

[Mickael Hubert]

Bonjour à tous,
nous devons réaliser du HA (et si possible du loadbalancing) entre 2
instances HAProxy, ces 2 Haproxy doivent-être hébergés dans 2 DC différents.
Pas possible de réaliser du VRRP car nous ne pouvons pas switcher l'IP
publique de l'un à l'autre des DC.

La solution la plus simple serait de réaliser du round robin DNS pour
pointer sur les 2 IP publiques des 2 HAproxy. Mais avant de se lancer tête
baissée dans le truc, je souhaitais savoir si vous auriez d'autre solutions
à me proposer ?
Car à ma connaissance, si un des HAProxy est HS, le DNS n'en saura rien et
continuera à balancer du trafic dessus (avec 50% d'échec).

Merci d'avance pour votre aide !

++

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

Re: [FRnOG] [TECH] L2 entre un tiers et une infra OVH

[Mickael Hubert]

Merci à tous pour vos retours.
En effet pas trop le choix que d'héberger ce routeur qqpart ;)
OVH ne font plus de "sur-mesure" dans leur offre d'housing, il faudrait
donc prendre 1/4 baie chez un tiers.
Autre point important, c'est qu'à l'heure actuelle, nous n'avons pas des
personnes sur Paris 24/7, il me faudra donc une offre "clé en main" pour au
moins le coup de bouton...

++

Le lun. 17 févr. 2020 à 13:10, Sébastien Lesimple <
sebastien.lesim...@iguanetel.fr> a écrit :

> Le 17/02/2020 à 09:13, Mickael Hubert a écrit :
>
> Bonjour à tous,
> je me permets de vous solliciter, car j'ai beaucoup de mal à trouver une
> solution à mon problème.
> Je cherche un moyen de monter un L2 entre divers clients et notre infra
> hébergée chez OVH.
>
> Certains clients travaillent avec Orange et souhaitent tout naturellement
> mettre une patte de leur MPLS dans notre infra, why not...
> Mais pour ce faire Orange a besoin d'installer un routeur, malheureusement
> chez OVH il n'est pas possible d'installer un équipement tiers dans leurs
> DCs.
>
> Si...
> Tu te prends 1/4 de baie dans la salle OVH GlobalSwitch.
> https://www.ovh.com/fr/housing/
> Et tu vois avec eux si monter un VLAN avec ton invra est possible, sinon
> un VxLAN ou un L2VPN ou encore du MPLSoGREoIP ou...
> Les solutions sont legion.
> Seb.
>
> Comment qu'on fait ??? :( Avez-vous déjà rencontré ce type de problème ?
>
> La seule idée que je vois serait d'héberger le routeur Orange chez un tier,
> puis de monter le L2 entre ce routeur et l'offre Cloud 
> Connect<https://www.ovh.com/fr/solutions/ovhcloud-connect/> 
> <https://www.ovh.com/fr/solutions/ovhcloud-connect/> d'OVH.
> Ensuite, mutualiser ce routeur Orange (1 vlan == 1 MPLS client)
>
> Vous auriez d'autres solutions svp, peut-être plus économique que de devoir
> repayer du U à un tiers ?
>
> Un grand merci d'avance à vous tous !
>
> ++
>
> ---
> Liste de diffusion du FRnOGhttp://www.frnog.org/
>
>
>

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

[FRnOG] [TECH] L2 entre un tiers et une infra OVH

[Mickael Hubert]

Bonjour à tous,
je me permets de vous solliciter, car j'ai beaucoup de mal à trouver une
solution à mon problème.
Je cherche un moyen de monter un L2 entre divers clients et notre infra
hébergée chez OVH.

Certains clients travaillent avec Orange et souhaitent tout naturellement
mettre une patte de leur MPLS dans notre infra, why not...
Mais pour ce faire Orange a besoin d'installer un routeur, malheureusement
chez OVH il n'est pas possible d'installer un équipement tiers dans leurs
DCs.

Comment qu'on fait ??? :( Avez-vous déjà rencontré ce type de problème ?

La seule idée que je vois serait d'héberger le routeur Orange chez un tier,
puis de monter le L2 entre ce routeur et l'offre Cloud Connect
 d'OVH.
Ensuite, mutualiser ce routeur Orange (1 vlan == 1 MPLS client)

Vous auriez d'autres solutions svp, peut-être plus économique que de devoir
repayer du U à un tiers ?

Un grand merci d'avance à vous tous !

++

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

Re: [FRnOG] [TECH] Bascule IP Publique

[Mickael Hubert]

Bonsoir,
de notre côté nous avons opté pour 4 routeurs (2 sur chaque DC)
- Coté LAN, nous avons du VRRP sur l'ensemble de nos VLANs
- Coté InterDC,  nous avons de l'OSPF, car nous avons réalisé un L3 au
dessus du L2 fourni par l'hébergeur
- Coté WAN, malheureusement les IP publiques ne switch pas de l'un à
l'autre, donc nous avons géré par DNS ou par double interco (SIP par
exemple)

Le but de cela était d'être en actif/actif et en cas de perte d'un DC que
l'on soit capable de tourner sur une patte

+ +

Le ven. 14 févr. 2020 à 16:30, Raphael Mazelier  a
écrit :

>
> On 14/02/2020 04:55, Michel Py wrote:
> > Je plussoie aussi. La redondance, c'est bien. La redondance testée,
> c'est mieux ! Quel que soit le système, çà marche rarement la première fois.
> >
> J'ai presque envie de dire que même si cela a marché pendant le test
> cela ne marchera pas quand tu en auras besoin.
>
> La meilleure redondance d'infrastructure (réseau/système) c'est celle
> dont tu n'as pas besoin.
>
> Premièrement c'est toujours meilleur d'avoir une redondance pensé au
> niveau applicatif.
>
> Deuxièmement si je me fie à mes 18 ans d'expériences, finalement je
> pense qu'essayer de rendre les choses redondantes m'ont posé plus de
> problèmes et faire perdre de temps que sauver quoi ce soit.
>
> Le meilleur exemple, parmi les nombreuses anecdotes que je pourrais
> avoir sur le sujet, c'est la redondance de data-center, ou on essaye
> d'avoir tout en double équitablement réparti, et que finalement on
> double le spof, et que dès qu'un des deux DCs à un soucis, l'ensemble
> est HS. Testé et approuvé de nombreuse fois. Ceci étant je peux moduler
> ce propos, car en cas de crash majeur (type incendie ou autre) c'est
> tout de même beaucoup plus rapide de repartir de ton second datacenter.
>
>
> --
>
> Raphael Mazelier
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

[FRnOG] [MISC] Conférence à Reims autour des data et de l'IA

[Mickael Hubert]

Bonjour à tous,
je pose ça là, cela pourrait peut-être en intéresser certains.
Un conférence qui m'a l'air pas mal, se déroulera à Reims (45 mins de
Paris) le 27/09/19
https://www.webinreims.fr/

*Un descriptif:*

Vous êtes-vous déjà demandé ce que devenaient réellement vos données
personnelles ?
Qui sont les personnes qui les exploitent ? Toutes les entreprises
disposent de données, à
petite, moyenne ou grande échelle. Peut-on réellement en tirer une valeur
ajoutée… et
comment ? Enfin qui n’a pas entendu parler d’intelligence artificielle ?


*Intervenants :*
- Aurélie Bayre, Développeuse React JS chez DaTeam

- Sophie Bertrand,
Responsable de
coopération numérique et Gallica à la
Bibliothèque Nationale de France

- Thibault Clérice,
Expert ingénierie
pour les digital humanities à l’École
Nationale des Chartes

- Jean-Christophe Gatuingt,
Co-fondateur de Visibrain

- Nicolas Gillet,
CEO de Black Moon Lab

- Jérémy Gignon,
Développeur chez AdBack

- Sylvain Laviolette,
CEO de Ezyperf

- Maël Montarou,
Directeur du développement d’audience de Prisma
Media

- Sylvain Peyronnet,
Chief AI de Qwant et Co-fondateur des IX-Labs

- Vincent Terrasi,
Pionnier du Data SEO

- Magali Touroude,
Conseil en Propriété Industrielle et fondatrice de
YesMyPatent.com

- Maxime Valette,
Entrepreneur + Investisseur

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

Re: [FRnOG] [TECH] Cluster VMWARE chez OVH

[Mickael Hubert]

Lol
Ça vaut aussi pour OVH je pense ;)

Le mar. 20 août 2019 20:24, David Ponzone  a
écrit :

> Je répondais à Olivier ceci dit :)
>
> David Ponzone
>
>
>
> Le 20 août 2019 à 20:19, Mickael Hubert  a écrit :
>
> Ha si seulement j'avais le choix :)
>
> Le mar. 20 août 2019 18:14, David Ponzone  a
> écrit :
>
>>
>> C’est pas un peu sport de reposer ton cœur de métier sur un acteur du
>> Cloud qui ne connaît rien à ton métier ?
>>
>> David Ponzone
>>
>>
>>
>> > Le 20 août 2019 à 16:31, Olivier Lange  a écrit :
>> >
>> >> Le mar. 20 août 2019 à 16:27, Mickael Hubert  a
>> écrit :
>> >>
>> >> Super merci beaucoup pour ta réponse ! Je n'hésiterai pas à te demander
>> >> des infos si besoin ;)
>> >> pas cool le vRack :( c'est franchement moyen.
>> >>
>> >> J'aime bien proxmox, mais pour y placer de l'infra VoIP j'ai encore des
>> >> réticences ...
>> >>
>> >
>> > SI c'est pour faire de la VOIP, oublie l'offre SDDC d'OVH. C'est
>> jsutement
>> > a cause de la VOIP qu'on quitte cette offre. On a des pertes de paquets
>> > aléatoires sur certains Hosts, sans que cela puisse être solutionner par
>> > OVH. Ca a durer 1 an 1/2. J'ai du migrer en urgence certaines VM vers un
>> > Proxmox chez OVH, le temps qu'on monte notre cluster.
>> >
>> > Pour le coup, on est opérateur téléphonique, et c'est notre coeur de
>> > métier. L'offre SDDC, c'est comme beaucoup de cloud, top pour de
>> l'appli en
>> > TCP, ou pouvoir déployer simplement... Mais pour de l'UDP, il y a trop
>> de
>> > paramètres non maitrisés, et quand tu veux détecter de la panne
>> aléatoire,
>> > et que tu n'a pas accès ni a l'host, ni au réseau, ca devient
>> franchement
>> > compliqué...
>> >
>> > Olivier
>> >
>> >>
>> >> ++
>> >>
>> >>
>> >>
>> >>> Le mar. 20 août 2019 à 16:21, Olivier Lange  a
>> écrit :
>> >>>
>> >>> Oui, c'est ca ;). Elle  plusieurs nom.
>> >>>
>> >>> Dans ce cas, non. Quand tu commande une offre Dedicated Cloud, tout
>> tes
>> >>> Hosts sont dans la même zone. Si tu veux avoir plusieurs DC, tu dois
>> >>> commander plusieurs Dedicated Cloud, et les mettres dans le vRack. Tu
>> >>> pourra ainsi communiquer en L2, mais impossible de gérer tes VM
>> directement
>> >>> depuis 1 seul Vsphere.
>> >>>
>> >>> Ou alors si tu veux de la HA sur plusieurs DC, tu peux installer
>> Zerto,
>> >>> mais tu dois la aussi commander 2 SDDC (ou Dedicated Cloud).
>> >>>
>> >>> Attention par contre avec le vRack:
>> >>> - Ne fait pas partie des SLA (pour le moment... Mais ca fait des
>> années
>> >>> qu'on rale la dessus...)
>> >>> - Pas sur que tu aie tes 10G entre les 2 clusters
>> >>>
>> >>> Hésite pas si tu as des questions. J'ai un infra SDDC depuis 5 ans,
>> mais
>> >>> la on est en train de sortir l'ensemble de l'infra pour les mettre
>> dans un
>> >>> cluster Proxmox dans un de nos DC ;)
>> >>>
>> >>> Olivier
>> >>>
>> >>> Le mar. 20 août 2019 à 16:16, Mickael Hubert  a
>> >>> écrit :
>> >>>
>> >>>> j'imagine que oui, c'est plutôt le nom "Dedicated cloud", mais c'est
>> >>>> sûrement la même chose non  ?
>> >>>>
>> >>>> Le mar. 20 août 2019 à 16:11, Olivier Lange  a
>> >>>> écrit :
>> >>>>
>> >>>>> Hello,
>> >>>>>
>> >>>>> Tu parle de l'offre SDDC ?
>> >>>>>
>> >>>>> Le mar. 20 août 2019 à 16:10, Mickael Hubert  a
>> >>>>> écrit :
>> >>>>>
>> >>>>>> Bonjour à tous,
>> >>>>>> Y aurait-il des personnes qui ont un hébergement vmware chez OVH ?
>> Si
>> >>>>>> oui,
>> >>>>>> j'ai quelques questions:
>> >>>>>> - Peut-on avoir des hosts vmware reliés dans le même cluster, dans
>> un
>> >>>>>> autre
>> >>>>>> DC (migration des VM facilité) ?
>> >>>>>> - Si pas possible, a-t-on au moins la possibilité de faire
>> transiter
>> >>>>>> le L2
>> >>>>>> entre les deux clusters indépendants ?
>> >>>>>>
>> >>>>>> Vous l'aurez compris, le but est de ne pas avoir toute l'infra
>> vmware
>> >>>>>> dans
>> >>>>>> un seul DC.
>> >>>>>>
>> >>>>>> Merci d'avance
>> >>>>>> ++
>> >>>>>>
>> >>>>>> ---
>> >>>>>> 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] [TECH] Cluster VMWARE chez OVH

[Mickael Hubert]

Ha si seulement j'avais le choix :)

Le mar. 20 août 2019 18:14, David Ponzone  a
écrit :

>
> C’est pas un peu sport de reposer ton cœur de métier sur un acteur du
> Cloud qui ne connaît rien à ton métier ?
>
> David Ponzone
>
>
>
> > Le 20 août 2019 à 16:31, Olivier Lange  a écrit :
> >
> >> Le mar. 20 août 2019 à 16:27, Mickael Hubert  a
> écrit :
> >>
> >> Super merci beaucoup pour ta réponse ! Je n'hésiterai pas à te demander
> >> des infos si besoin ;)
> >> pas cool le vRack :( c'est franchement moyen.
> >>
> >> J'aime bien proxmox, mais pour y placer de l'infra VoIP j'ai encore des
> >> réticences ...
> >>
> >
> > SI c'est pour faire de la VOIP, oublie l'offre SDDC d'OVH. C'est
> jsutement
> > a cause de la VOIP qu'on quitte cette offre. On a des pertes de paquets
> > aléatoires sur certains Hosts, sans que cela puisse être solutionner par
> > OVH. Ca a durer 1 an 1/2. J'ai du migrer en urgence certaines VM vers un
> > Proxmox chez OVH, le temps qu'on monte notre cluster.
> >
> > Pour le coup, on est opérateur téléphonique, et c'est notre coeur de
> > métier. L'offre SDDC, c'est comme beaucoup de cloud, top pour de l'appli
> en
> > TCP, ou pouvoir déployer simplement... Mais pour de l'UDP, il y a trop de
> > paramètres non maitrisés, et quand tu veux détecter de la panne
> aléatoire,
> > et que tu n'a pas accès ni a l'host, ni au réseau, ca devient franchement
> > compliqué...
> >
> > Olivier
> >
> >>
> >> ++
> >>
> >>
> >>
> >>> Le mar. 20 août 2019 à 16:21, Olivier Lange  a
> écrit :
> >>>
> >>> Oui, c'est ca ;). Elle  plusieurs nom.
> >>>
> >>> Dans ce cas, non. Quand tu commande une offre Dedicated Cloud, tout tes
> >>> Hosts sont dans la même zone. Si tu veux avoir plusieurs DC, tu dois
> >>> commander plusieurs Dedicated Cloud, et les mettres dans le vRack. Tu
> >>> pourra ainsi communiquer en L2, mais impossible de gérer tes VM
> directement
> >>> depuis 1 seul Vsphere.
> >>>
> >>> Ou alors si tu veux de la HA sur plusieurs DC, tu peux installer Zerto,
> >>> mais tu dois la aussi commander 2 SDDC (ou Dedicated Cloud).
> >>>
> >>> Attention par contre avec le vRack:
> >>> - Ne fait pas partie des SLA (pour le moment... Mais ca fait des années
> >>> qu'on rale la dessus...)
> >>> - Pas sur que tu aie tes 10G entre les 2 clusters
> >>>
> >>> Hésite pas si tu as des questions. J'ai un infra SDDC depuis 5 ans,
> mais
> >>> la on est en train de sortir l'ensemble de l'infra pour les mettre
> dans un
> >>> cluster Proxmox dans un de nos DC ;)
> >>>
> >>> Olivier
> >>>
> >>> Le mar. 20 août 2019 à 16:16, Mickael Hubert  a
> >>> écrit :
> >>>
> >>>> j'imagine que oui, c'est plutôt le nom "Dedicated cloud", mais c'est
> >>>> sûrement la même chose non  ?
> >>>>
> >>>> Le mar. 20 août 2019 à 16:11, Olivier Lange  a
> >>>> écrit :
> >>>>
> >>>>> Hello,
> >>>>>
> >>>>> Tu parle de l'offre SDDC ?
> >>>>>
> >>>>> Le mar. 20 août 2019 à 16:10, Mickael Hubert  a
> >>>>> écrit :
> >>>>>
> >>>>>> Bonjour à tous,
> >>>>>> Y aurait-il des personnes qui ont un hébergement vmware chez OVH ?
> Si
> >>>>>> oui,
> >>>>>> j'ai quelques questions:
> >>>>>> - Peut-on avoir des hosts vmware reliés dans le même cluster, dans
> un
> >>>>>> autre
> >>>>>> DC (migration des VM facilité) ?
> >>>>>> - Si pas possible, a-t-on au moins la possibilité de faire transiter
> >>>>>> le L2
> >>>>>> entre les deux clusters indépendants ?
> >>>>>>
> >>>>>> Vous l'aurez compris, le but est de ne pas avoir toute l'infra
> vmware
> >>>>>> dans
> >>>>>> un seul DC.
> >>>>>>
> >>>>>> Merci d'avance
> >>>>>> ++
> >>>>>>
> >>>>>> ---
> >>>>>> 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] [TECH] Cluster VMWARE chez OVH

[Mickael Hubert]

Super merci beaucoup pour ta réponse ! Je n'hésiterai pas à te demander des
infos si besoin ;)
pas cool le vRack :( c'est franchement moyen.

J'aime bien proxmox, mais pour y placer de l'infra VoIP j'ai encore des
réticences ...

++



Le mar. 20 août 2019 à 16:21, Olivier Lange  a écrit :

> Oui, c'est ca ;). Elle  plusieurs nom.
>
> Dans ce cas, non. Quand tu commande une offre Dedicated Cloud, tout tes
> Hosts sont dans la même zone. Si tu veux avoir plusieurs DC, tu dois
> commander plusieurs Dedicated Cloud, et les mettres dans le vRack. Tu
> pourra ainsi communiquer en L2, mais impossible de gérer tes VM directement
> depuis 1 seul Vsphere.
>
> Ou alors si tu veux de la HA sur plusieurs DC, tu peux installer Zerto,
> mais tu dois la aussi commander 2 SDDC (ou Dedicated Cloud).
>
> Attention par contre avec le vRack:
> - Ne fait pas partie des SLA (pour le moment... Mais ca fait des années
> qu'on rale la dessus...)
> - Pas sur que tu aie tes 10G entre les 2 clusters
>
> Hésite pas si tu as des questions. J'ai un infra SDDC depuis 5 ans, mais
> la on est en train de sortir l'ensemble de l'infra pour les mettre dans un
> cluster Proxmox dans un de nos DC ;)
>
> Olivier
>
> Le mar. 20 août 2019 à 16:16, Mickael Hubert  a écrit :
>
>> j'imagine que oui, c'est plutôt le nom "Dedicated cloud", mais c'est
>> sûrement la même chose non  ?
>>
>> Le mar. 20 août 2019 à 16:11, Olivier Lange  a
>> écrit :
>>
>>> Hello,
>>>
>>> Tu parle de l'offre SDDC ?
>>>
>>> Le mar. 20 août 2019 à 16:10, Mickael Hubert  a
>>> écrit :
>>>
>>>> Bonjour à tous,
>>>> Y aurait-il des personnes qui ont un hébergement vmware chez OVH ? Si
>>>> oui,
>>>> j'ai quelques questions:
>>>> - Peut-on avoir des hosts vmware reliés dans le même cluster, dans un
>>>> autre
>>>> DC (migration des VM facilité) ?
>>>> - Si pas possible, a-t-on au moins la possibilité de faire transiter le
>>>> L2
>>>> entre les deux clusters indépendants ?
>>>>
>>>> Vous l'aurez compris, le but est de ne pas avoir toute l'infra vmware
>>>> dans
>>>> un seul DC.
>>>>
>>>> Merci d'avance
>>>> ++
>>>>
>>>> ---
>>>> Liste de diffusion du FRnOG
>>>> http://www.frnog.org/
>>>>
>>>

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

Re: [FRnOG] [TECH] Cluster VMWARE chez OVH

[Mickael Hubert]

j'imagine que oui, c'est plutôt le nom "Dedicated cloud", mais c'est
sûrement la même chose non  ?

Le mar. 20 août 2019 à 16:11, Olivier Lange  a écrit :

> Hello,
>
> Tu parle de l'offre SDDC ?
>
> Le mar. 20 août 2019 à 16:10, Mickael Hubert  a écrit :
>
>> Bonjour à tous,
>> Y aurait-il des personnes qui ont un hébergement vmware chez OVH ? Si oui,
>> j'ai quelques questions:
>> - Peut-on avoir des hosts vmware reliés dans le même cluster, dans un
>> autre
>> DC (migration des VM facilité) ?
>> - Si pas possible, a-t-on au moins la possibilité de faire transiter le L2
>> entre les deux clusters indépendants ?
>>
>> Vous l'aurez compris, le but est de ne pas avoir toute l'infra vmware dans
>> un seul DC.
>>
>> Merci d'avance
>> ++
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>

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

[FRnOG] [TECH] Cluster VMWARE chez OVH

[Mickael Hubert]

Bonjour à tous,
Y aurait-il des personnes qui ont un hébergement vmware chez OVH ? Si oui,
j'ai quelques questions:
- Peut-on avoir des hosts vmware reliés dans le même cluster, dans un autre
DC (migration des VM facilité) ?
- Si pas possible, a-t-on au moins la possibilité de faire transiter le L2
entre les deux clusters indépendants ?

Vous l'aurez compris, le but est de ne pas avoir toute l'infra vmware dans
un seul DC.

Merci d'avance
++

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

Re: [FRnOG] [TECH] SBC - informations et retour d’expèrience

[Mickael Hubert]

Bonjour à tous,
étant un fervent défenseur de l'opensources, j'opterais pour du Freeswitch
+ (Kamailio / OpenSIPS)

Dans une ancienne vie j'ai travaillé avec du Genband, car seules les stacks
proprios sont capables de travailler en l'overlap IP (intégration dans du
MPLS par exemple).
Hormis ce cas d'overlap (dont tu n'auras pas besoin en partant sur de l'AWS
;) ), j'ai aussi travaillé sur un mix de FreeSwitch + OpenSIPS qui n'avait
strictement rien à envier au matos Genband.

Pour reprendre tes demandes:
- SIP only ==> FS + opensips
- Masquage de topologie ==> sur opensips (même si FS est naturellement
capable de le faire)
- Pas de transcoding pour le moment. ==> si besoin sur FS
- Facilité de routage, LCR, manipulation de numéro ==> sur opensips
- Manipulation des header SIP. ==> sur opensips
- Mode HA, si possible sans perte des comm lors du failover … ==> no prob
avec un keepalived + dev, nous avions entre 5 et 7 secondes de coupure du
RTP max, plutôt cool ;)

Pour finir, je suis OK avec Alain, j'entends beaucoup parler d'AudioCode
(hard + VM possibles) ou la Rolls-Royce des SBC, Oracle, mais je ne sais
pas si il y a une version VM...

++


Le ven. 5 avr. 2019 à 13:16, Raphael Mazelier  a écrit :

> On 04/04/2019 22:52, Kevin CHAILLY | Service Technique wrote:
>
> >
> > Si je fais tourner un gros asterisk / freeswitch / kamailio dans le
> Cloud,
> >
> >
> > Je serai assez sensible aux timings de la bête, avez-vous une infra de
> virtu spécifique pour les applications rile-taïme ? une recette magique, un
> hyperviseur aux fines herbes ?
> >
>
> D'une manière générale le cloud n'est pas magique, donc tu as les mêmes
> contraintes qu'on premise. Si tu veux tu peux prendre un serveur dédié.
> Sinon c'est comme de la virtualisation classique donc il faut prendre
> des instances qui ne sont pas à réservation fixe (par exemple bannir les
> instances T chez Aws).
>
>
> >
> > J'avais lu ici il me semble quelqu'un qui avait prix le parti de
> surdimensionner de l'hôte ESXi et ne faire porter que de la voix a celui-ci
> pour éviter les problèmes éventuels, c'est a une vache près la technique
> que j'utilise pour une partie de l'infra voix portée.
>
>
> Pas surdimensionné juste ne pas faire d'over prosionning du tout (ni
> mémoire, ni cpu) aka faire du partitionnement statique.
> Sinon en effet tu peux te retrouver avec des soucis assez peu drôle.
>
>
>
>
> --
> Raphael Mazelier
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [MISC] Mms pervers envoyé a un mineur

[Mickael Hubert]

Merci à tous pour vos réponses.
Ma famille a en effet porté plainte, car ce SMS a plutôt bien choqué ma
nièce...

++

Le jeu. 27 déc. 2018 21:02, Giles R DeMourot  a
écrit :

> Cengiz: Oui, mais la faille permet d'intercepter sms et communications. Le
> GCHQ puis la NSA  l'ont utilisé:
>
> 'NSA and/or GCHQ hacked into the Dutch SIM card manufacturer Gemalto,
> stealing the encryption keys for billions of cell phones. People are still
> trying to figure out exactly what this means, but it seems to mean that the
> intelligence agencies have access to both voice and data from all phones
> using those cards.' -The Intercept
>
> https://goo.gl/sRLe0Q
>
> -Original Message-
> From: frnog-requ...@frnog.org  On Behalf Of
> Cengiz Ünlü
> Sent: Thursday, December 27, 2018 8:29 PM
> To: Giles R DeMourot 
> Cc: Mickael Hubert ; Frnog misc 
> Subject: Re: [FRnOG] [MISC] Mms pervers envoyé a un mineur
>
> Bonsoir,
>
> Le mer. 26 déc. 2018 à 17:00, Giles R DeMourot a écrit :
> > Un faille de sécurité dans le Protocole 7 (SS7) permet avec  un kit
> > vendu par des acteurs russes sur le Darknet de détourner
> > communications, sms et mms. Voir: https://goo.gl/wZiUVA
>
> Ton lien parle des messages SMS uniquement ;-) Bien que visuellement pour
> l'utilisateur, les SMS et MMS utilisent le même client, les deux
> applications utilisent des protocoles différents.
>
> > From: frnog-requ...@frnog.org  On Behalf Of
> > Mickael Hubert Ma question est la suivante: est-il possible qu'un numéro
> de mobile français soit facilement usurpé ?
>
> Un SMS j'aurais répondu oui. Facilement, je ne me prononce pas.
> Un MMS, j'ai beaucoup plus de doute.
>
> > Bien entendu la famille de ma nièce compte porter plainte.
>
> J'espère que la famille a déjà porter plainte, il ne faut pas perdre de
> temps je pense !
>
> Cengiz
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>

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

[FRnOG] [MISC] Mms pervers envoyé a un mineur

[Mickael Hubert]

Bonjour,
Je me permets de poster sur cette mailing liste pour avoir une info.

Ma nièce de 15 ans vient de recevoir 2 MMS de la part d'un inconnu avec 2
photos : son buste nu et une seconde avec son sexe en érection. Je précise
que l'on voit très bien le visage de cet homme et qu'il a au moins 50 ans.

Sachant qu'il s'agit d'un simple MMS j'ai pu rappeler moi-même ce numéro.

L'homme au bout du fil me précise qu'il s'est fait pirater son portable et
qu'il a déjà porté plainte pour cet acte.

Ma question est la suivante: est-il possible qu'un numéro de mobile
français soit facilement usurpé ? Est-ce une pratique fréquente à votre
avis ?

Pour ma part si cet homme a pu répondre à ce même numéro qui a envoyé les 2
MMS pervers moins de 10mins après que ma nièce les ait reçus, je me dis
quand même que ce numéro n'est peut-être pas si piraté...

Bien entendu la famille de ma nièce compte porter plainte. En espérant que,
si cet homme dit vrai et qu'il s'est fait pirater, il ne sera pas inquiété
par cette plainte.

Bonne journée à vous et merci d'avance

Micka

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

[FRnOG] [BIZ] Recherche d'un cloud privé

[Mickael Hubert]

Bonjour à tous,
je suis à la recherche d'un hébergeur qui serait capable de me proposer du
cloud privé. J'ai besoin de qqch de plutôt robuste et avec peu de latence.

*pour plus d'info:*
- 99% de machines Linux en VM
- infra répartie sur deux DC
- possibilité d'avoir du L2 (8021.Q) ou L3 (MPLS) entre ces deux DC (100M
mini)
- Hyper V ou Vmware
- Bloc d'IP publiques V4 et V6 sur les deux DC (avec transit)
- Redondance complète entre les deux DC
- Être 100% autonome dans la gestion de l'infra au quotidien (création de
VM, de Vlans, etc ...)

Je vous retranscris ça pêle-mêle ;) , mais n'hésitez pas à me répondre en
privé pour toutes autres questions.

Un grand merci d'avance

++

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

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

[Mickael Hubert]

Le 17 mai 2018 à 14:00, Alexis <a...@gen-ip.fr> a écrit :

> J'approuve également. DNS et ENUM répondent parfaitement à la demande
> technique pour moi. Et un serveur DNS, on sait en faire depuis les débuts
> d'internet, on sait que ça tourne, c'est fiable, robuste, basique. Tout le
> monde peut en avoir chez soit sans avoir besoin d'un serveur avec 5Go
> de RAM pour tenir 100 millions de routes BGP. Ça répond juste au "KISS" :
> keep it simple and stupid.
>
> D'ailleurs, je ne suis pas expert DNS, mais on peut pas juste avoir
> quelque chose du genre "l'APNF met un serveur DNS master et déclare les IP
> des serveurs DNS des opérateurs  autorisés a avoir des DNS escalves du
> serveur de l'APNF. Chaque opérateur interroge son serveur enum esclave
> local, copie exacte du DNS master de l'APNF" ? C'est du très basique,
> minimaliste et ça évite aux opérateurs frileux/pas transparents de publier
> dans un annuaire public les numéros qu'ils gèrent.
>


*Dans tout les cas ce type de DNS ne devront jamais être publics à mon sens
(même si l'idée d'origine d'ENUM est de s'ouvrir sur l'INTERNET ;) )*

*Si on pousse l'idée en effet le mieux serait d'avoir des DNS autoritaires
chez l'asso, puis des résolveurs dans les réseaux internes des providers.*


>
> Par contre, ça laisse toujours des questions administratives. Quid des
> appels d'urgence ? De la validation des demandes d'ajout dans le domaine
> enum ? De la facturation inter-opérateurs (taxe d'acheminement ... vraiment
> utile de la conserver, franchement ?) ? Dispo uniquement sur un France-IX
> like avec QoS ? etc.
>


*- Numéros d'urgence: ça ne change rien pour moi, il faut les traduire puis
envoyer comme un SDA "normal".*

*- la TA est importante pour certains et beaucoup moins pour d'autres et la
population intéressée par ce type de projet seront les "autres",ok , mais
c'est sensible quand même ;)*
*- QOS: il faudra dans tout les cas passer par un réseau IP avec QOS entre
provider, donc oui QOS obligatoire*


>
> Alexis Prodhomme
> Support Technique Gen-IP
> email : supp...@gen-ip.fr
> tel : 02.90.75.30.50
>
> Le 17/05/2018 à 12:08, Mickael Hubert a écrit :
>
>> Bonjour à tous,
>>
>> Le 17 mai 2018 à 11:19, Richard DEMONGEOT <rich...@demongeot.biz> a
>> écrit :
>>
>> Hello,
>>>
>>> Toutes les idées a base de BGP sont très sexy, et intéressantes, mais il
>>> reste un problème de base. Comment chaque opérateur va devoir implémenter
>>> un composant liant BGP / Voix.
>>> Cependant, comme évoqué à plusieurs reprises, pas de modifications
>>> incessantes de la table de routage voix.
>>>
>>>
>> *Pour ma part le composant de routage pour la voix devrait-être le DNS
>> (ENUM), je sais j'insiste sur ce point ;) , mais devoir trouver /
>> développer un composant "gateway" entre BGP et voix pour gérer du trafic
>> de
>> prod me semble hasardeux.*
>> *Bon, ce composant existe peut-être déjà, je ne sais pas...*
>>
>>
>>
>> Pour la table de routage internationale, OSEF dans un IX. (ou alors, c'est
>>> un GIE, donc avec plusieurs fournisseurs, et c'est plus complexe). Dans
>>> tous les cas, les changements sur les non-membres : on s'en fout. (porta
>>> depuis / vers les membres à gérer uniquement). Exemple : porta orange /
>>> sfr
>>> : quel impact vu qu'a moyen terme aucun des deux ne sera dessus? Pire,
>>> belgacom / proxymus?
>>>
>>> Pour moi, le plus simple, sur, rapide, fonctionnel reste :
>>>
>>> Un IX dédié à la voix (qu'on peut multiplier à souhaits).
>>> Sur cet IX :
>>> - Chaque membre qui s'y connecte doit y mettre un ou plusieurs SBC;
>>> - L'association fourni un ou plusieurs proxy SIP - en guise de voice
>>> route
>>> server.
>>>
>>> Coût pour l'association :
>>> 1 switch (1G/10G de préférence);
>>> 3 serveurs (db + proxy).
>>>
>>> Le cheminement serai alors le suivant :
>>> Le SBC du client envoie son INVITE SIP, sur le / l'un des proxy.
>>> Le proxy intérroge la DB, fournie par l'APNF, et route sur le bon membre.
>>> => Si c'est pas sur un membre, alors plusieurs cas sont possibles :
>>> A/ L'association renvoi un code retour temporaire ou permanent sur ce
>>> numéro (pas routable sur l'IX);
>>> B/ L'association étant un GIE, et disposant de contrat de terminaison SIP
>>> peut router le numéro. ==> Quid de la facturation/re-facturation? Par
>>> contre, économie d'échelle si les contrats sont mutualisés.
>>> => Si le membre ne réponds pas (SIP option réguliers) a

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

[Mickael Hubert]

Bonjour à tous,

Le 17 mai 2018 à 11:19, Richard DEMONGEOT  a écrit :

> Hello,
>
> Toutes les idées a base de BGP sont très sexy, et intéressantes, mais il
> reste un problème de base. Comment chaque opérateur va devoir implémenter
> un composant liant BGP / Voix.
> Cependant, comme évoqué à plusieurs reprises, pas de modifications
> incessantes de la table de routage voix.
>


*Pour ma part le composant de routage pour la voix devrait-être le DNS
(ENUM), je sais j'insiste sur ce point ;) , mais devoir trouver /
développer un composant "gateway" entre BGP et voix pour gérer du trafic de
prod me semble hasardeux.*
*Bon, ce composant existe peut-être déjà, je ne sais pas...*


>
> Pour la table de routage internationale, OSEF dans un IX. (ou alors, c'est
> un GIE, donc avec plusieurs fournisseurs, et c'est plus complexe). Dans
> tous les cas, les changements sur les non-membres : on s'en fout. (porta
> depuis / vers les membres à gérer uniquement). Exemple : porta orange / sfr
> : quel impact vu qu'a moyen terme aucun des deux ne sera dessus? Pire,
> belgacom / proxymus?
>
> Pour moi, le plus simple, sur, rapide, fonctionnel reste :
>
> Un IX dédié à la voix (qu'on peut multiplier à souhaits).
> Sur cet IX :
> - Chaque membre qui s'y connecte doit y mettre un ou plusieurs SBC;
> - L'association fourni un ou plusieurs proxy SIP - en guise de voice route
> server.
>
> Coût pour l'association :
> 1 switch (1G/10G de préférence);
> 3 serveurs (db + proxy).
>
> Le cheminement serai alors le suivant :
> Le SBC du client envoie son INVITE SIP, sur le / l'un des proxy.
> Le proxy intérroge la DB, fournie par l'APNF, et route sur le bon membre.
> => Si c'est pas sur un membre, alors plusieurs cas sont possibles :
> A/ L'association renvoi un code retour temporaire ou permanent sur ce
> numéro (pas routable sur l'IX);
> B/ L'association étant un GIE, et disposant de contrat de terminaison SIP
> peut router le numéro. ==> Quid de la facturation/re-facturation? Par
> contre, économie d'échelle si les contrats sont mutualisés.
> => Si le membre ne réponds pas (SIP option réguliers) alors on réponds une
> erreur temporaire. (ou on load balance sur moins d'IP si le membre a
> plusieurs SBC)
>


*Chaque provider connecté au X doit avoir une réplication de la DB. Car si
tout est géré (au niveau routage voix par le X) nous nous retrouverons dans
le même cas (plantage d'Orange) si celui-ci plante.*


*De plus, cela engendre du trafic SIP (et des réponses) pour pas grand
chose.*

*Je voyais cela plutôt:*

*- lors de l'import de la DB APNF chez le provider, celui-ci sait qui se
trouve connecté sur tel ou tel X et donc créé sa propre DB avec tel préfixe
vers tel X (donc telle IP), puis tel préfixe vers l'autre X, etc ... (cela
peut-être automatisé, voir même si on parle d'asso en plus de l'APNF,
celle-ci pourrait fournir une DB modifiée avec les préfixes quelle gère)*

*- lors d'un appel vers tel numéro hors de son réseau, la DB chez le
provider sait où envoyer au plus proche*
*- Sinon on envoie par défaut sur son transitaire voix (du genre Orange ;)
)*



>
> Dans les deux cas, ralentissement de l'établissement de quelques
> milli-secondes pour le SBC appelant, c'est largement acceptable pour
> fall-back sur un autre fournisseur.
>
> Dans le modèle IX, je préfère l'option A, qui simplifie le boulot pour
> l'asso.
>

> Et pour la croissance me direz vous?
> Là encore, deux options :
> A/ On déploie un IX dans chaque DC, en se moquant complètement de
> l'interco, c'est à dire que chaque POP est stand-alone; (coûts multipliés
> par le nombre de POP)
>
> B/ On déploie un réseau multi DC (donc plus complexe), et les membres de
> l'interco Lyon peuvent taper sur des ressources Bordeaux. Pour les SBC des
> clients, c'est simple, ils mettent une interface en /28 sur le POP, et une
> route vers la /22. (coût qui ne sont pas proportionnels au nombre de POP,
> mais besoin d'équipement L3 pour gérer le backbone).
>
> Point bonus de la solution B, le proxy peut être anycasté entre plusieurs
> POP.
>
> Dans tous les cas, l'asso ne gère pas de transcoding (les membres envoient
> le RTP de pair à pair);
> Tant que tous les membres respectent un critère simple, supporter au moins
> le G.711, tout est inter-opérable;
> Si deux membres veulent jouer avec de la visio, ou des codec de plus haute
> qualité, ça n'a aucun impact sur les autres.
> Les membres n'ont pas à avoir de connaissances BGP (je sais, on est sur
> frnog, le BGP c'est simple)
>


*100% d'accord le X ne doit pas s'embêter avec du temps réel et du
transcoding.*

*chaque provider est assez grand pour se mettre d'accord avec son
destinataire (vive le SDP)*


>
> Avec juste le proxy sur les invite (donc initiation d'appel), l'asso ne
> peut pas influer sur la qualité de la voix (mono POP).
> Celle-ci est garantie, vue que les SBC parlent entre eux sur le même
> subnet. Dans le cas d'un réseau multi-pop, c'est plus complexe.
>
> Côté revenus de l'association, les 

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

[Mickael Hubert]

Bonjour à tous,
je confirme que le problème est résolu de notre coté et voici l'info de la
part de SFR:

"Le défaut ayant impacté vos services voix fixes et mobiles est résolu.
Orange a apporté des correctifs sur leurs infrastructures et confirme à
présent que le défaut sur leurs interconnexions VoIP avec les opérateurs
est résolu. Nous sommes à présent en fonctionnement nominal sur nos
interconnexions avec Orange. Nous gardons vos services en observation
jusqu¿à demain matin et nous excusons de la gène occasionnée."

Si jamais vous avez un véritable RFO de la part d'Orange ça serait sympa de
partager

merci d'avance et bonne journée

Le 15 mai 2018 à 17:02, Alain Bieuzent <alain.bieuz...@free.fr> a écrit :

> Mail reçu a l'instant de mon ccial ORANGE : "La situation est quasiment
> totalement résolue, nous vous ferons un retour sur les causes de cet
> incident très prochainement."
>
> Bonne soirée
>
> Le 15/05/2018 11:36, « Mickael LE MOINE » <frnog-requ...@frnog.org au
> nom de fr...@realitik.com> a écrit :
>
> 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 <tray...@keyyo.com> 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]
> >>>
> >>>
> >>> <http://www.serinyatelecom.fr/signatures/evenement-
> serinyatelecom.php>
> >>>
> >>>
> >>> Le 15 mai 2018 à 10:12, Mickael Hubert <mick...@winlux.fr> 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 <david.ponz...@gmail.com>
> 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 <mick...@winlux.fr>,
> wrote:
> >>>>>
> >>>>> Bonjour à tous,
> >>>>>
> >>>>>
>

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

[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 <mailbox.fr...@gmail.com> 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 <mick...@winlux.fr> 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 <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
>> ple

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

[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 <tray...@keyyo.com> 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]
>>
>>
>> <http://www.serinyatelecom.fr/signatures/evenement-serinyatelecom.php>
>>
>>
>> Le 15 mai 2018 à 10:12, Mickael Hubert <mick...@winlux.fr> 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 <david.ponz...@gmail.com> 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 <mick...@winlux.fr>, 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 <j.oha...@xoxo.fr> 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 <david.ponz...@gmail.com> 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 <jer...@ceriz.fr> 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 c

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

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

[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 <david.ponz...@gmail.com> 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 <mick...@winlux.fr>, 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 <j.oha...@xoxo.fr> 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 <david.ponz...@gmail.com> 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 <jer...@ceriz.fr> 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

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

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

[Mickael Hubert]

En effet enum + interco sip généralisée (enfin au moins IP).
Le backup avec enum se fait très bien, on utilise ça dans notre infra.

On pourrait confier les bases enum à l'apnf...
Bon je rêve là je sais, mais ca serait enfin moderne la téléphonie... Entre
les providers ;)


Le lun. 14 mai 2018 19:41, Cedric Millet (pro)  a
écrit :

> ENUM c'est fait pour c'est un annuaire géant. Mais une fois que tu as
> déterminé quel est l'opérateur qui gère ton appel entrant, si cet opérateur
> (et ses intercos) est/sont en carafe , bah de toute façon tu ne les recois
> pas tes appels entrants... (dont ca ne résoud pas tout, mais oui ca serait
> très utile que ce soit déployer en France)
>
> Ceci dit le seul soucis est toujours le meme : qui heberge la base ENUM de
> référence et qui est responsable de la maintenir ? Après les mécanismes de
> synchro entre/avec les autres bases ENUM de chaque opérateur ce n'est pas
> un probleme, il suffit de normaliser via la FFT  - T pour Telecom pas pour
> Tennis -  Hein on n'est pas vendredi ;)
> (le sujet base ENUM y a déjà été abordé pour la VoLTE mais sans suite car
> les opérateurs doivent se mettre d'accord sur un dénominateur commun et
> biensur chacun tire la couverture de son coté, donc sans obligation légale
> via l'ARCEP (par exemple), bah ca traine des années)
>
> Déjà qu'on est pas fichu en France d'avoir une base de référence des
> numeros d'urgence par code INSEE, et qu'il faut que chaque opérateur soit
> déclaré aupres de chaque sous prefecture...
> Donc pour ces 2 besoins précédents il faudrait une base commune comme pour
> la porta et l'APNF.
>
> Xavier a raison il faudrait que l'ARCEP impose cette obligation d'un
> interlocuteur unique, pour tous ces sujets...
> PS : A ces 2 sujets on peut rajouter IPv6 dans la liste des souhaits pour
> le pere Noel :op
>
> 2018-05-14 19:05 GMT+02:00 Alexis :
>
> > Sinon, y'a enum qui est spécialement fait pour ça. C'est basé sur du DNS
> > en e164. Je vous mets le petit lien Wikipedia qui va avec :
> > https://fr.wikipedia.org/wiki/ENUM
> >
> > Clairement, avant qu'Orange annonce ses numéros dans un annuaire enum, il
> > va s'écouler trs longtemps. Mais c'est mieux que rien et c'est
> > assez basique comme fonctionnement :)
> >
> > Alexis Prodhomme
> >
> > Le 14/05/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 ?
> >>
> >>
> >
> > ---
> > 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

[Mickael Hubert]

Re,
une certaine amélioration, mais ce n'est pas du tout folichon...
Ex: dés que je passe par le réseau Orange pas de terminaison du tout ou pas
de son.

++

Le 14 mai 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/

Re: [FRnOG] [MISC] VIAMICHELIN : Hack Google AdWords - Voxbone

[Mickael Hubert]

la réponse de Voxbone ;)

"Hi, this info will be sent to h...@voxbone.com. We have strict rules for
companies using our lines and will investigate fully. Thank you for
bringing this to our attention."

Le 4 décembre 2017 à 14:53, Xavier ROCA <x.r...@sipleo.com> a écrit :

> Bonjour,
>
> Je détourne un peu la discussion mais à chaque fois que l'on a eu un
> client via une page web de type d'Alerte virus... qui s'est fait arnaqué ou
> a subi une tentative et que l'on a pu remonter au numéro.
> C'était un numéro délivré par Voxbone à 100% (peut-être pas de bol).
> Je parle également de numéro géographique qui impose certain contrôle
> avant de le délivrer.
>
> Messieurs de Voxbone, je sais que vous trainait par là et je vous pense de
> bonne foi.
> Donc ce petit mail pour attirer votre attention si besoin.
> Je ne sais pas quel est votre mode d'attribution de numéros mais ils ont
> trouvés le moyens de passer vos contrôles assez facilement.
> Il serait peut-être intéressant de "revoir" votre mode d'attribution et si
> ce dernier est sécure de pouvoir transmettre aux services de l'état les
> éléments en votre possession dans de tel cas, si ce n'est pas déjà le cas.
> Il y a peut-être un de vos clients qui lui "loue" vos numéros sans trop se
> préoccuper du client et des vérifications à établir.
>
> Ou idéalement entre nous pour faciliter le dépôt de plainte de nos
> clients, si cela est envisageable ce serait bien.
>
> Surtout pour faciliter le travail de police derrière car la procédure peut
> prendre sinon tellement de temps que ces malfrats ne sont déjà plus là.
> Malheureusement, ce type d'arnaque, la plupart du temps, marche assez
> facilement sur des personnes plus fragiles moins aguerries au numérique.
> C'est tout sauf cool, en plus, ils n'osent pas le dire, porter plainte, la
> peur de paraitre idiot ou le sentiment que cela ne servira à rien.
>
> Mes 2cts
>
> Xavier
>
>
>
> -Message d'origine-
> De : Mickael Hubert [mailto:mick...@winlux.fr]
> Envoyé : lundi 4 décembre 2017 10:26
> À : frnog-al...@frnog.org
> Objet : Re: [FRnOG] [ALERT] VIAMICHELIN : Hack Google AdWords
>
> Salut à tous,
> Encore un numéro Voxbone.
>
> Je vais les recontacter par email comme la dernière fois. Ils ont été
> plutôt réactif.
>
> ++
>
> 2017-12-04 10:18 GMT+01:00 Jean-Pierre Ramoul <jpram...@gmail.com>:
>
> > Pour info :
> > https://voiprovider.wordpress.com/2017/11/19/une-fraude-
> > particulierement-bien-realisee/
> >
> > ​
> >
> > ---
> > 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] VIAMICHELIN : Hack Google AdWords

[Mickael Hubert]

Salut à tous,
Encore un numéro Voxbone.

Je vais les recontacter par email comme la dernière fois. Ils ont été
plutôt réactif.

++

2017-12-04 10:18 GMT+01:00 Jean-Pierre Ramoul :

> Pour info :
> https://voiprovider.wordpress.com/2017/11/19/une-fraude-
> particulierement-bien-realisee/
>
> ​
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] Grosse panne OVH ce matin

[Mickael Hubert]

Salut
A priori ça remonte doucement (du moins chez kimsufi) ;)

Le 9 novembre 2017 à 10:17, Jules-Henri Gavetti  a
écrit :

> Salut,
>
> Moi je pense aux équipes techniques, c'est une véritable épreuve
> psychologique.
>
> Bon courage
>
> Jules
>
> -Message d'origine-
> De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part
> de Dominique Rousseau
> Envoyé : jeudi 9 novembre 2017 09:54
> À : frnog@frnog.org
> Objet : Re: [FRnOG] [TECH] Grosse panne OVH ce matin
>
> Le Thu, Nov 09, 2017 at 09:32:20AM +0100, Julien Escario [
> esca...@azylog.net] a écrit:
> > Bonjour,
> > Ca ne vaut probablement pas trop le coup de faire les kékés sur cette
> liste.
>
> +1
> Je pense que pas grand monde ici n'a des infra du ampleur comparable a
> celles d'OVH pour pouvoir donner son avis...
>
> > Je ne vous rappelle qu'un truc : Redbus, 2006. Nous étions nombreux à
> > ne pas faire les malins à cette époque.
>
> J'espere pour eux qu'ils auront assez de café et un bbq (crepes, whatever,
> hein ;-)  pour se reconforter apres.
>
> > Courage aux équipes d'Oles qui doivent bien être sous pression avec
> > une obligation de résultat (rapide) dans une situation déjà bien
> > dégradée. Et aux autres qui font le support pour les clients qui ne
> savent plus vers qui se tourner.
>
> Carrement, bon courage a ceux qui sont sur le pont, et a tous ceux qui
> vont devoir repondre aux clients.
>
>
> --
> Dominique Rousseau
> Neuronnexion, Prestataire Internet & Intranet
> 21 rue Frédéric Petit - 8 Amiens
> tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
>
>
> ---
> 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] [BIZ] Solution SIP pour Opérateur

[Mickael Hubert]

ha oui aussi ne pas oublier la législation ! surtout si tu commences à
mutualiser les trunk. (1 gros trunk chez un transitaire, puis multi-trunk
pour tes clients finaux).
Le côté fun de la téléphonie : interception légale, cdr, numéros
d'urgence

On Feb 28, 2017 7:02 AM, "Mickael Hubert" <mick...@winlux.fr> wrote:

salut
ca dépend des compétences.
mais un jumelage entre freeswitch + opensips (ou kamalio).
très puissant pour la partie interopérabilité SIP.

après, certains clients ou transitaires n'apprécient que moyennement l'Open
Sources, même maîtrisé.

bon courage


On Feb 22, 2017 8:49 PM, "Christophe Jeannerot" <christo...@jeannerot.fr>
wrote:

Bonjour

Chez nous on utilise MOR de Kolmisoft, très bon rapport qualité prix :)

Envoyé de mon iPad

> Le 22 févr. 2017 à 08:18, sofiane jalid <sorichcan...@gmail.com> a écrit :
>
> Oui effectivement ;)
>
> Le 22 févr. 2017 08:15, "David Ponzone" <david.ponz...@gmail.com> a écrit
:
>
>> Non tu a bien fait mais il devrait peut-être appeler Centile non ?
>> Je doute que Keyyo donne des conseils gratuits pour un futur concurrent
:)
>> Surtout, si c’est de la bouse, je doute qu’ils le disent ouvertement.
>> Pareil si c’est la solution du siècle qui leur donne un fort avantage
>> concurrentiel.
>>
>> Sinon, y a ACME, Sonus, Metaswitch, Italtel peut-être, Cirpack, Sangoma,
>> Audiocodes, Squire, etc…
>> Ils n’ont pas tous la partie OSS/BSS, donc il faut greffer un produit
>> partenaire, et l’ardoise augmente.
>>
>> Plus toutes les solutions OpenSource basées sur Asterisk ou FreeSWITCH.
>> Là, Google donne facilement la liste.
>>
>> Note: si tu as un Centile, tu n’es plus un switchless.
>> Switchless, c’est les gens qui font une activité de voix (presel
>> historiquement) sans matériel, donc qui ne font qu’utiliser les services
>> wholesale des gros comme Verizon, SFR, Colt, voir Orange etc...
>>
>> Le 22 févr. 2017 à 00:29, sofiane jalid <sorichcan...@gmail.com> a écrit
:
>>
>> Ahaha Je n'ai pas dit que keyyo offrait un sbc equivalent genre acme,
>> audiocode oû un cirpack... où quelques choses de ce genre.
>>
>> Ne m'inventait pas une réponse please..
>>
>> Je lui proposé plustot de s'orienter vers eux afin qu'il ai un avis clair
>> et plustot pro point.
>>
>> Un switchless type centile qui est plustot bien abouti et niveau prix
>> d'entrée très rentable si ses clients n'ont pas de grand besoin ni
>> d'equipement proprietaire sur place. d'où mon questionnement.
>>
>> Maintenant ne connaissant pas son parc existant vu le peu de détail et la
>> necessité des interco SIP avec ses clients je réponds ? Je suis bon pour
le
>> pilori ?
>>
>> Sofiane
>>
>> Le 21 févr. 2017 23:57, "David Ponzone" <david.ponz...@gmail.com> a
>> écrit :
>>
>>> Ah bon ? Keyyo vend un logiciel de SIP Trunking/SBC/Billing ?
>>>
>>>
>>>
>>> Le 21 févr. 2017 à 23:20, sofiane jalid <sorichcan...@gmail.com> a écrit
>>> :
>>>
>>> Bonsoir
>>>
>>> Va voir du coté de keyyo...
>>>
>>> Cdt
>>>
>>>
>>> Sofiane
>>>
>>> Le 21 févr. 2017 23:09, "Tristan Mahé" <g...@remote-shell.net> a écrit :
>>>
>>> Hello Lucas,
>>>
>>> tout dépends le besoin, comme pour tout, si ton but est de faire
>>> uniquement du postpaid, ou du cc/prepaid, ou de fournir du vpbx, etc...
>>>
>>> Sur du opensource based, tu peux regarder du côté de Kazoo de 2600Hz,
>>> c'est bien maintenu et les gars sont sérieux, de bons retours de la
>>> communauté depuis quelques temps...
>>>
>>> On 02/20/2017 05:54 AM, Lucas Viallon wrote:
>>>
>>> Bonjour,
>>>
>>> J'ai besoin d'une petite info, on dispose de trunk sip opérateur pour
nos
>>> besoins internes. Ils sont connectés sur une simple machine virtuelle
>>> Asterisk.
>>>
>>> Aujourd'hui, on a des clients qui nous demandent de leur fournir des
>>> trunks SIP, je cherche a savoir ce qui est utilisé actuellement  dans la
>>> profession pour faire le lien entre les trunk sip opérateur et les
trunks
>>> SIP client.
>>>
>>> En gros, exist'il une solution soft qui permet de gerer cela ? surtout
au
>>> niveau de la facturation des communications.
>>>
>>> merci d'avance
>>> Lucas
>>>
>>>
>>>
>>>
>>> ---
>>> 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] [BIZ] Solution SIP pour Opérateur

[Mickael Hubert]

salut
ca dépend des compétences.
mais un jumelage entre freeswitch + opensips (ou kamalio).
très puissant pour la partie interopérabilité SIP.

après, certains clients ou transitaires n'apprécient que moyennement l'Open
Sources, même maîtrisé.

bon courage


On Feb 22, 2017 8:49 PM, "Christophe Jeannerot" 
wrote:

Bonjour

Chez nous on utilise MOR de Kolmisoft, très bon rapport qualité prix :)

Envoyé de mon iPad

> Le 22 févr. 2017 à 08:18, sofiane jalid  a écrit :
>
> Oui effectivement ;)
>
> Le 22 févr. 2017 08:15, "David Ponzone"  a écrit
:
>
>> Non tu a bien fait mais il devrait peut-être appeler Centile non ?
>> Je doute que Keyyo donne des conseils gratuits pour un futur concurrent
:)
>> Surtout, si c’est de la bouse, je doute qu’ils le disent ouvertement.
>> Pareil si c’est la solution du siècle qui leur donne un fort avantage
>> concurrentiel.
>>
>> Sinon, y a ACME, Sonus, Metaswitch, Italtel peut-être, Cirpack, Sangoma,
>> Audiocodes, Squire, etc…
>> Ils n’ont pas tous la partie OSS/BSS, donc il faut greffer un produit
>> partenaire, et l’ardoise augmente.
>>
>> Plus toutes les solutions OpenSource basées sur Asterisk ou FreeSWITCH.
>> Là, Google donne facilement la liste.
>>
>> Note: si tu as un Centile, tu n’es plus un switchless.
>> Switchless, c’est les gens qui font une activité de voix (presel
>> historiquement) sans matériel, donc qui ne font qu’utiliser les services
>> wholesale des gros comme Verizon, SFR, Colt, voir Orange etc...
>>
>> Le 22 févr. 2017 à 00:29, sofiane jalid  a écrit
:
>>
>> Ahaha Je n'ai pas dit que keyyo offrait un sbc equivalent genre acme,
>> audiocode oû un cirpack... où quelques choses de ce genre.
>>
>> Ne m'inventait pas une réponse please..
>>
>> Je lui proposé plustot de s'orienter vers eux afin qu'il ai un avis clair
>> et plustot pro point.
>>
>> Un switchless type centile qui est plustot bien abouti et niveau prix
>> d'entrée très rentable si ses clients n'ont pas de grand besoin ni
>> d'equipement proprietaire sur place. d'où mon questionnement.
>>
>> Maintenant ne connaissant pas son parc existant vu le peu de détail et la
>> necessité des interco SIP avec ses clients je réponds ? Je suis bon pour
le
>> pilori ?
>>
>> Sofiane
>>
>> Le 21 févr. 2017 23:57, "David Ponzone"  a
>> écrit :
>>
>>> Ah bon ? Keyyo vend un logiciel de SIP Trunking/SBC/Billing ?
>>>
>>>
>>>
>>> Le 21 févr. 2017 à 23:20, sofiane jalid  a écrit
>>> :
>>>
>>> Bonsoir
>>>
>>> Va voir du coté de keyyo...
>>>
>>> Cdt
>>>
>>>
>>> Sofiane
>>>
>>> Le 21 févr. 2017 23:09, "Tristan Mahé"  a écrit :
>>>
>>> Hello Lucas,
>>>
>>> tout dépends le besoin, comme pour tout, si ton but est de faire
>>> uniquement du postpaid, ou du cc/prepaid, ou de fournir du vpbx, etc...
>>>
>>> Sur du opensource based, tu peux regarder du côté de Kazoo de 2600Hz,
>>> c'est bien maintenu et les gars sont sérieux, de bons retours de la
>>> communauté depuis quelques temps...
>>>
>>> On 02/20/2017 05:54 AM, Lucas Viallon wrote:
>>>
>>> Bonjour,
>>>
>>> J'ai besoin d'une petite info, on dispose de trunk sip opérateur pour
nos
>>> besoins internes. Ils sont connectés sur une simple machine virtuelle
>>> Asterisk.
>>>
>>> Aujourd'hui, on a des clients qui nous demandent de leur fournir des
>>> trunks SIP, je cherche a savoir ce qui est utilisé actuellement  dans la
>>> profession pour faire le lien entre les trunk sip opérateur et les
trunks
>>> SIP client.
>>>
>>> En gros, exist'il une solution soft qui permet de gerer cela ? surtout
au
>>> niveau de la facturation des communications.
>>>
>>> merci d'avance
>>> Lucas
>>>
>>>
>>>
>>>
>>> ---
>>> 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] [TECH] Trunk SIP (REGISTER) avec un Alcatel OXE

[Mickael Hubert]

Hey un grand merci à toi, Google n'a pas été à la hauteur pour moi :( j'ai
bien trouvé de la doc Orange mais jamais avec REGISTER ;)
Mais tu as raison, vendredi est très proche, vu que ce sera jeudi ;)

Bonne soirée



Le 8 novembre 2016 à 17:57, David Ponzone <david.ponz...@gmail.com> a écrit
:

> T’as cherché un peu sur Google ou c’est déjà vendredi ? :)
>
> http://www.orange-business.com/files/axiome/130941/doc/
> Business%20Internet%20Voix/Presentation%20de%20loffre/en%20bref/OXE_R11.1_
> Configuration_Guideline_for_BIV_SIP_v1.3.pdf
>
>
>
>
> Le 8 nov. 2016 à 17:25, Mickael Hubert <mick...@winlux.fr> a écrit :
>
> Bonjour à tous,
> j'ai une petite question sur l'interco d'un OXE vers mon SBC SIP.
> En gros, le mainteneur m'explique qu'il est impossible pour un OXE de se
> REGISTER vers un provider SIP.
> Il n'y que la possibilité d'un trunk SIP IP to IP (sans authentification ou
> REGISTER).
>
> Confirmez-vous cela où est-ce possible de REGISTER un OXE ? Si oui, avec
> vous une petite doc  svp ?
>
> Un grand merci d'avance
>
> *Version de l'OXE: OmniPCX Enterprise R11.0.1 k1.520.22.b*
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>
>

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

[FRnOG] [TECH] Trunk SIP (REGISTER) avec un Alcatel OXE

[Mickael Hubert]

Bonjour à tous,
j'ai une petite question sur l'interco d'un OXE vers mon SBC SIP.
En gros, le mainteneur m'explique qu'il est impossible pour un OXE de se
REGISTER vers un provider SIP.
Il n'y que la possibilité d'un trunk SIP IP to IP (sans authentification ou
REGISTER).

Confirmez-vous cela où est-ce possible de REGISTER un OXE ? Si oui, avec
vous une petite doc  svp ?

Un grand merci d'avance

*Version de l'OXE: OmniPCX Enterprise R11.0.1 k1.520.22.b*

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

Re: [FRnOG] [TECH] service-policy output Cisco

[Mickael Hubert]

Re,
Faire du shaping en incoming, c'est bizarre pour moi (pour de l'UDP
j'entends). Mais si vous y arrivez, je suis preneur de la conf svp ;)

merci d'avance

Le 27 octobre 2016 à 12:40, Sébastien 65 <sebastien...@live.fr> a écrit :

> Bonjour Mickael,
>
>
> Il est à première vue possible de le faire sur du 3650.
>
>
> ----------
> *De :* Mickael Hubert <mick...@winlux.fr>
> *Envoyé :* jeudi 27 octobre 2016 12:21:06
> *À :* Sébastien 65
> *Cc :* David Ponzone; frnog-t...@frnog.org
>
> *Objet :* Re: [FRnOG] [TECH] service-policy output Cisco
>
> Bonjour à tous,
> en effet ce genre de chose ne se fait (à ma connaissance) qu'en upload sur
> l'équipement. Comme le dit David, en UDP c'est mort, tu n'as pas de notion
> de taille de fenêtre, etc ...
> le paquet UDP arrive sur ton interface mais c'est déjà trop tard pour le
> contrôle de bande passante.
>
> Si tu contrôles les deux extrémités du réseau (les deux switchs),
> travailles sur du service policy (ou autre mécanisme) en output de chaque
> coté.
> En tout cas cela fonctionne pour nous sur nos PE et CPE en output
> uniquement pour de la QOS voip.
>
> Cordialement
>
> Le 20 octobre 2016 à 18:52, Sébastien 65 <sebastien...@live.fr> a écrit :
>
>> Oui tu as raison... Mon cas est la mise en place d'une limitation de bp
>> sur un port donné rien de plus...  Il existe srr-queue mais la je planche
>> sur une façon de faire de l'asymétrie sur un port en quelque sorte 10M en
>> down et 2M en up... J'me disais qu'avec service-policy dans les deux sens
>> cela pouvait matcher
>> 
>> De : David Ponzone <david.ponz...@gmail.com>
>> Envoyé : jeudi 20 octobre 2016 18:45:47
>> À : Sébastien 65
>> Cc : frnog-t...@frnog.org
>> Objet : Re: [FRnOG] [TECH] service-policy output Cisco
>>
>> Il y a plein de littérature sur le sujet, mais en gros, tu ne peux pas
>> réellement mitiger du trafic qui est déjà arrivé à l'entrée de ton
>> interface...
>> Ca marchera un peu avec TCP à cause des mécanismes inclus dans le
>> protocole (mais essaie de mitiger du Windows Update comme ça, on va
>> rigoler), mais avec UDP, ça va pas le faire.
>>
>>
>> Le 20 oct. 2016 à 18:43, Sébastien 65 <sebastien...@live.fr> ebastien...@live.fr>> a écrit :
>>
>> En input je n'ai pas constaté de problème, peux tu développer le fond de
>> ta pensée ?
>> 
>> De : David Ponzone <david.ponz...@gmail.com> david.ponz...@gmail.com>>
>> Envoyé : jeudi 20 octobre 2016 18:40:41
>> À : Sébastien 65
>> Cc : frnog-t...@frnog.org<mailto:frnog-t...@frnog.org>
>> Objet : Re: [FRnOG] [TECH] service-policy output Cisco
>>
>> En input, aucun ne pourra le faire réellement efficacement :)
>>
>>
>> > Le 20 oct. 2016 à 18:29, Sébastien 65 <sebastien...@live.fr> ebastien...@live.fr>> a écrit :
>> >
>> > Bonsoir,
>> >
>> > Je cherche un switch Cisco capable de me gérer la commande
>> service-policy en output sans me faire insulter :)
>> >
>> > Déjà est-ce possible sur un switch ? Si oui quels sont les modèles
>> capable de gérer une policy en Input/Output sur une interface...
>> >
>> > Merci pour les renseignements.
>> >
>> > ---
>> > 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] [TECH] service-policy output Cisco

[Mickael Hubert]

Bonjour à tous,
en effet ce genre de chose ne se fait (à ma connaissance) qu'en upload sur
l'équipement. Comme le dit David, en UDP c'est mort, tu n'as pas de notion
de taille de fenêtre, etc ...
le paquet UDP arrive sur ton interface mais c'est déjà trop tard pour le
contrôle de bande passante.

Si tu contrôles les deux extrémités du réseau (les deux switchs),
travailles sur du service policy (ou autre mécanisme) en output de chaque
coté.
En tout cas cela fonctionne pour nous sur nos PE et CPE en output
uniquement pour de la QOS voip.

Cordialement

Le 20 octobre 2016 à 18:52, Sébastien 65  a écrit :

> Oui tu as raison... Mon cas est la mise en place d'une limitation de bp
> sur un port donné rien de plus...  Il existe srr-queue mais la je planche
> sur une façon de faire de l'asymétrie sur un port en quelque sorte 10M en
> down et 2M en up... J'me disais qu'avec service-policy dans les deux sens
> cela pouvait matcher
> 
> De : David Ponzone 
> Envoyé : jeudi 20 octobre 2016 18:45:47
> À : Sébastien 65
> Cc : frnog-t...@frnog.org
> Objet : Re: [FRnOG] [TECH] service-policy output Cisco
>
> Il y a plein de littérature sur le sujet, mais en gros, tu ne peux pas
> réellement mitiger du trafic qui est déjà arrivé à l'entrée de ton
> interface...
> Ca marchera un peu avec TCP à cause des mécanismes inclus dans le
> protocole (mais essaie de mitiger du Windows Update comme ça, on va
> rigoler), mais avec UDP, ça va pas le faire.
>
>
> Le 20 oct. 2016 à 18:43, Sébastien 65 > a écrit :
>
> En input je n'ai pas constaté de problème, peux tu développer le fond de
> ta pensée ?
> 
> De : David Ponzone  >>
> Envoyé : jeudi 20 octobre 2016 18:40:41
> À : Sébastien 65
> Cc : frnog-t...@frnog.org
> Objet : Re: [FRnOG] [TECH] service-policy output Cisco
>
> En input, aucun ne pourra le faire réellement efficacement :)
>
>
> > Le 20 oct. 2016 à 18:29, Sébastien 65 > a écrit :
> >
> > Bonsoir,
> >
> > Je cherche un switch Cisco capable de me gérer la commande
> service-policy en output sans me faire insulter :)
> >
> > Déjà est-ce possible sur un switch ? Si oui quels sont les modèles
> capable de gérer une policy en Input/Output sur une interface...
> >
> > Merci pour les renseignements.
> >
> > ---
> > 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: [MISC] [FRnOG] Problèmatique R1R2 et P-ANI

[Mickael Hubert]

Bonsoir à tous,
Pour info j'ai fait une conf call avec l'arcep qui nous expliquent qu'ils
ont bloqué l'attribution de R1R2 car bientôt plus de dispo...
En // ils ont envoyés une com officielle à Orange pour leurs demander une
explication sur leurs utilisation du R1R2.

Si vous n'avez pas de code et que votre fournisseur vous impose une hausse
de tarifs, il faut prévenir l'arcep et

Wait and see...

On Oct 6, 2016 8:57 AM, "David Ponzone"  wrote:

> David,
>
> oui, cela est sous-entendu dans le document de l’ARCEP (d’ailleurs, on
> sent bien dans les Annexes l’insistance de certains opérateurs, non-nommés,
> pour avoir cette information de localisation).
> Maintenant, Orange a défini sur une interco SIP (natif) le champ P-ANI
> pour jouer ce rôle.
> Mais les modalités d’interco SIP d’Orange découlant directement du
> document de la FFT, je suis surpris dans le document de la FFT (très
> recent) le champ P-ANI ne soit cité que dans le chapitre sur les appels
> vers les SVA, alors qu’Orange a défini que cela ne concernait que les
> appels vers Z=6,7 depuis Z=9.
> Qu’il y ait des particularités chez Orange, ok, mais là, c’est plus qu’une
> petite différence, et je n’arrive pas à savoir comment interpréter ceci.
>
> > Le 5 oct. 2016 à 22:31, David  a écrit :
> >
> > Bonjour,
> >
> > Le R1R2 / PANI est nécessaire pour avoir accès au tarif régulé sur la
> terminaison mobile pour un appel provenant d'un numéro non géographique
> > En gros si tu positionnes le PANI tu payes 0,0111 € la minute vers un
> mobile Orange, si tu ne mets rien tu es à 0,0465€...
> >
> > Je vous invites à lire les dernières conditions spécifiques IP Connexion
> Voix d'Orange
> >
> > Cdt,
> >
> > David
> >
> >
> > -Message d'origine-
> > De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la
> part de David Ponzone
> > Envoyé : mercredi 5 octobre 2016 17:40
> > À : Christophe ASSENS 
> > Cc : Frnog misc 
> > Objet : [MISC] Re: [FRnOG] Problèmatique R1R2 et P-ANI
> >
> > J’ai un peu potassé et si je comprends bien:
> > l’ARCEP a pondu un truc super il y a quelques années, le R1R2
> http://www.arcep.fr/uploads/tx_gsavis/05-0521.pdf
> >
> > Globalement peu utilisé jusqu’à maintenant, ça permet d’envoyer
> l’identification de l’opérateur émettant l’appel et le code insee de
> l’appelant, quand le numéro de l’appelant est non-géographique. Ceci étant
> réservé aux intercos SPIROU, je vois mal l’intérêt du R1R2 puisque on le
> connait l’opérateur qui envoie l’appel, à priori.
> > Et pourquoi cette limitation à 2 chiffres dès le départ ? On estime déjà
> qu’il n’y aura que 50 opérateurs fixe qui voudront envoyer des appels à
> Orange avec un numéro non-géo appelant ? Pourquoi une telle limitation
> alors qu’il n’y a pas presque pas de limitation en SPIROU aux nombres
> d’opérateurs qui peuvent monter une interco avec Orange, et aucune en SIP...
> > Et pourquoi avoir choisi R1R2C1C2C3C4C5XX plutôt que R1R2XXC1C2C3C4C5 ?
> Si finalement XX est utilisé un jour pour faire un R3R4, ça serait pas plus
> mal que ça soit à la suite de R1R2, mais bon, il doit y avoir des
> contraintes que je connais pas.
> > J’ai beau lire les retours Opérateur dans le doc de l’ARCEP, je n’arrive
> pas à distinguer des arguments clairs sur les choix qui ont été faits.
> >
> > Ensuite, la FFT a repris le R1R2C1C2C3C4C5XX mais cette fois comme un
> champ SIP qu’on doit envoyer quand on appelle un SVA (donc je suppose qu’on
> parle d’interco directe vers un fournisseur de SVA), depuis donc n’importe
> quel type de numéro.
> > Donc alors que l’ARCEP dans son document présupposait qu’un numéro dont
> Z=[1-5] est localisable par son ZABPQ (puisque les ZNE existent toujours
> pour le moment), et donc ne nécessite pas le R1R2C1C2C3C4C5XX (ils disent
> même carrément que les R1R2 sont réservés aux opérateurs qui présentent des
> 0870….oui le doc date un peu et n’a pas été remis à jour), la FFT elle nous
> dit que même pour un ZABPQMCDU localisable par sa ZNE, il faut quand même
> envoyer le R1R2C1C2C3C4C5XX.
> >
> > C’est pas un peu confus tout ça ou c’est le vendredi qui approche ?
> >
> >
> >> Le 5 oct. 2016 à 11:10, Christophe ASSENS  a écrit :
> >>
> >> Oui je te confirme que il faudrait corriger le doc FFT et que on a bien
> une réutilisation de ce header pour la localisation des numéros non
> géographique.
> >>
> >> Concrètement ça touche les A-Number 336 à 339 qui doivent être
> localisés.
> >>
> >> Quand tu vois qu'il y eu 15 attributions de R1R2 entre Juillet et
> >> Aout, c'est clair que c'est pas 15 opérateurs qui se sont mis à faire
> >> du SVA :-)
> >>
> >> Bref nous on a eu le notre donc on est content, ouf!, et Orange nous
> informe que dès 2017 ils vont encore plus renforcer le dispositif de
> billing basé sur P-ANI et ça va devenir de plus en plus compliqué car il
> n'y a plus de R1R2 dispos !
> >>
> >>
> >> Le 4 octobre 2016 à 14:10, David 

Re: [FRnOG] [ALERT] Problème de friture sur la ligne

[Mickael Hubert]

ça m'a l'air mieux en effet...


​

Le 5 avril 2016 à 15:26, Alain Bieuzent <alain.bieuz...@free.fr> a écrit :

> d’après mes tests et mes graphs, pour moi c'est ok :
>
>
>
> Le 05/04/2016 15:20, Thomas Bardin a écrit :
>
> oui mais en fait, non c'est pas résolu...
>
> Le 5 avril 2016 à 15:03, Alain Bieuzent <alain.bieuz...@free.fr> a écrit :
>
>> Dernier retour a mon ticket SFR :
>> " Bonjour, plus d'impact temporairement suite a modification de regles
>> sur un equipement de notre support IP à 14h20 . Nous vous tiendrons
>> informés de la suite de nos investigations .Cdt'
>>
>>
>>
>> Le 05/04/2016 14:31, Mickael Hubert a écrit :
>> > Bonjour à tous,
>> > idem chez nous (interco SIP Divop).
>> > Problème de pertes de paquets sur les deux clusters de SBC chez SFR.
>> >
>> > Cordialement
>> >
>> > Le 5 avril 2016 à 12:28, David RIBEIRO < <david.ribeir...@gmail.com>
>> david.ribeir...@gmail.com
>> > <mailto:david.ribeir...@gmail.com>> a écrit :
>> >
>> > Bonjour,
>> >
>> > Idem chez nous, client de l'offre Business Synchro (Solution FIXE
>> > BYTEL by
>> > Completel).
>> > Constat :
>> >
>> >- Appel en Interne OK
>> >- Appel sortant vers BYTEL légèrement hachuré.
>> >- Appel sortant vers Lasotel légèrement hachuré.
>> >- Aucun souci constaté sur les appels entrants.
>> >
>> > David
>> >
>> > Le 5 avril 2016 à 12:22, David Ponzone < <david.ponz...@gmail.com>
>> david.ponz...@gmail.com
>> > <mailto:david.ponz...@gmail.com>> a écrit :
>> >
>> > > Ben c’est normal, ça passe par le Panama…
>> > >
>> > >
>> > > > Le 5 avr. 2016 à 12:17, Alain Bieuzent <alain.bieuz...@free.fr
>> > <mailto:alain.bieuz...@free.fr>> a écrit
>> > > :
>> > > >
>> > > > Hello la liste,
>> > > >
>> > > > je confirme pour SFR et même défaut chez Completel.
>> > > >
>> > > > A+
>> > > >
>> > > > Le 05/04/2016 12:10, Xavier ROCA a écrit :
>> > > >> Bonjour,
>> > > >>
>> > > >>
>> > > >>
>> > > >> Nous constatons depuis quelques minutes de nombreuses
>> > remontés clients
>> > > >> signalant une dégradation type friture.
>> > > >>
>> > > >> Aucune perte de paquet réseau n’est présente. L’audio arrive
>> > abimés.
>> > > >>
>> > > >>
>> > > >>
>> > > >> Que sur les appels sortants.
>> > > >>
>> > > >> Un de nos confrères a aussi le même défaut
>> > > >>
>> > > >> Le point commun semble être SFR.
>> > > >>
>> > > >>
>> > > >>
>> > > >> Il y en a d’autres ?
>> > > >>
>> > > >>
>> > > >>
>> > > >> Cordialement
>> > > >>
>> > > >>
>> > > >>
>> > > >>
>> > > >>
>> > > >> Xavier
>> > > >>
>> > > >>
>> > > >> ---
>> > > >> 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/
>> > >
>> >
>> >
>> >
>> > --
>> > David
>> >
>> > ---
>> > Liste de diffusion du FRnOG
>> > http://www.frnog.org/
>> >
>> >
>> >
>> >
>> > --
>> > Cordialement
>> >
>> > HUBERT Mickaël
>> > Ingénieur VOIP - Hexanet
>> >
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>
>
>


-- 
Cordialement

HUBERT Mickaël
Ingénieur VOIP - Hexanet

-- 

Re: [FRnOG] [ALERT] Problème de friture sur la ligne

[Mickael Hubert]

Retour SFR:

*5 avr. 2016 15:09*


*Action corrective effectuée par nos supports à 14h20.Pouvez-vous faire des
tests et de nous confirmer ou pas le rétablissement des services
?Cordialement STC SFR*
  *5 avr. 2016 14:52* *Bonjour, plus d'impact temporairement suite a
modification de regles sur un equipement de notre support IP à 14h20 . Nous
vous tiendrons informés de la suite de nos investigations .Cdt *

Mais je confirme que non ce n'est tjs pas réglé de notre coté.
2 clients nous remontent encore des problèmes (tickets ouvert chez nous il
y a moins de 10 mins)

Cordialement

Le 5 avril 2016 à 15:03, Alain Bieuzent <alain.bieuz...@free.fr> a écrit :

> Dernier retour a mon ticket SFR :
> " Bonjour, plus d'impact temporairement suite a modification de regles
> sur un equipement de notre support IP à 14h20 . Nous vous tiendrons
> informés de la suite de nos investigations .Cdt'
>
>
>
> Le 05/04/2016 14:31, Mickael Hubert a écrit :
>
> Bonjour à tous,
> idem chez nous (interco SIP Divop).
> Problème de pertes de paquets sur les deux clusters de SBC chez SFR.
>
> Cordialement
>
> Le 5 avril 2016 à 12:28, David RIBEIRO <david.ribeir...@gmail.com> a
> écrit :
>
>> Bonjour,
>>
>> Idem chez nous, client de l'offre Business Synchro (Solution FIXE BYTEL by
>> Completel).
>> Constat :
>>
>>- Appel en Interne OK
>>- Appel sortant vers BYTEL légèrement hachuré.
>>- Appel sortant vers Lasotel légèrement hachuré.
>>- Aucun souci constaté sur les appels entrants.
>>
>> David
>>
>> Le 5 avril 2016 à 12:22, David Ponzone < <david.ponz...@gmail.com>
>> david.ponz...@gmail.com> a écrit :
>>
>> > Ben c’est normal, ça passe par le Panama…
>> >
>> >
>> > > Le 5 avr. 2016 à 12:17, Alain Bieuzent < <alain.bieuz...@free.fr>
>> alain.bieuz...@free.fr> a écrit
>> > :
>> > >
>> > > Hello la liste,
>> > >
>> > > je confirme pour SFR et même défaut chez Completel.
>> > >
>> > > A+
>> > >
>> > > Le 05/04/2016 12:10, Xavier ROCA a écrit :
>> > >> Bonjour,
>> > >>
>> > >>
>> > >>
>> > >> Nous constatons depuis quelques minutes de nombreuses remontés
>> clients
>> > >> signalant une dégradation type friture.
>> > >>
>> > >> Aucune perte de paquet réseau n’est présente. L’audio arrive abimés.
>> > >>
>> > >>
>> > >>
>> > >> Que sur les appels sortants.
>> > >>
>> > >> Un de nos confrères a aussi le même défaut
>> > >>
>> > >> Le point commun semble être SFR.
>> > >>
>> > >>
>> > >>
>> > >> Il y en a d’autres ?
>> > >>
>> > >>
>> > >>
>> > >> Cordialement
>> > >>
>> > >>
>> > >>
>> > >>
>> > >>
>> > >> Xavier
>> > >>
>> > >>
>> > >> ---
>> > >> 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/
>> >
>>
>>
>>
>> --
>> David
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>
>
>
> --
> Cordialement
>
> HUBERT Mickaël
> Ingénieur VOIP - Hexanet
>
>
>


-- 
Cordialement

HUBERT Mickaël
Ingénieur VOIP - Hexanet

-- 


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

Re: [FRnOG] [ALERT] Problème de friture sur la ligne

[Mickael Hubert]

Bonjour à tous,
idem chez nous (interco SIP Divop).
Problème de pertes de paquets sur les deux clusters de SBC chez SFR.

Cordialement

Le 5 avril 2016 à 12:28, David RIBEIRO  a écrit :

> Bonjour,
>
> Idem chez nous, client de l'offre Business Synchro (Solution FIXE BYTEL by
> Completel).
> Constat :
>
>- Appel en Interne OK
>- Appel sortant vers BYTEL légèrement hachuré.
>- Appel sortant vers Lasotel légèrement hachuré.
>- Aucun souci constaté sur les appels entrants.
>
> David
>
> Le 5 avril 2016 à 12:22, David Ponzone  a écrit :
>
> > Ben c’est normal, ça passe par le Panama…
> >
> >
> > > Le 5 avr. 2016 à 12:17, Alain Bieuzent  a
> écrit
> > :
> > >
> > > Hello la liste,
> > >
> > > je confirme pour SFR et même défaut chez Completel.
> > >
> > > A+
> > >
> > > Le 05/04/2016 12:10, Xavier ROCA a écrit :
> > >> Bonjour,
> > >>
> > >>
> > >>
> > >> Nous constatons depuis quelques minutes de nombreuses remontés clients
> > >> signalant une dégradation type friture.
> > >>
> > >> Aucune perte de paquet réseau n’est présente. L’audio arrive abimés.
> > >>
> > >>
> > >>
> > >> Que sur les appels sortants.
> > >>
> > >> Un de nos confrères a aussi le même défaut
> > >>
> > >> Le point commun semble être SFR.
> > >>
> > >>
> > >>
> > >> Il y en a d’autres ?
> > >>
> > >>
> > >>
> > >> Cordialement
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> Xavier
> > >>
> > >>
> > >> ---
> > >> 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/
> >
>
>
>
> --
> David
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>



-- 
Cordialement

HUBERT Mickaël
Ingénieur VOIP - Hexanet

-- 


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

Re: [FRnOG] [TECH] SIP ALG sur routeur

[Mickael Hubert]

+1
De notre coté, on désactive l'ALG sur tous les matériels qui le gèrent. On
laisse notre SBC gérer le NAT keepalive (opensips: nathelper.so).

Nous avons eu quelques surprises avec l'ALG sur les CPE Cisco 8XX par
exemple.

Cordialement

Le 11 octobre 2015 20:43, Michel Py  a
écrit :

> > David Ponzone a écrit :
> > La synthèse de nos réponses, c’était plutôt; désactive l’ALG sur le
> Cisco, parce que ça a jamais rendu service à personne :)
>
> Même si c'est vrai dans la plupart des cas, il  y a un élément dans la
> réponse d'Antoine qui est important:
>
> > Antoine Durant a écrit :
> > Bon je vais faire confiance à mon Asterisk puisque cela fonctionne bien
> !! Je vais rien toucher sur le Cisco...
>
> Si c'est un réseau de prod, ne touche pas avant de l'avoir simulé en lab.
> Si c'est pas en panne, pourquoi réparer ? Chaque fois que tu touches le
> réseau de prod même pour un "petit détail", tu ouvres la boîte de Pandore à
> un effet de bord, les pires étant ceux que tu ne détecte pas tout de suite.
>
>
> L'ALG, c'était un mal nécessaire dans 2 cas :
>
> - Les protocoles conçus avant NAT et qui ne se sont pas (ou pas bien)
> adaptés. Exemple : FTP. L'adresse IP est incluse dans le paquet, rendant
> l'usage d'un ALG nécessaire. Même si certaines évolutions (comme PASV) ont
> rendu la traversée de NAT et des pare-feu plus facile, il faut garder l'ALG.
>
> - Les protocoles conçus après NAT et mal conçus. Exemple : SIP. Alors que
> la généralisation de NAT était déjà bien en cours, SIP a été conçu pour ne
> pas traverser NAT facilement, ce qui a donné naissance aux ALGs SIP. Je
> mets "aux" à la place de "à", car il y en a plusieurs différents et aucun
> ne réagit pareil.
>
> Comme finalement les gens ont compris que NAT était là pour rester, les
> applications utilisant SIP (par exemple, Asterisk) se sont adaptées et sont
> maintenant capables de traverser NAT sans ALG.
>
> Michel.
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>



-- 
Cordialement

HUBERT Mickaël
Ingénieur VOIP - Hexanet

-- 


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

Re: [FRnOG] [MISC] Vendre du service et de la presta IT dans une ambassade

[Mickael Hubert]

Ok merci pour vos réponses ;)

par contre qqn à le numéro de la NSA, c'est un 0800 non ? Enfin c'est
forcement un numéro vert de toute façon ;)


Le 21 mars 2014 01:48, Michel Py mic...@arneill-py.sacramento.ca.us a
écrit :

  Mickael Hubert a écrit:
  Dans le cadre de la vente de services et/ou de prestations IT à une
  ambassade située en France, savez-vous quel droit s'applique ?

 Le droit du plus fort, comme d'habitude.

  En cas de non paiement des factures quel tribunal est compétent ?
  Le tribunal international ?

 Pas besoin de tribunal. Pour une prestation IT, je t'expliques comment
 faire:
 Tu fais une doc super détaillée, de tes prestations et du reste du réseau
 et du système.

 Si l'ambassade ne paie pas, aucun problème: tu vas voir la NSA en leur
 disant que tu as la doc complète et récente de l'infra d'une ambassade.
 Même si c'est celle des iouèssé, ils te paieront grassement.

 Pour une modique commission de 15%, je facilite ta transaction.

 Michel.



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

[FRnOG] [MISC] Vendre du service et de la presta IT dans une ambassade

[Mickael Hubert]

Salut à tous,

Une bonne petite question pour la fin de journée:

Dans le cadre de la vente de services et/ou de prestations IT à une
ambassade située en France, savez-vous quel droit s'applique ? En cas de
non paiement des factures quel tribunal est compétent ? Le tribunal
international ?

bref c'est con, mais pour moi une ambassade n'est pas un territoire
Français, donc ... si il y a un problème.. tu pleures !


Merci d'avance

Mika

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

[FRnOG] [BIZ] Capa pour Interco opérateur SIP France Telecom

[Mickael Hubert]

Bonjour à tous,
Dans le cadre d'une étude d'interco opérateur SIP France Telecom, j'aimerai
savoir si quelqu'un serait capable de me louer de la capa 100Mo entre TH2
et les 2 adresses ci-dessous, ce sont des DC FT.

1) 100Mo de TH2 vers 21 rue de la Motte 93300 Aubervilliers
2) 100Mo de TH2 vers 90 bld Kellermann 75013 Paris

De plus, si qqn est déjà colocalisé dans ces 2 DC, j'aimerai savoir s'il
serait possible de me louer du U ?


merci d'avance pour vos réponses.

-- 
Cordialement

Hubert Mickaël
Ingénieur VOIP - Hexanet

-- 


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

[FRnOG] [MISC] Recherche SBC SIP 2 SIP gérant le MPLS

[Mickael Hubert]

Bonjour à tous,
Nous sommes à la recherche d'un SBC sip2sip gérant le MPLS. En effet
Hexanet collecte ses clients soit en MPLS ou par accès standard (IP public).
Nous sommes confrontés à un problème de taille: faire passer le SIP et
surtout le flux RTP du réseau client vers le backbone VOIP (backbone basé
principalement sur OpenSIPS pour la SIG et MediaProxy pour le RTP).

*Nous avons certaines contraintes:*
- Gestion de diverses interfaces MPLS (une patte par MPLS client)
- Gestion d'une ou plusieurs interface(s) publique(s)
- Règle de routage avancée (Ex: rediriger les REGISTER vers certains
serveurs)
- Manipulation des header SIP
- transcodage voix
- possibilité de High Availability mode (Ex: VRRP sur les interfaces)

Sachant que nous faisons la sécurité SIP sur les OpenSIPS, nous n'avons pas
besoin d'une grosse Bertha qui sait tout faire, mais je doute trouver un
SBC qui sait répondre aux contraintes ci-dessus sans pour autant réaliser
la sécu SIP

*Nos recherches actuelles:*
- Acme Packet (Net-Net 3820)
- Cisco (ASR 1000)
- Cirpack (d'après leur doc il ne gérerait pas le MPLS)

Si quelqu'un connait différents modèles et qui a un retour d'expérience, je
suis preneur de toutes infos.

Merci d'avance


-- 
Cordialement

Hubert Mickaël
Hexanet

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

Re: [FRnOG] [MISC] Recherche SBC SIP 2 SIP gérant le MPLS

[Mickael Hubert]

Déjà merci pour vos réponses ;)
j'ai bien compris le principe du PE en front du SBC. Puis on transforme
le MPLS en VLAN. En fait nous avions espoir qu'un SBC puisse faire les 2.
Je pense que peut-être Cisco serait faire...

après on verra le prix ;)

++

2012/6/6 Tristan Mahé t.m...@b-and-c.net

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Salut Mickael,

 Je me permet de te signaler que tu cherches deux produits différents,
 un SBC dans un premier temps, et un egress point MPLS dans un second
 temps.

 Nous utilisons pour notre réseau du MPLS de bout en bout, et la voix
 circule dans un tunnel VPLS dédié avec du TE dans tous les sens.

 Pour cela nous avons utilisé une plateforme que nous avons construite
 autour de freeswitch, et un routeur MPLS qui tagge les tunnels dans
 des VLANs, ces VLANS étant ensuite récupérés sur le SBC.

 Cela répondra sans doute à ton cahier des charges, en ayant deux
 serveurs ( un SBC et un egress MPLS ) et non pas un seul qui fait tout.

 Si tu veux plus d'information, contacte moi hors-liste.

 Bien cordialement,

 Tristan Mahé.

 Le 06/06/2012 14:16, Mickael Hubert a écrit :
  Bonjour à tous, Nous sommes à la recherche d'un SBC sip2sip gérant
  le MPLS. En effet Hexanet collecte ses clients soit en MPLS ou par
  accès standard (IP public). Nous sommes confrontés à un problème de
  taille: faire passer le SIP et surtout le flux RTP du réseau client
  vers le backbone VOIP (backbone basé principalement sur OpenSIPS
  pour la SIG et MediaProxy pour le RTP).
 
  *Nous avons certaines contraintes:* - Gestion de diverses
  interfaces MPLS (une patte par MPLS client) - Gestion d'une ou
  plusieurs interface(s) publique(s) - Règle de routage avancée (Ex:
  rediriger les REGISTER vers certains serveurs) - Manipulation des
  header SIP - transcodage voix - possibilité de High Availability
  mode (Ex: VRRP sur les interfaces)
 
  Sachant que nous faisons la sécurité SIP sur les OpenSIPS, nous
  n'avons pas besoin d'une grosse Bertha qui sait tout faire, mais je
  doute trouver un SBC qui sait répondre aux contraintes ci-dessus
  sans pour autant réaliser la sécu SIP
 
  *Nos recherches actuelles:* - Acme Packet (Net-Net 3820) - Cisco
  (ASR 1000) - Cirpack (d'après leur doc il ne gérerait pas le MPLS)
 
  Si quelqu'un connait différents modèles et qui a un retour
  d'expérience, je suis preneur de toutes infos.
 
  Merci d'avance
 
 


 - --
 Tristan Mahé
 BC
 08.25.59.50.59
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.12 (GNU/Linux)

 iEYEARECAAYFAk/PUR8ACgkQ6Fs8qPC3T2mihQCdGj/pL1U2Qia5IbHZGNE4J0Nk
 c50AnjNIINSw6nXIQ7kfJcm/6f5MxyGQ
 =ysSa
 -END PGP SIGNATURE-


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




-- 
Cordialement

Hubert Mickaël
Hexanet

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

Re: [FRnOG] [MISC] Recherche SBC SIP 2 SIP gérant le MPLS

[Mickael Hubert]

Bonjour Guillaume,
Nous ne souhaitons pas faire de l'ALG. Nous voulons que le service sip
tourne sur le SBC.
Nous avons aussi été contacté par VOXAPP, nous ne connaissons pas. Nous
attendons leurs docs...



2012/6/6 Guillaume Barrot guillaume.bar...@gmail.com

 Cisco 7600S + carte ACE en mode SBC.
 Faudra peut etre passer par un peu de tromboning.
 Apres ACE/SBC n'est pas forcement le meilleur SBC du marche,
 tout dépend ce que tu veux en faire. (ALG SIP pour du NAT niveau 7 ?)

 A priori l'ASR9K ne supporte pas (encore ?) le SBC. Le CRS si a priori.


 Le 6 juin 2012 15:01, Mickael Hubert m.hub...@hexanet.fr a écrit :

 Déjà merci pour vos réponses ;)
 j'ai bien compris le principe du PE en front du SBC. Puis on transforme
 le MPLS en VLAN. En fait nous avions espoir qu'un SBC puisse faire les 2.
 Je pense que peut-être Cisco serait faire...

 après on verra le prix ;)

 ++

 2012/6/6 Tristan Mahé t.m...@b-and-c.net

  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA1
 
  Salut Mickael,
 
  Je me permet de te signaler que tu cherches deux produits différents,
  un SBC dans un premier temps, et un egress point MPLS dans un second
  temps.
 
  Nous utilisons pour notre réseau du MPLS de bout en bout, et la voix
  circule dans un tunnel VPLS dédié avec du TE dans tous les sens.
 
  Pour cela nous avons utilisé une plateforme que nous avons construite
  autour de freeswitch, et un routeur MPLS qui tagge les tunnels dans
  des VLANs, ces VLANS étant ensuite récupérés sur le SBC.
 
  Cela répondra sans doute à ton cahier des charges, en ayant deux
  serveurs ( un SBC et un egress MPLS ) et non pas un seul qui fait tout.
 
  Si tu veux plus d'information, contacte moi hors-liste.
 
  Bien cordialement,
 
  Tristan Mahé.
 
  Le 06/06/2012 14:16, Mickael Hubert a écrit :
   Bonjour à tous, Nous sommes à la recherche d'un SBC sip2sip gérant
   le MPLS. En effet Hexanet collecte ses clients soit en MPLS ou par
   accès standard (IP public). Nous sommes confrontés à un problème de
   taille: faire passer le SIP et surtout le flux RTP du réseau client
   vers le backbone VOIP (backbone basé principalement sur OpenSIPS
   pour la SIG et MediaProxy pour le RTP).
  
   *Nous avons certaines contraintes:* - Gestion de diverses
   interfaces MPLS (une patte par MPLS client) - Gestion d'une ou
   plusieurs interface(s) publique(s) - Règle de routage avancée (Ex:
   rediriger les REGISTER vers certains serveurs) - Manipulation des
   header SIP - transcodage voix - possibilité de High Availability
   mode (Ex: VRRP sur les interfaces)
  
   Sachant que nous faisons la sécurité SIP sur les OpenSIPS, nous
   n'avons pas besoin d'une grosse Bertha qui sait tout faire, mais je
   doute trouver un SBC qui sait répondre aux contraintes ci-dessus
   sans pour autant réaliser la sécu SIP
  
   *Nos recherches actuelles:* - Acme Packet (Net-Net 3820) - Cisco
   (ASR 1000) - Cirpack (d'après leur doc il ne gérerait pas le MPLS)
  
   Si quelqu'un connait différents modèles et qui a un retour
   d'expérience, je suis preneur de toutes infos.
  
   Merci d'avance
  
  
 
 
  - --
  Tristan Mahé
  BC
  08.25.59.50.59
  -BEGIN PGP SIGNATURE-
  Version: GnuPG v1.4.12 (GNU/Linux)
 
  iEYEARECAAYFAk/PUR8ACgkQ6Fs8qPC3T2mihQCdGj/pL1U2Qia5IbHZGNE4J0Nk
  c50AnjNIINSw6nXIQ7kfJcm/6f5MxyGQ
  =ysSa
  -END PGP SIGNATURE-
 
 
  ---
  Liste de diffusion du FRnOG
  http://www.frnog.org/
 



 --
 Cordialement

 Hubert Mickaël
 Hexanet

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




 --
 Cordialement,

 Guillaume BARROT




-- 
Cordialement

Hubert Mickaël
Hexanet

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