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