Re: [FRnOG] [TECH] comportement etrange smtp orange et starttls

[Vincent Tondellier via frnog]

Bonsoir,

Le Friday 17 April 2020 01:16:09 Juan Isoza a écrit :
> j'essaye avec plusieurs OS (essentiellement des variantes de linux)
> 
> openssl s_client -starttls smtp  -connect smtp-in.orange.fr:25

ha orange ...

Il n'y aurait pas un gros message "SSL 
routines:ssl_choose_client_version:unsupported protocol"  ?

Ca donne quoi avec l'option -tls1 ?

> avec une collection de openssl 1.1.0 ou 1.1.1
> 
> la moitier connectent, 


> l'autre pas...

Cette moitié, c'est pas Debian et dérivés, par hasard ?

orange ne supporte QUE TLSv1 (oui, en 2020), mais Debian a désactivé par 
défaut ce vieux protocole, obsolète, qui ne devrait plus être utilisé et "en 
danger critique d'extinction" vu que les navigateurs web l'ont (ou vont) le 
supprimer.


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

Re: [ML] [FRnOG] [TECH] comportement etrange smtp orange et starttls

[Manuel Guesdon]

On Fri, 17 Apr 2020 01:16:09 +0200
Juan Isoza  wrote:
>| j'essaye avec plusieurs OS (essentiellement des variantes de linux)
>| 
>| openssl s_client -starttls smtp  -connect smtp-in.orange.fr:25
>| 
>| avec une collection de openssl 1.1.0 ou 1.1.1
>| 
>| la moitier connectent, l'autre pas...

smtp-in.orange.fr.  600 IN  A   80.12.242.9
smtp-in.orange.fr.  600 IN  A   193.252.22.65

Tu tombes peut être alternativement sur un cluster ou sur un autre, l'un et
l'autre ayants une conf différente..

Manuel

--
__
Manuel Guesdon - OXYMIUM


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

[FRnOG] [TECH] comportement etrange smtp orange et starttls

[Juan Isoza]

bonjour,
j'essaye avec plusieurs OS (essentiellement des variantes de linux)

openssl s_client -starttls smtp  -connect smtp-in.orange.fr:25

avec une collection de openssl 1.1.0 ou 1.1.1

la moitier connectent, l'autre pas...

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

RE: [FRnOG] [TECH] Trunk SIP redondant

[Michel Py]

> Xavier Roca a écrit :
> De toute façon la problématique reste la même, SIP reste SIP et copie le 
> fonctionnement du legacy en
> ISDN/SS7, et rien n’a été prévu pour qu’une ressource téléphonique puisse 
> être annoncée par 2 chemins.
> Sachant que l’opérateur qui détient la ressource touche en plus des 
> reversements sur les appels entrants,
> et que la quasi-totalité du trafic utilise Orange (donc l’opérateur 
> historique)  comme transit entre les
> opérateurs (il y a très peu de peering, il n’est pas gratuit par définition, 
> au mieux il y a compensation,
> et 3 ou 4 opérateurs cumulent 90% du trafic; il y a un colistier qui a tenté 
> de montre un point de peering
> Voix: gros échec, il pourra peut-être nous donner sa vision du problème), on 
> sent bien qu’on est sur un
> modèle très différent de l’IP, et je vois mal un changement à ce niveau à 
> court-terme.

Je partage ton analyse. Le numéro de téléphone c'est ce qui reste du monopole 
que les opérateurs de voix, ironiquement y compris ceux qui sont nés de la 
suppression du monopole d'état, aiment bien. Personne n'a intérêt à changer le 
status quo. Je n'ai qu'une très vague idée comment cette partie marche en 
France, n'ayant rien connu que le monopole.
Ici il y a un processus appelé "porting", une vraie ch... quand on est le 
client, ou les deux opérateurs (l'ancien et le nouveau) doivent s'entendre sur 
la date et l'heure du changement, et çà coute un bras.


> J'ai aussi ajouté la publication d'IP douteuses sur le monde de la VoIP en 
> tenant compte du fil de la discussion.
> Je n'ai pas pris le temps d'écrire en CDC en interne mais ça va viendre. Par 
> contre le BGP, n'est pas ma tasse de
> thé, j'ai bien les notions et fait une formation avec France-X, mes va quand 
> même falloir que je retravaille le
> sujet avec des collègues. Si Michel PY, Rémy, Daniel et d'autres ont le temps 
> de faire un résumé didactique pour
> les nuls de ce qu'il faudrait pour que ce soit bien, je prends volontiers.

Il y a 4 aspects : 
1. Comment on détecte l'attaque.
2. Comment on décide qu'elle a pris fin.
3. Comment on injecte çà dans BGP.
4. Comment on distribue le machin.

Pour 1. et 2., çà dépend du protocole et de celui qui détecte a décidé. Ce que 
je fais n'est pas limité à SIP, d'ailleurs je fais aucune détection sur les 
attaques SIP moi-même, mon SIP n'étant pas ouvert vers l'extérieur. La 
philosophie de ce que fait Rémy me convient, je décide donc d'accepter sa 
blacklist. C'est pas tellement différent des RBL pour le spam, c'est à toi de 
choisir quelles sont les RBL qui te conviennent. Spamhaus par exemple je m'en 
sers, parce que c'est stable et sans emmerdes, alors que je crois me rappeler 
que SORBS j'ai enlevé parce qu'il y avait trop de faux positifs.

Rémy et moi faisons des taches complémentaires : il détecte les attaques dans 
son réseau / ses honeypots, alors que ce que je fais c'est plutôt de la 
consolidation et de la distribution.
Le CBBC c'est une consolidation de plusieurs sources, y compris très 
prochainement Rémy, que je redistribue avec BGP. BGP a deux avantages :
- La vitesse : 1 seconde après que Rémy détecte une attaque, cette IP est déjà 
bloquée chez moi. 2 secondes après, elle est bloquée chez le gens qui 
souscrivent à mon feed.
- La granularité : si les gens qui prennent mon feed n'aiment pas le blocage 
que Rémy fait, ils n'ont qu'à ignorer la communauté associée aux préfixes qu'il 
envoie.

Pour 3., presque tout le monde y compris moi utilise ExaBGP de Thomas Mangin :
https://github.com/Exa-Networks/exabgp
A noter que, pour les préfixes venant de Rémy, je n'ai pas d'injection : ce que 
je reçois c'est déjà du BGP. C'est Rémy qui fait sa propre injection (tu fais 
ExaBGP aussi ?).

Pour 4., on fait tous la même chose :
https://www.team-cymru.com/bogon-reference-bgp.html
https://www.spamhaus.org/bgpf/
http://arneill-py.sacramento.ca.us/cbbc/

On annonce des préfixes, avec une ou plusieurs communautés associées, dans le 
but que le destinataire les envoies dans un trou noir en réception si c'est 
l'adresse source et en émission si c'est l'adresse de destination. Le préfixe 
est annoncé pareil qu'un préfixe normal, sauf que la grande majorité c'est du 
/32, et c'est donc en fonction de la présence d'une communauté qu'on le droppe 
ou qu'on le forwarde.

Si tu as des questions précises, n'hésite pas.

Michel.


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

Re: [FRnOG] [TECH] Trunk SIP redondant

[Emmanuel DECAEN]

Bonjour,

Le 16/04/2020 à 09:54, David Ponzone a écrit :
> J’avais pris la question d’Emmanuel comme une question concernant les
> opérateurs, et je me rends compte qu’effectivement sa question portait
> sur les trunks pour client finaux.

En fait, les deux aspects m'intéressent et les deux réponses mes
conviennent.

> De toute façon la problématique reste la même, SIP reste SIP et copie
> le fonctionnement du legacy en ISDN/SS7, et rien n’a été prévu pour
> qu’une ressource téléphonique puisse être annoncée par 2 chemins.


C'est entièrement statique ?
Il n'y a pas moyen de dire techniquement "voici mes blocs" à l'opérateur
upstream (ou un peer) ?


> Sachant que l’opérateur qui détient la ressource touche en plus des
> reversements sur les appels entrants, et que la quasi-totalité du
> trafic utilise Orange (donc l’opérateur historique)  comme transit
> entre les opérateurs


En gros, si je comprends bien, il existe toujours un gros monopole de
fait avec Orange.

> (il y a très peu de peering, il n’est pas gratuit par définition, au
> mieux il y a compensation, et 3 ou 4 opérateurs cumulent 90% du
> trafic; il y a un colistier qui a tenté de montre un point de peering
> Voix: gros échec, il pourra peut-être nous donner sa vision du
> problème), on sent bien qu’on est sur un modèle très différent de
> l’IP, et je vois mal un changement à ce niveau à court-terme.


Et j'imagine que parler de l'aspect ci-dessous est un peu polémique ;-)

$ whois 3.3.e164.arpa.

domain: 3.3.e164.arpa
descr:  domaine enum de la France, France Metropole
remarks:    Website: http://www.telecom.gouv.fr/
remarks:    Email: admine...@industrie.gouv.fr

Bonne soirée.
-- 
*Emmanuel DECAEN*
E-Mail: e...@xsalto.com

www.xsalto.com
Tél: 04 92 36 60 06
Support: 04 92 36 60 07
Fax: 04 92 36 19 75

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

RE: [FRnOG] [TECH] Trunk SIP redondant

[x.roca]

Bonjour,

Quand j'ai vu le début de la discussion, je me doutais un peu qu'on allait y 
revenir.
Alors ce sujet est toujours d'actualité et n'est pas mort.
On a eu de belle contribution et de bon retour.
Partant déjà de là on a commencé la rédaction d'un cahier des charges sur le 
sujet.

Le projet étant porté par notre société qui reste une boîte privée 100% 
autofinancé on a comme beaucoup d'entre vous l'obligation d'établir certaines 
priorités économiques :)
Donc quand des prospects et clients nous sollicitent avec des prestations 
sonnantes et trébuchantes, et bien on les faits passer devant.
Je sais ce n'est pas bien !
Et honnêtement depuis on bosse bien et on a un nouveau soft à sortir qui nous 
occupe pas mal. 
Tout n'est pas perdu car le nouveau soft contient aussi une partie nécessaire 
au projet IAV.
C’est-à-dire la partie IHM, portail, traçage de logs etc...
Et ce n'est pas rien.

Avec nos capacités sur le SIP, il y a du travail qui n'est pas insurmontable.
Il nous faudrait juste un dév en plus pour 6 mois et on verrait si on le 
conserve ou pas.
IAV n'étant pas à la base dans mot esprit un projet financier, je n'ai pas 
imaginé de Business model autour de cela.
S'il y en avait un d'établit, cela justifiera que l'on investisse dedans.
Le blog est toujours ouvert pour ceux qui auraient des idées en ce sens.
On peut aussi à quelques-uns cofinancer cela, ce n'est pas non plus le bout du 
monde.

Sinon, cela reste dans nos sujets de fonds quand aura le temps et là, la 
situation nous a donné pas de travail et changement de plan.

J'ai aussi ajouté la publication d'IP douteuses sur le monde de la VoIP en 
tenant compte du fil de la discussion.
Je n'ai pas pris le temps d'écrire en CDC en interne mais ça va viendre.
Par contre le BGP, n'est pas ma tasse de thé, j'ai bien les notions et fait une 
formation avec France-X, mes va quand même falloir que je retravaille le sujet 
avec des collègues.
Si Michel PY, Rémy, Daniel et d'autres ont le temps de faire un résumé 
didactique pour les nuls de ce qu'il faudrait pour que ce soit bien, je prends 
volontiers.

Allez sur ceux, je retourne sur des sujets chauds pour Mr Covid-19

Allez RCT !
Je sais on n'est pas Dredi mais en ce moment il le faut tous les jours :)

Xavier



-Message d'origine-
De : David Ponzone  
Envoyé : jeudi 16 avril 2020 09:54
À : Cedric Millet (pro) 
Cc : Emmanuel DECAEN ; frnog-tech 

Objet : Re: [FRnOG] [TECH] Trunk SIP redondant

Oui bien sût, un fournisseur de trunk SIP pour client final peut normalement 
faire toute sorte de trucs de ce genre, plus ou moins custom en fonction de sa 
volonté de faire du custom et de l’importance du client.

J’avais pris la question d’Emmanuel comme une question concernant les 
opérateurs, et je me rends compte qu’effectivement sa question portait sur les 
trunks pour client finaux.
De toute façon la problématique reste la même, SIP reste SIP et copie le 
fonctionnement du legacy en ISDN/SS7, et rien n’a été prévu pour qu’une 
ressource téléphonique puisse être annoncée par 2 chemins.
Sachant que l’opérateur qui détient la ressource touche en plus des 
reversements sur les appels entrants, et que la quasi-totalité du trafic 
utilise Orange (donc l’opérateur historique)  comme transit entre les 
opérateurs (il y a très peu de peering, il n’est pas gratuit par définition, au 
mieux il y a compensation, et 3 ou 4 opérateurs cumulent 90% du trafic; il y a 
un colistier qui a tenté de montre un point de peering Voix: gros échec, il 
pourra peut-être nous donner sa vision du problème), on sent bien qu’on est sur 
un modèle très différent de l’IP, et je vois mal un changement à ce niveau à 
court-terme.


> Le 15 avr. 2020 à 23:44, Cedric Millet (pro)  a 
> écrit :
> 
> Hello
> Ca ne change rien à ce qu'a dit David mais pour info (sur panne du trunk A 
> coté client [car si c'est le softswitch/infra de ton opérateur qui est HS, 
> c'est mort]) y'a cette solution/piste (supportee par au moins les sbc 
> acmepacket/oracle et sonus) :
> 
> Tu peux toujours demander à ton opérateur s'il supporte le crankback 
> (reroutage sur cause d'erreur reçue du trunk A) ; parfois avec renumérotation 
> vers un numéro unique.
> 
> Au mieux t'auras donc toutes les sda de ton trunk A reroutees vers ton trunk 
> B (qui en nominal a ses propres sda).
> Et avec renumerotation : tes sda sont toutes transformees en un numero C 
> unique qui peut etre n'importe quel numero (voire meme un mobile si ton 
> operateur le permet).
> Quand c'est la misere ca peut etre utile en mode ultra dégradé...
> NB : C'est le client proprietaire du trunk A qui est facturé de la 
> renumerotation vers C.
> 
> Completel faisait (fait toujours?) ca sur une de ces offres.
> 
> Cedric
> 
> Le 15 avr. 2020 22:53, "David Ponzone"  > a écrit :
> Non, ça existe pas.
> Le meilleur niveau de redondante que tu puisses avoir c’est 2 intercos SIP 
> avec Orange sur un couple de SRTHD qui font partie du même noeud chez 

RE: [FRnOG] [TECH] Attaque SIP et SIPS

[Duchet Rémy]

Pas de soucis pour redistribuer les IP. Ce ne sont que des /32 (IPv4) /128 
(IPv6). Environ 54 000 IP se sont fait "flashé" sur les derniers 15 jours. Seul 
9 500 IPv4 et 650 IPv6 (environ) sont vraiment bannis à un instant T.
Pour la communauté, je peux mettre ce que tu souhaites, pas de soucis.
Je te réponds en OFF pour la suite.
Pour les autres,  si ça intérésse, pas de soucis pour monter une session BGP 
sur nos RS.
J'ajoute qu'on surveille autant des Honeypot que des "vrais" services en prod.
Pas seulement du http/https, mais aussi du SIP/SMTP/Pop3/Imap4/Rdp/SMB/VNC etc.
On a un seuil de sensibilité différent en fonction des services et on tracke 
les tentatives sur des longues périodes.
Bref, on a un outil fait "in-housse" pas mal flexible qui s'adapte à tous les 
services.

Rémy
-Original Message-
From: frnog-requ...@frnog.org  On Behalf Of Michel Py
Sent: mercredi, 15 avril 2020 20:00
To: Duchet Rémy ; frnog@frnog.org
Subject: RE: [FRnOG] [TECH] Attaque SIP et SIPS

> Rémy Duchet a écrit :
> Comme nous avons des sondes sur plein de services différents, la
> "liste" évolue sans arrêt. Du coup, je ne me vois pas faire un fichier (je 
> l'aurais fait avec Git) et des milliers de commits par jour.
> Donc, je veux bien les annoncer via BGP, ça me semble plus simple et 
> utilisable comme cela.

C'est la manière propre de faire çà. Je te contacte en privé pour les détails 
BGP. Est-ce que tu m'autorises à redistribuer tes préfixes ?


>> Daniel a écrit :
>> Le fichier n'a pas besoin d'être à jour à la minute prêt d'autant que
>> l'on va retrouver en grande partie les mêmes adresses. Une mise à jour 
>> hebdomadaire voire bi-mensuelle me parait suffisante.

Je ne suis pas d'accord, la vitesse de réaction est primordiale. Si j'ai le 
feed BGP de Rémy, une seconde après que le bachibouzouk l'attaque c'est dans 
mon trou noir aussi, donc viendu le l'attends déjà.

> Rémy Duchet :
> En fait, si. Je suis convaincu que plus de 60%  des attaques ne viennent 
> jamais des même IP.
> Cette IP qui attaque maintenant, ne l'est plus dans 1h (voir avant,
> dès qu'elle a été détecté / bannis). Dans notre automatisation, nous
> avons justement prévu le cas des attaques d'IP dynamique, pour ne pas 
> pénaliser la personne qui va hériter d'une IP qui a été bannis.

Je plussoie. J'ai vu dans bien des cas que le PC contaminé par un merdiciel va 
être rebooté, et la machinbox aussi, parce que Claude Michu se rend compte que 
quelque chose ne tourne pas rond. Des fois, l'adresse de la machinbox change, 
et c'est pas glop pour celui qui en hérite si c'est banni pour l'éternité.

Ton système, c'est 100 fois mieux que les sources en fichier texte dont je me 
sers.

> Je pense qu'il faudrait faire quelque chose de plus centralisé, avec
> de la redondance, et la capacité d'accueillir du monde.

Cà m'avais traversé l'esprit aussi.

> J'avais déjà vu ce que tu avais fait, et ça me semble déjà énorme
> comme job. Qu'est-ce que tu as envisagé comme amélioration future, hormis des 
> listes supplémentaires ?

Il y a 2 améliorations que je voulais faire avant de piquer le code de Jeremy, 
c'est :

1. Une communauté spécifique par liste, en plus de 65532:666. Ca permettrait à 
ceux qui prennent le feed de mettre un deny dans leur route-map pour ignorer 
les listes dont ils ne veulent pas.

2. Un fetch intelligent : au lieu faire un wget toutes les x minutes, lire 
uniquement l'en-tête du fichier et ne faire que wget que si il a changer. Cà 
permettrait d'augmenter la fréquence et d'économiser de la bande passante.

Michel.


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

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

Re: [FRnOG] [TECH] Trunk SIP redondant

[David Ponzone]

Oui bien sût, un fournisseur de trunk SIP pour client final peut normalement 
faire toute sorte de trucs de ce genre, plus ou moins custom en fonction de sa 
volonté de faire du custom et de l’importance du client.

J’avais pris la question d’Emmanuel comme une question concernant les 
opérateurs, et je me rends compte qu’effectivement sa question portait sur les 
trunks pour client finaux.
De toute façon la problématique reste la même, SIP reste SIP et copie le 
fonctionnement du legacy en ISDN/SS7, et rien n’a été prévu pour qu’une 
ressource téléphonique puisse être annoncée par 2 chemins.
Sachant que l’opérateur qui détient la ressource touche en plus des 
reversements sur les appels entrants, et que la quasi-totalité du trafic 
utilise Orange (donc l’opérateur historique)  comme transit entre les 
opérateurs (il y a très peu de peering, il n’est pas gratuit par définition, au 
mieux il y a compensation, et 3 ou 4 opérateurs cumulent 90% du trafic; il y a 
un colistier qui a tenté de montre un point de peering Voix: gros échec, il 
pourra peut-être nous donner sa vision du problème), on sent bien qu’on est sur 
un modèle très différent de l’IP, et je vois mal un changement à ce niveau à 
court-terme.


> Le 15 avr. 2020 à 23:44, Cedric Millet (pro)  a 
> écrit :
> 
> Hello
> Ca ne change rien à ce qu'a dit David mais pour info (sur panne du trunk A 
> coté client [car si c'est le softswitch/infra de ton opérateur qui est HS, 
> c'est mort]) y'a cette solution/piste (supportee par au moins les sbc 
> acmepacket/oracle et sonus) :
> 
> Tu peux toujours demander à ton opérateur s'il supporte le crankback 
> (reroutage sur cause d'erreur reçue du trunk A) ; parfois avec renumérotation 
> vers un numéro unique.
> 
> Au mieux t'auras donc toutes les sda de ton trunk A reroutees vers ton trunk 
> B (qui en nominal a ses propres sda).
> Et avec renumerotation : tes sda sont toutes transformees en un numero C 
> unique qui peut etre n'importe quel numero (voire meme un mobile si ton 
> operateur le permet).
> Quand c'est la misere ca peut etre utile en mode ultra dégradé...
> NB : C'est le client proprietaire du trunk A qui est facturé de la 
> renumerotation vers C.
> 
> Completel faisait (fait toujours?) ca sur une de ces offres.
> 
> Cedric
> 
> Le 15 avr. 2020 22:53, "David Ponzone"  > a écrit :
> Non, ça existe pas.
> Le meilleur niveau de redondante que tu puisses avoir c’est 2 intercos SIP 
> avec Orange sur un couple de SRTHD qui font partie du même noeud chez eux, et 
> ils s’occupent de router les appels en actif/actif ou actif/passif.
> Si Orange est dead sur les 2 SRTHD, t’es dead aussi.
> Peu probable (les SRTHD sont à plusieurs km l’un de l’autre), et si ça 
> arrive, y aura du monde dans les choux.
> 
> 
> 
> > Bonsoir,
> > 
> > Existe-t'il une solution pour avoir un Trunk SIP redondant pour les
> > appels entrants pour un bloc donné de numéros ?
> > En gros je prends un premier trunk SIP auprès de l'opérateur A et un
> > second trunk SIP auprès de l'opérateur B.
> > 
> > En temps normal, je reçois les appels depuis A et/ou depuis B.
> > En cas de problème avec A, je reçois immédiatement les appels depuis B
> > (et vice versa).
> > 
> > En gros, cela revient au mécanisme de BGP appliqué à la téléphonie.
> > 
> > Est-ce que cela implique d'avoir mes propres ressources en numérotation
> > (équivalent PI en IP) ?
> > Ou existe t'il des loueurs de blocs de numéros (équivalent LIR pour la
> > location d'un bloc IP /24) ?
> > 
> > Merci.
> > -- 
> > 
> > *Emmanuel DECAEN*
> > 
> > 
> > ---
> > 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] Re: [ALERT] Problème RPKI chez Free ?

[Stephane Bortzmeyer]

On Tue, Apr 14, 2020 at 12:16:12PM +0200,
 Stephane Bortzmeyer  wrote 
 a message of 17 lines which said:

> FRee annonce des préfixes comme le 78.192.0.0/10 mais aussi des /23 et
> /24 en dessous, qui ne sont pas visibles de partout.
> 
> Le /10 est désormais signé, avec un ROA qui permet jusqu'au /11,
> rendant les /24 invalides.

Notez que c'est désormais corrigé.


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

Re: [FRnOG] [TECH] Trunk SIP redondant

[Philippe Botherel]

Hello,

Sur les trunk Sewan, on peut faire un routage SDA par SDA.

Philippe

Le mer. 15 avr. 2020 à 23:45, Cedric Millet (pro) 
a écrit :

> Hello
> Ca ne change rien à ce qu'a dit David mais pour info (sur panne du trunk A
> coté client [car si c'est le softswitch/infra de ton opérateur qui est HS,
> c'est mort]) y'a cette solution/piste (supportee par au moins les sbc
> acmepacket/oracle et sonus) :
>
> Tu peux toujours demander à ton opérateur s'il supporte le crankback
> (reroutage sur cause d'erreur reçue du trunk A) ; parfois avec
> renumérotation vers un numéro unique.
>
> Au mieux t'auras donc toutes les sda de ton trunk A reroutees vers ton
> trunk B (qui en nominal a ses propres sda).
> Et avec renumerotation : tes sda sont toutes transformees en un numero C
> unique qui peut etre n'importe quel numero (voire meme un mobile si ton
> operateur le permet).
> Quand c'est la misere ca peut etre utile en mode ultra dégradé...
> NB : C'est le client proprietaire du trunk A qui est facturé de la
> renumerotation vers C.
>
> Completel faisait (fait toujours?) ca sur une de ces offres.
>
> Cedric
>
> Le 15 avr. 2020 22:53, "David Ponzone"  a écrit :
>
> Non, ça existe pas.
> Le meilleur niveau de redondante que tu puisses avoir c’est 2 intercos SIP
> avec Orange sur un couple de SRTHD qui font partie du même noeud chez eux,
> et ils s’occupent de router les appels en actif/actif ou actif/passif.
> Si Orange est dead sur les 2 SRTHD, t’es dead aussi.
> Peu probable (les SRTHD sont à plusieurs km l’un de l’autre), et si ça
> arrive, y aura du monde dans les choux.
>
>
>
> > Bonsoir,
> >
> > Existe-t'il une solution pour avoir un Trunk SIP redondant pour les
> > appels entrants pour un bloc donné de numéros ?
> > En gros je prends un premier trunk SIP auprès de l'opérateur A et un
> > second trunk SIP auprès de l'opérateur B.
> >
> > En temps normal, je reçois les appels depuis A et/ou depuis B.
> > En cas de problème avec A, je reçois immédiatement les appels depuis B
> > (et vice versa).
> >
> > En gros, cela revient au mécanisme de BGP appliqué à la téléphonie.
> >
> > Est-ce que cela implique d'avoir mes propres ressources en numérotation
> > (équivalent PI en IP) ?
> > Ou existe t'il des loueurs de blocs de numéros (équivalent LIR pour la
> > location d'un bloc IP /24) ?
> >
> > Merci.
> > --
> >
> > *Emmanuel DECAEN*
> >
> >
> > ---
> > 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/