Linphone 3.8 est sorti

Posté par  (site web personnel) . Édité par bagage, margrox, ZeroHeure, Sylvain Berfini, BAud, Florent Zara, Nicolas Boulay et lunacymaze. Modéré par rootix. Licence CC By‑SA.
Étiquettes : aucune
42
13
mar.
2015
Audiovisuel

Une nouvelle version de Linphone, un logiciel de voix sur IP SIP sous licence GPL, vient de sortir pour GNU/Linux, Windows et Mac OS X. Cette nouvelle version est numérotée 3.8.0 et porte le nom de code "Pablo".

logo linphone

Depuis la précédente version 3.7.0 sortie il y a quasiment 1 an, cette nouvelle version inclut plus de 1757 nouveaux commits.
Linphone 3.8 est disponible sous forme d'archive compressée ainsi que sous forme binaire pour les versions Windows et Mac.

Il y a beaucoup de changements, principalement dans la bibliothèque Liblinphone avec des nouveautés sur la qualité audio et vidéo, ainsi que sur le chiffrement des communications. L'écosystème a aussi un peu grandi, avec l'arrivée d'une version Windows Phone 8 et d'un wrapper Python. Voyez donc en suite de dépêche !

Nouveautés de cette version 3.8 nommée "Pablo" :

  • prise en charge de RTP / AVPF (RFC 4585) avec le codec VP8 : la fonctionnalité permet de récupérer des erreurs de transmission en redemandant certaines parties de l'image à décoder (au lieu de toute l'image) — cela permet de grandement améliorer la qualité vidéo sur des connexions à forte pertes ;
  • mode plein écran en appel vidéo, avec une incrustation du bouton pour raccrocher ;
  • un outil de configuration pour les paramètres audio (micro, haut parleurs) ;
  • mise à jour des traductions et ajout d'une nouvelle langue : l'arabe (grâce à l'excellent outil de traduction Transifex) ;
  • nous sommes passés sur notre propre implémentation du chiffrement ZRTP : BZRTP, qui gère maintenant AES sur 256bits ;
  • il est possible de choisir le type de transport de chaque compte SIP ; auparavant, un seul transport était appliqué à tous.

Les dépendances de Linphone ont aussi été mises à jour, et ont droit à une nouvelle version:

Quelques prises d'écran:

ecran principal

chat

appel vidéo

Quelques nouvelles autour de Linphone

Module Python

Un module Python sous licence GPLv2 permet d'interfacer toute la bibliothèque Linphone via une API objet. Cela permet de réaliser très rapidement des prototypes fonctionnels de communication audio et vidéo.
Une version dédiée pour Raspberry Pi est aussi maintenue, et un exemple basique d'application est fourni dans le wiki officiel.

Pour plus de détails, voir les liens suivants :

Enregistrement des communications et diffusion d'enregistrements, disponible en version expérimentale

Il est maintenant possible d'enregistrer les appels audio et vidéo, via la bibliothèque Matroska. Cette fonctionnalité est encore expérimentale, car elle nécessite une version récente de la bibliothèque, qui n'est pas empaquetée par toutes les distributions.
Grâce à cette même bibliothèque, il est possible de remplacer les flux audio et vidéo par un fichier local MKV. Cela permet de diffuser cette vidéo à votre correspondant en direct, en faisant glisser le fichier sur la fenêtre d'appel.

Pour plus d'informations, il faudra étudier le README de Linphone.

Miroirs sur GitHub

L'ensemble du code source de Linphone est désormais disponible sur GitHub. Nos dépôt officiels restent hébergés chez nous, mais les fonctionnalités d'exploration du code et de visualisation des modifications fournies par GitHub sont très appréciables.
Nous restons tout de même fidèles à nos mailing lists pour les demandes de patch et les discussions.

Linphone arrive sur Windows Phone 8

Même si cela n'est pas directement lié à Linux, Linphone est désormais disponible sur Windows Phone 8 sous licence GPL2. Celle version vient compléter la liste des plateformes mobiles supportées, après les versions Android et iOS.
Le code source se trouve sur le site officiel.

Conclusion

Après plus de 14 ans de service, Linphone continue son chemin dans le marché des logiciels de voix sur IP. Même si de plus en plus de plateformes sont supportées, la version Linux n'est pour autant pas délaissée et continue d'être développée.
Par ailleurs, la version 3.8.0 n'est définitivement pas la dernière, et de nouvelles fonctionnalités continuent d'être implémentées tant ce domaine est vaste !

Aller plus loin

  • # La version Linux n'est pour autant pas délaissée et continue d'être développée

    Posté par  . Évalué à 9. Dernière modification le 13 mars 2015 à 22:44.

    Heureusement!Ça serait ballot pour une application dont le nom est la contraction du mot Linux et du mot téléphone.

  • # Réémission

    Posté par  (site web personnel) . Évalué à 4.

    prise en charge de RTP / AVPF (RFC 4585) avec le codec VP8 : la fonctionnalité permet de récupérer des erreurs de transmission en redemandant certaines parties de l'image à décoder (au lieu de toute l'image) — cela permet de grandement améliorer la qualité vidéo sur des connexions à forte pertes ;

    Pas compris : de ce que je connais de la visio, il y a déjà un petit lag dû à IP genre 50 ms (ADSL-Core-ADSL, un seul sens car pas besoin de retour pour la vidéo/audio), et on affiche aussi tôt que possible l'image, puis pareil pour l'image suivant 30 ou 60 ms après (30 fps ou 15 fps). Une demeande de réémission va prendre 50 ms à envoyer à l'émetteur puis 50 ms pour transmettre de nouveau, on se retrouve donc avec des données en retard d'1 ou 2 images, images dont on a plus besoin (plus affichée).

    Du coup je me demande où je me plante dans l' "algo" qui fait que la réémission est utile.

    • [^] # Re: Réémission

      Posté par  . Évalué à 8.

      Les I-frame (images complètes) sont assez espacées dans le temps en VoIP.
      Donc avant si tu avais une erreur dans le flux il y avait 2 options : demander une nouvelle I-frame (au prix d'une bande passante plus élevée) ou ne rien faire (image dégradée).
      Je suppose que ça permet de demander une I-frame "partielle" qui permet de corriger l'erreur sans faire exploser la bande passante utilisée.

  • # transport pour SIP

    Posté par  . Évalué à 2.

    Merci pour ces infos.

    il est possible de choisir le type de transport de chaque compte SIP ; auparavant, un seul transport était appliqué à tous.

    C'était pas déjà sorti dans la version 3.7, ça ? Y a eu une amélioration depuis la 3.7 ?

    Ce qui est dommage, c'est que sur debian, on en est toujours á la version 3.6.1, même sous sid ou experimental, et que cette option m'intéresse au plus haut point (j'utilise en même temps le SIP classique pour la téléphonie, et le SIP - TLS pour ostel.co en substitution de skype). Mes tentatives de compil de la 3.7 se sont soldées par un échec.

    • [^] # Re: transport pour SIP

      Posté par  (site web personnel) . Évalué à 2.

      Argh dommage que ça ne passe pas si bien chez toi la compilation.
      Essaye toujours avec cette version, en lisant le README ça devrait passer.

      Pour ce qui est des comptes SIP, je ne me souviens plus, mais je crois qu'il n'était pas possible de facilement gérer le transport.

  • # blackberry 10 ?

    Posté par  . Évalué à 1.

    bonjour, le sdk liblinphone est valable apparemment pour bb10, est-ce qu'un client natif pour bb10 est en dev ?

  • # Bruit ?

    Posté par  . Évalué à 5.

    Pour l’instant, j’ai été extrêmement déçu de tous les client SIP que j’ai testé sous Linux : Empathy qui ne fonctionne tout simplement pas (j’ai sorti Wireshark, et il envoie des paquets SIP malformés…), Jitsi très mal intégré avec PulseAudio (le son au maximum à tous les nouveaux appels, ce qui fait très très mal aux oreilles)…

    Et tous ont un énorme défaut : un très très très mauvais filtre anti-bruit. Voire inexistant, j’ai pas regardé le code. J’ai beau avoir un casque-micro, tous mes correspondants se plaignent du bruit de fond. Viber filtre le bruit corrrectement. Teamspeak filtre le bruit correctement. Mon téléphone SIP filtre le bruit correctement. Je n’ai par contre trouvé aucun client SIP libre qui filtre le bruit correctement.

    Pour ceux qui ont testé : est-ce que ça vaut le coup de tenter Linphone ? Ou aurait eu le même problème et trouvé une autre solution satisfaisante ?

    • [^] # Re: Bruit ?

      Posté par  . Évalué à 2.

      Pour ce que j'ai testé sur PC et mobile, la qualité était top. Je n'ai pas eu de problème particulier vis-à-vis du bruit donc je ne peux pas te dire. En tout cas l'interface est vraiment très agréable. Dommage qu'il fasse tellement chauffer le CPU de mon smartphone ceci dit, il me vide la batterie assez rapidement.

    • [^] # Re: Bruit ?

      Posté par  . Évalué à 1.

      Pour ceux qui ont testé : est-ce que ça vaut le coup de tenter Linphone ? Ou aurait eu le même problème et trouvé une autre solution satisfaisante ?

      Twinkle est bien, il moins lourd que linphone, et la qualité est ok. Malheureusement, il ne semble plus être développé. Pour pouvoir l'installer sur debian j'ai dû chercher les dépendances sur lenny (mais ça marche, pas de conflit avec le système actuel)

      Linphone est bien aussi, mais bien plus lourd, et j'ai actuellement un problème de son (j'entends mais mon interlocuteur ne m'entend pas) avec le transport UDP, mais pas avec le transport TLS, je me demande si ça ne vient pas du NAT derrière lequel je suis. Ce que je ne comprends pas est que rien (ni ma config ni, apparemment celle du NAT de mon FAI) n'a changé. Je précise que je suis encore en 3.6.1, c'est la version qui est fournie dans les dépôt debian.

      Tu peux tenter de jouer avec les codecs, le G726-32 me donne des bons résultats pour linphone et pour twinkle.

      • [^] # Re: Bruit ?

        Posté par  (site web personnel) . Évalué à 2.

        Ton problème de son est très certainement dû au FAI qui filtre les paquets RTP, tu serais pas chez Bouygues par hasard?

        • [^] # Re: Bruit ?

          Posté par  . Évalué à 1.

          Merci pour ta réponse.
          Non je ne suis pas chez Bouygues, ni en France. Mon FAI est un petit fournisseur par radio, et il a un NAT assez sévère, Mais comme twinkle passe, avec les mêmes ports RTP (8000), je ne comprends pas bien. D'autant plus que linphone marchait bien il y a peu. J'ai mis les mêmes réglages de ports et de traversial NAT póur twinklle et pour linphone, mais rien à faire (ni avec STUN, ni direct connection, ni fixed IP). Je ne peux d'ailleurs pas faire du SIP à SIP, il faut que je passe dans ce cas par ostel.co, que je conseille d'ailleurs pour passer les NAT et FW, ça vaut bien skype en ce sens, et marche bien avec linphone.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.