RE: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...

[Olivier Varenne via frnog]

Je regarderai ça lundi



Cordialement,
 


Olivier Varenne
Président, R&D et développement
T +33 (0)4 27 04 40 00 | ipconnect.fr

Suivez-nous ! 


> -Message d'origine-
> De : David Ponzone 
> Envoyé : vendredi 21 juin 2024 16:58
> À : Olivier Varenne 
> Cc : x.r...@sipleo.com; frnog-al...@frnog.org
> Objet : Re: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...
> 
> C’est pareil, collecte L2TP, donc MTU 1460 à priori.
> À 1492, ça passe avec DF=1 ?
> Ca m’étonnerait.
> 
> David
> 
> > Le 21 juin 2024 à 16:55, Olivier Varenne 
> a écrit :
> >
> > Pas de xDSL dans notre cas. Fibre FTTH.
> >
> >
> >
> > Cordialement,
> >
> >
> >
> > Olivier Varenne
> > Président, R&D et développement
> > T +33 (0)4 27 04 40 00 | ipconnect.fr
> >
> > Suivez-nous !
> >
> >
> >> -Message d'origine-
> >> De : Xavier ROCA  De la part de x.r...@sipleo.com
> >> Envoyé : vendredi 21 juin 2024 15:47 À : Olivier Varenne
> >>  Cc : frnog-al...@frnog.org; 'David
> Ponzone'
> >>  Objet : RE: [FRnOG] [ALERT] La gestion
> du
> >> MAN chez Alphalink...
> >>
> >> Pensez au réglage du MSS
> >> Pour un MTU de 1500, MSS à 1460
> >> Sur certains équipements, on a dû forcer le MSS, le réglage du MTU
> ne
> >> modifier pas automatiquement le MSS
> >>
> >> -Message d'origine-
> >> De : frnog-requ...@frnog.org  De la part
> de
> >> David Ponzone Envoyé : vendredi 21 juin 2024 15:05 À : Olivier
> >> Varenne  Cc : ALEGRI Rémy
> >> ; frnog-al...@frnog.org Objet : Re: [FRnOG]
> >> [ALERT] La gestion du MAN chez Alphalink...
> >>
> >> Si tu parles de PPP sur ADSL/VDSL (donc collecté en L2TP), ça
> devait
> >> plutôt être 1460.
> >> De mémoire, je crois que c’est ce qui posait des problèmes, les BAS
> >> SFR foutaient la merde dans la négo du MTU.
> >> J’ai éradiqué SFR en ADSL/VDSL il y a longtemps, ça a réglé le
> >> problème.
> >>
> >> Quand tu forces 1492, tu arrives à pinger l’autre côté avec
> size=1492
> >> et DF=1 ?
> >>
> >> David
> >>
> >>> Le 21 juin 2024 à 14:56, Olivier Varenne
> 
> >> a écrit :
> >>>
> >>> 1480 en ppp sur mikrotik oui.
> >>> Et oui, nos soucis sont sur SFR...
> >>>
> >>>
> >>>
> >>> Cordialement,
> >>>
> >>>
> >>>
> >>> Olivier Varenne
> >>> Président, R&D et développement
> >>> T +33 (0)4 27 04 40 00 | ipconnect.fr
> >>>
> >>> Suivez-nous !
> >>>
> >>>
>  -Message d'origine-
>  De : David Ponzone  Envoyé :
> vendredi
> >> 21
>  juin 2024 14:47 À : Olivier Varenne  Cc
> :
>  ALEGRI Rémy ; frnog-al...@frnog.org Objet :
> Re:
>  [FRnOG] [ALERT] La gestion du MAN chez Alphalink...
> 
>  1480 par défaut sur un Mikrotik ?
>  Sur une interface PPP alors.
> 
>  Et ça serait pas SFR le lien ?
>  Parce que négo foireuse de MTU automatique, ça sent bon SFR
> en
> >> DSL.
>  Ou alors config foireuse du LNS (Alphalink je suppose, mais tu as
>  la main dessus non ?).
> 
>  David
> 
> > Le 21 juin 2024 à 14:38, Olivier Varenne via frnog
> >> 
>  a écrit :
> >
> > Salut remy
> > Tu vas bien ?
> >
> > On a des soucis vraiment etranges.
> > En effet certaines fois le MTU est en cause. Alphalink se
> > retranche sur le fait que les STAS indiquent un MTU à 1492.
> Mais
> > certains
>  équipements clients ont parfois des MTU inférieures (1480
> souvent,
> >> ce
>  qui est le cas par défaut des mikrotik) En spécifiant 1492 on
>  arrive dans le cas des krotik a résoudre le soucis, mais dans
>  d’autres cas
> >> non.
> >
> > Ce qui me chiffonne c’est que sauf erreur de ma part la RFC
> >> indique
>  qu’il est vraiment conseillé de passer en TCP en cas de
>  fragmentation, mais alphalink refuse catégoriquement l’emploi de
> >> TCP.
> >
> >
> >
> > Cordialement,
> >
> >
> > [cid:image001.png@01DAC3E8.8234D360]
> > Olivier Varenne
> > Président, R&D et développement
> > T +33 (0)4 27 04 40 00 |
> ipconnect.fr
> >
> > Suivez-nous !
> > [picto-twitter][picto-
>  youtube] >
> 
> >>
> tps://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug>[picto-
>  linkedin
> > ]
> >
> > De : ALEGRI Rémy  Envoyé : vendredi 21
> juin
> >> 2024
> > 14:22 À : Olivier Varenne  Cc :
> > frnog-al...@frnog.org Objet : Re: [FRnOG] [ALERT] La gestion du
> >> MAN
> > chez Alphalink...
> >
> >
> > Bonjour,
> >
> > D'après mon expertise, certains IPBX, comme des Alcatel, ne
>  supportent pas le Header Identity. Cependant, il est plus probable
>  que le lien réseau n'ait pas une MTU de 1500, ce qui empêche
> les
>  INVITE d'arriver correctement en UDP.
> >
> > Olivier, je te recommande de tester la MTU du lien sous Linux
> avec
> > la commande suivante pour une MTU de 1500
> >
> > ping -M do -s 1472 1.1.1.1
> >
> >
> >
> > Je confirme qu'Alphalink

Re: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...

[Hugues Voiturier]

Vous avez pas de MTU 1500 sur vos collectes FTTH PPPoE ? 

C’est quand même vachement plus pratique :-)

Hugues

Hugues Voiturier
Consultant en architecture réseau
AS2027

> On 21 Jun 2024, at 16:57, David Ponzone  wrote:
> 
> C’est pareil, collecte L2TP, donc MTU 1460 à priori.
> À 1492, ça passe avec DF=1 ?
> Ca m’étonnerait.
> 
> David
> 
>> Le 21 juin 2024 à 16:55, Olivier Varenne  a écrit :
>> 
>> Pas de xDSL dans notre cas. Fibre FTTH.
>> 
>> 
>> 
>> Cordialement,
>> 
>> 
>> 
>> Olivier Varenne
>> Président, R&D et développement
>> T +33 (0)4 27 04 40 00 | ipconnect.fr
>> 
>> Suivez-nous ! 
>> 
>> 
>>> -Message d'origine-
>>> De : Xavier ROCA  De la part de x.r...@sipleo.com
>>> Envoyé : vendredi 21 juin 2024 15:47
>>> À : Olivier Varenne 
>>> Cc : frnog-al...@frnog.org; 'David Ponzone' 
>>> Objet : RE: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...
>>> 
>>> Pensez au réglage du MSS
>>> Pour un MTU de 1500, MSS à 1460
>>> Sur certains équipements, on a dû forcer le MSS, le réglage du MTU ne
>>> modifier pas automatiquement le MSS
>>> 
>>> -Message d'origine-
>>> De : frnog-requ...@frnog.org  De la part de
>>> David Ponzone Envoyé : vendredi 21 juin 2024 15:05 À : Olivier
>>> Varenne  Cc : ALEGRI Rémy
>>> ; frnog-al...@frnog.org Objet : Re: [FRnOG] [ALERT]
>>> La gestion du MAN chez Alphalink...
>>> 
>>> Si tu parles de PPP sur ADSL/VDSL (donc collecté en L2TP), ça devait
>>> plutôt être 1460.
>>> De mémoire, je crois que c’est ce qui posait des problèmes, les BAS
>>> SFR foutaient la merde dans la négo du MTU.
>>> J’ai éradiqué SFR en ADSL/VDSL il y a longtemps, ça a réglé le
>>> problème.
>>> 
>>> Quand tu forces 1492, tu arrives à pinger l’autre côté avec size=1492
>>> et DF=1 ?
>>> 
>>> David
>>> 
 Le 21 juin 2024 à 14:56, Olivier Varenne 
>>> a écrit :
 
 1480 en ppp sur mikrotik oui.
 Et oui, nos soucis sont sur SFR...
 
 
 
 Cordialement,
 
 
 
 Olivier Varenne
 Président, R&D et développement
 T +33 (0)4 27 04 40 00 | ipconnect.fr
 
 Suivez-nous !
 
 
> -Message d'origine-
> De : David Ponzone  Envoyé : vendredi
>>> 21
> juin 2024 14:47 À : Olivier Varenne  Cc :
> ALEGRI Rémy ; frnog-al...@frnog.org Objet : Re:
> [FRnOG] [ALERT] La gestion du MAN chez Alphalink...
> 
> 1480 par défaut sur un Mikrotik ?
> Sur une interface PPP alors.
> 
> Et ça serait pas SFR le lien ?
> Parce que négo foireuse de MTU automatique, ça sent bon SFR en
>>> DSL.
> Ou alors config foireuse du LNS (Alphalink je suppose, mais tu as la
> main dessus non ?).
> 
> David
> 
>> Le 21 juin 2024 à 14:38, Olivier Varenne via frnog
>>> 
> a écrit :
>> 
>> Salut remy
>> Tu vas bien ?
>> 
>> On a des soucis vraiment etranges.
>> En effet certaines fois le MTU est en cause. Alphalink se retranche
>> sur le fait que les STAS indiquent un MTU à 1492. Mais certains
> équipements clients ont parfois des MTU inférieures (1480 souvent,
>>> ce
> qui est le cas par défaut des mikrotik) En spécifiant 1492 on arrive
> dans le cas des krotik a résoudre le soucis, mais dans d’autres cas
>>> non.
>> 
>> Ce qui me chiffonne c’est que sauf erreur de ma part la RFC
>>> indique
> qu’il est vraiment conseillé de passer en TCP en cas de
> fragmentation, mais alphalink refuse catégoriquement l’emploi de
>>> TCP.
>> 
>> 
>> 
>> Cordialement,
>> 
>> 
>> [cid:image001.png@01DAC3E8.8234D360]
>> Olivier Varenne
>> Président, R&D et développement
>> T +33 (0)4 27 04 40 00 | ipconnect.fr
>> 
>> Suivez-nous !
>> [picto-twitter][picto-
> youtube]> 
> 
>>> tps://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug>[picto-
> linkedin
>> ]
>> 
>> De : ALEGRI Rémy  Envoyé : vendredi 21 juin
>>> 2024
>> 14:22 À : Olivier Varenne  Cc :
>> frnog-al...@frnog.org Objet : Re: [FRnOG] [ALERT] La gestion du
>>> MAN
>> chez Alphalink...
>> 
>> 
>> Bonjour,
>> 
>> D'après mon expertise, certains IPBX, comme des Alcatel, ne
> supportent pas le Header Identity. Cependant, il est plus probable
> que le lien réseau n'ait pas une MTU de 1500, ce qui empêche les
> INVITE d'arriver correctement en UDP.
>> 
>> Olivier, je te recommande de tester la MTU du lien sous Linux avec
>> la commande suivante pour une MTU de 1500
>> 
>> ping -M do -s 1472 1.1.1.1
>> 
>> 
>> 
>> Je confirme qu'Alphalink transmet les INVITE avec le Header
>>> Identity :
>> 2024/06/21 14:06:45.559654 alphalink:5060 -> ipbx:5060
>>> INVITE
>> sip:0x@ipbx:5060 SIP/2.0
>> Via: SIP/2.0/UDP
>>> alphalink:5060;branch=z9hG4bKfb2c.e3208024.0
>> Max-Forwards: 69
>> From:
>>> ;tag=as4e911d28
>> To: 

Re: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...

[David Ponzone]

C’est pareil, collecte L2TP, donc MTU 1460 à priori.
À 1492, ça passe avec DF=1 ?
Ca m’étonnerait.

David

> Le 21 juin 2024 à 16:55, Olivier Varenne  a écrit :
> 
> Pas de xDSL dans notre cas. Fibre FTTH.
> 
> 
> 
> Cordialement,
>  
> 
> 
> Olivier Varenne
> Président, R&D et développement
> T +33 (0)4 27 04 40 00 | ipconnect.fr
> 
> Suivez-nous ! 
> 
> 
>> -Message d'origine-
>> De : Xavier ROCA  De la part de x.r...@sipleo.com
>> Envoyé : vendredi 21 juin 2024 15:47
>> À : Olivier Varenne 
>> Cc : frnog-al...@frnog.org; 'David Ponzone' 
>> Objet : RE: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...
>> 
>> Pensez au réglage du MSS
>> Pour un MTU de 1500, MSS à 1460
>> Sur certains équipements, on a dû forcer le MSS, le réglage du MTU ne
>> modifier pas automatiquement le MSS
>> 
>> -Message d'origine-
>> De : frnog-requ...@frnog.org  De la part de
>> David Ponzone Envoyé : vendredi 21 juin 2024 15:05 À : Olivier
>> Varenne  Cc : ALEGRI Rémy
>> ; frnog-al...@frnog.org Objet : Re: [FRnOG] [ALERT]
>> La gestion du MAN chez Alphalink...
>> 
>> Si tu parles de PPP sur ADSL/VDSL (donc collecté en L2TP), ça devait
>> plutôt être 1460.
>> De mémoire, je crois que c’est ce qui posait des problèmes, les BAS
>> SFR foutaient la merde dans la négo du MTU.
>> J’ai éradiqué SFR en ADSL/VDSL il y a longtemps, ça a réglé le
>> problème.
>> 
>> Quand tu forces 1492, tu arrives à pinger l’autre côté avec size=1492
>> et DF=1 ?
>> 
>> David
>> 
>>> Le 21 juin 2024 à 14:56, Olivier Varenne 
>> a écrit :
>>> 
>>> 1480 en ppp sur mikrotik oui.
>>> Et oui, nos soucis sont sur SFR...
>>> 
>>> 
>>> 
>>> Cordialement,
>>> 
>>> 
>>> 
>>> Olivier Varenne
>>> Président, R&D et développement
>>> T +33 (0)4 27 04 40 00 | ipconnect.fr
>>> 
>>> Suivez-nous !
>>> 
>>> 
 -Message d'origine-
 De : David Ponzone  Envoyé : vendredi
>> 21
 juin 2024 14:47 À : Olivier Varenne  Cc :
 ALEGRI Rémy ; frnog-al...@frnog.org Objet : Re:
 [FRnOG] [ALERT] La gestion du MAN chez Alphalink...
 
 1480 par défaut sur un Mikrotik ?
 Sur une interface PPP alors.
 
 Et ça serait pas SFR le lien ?
 Parce que négo foireuse de MTU automatique, ça sent bon SFR en
>> DSL.
 Ou alors config foireuse du LNS (Alphalink je suppose, mais tu as la
 main dessus non ?).
 
 David
 
> Le 21 juin 2024 à 14:38, Olivier Varenne via frnog
>> 
 a écrit :
> 
> Salut remy
> Tu vas bien ?
> 
> On a des soucis vraiment etranges.
> En effet certaines fois le MTU est en cause. Alphalink se retranche
> sur le fait que les STAS indiquent un MTU à 1492. Mais certains
 équipements clients ont parfois des MTU inférieures (1480 souvent,
>> ce
 qui est le cas par défaut des mikrotik) En spécifiant 1492 on arrive
 dans le cas des krotik a résoudre le soucis, mais dans d’autres cas
>> non.
> 
> Ce qui me chiffonne c’est que sauf erreur de ma part la RFC
>> indique
 qu’il est vraiment conseillé de passer en TCP en cas de
 fragmentation, mais alphalink refuse catégoriquement l’emploi de
>> TCP.
> 
> 
> 
> Cordialement,
> 
> 
> [cid:image001.png@01DAC3E8.8234D360]
> Olivier Varenne
> Président, R&D et développement
> T +33 (0)4 27 04 40 00 | ipconnect.fr
> 
> Suivez-nous !
> [picto-twitter][picto-
 youtube] 
 
>> tps://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug>[picto-
 linkedin
> ]
> 
> De : ALEGRI Rémy  Envoyé : vendredi 21 juin
>> 2024
> 14:22 À : Olivier Varenne  Cc :
> frnog-al...@frnog.org Objet : Re: [FRnOG] [ALERT] La gestion du
>> MAN
> chez Alphalink...
> 
> 
> Bonjour,
> 
> D'après mon expertise, certains IPBX, comme des Alcatel, ne
 supportent pas le Header Identity. Cependant, il est plus probable
 que le lien réseau n'ait pas une MTU de 1500, ce qui empêche les
 INVITE d'arriver correctement en UDP.
> 
> Olivier, je te recommande de tester la MTU du lien sous Linux avec
> la commande suivante pour une MTU de 1500
> 
> ping -M do -s 1472 1.1.1.1
> 
> 
> 
> Je confirme qu'Alphalink transmet les INVITE avec le Header
>> Identity :
> 2024/06/21 14:06:45.559654 alphalink:5060 -> ipbx:5060
>> INVITE
> sip:0x@ipbx:5060 SIP/2.0
> Via: SIP/2.0/UDP
>> alphalink:5060;branch=z9hG4bKfb2c.e3208024.0
> Max-Forwards: 69
> From:
>> ;tag=as4e911d28
> To: 
> Contact: 
> Call-ID: 16xx5643c450f8@alphalink2:5060
> CSeq: 102 INVITE
> P-Early-Media: supported
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
> Supported: timer
> Identity:
> 
> xx
> 
> xx
> xx

Re: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...

[David Ponzone]

A priori, il est en SIP UDP, donc ça le concerne pas :)

Mais sinon tu as raison, vaut mieux, en tout cas pour éviter les cas tordus.

David

> Le 21 juin 2024 à 15:46,   a écrit :
> 
> Pensez au réglage du MSS
> Pour un MTU de 1500, MSS à 1460
> Sur certains équipements, on a dû forcer le MSS, le réglage du MTU ne 
> modifier pas automatiquement le MSS
> 
> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de David 
> Ponzone
> Envoyé : vendredi 21 juin 2024 15:05
> À : Olivier Varenne 
> Cc : ALEGRI Rémy ; frnog-al...@frnog.org
> Objet : Re: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...
> 
> Si tu parles de PPP sur ADSL/VDSL (donc collecté en L2TP), ça devait plutôt 
> être 1460.
> De mémoire, je crois que c’est ce qui posait des problèmes, les BAS SFR 
> foutaient la merde dans la négo du MTU.
> J’ai éradiqué SFR en ADSL/VDSL il y a longtemps, ça a réglé le problème.
> 
> Quand tu forces 1492, tu arrives à pinger l’autre côté avec size=1492 et DF=1 
> ?
> 
> David
> 
>> Le 21 juin 2024 à 14:56, Olivier Varenne  a écrit :
>> 
>> 1480 en ppp sur mikrotik oui.
>> Et oui, nos soucis sont sur SFR...
>> 
>> 
>> 
>> Cordialement,
>> 
>> 
>> 
>> Olivier Varenne
>> Président, R&D et développement
>> T +33 (0)4 27 04 40 00 | ipconnect.fr
>> 
>> Suivez-nous ! 
>> 
>> 
>>> -Message d'origine-
>>> De : David Ponzone  Envoyé : vendredi 21 
>>> juin 2024 14:47 À : Olivier Varenne  Cc : 
>>> ALEGRI Rémy ; frnog-al...@frnog.org Objet : Re: 
>>> [FRnOG] [ALERT] La gestion du MAN chez Alphalink...
>>> 
>>> 1480 par défaut sur un Mikrotik ?
>>> Sur une interface PPP alors.
>>> 
>>> Et ça serait pas SFR le lien ?
>>> Parce que négo foireuse de MTU automatique, ça sent bon SFR en DSL.
>>> Ou alors config foireuse du LNS (Alphalink je suppose, mais tu as la 
>>> main dessus non ?).
>>> 
>>> David
>>> 
 Le 21 juin 2024 à 14:38, Olivier Varenne via frnog 
>>> a écrit :
 
 Salut remy
 Tu vas bien ?
 
 On a des soucis vraiment etranges.
 En effet certaines fois le MTU est en cause. Alphalink se retranche 
 sur le fait que les STAS indiquent un MTU à 1492. Mais certains
>>> équipements clients ont parfois des MTU inférieures (1480 souvent, ce 
>>> qui est le cas par défaut des mikrotik) En spécifiant 1492 on arrive 
>>> dans le cas des krotik a résoudre le soucis, mais dans d’autres cas non.
 
 Ce qui me chiffonne c’est que sauf erreur de ma part la RFC indique
>>> qu’il est vraiment conseillé de passer en TCP en cas de 
>>> fragmentation, mais alphalink refuse catégoriquement l’emploi de TCP.
 
 
 
 Cordialement,
 
 
 [cid:image001.png@01DAC3E8.8234D360]
 Olivier Varenne
 Président, R&D et développement
 T +33 (0)4 27 04 40 00 | ipconnect.fr
 
 Suivez-nous !
 [picto-twitter][picto-
>>> youtube]>>> 
>>> tps://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug>[picto-
>>> linkedin
 ]
 
 De : ALEGRI Rémy  Envoyé : vendredi 21 juin 2024 
 14:22 À : Olivier Varenne  Cc :
 frnog-al...@frnog.org Objet : Re: [FRnOG] [ALERT] La gestion du MAN 
 chez Alphalink...
 
 
 Bonjour,
 
 D'après mon expertise, certains IPBX, comme des Alcatel, ne
>>> supportent pas le Header Identity. Cependant, il est plus probable 
>>> que le lien réseau n'ait pas une MTU de 1500, ce qui empêche les 
>>> INVITE d'arriver correctement en UDP.
 
 Olivier, je te recommande de tester la MTU du lien sous Linux avec 
 la commande suivante pour une MTU de 1500
 
 ping -M do -s 1472 1.1.1.1
 
 
 
 Je confirme qu'Alphalink transmet les INVITE avec le Header Identity :
 2024/06/21 14:06:45.559654 alphalink:5060 -> ipbx:5060 INVITE
 sip:0x@ipbx:5060 SIP/2.0
 Via: SIP/2.0/UDP alphalink:5060;branch=z9hG4bKfb2c.e3208024.0
 Max-Forwards: 69
 From: ;tag=as4e911d28
 To: 
 Contact: 
 Call-ID: 16xx5643c450f8@alphalink2:5060
 CSeq: 102 INVITE
 P-Early-Media: supported
 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
 Supported: timer
 Identity:
 
 xx 
 
 xx 
 
 xx 
 
 xx 
 
 xx 
 
 -g 
 ;info=;al
 g=
 ES256;ppt=shaken
 Content-Type: application/sdp
 Content-Length: 403
 
 Par contre, il n'y a pas la classification de l'appel.
 
 Bien cordialement,
 ALEGRI Ré

RE: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...

[Olivier Varenne via frnog]

Pas de xDSL dans notre cas. Fibre FTTH.



Cordialement,
 


Olivier Varenne
Président, R&D et développement
T +33 (0)4 27 04 40 00 | ipconnect.fr

Suivez-nous ! 


> -Message d'origine-
> De : Xavier ROCA  De la part de x.r...@sipleo.com
> Envoyé : vendredi 21 juin 2024 15:47
> À : Olivier Varenne 
> Cc : frnog-al...@frnog.org; 'David Ponzone' 
> Objet : RE: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...
> 
> Pensez au réglage du MSS
> Pour un MTU de 1500, MSS à 1460
> Sur certains équipements, on a dû forcer le MSS, le réglage du MTU ne
> modifier pas automatiquement le MSS
> 
> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de
> David Ponzone Envoyé : vendredi 21 juin 2024 15:05 À : Olivier
> Varenne  Cc : ALEGRI Rémy
> ; frnog-al...@frnog.org Objet : Re: [FRnOG] [ALERT]
> La gestion du MAN chez Alphalink...
> 
> Si tu parles de PPP sur ADSL/VDSL (donc collecté en L2TP), ça devait
> plutôt être 1460.
> De mémoire, je crois que c’est ce qui posait des problèmes, les BAS
> SFR foutaient la merde dans la négo du MTU.
> J’ai éradiqué SFR en ADSL/VDSL il y a longtemps, ça a réglé le
> problème.
> 
> Quand tu forces 1492, tu arrives à pinger l’autre côté avec size=1492
> et DF=1 ?
> 
> David
> 
> > Le 21 juin 2024 à 14:56, Olivier Varenne 
> a écrit :
> >
> > 1480 en ppp sur mikrotik oui.
> > Et oui, nos soucis sont sur SFR...
> >
> >
> >
> > Cordialement,
> >
> >
> >
> > Olivier Varenne
> > Président, R&D et développement
> > T +33 (0)4 27 04 40 00 | ipconnect.fr
> >
> > Suivez-nous !
> >
> >
> >> -Message d'origine-
> >> De : David Ponzone  Envoyé : vendredi
> 21
> >> juin 2024 14:47 À : Olivier Varenne  Cc :
> >> ALEGRI Rémy ; frnog-al...@frnog.org Objet : Re:
> >> [FRnOG] [ALERT] La gestion du MAN chez Alphalink...
> >>
> >> 1480 par défaut sur un Mikrotik ?
> >> Sur une interface PPP alors.
> >>
> >> Et ça serait pas SFR le lien ?
> >> Parce que négo foireuse de MTU automatique, ça sent bon SFR en
> DSL.
> >> Ou alors config foireuse du LNS (Alphalink je suppose, mais tu as la
> >> main dessus non ?).
> >>
> >> David
> >>
> >>> Le 21 juin 2024 à 14:38, Olivier Varenne via frnog
> 
> >> a écrit :
> >>>
> >>> Salut remy
> >>> Tu vas bien ?
> >>>
> >>> On a des soucis vraiment etranges.
> >>> En effet certaines fois le MTU est en cause. Alphalink se retranche
> >>> sur le fait que les STAS indiquent un MTU à 1492. Mais certains
> >> équipements clients ont parfois des MTU inférieures (1480 souvent,
> ce
> >> qui est le cas par défaut des mikrotik) En spécifiant 1492 on arrive
> >> dans le cas des krotik a résoudre le soucis, mais dans d’autres cas
> non.
> >>>
> >>> Ce qui me chiffonne c’est que sauf erreur de ma part la RFC
> indique
> >> qu’il est vraiment conseillé de passer en TCP en cas de
> >> fragmentation, mais alphalink refuse catégoriquement l’emploi de
> TCP.
> >>>
> >>>
> >>>
> >>> Cordialement,
> >>>
> >>>
> >>> [cid:image001.png@01DAC3E8.8234D360]
> >>> Olivier Varenne
> >>> Président, R&D et développement
> >>> T +33 (0)4 27 04 40 00 | ipconnect.fr
> >>>
> >>> Suivez-nous !
> >>> [picto-twitter][picto-
> >> youtube] >>>
> >>
> tps://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug>[picto-
> >> linkedin
> >>> ]
> >>>
> >>> De : ALEGRI Rémy  Envoyé : vendredi 21 juin
> 2024
> >>> 14:22 À : Olivier Varenne  Cc :
> >>> frnog-al...@frnog.org Objet : Re: [FRnOG] [ALERT] La gestion du
> MAN
> >>> chez Alphalink...
> >>>
> >>>
> >>> Bonjour,
> >>>
> >>> D'après mon expertise, certains IPBX, comme des Alcatel, ne
> >> supportent pas le Header Identity. Cependant, il est plus probable
> >> que le lien réseau n'ait pas une MTU de 1500, ce qui empêche les
> >> INVITE d'arriver correctement en UDP.
> >>>
> >>> Olivier, je te recommande de tester la MTU du lien sous Linux avec
> >>> la commande suivante pour une MTU de 1500
> >>>
> >>> ping -M do -s 1472 1.1.1.1
> >>>
> >>>
> >>>
> >>> Je confirme qu'Alphalink transmet les INVITE avec le Header
> Identity :
> >>> 2024/06/21 14:06:45.559654 alphalink:5060 -> ipbx:5060
> INVITE
> >>> sip:0x@ipbx:5060 SIP/2.0
> >>> Via: SIP/2.0/UDP
> alphalink:5060;branch=z9hG4bKfb2c.e3208024.0
> >>> Max-Forwards: 69
> >>> From:
> ;tag=as4e911d28
> >>> To: 
> >>> Contact: 
> >>> Call-ID: 16xx5643c450f8@alphalink2:5060
> >>> CSeq: 102 INVITE
> >>> P-Early-Media: supported
> >>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
> >>> Supported: timer
> >>> Identity:
> >>> 
> >>> xx
> >>> 
> >>> xx
> >>> 
> >>> xx
> >>> 
> >>> xx
> >>> 
> >>> xx
> >>> 

RE: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...

[x.roca]

Pensez au réglage du MSS
Pour un MTU de 1500, MSS à 1460
Sur certains équipements, on a dû forcer le MSS, le réglage du MTU ne modifier 
pas automatiquement le MSS

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de David 
Ponzone
Envoyé : vendredi 21 juin 2024 15:05
À : Olivier Varenne 
Cc : ALEGRI Rémy ; frnog-al...@frnog.org
Objet : Re: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...

Si tu parles de PPP sur ADSL/VDSL (donc collecté en L2TP), ça devait plutôt 
être 1460.
De mémoire, je crois que c’est ce qui posait des problèmes, les BAS SFR 
foutaient la merde dans la négo du MTU.
J’ai éradiqué SFR en ADSL/VDSL il y a longtemps, ça a réglé le problème.

Quand tu forces 1492, tu arrives à pinger l’autre côté avec size=1492 et DF=1 ?

David

> Le 21 juin 2024 à 14:56, Olivier Varenne  a écrit :
> 
> 1480 en ppp sur mikrotik oui.
> Et oui, nos soucis sont sur SFR...
> 
> 
> 
> Cordialement,
>  
> 
> 
> Olivier Varenne
> Président, R&D et développement
> T +33 (0)4 27 04 40 00 | ipconnect.fr
> 
> Suivez-nous ! 
> 
> 
>> -Message d'origine-
>> De : David Ponzone  Envoyé : vendredi 21 
>> juin 2024 14:47 À : Olivier Varenne  Cc : 
>> ALEGRI Rémy ; frnog-al...@frnog.org Objet : Re: 
>> [FRnOG] [ALERT] La gestion du MAN chez Alphalink...
>> 
>> 1480 par défaut sur un Mikrotik ?
>> Sur une interface PPP alors.
>> 
>> Et ça serait pas SFR le lien ?
>> Parce que négo foireuse de MTU automatique, ça sent bon SFR en DSL.
>> Ou alors config foireuse du LNS (Alphalink je suppose, mais tu as la 
>> main dessus non ?).
>> 
>> David
>> 
>>> Le 21 juin 2024 à 14:38, Olivier Varenne via frnog 
>> a écrit :
>>> 
>>> Salut remy
>>> Tu vas bien ?
>>> 
>>> On a des soucis vraiment etranges.
>>> En effet certaines fois le MTU est en cause. Alphalink se retranche 
>>> sur le fait que les STAS indiquent un MTU à 1492. Mais certains
>> équipements clients ont parfois des MTU inférieures (1480 souvent, ce 
>> qui est le cas par défaut des mikrotik) En spécifiant 1492 on arrive 
>> dans le cas des krotik a résoudre le soucis, mais dans d’autres cas non.
>>> 
>>> Ce qui me chiffonne c’est que sauf erreur de ma part la RFC indique
>> qu’il est vraiment conseillé de passer en TCP en cas de 
>> fragmentation, mais alphalink refuse catégoriquement l’emploi de TCP.
>>> 
>>> 
>>> 
>>> Cordialement,
>>> 
>>> 
>>> [cid:image001.png@01DAC3E8.8234D360]
>>> Olivier Varenne
>>> Président, R&D et développement
>>> T +33 (0)4 27 04 40 00 | ipconnect.fr
>>> 
>>> Suivez-nous !
>>> [picto-twitter][picto-
>> youtube]>> 
>> tps://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug>[picto-
>> linkedin
>>> ]
>>> 
>>> De : ALEGRI Rémy  Envoyé : vendredi 21 juin 2024 
>>> 14:22 À : Olivier Varenne  Cc :
>>> frnog-al...@frnog.org Objet : Re: [FRnOG] [ALERT] La gestion du MAN 
>>> chez Alphalink...
>>> 
>>> 
>>> Bonjour,
>>> 
>>> D'après mon expertise, certains IPBX, comme des Alcatel, ne
>> supportent pas le Header Identity. Cependant, il est plus probable 
>> que le lien réseau n'ait pas une MTU de 1500, ce qui empêche les 
>> INVITE d'arriver correctement en UDP.
>>> 
>>> Olivier, je te recommande de tester la MTU du lien sous Linux avec 
>>> la commande suivante pour une MTU de 1500
>>> 
>>> ping -M do -s 1472 1.1.1.1
>>> 
>>> 
>>> 
>>> Je confirme qu'Alphalink transmet les INVITE avec le Header Identity :
>>> 2024/06/21 14:06:45.559654 alphalink:5060 -> ipbx:5060 INVITE
>>> sip:0x@ipbx:5060 SIP/2.0
>>> Via: SIP/2.0/UDP alphalink:5060;branch=z9hG4bKfb2c.e3208024.0
>>> Max-Forwards: 69
>>> From: ;tag=as4e911d28
>>> To: 
>>> Contact: 
>>> Call-ID: 16xx5643c450f8@alphalink2:5060
>>> CSeq: 102 INVITE
>>> P-Early-Media: supported
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
>>> Supported: timer
>>> Identity:
>>> 
>>> xx 
>>> 
>>> xx 
>>> 
>>> xx 
>>> 
>>> xx 
>>> 
>>> xx 
>>> 
>>> -g 
>>> ;info=;al
>>> g=
>>> ES256;ppt=shaken
>>> Content-Type: application/sdp
>>> Content-Length: 403
>>> 
>>> Par contre, il n'y a pas la classification de l'appel.
>>> 
>>> Bien cordialement,
>>> ALEGRI Rémy
>>> 
>>> 
>>> 
>>> Le 2024-06-21 13:52, Alain Bieuzent a écrit :
>>> Ce voudrais donc dire qu'Alphalink envoit les header Identity aux 
>>> ipbx
>> des clients, ce qui est interdit...
>>> 
>>> Le 21/06/2024 12:45, « Benoît Gigarel »
>> mailto:bgiga...@izarralde.com>
>> >> a 
>> écrit :
>>> 
>

Re: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...

[David Ponzone]

Si tu parles de PPP sur ADSL/VDSL (donc collecté en L2TP), ça devait plutôt 
être 1460.
De mémoire, je crois que c’est ce qui posait des problèmes, les BAS SFR 
foutaient la merde dans la négo du MTU.
J’ai éradiqué SFR en ADSL/VDSL il y a longtemps, ça a réglé le problème.

Quand tu forces 1492, tu arrives à pinger l’autre côté avec size=1492 et DF=1 ?

David

> Le 21 juin 2024 à 14:56, Olivier Varenne  a écrit :
> 
> 1480 en ppp sur mikrotik oui.
> Et oui, nos soucis sont sur SFR...
> 
> 
> 
> Cordialement,
>  
> 
> 
> Olivier Varenne
> Président, R&D et développement
> T +33 (0)4 27 04 40 00 | ipconnect.fr
> 
> Suivez-nous ! 
> 
> 
>> -Message d'origine-
>> De : David Ponzone 
>> Envoyé : vendredi 21 juin 2024 14:47
>> À : Olivier Varenne 
>> Cc : ALEGRI Rémy ; frnog-al...@frnog.org
>> Objet : Re: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...
>> 
>> 1480 par défaut sur un Mikrotik ?
>> Sur une interface PPP alors.
>> 
>> Et ça serait pas SFR le lien ?
>> Parce que négo foireuse de MTU automatique, ça sent bon SFR en DSL.
>> Ou alors config foireuse du LNS (Alphalink je suppose, mais tu as la
>> main dessus non ?).
>> 
>> David
>> 
>>> Le 21 juin 2024 à 14:38, Olivier Varenne via frnog 
>> a écrit :
>>> 
>>> Salut remy
>>> Tu vas bien ?
>>> 
>>> On a des soucis vraiment etranges.
>>> En effet certaines fois le MTU est en cause. Alphalink se retranche
>>> sur le fait que les STAS indiquent un MTU à 1492. Mais certains
>> équipements clients ont parfois des MTU inférieures (1480 souvent, ce
>> qui est le cas par défaut des mikrotik) En spécifiant 1492 on arrive
>> dans le cas des krotik a résoudre le soucis, mais dans d’autres cas non.
>>> 
>>> Ce qui me chiffonne c’est que sauf erreur de ma part la RFC indique
>> qu’il est vraiment conseillé de passer en TCP en cas de fragmentation,
>> mais alphalink refuse catégoriquement l’emploi de TCP.
>>> 
>>> 
>>> 
>>> Cordialement,
>>> 
>>> 
>>> [cid:image001.png@01DAC3E8.8234D360]
>>> Olivier Varenne
>>> Président, R&D et développement
>>> T +33 (0)4 27 04 40 00 | ipconnect.fr
>>> 
>>> Suivez-nous !
>>> [picto-twitter][picto-
>> youtube]>> 
>> tps://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug>[picto-
>> linkedin
>>> ]
>>> 
>>> De : ALEGRI Rémy 
>>> Envoyé : vendredi 21 juin 2024 14:22
>>> À : Olivier Varenne  Cc :
>>> frnog-al...@frnog.org Objet : Re: [FRnOG] [ALERT] La gestion du MAN
>>> chez Alphalink...
>>> 
>>> 
>>> Bonjour,
>>> 
>>> D'après mon expertise, certains IPBX, comme des Alcatel, ne
>> supportent pas le Header Identity. Cependant, il est plus probable que
>> le lien réseau n'ait pas une MTU de 1500, ce qui empêche les INVITE
>> d'arriver correctement en UDP.
>>> 
>>> Olivier, je te recommande de tester la MTU du lien sous Linux avec la
>>> commande suivante pour une MTU de 1500
>>> 
>>> ping -M do -s 1472 1.1.1.1
>>> 
>>> 
>>> 
>>> Je confirme qu'Alphalink transmet les INVITE avec le Header Identity :
>>> 2024/06/21 14:06:45.559654 alphalink:5060 -> ipbx:5060 INVITE
>>> sip:0x@ipbx:5060 SIP/2.0
>>> Via: SIP/2.0/UDP alphalink:5060;branch=z9hG4bKfb2c.e3208024.0
>>> Max-Forwards: 69
>>> From: ;tag=as4e911d28
>>> To: 
>>> Contact: 
>>> Call-ID: 16xx5643c450f8@alphalink2:5060
>>> CSeq: 102 INVITE
>>> P-Early-Media: supported
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
>>> Supported: timer
>>> Identity:
>>> xx
>>> xx
>>> xx
>>> xx
>>> xx
>>> -g
>>> ;info=;alg=
>>> ES256;ppt=shaken
>>> Content-Type: application/sdp
>>> Content-Length: 403
>>> 
>>> Par contre, il n'y a pas la classification de l'appel.
>>> 
>>> Bien cordialement,
>>> ALEGRI Rémy
>>> 
>>> 
>>> 
>>> Le 2024-06-21 13:52, Alain Bieuzent a écrit :
>>> Ce voudrais donc dire qu'Alphalink envoit les header Identity aux ipbx
>> des clients, ce qui est interdit...
>>> 
>>> Le 21/06/2024 12:45, « Benoît Gigarel »
>> mailto:bgiga...@izarralde.com>
>> >> a
>> écrit :
>>> 
>>> 
>>> Bonjour à tous,
>>> 
>>> 
>>> Çà y est, on y est aussi... Nos clients connectés chez Alphalink nous
>>> appellent pour des problèmes d'appels depuis ce matin.
>>> 
>>> 
>>> Voici la dernière communication de Alphalink à 11h56.
>>> 
>>> 
>>> Statut de l'incident :
>>> Nous avons répertoriés des équipements comportant des anomalies :
>>> 1-Les IPBX wazo semblent ne pas gérer correctement les Invites
>> fragmentés.
>>> 2-Les équipement Mitel MIVB ne sont pas e

RE: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...

[Olivier Varenne via frnog]

1480 en ppp sur mikrotik oui.
Et oui, nos soucis sont sur SFR...



Cordialement,
 


Olivier Varenne
Président, R&D et développement
T +33 (0)4 27 04 40 00 | ipconnect.fr

Suivez-nous ! 


> -Message d'origine-
> De : David Ponzone 
> Envoyé : vendredi 21 juin 2024 14:47
> À : Olivier Varenne 
> Cc : ALEGRI Rémy ; frnog-al...@frnog.org
> Objet : Re: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...
> 
> 1480 par défaut sur un Mikrotik ?
> Sur une interface PPP alors.
> 
> Et ça serait pas SFR le lien ?
> Parce que négo foireuse de MTU automatique, ça sent bon SFR en DSL.
> Ou alors config foireuse du LNS (Alphalink je suppose, mais tu as la
> main dessus non ?).
> 
> David
> 
> > Le 21 juin 2024 à 14:38, Olivier Varenne via frnog 
> a écrit :
> >
> > Salut remy
> > Tu vas bien ?
> >
> > On a des soucis vraiment etranges.
> > En effet certaines fois le MTU est en cause. Alphalink se retranche
> > sur le fait que les STAS indiquent un MTU à 1492. Mais certains
> équipements clients ont parfois des MTU inférieures (1480 souvent, ce
> qui est le cas par défaut des mikrotik) En spécifiant 1492 on arrive
> dans le cas des krotik a résoudre le soucis, mais dans d’autres cas non.
> >
> > Ce qui me chiffonne c’est que sauf erreur de ma part la RFC indique
> qu’il est vraiment conseillé de passer en TCP en cas de fragmentation,
> mais alphalink refuse catégoriquement l’emploi de TCP.
> >
> >
> >
> > Cordialement,
> >
> >
> > [cid:image001.png@01DAC3E8.8234D360]
> > Olivier Varenne
> > Président, R&D et développement
> > T +33 (0)4 27 04 40 00 | ipconnect.fr
> >
> > Suivez-nous !
> > [picto-twitter][picto-
> youtube] >
> tps://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug>[picto-
> linkedin
> > ]
> >
> > De : ALEGRI Rémy 
> > Envoyé : vendredi 21 juin 2024 14:22
> > À : Olivier Varenne  Cc :
> > frnog-al...@frnog.org Objet : Re: [FRnOG] [ALERT] La gestion du MAN
> > chez Alphalink...
> >
> >
> > Bonjour,
> >
> > D'après mon expertise, certains IPBX, comme des Alcatel, ne
> supportent pas le Header Identity. Cependant, il est plus probable que
> le lien réseau n'ait pas une MTU de 1500, ce qui empêche les INVITE
> d'arriver correctement en UDP.
> >
> > Olivier, je te recommande de tester la MTU du lien sous Linux avec la
> > commande suivante pour une MTU de 1500
> >
> > ping -M do -s 1472 1.1.1.1
> >
> >
> >
> > Je confirme qu'Alphalink transmet les INVITE avec le Header Identity :
> > 2024/06/21 14:06:45.559654 alphalink:5060 -> ipbx:5060 INVITE
> > sip:0x@ipbx:5060 SIP/2.0
> > Via: SIP/2.0/UDP alphalink:5060;branch=z9hG4bKfb2c.e3208024.0
> > Max-Forwards: 69
> > From: ;tag=as4e911d28
> > To: 
> > Contact: 
> > Call-ID: 16xx5643c450f8@alphalink2:5060
> > CSeq: 102 INVITE
> > P-Early-Media: supported
> > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
> > Supported: timer
> > Identity:
> > xx
> > xx
> > xx
> > xx
> > xx
> > -g
> > ;info=;alg=
> > ES256;ppt=shaken
> > Content-Type: application/sdp
> > Content-Length: 403
> >
> > Par contre, il n'y a pas la classification de l'appel.
> >
> > Bien cordialement,
> > ALEGRI Rémy
> >
> >
> >
> > Le 2024-06-21 13:52, Alain Bieuzent a écrit :
> > Ce voudrais donc dire qu'Alphalink envoit les header Identity aux ipbx
> des clients, ce qui est interdit...
> >
> > Le 21/06/2024 12:45, « Benoît Gigarel »
> mailto:bgiga...@izarralde.com>
> >> a
> écrit :
> >
> >
> > Bonjour à tous,
> >
> >
> > Çà y est, on y est aussi... Nos clients connectés chez Alphalink nous
> > appellent pour des problèmes d'appels depuis ce matin.
> >
> >
> > Voici la dernière communication de Alphalink à 11h56.
> >
> >
> > Statut de l'incident :
> > Nous avons répertoriés des équipements comportant des anomalies :
> > 1-Les IPBX wazo semblent ne pas gérer correctement les Invites
> fragmentés.
> > 2-Les équipement Mitel MIVB ne sont pas en mesure de gérer les
> > Identity Header de plus de 500 caractères (Développement en cours
> de
> > Mitel pour augmenter cette valeur) 3-PABX PANASONIC NS700
> Versions
> > impactées :
> > Panasonic-MPR16-V006.01089/VSIPGW-V3.
> > Panasonic-MPR16-V008.00055/VSIPGW-V3.
> >
> >
> >
> >
> > Cordialement,
> > Benoît
> >
> >
> >
> >
> > -Message d'origine-
> > De : frnog-requ...@frnog.org
> > >
> > mailto:frn

Re: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...

[David Ponzone]

1480 par défaut sur un Mikrotik ?
Sur une interface PPP alors.

Et ça serait pas SFR le lien ?
Parce que négo foireuse de MTU automatique, ça sent bon SFR en DSL.
Ou alors config foireuse du LNS (Alphalink je suppose, mais tu as la main 
dessus non ?).

David

> Le 21 juin 2024 à 14:38, Olivier Varenne via frnog  a écrit :
> 
> Salut remy
> Tu vas bien ?
> 
> On a des soucis vraiment etranges.
> En effet certaines fois le MTU est en cause. Alphalink se retranche sur le 
> fait que les STAS indiquent un MTU à 1492. Mais certains équipements clients 
> ont parfois des MTU inférieures (1480 souvent, ce qui est le cas par défaut 
> des mikrotik)
> En spécifiant 1492 on arrive dans le cas des krotik a résoudre le soucis, 
> mais dans d’autres cas non.
> 
> Ce qui me chiffonne c’est que sauf erreur de ma part la RFC indique qu’il est 
> vraiment conseillé de passer en TCP en cas de fragmentation, mais alphalink 
> refuse catégoriquement l’emploi de TCP.
> 
> 
> 
> Cordialement,
> 
> 
> [cid:image001.png@01DAC3E8.8234D360]
> Olivier Varenne
> Président, R&D et développement
> T +33 (0)4 27 04 40 00 | ipconnect.fr
> 
> Suivez-nous !
> [picto-twitter][picto-youtube][picto-linkedin]
> 
> De : ALEGRI Rémy 
> Envoyé : vendredi 21 juin 2024 14:22
> À : Olivier Varenne 
> Cc : frnog-al...@frnog.org
> Objet : Re: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...
> 
> 
> Bonjour,
> 
> D'après mon expertise, certains IPBX, comme des Alcatel, ne supportent pas le 
> Header Identity. Cependant, il est plus probable que le lien réseau n'ait pas 
> une MTU de 1500, ce qui empêche les INVITE d'arriver correctement en UDP.
> 
> Olivier, je te recommande de tester la MTU du lien sous Linux avec la 
> commande suivante pour une MTU de 1500
> 
> ping -M do -s 1472 1.1.1.1
> 
> 
> 
> Je confirme qu'Alphalink transmet les INVITE avec le Header Identity :
> 2024/06/21 14:06:45.559654 alphalink:5060 -> ipbx:5060
> INVITE sip:0x@ipbx:5060 SIP/2.0
> Via: SIP/2.0/UDP alphalink:5060;branch=z9hG4bKfb2c.e3208024.0
> Max-Forwards: 69
> From: ;tag=as4e911d28
> To: 
> Contact: 
> Call-ID: 16xx5643c450f8@alphalink2:5060
> CSeq: 102 INVITE
> P-Early-Media: supported
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
> Supported: timer
> Identity: 
> xx-g;info=;alg=ES256;ppt=shaken
> Content-Type: application/sdp
> Content-Length: 403
> 
> Par contre, il n'y a pas la classification de l'appel.
> 
> Bien cordialement,
> ALEGRI Rémy
> 
> 
> 
> Le 2024-06-21 13:52, Alain Bieuzent a écrit :
> Ce voudrais donc dire qu'Alphalink envoit les header Identity aux ipbx des 
> clients, ce qui est interdit...
> 
> Le 21/06/2024 12:45, « Benoît Gigarel » 
> mailto:bgiga...@izarralde.com> 
> >> a écrit :
> 
> 
> Bonjour à tous,
> 
> 
> Çà y est, on y est aussi... Nos clients connectés chez Alphalink nous
> appellent pour des problèmes d'appels depuis ce matin.
> 
> 
> Voici la dernière communication de Alphalink à 11h56.
> 
> 
> Statut de l'incident :
> Nous avons répertoriés des équipements comportant des anomalies :
> 1-Les IPBX wazo semblent ne pas gérer correctement les Invites fragmentés.
> 2-Les équipement Mitel MIVB ne sont pas en mesure de gérer les Identity
> Header de plus de 500 caractères (Développement en cours de Mitel pour
> augmenter cette valeur)
> 3-PABX PANASONIC NS700
> Versions impactées :
> Panasonic-MPR16-V006.01089/VSIPGW-V3.
> Panasonic-MPR16-V008.00055/VSIPGW-V3.
> 
> 
> 
> 
> Cordialement,
> Benoît
> 
> 
> 
> 
> -Message d'origine-
> De : frnog-requ...@frnog.org 
> > 
> mailto:frnog-requ...@frnog.org> 
> >> De la part 
> de Jérôme
> RICHARD
> Envoyé : vendredi 21 juin 2024 12:37
> À : Alain Bieuzent mailto:alain.bieuz...@free.fr> 
> >
> Cc : Olivier Varenne mailto:o.vare...@ipconnect.fr> 
> >>; 
> frnog-al...@frnog.org 
> >
> Objet : Re: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...
> 
> 
> Pour l'identity je suis Ok.
> 
> 
> Pour l'info d'attestation je n'avais pas vu 

RE: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...

[Olivier Varenne via frnog]

>Quand tu dis que maintenant c'est la panique, ça veut dire qu'ils se posent 
>des questions ?

Au début "circulez y'a rien a voir", puis "ha oui peut être en effet mais c'est 
pas nous", et maintenant ils en sont à appeler les clients un par un... 


Cordialement,
 


Olivier Varenne
Président, R&D et développement
T +33 (0)4 27 04 40 00 | ipconnect.fr

Suivez-nous ! 


> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de
> Toti FRnOG
> Envoyé : vendredi 21 juin 2024 10:40
> À : frnog-al...@frnog.org
> Objet : Re: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...
> 
> Bonjour,
> On a aussi des soucis Alphalink sur une vieille plateforme qu'on essaye
> d'éteindre depuis 1 an.
> Ils ne sont pas très clairs et le problème n'est soit disant pas chez eux
> ...
> Quand tu dis que maintenant c'est la panique, ça veut dire qu'ils se
> posent des questions ?
> 
> Le ven. 21 juin 2024 à 10:00, David Ponzone
>  a écrit :
> 
> > Hmm Alphalink comme fournisseur ?
> >
> > David
> >
> > > Le 21 juin 2024 à 09:55, Olivier Varenne via frnog
> 
> > > a
> > écrit :
> > >
> > > On est les seuls à être très, TRES, impacté par la mise en place du
> > > man
> > chez alphalink depuis plusieurs jours ?
> > > On a du mal à identifier l'origine du problème : dans certains cas
> > > cela
> > semble être un problème de MTU et de paquet SIP fragmenté,
> d'autres
> > cas sont plus obscurs...
> > > Je suis un peu étonné de rien avoir vu circuler ici, à croire qu'on
> > > est
> > un cas isolé ?
> > > Comment souvent : communication proche du 0, au début quand
> on a
> > > remonté
> > les soucis on nous a gentiment envoyé balader genre « c'est pas notre
> > probleme », et maintenant ça semble être la panique.
> > >
> > >
> > >
> > > Cordialement,
> > >
> > >
> > > [cid:image001.png@01DAC3C1.1D673B20]
> > > Olivier Varenne
> > > Président, R&D et développement
> > > T +33 (0)4 27 04 40 00 | ipconnect.fr
> > >
> > > Suivez-nous !
> > > [picto-twitter][picto-
> youtube]<
> >
> https://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug>[pict
> o-linked
> > in]< https://www.linkedin.com/company/20541473/admin/>
> > >
> > >
> > > ---
> > > 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] La gestion du MAN chez Alphalink...

[Olivier Varenne via frnog]

Salut remy
Tu vas bien ?

On a des soucis vraiment etranges.
En effet certaines fois le MTU est en cause. Alphalink se retranche sur le fait 
que les STAS indiquent un MTU à 1492. Mais certains équipements clients ont 
parfois des MTU inférieures (1480 souvent, ce qui est le cas par défaut des 
mikrotik)
En spécifiant 1492 on arrive dans le cas des krotik a résoudre le soucis, mais 
dans d’autres cas non.

Ce qui me chiffonne c’est que sauf erreur de ma part la RFC indique qu’il est 
vraiment conseillé de passer en TCP en cas de fragmentation, mais alphalink 
refuse catégoriquement l’emploi de TCP.



Cordialement,


[cid:image001.png@01DAC3E8.8234D360]
Olivier Varenne
Président, R&D et développement
T +33 (0)4 27 04 40 00 | ipconnect.fr

Suivez-nous !
[picto-twitter][picto-youtube][picto-linkedin]

De : ALEGRI Rémy 
Envoyé : vendredi 21 juin 2024 14:22
À : Olivier Varenne 
Cc : frnog-al...@frnog.org
Objet : Re: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...


Bonjour,

D'après mon expertise, certains IPBX, comme des Alcatel, ne supportent pas le 
Header Identity. Cependant, il est plus probable que le lien réseau n'ait pas 
une MTU de 1500, ce qui empêche les INVITE d'arriver correctement en UDP.

Olivier, je te recommande de tester la MTU du lien sous Linux avec la commande 
suivante pour une MTU de 1500

 ping -M do -s 1472 1.1.1.1



Je confirme qu'Alphalink transmet les INVITE avec le Header Identity :
2024/06/21 14:06:45.559654 alphalink:5060 -> ipbx:5060
INVITE sip:0x@ipbx:5060 SIP/2.0
Via: SIP/2.0/UDP alphalink:5060;branch=z9hG4bKfb2c.e3208024.0
Max-Forwards: 69
From: ;tag=as4e911d28
To: 
Contact: 
Call-ID: 16xx5643c450f8@alphalink2:5060
CSeq: 102 INVITE
P-Early-Media: supported
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
Supported: timer
Identity: 
xx-g;info=;alg=ES256;ppt=shaken
Content-Type: application/sdp
Content-Length: 403

Par contre, il n'y a pas la classification de l'appel.

Bien cordialement,
ALEGRI Rémy



Le 2024-06-21 13:52, Alain Bieuzent a écrit :
Ce voudrais donc dire qu'Alphalink envoit les header Identity aux ipbx des 
clients, ce qui est interdit...

Le 21/06/2024 12:45, « Benoît Gigarel » 
mailto:bgiga...@izarralde.com> 
>> a écrit :


Bonjour à tous,


Çà y est, on y est aussi... Nos clients connectés chez Alphalink nous
appellent pour des problèmes d'appels depuis ce matin.


Voici la dernière communication de Alphalink à 11h56.


Statut de l'incident :
Nous avons répertoriés des équipements comportant des anomalies :
1-Les IPBX wazo semblent ne pas gérer correctement les Invites fragmentés.
2-Les équipement Mitel MIVB ne sont pas en mesure de gérer les Identity
Header de plus de 500 caractères (Développement en cours de Mitel pour
augmenter cette valeur)
3-PABX PANASONIC NS700
Versions impactées :
Panasonic-MPR16-V006.01089/VSIPGW-V3.
Panasonic-MPR16-V008.00055/VSIPGW-V3.




Cordialement,
Benoît




-Message d'origine-
De : frnog-requ...@frnog.org 
> 
mailto:frnog-requ...@frnog.org> 
>> De la part de 
Jérôme
RICHARD
Envoyé : vendredi 21 juin 2024 12:37
À : Alain Bieuzent mailto:alain.bieuz...@free.fr> 
>
Cc : Olivier Varenne mailto:o.vare...@ipconnect.fr> 
>>; 
frnog-al...@frnog.org 
>
Objet : Re: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...


Pour l'identity je suis Ok.


Pour l'info d'attestation je n'avais pas vu l'info. C'est dommage de ne pas
le transmettre je trouve.


Cordialement,
Jérôme RICHARD








Le ven. 21 juin 2024 à 12:03, Alain Bieuzent 
mailto:alain.bieuz...@free.fr> 
>> a
écrit :



Bonjour Jérôme,

L'APNF a clairement précisé qu'il était interdit de transmettre
l'entête Identity aux client finaux (cela reste de l'info
inter-opérateur) et qu'il était aussi interdit de transmettre le
niveau d'attestation (quel que soit la manière utilisée).

Alain

Le 21/06/2024 11:53, « Jérôme RICHARD » 
mailto:frnog-requ...@frnog.org

RE: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...

[Olivier Varenne via frnog]

Sauf que chez nous, c'est le mikrotik qui droppe les paquets envoyés.
Dans certains cas on a résolu en tripatouillant le MTU, dans d'autres cas on 
est bloqué.
On a pas un client qui a le meme symptome.



Cordialement,
 


Olivier Varenne
Président, R&D et développement
T +33 (0)4 27 04 40 00 | ipconnect.fr

Suivez-nous ! 


> -Message d'origine-
> De : Benoît Gigarel 
> Envoyé : vendredi 21 juin 2024 12:45
> À : Jérôme RICHARD ; Alain Bieuzent
> 
> Cc : Olivier Varenne ; frnog-al...@frnog.org
> Objet : RE: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...
> 
> Bonjour à tous,
> 
> Çà y est, on y est aussi... Nos clients connectés chez Alphalink nous
> appellent pour des problèmes d'appels depuis ce matin.
> 
> Voici la dernière communication de Alphalink à 11h56.
> 
> Statut de l'incident :
> Nous avons répertoriés des équipements comportant des anomalies :
> 1-Les IPBX wazo semblent ne pas gérer correctement les Invites
> fragmentés.
> 2-Les équipement Mitel MIVB ne sont pas en mesure de gérer les
> Identity Header de plus de 500 caractères (Développement en cours de
> Mitel pour augmenter cette valeur) 3-PABX PANASONIC NS700 Versions
> impactées :
> Panasonic-MPR16-V006.01089/VSIPGW-V3.
> Panasonic-MPR16-V008.00055/VSIPGW-V3.
> 
> 
> Cordialement,
> Benoît
> 
> 
> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de
> Jérôme RICHARD Envoyé : vendredi 21 juin 2024 12:37 À : Alain
> Bieuzent  Cc : Olivier Varenne
> ; frnog-al...@frnog.org Objet : Re: [FRnOG]
> [ALERT] La gestion du MAN chez Alphalink...
> 
> Pour l'identity je suis Ok.
> 
> Pour l'info d'attestation je n'avais pas vu l'info. C'est dommage de ne
> pas le transmettre je trouve.
> 
> Cordialement,
> Jérôme RICHARD
> 
> 
> 
> 
> Le ven. 21 juin 2024 à 12:03, Alain Bieuzent  a
> écrit :
> 
> > Bonjour Jérôme,
> >
> > L'APNF a clairement précisé qu'il était interdit de transmettre
> > l'entête Identity aux client finaux (cela reste de l'info
> > inter-opérateur) et qu'il était aussi interdit de transmettre le
> > niveau d'attestation (quel que soit la manière utilisée).
> >
> > Alain
> >
> > Le 21/06/2024 11:53, « Jérôme RICHARD »  requ...@frnog.org  > frnog-requ...@frnog.org> au nom de jerome.rich...@va-telecom.fr
>  > jerome.rich...@va-telecom.fr>> a écrit :
> >
> >
> > Bonjour,
> >
> >
> > Le MAN ajoute un entête identity assez conséquent (plus de 500
> octet)
> > à l'INVITE SIP. Ca peut donner des INVITE à plus de 1600 octets et
> > donc de la fragmentation ce qui n'est pas supporté par tous les IPBX.
> > Le symptôme que j'ai pu constater c'est que l'IPBX destinataire ne
> > répond pas aux INVITE avec entête identity.
> >
> >
> > Nous avons fait le choix de ne pas le diffuser vers les trunks de nos
> > clients puisque nous réalisons le contrôle en amont et de diffuser
> > uniquement le Attestation-Info (A, B ou C) qui en ressort.
> >
> >
> > Donc a voir si les appels qui posent problème ont l'entête identity
> > dans l'INVITE.
> >
> >
> > Cordialement,
> > Jérôme RICHARD
> >
> >
> >
> >
> >
> >
> >
> >
> > Le ven. 21 juin 2024 à 09:55, Olivier Varenne via frnog
> > mailto:frnog@frnog.org>> a écrit :
> >
> >
> > > On est les seuls à être très, TRES, impacté par la mise en place du
> > > man chez alphalink depuis plusieurs jours ?
> > > On a du mal à identifier l'origine du problème : dans certains cas
> > > cela semble être un problème de MTU et de paquet SIP fragmenté,
> > > d'autres cas sont plus obscurs...
> > > Je suis un peu étonné de rien avoir vu circuler ici, à croire qu'on
> > > est
> > un
> > > cas isolé ?
> > > Comment souvent : communication proche du 0, au début quand
> on a
> > > remonté les soucis on nous a gentiment envoyé balader genre «
> c'est
> > > pas notre probleme », et maintenant ça semble être la panique.
> > >
> > >
> > >
> > > Cordialement,
> > >
> > >
> > > [cid:image001.png@01DAC3C1.1D673B20]
> > > Olivier Varenne
> > > Président, R&D et développement
> > > T +33 (0)4 27 04 40 00 | ipconnect.fr
> <
> > http://www.ipconnect.fr/>;>
> > >
> > > Suivez-nous !
> > > [picto-twitter] <
> > https://twitter.com/ip_connectweets>;>[picto-youtube]<
> > > https://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug>
> <
> > https://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug>
> > ;>[picto-linkedin]<
> > > https://www.linkedin.com/company/20541473/admin/> <
> > https://www.linkedin.com/company/20541473/admin/>;>
> > >
> > >
> > > ---
> > > 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] La gestion du MAN chez Alphalink...

[Olivier Varenne via frnog]

C'est pas le seul qu'on ait, mais clairement on accumule les soucis avec.



Cordialement,
 


Olivier Varenne
Président, R&D et développement
T +33 (0)4 27 04 40 00 | ipconnect.fr

Suivez-nous ! 


> -Message d'origine-
> De : David Ponzone 
> Envoyé : vendredi 21 juin 2024 10:00
> À : Olivier Varenne 
> Cc : frnog-al...@frnog.org
> Objet : Re: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...
> 
> Hmm Alphalink comme fournisseur ?
> 
> David
> 
> > Le 21 juin 2024 à 09:55, Olivier Varenne via frnog 
> a écrit :
> >
> > On est les seuls à être très, TRES, impacté par la mise en place du
> man chez alphalink depuis plusieurs jours ?
> > On a du mal à identifier l'origine du problème : dans certains cas cela
> semble être un problème de MTU et de paquet SIP fragmenté, d'autres
> cas sont plus obscurs...
> > Je suis un peu étonné de rien avoir vu circuler ici, à croire qu'on est
> un cas isolé ?
> > Comment souvent : communication proche du 0, au début quand on
> a remonté les soucis on nous a gentiment envoyé balader genre « c'est
> pas notre probleme », et maintenant ça semble être la panique.
> >
> >
> >
> > Cordialement,
> >
> >
> > [cid:image001.png@01DAC3C1.1D673B20]
> > Olivier Varenne
> > Président, R&D et développement
> > T +33 (0)4 27 04 40 00 | ipconnect.fr
> >
> > Suivez-nous !
> > [picto-twitter][picto-
> youtube] pVug>[picto-
> linkedin]
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/


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

RE: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...

[Olivier Varenne via frnog]

Bingo. Mais ce n’est pas le seul probleme…
En l’occurrence on a des soucis obscurs aussi de MTU.
A priori plutôt sur les connexions SFR



Cordialement,


[cid:image001.png@01DAC3E8.1AFFED60]
Olivier Varenne
Président, R&D et développement
T +33 (0)4 27 04 40 00 | ipconnect.fr

Suivez-nous !
[picto-twitter][picto-youtube][picto-linkedin]

De : Jérôme RICHARD 
Envoyé : vendredi 21 juin 2024 11:53
À : Olivier Varenne 
Cc : frnog-al...@frnog.org
Objet : Re: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...

Bonjour,

Le MAN ajoute un entête identity assez conséquent (plus de 500 octet) à 
l'INVITE SIP. Ca peut donner des INVITE à plus de 1600 octets et donc de la 
fragmentation ce qui n'est pas supporté par tous les IPBX. Le symptôme que j'ai 
pu constater c'est que l'IPBX destinataire ne répond pas aux INVITE avec entête 
identity.

Nous avons fait le choix de ne pas le diffuser vers les trunks de nos clients 
puisque nous réalisons le contrôle en amont et de diffuser uniquement le 
Attestation-Info (A, B ou C) qui en ressort.

Donc a voir si les appels qui posent problème ont l'entête identity dans 
l'INVITE.

Cordialement,
Jérôme RICHARD




Le ven. 21 juin 2024 à 09:55, Olivier Varenne via frnog 
mailto:frnog@frnog.org>> a écrit :
On est les seuls à être très, TRES, impacté par la mise en place du man chez 
alphalink depuis plusieurs jours ?
On a du mal à identifier l'origine du problème : dans certains cas cela semble 
être un problème de MTU et de paquet SIP fragmenté, d'autres cas sont plus 
obscurs...
Je suis un peu étonné de rien avoir vu circuler ici, à croire qu'on est un cas 
isolé ?
Comment souvent : communication proche du 0, au début quand on a remonté les 
soucis on nous a gentiment envoyé balader genre « c'est pas notre probleme », 
et maintenant ça semble être la panique.



Cordialement,


[cid:image001.png@01DAC3C1.1D673B20]
Olivier Varenne
Président, R&D et développement
T +33 (0)4 27 04 40 00 | 
ipconnect.fr

Suivez-nous !
[picto-twitter][picto-youtube][picto-linkedin]


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

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

Re: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...

[ALEGRI Rémy]

Bonjour,

D'après mon expertise, certains IPBX, comme des Alcatel, ne supportent 
pas le Header Identity. Cependant, il est plus probable que le lien 
réseau n'ait pas une MTU de 1500, ce qui empêche les INVITE d'arriver 
correctement en UDP.


Olivier, je te recommande de tester la MTU du lien sous Linux avec la 
commande suivante pour une MTU de 1500


 ping -M do -s 1472 1.1.1.1

Je confirme qu'Alphalink transmet les INVITE avec le Header Identity :

2024/06/21 14:06:45.559654 alphalink:5060 -> ipbx:5060
INVITE sip:0x@ipbx:5060 SIP/2.0
Via: SIP/2.0/UDP alphalink:5060;branch=z9hG4bKfb2c.e3208024.0
Max-Forwards: 69
From: ;tag=as4e911d28
To: 
Contact: 
Call-ID: 16xx5643c450f8@alphalink2:5060
CSeq: 102 INVITE
P-Early-Media: supported
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE
Supported: timer

Identity: 
xx-g;info=;alg=ES256;ppt=shaken

Content-Type: application/sdp
Content-Length: 403

Par contre, il n'y a pas la classification de l'appel.

Bien cordialement,
ALEGRI Rémy

Le 2024-06-21 13:52, Alain Bieuzent a écrit :

Ce voudrais donc dire qu'Alphalink envoit les header Identity aux ipbx 
des clients, ce qui est interdit...


Le 21/06/2024 12:45, « Benoît Gigarel » > a écrit :


Bonjour à tous,

Çà y est, on y est aussi... Nos clients connectés chez Alphalink nous
appellent pour des problèmes d'appels depuis ce matin.

Voici la dernière communication de Alphalink à 11h56.

Statut de l'incident :
Nous avons répertoriés des équipements comportant des anomalies :
1-Les IPBX wazo semblent ne pas gérer correctement les Invites 
fragmentés.

2-Les équipement Mitel MIVB ne sont pas en mesure de gérer les Identity
Header de plus de 500 caractères (Développement en cours de Mitel pour
augmenter cette valeur)
3-PABX PANASONIC NS700
Versions impactées :
Panasonic-MPR16-V006.01089/VSIPGW-V3.
Panasonic-MPR16-V008.00055/VSIPGW-V3.

Cordialement,
Benoît

-Message d'origine-
De : frnog-requ...@frnog.org  
mailto:frnog-requ...@frnog.org>> De la part 
de Jérôme

RICHARD
Envoyé : vendredi 21 juin 2024 12:37
À : Alain Bieuzent >
Cc : Olivier Varenne >; frnog-al...@frnog.org 


Objet : Re: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...

Pour l'identity je suis Ok.

Pour l'info d'attestation je n'avais pas vu l'info. C'est dommage de ne 
pas

le transmettre je trouve.

Cordialement,
Jérôme RICHARD

Le ven. 21 juin 2024 à 12:03, Alain Bieuzent > a

écrit :

Bonjour Jérôme,

L'APNF a clairement précisé qu'il était interdit de transmettre
l'entête Identity aux client finaux (cela reste de l'info
inter-opérateur) et qu'il était aussi interdit de transmettre le
niveau d'attestation (quel que soit la manière utilisée).

Alain

Le 21/06/2024 11:53, « Jérôme RICHARD »  frnog-requ...@frnog.org > au nom de 
jerome.rich...@va-telecom.fr  
jerome.rich...@va-telecom.fr >> a 
écrit :


Bonjour,

Le MAN ajoute un entête identity assez conséquent (plus de 500 octet)
à l'INVITE SIP. Ca peut donner des INVITE à plus de 1600 octets et
donc de la fragmentation ce qui n'est pas supporté par tous les IPBX.
Le symptôme que j'ai pu constater c'est que l'IPBX destinataire ne
répond pas aux INVITE avec entête identity.

Nous avons fait le choix de ne pas le diffuser vers les trunks de nos
clients puisque nous réalisons le contrôle en amont et de diffuser
uniquement le Attestation-Info (A, B ou C) qui en ressort.

Donc a voir si les appels qui posent problème ont l'entête identity
dans l'INVITE.

Cordialement,
Jérôme RICHARD

Le ven. 21 juin 2024 à 09:55, Olivier Varenne via frnog
mailto:frnog@frnog.org> >> a écrit :


On est les seuls à être très, TRES, impacté par la mise en place du
man chez alphalink depuis plusieurs jours ?
On a du mal à identifier l'origine du problème : dans certains cas
cela semble être un problème de MTU et de paquet SIP fragmenté,
d'autres cas sont plus obscurs...
Je suis un peu étonné de rien avoir vu circuler ici, à croire qu'on
est un cas isolé ?
Comment souvent : communication proche du 0, au début quand on a
remonté les soucis on nous a gentiment envoyé balader genre « c'est
pas notre probleme », et maintenant ça semble être la panique.

Cordia

Re: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...

[Alain Bieuzent]

Ce voudrais donc dire qu'Alphalink envoit les header Identity aux ipbx des 
clients, ce qui est interdit...

Le 21/06/2024 12:45, « Benoît Gigarel » mailto:bgiga...@izarralde.com>> a écrit :


Bonjour à tous,


Çà y est, on y est aussi... Nos clients connectés chez Alphalink nous 
appellent pour des problèmes d'appels depuis ce matin.


Voici la dernière communication de Alphalink à 11h56.


Statut de l'incident :
Nous avons répertoriés des équipements comportant des anomalies :
1-Les IPBX wazo semblent ne pas gérer correctement les Invites fragmentés.
2-Les équipement Mitel MIVB ne sont pas en mesure de gérer les Identity 
Header de plus de 500 caractères (Développement en cours de Mitel pour 
augmenter cette valeur)
3-PABX PANASONIC NS700
Versions impactées :
Panasonic-MPR16-V006.01089/VSIPGW-V3.
Panasonic-MPR16-V008.00055/VSIPGW-V3.




Cordialement,
Benoît




-Message d'origine-
De : frnog-requ...@frnog.org  
mailto:frnog-requ...@frnog.org>> De la part de Jérôme 
RICHARD
Envoyé : vendredi 21 juin 2024 12:37
À : Alain Bieuzent mailto:alain.bieuz...@free.fr>>
Cc : Olivier Varenne mailto:o.vare...@ipconnect.fr>>; 
frnog-al...@frnog.org 
Objet : Re: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...


Pour l'identity je suis Ok.


Pour l'info d'attestation je n'avais pas vu l'info. C'est dommage de ne pas 
le transmettre je trouve.


Cordialement,
Jérôme RICHARD








Le ven. 21 juin 2024 à 12:03, Alain Bieuzent mailto:alain.bieuz...@free.fr>> a 
écrit :


> Bonjour Jérôme,
>
> L'APNF a clairement précisé qu'il était interdit de transmettre
> l'entête Identity aux client finaux (cela reste de l'info
> inter-opérateur) et qu'il était aussi interdit de transmettre le
> niveau d'attestation (quel que soit la manière utilisée).
>
> Alain
>
> Le 21/06/2024 11:53, « Jérôme RICHARD »    frnog-requ...@frnog.org > au nom de 
> jerome.rich...@va-telecom.fr   jerome.rich...@va-telecom.fr >> a écrit :
>
>
> Bonjour,
>
>
> Le MAN ajoute un entête identity assez conséquent (plus de 500 octet)
> à l'INVITE SIP. Ca peut donner des INVITE à plus de 1600 octets et
> donc de la fragmentation ce qui n'est pas supporté par tous les IPBX.
> Le symptôme que j'ai pu constater c'est que l'IPBX destinataire ne
> répond pas aux INVITE avec entête identity.
>
>
> Nous avons fait le choix de ne pas le diffuser vers les trunks de nos
> clients puisque nous réalisons le contrôle en amont et de diffuser
> uniquement le Attestation-Info (A, B ou C) qui en ressort.
>
>
> Donc a voir si les appels qui posent problème ont l'entête identity
> dans l'INVITE.
>
>
> Cordialement,
> Jérôme RICHARD
>
>
>
>
>
>
>
>
> Le ven. 21 juin 2024 à 09:55, Olivier Varenne via frnog
> mailto:frnog@frnog.org>  >> a écrit :
>
>
> > On est les seuls à être très, TRES, impacté par la mise en place du
> > man chez alphalink depuis plusieurs jours ?
> > On a du mal à identifier l'origine du problème : dans certains cas
> > cela semble être un problème de MTU et de paquet SIP fragmenté,
> > d'autres cas sont plus obscurs...
> > Je suis un peu étonné de rien avoir vu circuler ici, à croire qu'on
> > est
> un
> > cas isolé ?
> > Comment souvent : communication proche du 0, au début quand on a
> > remonté les soucis on nous a gentiment envoyé balader genre « c'est
> > pas notre probleme », et maintenant ça semble être la panique.
> >
> >
> >
> > Cordialement,
> >
> >
> > [cid:image001.png@01DAC3C1.1D673B20]
> > Olivier Varenne
> > Président, R&D et développement
> > T +33 (0)4 27 04 40 00 | ipconnect.fr 
> > ;> <
> http://www.ipconnect.fr/>;> ;>
> >
> > Suivez-nous !
> > [picto-twitter] 
> > ;> <
> https://twitter.com/ip_connectweets>;> 
> ;>[picto-youtube]<
> > https://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug> 
> > ;> <
> https://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug> 
> 
> ;>[picto-linkedin]<
> > https://www.linkedin.com/company/20541473/admin/> 
> > ;> <
> https://www.linkedin.com/company/20541473/admin/>;> 
> ;>
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/   
> > ;>
> >
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/   
> ;>
>
>
>
>
>

Re: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...

[Alain Bieuzent]

On en fait rien et on n’en fera jamais rien.

 

Cette notation A/B/C aux états unis/Canada correspond à un niveau de confiance 
de l’appelant. En France elle correspond à une typologie d’appel

Un appel signé en B n’a pas moins de « valeur » qu’un appel signé en A.

 

A terme le niveau d’attestation B et C vont disparaître avec notamment la 
migration des interco SIP-I et SS7 vers SIP.

 

Alain

 

De : Jérôme RICHARD 
Date : vendredi 21 juin 2024 à 13:23
À : David Ponzone 
Cc : Alain Bieuzent , Olivier Varenne 
, "frnog-al...@frnog.org" 
Objet : Re: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...

 

> AMHA, laisser à un client final la liberté de couper des appels de manière 
> trop restrictive et infondée, ça serait > un cauchemar pour les Services 
> Clients des opérateurs.

 

Effectivement. On fait quoi de cette note A/B/C ?


Cordialement,
Jérôme RICHARD
Jérôme Richard
Directeur technique
0698614239 / 0272240542

jerome.rich...@va-telecom.fr

www.va-telecom.fr

3 rue du Tisserand, 44800, Nantes
 
 

 

Le ven. 21 juin 2024 à 12:41, David Ponzone  a écrit :

AMHA, laisser à un client final la liberté de couper des appels de manière trop 
restrictive et infondée, ça serait un cauchemar pour les Services Clients des 
opérateurs.

David

> Le 21 juin 2024 à 12:36, Jérôme RICHARD  a 
> écrit :
> 
> Pour l'identity je suis Ok.
> 
> Pour l'info d'attestation je n'avais pas vu l'info. C'est dommage de ne pas
> le transmettre je trouve.
> 
> Cordialement,
> Jérôme RICHARD
> 
> 
> 
> 
> Le ven. 21 juin 2024 à 12:03, Alain Bieuzent  a
> écrit :
> 
>> Bonjour Jérôme,
>> 
>> L'APNF a clairement précisé qu'il était interdit de transmettre l'entête
>> Identity aux client finaux (cela reste de l'info inter-opérateur) et qu'il
>> était aussi interdit de transmettre le niveau d'attestation (quel que soit
>> la manière utilisée).
>> 
>> Alain
>> 
>> Le 21/06/2024 11:53, « Jérôme RICHARD » > frnog-requ...@frnog.org> au nom de jerome.rich...@va-telecom.fr > jerome.rich...@va-telecom.fr>> a écrit :
>> 
>> 
>> Bonjour,
>> 
>> 
>> Le MAN ajoute un entête identity assez conséquent (plus de 500 octet) à
>> l'INVITE SIP. Ca peut donner des INVITE à plus de 1600 octets et donc de la
>> fragmentation ce qui n'est pas supporté par tous les IPBX. Le symptôme que
>> j'ai pu constater c'est que l'IPBX destinataire ne répond pas aux INVITE
>> avec entête identity.
>> 
>> 
>> Nous avons fait le choix de ne pas le diffuser vers les trunks de nos
>> clients puisque nous réalisons le contrôle en amont et de diffuser
>> uniquement le Attestation-Info (A, B ou C) qui en ressort.
>> 
>> 
>> Donc a voir si les appels qui posent problème ont l'entête identity dans
>> l'INVITE.
>> 
>> 
>> Cordialement,
>> Jérôme RICHARD
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Le ven. 21 juin 2024 à 09:55, Olivier Varenne via frnog > > a
>> écrit :
>> 
>> 
>>> On est les seuls à être très, TRES, impacté par la mise en place du man
>>> chez alphalink depuis plusieurs jours ?
>>> On a du mal à identifier l'origine du problème : dans certains cas cela
>>> semble être un problème de MTU et de paquet SIP fragmenté, d'autres cas
>>> sont plus obscurs...
>>> Je suis un peu étonné de rien avoir vu circuler ici, à croire qu'on est
>> un
>>> cas isolé ?
>>> Comment souvent : communication proche du 0, au début quand on a remonté
>>> les soucis on nous a gentiment envoyé balader genre « c'est pas notre
>>> probleme », et maintenant ça semble être la panique.
>>> 
>>> 
>>> 
>>> Cordialement,
>>> 
>>> 
>>> [cid:image001.png@01DAC3C1.1D673B20]
>>> Olivier Varenne
>>> Président, R&D et développement
>>> T +33 (0)4 27 04 40 00 | ipconnect.fr <
>> http://www.ipconnect.fr/>;>
>>> 
>>> Suivez-nous !
>>> [picto-twitter] <
>> https://twitter.com/ip_connectweets>;>[picto-youtube]<
>>> https://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug> <
>> https://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug>
>> ;>[picto-linkedin]<
>>> https://www.linkedin.com/company/20541473/admin/> <
>> https://www.linkedin.com/company/20541473/admin/>;>
>>> 
>>> 
>>> ---
>>> 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] La gestion du MAN chez Alphalink...

[David Ponzone]

Des stats pour l’ARCEP/APNF surtout, ils pourront voir qui achemine des appels 
non notés surtout, donc les méchants.
Et faire des beaux rapports inutiles.

David

> Le 21 juin 2024 à 13:23, Jérôme RICHARD  a 
> écrit :
> 
> > AMHA, laisser à un client final la liberté de couper des appels de manière 
> > trop restrictive et infondée, ça serait > un cauchemar pour les Services 
> > Clients des opérateurs.
> 
> Effectivement. On fait quoi de cette note A/B/C ?
> 
> Cordialement,
> Jérôme RICHARD
> 
> Jérôme Richard
> Directeur technique
> 
> 0698614239 / 0272240542
> 
> jerome.rich...@va-telecom.fr 
>   www.va-telecom.fr 
>   3 rue du Tisserand, 44800, Nantes
> 
> 
> 
> Le ven. 21 juin 2024 à 12:41, David Ponzone  > a écrit :
> AMHA, laisser à un client final la liberté de couper des appels de manière 
> trop restrictive et infondée, ça serait un cauchemar pour les Services 
> Clients des opérateurs.
> 
> David
> 
> > Le 21 juin 2024 à 12:36, Jérôme RICHARD  > > a écrit :
> > 
> > Pour l'identity je suis Ok.
> > 
> > Pour l'info d'attestation je n'avais pas vu l'info. C'est dommage de ne pas
> > le transmettre je trouve.
> > 
> > Cordialement,
> > Jérôme RICHARD
> > 
> > 
> > 
> > 
> > Le ven. 21 juin 2024 à 12:03, Alain Bieuzent  > > a
> > écrit :
> > 
> >> Bonjour Jérôme,
> >> 
> >> L'APNF a clairement précisé qu'il était interdit de transmettre l'entête
> >> Identity aux client finaux (cela reste de l'info inter-opérateur) et qu'il
> >> était aussi interdit de transmettre le niveau d'attestation (quel que soit
> >> la manière utilisée).
> >> 
> >> Alain
> >> 
> >> Le 21/06/2024 11:53, « Jérôme RICHARD »  >>   >> frnog-requ...@frnog.org > au nom de 
> >> jerome.rich...@va-telecom.fr   >> jerome.rich...@va-telecom.fr >> a 
> >> écrit :
> >> 
> >> 
> >> Bonjour,
> >> 
> >> 
> >> Le MAN ajoute un entête identity assez conséquent (plus de 500 octet) à
> >> l'INVITE SIP. Ca peut donner des INVITE à plus de 1600 octets et donc de la
> >> fragmentation ce qui n'est pas supporté par tous les IPBX. Le symptôme que
> >> j'ai pu constater c'est que l'IPBX destinataire ne répond pas aux INVITE
> >> avec entête identity.
> >> 
> >> 
> >> Nous avons fait le choix de ne pas le diffuser vers les trunks de nos
> >> clients puisque nous réalisons le contrôle en amont et de diffuser
> >> uniquement le Attestation-Info (A, B ou C) qui en ressort.
> >> 
> >> 
> >> Donc a voir si les appels qui posent problème ont l'entête identity dans
> >> l'INVITE.
> >> 
> >> 
> >> Cordialement,
> >> Jérôme RICHARD
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> 
> >> Le ven. 21 juin 2024 à 09:55, Olivier Varenne via frnog  >> 
> >> >> a
> >> écrit :
> >> 
> >> 
> >>> On est les seuls à être très, TRES, impacté par la mise en place du man
> >>> chez alphalink depuis plusieurs jours ?
> >>> On a du mal à identifier l'origine du problème : dans certains cas cela
> >>> semble être un problème de MTU et de paquet SIP fragmenté, d'autres cas
> >>> sont plus obscurs...
> >>> Je suis un peu étonné de rien avoir vu circuler ici, à croire qu'on est
> >> un
> >>> cas isolé ?
> >>> Comment souvent : communication proche du 0, au début quand on a remonté
> >>> les soucis on nous a gentiment envoyé balader genre « c'est pas notre
> >>> probleme », et maintenant ça semble être la panique.
> >>> 
> >>> 
> >>> 
> >>> Cordialement,
> >>> 
> >>> 
> >>> [cid:image001.png@01DAC3C1.1D673B20]
> >>> Olivier Varenne
> >>> Président, R&D et développement
> >>> T +33 (0)4 27 04 40 00 | ipconnect.fr 
> >>>  >>> > <
> >> http://www.ipconnect.fr/> >;>
> >>> 
> >>> Suivez-nous !
> >>> [picto-twitter] >>> > <
> >> https://twitter.com/ip_connectweets> 
> >> >;>[picto-youtube]<
> >>> https://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug 
> >>> > <
> >> https://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug> 
> >> >
> >> ;>[picto-linkedin]<
> >>> https://www.linkedin.com/company/20541473/admin/ 
> >>> > <
> >> https://www.linkedin.com/company/20541473/admin/> 
> >> >;>
> >>> 
> >>> 
> >>> ---
> >>> Liste de diffusion du FRnOG
> >>> http://www.frnog.org/   >>> >
> >>> 
> >> 
> >> 
> >

Re: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...

[Jérôme RICHARD]

> AMHA, laisser à un client final la liberté de couper des appels de
manière trop restrictive et infondée, ça serait > un cauchemar pour les
Services Clients des opérateurs.

Effectivement. On fait quoi de cette note A/B/C ?

Cordialement,
Jérôme RICHARD

Jérôme Richard

Directeur technique
[image: mobilePhone] 0698614239 / 0272240542
[image: emailAddress] jerome.rich...@va-telecom.fr 
[image: website] www.va-telecom.fr
[image: address] 3 rue du Tisserand, 44800, Nantes



Le ven. 21 juin 2024 à 12:41, David Ponzone  a
écrit :

> AMHA, laisser à un client final la liberté de couper des appels de manière
> trop restrictive et infondée, ça serait un cauchemar pour les Services
> Clients des opérateurs.
>
> David
>
> > Le 21 juin 2024 à 12:36, Jérôme RICHARD 
> a écrit :
> >
> > Pour l'identity je suis Ok.
> >
> > Pour l'info d'attestation je n'avais pas vu l'info. C'est dommage de ne
> pas
> > le transmettre je trouve.
> >
> > Cordialement,
> > Jérôme RICHARD
> >
> >
> >
> >
> > Le ven. 21 juin 2024 à 12:03, Alain Bieuzent  a
> > écrit :
> >
> >> Bonjour Jérôme,
> >>
> >> L'APNF a clairement précisé qu'il était interdit de transmettre l'entête
> >> Identity aux client finaux (cela reste de l'info inter-opérateur) et
> qu'il
> >> était aussi interdit de transmettre le niveau d'attestation (quel que
> soit
> >> la manière utilisée).
> >>
> >> Alain
> >>
> >> Le 21/06/2024 11:53, « Jérôme RICHARD »   >> frnog-requ...@frnog.org> au nom de jerome.rich...@va-telecom.fr
>  >> jerome.rich...@va-telecom.fr>> a écrit :
> >>
> >>
> >> Bonjour,
> >>
> >>
> >> Le MAN ajoute un entête identity assez conséquent (plus de 500 octet) à
> >> l'INVITE SIP. Ca peut donner des INVITE à plus de 1600 octets et donc
> de la
> >> fragmentation ce qui n'est pas supporté par tous les IPBX. Le symptôme
> que
> >> j'ai pu constater c'est que l'IPBX destinataire ne répond pas aux INVITE
> >> avec entête identity.
> >>
> >>
> >> Nous avons fait le choix de ne pas le diffuser vers les trunks de nos
> >> clients puisque nous réalisons le contrôle en amont et de diffuser
> >> uniquement le Attestation-Info (A, B ou C) qui en ressort.
> >>
> >>
> >> Donc a voir si les appels qui posent problème ont l'entête identity dans
> >> l'INVITE.
> >>
> >>
> >> Cordialement,
> >> Jérôme RICHARD
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> Le ven. 21 juin 2024 à 09:55, Olivier Varenne via frnog <
> frnog@frnog.org
> >> > a
> >> écrit :
> >>
> >>
> >>> On est les seuls à être très, TRES, impacté par la mise en place du man
> >>> chez alphalink depuis plusieurs jours ?
> >>> On a du mal à identifier l'origine du problème : dans certains cas cela
> >>> semble être un problème de MTU et de paquet SIP fragmenté, d'autres cas
> >>> sont plus obscurs...
> >>> Je suis un peu étonné de rien avoir vu circuler ici, à croire qu'on est
> >> un
> >>> cas isolé ?
> >>> Comment souvent : communication proche du 0, au début quand on a
> remonté
> >>> les soucis on nous a gentiment envoyé balader genre « c'est pas notre
> >>> probleme », et maintenant ça semble être la panique.
> >>>
> >>>
> >>>
> >>> Cordialement,
> >>>
> >>>
> >>> [cid:image001.png@01DAC3C1.1D673B20]
> >>> Olivier Varenne
> >>> Président, R&D et développement
> >>> T +33 (0)4 27 04 40 00 | ipconnect.fr <
> >> http://www.ipconnect.fr/>;>
> >>>
> >>> Suivez-nous !
> >>> [picto-twitter] <
> >> https://twitter.com/ip_connectweets>;>[picto-youtube]<
> >>> https://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug> <
> >> https://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug>
> >> ;>[picto-linkedin]<
> >>> https://www.linkedin.com/company/20541473/admin/> <
> >> https://www.linkedin.com/company/20541473/admin/>;>
> >>>
> >>>
> >>> ---
> >>> 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] La gestion du MAN chez Alphalink...

[David Ponzone]

AMHA, laisser à un client final la liberté de couper des appels de manière trop 
restrictive et infondée, ça serait un cauchemar pour les Services Clients des 
opérateurs.

David

> Le 21 juin 2024 à 12:36, Jérôme RICHARD  a 
> écrit :
> 
> Pour l'identity je suis Ok.
> 
> Pour l'info d'attestation je n'avais pas vu l'info. C'est dommage de ne pas
> le transmettre je trouve.
> 
> Cordialement,
> Jérôme RICHARD
> 
> 
> 
> 
> Le ven. 21 juin 2024 à 12:03, Alain Bieuzent  a
> écrit :
> 
>> Bonjour Jérôme,
>> 
>> L'APNF a clairement précisé qu'il était interdit de transmettre l'entête
>> Identity aux client finaux (cela reste de l'info inter-opérateur) et qu'il
>> était aussi interdit de transmettre le niveau d'attestation (quel que soit
>> la manière utilisée).
>> 
>> Alain
>> 
>> Le 21/06/2024 11:53, « Jérôme RICHARD » > frnog-requ...@frnog.org> au nom de jerome.rich...@va-telecom.fr > jerome.rich...@va-telecom.fr>> a écrit :
>> 
>> 
>> Bonjour,
>> 
>> 
>> Le MAN ajoute un entête identity assez conséquent (plus de 500 octet) à
>> l'INVITE SIP. Ca peut donner des INVITE à plus de 1600 octets et donc de la
>> fragmentation ce qui n'est pas supporté par tous les IPBX. Le symptôme que
>> j'ai pu constater c'est que l'IPBX destinataire ne répond pas aux INVITE
>> avec entête identity.
>> 
>> 
>> Nous avons fait le choix de ne pas le diffuser vers les trunks de nos
>> clients puisque nous réalisons le contrôle en amont et de diffuser
>> uniquement le Attestation-Info (A, B ou C) qui en ressort.
>> 
>> 
>> Donc a voir si les appels qui posent problème ont l'entête identity dans
>> l'INVITE.
>> 
>> 
>> Cordialement,
>> Jérôme RICHARD
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> Le ven. 21 juin 2024 à 09:55, Olivier Varenne via frnog > > a
>> écrit :
>> 
>> 
>>> On est les seuls à être très, TRES, impacté par la mise en place du man
>>> chez alphalink depuis plusieurs jours ?
>>> On a du mal à identifier l'origine du problème : dans certains cas cela
>>> semble être un problème de MTU et de paquet SIP fragmenté, d'autres cas
>>> sont plus obscurs...
>>> Je suis un peu étonné de rien avoir vu circuler ici, à croire qu'on est
>> un
>>> cas isolé ?
>>> Comment souvent : communication proche du 0, au début quand on a remonté
>>> les soucis on nous a gentiment envoyé balader genre « c'est pas notre
>>> probleme », et maintenant ça semble être la panique.
>>> 
>>> 
>>> 
>>> Cordialement,
>>> 
>>> 
>>> [cid:image001.png@01DAC3C1.1D673B20]
>>> Olivier Varenne
>>> Président, R&D et développement
>>> T +33 (0)4 27 04 40 00 | ipconnect.fr <
>> http://www.ipconnect.fr/>;>
>>> 
>>> Suivez-nous !
>>> [picto-twitter] <
>> https://twitter.com/ip_connectweets>;>[picto-youtube]<
>>> https://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug> <
>> https://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug>
>> ;>[picto-linkedin]<
>>> https://www.linkedin.com/company/20541473/admin/> <
>> https://www.linkedin.com/company/20541473/admin/>;>
>>> 
>>> 
>>> ---
>>> 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] La gestion du MAN chez Alphalink...

[Jérôme RICHARD]

Pour l'identity je suis Ok.

Pour l'info d'attestation je n'avais pas vu l'info. C'est dommage de ne pas
le transmettre je trouve.

Cordialement,
Jérôme RICHARD




Le ven. 21 juin 2024 à 12:03, Alain Bieuzent  a
écrit :

> Bonjour Jérôme,
>
> L'APNF a clairement précisé qu'il était interdit de transmettre l'entête
> Identity aux client finaux (cela reste de l'info inter-opérateur) et qu'il
> était aussi interdit de transmettre le niveau d'attestation (quel que soit
> la manière utilisée).
>
> Alain
>
> Le 21/06/2024 11:53, « Jérôme RICHARD »  frnog-requ...@frnog.org> au nom de jerome.rich...@va-telecom.fr  jerome.rich...@va-telecom.fr>> a écrit :
>
>
> Bonjour,
>
>
> Le MAN ajoute un entête identity assez conséquent (plus de 500 octet) à
> l'INVITE SIP. Ca peut donner des INVITE à plus de 1600 octets et donc de la
> fragmentation ce qui n'est pas supporté par tous les IPBX. Le symptôme que
> j'ai pu constater c'est que l'IPBX destinataire ne répond pas aux INVITE
> avec entête identity.
>
>
> Nous avons fait le choix de ne pas le diffuser vers les trunks de nos
> clients puisque nous réalisons le contrôle en amont et de diffuser
> uniquement le Attestation-Info (A, B ou C) qui en ressort.
>
>
> Donc a voir si les appels qui posent problème ont l'entête identity dans
> l'INVITE.
>
>
> Cordialement,
> Jérôme RICHARD
>
>
>
>
>
>
>
>
> Le ven. 21 juin 2024 à 09:55, Olivier Varenne via frnog  > a
> écrit :
>
>
> > On est les seuls à être très, TRES, impacté par la mise en place du man
> > chez alphalink depuis plusieurs jours ?
> > On a du mal à identifier l'origine du problème : dans certains cas cela
> > semble être un problème de MTU et de paquet SIP fragmenté, d'autres cas
> > sont plus obscurs...
> > Je suis un peu étonné de rien avoir vu circuler ici, à croire qu'on est
> un
> > cas isolé ?
> > Comment souvent : communication proche du 0, au début quand on a remonté
> > les soucis on nous a gentiment envoyé balader genre « c'est pas notre
> > probleme », et maintenant ça semble être la panique.
> >
> >
> >
> > Cordialement,
> >
> >
> > [cid:image001.png@01DAC3C1.1D673B20]
> > Olivier Varenne
> > Président, R&D et développement
> > T +33 (0)4 27 04 40 00 | ipconnect.fr <
> http://www.ipconnect.fr/>;>
> >
> > Suivez-nous !
> > [picto-twitter] <
> https://twitter.com/ip_connectweets>;>[picto-youtube]<
> > https://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug> <
> https://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug>
> ;>[picto-linkedin]<
> > https://www.linkedin.com/company/20541473/admin/> <
> https://www.linkedin.com/company/20541473/admin/>;>
> >
> >
> > ---
> > 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] La gestion du MAN chez Alphalink...

[Xavier Lemaire]

Bonjour

Voici la réponse hier de nos amis.
Je n'avais pas vu que  : " L'APNF a clairement précisé qu'il était interdit
de transmettre l'entête Identity"
Mais nous on le clean directement sur nos SBC

[image: image.png]


Bon courage


Le ven. 21 juin 2024 à 12:04, Alain Bieuzent  a
écrit :

> Bonjour Jérôme,
>
> L'APNF a clairement précisé qu'il était interdit de transmettre l'entête
> Identity aux client finaux (cela reste de l'info inter-opérateur) et qu'il
> était aussi interdit de transmettre le niveau d'attestation (quel que soit
> la manière utilisée).
>
> Alain
>
> Le 21/06/2024 11:53, « Jérôme RICHARD »  frnog-requ...@frnog.org> au nom de jerome.rich...@va-telecom.fr  jerome.rich...@va-telecom.fr>> a écrit :
>
>
> Bonjour,
>
>
> Le MAN ajoute un entête identity assez conséquent (plus de 500 octet) à
> l'INVITE SIP. Ca peut donner des INVITE à plus de 1600 octets et donc de la
> fragmentation ce qui n'est pas supporté par tous les IPBX. Le symptôme que
> j'ai pu constater c'est que l'IPBX destinataire ne répond pas aux INVITE
> avec entête identity.
>
>
> Nous avons fait le choix de ne pas le diffuser vers les trunks de nos
> clients puisque nous réalisons le contrôle en amont et de diffuser
> uniquement le Attestation-Info (A, B ou C) qui en ressort.
>
>
> Donc a voir si les appels qui posent problème ont l'entête identity dans
> l'INVITE.
>
>
> Cordialement,
> Jérôme RICHARD
>
>
>
>
>
>
>
>
> Le ven. 21 juin 2024 à 09:55, Olivier Varenne via frnog  > a
> écrit :
>
>
> > On est les seuls à être très, TRES, impacté par la mise en place du man
> > chez alphalink depuis plusieurs jours ?
> > On a du mal à identifier l'origine du problème : dans certains cas cela
> > semble être un problème de MTU et de paquet SIP fragmenté, d'autres cas
> > sont plus obscurs...
> > Je suis un peu étonné de rien avoir vu circuler ici, à croire qu'on est
> un
> > cas isolé ?
> > Comment souvent : communication proche du 0, au début quand on a remonté
> > les soucis on nous a gentiment envoyé balader genre « c'est pas notre
> > probleme », et maintenant ça semble être la panique.
> >
> >
> >
> > Cordialement,
> >
> >
> > [cid:image001.png@01DAC3C1.1D673B20]
> > Olivier Varenne
> > Président, R&D et développement
> > T +33 (0)4 27 04 40 00 | ipconnect.fr <
> http://www.ipconnect.fr/>;>
> >
> > Suivez-nous !
> > [picto-twitter] <
> https://twitter.com/ip_connectweets>;>[picto-youtube]<
> > https://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug> <
> https://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug>
> ;>[picto-linkedin]<
> > https://www.linkedin.com/company/20541473/admin/> <
> https://www.linkedin.com/company/20541473/admin/>;>
> >
> >
> > ---
> > 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/
>


-- 


FR 00 33 222 06 41 05
ES 00 34 951 820 240
ES 00 34 683 14 39 64

xav...@amassi-network.com

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
ce message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,

Amassi-network decline toute responsabilite si ce message a ete altere,
deforme ou falsifie. Merci.



This message and its attachments may contain confidential or privileged
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If you have received this email in error, please notify the sender and
delete this message and its attachments.

As emails may be altered, Amassi-network is not liable for messages that
have been modified, changed or falsified.

Thank you.

Re: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...

[Alain Bieuzent]

Bonjour Jérôme,

L'APNF a clairement précisé qu'il était interdit de transmettre l'entête 
Identity aux client finaux (cela reste de l'info inter-opérateur) et qu'il 
était aussi interdit de transmettre le niveau d'attestation (quel que soit la 
manière utilisée).

Alain

Le 21/06/2024 11:53, « Jérôme RICHARD » mailto:frnog-requ...@frnog.org> au nom de jerome.rich...@va-telecom.fr 
> a écrit :


Bonjour,


Le MAN ajoute un entête identity assez conséquent (plus de 500 octet) à
l'INVITE SIP. Ca peut donner des INVITE à plus de 1600 octets et donc de la
fragmentation ce qui n'est pas supporté par tous les IPBX. Le symptôme que
j'ai pu constater c'est que l'IPBX destinataire ne répond pas aux INVITE
avec entête identity.


Nous avons fait le choix de ne pas le diffuser vers les trunks de nos
clients puisque nous réalisons le contrôle en amont et de diffuser
uniquement le Attestation-Info (A, B ou C) qui en ressort.


Donc a voir si les appels qui posent problème ont l'entête identity dans
l'INVITE.


Cordialement,
Jérôme RICHARD








Le ven. 21 juin 2024 à 09:55, Olivier Varenne via frnog mailto:frnog@frnog.org>> a
écrit :


> On est les seuls à être très, TRES, impacté par la mise en place du man
> chez alphalink depuis plusieurs jours ?
> On a du mal à identifier l'origine du problème : dans certains cas cela
> semble être un problème de MTU et de paquet SIP fragmenté, d'autres cas
> sont plus obscurs...
> Je suis un peu étonné de rien avoir vu circuler ici, à croire qu'on est un
> cas isolé ?
> Comment souvent : communication proche du 0, au début quand on a remonté
> les soucis on nous a gentiment envoyé balader genre « c'est pas notre
> probleme », et maintenant ça semble être la panique.
>
>
>
> Cordialement,
>
>
> [cid:image001.png@01DAC3C1.1D673B20]
> Olivier Varenne
> Président, R&D et développement
> T +33 (0)4 27 04 40 00 | ipconnect.fr 
> ;>
>
> Suivez-nous !
> [picto-twitter] 
> ;>[picto-youtube]<
> https://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug> 
> ;>[picto-linkedin]<
> https://www.linkedin.com/company/20541473/admin/> 
> ;>
>
>
> ---
> 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] La gestion du MAN chez Alphalink...

[Jérôme RICHARD]

Bonjour,

Le MAN ajoute un entête identity assez conséquent (plus de 500 octet) à
l'INVITE SIP. Ca peut donner des INVITE à plus de 1600 octets et donc de la
fragmentation ce qui n'est pas supporté par tous les IPBX. Le symptôme que
j'ai pu constater c'est que l'IPBX destinataire ne répond pas aux INVITE
avec entête identity.

Nous avons fait le choix de ne pas le diffuser vers les trunks de nos
clients puisque nous réalisons le contrôle en amont et de diffuser
uniquement le Attestation-Info (A, B ou C) qui en ressort.

Donc a voir si les appels qui posent problème ont l'entête identity dans
l'INVITE.

Cordialement,
Jérôme RICHARD




Le ven. 21 juin 2024 à 09:55, Olivier Varenne via frnog  a
écrit :

> On est les seuls à être très, TRES, impacté par la mise en place du man
> chez alphalink depuis plusieurs jours ?
> On a du mal à identifier l'origine du problème : dans certains cas cela
> semble être un problème de MTU et de paquet SIP fragmenté, d'autres cas
> sont plus obscurs...
> Je suis un peu étonné de rien avoir vu circuler ici, à croire qu'on est un
> cas isolé ?
> Comment souvent : communication proche du 0, au début quand on a remonté
> les soucis on nous a gentiment envoyé balader genre « c'est pas notre
> probleme », et maintenant ça semble être la panique.
>
>
>
> Cordialement,
>
>
> [cid:image001.png@01DAC3C1.1D673B20]
> Olivier Varenne
> Président, R&D et développement
> T +33 (0)4 27 04 40 00 | ipconnect.fr
>
> Suivez-nous !
> [picto-twitter][picto-youtube]<
> https://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug>[picto-linkedin]<
> https://www.linkedin.com/company/20541473/admin/>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...

[Alain Bieuzent]

Quels genre de problème, appels cassés ?, pas de réponse aux INVITES ?

Le 21/06/2024 09:55, « Olivier Varenne via frnog » mailto:frnog-requ...@frnog.org> au nom de frnog@frnog.org 
> a écrit :


On est les seuls à être très, TRES, impacté par la mise en place du man chez 
alphalink depuis plusieurs jours ?
On a du mal à identifier l'origine du problème : dans certains cas cela semble 
être un problème de MTU et de paquet SIP fragmenté, d'autres cas sont plus 
obscurs...
Je suis un peu étonné de rien avoir vu circuler ici, à croire qu'on est un cas 
isolé ?
Comment souvent : communication proche du 0, au début quand on a remonté les 
soucis on nous a gentiment envoyé balader genre « c'est pas notre probleme », 
et maintenant ça semble être la panique.






Cordialement,




[cid:image001.png@01DAC3C1.1D673B20]
Olivier Varenne
Président, R&D et développement
T +33 (0)4 27 04 40 00 | ipconnect.fr 
;>


Suivez-nous !
[picto-twitter] 
;>[picto-youtube]
 
;>[picto-linkedin]
 ;>




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





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

Re: [FRnOG] [ALERT] La gestion du MAN chez Alphalink...

[Toti FRnOG]

Bonjour,
On a aussi des soucis Alphalink sur une vieille plateforme qu'on essaye
d'éteindre depuis 1 an.
Ils ne sont pas très clairs et le problème n'est soit disant pas chez eux
...
Quand tu dis que maintenant c'est la panique, ça veut dire qu'ils se posent
des questions ?

Le ven. 21 juin 2024 à 10:00, David Ponzone  a
écrit :

> Hmm Alphalink comme fournisseur ?
>
> David
>
> > Le 21 juin 2024 à 09:55, Olivier Varenne via frnog  a
> écrit :
> >
> > On est les seuls à être très, TRES, impacté par la mise en place du man
> chez alphalink depuis plusieurs jours ?
> > On a du mal à identifier l'origine du problème : dans certains cas cela
> semble être un problème de MTU et de paquet SIP fragmenté, d'autres cas
> sont plus obscurs...
> > Je suis un peu étonné de rien avoir vu circuler ici, à croire qu'on est
> un cas isolé ?
> > Comment souvent : communication proche du 0, au début quand on a remonté
> les soucis on nous a gentiment envoyé balader genre « c'est pas notre
> probleme », et maintenant ça semble être la panique.
> >
> >
> >
> > Cordialement,
> >
> >
> > [cid:image001.png@01DAC3C1.1D673B20]
> > Olivier Varenne
> > Président, R&D et développement
> > T +33 (0)4 27 04 40 00 | ipconnect.fr
> >
> > Suivez-nous !
> > [picto-twitter][picto-youtube]<
> https://www.youtube.com/channel/UC4W_ceUZgLBRAeQUjtopVug>[picto-linkedin]<
> https://www.linkedin.com/company/20541473/admin/>
> >
> >
> > ---
> > 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] La gestion du MAN chez Alphalink...

[David Ponzone]

Hmm Alphalink comme fournisseur ?

David

> Le 21 juin 2024 à 09:55, Olivier Varenne via frnog  a écrit :
> 
> On est les seuls à être très, TRES, impacté par la mise en place du man chez 
> alphalink depuis plusieurs jours ?
> On a du mal à identifier l'origine du problème : dans certains cas cela 
> semble être un problème de MTU et de paquet SIP fragmenté, d'autres cas sont 
> plus obscurs...
> Je suis un peu étonné de rien avoir vu circuler ici, à croire qu'on est un 
> cas isolé ?
> Comment souvent : communication proche du 0, au début quand on a remonté les 
> soucis on nous a gentiment envoyé balader genre « c'est pas notre probleme », 
> et maintenant ça semble être la panique.
> 
> 
> 
> Cordialement,
> 
> 
> [cid:image001.png@01DAC3C1.1D673B20]
> Olivier Varenne
> Président, R&D et développement
> T +33 (0)4 27 04 40 00 | ipconnect.fr
> 
> Suivez-nous !
> [picto-twitter][picto-youtube][picto-linkedin]
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

[FRnOG] [ALERT] La gestion du MAN chez Alphalink...

[Olivier Varenne via frnog]

On est les seuls à être très, TRES, impacté par la mise en place du man chez 
alphalink depuis plusieurs jours ?
On a du mal à identifier l'origine du problème : dans certains cas cela semble 
être un problème de MTU et de paquet SIP fragmenté, d'autres cas sont plus 
obscurs...
Je suis un peu étonné de rien avoir vu circuler ici, à croire qu'on est un cas 
isolé ?
Comment souvent : communication proche du 0, au début quand on a remonté les 
soucis on nous a gentiment envoyé balader genre « c'est pas notre probleme », 
et maintenant ça semble être la panique.



Cordialement,


[cid:image001.png@01DAC3C1.1D673B20]
Olivier Varenne
Président, R&D et développement
T +33 (0)4 27 04 40 00 | ipconnect.fr

Suivez-nous !
[picto-twitter][picto-youtube][picto-linkedin]


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

Re: [FRnOG] [TECH] scam live...

[Neo Futur]

Pour info, j ai deja vu ce deepfake scam avec elon musk 2 fois , sur
les chaines thinkerview et spaceX. A chaque fois j ai fait un
signalement a youtube en précisant "crypto scam QR code" et le live a
été bloqué dans la minute qui suit.

On Thu, Jun 20, 2024 at 8:41 PM David Ponzone  wrote:
>
> Ah déjà plus dispo, dommage :)
>
> > Le 20 juin 2024 à 20:20, Nicolas Parpandet via frnog  a 
> > écrit :
> >
> >
> > Hello,
> >
> > Je la connaissais pas celle là : https://www.youtube.com/watch?v=1MscioSU3_Y
> >
> > Un deepfake live sur Youtube pour détourner des crytpos, bienvenu dans le 
> > 21ieme siècle lol.
> >
> > A+
> >
> > Nicolas
> >
> > PS: si ya du haut level sur youtube ici on ne sait jamais... En cours de 
> > diffusion depuis plus de 2 heures.
> >
> >
> > ---
> > 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/

[MISC] Re: [FRnOG] [TECH] scam live...

[Arnaud Launay via frnog]

Le Fri, Jun 21, 2024 at 06:38:54AM +, Nicolas Parpandet via frnog a écrit:
> Si c'est autant connu et pratiqué, cela me laisse encore plus perplexe sur la
> gestion de la plateforme, ils font quoi les ingés chez Google ?

Ils sont occupés à jouer au chat et à la souris avec les adblockers.

Arnaud.


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