Bonsoir Daniel, Version d'Asterisk : 13.22.0-1~xivo3+deb9+20181129.142257.a8a0975 . A priori, dans le journal, ça cause de chan_sip partout et jamais de pjsip.
Nous n'avons pas de NAT. À mes yeux, le VPN est un réseau interne comme un autre. Nos utilisateurs VPN sont dans un /16. Une route par défaut existe sur le VPN avec next hop le routeur de site. Une route statique avec next hop = VPN existe sur le routeur de site. Pour moi, tout n'est que routage. Surtout, ce qui m'étonne, c'est qu'il suffit de changer de version d'un même softphone (Linphone) pour que ça fonctionne… mais que sur un seul système d'exploitation. Dans le journal Asterisk, j'ai bien des « Packet timed out after 32000ms with no response », mais je ne vois pas comment les corréler avec nos essais ? Je ne vois pas d'ID / chaînes de caractères en commun avec le reste du journal. Y'a trop de bruit autour pour dépatouiller avec un grep -C. Comment faire ? Définition du réseau /16 VPN dans la conf' XiVo : aucune idée, j'appelle un collègue à la rescousse. Je confirme que nos postes SNOM juste marchent depuis 5 ans. Merci. Bonne nuit. ----- Mail original ----- De: "Daniel via frnog" <frnog@frnog.org> À: frnog@frnog.org Envoyé: Lundi 16 Mars 2020 22:53:47 Objet: Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!) Bonsoir, tout d'abord la version de Xivo/Asterisk n'étant pas connu, il y a des différences importantes entre chan_sip et pjsip. . les problèmes de sons qui ne passent pas d'un côté et/ou de l'autre sont dus à des problèmes de NAT . les timeout peuvent être dus au session-timer et doivent se voir dans les logs du type no response received [bla bla] . concernant les différents échanges, les réseaux VPN sont ils définis dans localnet (chan_sip) local_net (pjsip) ? . j'ai rencontré pas mal de soucis à une certaine époque avec Linphone, j'ai abandonné. Je passe en iax dès que c'est possible (zoiper). Il semble que les problèmes rencontrés viennent de softphone, j'installe du SNOM (sauf DECT) et du GrandStream et n'ai jamais rencontré de tels problèmes, poste en interne ou externe. . en dehors de cela oui, SIP est un protocole que chacun peut mettre à sa sauce qui fait que infine la compatibilité n'est plus au RDV (Alcatel, Mitel. fibre Orange dédiée SIP (si elle existe encore), ...) Le 16/03/2020 à 22:05, Guillaume LUCAS a écrit : > Bonjour à tous, > > Mes collègues et moi rencontrons des problèmes avec nos softphones SIP, et > j'aimerais un avis et surtout être réconforté. > => Je sais que TOUTES les implémentations VOIP foirent plus ou moins. Je me > souviens d'une box Numericable qui rebootait lorsqu'un SIP INVITE légitime > > 1645 octets arrivait du WAN. Je me souviens des erreurs de segmentation > aléatoires de Jitsi/Ekiga. Je me souviens des messages SIP pas trop conformes > à la norme et à la validation approximative des messages SIP reçus. Etc. > => Mais je doute que le nombre de problèmes que nous rencontrons (et leur > amplitude) soit normal. > => Je suis dans une démarche de compréhension technique des problèmes > rencontrés, donc je ne suis pas intéressé par des alternatives à des > softphones. > > > Depuis 5 ans, nous utilisons le PABX Asterisk empaqueté dans la solution > XiVo. Nous avons des postes téléphoniques SNOM, des téléphones analogiques, > des T2, etc. IPv4 uniquement. Ce PABX n'est pas joignable depuis l'extérieur > (en IP). > > Nous avons aussi un VPN Cisco ASA. Adressage IPv4 RFC1918 (les réseaux > internes sont plutôt adressés avec des IPv4 publiques, pas de v6). Pas > d'IPv6. Accès aux réseaux internes, pas d'accès à Internet. Pas de filtrage > particulier (oui, n'importe quel utilisateur du VPN peut se promener dans > tous les réseaux internes, ça va changer). > > Depuis 6 mois environ, nous avons de très rares softphones Linphone > majoritairement sous winwin 7/10. Ils sont utilisés conjointement avec le VPN. > > Jusque-là, personne nous a fait remonter des problèmes sur les > softphones+VPN. Mais vu le peu d'utilisateurs… > Le coronavirus débarque et nous voilà priés de fournir un softphone à tout le > monde. Et là, surprise, ça ne marche plus. Ou plus tout le temps. Ou plus > pour tout le monde. > > > Le premier problème est un classique. Entre un softphone+VPN à domicile et un > poste SNOM du bureau, soit les deux interlocuteurs ne s'entendent pas, soit > un seul entend l'autre. > => Dans ses SDP, Linphone insère l'IP RFC1918 de l'interface physique (eth0, > Wi-Fi, etc.) plutôt que celle du VPN. Forcément, ça ne fonctionne pas. > => On installe un serveur STUN dans le réseau de l'organisation. On configure > STUN dans les paramètres de Linphone et ça fonctionne. > => Notons que certains Linphone fonctionnent aléatoirement et temporairement > sans STUN. Même chose avec Jitsi. Comment est-ce possible ? > => Un Wireshark nous montre qu'une fois l'échange SIP initié, le client cause > en STUN au PABX et que celui-ci répond. Pourquoi ça ne suffit pas toujours ? > C'est d'ailleurs bizarre, car aucun serveur STUN écoute en permanence, on > dirait que c'est fait à la demande ? > > > Deuxième problème. Lors d'une conversation entre un Linphone 3.11 empaqueté > dans Debian GNU/Linux ou Ubuntu GNU/Linux et un Linphone 4.1.1 GNU/Linux > distribué via Flatpak, si c'est le Linphone 4.1.1 qui initie la conversation, > la conversation durera 31/32 secs au maximum avant raccrochage auto. > => Pas de soucis si c'est le Linphone 3.11 qui initie la conversation. > => Pas de problème quand le Linphone 4.1.1 cause à un SNOM ou à un 06/09 > externe. > => Rien d'évident dans le journal des deux Linphone. > => Côté Asterisk, on voit que le Linphone 4.1.1 quitte le « 'native_rtp' > basic_bridge », donc Asterisk nettoie, à raison, avec code retour != 0. > => Wireshark montre un Asterisk qui envoie, au Linphone 4.1.1, un SIP BYE > avec un entête « X-Asterisk-HangupCause: no user responding ». > => Pas de pare-feu, pas de NAT. > => Nous pensons que le Linphone 3.11 n'envoie pas un message SIP attendu par > son interlocuteur. Ou paquet malformé. Ou Linphone 4.1.1 plus strict. Ou… > ==> Solution : sur GNU/Linux, utiliser Linphone 3.12 (+STUN, bien entendu) > partout. Ça fonctionne impec', sans exception. > > > Troisième problème. Le journal du VPN nous montre parfois des paquets UDP > bloqués entre le serveur Asterisk et un client VPN. C'est très peu (moins de > 10 paquets bloqués sur les 5 comptes utilisateurs surveillés pendant la > matinée, mais quand même. > => « no inspect sip » => plus de blocage. > > > Quatrième problème. Linphone 4.1.1 pour GNU/Linux arrête subitement d'émettre > des requêtes STUN. > => Wireshark installé sur la machine est formel. > => STUN est toujours activé dans la conf'. > => Linphone n'a pas été stoppé entre le moment "ça marche" et le moment "ça > marche plus". > => L'ordinateur n'a changé de réseau, n'a pas été redémarré ni autre. > => Après plusieurs redémarrages de Linphone, celui-ci émet à nouveau des > requêtes STUN, reçoit une réponse… mais choisi d'envoyer l'IPv4 RFC1918 de > l'interface eth0 dans sa SDP… … … Forcément, son utilisateur n'entendra pas > son correspondant… > => Entre le "ça marche" et "ça marche plus", l'ordinateur a obtenu une IPv6 > sur son réseau local. > => Dans les paramètres de Linphone, décocher « Autoriser IPv6 » conduit > Linphone à intégrer l'IPv4 obtenue via STUN dans sa SDP, et donc à rétablir > le fonctionnement. Aucun dysfonctionnement constaté cet après-midi. > > > Cinquième problème. Conversation entre un Linphone 4.1.1 winwin et un > Linphone 4.1.1 winwin ou Linphone 4.1.1 GNU/Linux. Personne s'entend. STUN > est configuré explicitement sur tous les Linphone. > => Wireshark nous montre que le Linphone winwin reçoit le flux RTP de > l'interlocuteur GNU/Linux. > => En revanche, pendant moins d'une seconde, le Linphone winwin émet son flux > RTP avec ip dst = serveur Asterisk. Après il interprète la SDP, journalise > cela « Change audio stream destination: RTP=10.30.1.24:7078 > RTCP=10.30.1.24:7079 » (l'IP est bien celle de l'interlocuteur) mais il > n'émet plus de RTP ! On dirait un bug de bascule, mais c'est la base de SIP > (mise en relation, musique d'attente, transfert d'appel…). Trop gros pour > être crédible. > => Avec Linphone 3.11 winwin : personne s'entend et ça raccroche auto au bout > de 31/32 secs (voir deuxième problème). > => Avec Linphone version winwin store : en fonction de qui initie l'appel, > soit personne s'entend soit uniquement un interlocuteur sur les deux. Et ça > raccroche auto au bout de 31/32 secs (voir deuxième problème). > => Rien dans le journal Asterisk. À le lire, le job est fait, ça dépile les > contextes, vérifie les droits d'appels, et crée des native_rtp basic-bridges > pour mettre les gens en relation. Tout se passe comme si c'est toujours les > clients qui foirent et obligent Asterisk à clore la communication. > => Pare-feu winwin désactivé, pas de NAT. > => Désactiver ICE côté Asterisk + redémarrer Asterisk change rien. > => Utiliser le client VOIP Zoiper + STUN : personne s'entend. > => Utiliser le client Jitsi ou Blink : parfois ça fonctionne, mais vu qu'il > n'est pas possible de configurer explicitement STUN, le comportement est > aléatoire. > => En fin de journée, sans action de notre part, on a pu avoir des appels > Linphone version winwin store <=> Linphone 4.1.1 GNU/Linux. Je parie que ça > ne fonctionnera plus demain. > => La version 4.1.1 pour winwin dont l'exe est distribué sur le site officiel > du projet ne fonctionne toujours pas. > => Si c'est le Linphone GNU/Linux qui initie l'appel, alors ça raccroche auto > au bout de 31/32 secs (deuxième problème). Quelqu'un sait pourquoi ? > => Très rigolo. Si, dans l'interface web de XiVo, pour chaque ligne SIP > participant au test, nous changeons la valeur du « temps de sonnerie » de 30 > secs à 60 secs, que les deux softphones sont redémarrés, alors ça change > rien. Mais si nous remettons 30 secs, que l'on ne redémarre pas nos > softphones, alors l'appel peut durer autant qu'on veut. Si l'on redémarre nos > softphones, retour case départ. WAAAAAAAAAAAAAAAT ???!!! > > > Pour finir, un bug rigolo. Lors d'un appel avec un Linphone winwin store, si > la fenêtre Linphone est réduite, les deux interlocuteurs ne s'entendent plus. > Il n'est pas obligatoire de laisser Linphone au premier plan, mais > interdiction de le réduire dans la zone de notification. C'est beau. > > > Voilà… Si vous avez > => du réconfort du genre « j'ai déjà vécu autant de problèmes avec mon > installation SIP, t'es pas un cas isolé » (les problèmes rencontrés sont > tellement bloquants pour la majorité des utilisateurs que je peine à croire > que nous sommes les premiers à les expérimenter)… > => des explications techniques pour expliquer les points 1 (pourquoi certains > clients VOIP fonctionnent parfois sans STUN à contexte/environnement > identique) et 5 (pourquoi ça raccroche au bout de 31/32 secs ? Quelle est la > sorcellerie derrière la modification du temps de sonnerie ?)… > => voire une réponse à la question « tout se joue VRAIMENT à une version de > softphone près ? »… > => Merci d'avance. > > Bonne fin de journée. > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ -- Daniel Huhardeaux +33.368460...@tootai.net sip: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/
