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.
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).
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".
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.
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).
- Appels multiples ;
- Étalonnage automatique de l'annulateur d'écho ;
- Optimisations.
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.
Aller plus loin
- Linphone (296 clics)
- Téléchargement (134 clics)
- Serveur registrar sip.linphone.org (116 clics)
- Belledonne Communications (35 clics)
- Listes de diffusion (37 clics)
# HTTP Digest
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 6.
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 barmic . Évalué à 1.
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 Sytoka Modon (site web personnel) . Évalué à 2.
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 barmic . Évalué à 2.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
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 Grégory CLEMENT . Évalué à 5.
[^] # Re: HTTP Digest
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
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 Juke (site web personnel) . Évalué à 1.
> 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 Nicolas Boulay (site web personnel) . Évalué à 2.
En gros, il faut un deuxième niveau de vérification.
"La première sécurité est la liberté"
[^] # Re: HTTP Digest
Posté par Antoine . Évalué à 3.
[^] # Re: HTTP Digest
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: HTTP Digest
Posté par Zenitram (site web personnel) . Évalué à 2.
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 Nicolas Boulay (site web personnel) . Évalué à 3.
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 daimrod . Évalué à 2.
'fin il existe pas mal de méthodes pour obfusquer du code, surtout avec le eval...
[^] # Re: HTTP Digest
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: HTTP Digest
Posté par zebra3 . Évalué à 8.
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 Antoine . Évalué à 2.
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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 2.
[^] # Re: HTTP Digest
Posté par Antoine . Évalué à 2.
# GTK+2
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
[^] # Re: GTK+2
Posté par smorlat . Évalué à 8.
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 MarbolanGos (site web personnel) . Évalué à 1.
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 djibb (site web personnel) . Évalué à 5.
"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 eon2004 . Évalué à 2.
[^] # Re: SGS
Posté par Victor . Évalué à 2.
[^] # Re: SGS
Posté par guillaume_bc . Évalué à 2.
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 djibb (site web personnel) . Évalué à 2.
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 guillaume_bc . Évalué à 2.
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 M . Évalué à 2.
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 guillaume_bc . Évalué à 2.
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 bubar🦥 (Mastodon) . Évalué à 3.
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 tipmeabout . Évalué à 1.
Est-ce que cela sera implémenté prochainement ?
[^] # Re: Proxy SOCKS
Posté par tipmeabout . Évalué à 1.
# Depot libre andoird
Posté par eon2004 . Évalué à 2.
# WebOS
Posté par Puyb (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.