Des nouvelles de Linphone (VoIP)

Posté par  . Modéré par j.
Étiquettes :
19
14
fév.
2011
Mobile
Linphone est un logiciel de téléphonie sur IP utilisant le protocole standard et ouvert SIP. Il est publié sous la licence libre GPLv2+ et s'utilise avec n'importe quel compte SIP (freephonie.net, ekiga.net, sip.linphone.org...).

Sous GNU/Linux, linphone se présente sous quatre formes :
  • L'application graphique Linphone, utilisant GTK ;

  • La bibliothèque liblinphone, écrite en C ;

  • L'application console linphonec ;

  • L'application console linphonecsh, pour scripter.

Aujourd'hui, quatre événements majeurs à annoncer :
  • La sortie de la version 3.4.0 pour GNU/Linux, Windows et Mac ;

  • L'ajout de la vidéo à la version Android (sdk >=2.0 requis) ;

  • La sortie d'une version Blackberry (Bold OS >= 5.0 requis) ;

  • Le lancement en version bêta d'un serveur "registrar" : sip.linphone.org.
Créé il y a 10 ans par Simon Morlat, le projet évolue vite depuis quelques années. Les développements sont soutenus par la toute récente société Belledonne Communications, qui finance notamment l'ajout de nouvelles fonctionnalités. Vous pouvez remonter les éventuels bogues ici-même ou sur la liste de diffusion. Un logiciel multiplateforme

Le cœur de Linphone est implémenté dans la bibliothèque multiplateforme liblinphone, écrite en C. Toutes les versions de Linphone utilisent cette bibliothèque, hormis le port Blackberry qui a nécessité une réécriture en Java.

Vous pouvez utiliser Linphone sur :
  • GNU/Linux (audio, vidéo) ;
  • Windows (audio, vidéo) ;
  • Mac (audio, via macports) ;
  • Android (audio, vidéo) ;
  • iPhone (audio) ;
  • Blackberry (audio, codec AMR) ;
  • Windows CE (audio, console).
Il semblerait que Linphone tourne également sur Freerunner, Nokia/Maemo et BSD.

Pour comprendre l'architecture de Linphone je vous invite à lire la documentation développeur. Les bibliothèques mediastreamer2 et oRTP ont également été créées par Simon Morlat.

Registrar sip.linphone.org

Avec le protocole standard et ouvert SIP, il est possible de contacter un utilisateur :
  • Directement de pair à pair : "sip:destinataire@192.168.0.1" ;
  • Via un registrar : "sip:destinataire@sip.linphone.org".
Il est bien sûr possible de contacter un utilisateur enregistré sur un autre serveur SIP.

Vous pouvez créer un compte sur linphone.org. Le serveur gère l'authentification "http digest", votre mot de passe ne passera pas en clair sur le réseau.

L'enregistrement multiple n'étant pas encore géré, seul le dernier agent utilisateur enregistré sonnera en cas d'appel. En effet, le protocole SIP permet de s'enregistrer plusieurs fois; lors d'un appel entrant, tous les appareils vont alors sonner et le premier à décrocher reçoit l'appel. Le service est en version beta.

Client GNU/Linux
La version GNU/Linux est la plus ancienne et remonte à 2001. La dernière version est la 3.4.0.

Les codecs pris en charge sont :
  • Audio : speex (dont large bande), GSM, PCMU/PCMA, AMR, iLbc ;
  • Vidéo : theora, mpeg4, snow, h263, h264.
Certains via des modules à compiler à partir du git linphone.org.

Parmi les fonctionnalités principales, on retrouve :
  • Multiples comptes ;
  • Mise en attente d'appels, reprise ;
  • IPv6 ;
  • STUN ;
  • Authentification DIGEST (votre mot de passe ne transite pas en clair sur le réseau) ;
  • Annulateur d'écho performant (votre correspondant n'entend pas sa voix).
Parmi les nouveautés :
  • Appels multiples ;
  • Étalonnage automatique de l'annulateur d'écho ;
  • Optimisations.
Client Android

Ce portage existe depuis mars 2010. La vidéo nécessite une version "récente" d'Android (sdk >= 2.0). Idéalement, un sdk supérieur à 2.2.

Les codecs pris en charge sont :
  • Audio : speex WB, speex NB, gsm, pcmu/pcma, iLbc ;
  • Vidéo : mpeg4, h264.
Il est possible de changer de caméra à la volée. Cette fonctionnalité a été testée sur Galaxy S (que je ne vous conseille pas), qui possède une caméra frontale et une à l'arrière. La plate-forme Android est très hétérogène donc de nombreux bogues peuvent subsister.

Aller plus loin

  • # HTTP Digest

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

    Le serveur gère l'authentification "http digest", votre mot de passe ne passera pas en clair sur le réseau.

    Authentification DIGEST (votre mot de passe ne transite pas en clair sur le réseau) ;

    … mais est stocké en clair sur le serveur. Avant qu'on ne me le rétorque, oui, je sais, pas la peine de stocker vraiment le message en clair, le hachage HA1 (oui, HA1, ce n'est pas un algorithme mais un nom de variable dans le protocole HTTP Digest) suffit, sauf que ce hachage HA1 suffit à se connecter, donc il remplace le mot de passe, donc le stocker en clair sur le serveur c'est comme stocker le mot de passe en clair, si quelqu'un récupère le fichier de mot de passe il peut se connecter. Donc je maintiens, le vrai mot de passe, c'est à dire ce qui suffit à se connecter, c'est à dire HA1, est stocké en clair sur le serveur.

    Tout ça parce que l'équipe SIP à l'IETF a cru intelligent de déprécier HTTP Basic parce que « le mot de passe transite en clair sur le réseau et que c'est très mal », ce qui est vrai, sauf que SSL.

    HTTP Basic seul : le mot de passe transite en clair mais n'a pas à être stocké en clair sur le serveur.
    HTTP Basic + SSL = le mot de passe ne transite pas en clair et n'a pas à être stocké en clair sur le serveur.
    HTTP Digest = le mot de passe ne transite pas en clair mais doit être stocké en clair sur le serveur.
    • [^] # Re: HTTP Digest

      Posté par  . Évalué à 1.

      Les certificats SSL c'est pas terrible non plus, hein. Tu vois tout les battons dans les roues que c'est avec les navigateurs et le problème que pose les certificats autosignés.

      En plus avec les "rainbows tables" et la performances des attaques par dictionnaires, je ne doute pas que les mot de passe MD5 peuvent pour beaucoup de monde facilement se craquer en quelques jours. Dernière chose, dans quasiment tout les cas, les mots de passes ne servent pas à chiffrer les informations contenues sur le serveur, donc l'attaquant a accès à tout le contenu et toute les informations client. Ce qui n'est pas terrible.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: HTTP Digest

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

        Sous UNIX, la tradition est de mettre son grain de sel partout. Donc on n'utilise pas MD5 en pratique mais SMD5 qui est bien plus difficile d'attaquer par force brute !

        Ceci dis, cette technique est connu depuis ... plus de 30 ans mais les ingénieurs Microsoft ne l'ont toujours pas comprise ;-)

        OK, je -> []
        • [^] # Re: HTTP Digest

          Posté par  . Évalué à 2.

          Et tu empêche les utilisateurs de mettre un mot de passe de moins de 8 caractères en leur obligeant d'avoir une entropie superieur à une certaine valeur ?

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: HTTP Digest

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

            Moi, ce que j'adore, ce sont les services qui interdisent au contraire d'utiliser des caractères qui permettraient d'augmenter l'entropie.

            Autrement dit, qui forcent à avoir un mot de passe faible. Du coup j'ai plusieurs classes de mots de passes :
            – des mots de passes forts pour les services bien faits (avec des [:alnum:], des [.,;!:] et des [#&~*£$]) ;
            – des mots de passes faibles pour les services mal fichus (avec des [:lower:] uniquement) ;
            – un mot de passe merdique pour les services merdiques (avec quatre ou six [:digit:] uniquement).

            Et ce qui est amusant, c'est que le mot de passe merdique en question, il ne me sert en pratique que pour deux services merdiques, les seuls que je connaisse, ceux qui au contraire mériteraient la plus grande sécurisation : ma carte bleue et le service d'administration de mes comptes en banques.
            • [^] # Re: HTTP Digest

              Posté par  . Évalué à 5.

              Mais pour la carte bleue tu ne peux pas faire du brut force étant donné qu'après 3 essais elle se bloq
      • [^] # Re: HTTP Digest

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

        Il faudrait un bout de code javascript pour que les site web détectent les proxy menteurs. Il existe plein d'entreprises qui font des attaques MAM sur le ssl, il suffit que le client accepte une seul fois le nouveau certificat, voir que l'entreprise l'installe directement sur les postes clients.

        Le bout de javascript devrait avoir l'information du contenu du certificat ssl puis qu'il lise le certificat effectivement lu par SSL. Je ne sais pas si c'est possible, mais cela devient urgent avec l'augmentation de l'usage privé du web en entreprise (banque en ligne, facebook,...).

        "La première sécurité est la liberté"

        • [^] # Re: HTTP Digest

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

          Le mardi 15 février 2011 à 11:35 +0100, Nicolas Boulay a écrit :
          > il suffit que le client accepte une seul fois le nouveau certificat,

          ouais mais dans ce cas en affichant le certificat du site, l'utilisateur
          verra le certif de l'entreprise non ?

          • [^] # Re: HTTP Digest

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

            Oui, le problème sont les gens qui clic trop vite. Et une fois accepté, c'est très difficile de faire marche arrière, voir de s'apercevoir du problème.

            En gros, il faut un deuxième niveau de vérification.

            "La première sécurité est la liberté"

        • [^] # Re: HTTP Digest

          Posté par  . Évalué à 3.

          S'il y a un proxy menteur, il peut très bien virer ton bout de javascript, ou le réécrire.
          • [^] # Re: HTTP Digest

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

            Bien sûr. Sauf que c'est beaucoup plus facile de le faire génériquement sur un lien ssl que de le faire avec un bout de javascript, qui peut changer sur chaque site.

            "La première sécurité est la liberté"

        • [^] # Re: HTTP Digest

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

          Du moment où le logiciel est "tainted", tu ne peux rien faire : la chaîne de confiance nécessite que le bout de la chaîne soit de confiance. Ton script ne servira à rien, si on peu mettre un mauvais certificat dans le navigateur, on peut lui faire désactiver ton Javascript dès qu'il est connu, ce serait juste une mauvaise protection (qui fait croire que tu es protégé sans l'être).

          Bref, si tu n'as pas le contrôle de la machine, tu ne peux rien faire pour te protéger, quoique tu fasse l'admin peut faire les contre-mesure puisqu'il contrôle la machine.
          • [^] # Re: HTTP Digest

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

            Vous parlez dans l'absolu. Je parle de 80% des cas.

            L'admin ne contrôle pas vraiment le client. Il contrôle surtout le réseau. Et je vois mal un admin faire un proxy menteur pour chaque site web.

            "La première sécurité est la liberté"

            • [^] # Re: HTTP Digest

              Posté par  . Évalué à 2.

              D'autant plus qu'on peut imaginer que le serveur crée un script unique à chaque fois, un peu comme les virus polymorphes.
              'fin il existe pas mal de méthodes pour obfusquer du code, surtout avec le eval...
              • [^] # Re: HTTP Digest

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

                Tu peux aussi le faire en plusieurs étapes en récupérant un bout de la page déjà chargé. tTu peux aussi recoder un système d'échange de clef publique en javascript pour vérifier le certificat. Tu peux aussi juste envoyer le certificat présenter au serveur.

                "La première sécurité est la liberté"

        • [^] # Re: HTTP Digest

          Posté par  . Évalué à 8.

          il existe plein d'entreprises qui font des attaques MAM sur le ssl

          C'est quoi une attaque MAM ? Tu leur envoies le jet privé d'un dictateur ?

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

    • [^] # Re: HTTP Digest

      Posté par  . Évalué à 2.

      Tout ça parce que l'équipe SIP à l'IETF a cru intelligent de déprécier HTTP Basic parce que « le mot de passe transite en clair sur le réseau et que c'est très mal », ce qui est vrai, sauf que SSL.

      SIP est certes possible sur TLS, sauf que SIP étant une grosse bouse, c'est pas sûr que beaucoup de gens s'attaquent à la combinaison des deux ;)
      (et il faut noter que dans son contexte d'utilisation - de longues sessions avec seulement quelques messages d'échangés -, SIP encourage plutôt le passage sur UDP que sur TCP)

      si quelqu'un récupère le fichier de mot de passe il peut se connecter

      Si quelqu'un récupère le fichier de mot de passe, il y a des chances qu'il ait accès à beaucoup d'autre choses aussi... et qu'il ait de toute façon déjà réussi à se connecter. Les fichiers de mot de passe ne se promènent pas de façon magique sur Internet quand on a le dos tourné.
      • [^] # Re: HTTP Digest

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

        Bon, alors on va passer à la critique suivante : grâce à ce HTTP Digest, impossible d'intégrer une identification SIP à un système existant et unique comme PAM ou LDAP.
        • [^] # Re: HTTP Digest

          Posté par  . Évalué à 2.

          On peut voir ça comme ça. Mais PAM / LDAP pourrait très bien intégrer la compatibilité Digest (qui n'est pas spécifique à HTTP, mais fait partie de la norme SASL).
  • # GTK+2

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

    Vous ne seriez pas passés en GTK+2 par hasard ? Parce que la dernière fois que j'avais essayé Linphone, c'était juste abominablement moche en GTK+1, or là ça a l'air joli et intégré.
    • [^] # Re: GTK+2

      Posté par  . Évalué à 8.

      Ca doit faire vraiment longtemps que tu n'as pas essayé linphone alors... L'interface graphique GTK a été refaite entièrement en 2006 je crois (en utilisant libglade). Il y aurait encore beaucoup de choses à améliorer dans cette interface: assistant de config audio, test call, affichage de l'intensité sonore, assistant de création de compte, intégration avec l'addressbook du système... Ne pouvant tout faire j'ai toujours choisi de privilégier la performance et la stabilité de la fonctionnalité de base à "l'enrobage", mais ça finira par venir, je l'espère.
      Merci pour ton commentaire sur la digest, c'est interressant. Le ha1 est un moindre mal, ça permet en cas d'accident d'éviter de rendre publique des user/passwd qui pourraient s'avérer fonctionner avec d'autres services si certains utilisateurs utilisent les mêmes identifiants pour leurs différents comptes (mail facebouc...).
      • [^] # Re: GTK+2

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

        Il est vrai que moi aussi je me rappelais de linphone l'an dernier sous Fedora pendant que j'étais en Espagne (super pratique) avec une interface vieillote. Du coup en lisant cela je me lance et c'est vrai que l'interface est déjà plus jolie.

        Par contre au premier démarrage il m'a indiqué avoir détecté de l'ipv6 sur mon système alors que tout est configuré en ipv4. Bug ou juste un message envoyé à tout le monde ?
        Your machine appears to be connected to an IPv6 network. By default linphone always uses IPv4. Please update your configuration if you want to use IPv6

        J'utilise NetworkManager sous gnome Fedora 14 avec ipv6 en ignore. Les ip6tables sont désactivées.
  • # SGS

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

    lapin compris :
    "Cette fonctionnalité a été testée sur Galaxy S (que je ne vous conseille pas)"

    C'est la fonctionnalité ou le smartphone que tu ne conseilles pas ?

    A part une autonomie de souris (12h), il me permet à ma geekattitude de s'exprimer complètement (flashage, frimwares, kernel mods, tuning, et même je peux téléphoner avec...)
    • [^] # Re: SGS

      Posté par  . Évalué à 2.

      Le tout sans windows?
      • [^] # Re: SGS

        Posté par  . Évalué à 2.

        Oui, normalement, avec heimdall tu peux t'en sortir (après dans la pratique je ne sais pas…).
    • [^] # Re: SGS

      Posté par  . Évalué à 2.

      Je parle bien du Galaxy S:

      La video est bizarre: la numérotation des caméras, une seule taille d'image supportée le reste étant redimensionné.

      L'audio est bogué: impossible de router le son vers le haut-parleur ou l'oreillette, boutons volume qui ne changent rien.

      Dans certains cas on peut blâmer l'API Android qui est franchement pas très propre dans la partie multimédia.
      Mais quand on voit les tonnes de logs que sort un Galaxy S on reste sur une impression de travail bâclé et pas fini.


      Au final, les applications de voip fonctionnent très mal.
      • [^] # Re: SGS

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

        quelle version d'android ?

        J'avoue que je n'ai pas testé tout ce que tu me dis mais me ferais un plaisir de faire des essais.

        j'ai une oreillette bloutouche qui marche...

        (je suis sous froyo 2.2.1)
        • [^] # Re: SGS

          Posté par  . Évalué à 2.

          Il s'agit de Froyo 2.2; et il faut lire écouteur à la place d'oreillette.

          Si tu veux tester, tu peux installer un linphone sur ton PC et un sur ton SGS.
          Ensuite :
          - appelle de SGS vers ton PC (tu peux mettre l'IP): l'audio devrait être correct.
          - appelle maintenant du PC vers le SGS: l'audio devrait sortir par le speaker au lieu de sortir par l'écouteur. Ce qui n'est pas bon.


          Il faudrait que je prenne le temps d'isoler le problème du speaker dans un projet simple, à part.
          Le problème vient peut être d'une mauvaise interaction entre l'audio de la sonnerie (haut parleur) et l'audio de l'appel (écouteur).
  • # .

    Posté par  . Évalué à 2.

    Pourquoi les codec vidéo sont disponible que sur arm7 sur android ?
    Pas mal de hard ont un accéléreration hardware


    La nouvelle api de androïd propose une stack sip. De multiples clients sip devrait voir le jour
    • [^] # Re: accélération matérielle

      Posté par  . Évalué à 2.

      Nous faisons tout le codage/décodage en logiciel.

      En effet, il n'y a pas d'API pour utiliser directement les codecs matériel.
      Android fournit une API pour lire et écrire des fichiers, mais après il faudrait parser le fichier ce qui introduit de la latence et qui n'est pas si simple.

      Donc nous limitons à l'architecture ARMv7 pour laquelle il existe des codecs logiciels optimisés et performants.
  • # Tu mens !!! ;-)

    Posté par  (Mastodon) . Évalué à 3.

    > et s'utilise avec n'importe quel compte SIP

    Mon téléphone fixe fourni par Orange est un téléphone SIP (sur abo fibre premium, c'est du sip). Et pourtant je ne peux pas utiliser LinPhone en remplacement logiciel, qui me permettrait de déporter plus facilement dans l'appartement la fonction téléphonie de mon abonnement.

    Il y a le téléphone sip, et le téléphone sip par Orange.
  • # Proxy SOCKS

    Posté par  . Évalué à 1.

    Il n'y a pas de support de proxy ni proxy SOCKS ? Dommage, c'est pratique pour passer les firewall du boulot.
    Est-ce que cela sera implémenté prochainement ?
    • [^] # Re: Proxy SOCKS

      Posté par  . Évalué à 1.

      Personne ne sait ? Ou suis-je le seul à souhaiter cette fonctionnalité ?
  • # Depot libre andoird

    Posté par  . Évalué à 2.

    Si votre appli Android est sous licence libre vous pourriez la soumettre au dépot regroupant les logiciels libres http://f-droid.org/repository/submit/
  • # WebOS

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

    Il y a aussi un portage en cours sur HP WebOS (linux) par l'équipe de WebOS internals...

    http://forums.precentral.net/webos-internals/274615-linphone-alpha-testing.html

Suivre le flux des commentaires

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