Re: [FRnOG] [TECH] Forticlient, Linux et OpenSSL
Ancien utilisateur d'openfortivpn maintenant passé sur openconnect pour la gestion du DTLS et autres options avancées. Bonne journée à tous -- Arnaud On Thu, 16 May 2024 at 10:57, Stéphane Rivière wrote: > Merci pour vos réponses rapides > > https://github.com/adrienverge/openfortivpn > > Et paquet direct pour Ubuntu : openfortivpn > > Un bon vieux bidule codé très proprement en C et des retours positifs, > ça sent bon... > > Donc quand ça va ressortir le mois prochain, je vais suivre votre conseil ! > > Encore merci pour votre aide :) > > -- > Stéphane Rivière > Ile d'Oléron - France > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: Re : Re: [FRnOG] [TECH] FREESWITCH et gestion des DTMF
Merci pour ces retours. En effet Kamailio fait sens pour cet usage. -- Arnaud On Sun, 19 Jun 2022 at 07:23, Benoit Chesneau wrote: > c'est clairement l'objet de kamailio. Je ne vois pa trop l'interêt de > patcher FS. > > Benoît > > > Le vendredi 17 juin 2022 à 20:44, David Ponzone > a écrit : > > Je vois pas d’autres moyens: > -de patcher FS comme tu proposais > -de mettre un vrai truc devant capable de ré-écrire le Allow (Kamailio, > OpenSIPS, commercial) > > A priori, les devs de FreeSWITCH considèrent qu’il faut pas toucher au > Allow. Tu peux altérer le SDP, mais pour le Allow, niet. > > > Le 17 juin 2022 à 18:07, Arnaud Gelly a écrit : > > > > Si tu fais : > > dtmf-type rfc2833 > > liberal-dtmf true > > > > tu proposes RFC2833 mais accepte SIP INFO. Ce qui permet de gérer des > endpoint qui savent faire QUE du SIP INFO. > > > > Nous on veut s'assurer de ne PAS avoir de SIP INFO. > > > > > > > > > > On Fri, 17 Jun 2022 at 18:01, David Ponzone <mailto:david.ponz...@gmail.com>> wrote: > > > > > Le 17 juin 2022 à 16:33, Arnaud Gelly arnaud.ge...@gmail.com>> a écrit : > > > > > > @David : Oui c'est bien ça le besoin. Les appels arrivent d'une > interco opérateur et on veut s'assurer qu'il n'y ai pas de traces de DTMF > dans la signalisation, uniquement dans le media. > > > > > > Nous avons par exemple des cas de re-invite ou le endpoint "oublie" > qu'il sait faire du RFC2833 et le DTMF passe en SIP INFO alors qu'il n'est > même pas géré par le endpoint. > > > > > > > C’est pas pour ce cas de figure là justement (endpoint buggué): > literal-dtmf=true ? > > (J’ai lu les docs en diagonale, et en ce qui concerne les DTMF ça a > toujours été très laconique….) > > > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] FREESWITCH et gestion des DTMF
Si tu fais : *dtmf-type rfc2833liberal-dtmf true* tu proposes RFC2833 mais accepte SIP INFO. Ce qui permet de gérer des endpoint qui savent faire QUE du SIP INFO. Nous on veut s'assurer de ne PAS avoir de SIP INFO. On Fri, 17 Jun 2022 at 18:01, David Ponzone wrote: > > > Le 17 juin 2022 à 16:33, Arnaud Gelly a écrit : > > > > @David : Oui c'est bien ça le besoin. Les appels arrivent d'une interco > opérateur et on veut s'assurer qu'il n'y ai pas de traces de DTMF dans la > signalisation, uniquement dans le media. > > > > Nous avons par exemple des cas de re-invite ou le endpoint "oublie" > qu'il sait faire du RFC2833 et le DTMF passe en SIP INFO alors qu'il n'est > même pas géré par le endpoint. > > > > C’est pas pour ce cas de figure là justement (endpoint buggué): > literal-dtmf=true ? > (J’ai lu les docs en diagonale, et en ce qui concerne les DTMF ça a > toujours été très laconique….) > > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] FREESWITCH et gestion des DTMF
@David : Oui c'est bien ça le besoin. Les appels arrivent d'une interco
opérateur et on veut s'assurer qu'il n'y ai pas de traces de DTMF dans la
signalisation, uniquement dans le media.
Nous avons par exemple des cas de re-invite ou le endpoint "oublie" qu'il
sait faire du RFC2833 et le DTMF passe en SIP INFO alors qu'il n'est même
pas géré par le endpoint.
On Fri, 17 Jun 2022 at 16:32, Richard Klein wrote:
> Bonjour
>
> Histoire de contredire David ...dans les fait il y a effectivement souvent
> des incidents ou les clients n'arrivent pas à composer les DTMF vers des
> SVI et la effectivement il faud éplucher les traces SIP de bout en bout.
> Richard
>
> Le ven. 17 juin 2022 à 16:24, David Ponzone a
> écrit :
>
>> Hmm je veux être sûr de comprendre: tu veux forcer la RFC2833 même si
>> l’autre endpoint ne le supporte pas ?
>> J’espère que l’autre endpoint n’est pas le téléphone du boss qui veut
>> appeler un 0899 coquin, parce que ça va chauffer…
>>
>> Jamais eu ce genre de besoin.
>> Le besoin c’est généralement plutôt que les DTMF marchent à peu près,
>> quoi qu’il en coûte.
>>
>>
>> > Le 17 juin 2022 à 16:15, Arnaud Gelly a écrit
>> :
>> >
>> > Bonjour à tous,
>> >
>> > Je cherche à m'assurer d'avoir uniquement des DTMF RFC2833 sur mon
>> réseau
>> > et d'empêcher au maximum le SIP INFO.
>> >
>> > Malgré les paramètres suivants, mon SBC Freeswitch transcode les DTMF en
>> > SIP INFO si la destination ne propose pas RFC2833 :
>> >
>> > dtmf-type rfc2833
>> > liberal-dtmf false
>> > pass-rfc2833 true
>> >
>> > C'est peut-être un comportement normal car on dit aussi qu'on supporte
>> la
>> > méthode INFO.
>> >
>> >
>> > Au delà d'un simple bug freeswitch est-ce que vous avez déjà eu ce
>> genre de
>> > besoin ? Est-ce que vous avez essayé d'enlever INFO dans le Allow ?
>> >
>> > Je cherche à voir si la piste avec des LUA peut arriver à cet objectif
>> ou
>> > s'il ne me reste plus qu'à éditer sophia.c pour enlever
>> > NUTAG_APPL_METHOD("INFO") et tracker où se fait la transposition
>> RFC2833 /
>> > SIP INFO.
>> >
>> > S'il y a d'autres moyens avant d'en arriver là je suis preneur.
>> >
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>
---
Liste de diffusion du FRnOG
http://www.frnog.org/
[FRnOG] [TECH] FREESWITCH et gestion des DTMF
Bonjour à tous,
Je cherche à m'assurer d'avoir uniquement des DTMF RFC2833 sur mon réseau
et d'empêcher au maximum le SIP INFO.
Malgré les paramètres suivants, mon SBC Freeswitch transcode les DTMF en
SIP INFO si la destination ne propose pas RFC2833 :
dtmf-type rfc2833
liberal-dtmf false
pass-rfc2833 true
C'est peut-être un comportement normal car on dit aussi qu'on supporte la
méthode INFO.
Au delà d'un simple bug freeswitch est-ce que vous avez déjà eu ce genre de
besoin ? Est-ce que vous avez essayé d'enlever INFO dans le Allow ?
Je cherche à voir si la piste avec des LUA peut arriver à cet objectif ou
s'il ne me reste plus qu'à éditer sophia.c pour enlever
NUTAG_APPL_METHOD("INFO") et tracker où se fait la transposition RFC2833 /
SIP INFO.
S'il y a d'autres moyens avant d'en arriver là je suis preneur.
Bon weekend !
--
Arnaud
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Re: [FRnOG] [ALERT] K-net down ?
Bonjour à tous, Communication de la part de K-NET aujourd'hui : *Comme nous l'avons déjà évoqué dans notre message du 10 novembre 2021, nous entreprenons depuis cet automne des maintenances d'envergure sur notre infrastructure réseau afin de préparer au mieux l'avenir.* *Malheureusement, en parallèle de ces maintenances, nous avons rencontré divers incidents techniques :* - *La téléphonie : Cet incident est actuellement toujours en cours de résolution. Notre équipe technique travaille activement afin de rétablir le service dans les meilleurs délais.* - *La connexion Internet : En janvier, une panne de serveur est survenue, impactant une grande partie de notre parc client. * - *Un problème sur le Réseau Fibre d'un de nos opérateurs d'infrastructure partenaire a également impacté une large partie d'entre vous entre le 19 et le 21 janvier. * *Nous sommes très sincèrement désolés pour toutes ces perturbations et mesurons à quel point cela peut vous impacter .* *Et vous assurons que toute notre équipe technique est mobilisée au quotidien pour revenir à une situation normale.* *Ces évènements ont perturbé fortement notre service client. Soyez assuré que nous mettons tout en œuvre pour répondre à l'ensemble de vos demandes.* *Nous vous remercions pour votre compréhension et vous assurons de notre investissement et de notre confiance en l'avenir.* *Bien cordialement,**La Direction * Espérons que tout revienne à la normale. Cordialement. -- Arnaud On Wed, 19 Jan 2022 at 12:28, Hugues Voiturier wrote: > Je vous laisse bouquiner, c’est instructif : > https://lafibre.info/k-net-internet/ > > Hugues Voiturier > Consultant en architecture réseau > AS57199 > > > On 19 Jan 2022, at 12:23, David Ponzone wrote: > > > > Je sais pas pour K-net mais en tout cas, c’est pas généralisé à tout > Losange FTTH. > > > >> Le 19 janv. 2022 à 11:53, Xavier Beaudouin via frnog > a écrit : > >> > >> Hello, > >> > >> Je ne sais pas si c'est généralisé mais via Losange Fibre dans mon coin > j'ai l'impression que K-net a des gros soucis. > >> A un tel point que le numéro de tel général réponds occupé... > >> La page d'incident sembre juste parler d'un problème de VOIP, mais pas > de problème liés a collecte FTTH... > >> Si jamais quelqu'un a des infos... ? > >> > >> (Heureusement que les backup xDSL et 4G sont là). > >> 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/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Logiciel d'inventaire orienté objet
+1 pour iTop. Le lien entre les objets se fait à l'import. Ex : 1 VM dépend d'un cluster qui dépend de plusieurs hyperviseurs qui dépendent chacun d'un serveur physique. Mais ensuite la gestion de l'analyse d'impact entre éléments est graphique : https://www.itophub.io/wiki/media?media=3_0_0%3Auser%3Aitop_analyse_impact_3.0.png C'est un peu long à modéliser mais le jeu en vaut la chandelle. Cordialement. -- Arnaud On Thu, 20 Jan 2022 at 10:22, Dominique Rousseau wrote: > Le Thu, Jan 20, 2022 at 09:53:29AM +0100, Frederic Hermann [ > fhe-fr...@neptune.fr] a écrit: > > Bonjour Fabien, > > > > iTop de Combodo (https://www.itophub.io/page/about-itop) est un CMDB > > qui qui pourrait correspondre. > > +1 > > J'utilise pas iTop, mais c'est ce à quoi j'ai tout de suite pensé en > lisant la question. > > > -- > Dominique Rousseau > Neuronnexion, Prestataire Internet & Intranet > 6 rue des Hautes cornes - 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/
Re: [FRnOG] [MISC] VPN pour IP Fixe
Hello, Voici un setup que j'ai chez moi pour du flux principalement entrant : Annonce ARP de l'IP failover sur l'interface du routeur publique. Route statique sur le routeur publique de cette IP failover via le tunnel VPN. Loopback sur le routeur maison avec l'IP publique failover Routé de bout en bout et pas de NAT. La techno du tunnel n'a pas d'importance. Pour les flux initiés par le routeur maison il est possible de rajouter l'IP failover comme source dans la default. Si ton flux doit arriver derrière ton routeur maison tu peux étendre le routage sur le même principe (haproxy dans mon cas). Have fun -- Arnaud Gelly On Thu, 30 Jan 2020 at 15:51, Guillaume PUTIER via frnog wrote: > Hello, > > Je te confirme que ça bouge pas. > > J'ai pas mal de clients prennent des VM chez nous pour y balancer du mTCP, > mono ou multi. > Il y a une masse pas possible de script en ce sens sur github ! > > Amuse toi bien > > Cordialement > > -- > > > > Guillaume PUTIER > > 18 allée du Poète 01480 Savigneux > tel : +33 4 48 140 411 > guillaume.put...@shpv.fr > > > > Le 30/01/2020 15:46, « Kevin Labécot » de kevin.labe...@1001pneus.fr> a écrit : > > OpenMTCPRouter (opensource) > Ca monte un tunnel entre chez toi et un serveur. L'installation se > fait > en quelques lignes de commandes côté client et serveur. > > Ca marche du feu de dieu pour bridger des connexions WAN mais ça > marchera sans bidouille qu'avec 1 connexion aussi :) > > > > -- Message d'origine -- > De: "Anthony Bourguignon via frnog" > À: frnog-m...@frnog.org > Envoyé : 30/01/2020 15:28:44 > Objet : [FRnOG] [MISC] VPN pour IP Fixe > > >Bonjour, > > > >Je vous explique le souci. J'ai un fournisseur d'accès qui ne me > permet pas d'avoir une IPv4 fixe. > >Elle ne bouge pas souvent, mais elle peut sauter à leur bon vouloir. > En plus de tout ça, si je peux > >faire en sorte que le fournisseur en question ne voit pas mon trafic, > c'est encore mieux. > > > >Jusque là, j'utilisais le VPN de FDN. Sauf qu'il y a régulièrement > des soucis (pertes de paquets > >souvent à 10% le soir), donc j'aimerais m'en passer. > > > >J'ai un serveur dédié chez un fournisseur, qui dispose d'une IPv4 (en > plus d'un bloc IPv6). J'y ai > >ajouté une IPv4 Failover (qui n'est pour le moment pas configurée sur > le serveur). > > > >Je voudrais faire en sorte que le routeur chez moi (un pc sous > linux), récupère cette IP Failover > >via une solution VPN. Si je ne suis pas trop nul, c'est donc un VPN > L2 qu'il me faut. J'ai tenté > >avec OpenVPN. Le problème, c'est qu'il faut monter une interface > bridge et connecter l'interface tap > >à ce bridge. C'est un peu chiant. D'autant qu'une macvtap sera > parfaite dans ce cas. Sauf que si je > >créé l'interface macvtap et que j'essaye de connecter OpenVPN à cette > interface, ça ne fonctionne > >pas, OpenVPN ne démarre pas (erreur lors d'un ioctl). Il faudrait que > j'ouvre un bug d'ailleurs, > >mais j'ai jeté un œil, ça n'a pas l'air de bouger des masses sur le > tracker OpenVPN. > > > >Du coup, est-ce que vous connaissez une solution simple pour faire ce > que je souhaite ? Si possible, > >sans bridge et sans routage nécessaire sur le serveur distant (règles > dans le firewall). Je n'ai pas > >besoin de gestion d'utilisateurs côté serveur, mon routeur sera le > seul client du VPN. > > > >Merci d'avance pour vos suggestions. > > > > > >--- > >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] Multihoming BGP avec COGENT en principal et SFR en backup
Hello, Bêtement je dirais d'annoncer les 4 /24 sur Cogent et le /22 sur SFR. Cordialement. -- Arnaud On Thu, 7 Nov 2019 at 11:34, Eddy Minet wrote: > Bonjour la liste, > > Je suis en train de me casser la tête pour avoir un peer BGP SFR en rôle > de « backup » et malgré le prépend qui est fait à la fois sur notre AS et > sur celui de SFR j’ai toujours un gros pourcentage du traffic dessus. > Il semble que les routes via SFR même 3 fois plus longues soient préférées > chez la plupart des autres AS. > Sur les looking glass je m’aperçois que la local preference est quasiment > toujours meilleure sur le peering SFR. > Y a-t-il une communauté magique pour agir là-dessus ? > > Si certains d’entre vous on une idée sur la question je suis preneur de > tout indice pouvant mer permettre d’avancer, en réponse sur la liste ou en > privé > > Eddy > > > > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
