RE: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Michel Py]

C'est même pas trollesque tellement c'est triste :
Avant de comprendre si un softphone fonctionne à travers VPN, faut essayer s'il 
fonctionne tout court.

Il y a 2 jours, j'ai essayé un softphone au travers du VPN. Cà n'a pas marché.
Aujourd'hui, j'ai essayé le même softphone directement sur le réseau local.
Pas sur le même VLAN que l'Asterisk, mais routage direct.
Ben çà n'a pas marché non plus. La merde à éviter : https://www.microsip.org/

Faudrait peut-être qu'on fasse une liste des softphones qui ne marchent pas. Ce 
n'est surement pas le seul.

Michel.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "Adrien Rivas" 


> Niveau réseau, l'ASA est dgw ou pas ? 

Non. Il donne assez uniquement à nos réseaux. Et les routes ajoutés sur un 
client VPN Linux sont de la forme "10.10.0.0/16 dev tun0".


> Les routes de VPN sont déclarées sur l'Asterisk si ASA pas dgw ? 

Non. Ni dans la table de routage système, ni dans localnet de XiVo. Dans la 
table de routage, il y a une route par défaut vers le routeur de site, qui, lui 
a une route statique pour le réseau des VPN.


> Au niveau des ACL on a bien la règle net_vpn/16 vers net_vpn/16 ?

Heu non ? On a vpn/16 <-> OUTSIDE


> Parce que ça pourrait ressembler à du routage asymétrique aussi. 

Huuum.


> ALG c'est effectivement mal, ça prend des initiatives qu'on lui a pas
> demandé de prendre et si c'est pas pour faire de la téléphonie via wan ça
> complique pour rien le debug.

A priori, on l'a désactivé depuis vendredi avec un « no inspect sip » et les 
timeout udp/sip configurés sont en dizaines de minutes (juste pour essayer, on 
est d'accord).
Après, comme écrit hier soirr, passer à un OpenVPN sans NAT ni filtrage, ça ne 
résout pas tous les cas d'échecs, donc le VPN ASA n'est pas le seul coupable.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "frnog" 

> pour que ca fonctionne il faut que les ports 1-2 (par default
asterisk rtp soit permis au niveau du asterisk).

C'est OK.


> Par experience si tu te fais trop chier tu peux essayer l'ipv6 donc tu
elimines tous les problemes de nat.

J'ai ni l'un, ni l'autre. :)


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[mailist via frnog]

Bonjour,

je ne sais pas si je suis trop tard maid bon.

pour que ca fonctionne il faut que les ports 1-2 (par default
asterisk rtp soit permis au niveau du asterisk).

Par experience si tu te fais trop chier tu peux essayer l'ipv6 donc tu
elimines tous les problemes de nat.

-pjsip show endpoints

-rtp set logger on (tu peux vois l'ip sur laquelle les packets rtp sont
envoyes)

-pjsip set logger on (si tu utilised pjsip, je le trouve beaucoup plus
stable et simple que chan_sip)

et tu peux regarder si tu vois quel est le probleme


Bon courage


vincent

On 3/17/20 9:04 AM, pisrateurb...@free.fr wrote:
> Bonjour à tous,
>
>
> On mixte du softphone (Zoiper) et du téléphone IP depuis 15 ans en IPsec/VPN 
> SSL,anciennement MPLS sur du Asterix/Xivo/Mitel et anciennement Ericson sur 
> des réseaux internes pas RFC 1918 (quelle idée mais c'est historique)
> Au tout début j'ai eu des problèmes d'implémentations à cause du NAT et/ou 
> des ACL, parfois parce qu'il n'y a pas que du 5060 mais du 5061 ou parce que 
> les communications coupaient au bout de 15 minutes à cause du routeur 
> central. Depuis qu'on a éliminé le NAT je n'ai plus ce soucis, SAUF lors 
> d'une expérimentions en TSE multi-utilisateur avec 1 IP par utilisateur.
> Petite précision, pas besoin d'utiliser de STUN ou de proxy NAT SBC.
>
> Ah si, j'ai encore un site avec passerelle externe et NAT qui me fait des 
> communications blanches sur certains SDA et opérateurs.
>
>
> @+
>
> Clément
>
>
> - Mail original -
> De: "Guillaume LUCAS" 
> À: frnog-t...@frnog.org
> Envoyé: Lundi 16 Mars 2020 22:05:07
> Objet: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment 
> autant de bugs que ça dans les implémentations SIP ?!)
>
> Bonjour à tous, 
>
> Mes collègues et moi rencontrons des problèmes avec nos softphones SIP, et 
> j'aimerais un avis et surtout être réconforté. 
> => Je sais que TOUTES les implémentations VOIP foirent plus ou moins. Je me 
> souviens d'une box Numericable qui rebootait lorsqu'un SIP INVITE légitime > 
> 1645 octets arrivait du WAN. Je me souviens des erreurs de segmentation 
> aléatoires de Jitsi/Ekiga. Je me souviens des messages SIP pas trop conformes 
> à la norme et à la validation approximative des messages SIP reçus. Etc. 
> => Mais je doute que le nombre de problèmes que nous rencontrons (et leur 
> amplitude) soit normal. 
> => Je suis dans une démarche de compréhension technique des problèmes 
> rencontrés, donc je ne suis pas intéressé par des alternatives à des 
> softphones. 
>
>
> Depuis 5 ans, nous utilisons le PABX Asterisk empaqueté dans la solution 
> XiVo. Nous avons des postes téléphoniques SNOM, des téléphones analogiques, 
> des T2, etc. IPv4 uniquement. Ce PABX n'est pas joignable depuis l'extérieur 
> (en IP). 
>
> Nous avons aussi un VPN Cisco ASA. Adressage IPv4 RFC1918 (les réseaux 
> internes sont plutôt adressés avec des IPv4 publiques, pas de v6). Pas 
> d'IPv6. Accès aux réseaux internes, pas d'accès à Internet. Pas de filtrage 
> particulier (oui, n'importe quel utilisateur du VPN peut se promener dans 
> tous les réseaux internes, ça va changer). 
>
> Depuis 6 mois environ, nous avons de très rares softphones Linphone 
> majoritairement sous winwin 7/10. Ils sont utilisés conjointement avec le 
> VPN. 
>
> Jusque-là, personne nous a fait remonter des problèmes sur les 
> softphones+VPN. Mais vu le peu d'utilisateurs… 
> Le coronavirus débarque et nous voilà priés de fournir un softphone à tout le 
> monde. Et là, surprise, ça ne marche plus. Ou plus tout le temps. Ou plus 
> pour tout le monde. 
>
>
> Le premier problème est un classique. Entre un softphone+VPN à domicile et un 
> poste SNOM du bureau, soit les deux interlocuteurs ne s'entendent pas, soit 
> un seul entend l'autre. 
> => Dans ses SDP, Linphone insère l'IP RFC1918 de l'interface physique (eth0, 
> Wi-Fi, etc.) plutôt que celle du VPN. Forcément, ça ne fonctionne pas. 
> => On installe un serveur STUN dans le réseau de l'organisation. On configure 
> STUN dans les paramètres de Linphone et ça fonctionne. 
> => Notons que certains Linphone fonctionnent aléatoirement et temporairement 
> sans STUN. Même chose avec Jitsi. Comment est-ce possible ? 
> => Un Wireshark nous montre qu'une fois l'échange SIP initié, le client cause 
> en STUN au PABX et que celui-ci répond. Pourquoi ça ne suffit pas toujours ? 
> C'est d'ailleurs bizarre, car aucun serveur STUN écoute en permanence, on 
> dirait que c'est fait à la demande ? 
>
>
> Deuxième problème. Lors d'une conversation entre un Linphone 3.11 empaqueté 
> dans Debian GNU/Linux ou Ubuntu GNU/Linux et un Linphone 4.1.1 GNU/Linux 
> distribué via Flatpak, si c'est le Linphone 4.1.1 qui initie la conversation, 
> la conversation durera 31/32 secs au maximum avant raccrochage auto. 
> => Pas de soucis si c'est le Linphone 3.11 qui initie la conversation. 
> => Pas de problème quand le Linphone 4.1.1 cause à un SNOM ou à un 06/09 
> externe. 
> => Rien 

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Adrien Rivas]

Niveau réseau, l'ASA est dgw ou pas ? Les routes de VPN sont déclarées sur
l'Asterisk si ASA pas dgw ? Au niveau des ACL on a bien la règle net_vpn/16
vers net_vpn/16 ? Parce que ça pourrait ressembler à du routage asymétrique
aussi. Le firewall de la solution internet security peut faire ce genre de
choses aussi (coucou Kaspersky EDR).

ALG c'est effectivement mal, ça prend des initiatives qu'on lui a pas
demandé de prendre et si c'est pas pour faire de la téléphonie via wan ça
complique pour rien le debug.

Le mer. 18 mars 2020 à 21:30, Guillaume LUCAS <
guillaume.lu...@univ-avignon.fr> a écrit :

> Le 18/03/2020 à 21:21, Daniel via frnog a écrit :
> > Essaye alors Twinkle.
>
> Je crois que ça a été fait et que ça ne fonctionnait pas.
> Je parle avant nat=yes et directmedia=no, bien entendu.
>
>
> > Au passage, nat=yes est déprécié, mets nat=force_rport,comedia
>
> XiVo le fait tout seul. Je dis nat=yes pour gagner du temps.
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

Le 18/03/2020 à 21:21, Daniel via frnog a écrit :
Essaye alors Twinkle. 


Je crois que ça a été fait et que ça ne fonctionnait pas.
Je parle avant nat=yes et directmedia=no, bien entendu.



Au passage, nat=yes est déprécié, mets nat=force_rport,comedia


XiVo le fait tout seul. Je dis nat=yes pour gagner du temps.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Daniel via frnog]

Le 18/03/2020 à 20:51, Guillaume LUCAS a écrit :

Le 17/03/2020 à 22:21, Daniel via frnog a écrit :

. tester avec csipsimple qui est très stable


Mais plus maintenu, plus dispo sur f-droid, etc.
Essaye alors Twinkle. Au passage, nat=yes est déprécié, mets 
nat=force_rport,comedia


--
Daniel Huhardeaux
+33.368460...@tootai.net  sip:8...@sip.tootai.net
+41.445532...@swiss-itech.chtootaiNET


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

Le 18/03/2020 à 14:27, Guillaume LUCAS a écrit :

Je vais tester avec du Linphone 4.1.1 winwin, etc. Si pas d'amélioration, ça 
validera que le VPN ASA n'est pas coupable.


Je retiens :
  * OpenVPN (+ garantie d'absence de filtrage et de NAT) apporte rien 
par rapport à ASA pour des conversation Linphone GNU/Linux. Le RTP 
learning se fait tout pareil, relais RTP tout pareil, et si ça échoue, 
P2P tout pareil ;


  * OpenVPN fait fonctionner Linphone 4.1.1 winwin. Je ne l'ai jamais 
vu fonctionner avec l'ASA. Le RTP learning échoue donc ça bascule en P2P 
et ça marche. Plus de coupure après 30 secs sur Linphone version winwin 
store ;


  * Mais OpenVPN ne suffit pas à faire fonctionner toutes les 
conversations Linphone winwin <> Linphone GNU/Linux. À versions 
identiques, certains collègues ne s'entendent pas. Puis s'entendent lors 
d'un essai 2 minutes plus tard puis ne s'entendent plus lors d'un autre 
essai, puis… Bref, très aléatoire.


Synthèse : ce que dit Raphaël => un ASA ça se comporte bizarrement, mais 
son absence ne résout pas tout.



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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

Le 18/03/2020 à 14:06, Raphael Mazelier a écrit :

Sinon si tu peux centraliser la conf de tes linphones ca serait aussi
pour toi le meilleur, avec pareil l'option qui va bien.


Je n'ai pas compris ? Comment centralises-tu la conf' des linphones ?


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

Le 17/03/2020 à 22:21, Daniel via frnog a écrit :

. tester avec csipsimple qui est très stable


Mais plus maintenu, plus dispo sur f-droid, etc.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

Le 17/03/2020 à 22:04, Michel Py a écrit :

Guillaume LUCAS a écrit :
C'est ça. Et ceux essayés (Jitsi, Linphone, Blink, Zoiper) échouent sur le 
choix de
l'IP, soit tout le temps, soit par moments. D'où mon usage de STUN.


Maintenant je comprends. Je ne me doutais pas que les clients softphone avaient 
ce genre de limitation; c'est bizarre que personne n'ait pensé a çà avant.


De ce que j'ai compris, ce problème est censé être résolu par nat=yes 
dans Asterisk (Asterisk réécrit le SDP avec l'IP source effective du 
paquet SIP qu'il reçoit, entre autres) et/ou par ICE dans lequel le 
principe est de donner tous les couples IP+port permettant de te joindre 
et que l'interlocuteur les essayent, un à un. Sauf que ICE n'a pas 
fonctionné avec moi…


Notons que les navigateurs web sont bien équipés pour ça dans le cadre 
de webrtc. Dans la config' de Firefox, la clé « 
media.peerconnection.ice.force_interface » permet de sélectionner 
l'interface à utiliser… Ça a aussi ses inconvénients genre quelqu'un qui 
voudrait faire de la téléphonie pro (supposons avec VPN) et perso (sans 
VPN) devrait en changer la valeur en permanence…



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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "Raphael Mazelier" 

> Le rtp learning c'est une invention d'asterisk j'imagine qui doit être 
> une fonctionnalité qui essaie de découvrir la topologie réseau et donc 
> setter les adresses ip dans le rtp.

Ouki.


> Une bonne manière de bien comprendre c'est de démarrer avec un 
> opensips/kamailio et du rtpproxy/mediaproxy.

J'aurais aimé, mais je dois faire avec l'existant.


J'ai mis nat=yes et directmedia=no et viré STUN sur deux comptes SIP. 
=> Ça marche, y compris Linphone 3.11, y compris Linphone 4.1.1 windows avec 
VPN ASA (ça n'a jamais fonctionné avant, jamais jamais jamais).
=> J'attends que d'autres collègues testent et si c'est positif, OK pour 
généraliser ça sur les comptes SIP associées à des softphones (non, pas touche 
au reste pour l'instant).


Je retiens :
  * RTP autolearn est chatouilleux, même sans filtrage/NAT sur le réseau et aux 
extrémités, il peut foirer et donc faire basculer une conversation en P2P ;

  * Lors de cette "bascule" P2P, on peut se retrouver avec un interlocuteur qui 
envoie son flux RTP au PABX et l'autre qui l'envoie en direct, ce qui est en 
contradiction avec derniers SDP échangés ;
  => Je pense qu'il y a un bug dans certains softphones genre Linphone qui 
envoie son RTP à l'Asterisk, reçoit le SDP "non en fait envoie en direct", qui 
journalise « Change audio stream destination: RTP=10.30.1.24:7078 » (c'est la 
bonne IP de l'interlocuteur, celle du dernier SDP échangé, donc le SDP 
est parsé) mais qui cesse d'envoyer du RTP…

  * Les implémentations rattrapent certains coups comme elles le peuvent genre 
pas de coupure après 30 secs avec Linphone 4.1.1 alors qu'il y en a sur 
Linphone 3.11, le reste (réseau, PABX, terminaux) étant inchangé. Linphone 
GNU/linux semble être moins chatouilleux que Linphone winwin à version 
équivalente ;

  * Il y a quand même des bugs curieux dans les implémentations.
  => Réduire la fenêtre d'appel de Linphone winwin = plus de son dans les 
deux sens, l'agrandir à nouveau fait revenir le son ;
  => Linphone 4.1.1 winwin ne peut pas être appelé pendant quelques 
dizaines de secondes après avoir raccroché un appel (même quand c'est lui qui 
raccroche, Asterisk voit bien le hangup) ;
  => Linphone ne signale pas un appel entrant ;
  => Réponse STUN ignorée (IP obtenue pas inséré dans le SDP) ;
  => Etc.








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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Raphael Mazelier]

Si tu savais… :D

Je bloque sur un point sur l'idée de relais RTP : que se passe-t-il quand le 
RTP learning foire ? Fin des appels ?
Parce que là, je viens de tester entre du Linphone winwin et Linux. Ça ne 
fonctionnait pas avant (donc le VPN OpenVPN apporte quelque chose) et, surtout, 
je constate que le RTP learning n'arrive pas au stade
« Complete » et que les softphones échangent en P2P. Que va-t-il se passer pour 
eux si je force un relais RTP ? Moi je comprends qu'ils ne pourront plus se 
téléphoner… Pas cool.



Le rtp learning c'est une invention d'asterisk j'imagine qui doit être 
une fonctionnalité qui essaie de découvrir la topologie réseau et donc 
setter les adresses ip dans le rtp.


C'est aussi pour cela que je n'aime pas trop asterisk, ca fait beaucoup 
de magie et a la fin on ne comprends pas vraiment ce que l'on fait.


Une bonne manière de bien comprendre c'est de démarrer avec un 
opensips/kamailio et du rtpproxy/mediaproxy.


--

Raphael Mazelier


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

RE: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Michel Py]

> Kevin CHAILLY a écrit :
> Dans la guerre Asterisk vs FreeSWITCH pour des 픯픞픦픰픬픫픰 픥픦픰픱픬픯픦픮픲픢픰 ™ nous 
> utilisons des produits basés sur Asterisk

Sympa la fonte, et pareil ici.

>>> Daniel Huhardeaux a écrit :
>>> Et rajoute directmedia = no

C'est bien çà que je voulais dire, j'avais le nom du paramètre sur le bout de 
la langue.

>> Guillaume LUCAS a écrit :
>> Côté Asterisk, donc. J'suis pas encore chaud pour qu'Asterisk soit relais 
>> RTP de tout le monde..

> Raphael Mazelier a écrit :
> Pourquoi ? sans transcoding c'est juste la copie de paquet, ça coûte que 
> dalle en cpu. Pareil en réseau. Et ça va résoudre 90% de tes problèmes.

Je plussoie.

Michel.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Daniel via frnog]

Je pense que David ne supporte plus le confinement ;)

Le 18/03/2020 à 16:50, Kevin CHAILLY | Service Technique a écrit :

Mon dieu nous sommes déjà vendredi !

Dans la guerre Asterisk vs FreeSWITCH pour des 픯픞픦픰픬픫픰 픥픦픰픱픬픯픦픮픲픢픰 ™ nous 
utilisons des produits basés sur Asterisk,

Quelles bonnes raisons y-a-t-il d'utiliser FreeSWITCH ? (j'veux dire, là, c'est 
le moment de réformer l'historique !)

Kévin

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de David 
Ponzone
Envoyé : mercredi 18 mars 2020 16:18
À : Guillaume LUCAS 
Cc : frnog 
Objet : Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il 
vraiment autant de bugs que ça dans les implémentations SIP ?!)

Bon,

Etape 1: tu vires ton *
Etape 2: tu utilises un produit FreeSWITCH-based Etape 3: tu dors peinard et 
plus jamais tu te poses ce genre de questions :)


Le 18 mars 2020 à 16:10, Guillaume LUCAS  a 
écrit :

- Mail original -

De: "David Ponzone" 
Mais Guillaume veut pas nous avouer que son * tourne sur un RaspPi 1
et que donc le rte-proxy….:)

Si tu savais… :D

Je bloque sur un point sur l'idée de relais RTP : que se passe-t-il quand le 
RTP learning foire ? Fin des appels ?
Parce que là, je viens de tester entre du Linphone winwin et Linux. Ça
ne fonctionnait pas avant (donc le VPN OpenVPN apporte quelque chose) et, 
surtout, je constate que le RTP learning n'arrive pas au stade « Complete » et 
que les softphones échangent en P2P. Que va-t-il se passer pour eux si je force 
un relais RTP ? Moi je comprends qu'ils ne pourront plus se téléphoner… Pas 
cool.


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


--
Daniel Huhardeaux
+33.368460...@tootai.net  sip:8...@sip.tootai.net
+41.445532...@swiss-itech.chtootaiNET


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

RE: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Kevin CHAILLY | Service Technique]

Mon dieu nous sommes déjà vendredi ! 

Dans la guerre Asterisk vs FreeSWITCH pour des 픯픞픦픰픬픫픰 픥픦픰픱픬픯픦픮픲픢픰 ™ nous 
utilisons des produits basés sur Asterisk,

Quelles bonnes raisons y-a-t-il d'utiliser FreeSWITCH ? (j'veux dire, là, c'est 
le moment de réformer l'historique !)

Kévin

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de David 
Ponzone
Envoyé : mercredi 18 mars 2020 16:18
À : Guillaume LUCAS 
Cc : frnog 
Objet : Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il 
vraiment autant de bugs que ça dans les implémentations SIP ?!)

Bon,

Etape 1: tu vires ton *
Etape 2: tu utilises un produit FreeSWITCH-based Etape 3: tu dors peinard et 
plus jamais tu te poses ce genre de questions :)

> Le 18 mars 2020 à 16:10, Guillaume LUCAS  a 
> écrit :
> 
> - Mail original -
>> De: "David Ponzone" 
> 
>> Mais Guillaume veut pas nous avouer que son * tourne sur un RaspPi 1 
>> et que donc le rte-proxy….:)
> 
> Si tu savais… :D
> 
> Je bloque sur un point sur l'idée de relais RTP : que se passe-t-il quand le 
> RTP learning foire ? Fin des appels ?
> Parce que là, je viens de tester entre du Linphone winwin et Linux. Ça 
> ne fonctionnait pas avant (donc le VPN OpenVPN apporte quelque chose) et, 
> surtout, je constate que le RTP learning n'arrive pas au stade « Complete » 
> et que les softphones échangent en P2P. Que va-t-il se passer pour eux si je 
> force un relais RTP ? Moi je comprends qu'ils ne pourront plus se téléphoner… 
> Pas cool.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[David Ponzone]

Bon,

Etape 1: tu vires ton *
Etape 2: tu utilises un produit FreeSWITCH-based
Etape 3: tu dors peinard et plus jamais tu te poses ce genre de questions :)

> Le 18 mars 2020 à 16:10, Guillaume LUCAS  a 
> écrit :
> 
> - Mail original -
>> De: "David Ponzone" 
> 
>> Mais Guillaume veut pas nous avouer que son * tourne sur un RaspPi 1 et que 
>> donc le rte-proxy….:)
> 
> Si tu savais… :D
> 
> Je bloque sur un point sur l'idée de relais RTP : que se passe-t-il quand le 
> RTP learning foire ? Fin des appels ?
> Parce que là, je viens de tester entre du Linphone winwin et Linux. Ça ne 
> fonctionnait pas avant (donc le VPN OpenVPN apporte quelque chose) et, 
> surtout, je constate que le RTP learning n'arrive pas au stade 
> « Complete » et que les softphones échangent en P2P. Que va-t-il se passer 
> pour eux si je force un relais RTP ? Moi je comprends qu'ils ne pourront plus 
> se téléphoner… Pas cool.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

- Mail original -
> De: "David Ponzone" 

> Mais Guillaume veut pas nous avouer que son * tourne sur un RaspPi 1 et que 
> donc le rte-proxy….:)

Si tu savais… :D

Je bloque sur un point sur l'idée de relais RTP : que se passe-t-il quand le 
RTP learning foire ? Fin des appels ?
Parce que là, je viens de tester entre du Linphone winwin et Linux. Ça ne 
fonctionnait pas avant (donc le VPN OpenVPN apporte quelque chose) et, surtout, 
je constate que le RTP learning n'arrive pas au stade 
« Complete » et que les softphones échangent en P2P. Que va-t-il se passer pour 
eux si je force un relais RTP ? Moi je comprends qu'ils ne pourront plus se 
téléphoner… Pas cool.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Stéphane Rivière]

> Les SNOM également et avec ces deux fabricants je n'ai *jamais* eu de
> problème en utilisant leur VPN. 

+1

> . tester avec csipsimple qui est très stable

+1

> . passer en IAX avec Zoiper. IAX c'est bien ;)
> 
> PS: mon dialplan qui sauve mes journées:
> ...
> same = n,Dial(PJSIP/xxx@mytrunk,,)
> same = n,ExecIf($["${DIALSTATUS}" = "CHANUNAVAIL" | "${DIALSTATUS}" =
> "CONGESTION"]?Dial(IAX2/mytrunk/xxx,,))

Pas c*n si la terminaison cause IAX... Merci pour la stuce :)

-- 
Be Seeing You
Number Six


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[David Ponzone]

Raphael,

Tu prêches un convaincu.
Mais Guillaume veut pas nous avouer que son * tourne sur un RaspPi 1 et que 
donc le rte-proxy….:)

> Le 18 mars 2020 à 14:50, Raphael Mazelier  a écrit :
> 
> 
> On 18/03/2020 14:34, David Ponzone wrote:
>> Je connais pas ton archi, mais si derrière t’as une Patton/Audiocodes/Bero 
>> qui peut joindre les endpoint, alors oui, tu peux faire du direct.
>> Sinon tu es obligé d’utiliser l’* comme B2BUA/SBC.
>> 
>> 
> Oui mais la encore c'est casse gueule. Ce n'est pas pour rien qu'on a inventé 
> les rtp-proxy.
> 
> --
> 
> Raphael Mazelier
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Raphael Mazelier]

On 18/03/2020 14:34, David Ponzone wrote:

Je connais pas ton archi, mais si derrière t’as une Patton/Audiocodes/Bero qui 
peut joindre les endpoint, alors oui, tu peux faire du direct.
Sinon tu es obligé d’utiliser l’* comme B2BUA/SBC.


Oui mais la encore c'est casse gueule. Ce n'est pas pour rien qu'on a 
inventé les rtp-proxy.


--

Raphael Mazelier


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[David Ponzone]

Je connais pas ton archi, mais si derrière t’as une Patton/Audiocodes/Bero qui 
peut joindre les endpoint, alors oui, tu peux faire du direct.
Sinon tu es obligé d’utiliser l’* comme B2BUA/SBC.

> Le 18 mars 2020 à 14:29, Guillaume LUCAS  a 
> écrit :
> 
>> - Mail original -
>> De: "David Ponzone" 
> 
>> Le plus lourd, c’est les appels vers et depuis l’extérieur, qui seront plus 
>> autour de 100 et qui sont obligatoirement relayés par l’*.
> 
> Quand RTP learning fonctionne. Sinon c'est p2p, entre le softphone/SNOM et la 
> passerelle T2, non ?
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "David Ponzone" 

> Le plus lourd, c’est les appels vers et depuis l’extérieur, qui seront plus 
> autour de 100 et qui sont obligatoirement relayés par l’*.

Quand RTP learning fonctionne. Sinon c'est p2p, entre le softphone/SNOM et la 
passerelle T2, non ?


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "David Ponzone" 

Vérifie si Linphone 3 a pas besoin que tu lui dises de mettre le paramètre 
rport.

=> use_rport=1 dans la section sip de linphonerc = pas d'amélioration.

Pour la coupure après 31/32/36 secs de conversation, j'ai (re)mis 
session-timers=refuse sur les deux comptes SIP impliqués. Pas de changement.

Comme dit dans mon précédent mail, je suis désormais certain de pas avoir de 
filtrage aux extrémités (iptables -L -n -v) ni sur le VPN (pfctl -d) ni de NAT 
(pfctl -d).

J'arrive à la conclusion que y'a un bug sur Linphone 3.11. Une autre 
explication m'échappe-t-elle ?

Je vais tester avec du Linphone 4.1.1 winwin, etc. Si pas d'amélioration, ça 
validera que le VPN ASA n'est pas coupable. 
Partant de là, si je comprends bien, soit je reste borné et donc il n'y a pas 
de solution évidente, soit je force Asterisk comme relais RTP.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[David Ponzone]

>> 
> Pourquoi ? sans transcoding c'est juste la copie de paquet, ça coûte que 
> dalle en cpu. Pareil en réseau. Et ça va résoudre 90% de tes problèmes.
> 

Ouais et puis les appels internes, c’est pas si fréquent de nos jours, même en 
télétravail.
Sur 800 personnes, je penses pas que tu dépasses 50 appels en crête.
Le plus lourd, c’est les appels vers et depuis l’extérieur, qui seront plus 
autour de 100 et qui sont obligatoirement relayés par l’*.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Raphael Mazelier]

On 18/03/2020 13:47, Guillaume LUCAS wrote:


Côté Asterisk, donc.
J'suis pas encore chaud pour qu'Asterisk soit relais RTP de tout le monde… D'un 
autre côté… avec le RTP autolearn, il l'est implicitement depuis longtemps, si 
je comprends bien ?


Pourquoi ? sans transcoding c'est juste la copie de paquet, ça coûte que 
dalle en cpu. Pareil en réseau. Et ça va résoudre 90% de tes problèmes.


Mon conseil tu fais tout passer par ton asterisk SIG+RTP, et tu trouve 
la conf qui va bien pour laisser les ports RTP ouverts. (parce que sinon 
effectivement tu vas tomber dans les problèmes de comm semi blanche à 
30s, enfin le temps du timeout d'un port nat udp sur le fw local). Sinon 
si tu peux centraliser la conf de tes linphones ca serait aussi pour toi 
le meilleur, avec pareil l'option qui va bien.


--

Raphael Mazelier


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Daniel via frnog]

Le 18/03/2020 à 13:47, Guillaume LUCAS a écrit :

- Mail original -
De: "frnog" 
Et rajoute directmedia = no

Côté Asterisk, donc.
J'suis pas encore chaud pour qu'Asterisk soit relais RTP de tout le monde… D'un 
autre côté… avec le RTP autolearn, il l'est implicitement depuis longtemps, si 
je comprends bien ?
Oui. Ceci dit en trouvant la-les sources du problème tu pourras toujours 
ajuster derrière ;)


--
Daniel Huhardeaux
+33.368460...@tootai.net  sip:8...@sip.tootai.net
+41.445532...@swiss-itech.chtootaiNET


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "frnog" 

> Et rajoute directmedia = no

Côté Asterisk, donc.
J'suis pas encore chaud pour qu'Asterisk soit relais RTP de tout le monde… D'un 
autre côté… avec le RTP autolearn, il l'est implicitement depuis longtemps, si 
je comprends bien ?


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Daniel via frnog]

Le 18/03/2020 à 13:23, David Ponzone a écrit :

Vérifie si Linphone 3 a pas besoin que tu lui dises de mettre le paramètre 
rport.

Et rajoute directmedia = no



Le 18 mars 2020 à 12:57, Guillaume LUCAS  a 
écrit :

Je me suis souvenu que j'avais un PFSense de test dans un coin avec un OpenVPN 
déjà tout prêt.
Lui fait du NAT. Il a aucune règle de filtrage et j'ai pfctl -d. Utilisation de 
TUN + un même réseau pour tous les clients. Aucun pare-feu sur les clients.

Premier test : je monte ce VPN OpenVPN, je démarre Linphone, il m'enregistre 
sur le PABX : ip src = IP du PFSense (donc NAT). Je tél à la chambre de 
conférence. Je n'ai pas de son. Environ normal sauf que STUN aurait du faire le 
job puisque l'IP retournée par le serveur STUN était bien l'IP de NAT. Donc 
STUN fail. Sur mon compte SIP, je mets nat=yes. Restart Linphone. Ça fonctionne.
=> conclusion : nat=yes produit bien un effet quand y'a du NAT. J'en doutais 
pas, mais j'étais surpris que ça ne fonctionne pas hier.

Deuxième test : je vire le NAT du PFSense. Je teste avec mtr, netcat, etc. que j'peux 
faire du client<->client. Je vire nat=yes. Appel entre collègues avec Linphone 
4.1.1. Ça marche. Pas de bug des 30 secondes. Mais, avec cet interlocuteur, ça a 
souvent fonctionné, donc ça veut rien dire.

Troisième test : Même que deuxième test, mais avec Linphone 3.11 d'un côté. On 
s'entend, mais coupure auto après 36 secondes (et plus 31/32 :D).
=> conclusion : le VPN ASA est pas le seul fautif, on dirait.

J'ai analysé les captures réseau des 3 tests et le journal Asterisk.
  * Quand ça fonctionne avec Linphone 4.1.1 des deux côtés, l'Asterisk est en 
relais RTP.
  * Dans le journal Asterisk, je vois un « Strict RTP learning complete » pour 
mon collègue et pour moi.

  * Quand ça fonctionne durant 30 secs avec Linphone 4.1.1 d'un côté et 3.11 de 
l'autre, Asterisk n'est pas en relais RTP.
  * Dans le journal Asterisk, je vois un aucun « Strict RTP learning complete » 
pour qui que ce soit. Il y a bien les « Strict RTP learning after remote 
address set to », mais ça s'arrête là.

  * Quand un seul interlocuteur entend l'autre avec Linphone 3.11 (car je 
triche), je vois un flux RTP envoyé à Asterisk, l'autre envoyé en direct. Je 
vois un « Strict RTP learrning complete » pour moi, et que du « Strict RTP 
learning after remote address set to » avec l'IP de VPN du collègue, mais pas 
de « Complete ». Donc je n'entends pas le collègue et son flux RTP arrive en 
direct, sans passer par Asterisk et se fait probablement jeter par un contrôle 
d'intégrité de Linphone.


J'en déduis qu'il est difficile d'accuser l'ASA.

On dirait qu'il y a un fail de RTP autolearn avec Linphone 3.11, tout le reste 
étant identique par ailleurs. Pourquoi ?

Je vais faire tester le VPN OpenVPN garanti sans NAT ni filtrage à plus de 
collègues.


- Mail original -
De: "Stéphane Rivière" 
À: "frnog" 
Envoyé: Mardi 17 Mars 2020 20:32:09
Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment 
autant de bugs que ça dans les implémentations SIP ?!)


Merci pour ce diag. :)

On est tous arrivé au même.


Quand la colère va me prendre,

Ou la lassitude...


je vais monter un VPN OpenVPN tout neuf sur lequel je serai sûr que y'a pas d'ACL 
ni rien et hop hop >hop. Pas envie de démerder un Cisco ASA.

La VOIP en SIP/RTP, ça marche. Mais dans ta config (et beaucoup
d'autres), c'est avec un VPN qu'on fait de la VOIP en mode KISS qui
tombe en marche à tous les coups.

Parce qu'à la base c'est aussi foireux qu'un FTP passif (comme déjà dit
par un colistier). C'est ainsi. Et au moins, on est désormais dans une
techno unique. Du temps de l'ISDN y'avait aussi des trucs pourris.

--
Stéphane Rivière
Ile d'Oléron - France


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


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


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


--
Daniel Huhardeaux
+33.368460...@tootai.net  sip:8...@sip.tootai.net
+41.445532...@swiss-itech.chtootaiNET


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[David Ponzone]

Vérifie si Linphone 3 a pas besoin que tu lui dises de mettre le paramètre 
rport.

> Le 18 mars 2020 à 12:57, Guillaume LUCAS  a 
> écrit :
> 
> Je me suis souvenu que j'avais un PFSense de test dans un coin avec un 
> OpenVPN déjà tout prêt.
> Lui fait du NAT. Il a aucune règle de filtrage et j'ai pfctl -d. Utilisation 
> de TUN + un même réseau pour tous les clients. Aucun pare-feu sur les 
> clients. 
> 
> Premier test : je monte ce VPN OpenVPN, je démarre Linphone, il m'enregistre 
> sur le PABX : ip src = IP du PFSense (donc NAT). Je tél à la chambre de 
> conférence. Je n'ai pas de son. Environ normal sauf que STUN aurait du faire 
> le job puisque l'IP retournée par le serveur STUN était bien l'IP de NAT. 
> Donc STUN fail. Sur mon compte SIP, je mets nat=yes. Restart Linphone. Ça 
> fonctionne.
> => conclusion : nat=yes produit bien un effet quand y'a du NAT. J'en doutais 
> pas, mais j'étais surpris que ça ne fonctionne pas hier.
> 
> Deuxième test : je vire le NAT du PFSense. Je teste avec mtr, netcat, etc. 
> que j'peux faire du client<->client. Je vire nat=yes. Appel entre collègues 
> avec Linphone 4.1.1. Ça marche. Pas de bug des 30 secondes. Mais, avec cet 
> interlocuteur, ça a souvent fonctionné, donc ça veut rien dire. 
> 
> Troisième test : Même que deuxième test, mais avec Linphone 3.11 d'un côté. 
> On s'entend, mais coupure auto après 36 secondes (et plus 31/32 :D).
> => conclusion : le VPN ASA est pas le seul fautif, on dirait.
> 
> J'ai analysé les captures réseau des 3 tests et le journal Asterisk.
>  * Quand ça fonctionne avec Linphone 4.1.1 des deux côtés, l'Asterisk est en 
> relais RTP.
>  * Dans le journal Asterisk, je vois un « Strict RTP learning complete » pour 
> mon collègue et pour moi.
> 
>  * Quand ça fonctionne durant 30 secs avec Linphone 4.1.1 d'un côté et 3.11 
> de l'autre, Asterisk n'est pas en relais RTP.
>  * Dans le journal Asterisk, je vois un aucun « Strict RTP learning complete 
> » pour qui que ce soit. Il y a bien les « Strict RTP learning after remote 
> address set to », mais ça s'arrête là.
> 
>  * Quand un seul interlocuteur entend l'autre avec Linphone 3.11 (car je 
> triche), je vois un flux RTP envoyé à Asterisk, l'autre envoyé en direct. Je 
> vois un « Strict RTP learrning complete » pour moi, et que du « Strict RTP 
> learning after remote address set to » avec l'IP de VPN du collègue, mais pas 
> de « Complete ». Donc je n'entends pas le collègue et son flux RTP arrive en 
> direct, sans passer par Asterisk et se fait probablement jeter par un 
> contrôle d'intégrité de Linphone.
> 
> 
> J'en déduis qu'il est difficile d'accuser l'ASA. 
> 
> On dirait qu'il y a un fail de RTP autolearn avec Linphone 3.11, tout le 
> reste étant identique par ailleurs. Pourquoi ?
> 
> Je vais faire tester le VPN OpenVPN garanti sans NAT ni filtrage à plus de 
> collègues.
> 
> 
> ----- Mail original -----
> De: "Stéphane Rivière" 
> À: "frnog" 
> Envoyé: Mardi 17 Mars 2020 20:32:09
> Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il 
> vraiment autant de bugs que ça dans les implémentations SIP ?!)
> 
>> Merci pour ce diag. :)
> 
> On est tous arrivé au même.
> 
>> Quand la colère va me prendre, 
> 
> Ou la lassitude...
> 
>> je vais monter un VPN OpenVPN tout neuf sur lequel je serai sûr que y'a pas 
>> d'ACL ni rien et hop hop >hop. Pas envie de démerder un Cisco ASA.
> 
> La VOIP en SIP/RTP, ça marche. Mais dans ta config (et beaucoup 
> d'autres), c'est avec un VPN qu'on fait de la VOIP en mode KISS qui 
> tombe en marche à tous les coups.
> 
> Parce qu'à la base c'est aussi foireux qu'un FTP passif (comme déjà dit 
> par un colistier). C'est ainsi. Et au moins, on est désormais dans une 
> techno unique. Du temps de l'ISDN y'avait aussi des trucs pourris.
> 
> -- 
> Stéphane Rivière
> Ile d'Oléron - France
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "Denis Fondras" 

pfctl -d désactive PF donc... les règles de NAT.

J'ai été trop vite… J'ai mélangé présentation du bidule et état actuel.
Donc, au début, et jusqu'à la fin de mon premier test hier soir, PF était 
activé (+ règle "tout autoriser"), il y avait du NAT. Après mon test, j'ai viré 
la règle de NAT puis je me suis dit autant faire pfctl -d. Donc depuis hier 
soir jusqu'à maintenant, PF est désactivé, donc absence de NAT et de filtrage.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Denis Fondras]

On Wed, Mar 18, 2020 at 12:57:09PM +0100, Guillaume LUCAS wrote:
> Lui fait du NAT. Il a aucune règle de filtrage et j'ai pfctl -d. 
> 

pfctl -d désactive PF donc... les règles de NAT.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

Je me suis souvenu que j'avais un PFSense de test dans un coin avec un OpenVPN 
déjà tout prêt.
Lui fait du NAT. Il a aucune règle de filtrage et j'ai pfctl -d. Utilisation de 
TUN + un même réseau pour tous les clients. Aucun pare-feu sur les clients. 

Premier test : je monte ce VPN OpenVPN, je démarre Linphone, il m'enregistre 
sur le PABX : ip src = IP du PFSense (donc NAT). Je tél à la chambre de 
conférence. Je n'ai pas de son. Environ normal sauf que STUN aurait du faire le 
job puisque l'IP retournée par le serveur STUN était bien l'IP de NAT. Donc 
STUN fail. Sur mon compte SIP, je mets nat=yes. Restart Linphone. Ça fonctionne.
=> conclusion : nat=yes produit bien un effet quand y'a du NAT. J'en doutais 
pas, mais j'étais surpris que ça ne fonctionne pas hier.

Deuxième test : je vire le NAT du PFSense. Je teste avec mtr, netcat, etc. que 
j'peux faire du client<->client. Je vire nat=yes. Appel entre collègues avec 
Linphone 4.1.1. Ça marche. Pas de bug des 30 secondes. Mais, avec cet 
interlocuteur, ça a souvent fonctionné, donc ça veut rien dire. 

Troisième test : Même que deuxième test, mais avec Linphone 3.11 d'un côté. On 
s'entend, mais coupure auto après 36 secondes (et plus 31/32 :D).
=> conclusion : le VPN ASA est pas le seul fautif, on dirait.

J'ai analysé les captures réseau des 3 tests et le journal Asterisk.
  * Quand ça fonctionne avec Linphone 4.1.1 des deux côtés, l'Asterisk est en 
relais RTP.
  * Dans le journal Asterisk, je vois un « Strict RTP learning complete » pour 
mon collègue et pour moi.

  * Quand ça fonctionne durant 30 secs avec Linphone 4.1.1 d'un côté et 3.11 de 
l'autre, Asterisk n'est pas en relais RTP.
  * Dans le journal Asterisk, je vois un aucun « Strict RTP learning complete » 
pour qui que ce soit. Il y a bien les « Strict RTP learning after remote 
address set to », mais ça s'arrête là.

  * Quand un seul interlocuteur entend l'autre avec Linphone 3.11 (car je 
triche), je vois un flux RTP envoyé à Asterisk, l'autre envoyé en direct. Je 
vois un « Strict RTP learrning complete » pour moi, et que du « Strict RTP 
learning after remote address set to » avec l'IP de VPN du collègue, mais pas 
de « Complete ». Donc je n'entends pas le collègue et son flux RTP arrive en 
direct, sans passer par Asterisk et se fait probablement jeter par un contrôle 
d'intégrité de Linphone.


J'en déduis qu'il est difficile d'accuser l'ASA. 

On dirait qu'il y a un fail de RTP autolearn avec Linphone 3.11, tout le reste 
étant identique par ailleurs. Pourquoi ?

Je vais faire tester le VPN OpenVPN garanti sans NAT ni filtrage à plus de 
collègues.


- Mail original -
De: "Stéphane Rivière" 
À: "frnog" 
Envoyé: Mardi 17 Mars 2020 20:32:09
Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment 
autant de bugs que ça dans les implémentations SIP ?!)

> Merci pour ce diag. :)

On est tous arrivé au même.

> Quand la colère va me prendre, 

Ou la lassitude...

>je vais monter un VPN OpenVPN tout neuf sur lequel je serai sûr que y'a pas 
>d'ACL ni rien et hop hop >hop. Pas envie de démerder un Cisco ASA.

La VOIP en SIP/RTP, ça marche. Mais dans ta config (et beaucoup 
d'autres), c'est avec un VPN qu'on fait de la VOIP en mode KISS qui 
tombe en marche à tous les coups.

Parce qu'à la base c'est aussi foireux qu'un FTP passif (comme déjà dit 
par un colistier). C'est ainsi. Et au moins, on est désormais dans une 
techno unique. Du temps de l'ISDN y'avait aussi des trucs pourris.

-- 
Stéphane Rivière
Ile d'Oléron - France


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


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "Michel Py" 

> Je comprends que tu veux rester sur le softphone, mais çà vaudrait peut-être 
> le coup de dépenser 50 balles pour essayer un téléphone de bureau qui a 
> support de VPN. Je promets pas que çà marcherait mieux (j'ai jamais essayé), 
> mais les Grandstream ont une option OpenVPN.

C'est un point qui revient souvent alors je vais répondre.

1) Je ne pense pas qu'on ait les épaules assez solides pour gérer de la 
diffusion de SNOM. En termes d'inventaire, de suivi, etc.
2) Nous distribuons des 06 à nos VIP (c'est-à-dire des gens reponsables 
comme on nous le vend à longueur de journée). Nous constatons une corrélation 
entre chaque date de sortie du nouvel iPhone/Samsung et un taux de casse plus 
élevé des écrans des 06 déjà en circulation. Corrélation ne fait pas causalité, 
bien entendu. Peut-être que l'excitation procurée par la sortie d'un tel joujou 
rend les mains moites. Mais c'est fâcheux.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Daniel via frnog]

Le 17/03/2020 à 22:04, Michel Py a écrit :

[...]

C'est ça. Et ceux essayés (Jitsi, Linphone, Blink, Zoiper) échouent sur le 
choix de
l'IP, soit tout le temps, soit par moments. D'où mon usage de STUN.

Maintenant je comprends. Je ne me doutais pas que les clients softphone avaient 
ce genre de limitation; c'est bizarre que personne n'ait pensé a çà avant.

Je comprends que tu veux rester sur le softphone, mais çà vaudrait peut-être le 
coup de dépenser 50 balles pour essayer un téléphone de bureau qui a support de 
VPN. Je promets pas que çà marcherait mieux (j'ai jamais essayé), mais les 
Grandstream ont une option OpenVPN.


Les SNOM également et avec ces deux fabricants je n'ai *jamais* eu de 
problème en utilisant leur VPN. Ceci dit avec les Softphones non plus ...


Ce que je ferais:

. tester avec csipsimple qui est très stable

. passer en IAX avec Zoiper. IAX c'est bien ;)

PS: mon dialplan qui sauve mes journées:
...
same = n,Dial(PJSIP/xxx@mytrunk,,)
same = n,ExecIf($["${DIALSTATUS}" = "CHANUNAVAIL" | "${DIALSTATUS}" = 
"CONGESTION"]?Dial(IAX2/mytrunk/xxx,,))

...

--
Daniel Huhardeaux
+33.368460...@tootai.net  sip:8...@sip.tootai.net
+41.445532...@swiss-itech.chtootaiNET


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

RE: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Michel Py]

> Guillaume LUCAS a écrit :
> Perso, je ne veux pas qu'Asterisk soit relais RTP, car il
> faut dimensionner le serveur pour la montée en chargée

C'est ce que je fais avec 500 utilisateurs, avec une bécane pas trop pourrie 
aucun problème.
Je me rappelle plus trop l'option, mais j'ai choisi de garder Asterisk entre 
les postes. Un flux audio, même HD, c'est pas grand-chose ces jours-ci.

>> Il faut donc que ton softphone soit assez intelligent pour comprendre qu'il 
>> est lié
>> à l'interface VPN et qu'il prenne l'adresse dynamique que le serveur VPN lui 
>> envoie.

> C'est ça. Et ceux essayés (Jitsi, Linphone, Blink, Zoiper) échouent sur le 
> choix de
> l'IP, soit tout le temps, soit par moments. D'où mon usage de STUN.

Maintenant je comprends. Je ne me doutais pas que les clients softphone avaient 
ce genre de limitation; c'est bizarre que personne n'ait pensé a çà avant.

Je comprends que tu veux rester sur le softphone, mais çà vaudrait peut-être le 
coup de dépenser 50 balles pour essayer un téléphone de bureau qui a support de 
VPN. Je promets pas que çà marcherait mieux (j'ai jamais essayé), mais les 
Grandstream ont une option OpenVPN.

Michel.



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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Raphael Mazelier]

Cela me ramène quelque année en arrière. Et cela me rappelle aussi 
pourquoi on posait des box chez les clients.  (coucou les ex-B3G, 
Ipnotic, Paritel)


Faire de la Voip si tu ne maîtrise pas le lan client c'est possible mais 
source d'emmerdements infinis.


Comme déjà mentionné il faut absolument que ton RTP soit in path de ton 
asterisk (rtp proxy , whatever).


Au final je me demande si tu ne t’embête pas plus avec un vpn que sans. 
(alors surtout un ASA qui si tu n'y prend pas garde va joyeusement faire 
n'importe quoi avec tes paquets SIP, a se demander d'ailleurs pourquoi 
on a crée des ALGs SIP pour qu'au final la 1ere chose à faire c'est de 
les désactiver).


En public ICE/STUN/TURN peuvent définitivement aider. Après si pour X 
raison tu es obligé d'utiliser un VPN, bin bon courage. Wireshark va 
être ton ami proche des prochains jours.


Good luck.

--

Raphael Mazelier

On 17/03/2020 18:43, Guillaume LUCAS wrote:

- Mail original -
De: "frnog" 
Réussis tu à pinguer l'IP en 192.168.x.y à partir du PABX ?

Non. Et surtout, je ne veux pas ping les réseaux domestiques de mes usagers. Ce 
n'est pas mon rôle d'utiliser notre VPN pour accéder à leur réseau local.


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



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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

Ouki, merci.

Du coup, je retiens :
  * nat=yes n'a pas fonctionné, c'est très bizarre, donc sortir tcpdump ;
  * session-timers=refuse n'a pas fonctionné, c'est bizarre, preuve 
supplémentaire d'un filtrage ;
  * monter un autre VPN vite-fait ;
  * désactiver RTP learning pour voir. J'ai déjà vu un interlocuteur envoyer 
son RTP à Asterisk et pas l'autre, du coup, ça ne fonctionnait pas.


- Mail original -
De: "David Ponzone" 
À: "Guillaume LUCAS" 
Cc: "frnog" 
Envoyé: Mardi 17 Mars 2020 20:55:48
Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment 
autant de bugs que ça dans les implémentations SIP ?!)

Faut fouiner, je connais pas assez Asterisk et encore moins les versions 
récentes. Et côté doc, c’est comment dire….

> Le 17 mars 2020 à 20:53, Guillaume LUCAS  a 
> écrit :
> 
>> - Mail original -
>> De: "David Ponzone" 
> 
>>> Qu'est-ce qui peut expliquer les échecs de l'autolearn ?
> 
>> Que l’IP que présente le softphone est une IP que Asterisk a dans son 
>> localnet.
> 
> Mon localnet est vide. Si tu m'avais dit « Que l’IP que présente le softphone 
> N'EST PAS une IP que Asterisk a dans son localnet. », ça expliquait ce 
> scénario que j'ai pas compris.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[David Ponzone]

Faut fouiner, je connais pas assez Asterisk et encore moins les versions 
récentes. Et côté doc, c’est comment dire….

> Le 17 mars 2020 à 20:53, Guillaume LUCAS  a 
> écrit :
> 
>> - Mail original -
>> De: "David Ponzone" 
> 
>>> Qu'est-ce qui peut expliquer les échecs de l'autolearn ?
> 
>> Que l’IP que présente le softphone est une IP que Asterisk a dans son 
>> localnet.
> 
> Mon localnet est vide. Si tu m'avais dit « Que l’IP que présente le softphone 
> N'EST PAS une IP que Asterisk a dans son localnet. », ça expliquait ce 
> scénario que j'ai pas compris.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "David Ponzone" 

> > Qu'est-ce qui peut expliquer les échecs de l'autolearn ?

> Que l’IP que présente le softphone est une IP que Asterisk a dans son 
> localnet.

Mon localnet est vide. Si tu m'avais dit « Que l’IP que présente le softphone 
N'EST PAS une IP que Asterisk a dans son localnet. », ça expliquait ce scénario 
que j'ai pas compris.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[David Ponzone]

> Le 17 mars 2020 à 20:46, Guillaume LUCAS  a 
> écrit :
> 
> - Mail original -
> De: "David Ponzone" 
> 
>> Ah non, en autolearn, il est forcément dans le path RTP.
> 
> Attends, attends, attends.
> 
> Il se passe quoi quand l'autolearn marche que pour l'un des deux 
> interlocuteurs ? Ça donnerait pas une conversation où un seule interlocuteur 
> entend l'autre, par hasard ?

C’est pas gênant: autolean pour un des 2, pas pour l’autre, mais relais RTP 
forcément.

> Genre là, dans le journal, je vois un Strict learning complete pour un 
> interlocuteur sur les deux (on va le nommer Toto). Pour l'autre interlocuteur 
> (Titi), le learning voit qu'une IP 192.168.0.X… . Et ça correspond pile à un 
> essai où l'un des deux ne s'entendait pas. Juste après, Toto m'a téléphoné. À 
> nouveau, il a eu un Strict learning complete et moi aussi, donc on pouvait 
> converser… 
> 
> Qu'est-ce qui peut expliquer les échecs de l'autolearn ?

Que l’IP que présente le softphone est une IP que Asterisk a dans son localnet.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

- Mail original -
De: "David Ponzone" 

> Ah non, en autolearn, il est forcément dans le path RTP.

Attends, attends, attends.

Il se passe quoi quand l'autolearn marche que pour l'un des deux interlocuteurs 
? Ça donnerait pas une conversation où un seule interlocuteur entend l'autre, 
par hasard ?
Genre là, dans le journal, je vois un Strict learning complete pour un 
interlocuteur sur les deux (on va le nommer Toto). Pour l'autre interlocuteur 
(Titi), le learning voit qu'une IP 192.168.0.X… . Et ça correspond pile à un 
essai où l'un des deux ne s'entendait pas. Juste après, Toto m'a téléphoné. À 
nouveau, il a eu un Strict learning complete et moi aussi, donc on pouvait 
converser… 

Qu'est-ce qui peut expliquer les échecs de l'autolearn ?


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[David Ponzone]

> Le 17 mars 2020 à 20:31, Guillaume LUCAS  a 
> écrit :
> 
>> - Mail original -
>> De: "David Ponzone" 
> 
>> Ah non, en autolearn, il est forcément dans le path RTP.
> 
> Moi je parle de ça dans le journal :
> « Strict RTP learning after remote address set to: 10.30.1.4:7078
> Strict RTP learning complete - Locking on source address 10.30.1.4:7078 »
> 
> À ce moment-là, il me semble que les flux RTP étaient directs.

Non non.
Enfin j’ai jamais vu faire. Ca serait compliqué, faudrait renvoyer des SIP 
UPDATE aux 2 endpoints, mais si tu changes le SDP en cours d’appel, il est 
possible, probable même, voir certain, que le port va changer à cause du NAT 
devant le endpoint, donc c’est mort.
L’autolearn repose sur le fait d’apprendre le vrai couple IP/PORT du flux, qui 
ne changera plus tant que l’appel dure, pareil pour l’autre endpoint, et tu 
fais le relais entre les 2.

> 
> Comment puis-je activer/désactiver l'autolearn ? Juste pour voir la diff'…
> 

Je sais pas, j’ai abandonné Asterisk pour FreeSWITCH, il y a longtemps.

> 
>> Mais du relais RTP sans transcoding, ça prend que dalle.
>> T’as beaucoup de monde comme ça ?
> 
> Si on généralisait le télétravail au max du max (ce qui n'arrivera pas 
> puisqu'on a un écrit officiel nous informant qu'il n'y aura pas de perte de 
> rémunération si refus du télétravail, donc autant rien faire), on aurait 800 
> personnes.


800 personnes, c’est max 120-150 appels simultanés si c’est un usage entreprise 
standard, ça tient sur 4 coeurs.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Stéphane Rivière]

Merci pour ce diag. :)


On est tous arrivé au même.

Quand la colère va me prendre, 


Ou la lassitude...


je vais monter un VPN OpenVPN tout neuf sur lequel je serai sûr que y'a pas d'ACL 
ni rien et hop hop >hop. Pas envie de démerder un Cisco ASA.


La VOIP en SIP/RTP, ça marche. Mais dans ta config (et beaucoup 
d'autres), c'est avec un VPN qu'on fait de la VOIP en mode KISS qui 
tombe en marche à tous les coups.


Parce qu'à la base c'est aussi foireux qu'un FTP passif (comme déjà dit 
par un colistier). C'est ainsi. Et au moins, on est désormais dans une 
techno unique. Du temps de l'ISDN y'avait aussi des trucs pourris.


--
Stéphane Rivière
Ile d'Oléron - France


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "David Ponzone" 

> Ah non, en autolearn, il est forcément dans le path RTP.

Moi je parle de ça dans le journal :
« Strict RTP learning after remote address set to: 10.30.1.4:7078
Strict RTP learning complete - Locking on source address 10.30.1.4:7078 »

À ce moment-là, il me semble que les flux RTP étaient directs.

Comment puis-je activer/désactiver l'autolearn ? Juste pour voir la diff'…


> Mais du relais RTP sans transcoding, ça prend que dalle.
> T’as beaucoup de monde comme ça ?

Si on généralisait le télétravail au max du max (ce qui n'arrivera pas 
puisqu'on a un écrit officiel nous informant qu'il n'y aura pas de perte de 
rémunération si refus du télétravail, donc autant rien faire), on aurait 800 
personnes.


J'aimerais bien l'avis de la liste : un TURN résoudrait à coup sûr mon 
problème, mais, c'est crade, non ? :(


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "Michel Py" 

> Installer une route vers le réseau local c'est pas une solution, car tu vas 
> de retrouver avec une ribambelle de 192.168.0.0.

Et il faut ajouter ces routes chez tous les clients VPN, et donc avoir des 
collisions (genre si on dit à un usager avec une connexion Numericable 
d'envoyer 192.168.0.0/24 dans le VPN, vlam).


> Il faut donc que ton softphone soit assez intelligent pour comprendre qu'il 
> est lié à l'interface VPN et qu'il prenne l'adresse dynamique que le serveur 
> VPN lui envoie.

C'est ça. Et ceux essayés (Jitsi, Linphone, Blink, Zoiper) échouent  sur le 
choix de l'IP, soit tout le temps, soit par moments. D'où mon usage de STUN.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[David Ponzone]

> Le 17 mars 2020 à 20:17, Guillaume LUCAS  a 
> écrit :
> 
>> - Mail original -
>> De: "David Ponzone" 
> 
>> Moi ce que je pige pas, c’est qu’en RTP autolearn, ça devrait marcher dans 
>> tous les cas, Asterisk apprenant tout seul l’IP:PORT de chaque flux RTP, et 
>> faisant le relais RTP.
> 
> Idem. Dans le journal d'Asterisk, je vois bien qu'il autolearn et tout, mais 
> ça marche pas.
> De même, l'activation infructueuse de nat=yes me laisse très dubitatif. Si 
> Asterisk réécrit les SDP, ça devrait fonctionner, sauf si les softphones sont 
> bind() uniquement sur l'IP RFC1918 locale (non VPN). Je vais revenir sur ça 
> demain.
> 
> Quand tu parles de relais RTP, tu veux parler de relais SDP, non ?
> Perso, je ne veux pas qu'Asterisk soit relais RTP, car il faut dimensionner 
> le serveur pour la montée en chargée.
> C'est aussi pour ça que je n'ai pas installé de serveur TURN, qui serait une 
> solution vite-fait-bien-fait à mon problème.
> 

Ah non, en autolearn, il est forcément dans le path RTP.
Mais du relais RTP sans transcoding, ça prend que dalle.
T’as beaucoup de monde comme ça ?


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "David Ponzone" 

> Moi ce que je pige pas, c’est qu’en RTP autolearn, ça devrait marcher dans 
> tous les cas, Asterisk apprenant tout seul l’IP:PORT de chaque flux RTP, et 
> faisant le relais RTP.

Idem. Dans le journal d'Asterisk, je vois bien qu'il autolearn et tout, mais ça 
marche pas.
De même, l'activation infructueuse de nat=yes me laisse très dubitatif. Si 
Asterisk réécrit les SDP, ça devrait fonctionner, sauf si les softphones sont 
bind() uniquement sur l'IP RFC1918 locale (non VPN). Je vais revenir sur ça 
demain.

Quand tu parles de relais RTP, tu veux parler de relais SDP, non ?
Perso, je ne veux pas qu'Asterisk soit relais RTP, car il faut dimensionner le 
serveur pour la montée en chargée.
C'est aussi pour ça que je n'ai pas installé de serveur TURN, qui serait une 
solution vite-fait-bien-fait à mon problème.


> Je pense qu’il faut explorer cette piste, en prenant des traces côté Asterisk 
> si nécessaire, et comprendre ce qui merde.

Je n'ai pas de capture réseau des essais avec nat=yes, et oui, c'est 
problématique.


> Ca permettrait au moins d’incriminer l’ASA une fois pour toute.

Ben ça, j'ai du wireshark sur les clients et du tcpdump sur l'Asterisk donc 
j'vois bien que la SDP part avec une IP "invalide" d'un softphone, qu'Asterisk 
la relaie et que le client la reçoit. Et inversement, quand ça marche, je vois 
des SDP avec la "bonne" IP. Ces captures datent d'avant l'activation de nat=yes 
sur quelques comptes SIP, bien entendu.

Ce qui m'étonne le plus, c'est le softphone qui utilise STUN, puis en fait non, 
puis qui ne tient plus compte de la réponse STUN pour forger sa SDP, puis si, 
puis non, puis après il ne tient pas compte d'une SDP valide reçue donc il 
envoie le flux audio au mauvais endroit, puis ça marche, puis retour case 
départ…


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

RE: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Michel Py]

> Guillaume LUCAS a écrit :
> Ça dit que à chaque fois que j'ai vu de la VOIP ne pas fonctionner, c'était 
> toujours
> parce que les softphones ne mettaient pas leur "bonne" IP dans le message 
> SIP/SDP,
> forcément que le softphone d'en face ne pourra pas leur envoyer de RTP. Genre 
> "viens
> me causer sur 127.0.0.1" ça va pas marcher. "Viens me causer sur 
> 192.168.0.14" non
> plus. Je dis la même chose que toi quand tu écris « problème de binding ».

J'avais pas percuté avant, mais en effet c'est probablement un de tes 
problèmes. Dans ton softphone, il faut que tu puisses choisir l'interface VPN 
et que le softphone comprenne que c'est celle à utiliser. Installer une route 
vers le réseau local c'est pas une solution, car tu vas de retrouver avec une 
ribambelle de 192.168.0.0.

>> Réussis tu à pinguer l'IP en 192.168.x.y à partir du PABX ?
> Non, mais je ne veux pas faire ça. Sinon faut que je route 192.168.0.0/24 
> pour NC-SFR,
> 192.168.1.0/24 pour un autre FAI, 192.168.42.0/24 pour le geek, 172.16 pour 
> MacDo, etc.
> etc. On ne s'en sort plus. Je ne vais pas définir tous les réseaux privés que 
> chacun
> peut avoir chez soi ou au cybercafé dans mes localnets, si ? 

Non, ton analyse est bonne.

> Pour moi le softphone doit prendre l'IP qu'il a dans notre VPN, pas l'IP 
> qu'il a à sa maison.

Correct, contrairement à ce que j'ai écrit plus tot.

Il faut donc que ton softphone soit assez intelligent pour comprendre qu'il est 
lié à l'interface VPN et qu'il prenne l'adresse dynamique que le serveur VPN 
lui envoie.

A part çà, changer de système de VPN çà serait à essayer, si ce n'est que pour 
savoir ou ton problème est.

Michel.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[David Ponzone]

Moi ce que je pige pas, c’est qu’en RTP autolearn, ça devrait marcher dans tous 
les cas, Asterisk apprenant tout seul l’IP:PORT de chaque flux RTP, et faisant 
le relais RTP.
Je pense qu’il faut explorer cette piste, en prenant des traces côté Asterisk 
si nécessaire, et comprendre ce qui merde.
Ca permettrait au moins d’incriminer l’ASA une fois pour toute.

> Le 17 mars 2020 à 19:26, Guillaume LUCAS  a 
> écrit :
> 
>> - Mail original -
>> De: "Thierry Chich" 
> 
> 
>> Le problème vient peut-être du VPN. Peut-être que 2 IP attribuée par le VPN 
>> ne se voient pas entre elles, ou partiellement ? On vient d’avoir le coup 
>> avec du jitsi. Le p2p, c’est bien joli, mais bon.
> 
> À mon avis, une partie du problème est dans le mot « partiellement », en 
> effet.
> Quand ça fonctionne, les flux RTP circulent bien d'IP attribuée par le VPN à 
> IP attribuée par le VPN ;
> ping entre deux clients VPN OK ;
> http entre deux clients VPN OK ;
> netcat udp entre deux clients VPN OK.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "Thierry Chich" 


> Le problème vient peut-être du VPN. Peut-être que 2 IP attribuée par le VPN 
> ne se voient pas entre elles, ou partiellement ? On vient d’avoir le coup 
> avec du jitsi. Le p2p, c’est bien joli, mais bon.

À mon avis, une partie du problème est dans le mot « partiellement », en effet.
 Quand ça fonctionne, les flux RTP circulent bien d'IP attribuée par le VPN à 
IP attribuée par le VPN ;
 ping entre deux clients VPN OK ;
 http entre deux clients VPN OK ;
 netcat udp entre deux clients VPN OK.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "frnog" 

> Définitivement pour moi problème de NAT ou Pare-Feu

Merci pour ce diag. :)
Quand la colère va me prendre, je vais monter un VPN OpenVPN tout neuf sur 
lequel je serai sûr que y'a pas d'ACL ni rien et hop hop hop. Pas envie de 
démerder un Cisco ASA.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "frnog" 

> J'avais bien compris que tu ne veux pas le faire, tu comprends donc que 
> ton rtp se perd si le client envois une IP injoignable au PABX

Tout à fait, je comprends.
Je corrige un truc : le client envoie, en SDP, une IP injoignable au PABX, mais 
aussi à son interlocuteur.
Donc en fait, tous nos clients VPN devraient avoir une route pour (dans 
l'exemple que je prends depuis le début) 192.168.0.24, ce qui va forcément 
faire collision avec des réseaux domestiques qui utilisent cette plage. D'où 
l'ajout de routes n'est pas une bonne idée, c'est au softphone de sélectionner 
la bonne IP pour la filer en SDP, avec ICE, STUN, autre…

Ce qui me dépasse, c'est quand le softphone fait des requêtes STUN, mets bien 
son IP VPN dans SDP (donc l'appel fonctionne) puis, des heures plus tard, sans 
aucun changement de conf' ni redémarrage du softphone ni… cesse de faire du 
STUN ou émet des requêtes STUN, reçoit la réponse, mais n'intègre pas l'IP dans 
SDP… ou autre… Si y'avait pas ça, la solution STUN, bien que crade, 
fonctionnerait.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "frnog" 

> Réussis tu à pinguer l'IP en 192.168.x.y à partir du PABX ?

Non. Et surtout, je ne veux pas ping les réseaux domestiques de mes usagers. Ce 
n'est pas mon rôle d'utiliser notre VPN pour accéder à leur réseau local.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "David Ponzone" 

> Tu veux pas modifier la nat.address dans le fichier de conf de linphone (voir 
> le lien que j’ai envoyé il y a quelques minutes), pour voir si ça aide 
> linphone à envoyer un SDP correct ?

J'essaye de dépiler mes mails dans l'ordre.

Alors ça, c'est la première chose que j'ai testé vendredi. Avant STUN, ICE et 
compagnie. Et ça marchait. Il restait le problème de "ça raccroche auto après 
30 secs" mais au moins les flux RTP montaient. J'ai pas testé aussi longuement 
que ICE et STUN, donc si ça se trouve, ça marche pas sur le long terme, comme 
STUN.

Pourquoi j'ai pas gardé ? Parce que l'adressage IP de notre VPN est dynamique. 
Pas statique. Pas d'IP préférée. Rien, du pur dynamique. J'ai oublié de le dire 
ici.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[David Ponzone]

Tu veux pas modifier la nat.address dans le fichier de conf de linphone (voir 
le lien que j’ai envoyé il y a quelques minutes), pour voir si ça aide linphone 
à envoyer un SDP correct ?

> Le 17 mars 2020 à 18:29, Guillaume LUCAS  a 
> écrit :
> 
>> - Mail original -
>> De: "frnog" 
> 
> Le 17/03/2020 à 13:32, Guillaume LUCAS a écrit :
>> Et cela te parait normal? Il y a déjà un problème au départ, Linphone ou 
>> autre.
> 
> Ben, comme j'ai vu ça en cours et en pratique, je me dis implémentation 
> foireuse et comme ça me semble quand même trop gros, j'viens demander ici si 
> c'est normal.
> En vrai, ça me semble aberrant… Mais comme j'ai déjà vu ces 10 dernières 
> années de la part de plusieurs softphones…
> 
> 
> 
>> Une solution serait de mettre le réseau 192.168.0/24 dans localnet et de 
>> faire une route sur le PABX qui enverrait le trafic vers l'interface VPN. 
>> C'est du bricolage
> 
> Oui et non. Je ne sais pas comment marche un Cisco ASA, mais, avec OpenVPN, 
> si tu routes, vers un client, une IP/réseau que tu n'as pas défini dans la 
> conf' OpenVPN (iroute, etc.), le trafic arrivera pas au client. Donc, si je 
> faisais ça, faudrait vérifier ça.
> 
> Et oui, ça serait du bricolage… Mais ça fonctionnerait très probablement…
> 
> 
> 
>> Comme dit par d'autres STUN ou ICE ne devriaent pas être nécessaires
> 
> Ce qui pré-suppose que le softphone sélectionne la "bonne IP" pour la mettre 
> dans SDP. Linphone, Jitsi, Zoiper, Blink, tous échouent par moments (Jitsi) 
> ou tout le temps sans STUN (Linphone) ou tout le temps même avec STUN 
> (Zoiper).
> 
> 
> 
>> As tu fais les modifs au niveau localnet ?
> 
> Nope, du coup.
> 
> 
> 
>> Soit tu as 2 problèmes, Pare-Feu et Softphone
> 
> Vrai…
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Thierry Chich]

Le problème vient peut-être du VPN. Peut-être que 2 IP attribuée par le VPN ne 
se voient pas entre elles, ou partiellement ? On vient d’avoir le coup avec du 
jitsi. Le p2p, c’est bien joli, mais bon.

Thierry Chich

> Le 17 mars 2020 à 18:19, Guillaume LUCAS  a 
> écrit :
> 
> - Mail original -
> De: "frnog" 
> 
>> Donc session timeout: Essaye en mettant session-timers=refuse dans la  
>> config d'un client qui génère cette erreur
> 
> J'ai fait. Reload Asterisk. Restart tous les softphones impliqués. Essai. Ça 
> ne fonctionne pas, ça coupe toujours après 32 secs.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "frnog" 

Le 17/03/2020 à 13:32, Guillaume LUCAS a écrit :
> Et cela te parait normal? Il y a déjà un problème au départ, Linphone ou 
> autre.

Ben, comme j'ai vu ça en cours et en pratique, je me dis implémentation 
foireuse et comme ça me semble quand même trop gros, j'viens demander ici si 
c'est normal.
En vrai, ça me semble aberrant… Mais comme j'ai déjà vu ces 10 dernières années 
de la part de plusieurs softphones…



> Une solution serait de mettre le réseau 192.168.0/24 dans localnet et de 
> faire une route sur le PABX qui enverrait le trafic vers l'interface VPN. 
> C'est du bricolage

Oui et non. Je ne sais pas comment marche un Cisco ASA, mais, avec OpenVPN, si 
tu routes, vers un client, une IP/réseau que tu n'as pas défini dans la conf' 
OpenVPN (iroute, etc.), le trafic arrivera pas au client. Donc, si je faisais 
ça, faudrait vérifier ça.

Et oui, ça serait du bricolage… Mais ça fonctionnerait très probablement…



> Comme dit par d'autres STUN ou ICE ne devriaent pas être nécessaires

Ce qui pré-suppose que le softphone sélectionne la "bonne IP" pour la mettre 
dans SDP. Linphone, Jitsi, Zoiper, Blink, tous échouent par moments (Jitsi) ou 
tout le temps sans STUN (Linphone) ou tout le temps même avec STUN (Zoiper).



> As tu fais les modifs au niveau localnet ?

Nope, du coup.



> Soit tu as 2 problèmes, Pare-Feu et Softphone

Vrai…


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Daniel via frnog]

Le 17/03/2020 à 18:18, Guillaume LUCAS a écrit :

- Mail original -
De: "frnog" 


Donc session timeout: Essaye en mettant session-timers=refuse dans la  config 
d'un client qui génère cette erreur

J'ai fait. Reload Asterisk. Restart tous les softphones impliqués. Essai. Ça ne 
fonctionne pas, ça coupe toujours après 32 secs.

Définitivement pour moi problème de NAT ou Pare-Feu

--
Daniel Huhardeaux
+33.368460...@tootai.net  sip:8...@sip.tootai.net
+41.445532...@swiss-itech.chtootaiNET


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

- Mail original -
De: "frnog" 

> Donc session timeout: Essaye en mettant session-timers=refuse dans la  config 
> d'un client qui génère cette erreur

J'ai fait. Reload Asterisk. Restart tous les softphones impliqués. Essai. Ça ne 
fonctionne pas, ça coupe toujours après 32 secs.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[David Ponzone]

Un autre article qui parle de ça, et qui donne le bon paramètre pour le 
linphonerc, utilisable évidemment seulement si le VPN attribue une IP fixe:

https://linphone-users.nongnu.narkive.com/g4m2kB9q/how-to-tell-linphone-which-ip-address-to-use
 


> Le 17 mars 2020 à 17:43, Daniel via frnog  a écrit :
> 
> 
> Le 17/03/2020 à 15:05, Guillaume LUCAS a écrit :
>> 
>> [...]
>>> Réussis tu à pinguer l'IP en 192.168.x.y à partir du PABX ?
>> Non, mais je ne veux pas faire ça. Sinon faut que je route 192.168.0.0/24 
>> pour NC-SFR, 192.168.1.0/24 pour un autre FAI, 192.168.42.0/24 pour le geek, 
>> 172.16 pour MacDo, etc. etc. On ne s'en sort plus. Je ne vais pas définir 
>> tous les réseaux privés que chacun peut avoir chez soi ou au cybercafé dans 
>> mes localnets, si ? Pour moi le softphone doit prendre l'IP qu'il a dans 
>> notre VPN, pas l'IP qu'il a à sa maison.
> J'avais bien compris que tu ne veux pas le faire, tu comprends donc que ton 
> rtp se perd si le client envois une IP injoignable au PABX
> 
> [...]
> 
> -- 
> Daniel Huhardeaux
> +33.368460...@tootai.netsip:8...@sip.tootai.net
> +41.445532...@swiss-itech.ch  tootaiNET
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Daniel via frnog]

Le 17/03/2020 à 15:05, Guillaume LUCAS a écrit :


[...]

Réussis tu à pinguer l'IP en 192.168.x.y à partir du PABX ?

Non, mais je ne veux pas faire ça. Sinon faut que je route 192.168.0.0/24 pour 
NC-SFR, 192.168.1.0/24 pour un autre FAI, 192.168.42.0/24 pour le geek, 172.16 
pour MacDo, etc. etc. On ne s'en sort plus. Je ne vais pas définir tous les 
réseaux privés que chacun peut avoir chez soi ou au cybercafé dans mes 
localnets, si ? Pour moi le softphone doit prendre l'IP qu'il a dans notre VPN, 
pas l'IP qu'il a à sa maison.
J'avais bien compris que tu ne veux pas le faire, tu comprends donc que 
ton rtp se perd si le client envois une IP injoignable au PABX


[...]

--
Daniel Huhardeaux
+33.368460...@tootai.net  sip:8...@sip.tootai.net
+41.445532...@swiss-itech.chtootaiNET


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Stéphane Rivière]

> Faire marcher SIP à travers NAT çà a toujours été une galère, mais au travers 
> d'un VPN je ne vois pas pourquoi çà ne marcherait pas.

+1

>> Nous n'avons pas de NAT. À mes yeux, le VPN est un réseau interne comme un 
>> autre.

+1

-- 
Be Seeing You
Number Six


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "David Ponzone" 

> Ok, un truc couillon: ça fait une différence si tu montes le VPN AVANT et 
> APRÈS de lancer Linphone ?

Alors, ça ne m'était pas venu à l'idée d'ouvrir Linphone avant de monter le 
VPN, pour moi c'était sûr qu'il ne faut pas faire ça. J'ai testé pour toi et, 
forcément, ça foire bien. Au début impossible d'être destinataire d'un appel, 
le PABX dit que le user n'est pas là. En laissant Linphone se rendre compte de 
la réalité (> 10 minutes), il s'enregistre à nouveau. Les appels ne 
fonctionnent pas (personne s'entend ou un des deux seulement et vu l'IP RFC1918 
hors VPN dans le message SDP… … …), même avec les personnes avec lesquelles 
cela fonctionnait juste avant et avec lesquels ça a fonctionné après avoir 
redémarré Linphone pour conclure le test.

Donc oui, il faut bien monter le VPN avant d'ouvrir Linphone.
Et ça pose un souci. En cas de coupure ADSL (ou autre), notre VPN va remonter 
auto. L'utilisateur changera d'IP. Linphone sera perdu. Je me vois mal demander 
à mes utilisateurs de redémarrer Linphone en permanence.


> Si c’est un problème de SDP, ça peut aider de dire à Asterisk que ces clients 
> là sont derrière du NAT, donc il va utiliser l’autoNAT (RTP auto learn) et ne 
> pas faire confiance au SDP.

A priori, c'est ce que j'ai testé en activant nat = « Oui (force rport + 
comedia) » dans XiVo + redémarrer les softphones puis tester, non ?



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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "frnog" 
> À: "frnog" 
> Envoyé: Mardi 17 Mars 2020 14:24:12
> Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il 
> vraiment autant de bugs que ça dans les implémentations SIP ?!)

> Tu pars du principe de ta configuration. Asterisk doit connaitre son  
> external IP qu'il met dans les entêtes SIP/RTP si l'IP du client n'est 
> pas définie dans ses localnet

Ben il a une seule IP, lui. Et elle est joignable depuis les VPN et depuis les 
SNOM. J'ai mtr, netcat, etc.



> Réussis tu à pinguer l'IP en 192.168.x.y à partir du PABX ?

Non, mais je ne veux pas faire ça. Sinon faut que je route 192.168.0.0/24 pour 
NC-SFR, 192.168.1.0/24 pour un autre FAI, 192.168.42.0/24 pour le geek, 172.16 
pour MacDo, etc. etc. On ne s'en sort plus. Je ne vais pas définir tous les 
réseaux privés que chacun peut avoir chez soi ou au cybercafé dans mes 
localnets, si ? Pour moi le softphone doit prendre l'IP qu'il a dans notre VPN, 
pas l'IP qu'il a à sa maison.



> Mets le sur tous les clients

D'acc.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Daniel via frnog]

Le 17/03/2020 à 14:08, Guillaume LUCAS a écrit :

- Mail original -
De: "frnog" 
À: "frnog" 
Envoyé: Mardi 17 Mars 2020 09:23:08
Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment 
autant de bugs que ça dans les implémentations SIP ?!)



Je pense que Linphone est à mettre en cause. Le problème n'est pas que
le routage, Asterisk doit savoir quelle IP mettre dans les entêtes SIP.

Peux-tu expliquer, stp ? Dans mes souvenirs. Un interlocuteur lance un appel. SIP 
INVITE vers le PABX qui transmet à l'interlocuteur (je passe trying/ringing, etc.). 
Si ça décroche, y'a échange des SDP en passant par le PABX. Au début, le PABX 
connecte chaque interlocuteur à lui (donc la connaissance de sa propre IP suffit 
pour dire "viens me causer sur cette IP+port avec tels codecs), puis il 
connecte les deux interlocuteurs directement en relayant simplement le SDP émis par 
chaque softphone. Dedans y'a l'IP+port et les codecs à utiliser. Pour moi Asterisk 
devient neutre à ce stade-là.


Tu pars du principe de ta configuration. Asterisk doit connaitre son 
external IP qu'il met dans les entêtes SIP/RTP si l'IP du client n'est 
pas définie dans ses localnet


https://www.voip-info.org/asterisk-sip-externip/


Dans l'interface Waxo/Xivo => Services => protocol SIP => Réseau il y a
une zone réseau local: le VPN en /16 doit y être défini

On a rien défini. Pas même le /16 RFC1918 qui héberge nos SNOM. Pas même le 
VLAN des passerelles T2.
Au niveau système, il y a une route par défaut, pas de routes vers les VLANs 
(VPN, SNOM, passerelles T2, etc.).

Réussis tu à pinguer l'IP en 192.168.x.y à partir du PABX ?

Donc session timeout: Essaye en mettant session-timers=refuse dans la  config 
d'un client qui génère cette erreur

D'acc. Mais… Comment j'identifie ce client ?

Mets le sur tous les clients

Comme dit, y'a trop de bruit, je n'arrive pas à corréler…
La modif' se fait côté Asterisk, on est d'accord ?

Oui

--
Daniel Huhardeaux
+33.368460...@tootai.net  sip:8...@sip.tootai.net
+41.445532...@swiss-itech.chtootaiNET


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[David Ponzone]

Ok, un truc couillon: ça fait une différence si tu montes le VPN AVANT et APRÈS 
de lancer Linphone ?

Si c’est un problème de SDP, ça peut aider de dire à Asterisk que ces clients 
là sont derrière du NAT, donc il va utiliser l’autoNAT (RTP auto learn) et ne 
pas faire confiance au SDP.


> Le 17 mars 2020 à 13:46, Guillaume LUCAS  a 
> écrit :
> 
> Ça dit que à chaque fois que j'ai vu de la VOIP ne pas fonctionner, c'était 
> toujours parce que les softphones ne mettaient pas leur "bonne" IP dans le 
> message SIP/SDP, forcément que le softphone d'en face ne pourra pas leur 
> envoyer de RTP. Genre "viens me causer sur 127.0.0.1" ça va pas marcher. 
> "Viens me causer sur 192.168.0.14" non plus. Je dis la même chose que toi 
> quand tu écris « problème de binding ».
> 
> 
> - Mail original -
> De: "David Ponzone" 
> À: "Guillaume LUCAS" 
> Cc: "frnog" 
> Envoyé: Mardi 17 Mars 2020 13:42:12
> Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il 
> vraiment autant de bugs que ça dans les implémentations SIP ?!)
> 
>> 
>> En même temps, de mes souvenirs de cours VOIP et de ma pratique précédente 
>> de la VOIP, c'est la banalité de dire que ce ne sont pas les bonnes adresses 
>> IP qui sont échangées dans SDP…
>> 
> 
> 
> Je ne comprends pas le sens de cette phrase (put…je vieillis) :)
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "frnog" 
> À: "frnog" 
> Envoyé: Mardi 17 Mars 2020 09:23:08
> Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il 
> vraiment autant de bugs que ça dans les implémentations SIP ?!)


> Je pense que Linphone est à mettre en cause. Le problème n'est pas que 
> le routage, Asterisk doit savoir quelle IP mettre dans les entêtes SIP.

Peux-tu expliquer, stp ? Dans mes souvenirs. Un interlocuteur lance un appel. 
SIP INVITE vers le PABX qui transmet à l'interlocuteur (je passe 
trying/ringing, etc.). Si ça décroche, y'a échange des SDP en passant par le 
PABX. Au début, le PABX connecte chaque interlocuteur à lui (donc la 
connaissance de sa propre IP suffit pour dire "viens me causer sur cette 
IP+port avec tels codecs), puis il connecte les deux interlocuteurs directement 
en relayant simplement le SDP émis par chaque softphone. Dedans y'a l'IP+port 
et les codecs à utiliser. Pour moi Asterisk devient neutre à ce stade-là.



> Dans l'interface Waxo/Xivo => Services => protocol SIP => Réseau il y a 
> une zone réseau local: le VPN en /16 doit y être défini

On a rien défini. Pas même le /16 RFC1918 qui héberge nos SNOM. Pas même le 
VLAN des passerelles T2.
Au niveau système, il y a une route par défaut, pas de routes vers les VLANs 
(VPN, SNOM, passerelles T2, etc.).



> Donc session timeout: Essaye en mettant session-timers=refuse dans la  config 
> d'un client qui génère cette erreur

D'acc. Mais… Comment j'identifie ce client ? Comme dit, y'a trop de bruit, je 
n'arrive pas à corréler…
La modif' se fait côté Asterisk, on est d'accord ?


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Daniel via frnog]

Le 17/03/2020 à 13:47, Daniel via frnog a écrit :

[..] Je donne les preuves suivantes :
   * Dans le journal de mon Asterisk, j'ai bien des « chan_sip.c: 
Registered SIP 'bczhcigi' at 10.30.1.175:62633 ». 10.30.X.X est bien 
une IP VPN. Je vois bien une IP 10.30/16 différente par softphone ;
   * Quand ils fonctionnent, les flux RTP circulent bien entre deux 
IP 10.30.x.x, et c'est bien les IPs attribuées, par le VPN, aux deux 
clients VPN ;
   * mtr depuis mon ordi+VPN vers un de nos serveurs : un seul saut, 
le serveur lui-même. mtr entre le serveur et mon ordi+VPN : un seul 
saut, mon IP VPN (10.30.1.175).
Ca c'est de l'IP, pas du SIP. Le routage IP est bon puisque les 
paquets partent et arrivent la ou ils doivent. Le problème est avec SIP

Correction, RDP

--
Daniel Huhardeaux
+33.368460...@tootai.net  sip:8...@sip.tootai.net
+41.445532...@swiss-itech.chtootaiNET


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

Ça dit que à chaque fois que j'ai vu de la VOIP ne pas fonctionner, c'était 
toujours parce que les softphones ne mettaient pas leur "bonne" IP dans le 
message SIP/SDP, forcément que le softphone d'en face ne pourra pas leur 
envoyer de RTP. Genre "viens me causer sur 127.0.0.1" ça va pas marcher. "Viens 
me causer sur 192.168.0.14" non plus. Je dis la même chose que toi quand tu 
écris « problème de binding ».


- Mail original -
De: "David Ponzone" 
À: "Guillaume LUCAS" 
Cc: "frnog" 
Envoyé: Mardi 17 Mars 2020 13:42:12
Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment 
autant de bugs que ça dans les implémentations SIP ?!)

> 
> En même temps, de mes souvenirs de cours VOIP et de ma pratique précédente de 
> la VOIP, c'est la banalité de dire que ce ne sont pas les bonnes adresses IP 
> qui sont échangées dans SDP…
> 


Je ne comprends pas le sens de cette phrase (put…je vieillis) :)

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


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[David Ponzone]

> 
> En même temps, de mes souvenirs de cours VOIP et de ma pratique précédente de 
> la VOIP, c'est la banalité de dire que ce ne sont pas les bonnes adresses IP 
> qui sont échangées dans SDP…
> 


Je ne comprends pas le sens de cette phrase (put…je vieillis) :)

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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "David Ponzone" 
> À: "Guillaume LUCAS" 
> Cc: "frnog" 
> Envoyé: Mardi 17 Mars 2020 07:34:53
> Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il 
> vraiment autant de bugs que ça dans les implémentations SIP ?!)

> Tu es visiblement pas le seul à avoir ce problème de binding.

En même temps, de mes souvenirs de cours VOIP et de ma pratique précédente de 
la VOIP, c'est la banalité de dire que ce ne sont pas les bonnes adresses IP 
qui sont échangées dans SDP…


> Ca vaut quand même le coup de tester Zoiper ou Bria au moins pour avoir la 
> confirmation que ça vient bien de Linphone, et ensuite tu pourras déterminer 
> si t’as envie de debugguer leur truc.

Mes collègues ont testé Zoiper sous winwin : ça ne chemar pas, personne 
s'entend, y compris quand STUN est activé. Je n'ai pas plus d'éléments, 
notamment pas de capture réseau des SDP.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[David Ponzone]

En interne, dans un VPN routé sans NAT, tu devais jamais avoir besoin de STUN.
Déjà que même avec du NAT, c’est pas nécessaire avec un SBC « intelligent » .

Tu veux pas juste essayer Zoiper gratuit ou autre, parce que perdre du temps 
sur un Linphone qui est peut-être une grosse bouze….
Opensource n’est pas synonyme de qualité.

> Le 17 mars 2020 à 13:32, Guillaume LUCAS  a 
> écrit :
> 
>> - Mail original -
>> De: "Michel Py" 
>> À: "Daniel" , "frnog" 
>> Envoyé: Mardi 17 Mars 2020 01:19:26
>> Objet: RE: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il 
>> vraiment autant de bugs que ça dans les implémentations SIP ?!)
> 
>> Je ne vois pas pourquoi. Si le VPN marche, tout devrait se passer avec 
>> RFC1918, donc l'adresse du softphone est bien celle du lien physique. 
>> Je ne comprends pas pourquoi tu t'enquiquines avec STUN, si tu as un VPN il 
>> ne devrait pas y avoir de NAT donc aucun besoin d'avoir STUN.
> 
> Raisonnement :
> 1) Notre PABX n'est pas joignable en IP depuis Internet ;
> 
> 2) D'où il faut le VPN pour s'enregistrer sur le PABX et plus si affinité ;
> 
> 3) Donc l'ordi sur lequel est installé un softphone a au moins deux 
> interfaces : eth0|wlan0 et vpn0 ;
> 
> 4) Notre VPN n'installe pas de route par défaut, juste les routes vers nos 
> réseaux internes ;
> 
> 5) Sur vpn0, il y aura une IP 10.30.x.x/16, réseau de tous nos clients VPN ;
> 
> 6) Sur eth0|wlan0, il aura l'IPv4 RFC1918 attribuée par le DHCP de sa box 
> genre 192.168.0.14/24 ;
> 
> 7) Lors de l'enregistrement sur le PABX, le softphone va émettre un SIP 
> REGISTER avec ip dst=. Le VPN offre une route /24 pour le réseau qui 
> contient le PABX, donc ça passe forcément par le VPN, donc le système 
> d'exploit' va sélectionner l'IP sur l'interface vpn0 pour la mettre dans ip 
> src du paquet IP ;
> 
> 8) Lors d'un appel, je constate, avec wireshark/tcpdump, que le softphone met 
> parfois l'IP de vpn0 (10.30.x.x) dans le paquet SDP et donc, là, ça marche de 
> base (comme ça semblait fonctionner depuis 6 mois pour les quelques 
> utilisateurs), car c'est du routage de base. Mais, souvent, il met l'IP de 
> eth0. Forcément, l'interlocuteur à l'autre bout ne peut pas envoyer de RTP 
> avec ip dst=192.168.0.14…
> 
> 9) Avec un serveur STUN sur le réseau local, la requête STUN sera contrainte, 
> par le routage, de passer dans le VPN (comme le SIP vers le PABX, voir point 
> 7) donc retournera toujours l'IP RFC1918 de vpn0. Et donc les flux RTP 
> monteront. Et c'est ce qui se passe quand les softphones ne 
> """"choisissent"""" pas d'ignorer la réponse qu'ils ont eu du serveur STUN 
> et/ou qu'ils n'ignorent pas la dernière SDP reçue et/ou…
> 
> 
> Je sais qu'il ne faut plus utiliser seulement STUN, que ICE c'est mieux. Mais 
> avant d'installer un serveur STUN à l'arrache, j'ai testé ICE et ça ne 
> fonctionnait pas. Dans mes souvenirs, ICE est une méthodo qui consiste à 
> s'échanger, dans SDP, tous les couples IP+port possibles, qu'on nomme 
> candidats. On a activé ça sur les softphones et c'est activé de base dans 
> XiVo. Quand j'analyse les SDP avec tcpdump, je vois qu'une seule proposition 
> dans SDP, l'IP RFC1918 de eth0…
> 
> 
>> Faire marcher SIP à travers NAT çà a toujours été une galère, mais au 
>> travers d'un VPN je ne vois pas pourquoi çà ne marcherait pas.
> 
> Idem ! C'est bien ce qui me prend la tête ! :)
> 
> 
>> Exactement ! Daniel a raison de dire que les problèmes que tu as sentent NAT 
>> a plein nez, ceci dit.
>> Si t'es sur qu'il n'y a pas de NAT (faire un traceroute) çà sent le pare-feu.
> 
> Je donne les """"preuves"""" suivantes :
>  * Dans le journal de mon Asterisk, j'ai bien des « chan_sip.c: Registered 
> SIP 'bczhcigi' at 10.30.1.175:62633 ». 10.30.X.X est bien une IP VPN. Je vois 
> bien une IP 10.30/16 différente par softphone ;
>  * Quand ils fonctionnent, les flux RTP circulent bien entre deux IP 
> 10.30.x.x, et c'est bien les IPs attribuées, par le VPN, aux deux clients VPN 
> ;
>  * mtr depuis mon ordi+VPN vers un de nos serveurs : un seul saut, le serveur 
> lui-même. mtr entre le serveur et mon ordi+VPN : un seul saut, mon IP VPN 
> (10.30.1.175).
> 
> 
> Pare-feu, je commence à y croire vu le merdier dans nos ACL Cisco ASA… Mais 
> comment expliquer que, sans y toucher, nos tests soient concluants de temps 
> en temps avec Linphone GNU/Linux ? Là, pour moi, ça échappe à toute 
> rationalité. Soit tu bloques constamment, soit tu laisses passer, mais pas 
> les deux.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

> - Mail original -
> De: "Michel Py" 
> À: "Daniel" , "frnog" 
> Envoyé: Mardi 17 Mars 2020 01:19:26
> Objet: RE: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il 
> vraiment autant de bugs que ça dans les implémentations SIP ?!)

> Je ne vois pas pourquoi. Si le VPN marche, tout devrait se passer avec 
> RFC1918, donc l'adresse du softphone est bien celle du lien physique. 
> Je ne comprends pas pourquoi tu t'enquiquines avec STUN, si tu as un VPN il 
> ne devrait pas y avoir de NAT donc aucun besoin d'avoir STUN.

Raisonnement :
1) Notre PABX n'est pas joignable en IP depuis Internet ;

2) D'où il faut le VPN pour s'enregistrer sur le PABX et plus si affinité ;

3) Donc l'ordi sur lequel est installé un softphone a au moins deux interfaces 
: eth0|wlan0 et vpn0 ;

4) Notre VPN n'installe pas de route par défaut, juste les routes vers nos 
réseaux internes ;

5) Sur vpn0, il y aura une IP 10.30.x.x/16, réseau de tous nos clients VPN ;

6) Sur eth0|wlan0, il aura l'IPv4 RFC1918 attribuée par le DHCP de sa box genre 
192.168.0.14/24 ;

7) Lors de l'enregistrement sur le PABX, le softphone va émettre un SIP 
REGISTER avec ip dst=. Le VPN offre une route /24 pour le réseau qui 
contient le PABX, donc ça passe forcément par le VPN, donc le système 
d'exploit' va sélectionner l'IP sur l'interface vpn0 pour la mettre dans ip src 
du paquet IP ;

8) Lors d'un appel, je constate, avec wireshark/tcpdump, que le softphone met 
parfois l'IP de vpn0 (10.30.x.x) dans le paquet SDP et donc, là, ça marche de 
base (comme ça semblait fonctionner depuis 6 mois pour les quelques 
utilisateurs), car c'est du routage de base. Mais, souvent, il met l'IP de 
eth0. Forcément, l'interlocuteur à l'autre bout ne peut pas envoyer de RTP avec 
ip dst=192.168.0.14…

9) Avec un serveur STUN sur le réseau local, la requête STUN sera contrainte, 
par le routage, de passer dans le VPN (comme le SIP vers le PABX, voir point 7) 
donc retournera toujours l'IP RFC1918 de vpn0. Et donc les flux RTP monteront. 
Et c'est ce qui se passe quand les softphones ne """"choisissent"""" pas 
d'ignorer la réponse qu'ils ont eu du serveur STUN et/ou qu'ils n'ignorent pas 
la dernière SDP reçue et/ou…


Je sais qu'il ne faut plus utiliser seulement STUN, que ICE c'est mieux. Mais 
avant d'installer un serveur STUN à l'arrache, j'ai testé ICE et ça ne 
fonctionnait pas. Dans mes souvenirs, ICE est une méthodo qui consiste à 
s'échanger, dans SDP, tous les couples IP+port possibles, qu'on nomme 
candidats. On a activé ça sur les softphones et c'est activé de base dans XiVo. 
Quand j'analyse les SDP avec tcpdump, je vois qu'une seule proposition dans 
SDP, l'IP RFC1918 de eth0…


> Faire marcher SIP à travers NAT çà a toujours été une galère, mais au travers 
> d'un VPN je ne vois pas pourquoi çà ne marcherait pas.

Idem ! C'est bien ce qui me prend la tête ! :)


> Exactement ! Daniel a raison de dire que les problèmes que tu as sentent NAT 
> a plein nez, ceci dit.
> Si t'es sur qu'il n'y a pas de NAT (faire un traceroute) çà sent le pare-feu.

Je donne les """"preuves"""" suivantes :
  * Dans le journal de mon Asterisk, j'ai bien des « chan_sip.c: Registered SIP 
'bczhcigi' at 10.30.1.175:62633 ». 10.30.X.X est bien une IP VPN. Je vois bien 
une IP 10.30/16 différente par softphone ;
  * Quand ils fonctionnent, les flux RTP circulent bien entre deux IP 
10.30.x.x, et c'est bien les IPs attribuées, par le VPN, aux deux clients VPN ;
  * mtr depuis mon ordi+VPN vers un de nos serveurs : un seul saut, le serveur 
lui-même. mtr entre le serveur et mon ordi+VPN : un seul saut, mon IP VPN 
(10.30.1.175).


Pare-feu, je commence à y croire vu le merdier dans nos ACL Cisco ASA… Mais 
comment expliquer que, sans y toucher, nos tests soient concluants de temps en 
temps avec Linphone GNU/Linux ? Là, pour moi, ça échappe à toute rationalité. 
Soit tu bloques constamment, soit tu laisses passer, mais pas les deux.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Daniel via frnog]

Bonjour

Le 17/03/2020 à 00:11, Guillaume LUCAS a écrit :

Bonsoir Daniel,

Version d'Asterisk : 13.22.0-1~xivo3+deb9+20181129.142257.a8a0975 .
A priori, dans le journal, ça cause de chan_sip partout et jamais de pjsip.


sip show peers => chan_sip

pjsip list endpoints => pjsip



Nous n'avons pas de NAT. À mes yeux, le VPN est un réseau interne comme un 
autre. Nos utilisateurs VPN sont dans un /16. Une route par défaut existe sur 
le VPN avec next hop le routeur de site. Une route statique avec next hop = VPN 
existe sur le routeur de site. Pour moi, tout n'est que routage. Surtout, ce 
qui m'étonne, c'est qu'il suffit de changer de version d'un même softphone 
(Linphone) pour que ça fonctionne… mais que sur un seul système d'exploitation.
Je pense que Linphone est à mettre en cause. Le problème n'est pas que 
le routage, Asterisk doit savoir quelle IP mettre dans les entêtes SIP. 
Dans l'interface Waxo/Xivo => Services => protocol SIP => Réseau il y a 
une zone réseau local: le VPN en /16 doit y être défini


Dans le journal Asterisk, j'ai bien des « Packet timed out after 32000ms with 
no response », mais je ne vois pas comment les corréler avec nos essais ? Je ne 
vois pas d'ID / chaînes de caractères en commun avec le reste du journal. Y'a 
trop de bruit autour pour dépatouiller avec un grep -C. Comment faire ?
Donc session timeout: Essaye en mettant session-timers=refuse dans la 
config d'un client qui génère cette erreur


Définition du réseau /16 VPN dans la conf' XiVo : aucune idée, j'appelle un 
collègue à la rescousse.

Voir ci dessus


Je confirme que nos postes SNOM juste marchent depuis 5 ans.

Merci.

Bonne nuit.


- Mail original -
De: "Daniel via frnog" 
À: frnog@frnog.org
Envoyé: Lundi 16 Mars 2020 22:53:47
Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment 
autant de bugs que ça dans les implémentations SIP ?!)

Bonsoir,

tout d'abord la version de Xivo/Asterisk n'étant pas connu, il y a des
différences importantes entre chan_sip et pjsip.

. les problèmes de sons qui ne passent pas d'un côté et/ou de l'autre
sont dus à des problèmes de NAT

. les timeout peuvent être dus au session-timer et doivent se voir dans
les logs du type no response received [bla bla]

. concernant les différents échanges, les réseaux VPN sont ils définis
dans localnet (chan_sip) local_net (pjsip) ?

. j'ai rencontré pas mal de soucis à une certaine époque avec Linphone,
j'ai abandonné. Je passe en iax dès que c'est possible (zoiper). Il
semble que les problèmes rencontrés viennent de softphone, j'installe du
SNOM (sauf DECT) et du GrandStream et n'ai jamais rencontré de tels
problèmes, poste en interne ou externe.

. en dehors de cela oui, SIP est un protocole que chacun peut mettre à
sa sauce qui fait que infine la compatibilité n'est plus au RDV
(Alcatel, Mitel. fibre Orange dédiée SIP (si elle existe encore), ...)

Le 16/03/2020 à 22:05, Guillaume LUCAS a écrit :

Bonjour à tous,

Mes collègues et moi rencontrons des problèmes avec nos softphones SIP, et 
j'aimerais un avis et surtout être réconforté.
=> Je sais que TOUTES les implémentations VOIP foirent plus ou moins. Je me 
souviens d'une box Numericable qui rebootait lorsqu'un SIP INVITE légitime > 1645 
octets arrivait du WAN. Je me souviens des erreurs de segmentation aléatoires de 
Jitsi/Ekiga. Je me souviens des messages SIP pas trop conformes à la norme et à la 
validation approximative des messages SIP reçus. Etc.
=> Mais je doute que le nombre de problèmes que nous rencontrons (et leur 
amplitude) soit normal.
=> Je suis dans une démarche de compréhension technique des problèmes 
rencontrés, donc je ne suis pas intéressé par des alternatives à des softphones.


Depuis 5 ans, nous utilisons le PABX Asterisk empaqueté dans la solution XiVo. 
Nous avons des postes téléphoniques SNOM, des téléphones analogiques, des T2, 
etc. IPv4 uniquement. Ce PABX n'est pas joignable depuis l'extérieur (en IP).

Nous avons aussi un VPN Cisco ASA. Adressage IPv4 RFC1918 (les réseaux internes 
sont plutôt adressés avec des IPv4 publiques, pas de v6). Pas d'IPv6. Accès aux 
réseaux internes, pas d'accès à Internet. Pas de filtrage particulier (oui, 
n'importe quel utilisateur du VPN peut se promener dans tous les réseaux 
internes, ça va changer).

Depuis 6 mois environ, nous avons de très rares softphones Linphone 
majoritairement sous winwin 7/10. Ils sont utilisés conjointement avec le VPN.

Jusque-là, personne nous a fait remonter des problèmes sur les softphones+VPN. 
Mais vu le peu d'utilisateurs…
Le coronavirus débarque et nous voilà priés de fournir un softphone à tout le 
monde. Et là, surprise, ça ne marche plus. Ou plus tout le temps. Ou plus pour 
tout le monde.


Le premier problème est un classique. Entre un softphone+VPN à domicile et un 
poste SNOM du bureau, soit les deux interlocuteurs ne s'entendent pas, soit un 
seul entend l'autre.
=> Dans ses SDP, Linphone insère l'

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[pisrateurboun]

Bonjour à tous,


On mixte du softphone (Zoiper) et du téléphone IP depuis 15 ans en IPsec/VPN 
SSL,anciennement MPLS sur du Asterix/Xivo/Mitel et anciennement Ericson sur des 
réseaux internes pas RFC 1918 (quelle idée mais c'est historique)
Au tout début j'ai eu des problèmes d'implémentations à cause du NAT et/ou des 
ACL, parfois parce qu'il n'y a pas que du 5060 mais du 5061 ou parce que les 
communications coupaient au bout de 15 minutes à cause du routeur central. 
Depuis qu'on a éliminé le NAT je n'ai plus ce soucis, SAUF lors d'une 
expérimentions en TSE multi-utilisateur avec 1 IP par utilisateur.
Petite précision, pas besoin d'utiliser de STUN ou de proxy NAT SBC.

Ah si, j'ai encore un site avec passerelle externe et NAT qui me fait des 
communications blanches sur certains SDA et opérateurs.


@+

Clément


- Mail original -
De: "Guillaume LUCAS" 
À: frnog-t...@frnog.org
Envoyé: Lundi 16 Mars 2020 22:05:07
Objet: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment 
autant de bugs que ça dans les implémentations SIP ?!)

Bonjour à tous, 

Mes collègues et moi rencontrons des problèmes avec nos softphones SIP, et 
j'aimerais un avis et surtout être réconforté. 
=> Je sais que TOUTES les implémentations VOIP foirent plus ou moins. Je me 
souviens d'une box Numericable qui rebootait lorsqu'un SIP INVITE légitime > 
1645 octets arrivait du WAN. Je me souviens des erreurs de segmentation 
aléatoires de Jitsi/Ekiga. Je me souviens des messages SIP pas trop conformes à 
la norme et à la validation approximative des messages SIP reçus. Etc. 
=> Mais je doute que le nombre de problèmes que nous rencontrons (et leur 
amplitude) soit normal. 
=> Je suis dans une démarche de compréhension technique des problèmes 
rencontrés, donc je ne suis pas intéressé par des alternatives à des 
softphones. 


Depuis 5 ans, nous utilisons le PABX Asterisk empaqueté dans la solution XiVo. 
Nous avons des postes téléphoniques SNOM, des téléphones analogiques, des T2, 
etc. IPv4 uniquement. Ce PABX n'est pas joignable depuis l'extérieur (en IP). 

Nous avons aussi un VPN Cisco ASA. Adressage IPv4 RFC1918 (les réseaux internes 
sont plutôt adressés avec des IPv4 publiques, pas de v6). Pas d'IPv6. Accès aux 
réseaux internes, pas d'accès à Internet. Pas de filtrage particulier (oui, 
n'importe quel utilisateur du VPN peut se promener dans tous les réseaux 
internes, ça va changer). 

Depuis 6 mois environ, nous avons de très rares softphones Linphone 
majoritairement sous winwin 7/10. Ils sont utilisés conjointement avec le VPN. 

Jusque-là, personne nous a fait remonter des problèmes sur les softphones+VPN. 
Mais vu le peu d'utilisateurs… 
Le coronavirus débarque et nous voilà priés de fournir un softphone à tout le 
monde. Et là, surprise, ça ne marche plus. Ou plus tout le temps. Ou plus pour 
tout le monde. 


Le premier problème est un classique. Entre un softphone+VPN à domicile et un 
poste SNOM du bureau, soit les deux interlocuteurs ne s'entendent pas, soit un 
seul entend l'autre. 
=> Dans ses SDP, Linphone insère l'IP RFC1918 de l'interface physique (eth0, 
Wi-Fi, etc.) plutôt que celle du VPN. Forcément, ça ne fonctionne pas. 
=> On installe un serveur STUN dans le réseau de l'organisation. On configure 
STUN dans les paramètres de Linphone et ça fonctionne. 
=> Notons que certains Linphone fonctionnent aléatoirement et temporairement 
sans STUN. Même chose avec Jitsi. Comment est-ce possible ? 
=> Un Wireshark nous montre qu'une fois l'échange SIP initié, le client cause 
en STUN au PABX et que celui-ci répond. Pourquoi ça ne suffit pas toujours ? 
C'est d'ailleurs bizarre, car aucun serveur STUN écoute en permanence, on 
dirait que c'est fait à la demande ? 


Deuxième problème. Lors d'une conversation entre un Linphone 3.11 empaqueté 
dans Debian GNU/Linux ou Ubuntu GNU/Linux et un Linphone 4.1.1 GNU/Linux 
distribué via Flatpak, si c'est le Linphone 4.1.1 qui initie la conversation, 
la conversation durera 31/32 secs au maximum avant raccrochage auto. 
=> Pas de soucis si c'est le Linphone 3.11 qui initie la conversation. 
=> Pas de problème quand le Linphone 4.1.1 cause à un SNOM ou à un 06/09 
externe. 
=> Rien d'évident dans le journal des deux Linphone. 
=> Côté Asterisk, on voit que le Linphone 4.1.1 quitte le « 'native_rtp' 
basic_bridge », donc Asterisk nettoie, à raison, avec code retour != 0. 
=> Wireshark montre un Asterisk qui envoie, au Linphone 4.1.1, un SIP BYE avec 
un entête « X-Asterisk-HangupCause: no user responding ». 
=> Pas de pare-feu, pas de NAT. 
=> Nous pensons que le Linphone 3.11 n'envoie pas un message SIP attendu par 
son interlocuteur. Ou paquet malformé. Ou Linphone 4.1.1 plus strict. Ou… 
==> Solution : sur GNU/Linux, utiliser Linphone 3.12 (+STUN, bien entendu) 
partout. Ça fonctionne impec', sans exception. 


Troisième problème. Le journal du VPN nous montre parfois des paquets UDP 
bloqués entre le serveur Asterisk et un client VPN. C'est très peu 

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[David Ponzone]

https://superuser.com/questions/1133293/linphone-sip-invite-providing-wrong-ip-on-multi-nic-system

Tu es visiblement pas le seul à avoir ce problème de binding.
Pas beaucoup de discussion sur ce sujet néanmoins.
Ca vaut quand même le coup de tester Zoiper ou Bria au moins pour avoir la 
confirmation que ça vient bien de Linphone, et ensuite tu pourras déterminer si 
t’as envie de debugguer leur truc.

David Ponzone



> Le 17 mars 2020 à 00:12, Guillaume LUCAS  a 
> écrit :
> 
> Bonsoir Daniel,
> 
> Version d'Asterisk : 13.22.0-1~xivo3+deb9+20181129.142257.a8a0975 .
> A priori, dans le journal, ça cause de chan_sip partout et jamais de pjsip.
> 
> Nous n'avons pas de NAT. À mes yeux, le VPN est un réseau interne comme un 
> autre. Nos utilisateurs VPN sont dans un /16. Une route par défaut existe sur 
> le VPN avec next hop le routeur de site. Une route statique avec next hop = 
> VPN existe sur le routeur de site. Pour moi, tout n'est que routage. Surtout, 
> ce qui m'étonne, c'est qu'il suffit de changer de version d'un même softphone 
> (Linphone) pour que ça fonctionne… mais que sur un seul système 
> d'exploitation.
> 
> Dans le journal Asterisk, j'ai bien des « Packet timed out after 32000ms with 
> no response », mais je ne vois pas comment les corréler avec nos essais ? Je 
> ne vois pas d'ID / chaînes de caractères en commun avec le reste du journal. 
> Y'a trop de bruit autour pour dépatouiller avec un grep -C. Comment faire ?
> 
> Définition du réseau /16 VPN dans la conf' XiVo : aucune idée, j'appelle un 
> collègue à la rescousse.
> 
> Je confirme que nos postes SNOM juste marchent depuis 5 ans.

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

RE: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Michel Py]

> Daniel Huhardeaux a écrit :
> les problèmes de sons qui ne passent pas d'un côté et/ou de l'autre sont dus 
> à des problèmes de NAT

+1. Ou de pare-feu. Dans le genre le port 5060 est ouvert mais les ports 
utilisés par RTP ne le sont pas.

Le seul softphone dont je me sers est GSWave de Grandstream sur Android, jamais 
eu de problème avec.
J'ai des téléphones Grandstream qui marchent à travers de VPN, aucun problème 
non plus. J'ai un tronc IAX entre 2 Asterisk au travers du VPN aussi, çà juste 
marche.

> Guillaume LUCAS a écrit :
> => Dans ses SDP, Linphone insère l'IP RFC1918 de l'interface physique (eth0,
> Wi-Fi, etc.) plutôt que celle du VPN. Forcément, ça ne fonctionne pas.

Je ne vois pas pourquoi. Si le VPN marche, tout devrait se passer avec RFC1918, 
donc l'adresse du softphone est bien celle du lien physique. 
Je ne comprends pas pourquoi tu t'enquiquines avec STUN, si tu as un VPN il ne 
devrait pas y avoir de NAT donc aucun besoin d'avoir STUN.

Faire marcher SIP à travers NAT çà a toujours été une galère, mais au travers 
d'un VPN je ne vois pas pourquoi çà ne marcherait pas.

> Nous n'avons pas de NAT. À mes yeux, le VPN est un réseau interne comme un 
> autre.

Exactement ! Daniel a raison de dire que les problèmes que tu as sentent NAT a 
plein nez, ceci dit.
Si t'es sur qu'il n'y a pas de NAT (faire un traceroute) çà sent le pare-feu.

> A priori, dans le journal, ça cause de chan_sip partout et jamais de pjsip.

Avec Asterisk 13, je ne fais plus que du PJSIP. C'est la seule manière propre 
de connecter plus d'un téléphone sur une seule extension, de toute façon.

Michel.


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

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Guillaume LUCAS]

Bonsoir Daniel,

Version d'Asterisk : 13.22.0-1~xivo3+deb9+20181129.142257.a8a0975 .
A priori, dans le journal, ça cause de chan_sip partout et jamais de pjsip.

Nous n'avons pas de NAT. À mes yeux, le VPN est un réseau interne comme un 
autre. Nos utilisateurs VPN sont dans un /16. Une route par défaut existe sur 
le VPN avec next hop le routeur de site. Une route statique avec next hop = VPN 
existe sur le routeur de site. Pour moi, tout n'est que routage. Surtout, ce 
qui m'étonne, c'est qu'il suffit de changer de version d'un même softphone 
(Linphone) pour que ça fonctionne… mais que sur un seul système d'exploitation.

Dans le journal Asterisk, j'ai bien des « Packet timed out after 32000ms with 
no response », mais je ne vois pas comment les corréler avec nos essais ? Je ne 
vois pas d'ID / chaînes de caractères en commun avec le reste du journal. Y'a 
trop de bruit autour pour dépatouiller avec un grep -C. Comment faire ?

Définition du réseau /16 VPN dans la conf' XiVo : aucune idée, j'appelle un 
collègue à la rescousse.

Je confirme que nos postes SNOM juste marchent depuis 5 ans.

Merci.

Bonne nuit.


- Mail original -
De: "Daniel via frnog" 
À: frnog@frnog.org
Envoyé: Lundi 16 Mars 2020 22:53:47
Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment 
autant de bugs que ça dans les implémentations SIP ?!)

Bonsoir,

tout d'abord la version de Xivo/Asterisk n'étant pas connu, il y a des 
différences importantes entre chan_sip et pjsip.

. les problèmes de sons qui ne passent pas d'un côté et/ou de l'autre 
sont dus à des problèmes de NAT

. les timeout peuvent être dus au session-timer et doivent se voir dans 
les logs du type no response received [bla bla]

. concernant les différents échanges, les réseaux VPN sont ils définis 
dans localnet (chan_sip) local_net (pjsip) ?

. j'ai rencontré pas mal de soucis à une certaine époque avec Linphone, 
j'ai abandonné. Je passe en iax dès que c'est possible (zoiper). Il 
semble que les problèmes rencontrés viennent de softphone, j'installe du 
SNOM (sauf DECT) et du GrandStream et n'ai jamais rencontré de tels 
problèmes, poste en interne ou externe.

. en dehors de cela oui, SIP est un protocole que chacun peut mettre à 
sa sauce qui fait que infine la compatibilité n'est plus au RDV 
(Alcatel, Mitel. fibre Orange dédiée SIP (si elle existe encore), ...)

Le 16/03/2020 à 22:05, Guillaume LUCAS a écrit :
> Bonjour à tous,
>
> Mes collègues et moi rencontrons des problèmes avec nos softphones SIP, et 
> j'aimerais un avis et surtout être réconforté.
> => Je sais que TOUTES les implémentations VOIP foirent plus ou moins. Je me 
> souviens d'une box Numericable qui rebootait lorsqu'un SIP INVITE légitime > 
> 1645 octets arrivait du WAN. Je me souviens des erreurs de segmentation 
> aléatoires de Jitsi/Ekiga. Je me souviens des messages SIP pas trop conformes 
> à la norme et à la validation approximative des messages SIP reçus. Etc.
> => Mais je doute que le nombre de problèmes que nous rencontrons (et leur 
> amplitude) soit normal.
> => Je suis dans une démarche de compréhension technique des problèmes 
> rencontrés, donc je ne suis pas intéressé par des alternatives à des 
> softphones.
>
>
> Depuis 5 ans, nous utilisons le PABX Asterisk empaqueté dans la solution 
> XiVo. Nous avons des postes téléphoniques SNOM, des téléphones analogiques, 
> des T2, etc. IPv4 uniquement. Ce PABX n'est pas joignable depuis l'extérieur 
> (en IP).
>
> Nous avons aussi un VPN Cisco ASA. Adressage IPv4 RFC1918 (les réseaux 
> internes sont plutôt adressés avec des IPv4 publiques, pas de v6). Pas 
> d'IPv6. Accès aux réseaux internes, pas d'accès à Internet. Pas de filtrage 
> particulier (oui, n'importe quel utilisateur du VPN peut se promener dans 
> tous les réseaux internes, ça va changer).
>
> Depuis 6 mois environ, nous avons de très rares softphones Linphone 
> majoritairement sous winwin 7/10. Ils sont utilisés conjointement avec le VPN.
>
> Jusque-là, personne nous a fait remonter des problèmes sur les 
> softphones+VPN. Mais vu le peu d'utilisateurs…
> Le coronavirus débarque et nous voilà priés de fournir un softphone à tout le 
> monde. Et là, surprise, ça ne marche plus. Ou plus tout le temps. Ou plus 
> pour tout le monde.
>
>
> Le premier problème est un classique. Entre un softphone+VPN à domicile et un 
> poste SNOM du bureau, soit les deux interlocuteurs ne s'entendent pas, soit 
> un seul entend l'autre.
> => Dans ses SDP, Linphone insère l'IP RFC1918 de l'interface physique (eth0, 
> Wi-Fi, etc.) plutôt que celle du VPN. Forcément, ça ne fonctionne pas.
> => On installe un serveur STUN dans le réseau de l'organisation. On configure 
> STUN dans les paramètres de Linphone et ça fonctionne.
> => Notons que certains Linphone fonctionnent aléatoirement et te

Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

[Daniel via frnog]

Bonsoir,

tout d'abord la version de Xivo/Asterisk n'étant pas connu, il y a des 
différences importantes entre chan_sip et pjsip.


. les problèmes de sons qui ne passent pas d'un côté et/ou de l'autre 
sont dus à des problèmes de NAT


. les timeout peuvent être dus au session-timer et doivent se voir dans 
les logs du type no response received [bla bla]


. concernant les différents échanges, les réseaux VPN sont ils définis 
dans localnet (chan_sip) local_net (pjsip) ?


. j'ai rencontré pas mal de soucis à une certaine époque avec Linphone, 
j'ai abandonné. Je passe en iax dès que c'est possible (zoiper). Il 
semble que les problèmes rencontrés viennent de softphone, j'installe du 
SNOM (sauf DECT) et du GrandStream et n'ai jamais rencontré de tels 
problèmes, poste en interne ou externe.


. en dehors de cela oui, SIP est un protocole que chacun peut mettre à 
sa sauce qui fait que infine la compatibilité n'est plus au RDV 
(Alcatel, Mitel. fibre Orange dédiée SIP (si elle existe encore), ...)


Le 16/03/2020 à 22:05, Guillaume LUCAS a écrit :

Bonjour à tous,

Mes collègues et moi rencontrons des problèmes avec nos softphones SIP, et 
j'aimerais un avis et surtout être réconforté.
=> Je sais que TOUTES les implémentations VOIP foirent plus ou moins. Je me 
souviens d'une box Numericable qui rebootait lorsqu'un SIP INVITE légitime > 1645 
octets arrivait du WAN. Je me souviens des erreurs de segmentation aléatoires de 
Jitsi/Ekiga. Je me souviens des messages SIP pas trop conformes à la norme et à la 
validation approximative des messages SIP reçus. Etc.
=> Mais je doute que le nombre de problèmes que nous rencontrons (et leur 
amplitude) soit normal.
=> Je suis dans une démarche de compréhension technique des problèmes 
rencontrés, donc je ne suis pas intéressé par des alternatives à des softphones.


Depuis 5 ans, nous utilisons le PABX Asterisk empaqueté dans la solution XiVo. 
Nous avons des postes téléphoniques SNOM, des téléphones analogiques, des T2, 
etc. IPv4 uniquement. Ce PABX n'est pas joignable depuis l'extérieur (en IP).

Nous avons aussi un VPN Cisco ASA. Adressage IPv4 RFC1918 (les réseaux internes 
sont plutôt adressés avec des IPv4 publiques, pas de v6). Pas d'IPv6. Accès aux 
réseaux internes, pas d'accès à Internet. Pas de filtrage particulier (oui, 
n'importe quel utilisateur du VPN peut se promener dans tous les réseaux 
internes, ça va changer).

Depuis 6 mois environ, nous avons de très rares softphones Linphone 
majoritairement sous winwin 7/10. Ils sont utilisés conjointement avec le VPN.

Jusque-là, personne nous a fait remonter des problèmes sur les softphones+VPN. 
Mais vu le peu d'utilisateurs…
Le coronavirus débarque et nous voilà priés de fournir un softphone à tout le 
monde. Et là, surprise, ça ne marche plus. Ou plus tout le temps. Ou plus pour 
tout le monde.


Le premier problème est un classique. Entre un softphone+VPN à domicile et un 
poste SNOM du bureau, soit les deux interlocuteurs ne s'entendent pas, soit un 
seul entend l'autre.
=> Dans ses SDP, Linphone insère l'IP RFC1918 de l'interface physique (eth0, 
Wi-Fi, etc.) plutôt que celle du VPN. Forcément, ça ne fonctionne pas.
=> On installe un serveur STUN dans le réseau de l'organisation. On configure 
STUN dans les paramètres de Linphone et ça fonctionne.
=> Notons que certains Linphone fonctionnent aléatoirement et temporairement 
sans STUN. Même chose avec Jitsi. Comment est-ce possible ?
=> Un Wireshark nous montre qu'une fois l'échange SIP initié, le client cause 
en STUN au PABX et que celui-ci répond. Pourquoi ça ne suffit pas toujours ? C'est 
d'ailleurs bizarre, car aucun serveur STUN écoute en permanence, on dirait que 
c'est fait à la demande ?


Deuxième problème. Lors d'une conversation entre un Linphone 3.11 empaqueté 
dans Debian GNU/Linux ou Ubuntu GNU/Linux et un Linphone 4.1.1 GNU/Linux 
distribué via Flatpak, si c'est le Linphone 4.1.1 qui initie la conversation, 
la conversation durera 31/32 secs au maximum avant raccrochage auto.
=> Pas de soucis si c'est le Linphone 3.11 qui initie la conversation.
=> Pas de problème quand le Linphone 4.1.1 cause à un SNOM ou à un 06/09 
externe.
=> Rien d'évident dans le journal des deux Linphone.
=> Côté Asterisk, on voit que le Linphone 4.1.1 quitte le « 'native_rtp' 
basic_bridge », donc Asterisk nettoie, à raison, avec code retour != 0.
=> Wireshark montre un Asterisk qui envoie, au Linphone 4.1.1, un SIP BYE avec 
un entête « X-Asterisk-HangupCause: no user responding ».
=> Pas de pare-feu, pas de NAT.
=> Nous pensons que le Linphone 3.11 n'envoie pas un message SIP attendu par 
son interlocuteur. Ou paquet malformé. Ou Linphone 4.1.1 plus strict. Ou…
==> Solution : sur GNU/Linux, utiliser Linphone 3.12 (+STUN, bien entendu) 
partout. Ça fonctionne impec', sans exception.


Troisième problème. Le journal du VPN nous montre parfois des paquets UDP 
bloqués entre le serveur Asterisk et un client VPN. C'est très peu (moins de 10 
paquets bloqués