En effet, la Jabber Software Foundation (JSF) a publié un ensemble de protocoles appelé "Jingle" permettant de gérer les connexions multimédia de pair à pair. Actuellement deux protocoles sont disponibles :
- "Jingle Signalling" : protocole de base pour toute connexion multimédia
> "Jingle Audio" : protocole spécifique aux communications de type voix sur IP
Ces deux protocoles ont été rédigés en collaboration avec Google et sont très proches du protocole utilisé dans le logiciel Google Talk. Pour faciliter l'implantation de ces protocoles, Google a publié sous licence BSD une bibliothèque en C++ directement extraite du code de Google Talk. Cette bibliothèque est actuellement en train d'être intégrée au client Jabber Psi.
Jingle semble déjà séduire de nombreux acteurs du monde Jabber et devrait être prochainement intégré aux produits d'Antepo, Cerulean Studios (Trillian), Coversant, Digium (Asterisk), Gaim, Jive Software, Novamens, Psi, SAPO, et Tipic. Comme l'explique Peter Saint Andre (le président de la JSF) sur son blog, les précédentes tentatives de la JSF pour définir un protocole de transport de la voix ont reçu jusqu'à présent des retours peu favorables. Notamment le protocole TINS qui définit comment négocier une session SDP par XMPP est souvent jugé trop compliqué. Les protocoles Jingle sont donc censés résoudre ce problème en proposant une solution plus intégrée à XMPP là où TINS était focalisé sur la facilité de compatibilité avec SIP. Néanmoins, la Jabber Software Foundation travaille actuellement à normaliser la façon dont Jingle devrait s'interfacer avec SIP, H323 et IAX. La complexité d'interface XMPP/protocole externe devrait donc être ramenée au niveau des passerelles (côté serveur), ce qui a toujours été la philosophie de Jabber.
Jingle est actuellement au tout début de sa phase de normalisation (les protocoles ont pour l'instant le statut « expérimental ») et évoluera par le processus de normalisation standard de la JSF auquel n'importe qui peut prendre part à travers la liste de diffusion Standards-JIG.
Aller plus loin
- Annonce officielle de la JSF (6 clics)
- Explication de la genèse du protocole par Peter Saint Andre (4 clics)
- Annonce de la sortie de libjingle (3 clics)
- Annonce du support de jingle dans Psi (3 clics)
- Annonce du support de jingle dans Gaim (5 clics)
- Site communautaire francophone de Jabber (11 clics)
# routeur NAT
Posté par Rémi baudruche . Évalué à 9.
Par exemple Skype (qui n'est pas une référence du libre) utilise un systeme de peer-to-peer qui permet d'etablire un connexion entre nimporte qui même deux personnes derière un routeur NAT.
[^] # Re: routeur NAT
Posté par Rémi PALANCHER (site web personnel) . Évalué à 9.
Je ne sais pas trop par quel port passe tout ce bazar mais ça passe très bien...
Alors étant donné que les protocoles sont à priori très proches, gageons qu'il en soit de même pour Jingle !
Mais j'ai eu des échos comme quoi ça ne se passait pas spécialement bien avec SIP.
En tout cas, ça ressemble à un grand pas pour la IM/voIP libre.
[^] # Re: routeur NAT
Posté par Snark_Boojum . Évalué à 6.
Snark sur #gnomemeeting
[^] # Re: routeur NAT
Posté par Rémi baudruche . Évalué à 5.
j'ai plusieures supositions, mais ça n'est que des élucubrations.
I - Si il n'y en a qu'un des deux qui est derière un routeur NAT :
c'est le client deriere le routeur NAT qui contacte l'autre qui est joignable dirrectement
II - si les deux sont deriere un NAT :
- Magie noire
- passerelle sur un server
- passerelle sur d'autres clients qui sont accessible en entrée
je m'intéroge là dessu depuis que j'ai vu skype fonctionner avec deux ordi deriere un fire-wall.
[^] # Re: routeur NAT
Posté par M . Évalué à 8.
Pour skype c'est tu p2p, donc tu passe par d'autres clients (d'ou les pb de secu car tu sais pas trop ce qui passe par ton reseau...)
[^] # Re: routeur NAT
Posté par ecyrbe . Évalué à 4.
Si ce n'est pas ce qu'on appelle du NAT symmétrique, alors on peut toujours réussir à passer Directement en NAT to NAT sans utiliser de passerelle. A première vu on se dit que c'est pas possible, mais si! suffit de faire transiter les flux en udp, et de savoir ou envoyer (qu'elle ip et quel port).
Pour le cas ou l'un des deux est dans un NAT symmetrique, alors on a le choix, passer par une passerelle spécifique au protocole ou passer par une passerelle générique (appelée TURN, cf draft en cours à l'ietf). La passerelle, après elle peut être soit dédiée sur un serveur central, soit sur un client dont le réseaux n'est pas du NAT symmetrique.
ça c'était pour les flux audios eux mêmes... pour permettre à SIP/SDP de passer lui aussi le NAT, on doit utiliser des serveurs STUNs (standard de l'ietf) pour résoudre les problèmes d'adressage du protocole.
# Génial!
Posté par psychoslave__ (site web personnel) . Évalué à -10.
Enfin si ma caméra est reconnue... humm, une bonne séance bidouillage en perspective.
/me RFTM.
[^] # Re: Génial!
Posté par Olivier Grisel (site web personnel) . Évalué à 4.
[^] # Re: Génial!
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 10.
s/à l'air en cours d'achevement/est achevé ;-)
> Par contre je sais pas si ca marchera sous linux.
oui, ça fonctionnera sous linux, toutefois, la version windows sortira avant...
# Il manque Kopete dans la liste
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 6.
En fait, on peut tout à fait penser que d'ici 1 an, on aura plein de clients win/linux/osx qui supporteront un Jabber audio/video, des serveurs Jabber capable d'absorber de gros traffics (via google), et donc il sera enfin temps de faire migrer ses contacts.
[^] # Re: Il manque Kopete dans la liste
Posté par Aldoo . Évalué à 6.
Dans ce cas, on effectivement de bonnes raisons de penser que Kopete supportera Jingle peu de temps après Psi.
[^] # Re: Il manque Kopete dans la liste
Posté par creak (site web personnel) . Évalué à 2.
Alors, oui, on peut parler tranquillou, mais impossible d'utiliser des trucs simple de Jabber comme le changement de pseudo + message d'info sur ce qu'on est en train de faire. De plus l'affichage des infos est vraiment restreinte...
J'ai comparé sur les deux vu que j'ai un compte Jabber et un compte GTalk.
Vous en pensez quoi vous de cette compatibilité que Google avait pourtant annoncée??
[^] # Re: Il manque Kopete dans la liste
Posté par Victor . Évalué à 5.
Attend gaim 2.0 avant de voir ce que fais gaim en fait vu qu'il va y avoit pleins de nouveaux trucs, dont le support de ces fonctions je suppose :)
[^] # Re: Il manque Kopete dans la liste
Posté par Victor . Évalué à 2.
tu voulais dire que le "jabber" gtalk n'implementait pas ces fonctions ?
[^] # Re: Il manque Kopete dans la liste
Posté par Jean Roc Morreale . Évalué à 4.
[^] # Re: Il manque Kopete dans la liste
Posté par Nicolas Schoonbroodt . Évalué à 7.
Peut-être gtalk utilise-t-il le 22... pour en être sûr, quelqu'un peut essayer gajim <-> gtalk ...
[^] # Re: Il manque Kopete dans la liste
Posté par Nicolas Schoonbroodt . Évalué à 6.
[...] gtalk utilise [...] le 85, mais vous aviez corrigé de vous même ;-)
[^] # Re: Il manque Kopete dans la liste
Posté par bero . Évalué à 4.
En même temps, quand on voit Jingle-audio, on reconnait bien un SDP SIP à la sauce XML. La description d'une video se fera de la même façon.
# anglicisme
Posté par plic . Évalué à 3.
Merci.
La faculté de citer est un substitut commode à l'intelligence -- Somerset Maugham
[^] # Re: anglicisme
Posté par 桃白白 . Évalué à 3.
[^] # Re: anglicisme
Posté par welty . Évalué à 1.
[^] # Re: anglicisme
Posté par welty . Évalué à -2.
# Centralise vs desentralise
Posté par tanguy_k (site web personnel) . Évalué à 2.
Ca c'est un truc que je ne comprends pas. On essaye le plus possible de tout decentraliser alors qu'au contraire Jabber (semi) centralise.
La philosophie d'Internet (de TCP/IP) est de mettre l'intelligence au bord du reseau. On voit actuellement a quel point ces concepteurs avaient raison: on peut faire passer n'importe quel type d'information sur Internet, se sont les terminaux (PC) qui intepretent l'information et ca tombe bien car ils sont de plus en plus puissants pour un cout de plus en plus faible.
Avec Jabber au contraire ce sont les serveurs qui ont de l'intelligence en permettant l'interconnexion avec d'autres reseaux.
La recherche actuelle est tournee vers les systemes decentralises:
http://pdos.csail.mit.edu/chord/#pubs
http://research.microsoft.com/~antr/Pastry/pubs.htm
http://ntrg.cs.tcd.ie/undergrad/4ba2.02-03/p9.html
Je ne sais pas si Jabber a de l'avenir, mais en tout cas je suis plus partisant pour des solutions comme Gaim ou c'est le PC final qui contient l'intelligence et pas le serveur.
[^] # Re: Centralise vs desentralise
Posté par push . Évalué à 2.
[^] # Re: Centralise vs desentralise
Posté par gnujsa . Évalué à 7.
Quelques serveurs officielements enregistrés:
http://www.jabber.org/network/
http://www.xmpp.net/
Mais il y en a en réalité beaucoup plus que ça.
Aprés, de mettre l'intelligence côté client ou serveur, c'est un autre débat, mais les serveurs jabbers sont effectivement décentralisé, et pas juste, que d'un point de vue technique ou géographique. Jabber ne dépend pas d'un pays ou d'une société, n'importe qui peut faire tourner un serveur jabber, que ce soit pour une utilisation publique ou privée.
[^] # Re: Centralise vs desentralise
Posté par tanguy_k (site web personnel) . Évalué à 4.
Ba justement je parle de cet autre debat ! Mon post se refere a une citation: la gestion du multiprotocole se fait du cote serveur alors que pour moi cela devrait etre du cote client comme Gaim le fait. Je ne remet pas en cause le reste !
[^] # Re: Centralise vs desentralise
Posté par Erwan . Évalué à 10.
Tu imagines si on avait 50 versions de http ? Ce serait un beau bordel.
Alors acceder a ICQ et compagnie depuis un compte Jabber c'est juste un truc "en bonus", pas une fonctionnalite cle de Jabber. Personne ne t'empeche d'utiliser Gaim pour acceder a ton compte jabber et tous tes autres protocoles.
[^] # Re: Centralise vs desentralise
Posté par tanguy_k (site web personnel) . Évalué à 1.
On est tous d'accord avec ca. Le fait que ca existe et donc qu'il faut le supporter.
Personne ne t'empeche d'utiliser Gaim pour acceder a ton compte jabber et tous tes autres protocoles.
Je m'en doute, merci bien.
Je le refait: je ne comprends pas la philosophie de Jabber qui est de gerer le multiprotocole cote serveur alors que la logique voudrait que cela soit gere du cote client. Le fait de gerer le multiprotocole cote serveur a aussi des impacts sur le protocole lui meme.
[^] # Re: Centralise vs desentralise
Posté par Krunch (site web personnel) . Évalué à 6.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Centralise vs desentralise
Posté par tanguy_k (site web personnel) . Évalué à 1.
Beaucoup moins que si le client avait à le gérer lui même.
Tu confonds: je parle de la definition du protocole Jabber.
[^] # Re: Centralise vs desentralise
Posté par Nÿco (site web personnel) . Évalué à 2.
Regarde ton téléphone, tu ne lui demandes que de joindre tes correspondants... qu'ils soient en RTC, GSM, RNIS, MGCP, SIP et j'en passe !
Regarde ta téloche : tu as une antenne RF, un boîtier TNT, un câble; une parabole, c'est un gros bordel !
[^] # Re: Centralise vs desentralise
Posté par Zenitram (site web personnel) . Évalué à 3.
Ah? Je croyais que mon téléphone parlait :
- Pour la com' : GSM, GPRS, EDGE, UMTS release3, UMTS Release 4, et les prochains supporteront UMTS release 5 (HSPDA).
- Pour l'affichage : WAP, HTML, Java.
Rien que pour joindre mes correspondants, j'ai 5 normes, et pour afficher des choses au moins 3 normes.
Mauvais exemple donc, ou exemple contre ce que tu affirmes : le client supporte souvent plusieurs normes, que ce soit un telephone ou un PC.
[^] # Re: Centralise vs desentralise
Posté par kd . Évalué à 4.
Je pense que tu as détourné l'exemple original.
Pour le téléphone, il te suffit d'une seul norme pour pouvoir l'utiliser. J'ai un vieux téléphone portable qui ne connaît que le GSM. Pourtant, si j'ai envie de t'appeler, je pourrai.
Ce n'est pas le cas de ta télévision. Je n'ai pas de décodeur canal+, je ne peux pas regarder cette chaîne ; je n'ai pas de boitier TNT, je n'ai pas accès aux chaînes offertes ; je n'ai pas de parabole, je n'ai pas accès aux chaînes diffusées par satellites.
Quoi qu'il en soit concernant la pertinence de cet exemple, il est évidemment mieux pour tout le monde qu'un seul protocole d'IM puisse s'imposer. Après tout, pour les mails, il n'y a que SMTP pour l'acheminement des mails. Pour le web, il n'y a que l'HTTP.
À part pour les sociétés qui ont des parts importantes de marché, comme Microsoft, tout le monde a intérêt à se tourner vers un protocole ouvert et normalisé.
Ce sont pour ces raisons que je pense de manière raisonnable qu'un protocole comme celui de Jabber finira par s'imposer, malgré l'hégémonie de MSN, surtout en Europe.
[^] # Re: Centralise vs desentralise
Posté par Zenitram (site web personnel) . Évalué à 0.
Si ton telephone est uniquement GSM comme tu le dis, ben... si tu es dans une zone non couverte par le GSM mais seulement par l'UMTS (hypothetique en FRance, mais reel ailleurs), tu ne peux pas me telephoner avec ton téléphone!!!
Quel que soit le sens dont tu tourneras ton argument, il se retournera contre toi : un telephone ne pourra pas parler a une antenne ne parlant pas la meme lanque, c'est un fait.
En fait tu confonds deux choses : l'accès au reseau (GSM, UMTS) et l'accès a une personne pas sur le meme reseau (RTC, SIP)
Si on reviens a Jabber, ne confond pas l'accès au reseau Jabber ou MSN, et l'interopérabilité entre les reseau Jabber et MSN.
On a alors plusieurs solutions pour cette interoperabilité : soit un seul protocole (mais inimaginable), soit plusieurs protocoles dans le messenger, soit des passerelles.
Jabber a fait le choix des passerelles (comme le telephone entre Fixe et Mobile), Gaim a fait le choix du multiportocole (comme le telehone mobile entre GSM et UMTS), je pense que comme pour le telephone c'est une addition des deux qui fonctionnera.
PS : en terme d'opérabilité dans le telephone mobile, desolé, j'utilise pas les passerelles, pour telephoner a un fixe j'utilise un fixe a coté de moi, comme quoi, ton exemple de telephone n'est vraiment pas bon, car en general on utilise au moins deux protocole auniveau du client (GSM, et RTC)... A moins que tu n'es pas d'abonnement fixe et que tu utilise qu'un telephone ;-)
[^] # Re: Centralise vs desentralise
Posté par Yth (Mastodon) . Évalué à 8.
Il est évident qu'on considère un "client" (ici le téléphone) se connectant à un "serveur" (l'antenne) parlant le même protocole.
Il n'est pas question de pouvoir téléphoner *de* n'importe où, mais bien *vers* n'importe où en ne "connaissant" qu'un unique protocole de communication, le GSM par exemple.
Avec les IM, si tu utilises jabber par exemple, il est *évident* que tu ne te connecteras pas à un serveur MSN. Mais là différence est là : tu es connecté au réseau parce que (intelligemment !) tu te connectes à un serveur jabber, et grâce aux passerelles : tu peux communiquer avec des gens sous Yahoo par exemple, ne connaissant qu'un unique protocole, et te connectant à quelqu'un qui te comprend.
La réciproque est fausse, si tu utilises ICQ, tu peux te gratter pour causer à quelqu'un sous jabber, MSN, Yahoo...
En bref, il te dit qu'avec les téléphones portables tu n'as *pas* besoin de te connecter à tout les réseaux pour communiquer sur tout les réseaux, un seul suffit et ceci parce qu'il y a des "passerelles" entre ces réseaux.
Et que pour les IM, c'est l'inverse, mais que jabber lui te permet de fonctionner de façon similaire, certes grâce à une sorte de bidouille, car il te faut quand même un compte sur les autres réseaux.
C'est, je le crains, toi qui confond l'accès à un réseau et l'accès à une autre personne sur un autre réseau...
Et euh perso, je n'ai pas de téléphone fixe, et pour appeler des gens, je suis 100% GSM de mon côté de la ligne, quel que soit le destinataire, et je ne m'en porte pas plus mal...
Et euh perso, je n'ai que jabber (psi + passerelles sur jabber.org.uk), et pour parler à des gens, je suis 100% jabber de mon côté de la ligne, quel que soit le destinataire, et je ne m'en porte pas plus mal...
Yth.
[^] # Re: Centralise vs desentralise
Posté par Yth (Mastodon) . Évalué à 10.
Par exemple, tu es en entreprise, ou en résidence estudiantine, il peut y avoir un serveur jabber local, permettant les communications locales directement sans pomper le tuyau vers internet, et la politique réseau est restrictive vers le net, ce qui t'empèche de te connecter directement sur tout tes protocoles exotiques d'IM que tu affectionnes.
Il suffit que l'admin laisse uniquement le serveur jabber accéder au net sans limitations pour que tu puisses multi-protocoler grâce à lui, et sans qu'il ait besoin d'installer les passerelles dessus, puisque tu peux en étant connecté sur un serveur, utiliser via lui les passerelles installées sur un autre !
De plus, comme pour par exemple MSN, tout n'est pas géré, en particulier le transfert de vir... fichiers, tu protège le réseau interne des nuées de vers, chevaux de troie, virus et compagnie qui se propagent allègrement sur ce merveilleux incub... réseau.
Donc dire comme ça "faut mettre tout sur le client et rien sur le serveur" c'est pas forcément super subtil, la réalité est (toujours) plus complexe et riche, et chiante, et frustrante, et passionnante, et désolante, et... Rhaaa !
Yth.
[^] # Re: Centralise vs desentralise
Posté par Maxime (site web personnel) . Évalué à 10.
[^] # Re: Centralise vs desentralise
Posté par Bonnefille Guilhem (site web personnel) . Évalué à 5.
Je crois que tu fais un petit amalgame.
Comme le montre les autres réponses à ton commentaire. les serveurs Jabber sont décentralisés justement. Contrairement à ICQ ou MSN, tu peux te connecter au serveur que tu préfère, celui de ton LUG, ton propre serveur, etc. du moment que ce serveur est connecté au autres tu "vois" le monde entier ;-).
Gaim n'embarque pas plus d'intelligence que n'importe quel client Jabber, si ce n'est que c'est un client multi-protocole. On peut rapprocher Gaim des navigateurs modernes qui savent faire du HTTP, du FTP et tous les trucs qu'on veut bien leur apprendre via les plugins and co.
Quand au fait qu'il y ait des serveurs pour les com. de type messagerie instantanée, je pense que c'est surtout parceque cela permet justement le instantané. En effet, en terme de IM/Chat réellement décentralisé (P2P) on peut citer MyJXTA2[1] qui est un vrai chat P2P. Le problème (à ce que j'en ai vu lors de mes petits tests) c'est que la détection des autres manque de réactivité. Mais sinon, c'est très séduisant.
[1] http://myjxta2.jxta.org/
[^] # Re: Centralise vs desentralise
Posté par tiennou_minet . Évalué à 10.
Au niveau de la philosophie d'internet, je ne suis pas tout à fait d'accord. En fait, effectivement, la philosophie d'Internet est de mettre l'intelligence au bord du réseau, c'est à dire de décentraliser. Cependant, quand tu regardes l'Internet actuel, tu comprends vite que le bord du réseau n'est pas l'utilisateur final mais le LAN. Chaque sous-réseau peut avoir son propre serveur Web, son propre serveur mail, son propre DNS, etc. En revanche, au niveau du client final, le but est qu'il reste le plus simple possible. On le voit bien au niveau du web, un client web n'est qu'une interface pour récupérer des informations qui sont générées au niveau du serveur. On appelle d'ailleurs ça un client léger.
Un système de messagerie instantanée complètement P2P ne serait pas forcément dénué d'intérêt mais aurait quand même beaucoup d'inconvénients. Ta liste de contacts serait locale (donc si tu changes de machine tu ne la retrouves pas), tu devrais t'authentifier auprès de tous tes contacts plutôt qu'auprès d'un serveur, etc.
[^] # Re: Centralise vs desentralise
Posté par manatlan (site web personnel) . Évalué à 4.
merci pour ta remarque qui a donné suite à un débat vraiment très instructif ! sans aucun troll, et vraiment passionnant ...
Je suis également un convaincu jabber, mais j'ai adoré le comparatif avec les gsm ... ça m'a expliqué pas mal de choses ...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.