Bonjour, je ne sais pas si je suis trop tard maid bon.
pour que ca fonctionne il faut que les ports 10000-20000 (par default asterisk rtp soit permis au niveau du asterisk). Par experience si tu te fais trop chier tu peux essayer l'ipv6 donc tu elimines tous les problemes de nat. -pjsip show endpoints -rtp set logger on (tu peux vois l'ip sur laquelle les packets rtp sont envoyes) -pjsip set logger on (si tu utilised pjsip, je le trouve beaucoup plus stable et simple que chan_sip) et tu peux regarder si tu vois quel est le probleme Bon courage vincent On 3/17/20 9:04 AM, pisrateurb...@free.fr wrote: > Bonjour à tous, > > > On mixte du softphone (Zoiper) et du téléphone IP depuis 15 ans en IPsec/VPN > SSL,anciennement MPLS sur du Asterix/Xivo/Mitel et anciennement Ericson sur > des réseaux internes pas RFC 1918 (quelle idée mais c'est historique) > Au tout début j'ai eu des problèmes d'implémentations à cause du NAT et/ou > des ACL, parfois parce qu'il n'y a pas que du 5060 mais du 5061 ou parce que > les communications coupaient au bout de 15 minutes à cause du routeur > central. Depuis qu'on a éliminé le NAT je n'ai plus ce soucis, SAUF lors > d'une expérimentions en TSE multi-utilisateur avec 1 IP par utilisateur. > Petite précision, pas besoin d'utiliser de STUN ou de proxy NAT SBC. > > Ah si, j'ai encore un site avec passerelle externe et NAT qui me fait des > communications blanches sur certains SDA et opérateurs. > > > @+ > > Clément > > > ----- Mail original ----- > De: "Guillaume LUCAS" <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/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
