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/
