Je vois, sur ce site, pas mal d'interrogations sur l'évolution de XMPP, de critiques, et de dénigrement. Je pense donc qu'il peut être utile de donner de temps en temps des petites nouvelles sur ce qu'il se passe en interne.
Sommaire
Évènements Fédératifs
Il y a dernièrement eu deux évènements impliquant de grands noms de la messagerie propriétaire.
Skype
Celui qui a plus fait parler est le soi-disant support de XMPP dans Skype qui apparaît dans la prochaine bêta Windows. Mais alors que la source originelle (Skype Journal) laisse entendre que le réseau Skype est quasiment prêt à se connecter au réseau standard…
So, now that Skype has XMPP for polling/updating servers, it looks like Skype is almost ready to connect the Skype network to other IM networks.
… si — en suivant les liens — on se réfère à la note de version du produit, il me semble plus comprendre que, simplement, le client Skype est devenu multi-protocole pour suivre la tendance Facebook. Alors, si le client a effectivement intégré du code XMPP (puisque c'est le protocole utilisé par Facebook), ce code n'est que côté client d'une part (il n'y a donc, d'annoncé officiellement par Microsoft Skype en tous cas, actuellement aucune interconnexion possible avec la Fédération IM), d'autre part ils l'ont vraisemblablement bridé pour se connecter au serveur Facebook. Notez que je n'ai pas testé, déjà simplement parce que je n'ai pas de Windows. Mais la note de version ne semble vraiment rien dire d'autre que cela. Cela n'a donc simplement aucun intérêt pour moi: c'est du vent (au passage, qui montre la volonté de Microsoft de surfer sur la vague Facebook, donc d'accepter leur assise dans le monde du « réseau sociale »), comme tout ce qui touche ce monstre Facebook.
On note aussi le niveau d'information de ce "journaliste" du Skype Journal qui écrit que XMPP est le protocole utilisé par Yahoo! et Microsoft Live Messenger (pour ceux qui prennent l'information comme une grande nouvelle, je précise: c'est simplement faux) ou que c'est aussi le cas de la plupart des réseaux Jabber (il n'a donc apparemment pas compris que Jabber n'est qu'un synonyme historique de XMPP. Je sens les trolls venir sur le nom, mais sachez que je n'y répondrai plus).
AOL
Et là, si vous êtes perspicace, vous aurez remarqué que ce journaliste citait aussi AIM dans sa liste d'utilisateurs de XMPP mais que je ne l'ai pas relevé avec les deux autres. Car oui, là c'est le second évènement, et personnellement je l'ai trouvé beaucoup plus excitant. Pourtant à l'inverse celui-ci fut plutôt dénigré. Au contraire, je pense qu'il aurait été très intéressant que cet évènement fasse parler de lui car il était important qu'AOL voit que la communauté mondiale accueille leur avancée vers l'ouverture à bras ouverts, pour les y encourager.Mais j'écris, j'écris… donc: AIM s'est rendu accessible par XMPP!
Bon passé le marketing à moitié vrai-faux, je refroidis les grosses joies.
- Il ne s'agit que d'un s2s (serveur à serveur), ce qui signifie qu'en "interne" dans le réseau AIM, les communications sont pour l'instant toujours dans leur protocole propriétaire, mais dès qu'on sort du réseau interne, les communications sont converties en XMPP. Personnellement je n'estime pas cela extrêmement ennuyeux, du moment qu'on peut contacter des utilisateurs AIM (et qu'eux peuvent nous contacter) sans avoir à créer de compte sur leur réseau privé. C'est de la vraie intéropérabilité. Je pense aussi qu'avec le temps, ils verront qu'ils ne peuvent tenir sur les deux fronts à la fois, maintenant constamment un protocole privé et un convertisseur vers le protocole standard. Mais c'est peut-être vœu pieu. On sait que les entreprises ne se rendent pas toujours compte de leur inefficacité rapidement.
- Mais surtout dans les faits, ce n'est qu'un accord commercial entre Google et AOL (aussi annoncé ici, le jour de l'Open Discussion Day, soit le 19 mai, pas mal comme coincidence!) pour l'instant. C'est à dire que seul les utilisateurs de gtalk peuvent parler aux utilisateurs AIM.
Et là vous vous dites "quelle escroquerie!". Mais là où l'espoir reste très bon est qu'il s'agit vraiment d'un serveur XMPP passerelle chez AOL. Gtalk et AIM ne communique pas par un protocole propriétaire tiers.
bash
$ telnet xmpp.gxmpp.oscar.aol.com 5269
[j'envoie]
xml
<?xml version='1.0'?>
<stream:stream
from='zemarmot.net'
to='aol.com'
version='1.0'
xml:lang='en'
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'>
[je reçois]
xml
<?xml version='1.0' encoding='UTF-8'?> <stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:server' from='aol.com' id='4c672fc9' version='1.0'><stream:error><undefined-condition xmlns='urn:ietf:params:xml:ns:xmpp-streams'/></stream:error></stream:stream>
Je suis rejeté simplement parce que je ne suis pas Google, mais il y a bien un serveur XMPP chez AOL. Aussi des enregistrements DNS de service XMPP ont été enregistrés. Si le but était uniquement de se contenter d'un accord Google-AIM, il n'y aurait aucune raison de diffuser des enregistrements DNS publics:
$ ring -t SRV _xmpp-server._tcp.aol.com
aol.com. has a xmpp-server service record on tcp:
priority = 0
weight = 1
port = 5269
target = xmpp.gxmpp.oscar.aol.com.Apparemment les Google Apps ne sont pas encore supportés (d'après la documentation, mais j'ai remarqué que certaines documentations de service Google ne sont pas à jour, donc… à tester) mais ils disent "travailler pour que ce le soit". Et puisque les Google Apps sont n'importe quel nom de domaine, le jour où ce sera fait, ce sera peut-être parce qu'AIM sera totalement ouvert! En tous cas, pour l'instant, je ne connais aucun autre serveur qui a un tel accord avec AIM, mais AOL a une courte page indiquant que cela peut être possible, et où ils disent surtout que "l'utilisation de la passerelle est actuellement limitée à des partenaires spécifiques" (traduction libre, et emphase de ma part).
Rappelons enfin que Google non plus n'avaient pas ouverts leurs propres serveurs avant 6 mois en réseau clos, et surtout que AIM a un historique très favorable. Souvenez-vous, ce début 2008 où fut découvert par hasard un serveur XMPP de test que AOL faisait tourner. Ce serveur permettait aux utilisateurs de AIM de se connecter à leur compte AIM en utilisant des clients Jabber génériques. Ce serveur de test n'existe plus à ma connaissance (en tous cas, plus à la même adresse), mais cela augure un travail en cours dans le sens de l'ouverture (comme l'indique ce message du Lead Architect AOL à l'époque). Et surtout c'est donc la preuve d'une implémentation c2s (client à serveur) existante quelque part chez AOL!
Je vois bien plus de chance de voir AIM devenir la prochaine grosse addition à la fédération (tout est techniquement déjà là, ils n'ont qu'à faire sauter la liste blanche qui limite la connexion avec les serveurs google et c'est bon, ils sont fédérés). Mais forcément, comme certains nous le rappellent, c'est un réseau moribond (qui fut pourtant à une époque le plus gros réseau propriétaire) et donc n'intéresse plus personne. Mais moi — je suis peut-être le seul — je dis: AOL, si vous me lisez dans ce coin perdu de l'internet francophone, continuez sur cette voie!
Jingle
Passons à tout autre chose. La fonctionnalité la plus attendue par les utilisateurs à l'heure actuelle, c'est Jingle! J'entends par là en particulier la Voix et Vidéo, et ce, fonctionnant presque dans tous les cas. Donc où en est-on? Je lis de ci de là des approximations, donc voici les dernières news à peu près vraies.
L'implémentation numéro 1: Google
Voix et Vidéo
Numéro 1 en âge et en utilisation en effet, puisqu'il s'agit de l'implémentation d'origine. J'ai lu beaucoup de bêtises sur Google qui ne voulait pas se mettre à jour, sur l'existence de plusieurs spécifications, etc. Bon pour finir toute polémique, pour ceux ne l'ayant pas lu dernièrement, Google a annoncé officiellement son support aux dernières spécifications Jingle (XEP-166 et XEP-167). Cette mise à jour concerne les appels par Gmail, iGoogle et Orkut, ainsi que la libjingle. Google Talk sur Android n'est pas encore mis à jour mais le sera bientôt, par contre ils ont annoncé qu'ils ne mettront pas à jour Google Talk Windows, poussant ainsi probablement dans le sens de leur politique actuelle "tout web" (en d'autres termes, le logiciel lourd sous Windows est mort).
Dans le même temps, ils conseillent aussi à tous ceux qui avaient intégré du code spécifique GoogleTalk dans leurs clients de le retirer et de passer à du code générique.
Pour le futur proche, leur travail en cours est sur ICE-UDP (XEP-0176) qui a pour but d'améliorer la traversée des NAT. Actuellement pour dialoguer avec les serveurs Google avec ce transport, il faut se baser sur le brouillon 6 de ICE d'après l'ingénieur Google (Peter Thatcher), bien qu'évidemment je ne le conseille pas. Voyons long terme, Google travaille dessus, on peut donc espérer une mise à jour des clients pas si lointaine. Donc toutes les implémentations XMPP, si vous ne l'avez pas déjà fait, implémentez la version finalisée de ICE (ou utilisez une librairie qui l'implémente): RFC-5245.
Transfert de Fichiers
Pour les fichiers de transfert, vous serez déçu, Google n'a pas encore leur support aux dernières spécifications dans ses plans. Ils utilisent encore une ancienne version expérimentale (utilisant aussi Jingle, comme la spécification conseillée de nos jours, mais différemment). Mais je ne doute pas que cela arrivera. Simplement ce n'est clairement pas leur priorité devant la voix et vidéo. Ou bien si leur solution s'avère bien meilleure, certains leur ont proposé de la mettre sur papier pour voir si le fichier de transfert par Jingle peut bénéficier davantage d'expérience Google (toujours pour traverser des NATs, mais cette fois en TCP, ou bien en UDP mais avec une couche de fiabilité).
En fait il y a actuellement plusieurs solutions possibles dans les implémentations de Google eux-même, d'après l'ingénieur Google que l'équipe prévoient de rajouter dans la libjingle un jour. Quoiqu'il en soit, on voit que le transfert de fichier a encore beaucoup de marge d'évolution, mais que ce n'est pas pour tout de suite.
Autres trolls
Dans les autres trolls lancés par Google, pour ceux leur disant qu'ils se font concurrence à eux-même avec WebRTC, ils répondent que non. WebRTC est un moyen d'inclure de la vidéo en streaming dans le navigateur et que ça peut tout à fait s'interfacer avec Jingle. C'est donc complémentaire. À vrai dire, Justin Uberti ("Technical Leader" de l'équipe XMPP chez Google) rappelle que c'est déjà ainsi que l'implémentation gmail marche actuellement.
Un autre ingénieur Google, ancien de l'équipe IM, explique son point de vue sur SIP: en quelques mots, c'est complexe, confus, une sécurité en bout de chandelle et une technique de fédération très bancale (qui nécessite plus les avocats des entreprises que les techniciens selon lui). Bon je n'en dirai pas plus là-dessus, je n'ai aucune connaissance technique de SIP. En tous cas, Google semble faire leur choix. Comme ils le disent dans leur annonce "jingle, c'est le futur!"
Qu'est-ce qui ne marche pas dans Jingle?
Un non-développeur a lancé une autre discussion sur ce qui ne va pas dans Jingle.
De la discussion engendrée, 3 points peuvent en être synthétisés:
- Des incompatibilités de codec;
- Les problèmes de connexion (NAT, etc.), et donc la "nouveauté" des standards associés pour les passer (ICE, nodes, etc.), ce qui implique des manques dans les implémentations.
- Des implémentations incomplètes, bugguées (je sens venir les trolls sur celle-là), ou utilisant des spécifications un peu anciennes car implémentées avant que les spécifications soient finalisées, comme par exemple lorsque Gtalk utilisait une trop vieille version de Jingle.
Les codecs
Le premier point est un énorme troll qui traîne depuis des années: faut-il un codec de référence, et si oui lequel? Qu'est-ce qu'un bon codec de référence?
- C'est déjà un codec sans brevet, licence ou autre épée de Damoclès. Cela retire H.264 pour la vidéo évidemment.
- C'est un codec qui peut se trouver sur le plus (sinon toutes) de plateformes possible.
Ce second point en particulier implique de nombreuses restrictions; déjà si possible un codec dont le traitement ne prend pas trop de ressource. C'est en particulier vrai pour l'embarqué en général, et les téléphones ou autre tablettes en particulier (surtout de nos jours). Au final, puisque personne ne voulait prendre une vraie décision et pour ne pas refaire les mēme discussions encore et encore, j'ai pris sur moi de pousser le codec audio dont le consensus me paraissait le plus évident: G.711, existant sous 2 variantes (PCMU et PCMA) car:
- Extrêmement simple à implémenter: on trouve des implémentations en quelques lignes dans de nombreux projets OpenSource.
- Extrêmement vieux, et donc tout brevet logiciel qui a pu exister n'est plus.
- Un point déterminant: il se trouve être le codec historique utilisé dans l'infrastructure téléphonique classique. Cela implique qu'il est implémenté sur toute passerelle de télécommunication (pour lier la VOIP et la téléphonie classique), sous l'une ou l'autre (voire les deux) forme: PCMA (base de l'infrastructure Amérique du Nord-Japon) ou PCMU (reste du monde). Il semblerait que de nombreuses passerelles ne supportent rien d'autre que ces codecs d'ailleurs. En nous assurant que tous les clients supportent ces codecs, nous rendons ainsi tous les clients compatibles pour se brancher directement avec le réseau téléphonique.
- Usage déjà très courant dans le monde XMPP: l'implémentation majeure Gtalk le supporte, ainsi que de nombreux autres clients.
- Simple donc finalement est assez bon pour l'utilisation ressource, donc la batterie des machines.
Faisant ainsi le choix du support maximum en prenant le plus petit dénominateur commun, même si la qualité n'est pas extraordinaire (pensez "téléphone") comparé aux codecs récents comme Opus (qui est notre espoir audio du futur dans le domaine, développé notamment avec l'équipe Skype et Jean-Marc Valin, l'auteur de Speex, mais souffre d'incertitudes de brevets qui sont en règlement), il faut toutefois noter qu'une recommandation de codec n'a pas pour but de dire quel est le meilleur codec, mais quel est celui qui nous servira de fallback si un meilleur codec commun n'existe pas. En gros, on veut que toute implémentation ait toujours au moins un codec en commun.
Pour ceux qui se demandent: et Speex? Il fait bien sûr parti de ceux que l'on a considérés, et a aussi une bonne infiltration dans le milieu. Il ne fut pas choisi, déjà comparé à l'infiltration de G.711 dans l'industrie télécom, ensuite parce qu'il est fait pour de la haute qualité et ne serait pas si efficace que cela au niveau utilisation ressource (ce qui pose problème pour l'embarqué), enfin parce que son propre auteur essaie de l'enterrer au profit du nouveau codec dans lequel il met toute l'expertise qu'il a eu avec Speex: OPUS.
Enfin pour la vidéo, je n'ai pas réussi à pousser de gagnant, déjà parce que la discussion a eu beaucoup plus de mal à se lancer (pour déceler un consensus), ensuite parce qu'il n'y a pas véritablement de vrai codec vidéo aussi parfait que ne l'était G.711. Il y avait bien H.261, vieux codec aussi, sans brevet par âge, et utilisé aussi dans l'industrie du téléphone (visio conf). Néanmoins il semblerait que la qualité soit vraiment mauvaise et que ce ne soit pas si simple à implémenter, n'en faisant pas un équivalent réel. Notre meilleur espoir est de voir comment VP8 va démarrer dans le web et de s'en emparer ensuite.
En d'autres termes, voici nos deux espoirs dans le monde de l'IM: VP8 et OPUS.
La connectivité
En dehors de ICE-UDP dont je parlais, la technique de nœud de relai (qui peuvent être fournis par des serveurs, ou bien des clients peuvent eux-même se présenter comme des relais, permettant ainsi d'obtenir un système où notre liste de contact peut nous aider à faire passer nos appels quand nous sommes dans un environnement très fermé). L'idée est bonne mais, comme certains l'ont fait remarquer, il existe encore peu de serveur ou de client proposant de tels relais. Dans les faits, cela n'existe pas concrêtement, en dehors du papier.
Le service jabber.org prévoit de mettre en place un tel nœud pour créer un précédent (non qu'il n'y en ait aucun, mais s'il y en a, ils sont bien cachés) et aussi montrer l'exemple.
Conversation audio/vidéo à plus de 2!
On n'a pas encore un noyau stable de la VOIP à deux, mais nombreux sont ceux qui poussent la gueulante sur le manque pour la conférence. Eh bien vous avez raison, il faut voir loin!
Malheureusement il y a concurrence. C'est un sujet en ébullition qui génère de nombreuses discussions enflammées car il y a deux implémentations (basées sur Jingle évidemment) qui se font la guerre.:
- Coin, très récent, reprends des concepts du monde SIP et ne se basent pas sur MUC (Multi User Chat, autrement dit les chatrooms). Le but est surtout de promouvoir l'intéropérabilité avec les clients SIP pour pouvoir créer des conférences avec à la fois des utilisateurs SIPs et XMPP apparemment. C'est donc intéressant, mais l'architecture basée sur le vieux SIP ne semble pas plaire à tout le monde. Implémenté par le client Jitsi.
- Muji, beaucoup plus ancien (autrefois appelé mingle), basé sur les MUCs et donc avec une vision probablement plus XMPP-centrée.
Je ne donnerai pas d'avis, je n'ai lu aucun des deux pour l'instant. Mais étant donné le ramdam créé récemment par l'arrivée de Coin (qui a réveillé Muji, plus mis à jour depuis 2009 et n'a jamais connu de moment de gloire ni d'implémentation en masse. Jingle à l'époque étant beaucoup plus bancal cependant, cela se comprend), il ne fait aucun doute que ce sujet va connaître du ménage et des combats mémorables dans les mois à venir.
Surtout que Google nous a annoncé, il y a 4 jours… qu'ils ont eux-même une troisième implémentation différente des 2 autres (utilisé notamment dans Google+), basée sur les MUC, Jingle, ICE et RTP! Badaboum! Peter Thatcher nous dit qu'il est en ce moment même en train d'écrire la documentation. Je pense qu'on aura cette nouvelle spécification devant les yeux très bientôt (avant la fin de l'été pour agrémenter nos longues soirées d'hiver en lecture?).
Au passage, Peter nous fait son petit commentaire sur Muji, qui ouvre N2 sessions Jingle (une entre chaque participant), ce qui n'est pas terrible quand le nombre de participants commence à grimper (comme il le dit, à 10 participants, 100 connexions? Mise à l'échelle impossible).
À priori ce serait plutôt N*(N+1)/2 (alors que Coin, c'est N-1), mais ça reste du teta(N**2) (on nous dit aussi que c'est la version actuelle mais que le design final de Muji serait bien plus efficace. En même temps, ils le peaufinent depuis 2009 ce design…).
Si je devais faire mon devin, je dirais que l'arrivée de la spécification de Google va mettre tout le monde "d'accord" (mais je peux me tromper, "devin" n'est pas ma profession première), car ils ont un argument de poids: le chiffre. Ils ont des utilisateurs (et pas qu'un peu) donc cela écrase tout, à côté de deux spécifications qui bataillent depuis un mois, dont une existe depuis deux ans sans prise réelle. On retrouve un peu la situation à l'arrivée de Jingle: quelques spécifications éparses pour faire de la vidéo, mais aucune n'arrivait à avoir le dessus et Jingle est arrivée avec sa masse utilisateur. Néanmoins rien n'est fini. Nous sommes un organisme de standard, toutes les spécifications seront lues et les choses qui devront être revues et modifiées le seront. C'est la règle du jeu.
Participez!
Je ne le dirai jamais assez: participez s'il vous plaît! Je vois énormément d'énergie gaspillée sur ce site à se plaindre. Alors oui la XSF n'est pas si bien organisée, je suis le premier à le dire. Mais aussi c'est parce que nous avons besoin de vous! Comment participer?
Participez à du développement logiciel
Les clients et serveurs ont une énorme marge de progression. N'hésitez pas à aider les projets que vous aimez.
Améliorez les spécifications
J'ai lu quantité de plaintes ici sur le fait que nos choix sont mauvais! Mais sacré nom d'une Marmotte, que ne venez-vous pas nous le dire en face? Si nous faisons une grossière erreur, c'est pas au mur à côté de vous qu'il faut le dire, mais à nous. Venez nous donner votre sagesse et votre science.
Cela ne s'adresse pas qu'aux plaintifs du coin. Je sais que de nombreux francophones développent du logiciel XMPP, mais nombre d'entre vous ne participez pas du tout au développement des spécifications. Alors si vraiment vous croyez n'avoir rien à dire et vous trouvez tout parfait, et préférez nous laisser décider, je respecte. Mais est-ce vraiment le cas? Ne voulez-vous améliorer certains points (il y a nombre de points à améliorer, mais on n'a pas assez de monde pour être sur tous les plans à la fois)? On n'attend que cela. Et ne pensez pas que vous n'avez pas les capacités de discuter spéc. Réfléchir des spécs, cela s'apprend, comme tout (pour la plupart d'entre vous en plus, vous avez déjà la compétence "gestion de troll").
Améliorez le réseau
Vous le voyez, les spécifications sont en mouvement constant. Ce qui importe le plus pour l'intéropérabilité en tant que simple utilisateur, c'est que vous participiez à un réseau stable, et pour cela, mettez à jour vos clients, vos serveurs. Jingle est extrèmement récent et par conséquent commence à peine à vraiment se stabiliser dans les implémentations (comme le montre Google récemment). Si vous ne mettez pas à jour vos clients, c'est évident que si tout le monde a une version plus ou moins expérimentale du protocole, cela marchera moyen.
Et si vous avez un serveur: installez un nœud Jingle dessus pour améliorer la connectivité générale du réseau. Si tous les petits serveurs ont un nœud Jingle, la connectivité fera soudain un bond, les clients implémenteront la gestion des nœuds relai bien plus vite, et la pénétration du standard IM s'accélérera car les utilisateurs diront "ah bah oui, ça marche".
Reportez les bugs
Alors oui y aura des bugs. La plupart de ces spécifications ne sont pas stables. Le but n'est pas d'installer un nouveau logiciel et de dire "ah bah voilà, je l'avais dit, cela ne marche pas", mais de reporter des bugs précis si possible (je ne dis pas de faire un ticket "ça marche pas", mais je sais que bcp ici ont des compétences d'analyse informatique un peu plus élevées que cela).
Aussi pareil Relay Nodes est récent, expérimental et virtuellement totalement inexistant actuellement. Il est un nouveau dans l'environnement IM. Donc si vous installez un serveur de relai, regardez vos logs, et reportez les bugs.
C'est à peu près tout. Désolé, c'est un peu long. J'espère que vous ne vous êtes pas trop ennuyé.
Aller plus loin
- XMPP Standards Foundation (225 clics)
- Journal DLFP à l'origine de la dépêche (124 clics)
# Merci!
Posté par ʭ ☯ . Évalué à 5.
Information passionnante, même si très technique. L'enjeu final est toujours en vue, j'ai l'impression d'avoir toujours tout compris.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
# Merci pour ces info
Posté par guillaume Dorchies . Évalué à -8.
Non pas trop long et très intéressant et je dois avoué que je n'utilise pas d'IM parceque de toute façon cela ne fonctionne pas ... ;-)
# SIP
Posté par anakin . Évalué à 5.
J'ai une interrogation par rapport à SIP. SIP permet chez certains opérateurs d'appeler des numéros de téléphones classiques (d'où son utilisation dans les box des FAI ?). Est-ce qu'il serait techniquement possible un jour de pouvoir faire la même chose avec jingle ?
Aussi que penser de P2P SIP (http://www.p2psip.org/) et de GNU Free Call (http://www.gnutelephony.org/index.php/GNU_Free_Call_Announcement) ?
[^] # Re: SIP
Posté par Jehan (site web personnel, Mastodon) . Évalué à 9.
Salut,
je ne suis pas un expert de ces sujets, mais théoriquement oui tout est possible. D'ailleurs c'est notamment pour ce genre de chose que les plateformes de télécoms classiques rentrent dans nos critères de décision (par exemple dans la dépêche pour le choix de notre codec audio "de base"). On améliore nos points de compatibilité pour pénétrer le marché télécom.
Ensuite dans la pratique, ça dépend déjà beaucoup de l'industrie des télécoms. Eux se sont habitués à SIP qui fut premier sur le marché et donc toute leur infrastructure logicielle pour relier les réseaux VOIP et télécoms est basé aussi sur SIP. Cela signifie deux choses:
(1) Soit XMPP prend vraiment de plus en plus d'importance dans le monde de la VOIP (et c'est possible), et les télécoms se mettront donc à s'y intéresser et à travailler avec nous (directement ou non) pour interfacer aisément un appel Jingle sur un appel "physique". Si cela arrive cependant, il y a presque forcément une certaine latence, comme pour tout dans les grosses entreprises qui sont plutôt réactives que pro-actives (et donc réagiront en panique quand ils voient que XMPP prend le dessus et que SIP disparaît par exemple, plutôt que se préparer en avance).
(2) Soit nous nous adaptons aux interfaces actuelles en créant des passerelles XMPP vers SIP (puis la communication "traduite" SIP s'interface elle-même dans une passerelle télécom).
C'est en fait ce qui se fait actuellement. C'est ainsi que marchent les appels gtalk vers des lignes physiques, en passant par une passerelle SIP (si je ne me plante pas).
Idéalement évidemment dans ma position, je préfèrerai le point (1), mais le point (2) est plus probable, au moins à court terme. Peut-être plus tard verrons-nous apparaître un mélange des deux possibilités (et à terme le cas (1) seulement si XMPP l'emporte totalement en utilisation sur SIP, ce qui ne me paraît pas improbable, voyant la tendance actuelle).
Pour les deux projets que tu cites, le P2PSIP n'a plus de nouvelle sur le site depuis 2009. Il semble par contre y avoir de l'activité récente de soumission de rfc à l'IETF mais relativement peu de discussion donc une communauté assez absente (et donc pour l'instant sans communauté ni allié fort…). Ensuite sinon techniquement je connais pas, et j'ai pas creusé. Ça se repose sur le réseau actuel SIP (c'est à dire: est-ce compatible avec l'existant?) ou bien c'est un nouveau protocole/réseau incompatible (et le nom, c'est juste pour dire que ça reprend des idées)? Parce que si c'est une tentative de créer un troisième réseau, ce ne sera pas simple avec la concurrence de SIP et XMPP.
Quant à Gnutelephony, je pige pas trop ce que c'est (j'ai pas poussé non plus beaucoup). Ça parle aussi de téléphonie p2p, mais en même temps de serveur (donc pas si p2p, ou en tous cas, pas pleinement). En fait, j'ai surtout l'impression que c'est un projet dont le but n'est au final que de promouvoir le serveur GNU SIP Witch (donc une implémentation serveur SIP). Ou bien y a-t-il autre chose que je ne vois pas?
Bon désolé, en gros je connais pas tes projets, mais bon c'est du SIP, donc déjà c'est pas mon domaine. Je n'ai pas la connaissance pour en dire beaucoup plus.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: SIP
Posté par Yannick . Évalué à 2.
C'est un projet actif, et qui je pense est tout près de finaliser sa RFC de base. Il vaut mieux regarder la mailing list pour se faire une idée car effet le site n'est pas à jour.
cf. http://www.ietf.org/mail-archive/web/p2psip/current/msg05978.html
Il existe une implémentation en java qui va être libre avec des tests d'interopérabilités qui ont été fait et sont concluants. cf. http://blog.marc.petit-huguenin.org/
L'idée est bien d'être interopérable avec SIP, toutefois cela a été étendu comme une surcouche assez neutre ; le but principal est de résoudre ce problème de la traversée des NATs en utilisant la technique de skype : organiser les clients avec une DHT http://fr.wikipedia.org/wiki/Table_de_hachage_distribu%C3%A9e (la spécification oblige à implémenter CHORD http://fr.wikipedia.org/wiki/Chord , mais elle permet d'en mettre d'autres...)
# m'en fou j'utilserais bientot retroshare
Posté par modr123 . Évalué à -3.
msn is dead
dans tout mes contact
fb :0
talk :0
msn: tous
[^] # Re: m'en fou j'utilserais bientot retroshare
Posté par ᴼ ᴹᴬᴺᴺ . Évalué à 5.
Trop le chance moi ils m'ont tous bloqués sur msn !
Je vais redonner mon adresse sur mon skyblog pour avoir de nouveau des amis.
207829⁶+118453⁶=193896⁶+38790⁶+14308⁶+99043⁶+175539⁶
# Du concret !
Posté par Salim . Évalué à 6.
Merci pour cette maj.
A part Google, quelle serait l'implémentation la plus avancée de Jingle (avec ou ICE-UDP si possible !) ??
Qui implémente OPUS pour Jingle aujourd'hui ?
[^] # Re: Du concret !
Posté par ᴼ ᴹᴬᴺᴺ . Évalué à 1.
Il y a Jitsi qui se débrouille pas mal à mon avis
http://www.jitsi.org/index.php/Main/Features
Après je ne l'ai pas testé dans tous les sens, je ne peux pas garantir que ça marche bien.
207829⁶+118453⁶=193896⁶+38790⁶+14308⁶+99043⁶+175539⁶
[^] # Re: Du concret !
Posté par Larry Cow . Évalué à 3.
Sinon, sur la partie Voix uniquement (pour l'instant?), il y a OneTeam qui gère bien aussi. Et au lieu d'être du gros-Java-qui-tâche (tm), c'est basé sur XulRunner.
[^] # Re: Du concret !
Posté par Jehan (site web personnel, Mastodon) . Évalué à 9.
Je ne saurais répondre à la première question. Je ne compare pas beaucoup les clients dernièrement.
Note que j'essaie de préparer un évènement interopérabilité qui permettra de tester massivement (avec l'aide d'utilisateurs et la collaboration des développeurs) les clients. Le but d'un tel évènement n'est pas de montrer du doigt ou de trouver un "gagnant" mais de trouver ce qui ne va pas dans les implémentations actuelles, de rassembler de l'information de debug massivement sur des environnements hétérogènes (les utilisateurs aléatoires du monde) et de les corriger. Néanmoins ça permettra quand même de voir les implémentations qui se comportent le mieux. Ensuite faut arriver surtout à motiver les diverses équipes de clients, puis organiser cela, etc. En gros ce sera pas avant quelques mois. Si jamais ça se fait, je ferai une news sur linuxfr.
Pour OPUS, aucune idée non plus, mais au hasard, je dirais "personne". C'est extrêmement récent. Si tu regardes la spéc, le brouillon le plus ancien date d'octobre 2010 (et si tu remontes dans des brouillons d'autres propositions liées, c'est à peine plus vieux, mi 2010). OPUS se base sur SILK contribué par Skype et CELT de xiph.org. L'un comme l'autre sont à l'état de brouillons IETF également (les deux ayant leurs premières versions en début 2010). Et le tout est activement modifié. C'est donc une spéc instable d'un codec, basée elle-même sur plusieurs codecs, eux-même instable, le tout en plein développement.
En gros, on peut utiliser ces spécifications pour commencer à développer, faire des tests, s'émerveiller du futur, mais il ne faut pas considérer cela comme stable et surtout pas dans un espoir d'interopérabilité immédiate en espérant que deux implémentations différentes seront compatibles.
Mais je ne dis pas ça pour dissuader quiconque de commencer à implémenter, hein. Les premières implémentations/expérimentations essuient certes les plâtres, mais aussi permettent d'avancer le plus rapidement l'écriture de spécs et aussi d'améliorer ces dernières qualitativement (en pratique, on tombe tjrs sur des choses auxquels on ne pense pas si on se limite à de la réflexion théorique).
Aussi même si OPUS est créé dans une optique ouverte (car IETF) et qu'il n'y a donc pas à douter que la version finale sera libre de brevets, il semblerait qu'il y ait eu des réclamations de brevet logiciel sur le brouillon d'OPUS actuel (déjà!), comme je l'ai dit dans la dépêche. Donc déjà ça peut prendre du temps avant de démêler tout cela, d'autre part, ça peut être une raison majeure pour changer certaines parties d'une spéc (ça dépend de chacun, mais parfois il est plus simple de contourner les difficultés, surtout certaines aussi débiles que les brevets, que de se battre contre des moulins).
Note: la liste des IPR (Intellectual Property Rights) d'OPUS est là où on voit que Broadcom, Skype et Xiph.org abandonnent leur droit de poursuivre (pour violation de brevet) pour cette spéc (si je lis bien). A priori le seul IPR agressif est celui de Qualcomm, qui dit «Reasonable and Non-Discriminatory License to All Implementers with Possible Royalty/Fee.»
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Du concret !
Posté par Salim . Évalué à 2.
Merci pour la réponse complète !
Il faut excuser ma démarche "consumériste", il est vrai qu'il n'y a pas meilleure motivation qu'une implémentation concrète avec laquelle on peut découvrir, faire joujou, et proposer des idées d'évolution.
Mais je vois que tout ça est très "frais".
C'est en soi très intriguant. Il n'existe pas aujourd'hui un logiciel que je peux mettre sur mon ordi, et celui de ma mère et juste commencer à parler sans prise de tête ! En 2011, c'est.. étonnant !
# Question HS : parle plus loin du téléphone
Posté par Laurent Pointecouteau (site web personnel, Mastodon) . Évalué à 4.
J'apprends via ce journal, par ailleurs fort intéressant, que le G.711 serait ainsi la véritable raison pour laquelle on ne comprend rien à ce que dit ma mère au téléphone. Et ce depuis les années 70 !
Aussi oserai-je poser cette question idiote : quand est-ce qu'on pourra améliorer ça ? Est-on bridé en la matière par la nature-même du réseau téléphonique ? Et en VoIP, les FAI pourraient-ils faire quelque chose ? J'ai entendu parler de "voix HD" chez Orange et d'autres concepts difficiles à cerner, mais je me demande s'il existe une raison empirique définitive à la piètre qualité du son des téléphones en 2011.
[^] # Re: Question HS : parle plus loin du téléphone
Posté par Benoît Sibaud (site web personnel) . Évalué à 10.
Les codecs classiques/historiques pour la téléphonie sont G711 a et µ. Il en existe plein d'autres... G.722, G.722.1, G.729, AMR, AMR Wideband, etc. Certains sont faits pour consommer peu de bande passante, d'autres peu de temps de calcul, etc. Et surtout il y a plein de brevets logiciels dans tous les sens.
Deux exemples :
Sipro.com « your licensing service provider for intellectual property rights (IPR) to standardized telecommunications technologies, including 3GPP W-CDMA FDD Standard and ITU-T G.729, G.723.1 G.729.1 and G.711.1 recommendations for speech and audio coding. »
mpegla.com « Patents pools MPEG-2 ATSC AVC/H.264 VC-1 MPEG-4 Visual MPEG-2 Systems 1394 MPEG-4 Systems »
En raison de ces brevets logiciels, les logiciels libres de VoIP ou d'analyse réseau peuvent souffrir de limitations. Par exemple wireshark ne fournit pas le même confort sur ces codecs brevetés. Cf http://wiki.wireshark.org/RTP_statistics
[^] # Re: Question HS : parle plus loin du téléphone
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Salut,
faudrait trouver quelqu'un qui bosse ou a bossé ds l'industrie télécoms pour répondre mieux. En tous cas, si la question est de savoir s'ils utilisent d'autres codecs que G.711, bien sûr. Ils évoluent comme tout le monde. Mais je pense que G.711 est simplement l'un des plus vieux, et donc est choisi comme "codec obligatoire" dans toute nouvelle technologie de communication audio (ce qu'on a aussi fait très récemment, comme je l'indique dans la dépêche). Le but de cela n'est pas de lui donner la priorité mais simplement que quelque soit le réseau que tu vas utiliser (les lignes de cuivre historiques, les quelques variantes de téléphone numérique, les foultitudes de réseau mobiles, etc.), au final on a toujours G.711 comme solution de secours (donc tous les réseaux sont compatibles).
En gros, si tu appelles quelqu'un, soit il y a un maillon faible (par exemple l'un des deux est sur un bon vieux fixe), soit vous êtes sur deux technologies différentes, toutes deux avec des codecs haute qualité, mais pas les mêmes, donc vous retombez sur votre seul codec commun: un codec d'il y a 40 ans.
Aussi quand on y pense, la communication peut passer par des passerelles. Par exemple supposons un appel Jingle, qui utilise Speex ou autre codec voix haute qualité. Supposons que tu appelles un téléphone qui peut aussi utiliser le codec Speex (d'après Wikipedia, la recommandation H.323 est utilisée dans des réseaux 3G ou les lignes numériques ISDN par exemple et a apparemment des implémentations avec Speex). A priori tout va bien. Mais voilà, tu passes par une passerelle qui lie ton serveur XMPP à un fournisseur télécom (avec qui il y a un contrat pour que les utilisateurs puissent accéder au réseau tél classique), qui elle ne peut faire passer que du G.711 (a priori d'après ceux qui disaient bien connaître sur la ml IETF, il y a bcp de passerelles qui ne connaissent que ce codec). Dc bah j'imagine que dans un cas comme cela, tout le monde retombe sur ce codec commun alors qu'à chaque bout, vous aviez en commun un bien meilleur codec.
Et je pense qu'on se débarrassera pas facilement de G.711, ne serait-ce parce qu'il y aura les lignes cuivre pour un bon moment (même si elles perdent du terrain avec le sans-fil) et qu'on ne doit pas casser la compatibilité.
Note que toute ma réponse n'est que le reflet de ma propre compréhension du sujet, qui est basée sur une connaissance minime. Je ne bosse pas dans l'industrie télécom, et n'ai jamais eu à travailler sur une connexion entre un réseau VoIP et les réseaux télécoms. Ma propre participation sur ce sujet précis dans les listes consiste essentiellement à lire ce qu'écrivent ceux qui disent savoir (et quand je répondais sur le sujet des codecs audio par exemple, ce fut essentiellement pour synthétiser les diverses choses que les autres ont écrites et essayer de dégager un consensus pour faire avancer les choses). Donc en gros, j'y connais rien et je peux me planter. Tout apport de connaissance par quelqu'un qui travaille dans le milieu est bienvenu.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Question HS : parle plus loin du téléphone
Posté par Benoît Sibaud (site web personnel) . Évalué à 8.
Un complément : il faut aussi convertir pour passer du G711a à du G711µ et réciproquement (sinon c'est juste inaudible).
Sinon oui il y a des changements de codecs sur les passerelles RTC-VoIP ou pour les communications inter-opérateurs (RTC-RTC, VoIP-VoIP ou RTC-VoIP) ou pour cause de changement de techno (codecs pour de la téléphonie mobile vs codecs pour paire de cuivre), les différents modes de transport pour les DTMF (les appuis sur les touches), les utilisations autres de la bande passante (modem RTC qui utilise les fréquences vocales, ADSL qui utilisent une autre plage, etc.), les technos plutôt opérateur telco (RTC, SIP) ou plutôt web (XMPP), ...
[^] # Re: Question HS : parle plus loin du téléphone
Posté par Mathieu Segaud . Évalué à 3.
En téléphonie, on utilise g711 A et B, mais c'est plutot le codec le moins en vogue. Celui que les opérateurs déploient dans leurs réseaux pour les protocoles VOIP, c'est g729 (breveté... :( ). Faut dire que g711 c'est "libre", mais par contre aucun opérateur n'en veut, à cause de la taille monstrueuse des paquets (la compression est très mauvaise en PCMA et PCMB (g711))
du coup je reste dubitatif quant à l'utilisation de ce codec, à mon avis, gsm ou speex seraient quand même moins gourmands et violents pour nos réseaux. Si les g711 sont pas trop gourmands côté cpu, c'est parce qu'ils sont pas optimisés pour une utilisation sur le réseau. :(
[^] # Re: Question HS : parle plus loin du téléphone
Posté par Jehan (site web personnel, Mastodon) . Évalué à 5.
Salut,
quand tu parles de taille monstrueuse des paquets, peut-être aussi est-ce "par rapport" à sa qualité moyenne. Donc forcément des codecs plus récents comme Speex sont bien plus optimisés avec donc une bien meilleure compression, mais en absolu (faisant abstraction de la qualité), l'échange en g711 sera moins gros que l'échange Speex, non?
Pour ce qui est de ne pas être en vogue en téléphonie, je pense que tu entends que ce n'est pas populaire car on aimerait tous s'en débarrasser, mais dans les faits, on est pris au piège par l'infrastructure (historique) existante. Moi c'est ce que j'ai compris. En tous cas, tous ceux qui bossaient ou avaient bossé en téléphonie tenaient le discours que c'était la base codec minimum présente dans toute technologie télécom.
Il faut donc bien comprendre qu'il s'agit, pour nous aussi, d'un choix uniquement pragmatique. C'est "le codec que tout le monde doit au moins avoir parce qu'il marchera partout et y a aucune raison de pas l'implémenter tellement il est simple à implémenter" (on trouve des implémentations en quelques dizaines de ligne). Mais ce n'est nullement un codec conseillé. Idéalement il ne sera jamais utilisé mais il sera toujours là en roue de secours.
Ensuite oui Speex était clairement notre second espoir pour cette place de codec par défaut, et il aurait sûrement pris la place si s'intégrer aisément au monde de la téléphonie n'avait eu aucun intérêt. Ce point a été décisif.
Note que si les réseaux télécoms évoluent et que le codec G.711 disparaît, nos propres spécs évolueront. En tous cas, il me paraît évident que dans le monde de la VoIP, ce ne sera presque jamais le codec utilisé entre deux clients VoIP. Speex a beaucoup d'implémentations et il y a aussi peu de raison de ne pas l'implémenter.
Mais il y a de fortes chances que Speex n'évoluera plus beaucoup maintenant que son auteur lui-même essaie de l'enterrer au profit de son nouveau joujou.
Un dernier truc dont je n'ai pas parlé dans le billet, c'est que Speex est orienté voix et est apparemment vraiment mauvais dans plein d'autres domaines audio (c'est vrai aussi de G.711, mais c'est pas ça qui fait qu'on l'a choisi, comme je disais plus haut). C'était une bonne idée quand on pensait uniquement "Voice over IP" mais maintenant on pense plus large. En gros, je ne suis pas sûr que Speex a beaucoup d'avenir maintenant.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Question HS : parle plus loin du téléphone
Posté par Zenitram (site web personnel) . Évalué à 3.
Pour rajouter un peu sur les très bonnes réponses des autres (c'est pas bientôt fini de répondre d'aussi longs et intéressants commentaires?) :
Oui. Par des choix anciens, qui allait bien à l'époque mais dont on subit les conséquences aujourd’hui parce que changer ça coûte cher, si tu gardes de l'ancien à un endroit (comme souvent, on est limité par le maillon le plus faible) ben tu es limité par cet endroit. Mais si tu vires l'ancien chez toi, ben tu peux avoir une qualité CD sans problème (c'est ce qui fait le succès de Skype par exemple). Juste que comme ça bouffe plus de débit (débit variable pour Skype par exemple, qui peut monter haut, qui s'adapte à ce qu'il a comme débit possible, alors que les G.7xx ou AMR sont en débit fixe, pour passer par le système de transmission par circuit du réseau téléphonique). Pour te donner un autre d'idée, l'AMR Wide Band est à 23.85 kbps grand maxi, alors forcément, avec ça tu coupes des fréquences et tu massacres la voix pour que ça passe, quand Skype, Speex ou autre utilisent Internet avec facile du 64 ou du 128 Kbps à leur disposition (+une capacité de calcul qui tue par rapport à une puce d'il y a 20 ans).
Débarrasse-toi toi-même de vieux truc, et hop tu "pourras améliorer ça", ça dépend surtout de toi et de ton correspondant. Perso, dès que je peux, j'utilise Skype (je sais, pas libre ça pue, mais trouve-moi un truc libre qui juste marche partout, qui soit simple à utiliser, si tu veux du libre... Moi, je n'ai pas trouvé), et avec un bon casque/micro, j'ai l'impression que mon interlocuteur est en face de moi alors qu'il est aux US (et il y a une sacré différence, autant j'arrive à survivre avec Skype vu mon niveau d'anglais, autant je comprend rien du tout quand on fait de mobile à mobile horrible à entendre).
Bref, ça dépends que de toi, de ton correspondant, et le prix que tu es prêt à mettre dedans (pas grand chose en fixe, mais en mobile si tu veux consommer plus de débit, ben le prix va vite monter)
[^] # Re: Question HS : parle plus loin du téléphone
Posté par BAud (site web personnel) . Évalué à 1.
Vu que tu as un serveur :
Le serveur intermédiaire sert à avoir une IP publique et y placer le relais accessible de tes interlocuteurs ; avec IPv6 de part et d'autre ce sera plus simple (si bien^Wintelligemment conçu). Sinon, ya STUN. Bref y passer un peu de temps initialement, genre 1h plutôt que 10 min entre pulseaudio, la webcam, le firewall, la conf' de base et le temps au téléphone, un peu de patience quoi et quelques bugs report au passage ou l'écriture d'un tuto pour montrer que ça fonctionne...).
[^] # Re: Question HS : parle plus loin du téléphone
Posté par Zenitram (site web personnel) . Évalué à 6.
Skype, juste ça marche. Tu es masochiste, pas moi.
Bon, comme je suis curieux, j'ai testé, pour connaitre un peu la compétition :
- Install (sous Windows) du serveur et client facile
- 1er lancement, fail : il me demande des données techniques imbitable pour l'utilisateur moyen : faut que je choisisse mon périphérique audio (peut-être parce que j'en ai 2... Mais j'en ai rien à faire, Windows a un truc "périphérique par défaut", ce n'est pas pour rien, Skype balance sur le périphérique par défaut et permet de choisir dans les options si besoin par par défaut. Ah testé sur une autre machine avec un périphérique, il me demande quel périphérique utiliser, double fail), puis me demande d’optimiser moi-même à la mano le ratio latence/buffer, puis me demande de faire des tests audio (qu'est-ce qu'il m'emmerde avec ça? Skype sait s'adapter en quelques secondes lors du premier coup de fil). Ceci est certainement acceptable pour moi, mais certainement pas pour mes interlocuteurs.
- Lancé, fail : par défaut, j'ai une fenêtre de log qui me parle chinois, c'est quoi ce bordel?
- Manque la vidéo, Skype un bouton et j'ai la vidéo.
- Manque la partie texte (fenêtre de message globale, ridicule), Skype offre ça directement.
- Manque toute la partie présence, Skype offre ça.
Bref, sur ce qu'il a pour objectif (les parties de jeu en réseau avec quelques utilisateurs prêt à passer un peu de temps et connaissant un peu leur machine), il a l'air pas mal au niveau technique. Mais il est d'une techniquement et au niveau GUI pas prêt pour Mme Michu (mes contacts principaux sont des pros qui n'ont aucune envie de tester leur micro si Skype fait pareil sans test), et très mono-tache (pas de messagerie instantanée, pas possible de se connecter sur plus d'un serveur à la fois alors que Skype j'ai tout le monde Skype d'un coup car un réseau, quand on permet l’utilisateur de plusieurs réseau ben vaut mieux permettre la connexion à plusieurs réseau pour la présence, ah zut pas fait pour la présence c'est vrai, pas de vidéo)
Bref, si tu proposes Mumble pour remplacer Skype, c'est que tu n'as vraiment aucune idée du besoin rempli par Skype, ce qui fait que Skype est utilisé et est connu par beaucoup de monde.
Je serai moins idiot (bien que j'avais déjà lu Mumble ici en tant que remplaçant potentiel de Skype, ça ressort parfois), mais je ne remplacerait certainement pas Skype. Regardez un minimum ce que fait Skype avant de proposer un logiciel qui ne remplit pas le besoin, vous passez pour juste frustrés car Skype est proprio et vous passez pour des gens prêt à filer n'importe quel nom pour dire que le libre sait faire (non, il ne sait pas faire)
Les gens veulent un logiciel intégré, pas un "alors pour le besoin d'IM, il y a Pidgin, pour le besoin d'audio il y a Mumble, mais bon, faut dire aux gens de se connecter sur le même serveur que toi, vous vous donnez rendez-vous quoi, pour la vidéo attend je dois avoir un VLC dans le coin, ah oui pour chacun faut un login différent", Skype juste ça marche. Et je les comprend : pourquoi s'emmerder quand un logiciel répond au besoin? Pourquoi s'amuser à manipuler 36 trucs pas agréables? (juste parce que c'est libre? Pas suffisant). Les libristes ont un gros problème : ils ne veulent pas voir le besoin des gens, et pensent que pour mériter un truc qui marche, il faut connaitre la technique sinon on ne mérite pas. (Bon, pas tous, par exemple Firefox déchire car justement, ils ont mis l'analyse du besoin utilisateur très en avant, c'est leur priorité, quitte à faire gueuler les libristes)
En attendant, les logiciels proprios ont de beaux jours devant eux.
[^] # Re: Question HS : parle plus loin du téléphone
Posté par Adrien . Évalué à 7.
Juste pour un dire un truc à propos de IPv6 :
J'ai récemment déménager et maintenant je suis connecté en IPv6. Pour la VoIP avec Pidgin, ça a tout changé : avant (IPv4 + NAt, derrière une machinBox) pas moyen de le faire marcher, c'était franchement récalcitrant j'ai abandonné.
En IPv6 je teste, ça marche du premier coup :-O Ça a été une sacrée bonne surprise, autant pour la partie IPv6 que Jabber.
Du coup maintenant je vois très concrètement l'utilité et la nécessité d'IPv6 pour le réseau…
[^] # Re: Question HS : parle plus loin du téléphone
Posté par Zenitram (site web personnel) . Évalué à -7.
Il y a personne pour dire que le NAT n'est pas un pis-aller, oui IPv6 est bien. Mais... pourquoi changer toute la chaine de transport quand on arrive à faire évoluer ce bon vieux IPv4 pour que ça réponde au besoin? en IPV4, deux personnes derrière un NAT, ça marche très bien. Techniquement, c'est galère pour le développeur, oui, mais ça marche. Demander aux gens de changer pour aucun gain pour eux (juste moins de galère pour le développeur), ce n'est pas suffisant (et on le voit : tout le monde s'en fout d'IPv6).
IPv6 est toujours à la recherche de sa "killer-feature" qu'IPv4 ne peut pas remplir en bidouillant.
[^] # Re: Question HS : parle plus loin du téléphone
Posté par Dorian . Évalué à 2.
Il vient de te prouver le contraire, mais non, tu veux troller pour troller…
« En fait, le monde du libre, c’est souvent un peu comme le parti socialiste en France » Troll
[^] # Re: Question HS : parle plus loin du téléphone
Posté par Zenitram (site web personnel) . Évalué à -7.
Il vient de prouver quoi? Qu'avec IPv6, c'est génial car ça marche du premier coup la VoIP?
Je lui donne un contre exemple : chez tous les utilisateurs d'un logiciel connu, ça marche du premier coup, en IPv4.
Alors pointe moi où il démontre que IPv6 propose mieux.
Pour info, le fait de pouvoir utiliser un logiciel libre à la place d'un logiciel proprio a une importance pour 1% de la population, bref aucune importance pour une killer feature.
C'est du foutage de gueule que de trouver une killer feature dans un truc qui fonctionne en IPv4 chez 99% des gens. Du Troll? Non, une réalité bien réelle chez les gens, qui ne s'emmerdent pas.
[^] # Re: Question HS : parle plus loin du téléphone
Posté par Adrien . Évalué à 5.
« Alors pointe moi où il démontre que IPv6 propose mieux. »
Pour les esprits trollifères :
– avec IPv4 + NAT : pidgin marche pas chez moi.
– avec IPv6 : pidgin marche.
Donc pour les gens qui n'ont pas envie de s'emmerder, oui IPv6 c'est mieux. En
Je me fiche de savoir ce que fais skype. Zenitram, tu m'as habitués à mieux en troll quand même.
En plus skype n'est même pas dans les dépôts et la version Linux est à la ramasse. Donc en tant qu'« utilisateur qui ne s'emmerde pas » j'utilise pidgin, avec IPv6.
[^] # Re: Question HS : parle plus loin du téléphone
Posté par Zenitram (site web personnel) . Évalué à -4.
Bien pour toi. Mais le fait que pour toi, dans une utilisation limitée volontairement au libre, ça marche mieux, ne fait pas d'IPv6 un truc génial qui a sa killer feature pour être déployé.
Je répondais à Dorian qui dit qu'avec ta démo, IPv6 a sa killer feature, non elle ne l'a pas : pour toi oui, mais une killer feature, c'est un truc massivement utile qui va pouvoir être "vendable" partout. Et dans 99% des cas, ta killer feature, on va lui rire au nez en disant "chez moi ça marche sans IPv6".
Je persiste donc : IPv6 est toujours à la recherche de sa "killer-feature".
[^] # Re: Question HS : parle plus loin du téléphone
Posté par Dorian . Évalué à 10.
Abandonne, tu vas pas nous faire croire ici que IPv4+NAT c'est mieux que IPv6 !
« En fait, le monde du libre, c’est souvent un peu comme le parti socialiste en France » Troll
[^] # Re: Question HS : parle plus loin du téléphone
Posté par abraxas . Évalué à 5.
La killer feature, c'est qu'il y a des adresses pour tout le monde (et pour tous les clients, pas juste pour tous les foyers).
Tu le sais pertinemment, donc je ne vois pas pourquoi tu persistes.
[^] # Re: Question HS : parle plus loin du téléphone
Posté par Prodejeu . Évalué à 0.
La killer feature ?
Avoir plus d'IP ? ;-)
[^] # Re: Question HS : parle plus loin du téléphone
Posté par Altor . Évalué à 0. Dernière modification le 24 août 2019 à 13:55.
J'ai essayé skype et bien je n'ai même pas réussi à le démarrer. Pourtant, j'ai téléchargé la version static et j'ai suivi les instructions du README.
On me souffle dans l'oreillette que c'est parce que je suis en 64 bits. Pourtant, sur la page de téléchargement ou le README il n'y a rien d'indiqué…
[^] # Re: Question HS : parle plus loin du téléphone
Posté par Victor . Évalué à 2.
Sur archlinux ça marche sans problème en 64bits:
Dépend de :
xdg-utils hicolor-icon-theme lib32-qt lib32-alsa-lib lib32-libxss lib32-libxv
Dépendances opt. :
lib32-v4l-utils: webcam support
lib32-libcanberra: XDG sound support
lib32-libpulse: PulseAudio support
[^] # Re: Question HS : parle plus loin du téléphone
Posté par Altor . Évalué à 1.
Je suis allé sur le site officiel et j'ai télécharger la version static pour ne pas me prendre la tête. J'ai une version purement 64bits et ça ne marche pas sans le multilib. Or ça ce n'est pas précisé sur le site officiel. Du coup on ne peut pas dire que skype juste marche sous linux.
# Impressions
Posté par Maclag . Évalué à 10.
Tout d'abord, bravo pour ce bel article, très clair, et qui se lit tout seul.
Corrige-moi si je me trompe, mais dans l'ensemble:
Pour les réactions émotionnelles, sachez qu'ici, il est passé 0h00 et on est déjà le 8, voilà!
Moi j'attends toujours de pouvoir recommander XMPP à mes parents sans m'entendre répondre que leurs potes en ont jamais entendu parler mais ils sont sur msn ou Skype.
Et mieux: héberger un serveur en [notre-nom-de-famille].com/perso/autre
[^] # Re: Impressions
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10.
Oui. Mais vois l'état des "concurrents" de nos jours. Les gros d'avant — MSN, ICQ, AIM, Skype… — ne sont plus que des dinosaures en voie d'extinction qui font de la lêche aux primates d'aujourd'hui (Google et Facebook qu'ils se mettent à intégrer dans leurs clients respectifs). Ces deux nouveaux grands de l'IM se trouvent tous deux utiliser… XMPP (bon un seul est fédéré)! Parmi eux, AIM/ICQ commence à se mettre sérieusement à XMPP (officiellement); Skype est effectivement celui qui a encore la meilleure "aura" en VoIP, mais cela n'empêche pas qu'il n'est plus rentable, qu'il a donc été vendu (une fortune certes, mais certains disent que ce prix était de la folie, l'avenir nous le dira), et que leur récent "business model" semble être de se décider à faire le larbin de celui qui marche (Facebook que leur client "supporte" maintenant); MSN, bon bah ils sont juste devenus quasi inexistants.
Alors peut-on vraiment parler de réussite? Certes sur un plan financier, certains ont dû profiter largement pendant que ça durait et s'en sortiront très bien, mais l'avenir est compromis pour ces technologies. C'est du court terme.
Je crois que c'est se voiler la face que de ne pas voir la prédominance de XMPP de nos jours. Le standard fait son bonhomme de chemin, tranquille certes, les gens ne connaissent pas le nom du protocole derrière (et perso, on s'en fout. Va parler de POP3, IMAP ou SMTP aux gens), mais si on fait des chiffres d'utilisation (cad pas en comptabilisant les "comptes morts"), je suis persuadé que nous sommes numéro 1 (peut-être numéro 2 si on ne compte pas Facebook car ils valent pas mieux que les autres et sans être fédéré, ils comptent pas vraiment).
Pendant ce temps, les autres viennent ou viendront petit à petit (AOL par exemple très bientôt, espérons le).
Oui cela s'est passé beaucoup ainsi pour certaines technologies (la VoIP en particulier). Pour le reste, ils ont fait comme tout le monde et ont profité de ce que les autres ont développé. La base du protocole, les MUCs, les vcards, la plupart des fonctionnalités XMPP, ils ont simplement suivi ce qui existait et marchait. Même dans les trucs récents: l'identification SCRAM par exemple, je trouve ça purement génial comparé à ce qui se fait de nos jours, par exemple dans le web; le versionnement de roster; tous les trucs qui se sont fait à partir de Jingle sans rapport avec Google (les Nodes, etc.).
Pour la vidéo, forcément quand ils sont arrivés, il n'y avait rien qui avait fait son nid, donc ils ont comblé un manque. On ne va pas rejeter cette fonctionnalité dont les contributions ont suivi les règles (pourquoi le ferait-on? Pour faire les rebelles? Parce qu'on aime pas le méchant capitalisme?!). Note qu'ils ont proposé et implémenté Jingle, ça marchait bien, mais ça a été amélioré et Google n'a pas dit "non, vous ferez comme nous, et c'est tout" comme tu l'affirmes. Non ils ont pris leurs développeurs et ils leur ont dit: "ok le standard a changé, s'il vous plaît, mettez à jour en suivant les recommandations de la XSF" (d'ailleurs cela était reproché dans l'autre sens car justement Google était pas encore à jour. Comme quoi, les gens sont jamais contents: si on avait suivi à la lettre sans rien revoir le protocole de gtalk, on aurait dit qu'on est vendu à Google. Mais si on améliore le protocole, c'est nul "y a 2 Jingle" -> cf. remarque qu'on m'a faite sur le dernier billet). Il n'y a pas de domination de Google sur la XSF qui est et restera purement neutre. Dans une spéc comme Jingle, il y a eu énormément de contribution hors-Google.
Mais sinon de manière générale, oui tu as raison. Google arrive et met un peu des coups de pieds dans une fourmilière de débats (pas forcément des débats stériles ceci dit) et s'impose avec son nombre utilisateur. Bienvenue dans le monde des Standards. Mais toi tu fais paraître cela comme une très mauvaise chose. Ça ne l'est pas.
Si tu travailles un peu en entreprise, tu sais sûrement comment ça se passe: on développe des trucs dans l'urgence, on mets les bugs sous le tapis plutôt que les corriger, on fournit du support langue-de-bois, on fait des trucs qui "marchent" en effet dans la plupart des cas, mais on laisse de côté des trucs inutiles comme l'interopérabilité, les cas spéciaux chiants qui font 1% de nos utilisateurs, on prend des technologies spécifiques pleines de brevets et qui ne marchent pas sur toutes les plateformes, etc. En gros on fait les trucs mal, mais qui donnent le change, et surtout avec une implémentation.
Par contre les organismes de standard, c'est une coquille vide à la base, avec des règles pour faire tout ce que les entreprises ne veulent pas faire. Et les gens qui remplissent la coquille sont soit des "standardiseurs" purs et durs (des mecs qui font bcp de théories, lisent les standards à la pelle, et participent à 50 groupes de travail, etc. mais n'implémentent pas), quelques gens qui font des projets logiciels (éventuellement en hobby) et ne participent qu'aux 3/4 standards qui les intéressent, et… les entreprises. Ces dernières y gagnent tout ce qu'elles ne savent pas faire bien. Donc en effet, c'est tout à fait ça: les organismes de standard sont pour ces entreprises des « service[s] d'optimisation et validation pour [leur protocoles]». Elles y gagnent cela. De notre côté, les standards y gagnent la réactivité des entreprises qui ont des gens payés pour travailler à temps plein sur ces protocoles et qui doivent faire les choses rapidement pour battre la concurrence. Sans eux, effectivement, il y a soit des nouveaux standards qui sont tellement géniaux, ou qui manquaient tant jusque là, que leur implémentation partout s'impose (extraordinairement rare), soit beaucoup de disputes pour des standards ou des approches différentes. Mais au final ce qui compte, ce sont les implémentations. C'est ça qui décide réellement qu'un standard passe un stade du "vent" au "réel". Et bien que ces implémentations peuvent être des projets hobbyistes, les "gros chiffres" sont en général faits par les entreprises qui y mettent des moyens. Donc ils implémentent ce qu'ils estiment être le mieux (pas forcément ce qu'ils ont développé; souvent ils choisissent un des "combattants" dans les débats contradictoires et ça clôt le débat).
Les vrais gagnants dans tout ça, ce sont les utilisateurs. Et c'est ça l'important.
Enfin dernier point si on ne voit que Google, c'est que ce sont la seule entreprise de cette taille qui participe à la XSF autant, mais on n'attend que cela que les autres viennent (peut-être bientôt AOL? Facebook, ils font que parasiter, mais pour contribuer, on attend toujours, etc.). Mais de manière générale, on ne profite pas que d'eux. Par exemple, je parlais plus haut de Skype, qui en un sens aide aussi XMPP en participant à SILK et OPUS que l'on se privera pas pour utiliser également (pareil, pourquoi ils contribuent IETF et font ami-ami avec xiph.org et d'autre au lieu de faire dans leur coin? Parce qu'ils se rendent bien compte que ça leur apporte beaucoup plus de travailler ainsi).
Ce que j'essaie d'expliquer, c'est un peu comment ça marche en interne, quelle est la "vie" d'un standard, quel est le processus pour créer la colonne vertébrale du net, que sont ces organismes que vous semblez tous exécrer comme un ramassis de brasseurs de vent. Les organismes de standardisation (que ce soit XSF pour l'IM, W3C pour le web ou l'IETF pour l'Internet en général) sont lents, chiants, trollifère, mais ils fabriquent des choses qui durent. XMPP n'a fait que progresser tranquillement depuis 12 ans. En fonctionnalité, en implémentation, et en part de marché. Les autres, c'est du vent marketing. Ils vont et viennent. Ils font du "buzz", puis on les oublie. Ils se vendent entre eux, se prostituent, atteignent des sommets… pour chuter sans préfixe "para". Les standards, eux, progressent. Et c'est tout.
C'est vrai pour le web (il y a les "alternatives proprios" qui ont leur heure de gloire à coup de milliards puis leur déchéance), pour l'IM, pour tout.
Moi il est 4h30 et aussi le 8.
Pour ma part, j'attends que les gens arrêtent de parler de XMPP et de troller sur le nom ou l'inconnu de ce nom. Personnellement je parle aux gens uniquement de "messagerie" ou "messagerie instantanée". Parce que l'avenir est simplement dans l'interopérabilité. Déjà on travaille pour rendre XMPP et SIP intéropérable et il m'est avis que les sociétés qui vont progressivement se mettre à XMPP vont dans un premier temps faire des passerelles en gardant leur protocole proprio en interne. Mais cela n'importe pas. Je veux juste pouvoir demander à quelqu'un son adresse IM, l'ajouter à mon roster et le contacter ainsi, sans me préoccuper de son fournisseur et de la technique derrière. Et cela n'arrivera pas tant qu'on fera des distinctions qui n'importent qu'aux techniciens.
Bah va y, fais le! :-) Avant même d'avoir un serveur auto-hébergé, tu peux même gratuitement utiliser les services de l'APINC qui te fournit son serveur XMPP avec ton propre domaine: http://jabber.apinc.org/
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Impressions
Posté par warwick . Évalué à -1.
Double plussoyage!
Bon et sinon vous êtes dans quel coin, si cela n'est pas trop indiscret?
Je me disais que ca serait sympa d'avoir une carte pour savoir un peu ou les uns et les autres vivent (un peu comme celle des développeurs gnome), ce qui m'a amené à penser que ce serait sympa d'avoir une carte des lieux où se rencontrer et discuter, pour de vrai, entre libristes, en vacances ou pas :) (je sais! Yakafer ...)
[^] # Re: Impressions
Posté par jnanar (site web personnel) . Évalué à 6.
Linuxfr, le premier site de rencontre pour les moules.
-->[]
[^] # Re: Impressions
Posté par Jehan (site web personnel, Mastodon) . Évalué à 2.
Dernièrement principalement en Corée. Je passe régulièrement au Japon aussi. Sinon je crois qu'on peut se tutoyer sur ce site, sauf si vous insistez vraiment pour qu'on se vouvoie.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: Impressions
Posté par Mathieu Segaud . Évalué à 3.
la folie du rachat de Skype par Microsoft, c'est qu'en même temps, MS essaye de faire adopter son OS pour mobile... je me demande ce que font les spécialistes de la prospective chez Microsoft:
1) faire dire à Elop que Windows Phone destiné pour les prochains Nokia contiendra Skype
2) faire dire à Elop que Skype sur Windows Phone sera l'une des composantes les plus importantes du nouvel ecosystème "téléphonie" que Microsoft entend créer...
du coup les opérateurs ont fait retirer TOUS les tel windows phone 7 (y en avait pas beaucoup) de leurs boutiques: aucun opérateur n'acceptera jamais que Skype utilise leurs tuyaux...
[^] # Re: Impressions
Posté par SF . Évalué à 3.
Je suis très satisfait d'un éventuel remplacement de skype par xmpp.
Par contre quand je pars à l'étranger heureusement qu'il y a skype pour discuter avec les enfants qui restent en France. Je lance Skype quelques jours pas an, quand je veux être sur de pouvoir communiquer (et de chaque coté il n'y a qu'un seul contact), c'est ça qui manque encore.
Ouhai on peut faire avec d'autre outils, ce que je fais le reste de l'année mais dans le cas précis où je veux être certain qu'un appel aboutisse sans avoir à gérer le contexte local ben euh... content de trouver cette interface lourdingue et imbuvable mais qui me permet de passer l'appel sans y consacrer ni temps ni intelligence de part et d'autre.
# multicast
Posté par Samuel Thibault (site web personnel) . Évalué à 9.
Pour les discussions à plusieurs, on a déjà une technologie qui est censée faire tout bien pour n'avoir que N connexions: le multicast. Mais il n'a jamais été déployé jusqu'aux quidams, parce que pas considéré utile, et donc du coup pas utilisé par les webradios etc. alors que ça leur coûterait bien moins cher en bande passante, etc, etc..
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.