http://halr9000.com/article/243
Deux JEP ont été proposées par des tits-gars de Google : la signalisation de VoIP sur le protocole Jabber (XMPP), voici donc les détails de leur protocole maison, ça s'appelle Jingle. Ils ont annoncé, ils l'ont fait, même s'ils ont mis du temps, donc yapuka.
Ces spécifications sont sont accessibles à tous et implémentables par tous les développeurs de clients et serveurs Jabber. Elles ne sont toutefois qu'au stade de proposition et ne sont pas encore acceptées telles qu'elles par la Jabber Software Foundation. Il va donc s'ensuivre un processus de révision et validation du bébé. A priori, ça devrait aller assez vite, car c'est déjà implémenté et validé par Google Talk.
Tout le monde voudrait intégrer Jabber et SIP, mais personne ne le fait réellement... ces JEPs sont co-rédigées par Peter Saint-André, le boss de la Jabber Software Foundation.
Journal Jingle : la VoIP sur Jabber, made in Google
12
déc.
2005
# Commentaire supprimé
Posté par Anonyme . Évalué à 4.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Re:
Posté par Khâpin (site web personnel) . Évalué à 8.
Jabber Enhancement Proposal
# Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
# ...
Posté par Marc (site web personnel) . Évalué à 7.
les personnes visées apprécieront je pense. Je crois qu'elles seront aussi d'accord pour dire qu'elles n'ont pas le poid de Google, mais ce n'est pas une raison pour rabaisser leur taf. Je ne m'y connais pas assez dans le domaine, mais je suis presque sûr que leurs efforts ne sont pas inutiles :)
[^] # Re: ...
Posté par Maclag . Évalué à 2.
Se déchirer la tête pendant des mois pour implémenter un protocole de VoIP sur jabber, sachant que peut-être il ne sera jamais accepté alors qu'un autre si, ben moi ça me rebuterait déjà pas mal!
Merci à Google de mettre son poids dans la balance, et dommage qu'il faille ça pour que jabber avance!
[^] # Re: ...
Posté par benja . Évalué à 7.
Encore une fois, laisser sous-entendre que c'est grâce à Google que cela avance est totalement faux et est encore plus réducteur du travail effectué par les autres développeurs.
Extrait de l'introduction de la jep^W^W la proposition de jep:
As a result of feedback received on JEP-0111, the second and fourth authors of this document began to define such a signalling protocol, code-named Jingle. Upon communication with members of the Google Talk team, it was discovered that the emerging Jingle approach was conceptually (and even syntactically) quite similar to the signalling protocol used in the Google Talk application. Therefore, in the interest of interoperability and adoption, we decided to harmonize the two approaches. The signalling protocol specified therein is, therefore, substantially equivalent to the existing Google Talk protocol, with several adjustments based on feedback received from implementors as well as for publication within the Jabber Software Foundation's standards process.
Donc en gros il s'agit plus de l'évolution d'une précédente JEP écrite par Peter Saint-Andre et Joe Hildebrand qui s'est trouvée être fort proche du protocole de Google Talk. Il s'en est suivit un travail d'harmonisation avec les gars de google qui fait que Google Talk implémente déja ce protocole.
[^] # Re: ...
Posté par Bruce Le Nain (site web personnel) . Évalué à 6.
Il disait justement que les développeurs faisaient un travail ingrat en développant des JEP qui mettent des siècles à être validés (c'est à dire sortir du statut draft, ou proposed vers expérimental, sans même encore parler d'implémentation...)
je me répète par rapport à un de mes commentaires précédents, mais Il y a des nombreux jep en attente, j'ai l'impression que tout a plus ou moins été développé pour correspondre aux attentes pro, perso, geek, kikoolol concernant jabber : les émoticônes/genicônes personalisés ( http://www.theoretic.com/proposals/list , la page des icônes semble avoir disparu... ) les flux multimedia ( JEP media streams (vidéo audio) dans jabber :
http://delta.affinix.com/specs/jep-media.html
JEP streaming
http://delta.affinix.com/specs/jep-rtsp.html ) les jeux, les tableaux blancs les tic tac toe, les avatars (statut expérimental sur http://www.jabber.org/jeps/jeplist.shtml ), les wizz fuck...
Il y a une longue liste d'attente, et voilà un petit message explicatif de Justin Karneges (début de l'année certes)
( http://mail.jabber.org/pipermail/standards-jig/2005-February(...) )
En résumé, pour certains, à la JSF, ils tardent, pour d'autres ils prennent des précautions. Jabber est aussi un protocole fait pour durer, pas uniquement pour concurencer et écraser tout sur son passage en deux mois. C'est peut-être un tort, tout le monde n'est pas obligé d'agir selon le même référentiel.
Jabber c'est plus qu'un logiciel de chat, c'est une techno structurée, ayant pour but de pouvoir s'intégrer à de nombreuses architectures. Certaines entreprises y croient. Et surtout de plus en plus d'utilisateurs.
Google peut faire accélerer les choses ? Espérons dans ce cas que ça soit dans la bonne direction. Peut-être est-ce ce qui manquait à Jabber.
# Enfin!
Posté par keyes . Évalué à 7.
Le non-support du son et surtout de la vidéo pour les protocoles IM très utilisés (je ne parle donc pas de GnomeMeeting) rebuté vraiment les utilisateurs de Windows à migrer sous Linux, mais tout s'arrange!
Le Kopete intégré à KDE 3.5 supporte la webcam pour la plupart des protocoles dont MSN. Gaim 2.0 qui sortira à la fin du moi supportera lui aussi le son et la vidéo (fusion avec Gaim-vv).
Wengo devient de plus en plus stable (vidéo et son).
Le support de Google Talk avec la publication de ces spécifications ne saurait tarder, surtout que Google a embauché le développeur principal de Gaim pour rendre les principaux clients IM libres compatibles avec Google Talk.
Seul petit bémol pour Skype, même s'il existe un portage sous Linux il devient vraiment peu utilisable (OSS, bugs, non-support des nouvelles fonctionnalités incluses dans la version Windows).
Mais bon contrairement aux autres que j'ai cité, Skype n'est pas libre. Autant ne pas le privilégier.
[^] # Re: Enfin!
Posté par locnet . Évalué à 2.
Arreter moi si je me trompe, mais Kopete supporte la video, pas le son des webcam.
C'est pas un détail, je trouve.
[^] # Re: Enfin!
Posté par Jiel (site web personnel) . Évalué à 10.
Et il supporte la vidéo des micros? ;-)
[^] # Re: Enfin!
Posté par djibb (site web personnel) . Évalué à 2.
Peut etre attendent -t-ils que ce soit implementer ds Jabber pour le rendre fonctionnel ;)
[^] # Re: Enfin!
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 4.
Concernant le son sur msn, il y a aussi du travail en cours, mais le gas veut finir celui sur jabber d'abord.
[^] # Re: Enfin!
Posté par Alex . Évalué à 2.
Si quelqu'un veut aider qu'il n'hésite pas, le code est clair et l'équipe sympathique. Le seul truc un peu "chiant" est que tout code étendant le proto doit être soumis à l'équipe de psy (kopete reutilise libiris développé pour psy).
[^] # Re: Enfin!
Posté par Nicolas Schoonbroodt . Évalué à 6.
[^] # Re: Enfin!
Posté par golum . Évalué à 3.
[^] # Re: Enfin!
Posté par Alex . Évalué à 1.
[^] # Re: Enfin!
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 2.
Sinon, je confirme, l'équipe est tres sympatique, vraiment !
[^] # Re: Enfin!
Posté par Michaël Larouche . Évalué à 1.
Pour la maintenance du plugin Jabber, je crois qu'on va se partager ça moi et Gof. On a discutté de nos plans pour KDE4 concernant Jabber l'autre jour sur IRC. Gof va plus s'occuper de la vidéo et de la voix, et faire le mappage transport<->Kopete::Account, tandis que moi la voix aussi, le Multi-User-Chat, et le Service Discovery
[^] # Re: Enfin!
Posté par Gof (site web personnel) . Évalué à 2.
Il faut juste que je trouve le temps, entre l'unif et la vrai vie :-)
(enfin pas vraiment la vrai vie)
(déjà, faudrais que j'arrête linuxfr, ça augmenterais ma productivité)
# plus vite que la musique
Posté par thaodalf . Évalué à 4.
faudrais pas partir du fait que googletalk l'implemente déjà pour l'accepter sans retenue et directement. j'ai l'impression qu'ils grillent les étapes et cherchent à imposer leur protocole/design par le fait que celui-ci fonctionne déjà sur leur logiciel maison.
si jabber refuse pour une raison x ou y, google va t'il accepter de revoir sa copie ? même si ils sont libre d'utiliser ou nom leur protocole maison il ne faudrait pas que cela disperse les gens et entraine de la confusion auprés du public (mon jabber video google ne fonctionne pas avec mon jabber video truc).
[^] # Re: plus vite que la musique
Posté par Bruce Le Nain (site web personnel) . Évalué à 4.
La mémoire collective s'efface vite... nous y repenserons quand nous aurons des serveurs "optimisés pour" google talk en 1280 * 1024...
[^] # Re: plus vite que la musique
Posté par Thomas Douillard . Évalué à 3.
[^] # Re: plus vite que la musique
Posté par Talou (site web personnel) . Évalué à 1.
Le jabber council meeting se tenait hier : http://www.jabber.org/muc-logs/council@conference.jabber.org(...)
les points 9 et 10 concernaient Jingle d'après http://www.jabber.org/council/meetings/agendas/2005-12-14.ht(...) .
Il semblerait que les JEPs aient été acceptés.
# SIP ou pas ?
Posté par GrosBenny . Évalué à 3.
http://www.google.com/talk/developer.html
Mais bon, on dirait qu'ils ne sont pas surs non plus... Ils definissent une sorte d'intéropérabilité (qui se ferait peut etre sur les serveurs, comme les gateways actuelles ?)
http://www.jabber.org/jeps/inbox/jingle.html
# XMPP ou SIP?
Posté par Zenitram (site web personnel) . Évalué à 2.
[^] # Re: XMPP ou SIP?
Posté par Johann Ollivier-Lapeyre (site web personnel) . Évalué à 2.
Je ne sais pas si SIP sera forcement utilisé. Faudra que je lise cette JEP autrement qu'en diagonale pour ça. :-)
[^] # Re: XMPP ou SIP?
Posté par GrosBenny . Évalué à 2.
Le problème est là, est-ce que cela vaut le coup de faire un demi choix avec XMPP+SIP, ou alors de lacher XMPP et de prendre l'ensemble SIP+SIMPLE. (Résumé simpliste qui ne tiens pas compte des avantages de chacun).
[^] # Re: XMPP ou SIP?
Posté par fredix . Évalué à 2.
[^] # Re: XMPP ou SIP?
Posté par duf . Évalué à 0.
Donc si le choix se porte sur MSN Messenger pour ces opérateurs, comme l'a fait Bouygues pour booster son imode, demain que va-t-il se passer pour Jabber ? Qui voudra l'utiliser alors que les gens pourront avoir un seul et même IM sur leur ordinateur et leur téléphone portable....
Moi je pense que c'est en ce moment que ça se joue et qu'il ne faut pas hésiter à mettre une croix sur XMPP et passer à SIP (pour la présence xcap existe).
Enfin bon chacun fait ce qu'il veut.
[^] # Re: XMPP ou SIP?
Posté par tiennou_minet . Évalué à 10.
Ca n'engage que toi, je trouve que ça bouge beaucoup au niveau de Jabber, tant au niveau des protocoles que des implantations. Je précise aussi que le fait que Jabber ne soit pas très avancé au niveau du support de la voix et de la vidéo ne signifie pas que Jabber fait du sur place. Les autres possibilités de Jabber ne t'intéressent peut-être pas mais le réseau ne s'en développe pas moins.
SIP et ses extensions pour la messagerie instantanée SIMPLE ont leurs supportaires (notamment Microsoft et IBM) et c'est certainement le marché qui décidera lequel s'imposera. Pour ma part, je supporte activement XMPP qui me paraît beaucoup plus intéressant sur de nombreux plans.
D'abord, effectivement SIP se développe bien dans le domaine de la téléphonie sur IP pure. Par contre, au niveau de la messagerie instantanée, SIP/SIMPLE a des années de retard sur Jabber. Le(s) protocole(s) est encore très largement incomplet et en développement et les seules implantations dignes d'intérêt et disponibles actuellement (aussi bien client que serveur) sont propriétaires et largement incompatibles entre elles. Au niveau du protocole, tu peux regarder le tableau suivant pour avoir une idée de tout ce qui manque :
http://www.jabber.org/protocol/xmpp-simple.shtml
En terme d'architecture, le modèle de type P2P de SIP est bien adapté à la transmission de flux multi-média mais il pose de nombreux problèmes dans le cadre d'un système de messagerie instantanée :
- comme SIP, SIP/SIMPLE pose des problèmes dans les environnement de type NAT ;
- SIP/SIMPLE pose des problèmes de passage à l'échelle. D'une part, les messages SIP/SIMPLE sont encore plus verbeux que les messages XMPP (tous les messages contiennent toutes les informations de connexion car il n'y a pas de notion de session comme pour pour XMPP, etc.) mais en plus SIP/SIMPLE génère beaucoup plus de messages. Par exemple, sous Jabber quand tu changes ton état de présence (disponible->absent), un seul message de présence est envoyé à ton serveur et le message est ensuite diffusé à tous tes contacts. Sous SIP/SIMPLE, quand tu changes ton état de présence, ton client envoie directement un message de présence à chacun de tes contacts. Sous XMPP, les messages ont donc plus tendance à être concentrés au niveau du coeur de réseau et pour SIP au niveau des liens terminaux. Sur un réseau local avec beaucoup de clients ayant chacun beaucoup de contacts, la différence peut devenir significative (surtout si les messages de présence commencent à contenir des photos, etc.). Pour ces questions, un livre blanc très intéressant est disponible sur le site de jabber.com mais il faut s'inscrire pour pouvoir le télécharger ;
- SIP/SIMPLE pose des problèmes au niveau de l'administration d'un réseau. Sous Jabber, tous les messages passent par le serveur. Il est donc facile de logger les messages (obligation juridique pour les entreprises de certains pays), de ne permettre que certains types de messages, etc. Sous SIP/SIMPLE, les messages sont échangés de pair à pair entre utilisateurs donc il est beaucoup plus difficile d'administrer le réseau.
SIP/SIMPLE est donc peut-être mieux adapté à certains types d'environnements spécifiques (lesquels ?) mais XMPP est pour l'instant très en avance et me paraît beaucoup plus prometteur.
Cela dit, si tu administres un serveur public (enfin pas serveur au sens de Jabber mais un registrar et un proxy SIP) SIP/SIMPLE et que tu as un bon client libre à me proposer pour que j'essaie, je serais heureux de me tromper ;-)
[^] # Re: XMPP ou SIP?
Posté par Zenitram (site web personnel) . Évalué à 5.
C'est une partie très visible, faudrait que ca change... :(
Ah ca, pour etre verbeux, SIP l'est! ;-)
La, on en vient a parler d'architecture : centralisé contre décentralisé.
Le décentralisé "a la SIP" a ses avantages : pas de charge serveur (pour ton exemple, c'est le serveur qui se tape le boulot, le goulot d'etranglement est donc au niveau du serveur...), pas de log (ca peut interesser les gens portés sur la vie privée. A noter que des études sur SIP sont en cours pour changer ca, genre pour les interceptions légales ;-) )
Mais : SIP est plus supporté par les opérateurs, et les opérateurs peuvent imposer leur choix... Je n'ai pas de client a proposer, j'ai juste eu une formation sur SIP, et j'ai vu les possiblilités de la chose (pas que SIMPLE). Le probleme est que XMPP fait concurence "seulement" a SIMPLE, tandis que SIP (et l'IMS) font bien plus, les operateurs risquent de pas vouloir s'embeter avec un protocole supplémentaire.
Je ne supporte ni l'un, ni l'autre, je me pose des questions, c'est tout. SIP est peut-etre un trop gros projet qui va s'effondrer tout seul du fait d'une masse critique, on verra... j'utilise Jabber en attendant ;-)
[^] # Re: XMPP ou SIP?
Posté par tiennou_minet . Évalué à 2.
Justement, l'impression que j'ai, pour l'instant confirmée par la situation actuelle, c'est que SIP/SIMPLE est une technologie puissante mais lourde à mettre en place et qui me paraît réservée aux opérateurs ou en tout cas à des gros de l'informatique. Pour l'instant XMPP est de loin le plus utilisé par les utilisateurs de la base (site communautaires, personnels, entreprises, etc.) et SIP est plus développé chez les opérateurs. A un certain point, chaque groupe va vouloir rallier l'autre à sa cause et il est difficile de dire maintenant ce qu'il en résultera.
En tout cas, qu'on tende vers l'un ou l'autre ou encore un mélange des deux, si on tend vers plus d'ouverture ça m'ira parfaitement.
[^] # Re: XMPP ou SIP?
Posté par Damien Sandras (site web personnel) . Évalué à 3.
Pas forcément si on passe par le serveur, mais ce n'est pas entièrement faux.
- "Sous SIP/SIMPLE, quand tu changes ton état de présence, ton client envoie directement un message de présence à chacun de tes contacts."
Non, tu envoies un message "PUBLISH" au serveur, et le serveur relaie l'information.
- "Sous SIP/SIMPLE, les messages sont échangés de pair à pair entre utilisateurs donc il est beaucoup plus difficile d'administrer le réseau."
Non encore, tu configures ton proxy en "Record-Route" et tous les messages de signalisation passeront par lui.
[^] # Re: XMPP ou SIP?
Posté par Geo Vah . Évalué à 1.
Pas forcément si on passe par le serveur, mais ce n'est pas entièrement faux.
Ayant bosser en stage pour un concepteur de puce modem ADSL , j'ai bien vu le problem de SIP et la VOIP avec du NAT : le modem modifiait les paquets de type SIP pour changer l'adresse de l'émetteur, donc oui il a des problemes, d'ailleurs le client se plaignait que son téléphone SIP ne marchait pas avec ce modem...
[^] # Re: XMPP ou SIP?
Posté par Damien Sandras (site web personnel) . Évalué à 2.
[^] # Re: XMPP ou SIP?
Posté par Mr F . Évalué à 2.
# NAT
Posté par Alban Crequy (site web personnel) . Évalué à 1.
Il me semble qu'avec Skype ça marche: je crois que lorsque les 2 correspondants sont derrière un NAT, un gentil proxy (un autre utilisateur quelconque de Skype qui n'utilise pas de NAT) route les données.
Quelqu'un pour confirmer?
[^] # Re: NAT
Posté par Nicolas Schoonbroodt . Évalué à 2.
[1] http://www.jabber.org/jeps/inbox/jingle.html
[^] # Re: NAT
Posté par tiennou_minet . Évalué à 4.
Oui Jingle prévoit l'utilisation d'un proxy pour passer les NAT et Google en a un pour son GTalk donc pas de problème pour passer les NAT avec GTalk. Par contre, comme le protocole est tout frais (même pas encore finalisé), aucun proxy libre pour ce protocole n'existe à l'heure actuelle. Le problème pour mettre en place un proxy pour les flux multimédia au niveau de petits serveurs se posera surtout à propos de la bande passante nécessaire à ce genre de services. A mon avis, c'est le genre de service qui restera longtemps réservé aux sociétés commerciales capables de s'offrir la bande passante nécessaire.
[^] # Re: NAT
Posté par sylware . Évalué à 3.
[^] # Re: NAT
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Grace au NAT, nous avons plein de problème alors que sans lui, on aurait déjà un IPv6 opérationel.
# y a pas que google dans la vie...
Posté par psychoslave__ (site web personnel) . Évalué à 2.
http://www.tipic.com/taxonomy/view/or/29
un résumé?
Tipic Inc. launches the first Open Source, P2P, VoIP and Video conferencing solution for XMPP/Jabber.
Voila, merci Tipic Inc.
[^] # Re: y a pas que google dans la vie...
Posté par golum . Évalué à 3.
Saluons l'initiative mais regrettons qu'il faille que ce soit à reculons qu'ils se lancent dans le libre.Si Google n'avait pas été là , je ne suis pas sûr qu'ils auraient eu la même démarche.
[^] # Re: y a pas que google dans la vie...
Posté par Damien Sandras (site web personnel) . Évalué à 3.
[^] # Re: y a pas que google dans la vie...
Posté par Eric Streit . Évalué à 1.
Eric!
--------
[^] # Re: y a pas que google dans la vie...
Posté par Damien Sandras (site web personnel) . Évalué à 3.
[^] # Re: y a pas que google dans la vie...
Posté par Eric Streit . Évalué à 3.
Eric!
-------
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.