Conversations est sûrement le client XMPP pour Android le plus abouti.
Sa version 2.8 apporte les appels audio et vidéo en 1v1.
Client
Pour l’utilisateur, c’est très simple, une icône de combiné téléphonique a été rajoutée en haut de l’écran. Quand on clique dessus, un menu propose au choix l’appel audio ou vidéo.
Les appels sont chiffrés de bout en bout en utilisant DTLS-SRTP (comme webRTC) et utilisent Jingle pour initier la communication.
De mes tests personnels, la qualité des appels vidéo est bonne. La latence est faible, l’annulation d’echo est performante et permet de parler avec le smartphone au bout du bras.
Par contre en appel vidéo, le téléphone chauffe beaucoup par conséquence l’autonomie diminue grandement. Je ne sais pas si c’est le cas sur d’autres applications d’appel vidéo vu que je n’en utilisais pas avant.
Le gros avantage de Conversations(XMPP), par rapport à Riot(Matrix) c’est qu’il consomme beaucoup moins de batterie en arrière plan et que les notifications sont instantanées sans reposer sur les services Google (Google Push qui nécessite l’installation de Google Play services (propriétaire) avec des permissions étendues et le consentement à la collecte de données par Google)
Par rapport à SIP. tout dépend si on le compare au service Linphone LIME qui peut être chiffré de bout en bout comme ici ou le service OVH où tout passe en clair de bout en bout.
Je ne connais pas d’autres client compatible avec les appels de Conversations pour l’instant.
Serveur
Coté serveur, j’utilise Prosody comme serveur XMPP sur une machine derrière un routeur faisant office de NAT et pare-feu.
Pour une connexion entre 2 clients qui seraient sur le même LAN, il n’y a rien à faire coté serveur.
Mais en pratique, il n’est pas rare que les 2 clients se trouvent derrière des pare-feu interdisant les connexions entrantes. Pour résoudre ce cas, il faut mettre en place un relai de communication sur le serveur.
Pour cela, on va installer un service TURN avec le programme coturn.
Sur Debian :
# apt install coturn
On édite le fichier /etc/turnserver.conf:
use-auth-secret static-auth-secret=monsecret no-tcp external-ip=mondomain.com realm=mondomain.com
« mondomain.com » correspond au nom de domaine qui permet de joindre le serveur coturn par Internet.
« monsecret » est un mot de passe aléatoire qui permettra de réserver l’usage de ce relai TURN à votre service prosody.
Pour le démarrer, dans le fichier /etc/default/coturn, on active « TURNSERVER_ENABLED=1 »
Puis on lance le service :
# systemctl enable coturn # systemctl start coturn
Le port du serveur à exposer sur Internet est le 3478 UDP.
Dans Prosody, vous devez activer le module mod_turncredentials. Pour y avoir accès sur Debian Buster, j’ai du installer le paquet des backports.
# apt install prosody-modules -t buster-backports
Dans le fichier de config Prosody /etc/prosody/prosody.cfg.lua vous devez ajouter au modules activés :
"turncredentials";
Puis avant les VitualHosts définir (notez les guillemets en plus par rapport à la config coturn):
turncredentials_host="mondomain.com" turncredentials_secret="monsecret"
Redémarrer prosody et voila !
Si vous administrez un serveur XMPP, je vous invite à utiliser l’outil de « compliance » de Conversations qui peut vous renseigner sur les XEP qu’il vous serait utile de supporter pour avoir une bonne expérience client.
Remerciements
Le développement de cette fonctionnalité a été possible grâce au financement de NLnet
Vous pouvez donner de l’argent au developpeur principal Daniel Gultsh par LiberaPay
Hello,
Tout d’abord merci pour tes posts que je lis depuis longtemps via RSS.
Tu dis “Le gros avantage de Conversations(XMPP), par rapport à Riot(Matrix) c’est qu’il consomme beaucoup moins de batterie en arrière plan et que les notifications sont instantanées sans reposer sur les services Google (Google Push qui nécessite l’installation de Google Play services (propriétaire) avec des permissions étendues et le consentement à la collecte de données par Google) »
Mais la version de Riot(Matrix) diffusée par FDroid n’utilise pas les GCM et permet d’ajuster la synchro :
“Note that the F-Droid release does not use GCM for notifications – instead it will keep syncing in the background. If you find that the ongoing background sync is using too much battery, you can add a delay or change the timeout of the sync or even disable background sync completely, in the settings page. »
Dans cette configuration je suppose que les deux applications consomment autant de batterie, non ? Soit le tel est en veille et aucune des deux ne consomment (ni ne reçoivent) soit le tel est actif et si le délai entre deux synchros est le même dans les deux applis, je suppose que le delta est uniquement lié à la quantité de données ?
Je ne connais pas bien l’implémentation de XMPP. Peut être que ça maintient une connexion au lieu de faire des synchros à intervalles réguliers ?
Merci d’avance pour ton retour.
Et continue le partage de qualité 👍
Michael B : Bonjour, le principe même de XMPP est de maintenir une connection tcp de manière à limiter l’activité (XEP 0198)
Plus d’informations ici https://gultsch.de/xmpp_2016.html
Merci neox pour la réponse !