subject:"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 \?\!\)"


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 ?!)




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 ?!)


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 ?!)


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 ?!)


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 ?!)


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 ?!)

> - 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 ?!)

2020-03-18 Par sujet 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 ?!)

2020-03-18 Par sujet 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 ?!)


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 ?!)

2020-03-18 Par sujet 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 ?!)

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 ?!)

- 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 ?!)

2020-03-18 Par sujet 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 ?!)

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 ?!)

2020-03-18 Par sujet 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 ?!)

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 ?!)

> - 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 ?!)

> - 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 ?!)

>> 
> 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 ?!)

2020-03-18 Par sujet 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 ?!)




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 ?!)

> - 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 ?!)




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 ?!)

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 ?!)

> - 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 ?!)

2020-03-18 Par sujet 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 ?!)

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 ?!)

> - 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 ?!)




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 ?!)

2020-03-17 Par sujet 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 ?!)

2020-03-17 Par sujet 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 ?!)

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 ?!)

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 ?!)

> - 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 ?!)



> 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 ?!)

- 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 ?!)

> 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 ?!)

2020-03-17 Par sujet 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 ?!)

> - 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 ?!)

> - 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 ?!)



> 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 ?!)

> - 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 ?!)

2020-03-17 Par sujet 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 ?!)

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 ?!)

> - 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 ?!)

> - 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 ?!)

> - 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 ?!)

> - 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 ?!)

> - 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 ?!)

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 ?!)

2020-03-17 Par sujet 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 ?!)

> - 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 ?!)




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 ?!)

- 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 ?!)

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 ?!)




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 ?!)

2020-03-17 Par sujet 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 ?!)

> - 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 ?!)

> - 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 ?!)




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 ?!)

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 ?!)

> - 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 ?!)




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 ?!)

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

[...]
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…

Et cela te parait normal? Il y a déjà un problème au départ, Linphone ou
autre.

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

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…

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

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 ! :)

As tu fais les modifs au niveau localnet ?

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).
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

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.

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

--
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 ?!)

Ç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 ?!)



> 
> 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 ?!)

> - 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 ?!)

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 ?!)

> - 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 ?!)