Omega a écrit 104 commentaires

Donc pour toi SIP est un protocole figé ? Et il est interdit à des applications de rajoutés des fonctionnalités non prévues par le protocole ?

Il n'est pas possible de faire un protocole pour une chose aussi complexe que la téléphonie en prenant en compte toutes les possibilités, vu qu'on ne connait surement pas toutes les possibilités.

Les commandes ad-hoc c'est pas une bidouille. Et tu fais comment avec SIP pour créer une fonctionnalité qui n'est pas prévue dans le protocole de base ?

Et comment faire pour que deux softs implémentent la chose de la même façon puisque ce n'est pas défini ?
Et ben définissons le. Au début de SIP rien n'était définit non plus.

A mon sens, on ne verra jamais Jingle comme solution de ToIP. SIP règnera en maître sur ce créneau. Il finira également sans doute par remplacer XMPP pour la partie IM.
Ca m'étonnerait franchement que SIMPLE remplace XMPP. Perso je pense plutôt qu'on verra des solutions hybrides, en tout cas pour le moment. Dans tous les cas ce qui est important c'est que ce soit des standards ouverts qui dominent.

J'ai rien compris à ta réponse. la signalisation passe par le protocole.

Si tu veux pas faire ça avec un numéro spécial, tu peux utiliser les commandes ad-hoc de xmpp qui permettent de faire tout et n'importe quoi. Ca permettrait à un softphone de proposer une option intercept call et une liste de téléphone qui sonnent et auxquels ont peut répondre. Et pour ça y'a pas de yaka à faire, vu que le protocole existe déjà.

C'est pas de l'interception d'appel ça... c'est juste du multi-appel, et ça, même ma prise téléphonique cuivre me permet de le faire...
Si j'ai bien compris c'est tu tapes un numéro particulier et ça va te faire prendre la communication qui allait vers un autre poste, c'est bien ça ?

Dans ce cas je vois pas trop ce que le protocole vient faire la dedans, c'est plus un problème du serveur SIP ou Jingle, donc je vois pas ce qui empècherait de faire un serveur Jingle faisant ça. D'ailleurs peut-être ben qu'asterisk et son greffon jingle le font.

C'est pas de l'interception d'appel ça... c'est juste du multi-appel, et ça, même ma prise téléphonique cuivre me permet de le faire...
Ben explique moi ce qu'est l'interception d'appel alors.

Entre autre dans le cadre du PSTN, lors du call setting, le paquet traverse les différents commutateur, qui réserve la bp nécessaire.
elle est libérée lors de la rupture du call.
C'est pas SIP c'est le PSTN là, donc c'est la passerelle SIP<->PSTN qui réserve, une passerelle Jingle<->PSTN ferait pareil.

Le paquet SIP indiquant les différents paramètres de connexions utilisé (par le biais de SDP), cela permet aux différents équipement de savoir qu'un call est effectué et quel paquets prioritiser.
Y'a beaucoup de routeur qui vont analyser les paquets SIP pour faire de la QoS ? Et on peut faire de la QoS sans ça de toutes façons.

Le fait d'etre un standard IETF déjà usité par le monde industriel et l'ensemble des acteurs du marché, par exemple ...
Le fait d'être un standard largement déployé et dont la fiabilité n'a plus besoin d'être prouvée.
Ouais enfin je parle au niveau technique. Parce que bon si on part là dessus on peut dire que Linux n'a aucun avenir puisque la plupart des acteurs du marché l'ignore

Si tu veux mapper par contre de ton coté, regarde du coté de ce qu'implémente SS7, H323 et SIP... mais eux ils comprendront toujours rien quand tu emetra un call.

Parce que tu crois que les clients H323 et le PSTN comprennent SIP ? C'est des passerelles qui font la conversion, rien n'empèche de faire pareil pour Jingle..

Mais un jour faudra sortir de sa bulle et constater que d'autres ont fait d'autres choix que toi, et que si tu veux t'adapter, il faudra bien les suivre ces choix.
Si on suit ce raisonnement on avance pas vraiment. On fait comme avant, vu que ça marche pas trop mal.

Ca semble pas etre l'avis de tout le monde.(2 min de recherche et je trouve une lib lgpl pour sip : http://sofia-sip.sourceforge.net/ )
Et ? Ça veut pas dire que c'est pas compliqué, ça veut juste dire que c'est utile. Y'a plein de projets libres qui font des trucs utiles mais compliqués (genre Wine ou Samba).

- intercepter un appel à destination d'un collègue si on en a le droit
Qu'est qui empèche le serveur jingle d'envoyer l'appel aux deux clients ? Le premier qui répond prendrait l'appel.

- recevoir les indications de réception de messages vocaux
Suffirait de faire l'extension qui va bien, mais un truc du genre <query xmlns="xmpp:urn:audio-message><number>1</number><(...) devrait faire l'affaire. Bon après certes c'est pas standardisé pour l'instant, et si ce n'est pas fait on va se retrouver avec plein d'extensions proprio.

- effectuer un transfert à l'aveugle
- effectuer une transfert consultatif
Je sais pas ce que c'est donc je peux pas commenter, mais ça me semble plutôt des fonctionnalités au niveau du serveur, pas vraiment du protocol. Après depuis un client jabber pour effectuer ce genre d'action y'a les commandes ad-hoc.

- négociation des codecs vidéos avec paramétrage avancé
Je sais pas ce que tu appelles paramétrage avancé, mais comme le format utilisé par jingle est mappable à SDP (http://www.xmpp.org/extensions/xep-0180.html#sdp) on doit pouvoir faire grosso modo la même chose qu'avec SDP.

- changement de codec en cours d'appel
http://www.xmpp.org/extensions/xep-0166.html#session-modify

réservation de la bande passante par là ou passe le paquet SIP ?
C'est quoi l'intérêt ? Les paquets SIP ne nécessitent pas beaucoup de bande passante, vu qu'ils ne contiennent que les informations de signalisations. À moins que tu ne veuilles parler des paquet RTP. Mais même dans ce cas je vois pas trop comment SIP peut réserver la bande passante, ça se passe plutôt dans les couches inférieurs avec la QoS et je ne vois pas pourquoi un client Jingle ne pourrait pas réserver aussi la bande passante.

Une structure unifiée pour gérer les flux multimédias(qui ont les mêmes contraintes) , qu'ils viennent d'un IM, du PSTN, ...
?
Mais encore ? Qu'est-ce que fait SIP à ce niveau qui ne peut pas être fait par Jingle ? Suffit juste de pouvoir mapper les fonctionnalité du PSTN à Jingle, et si il manque des fonctions vu que XMPP est extensible rien n'empèche justement de l'étendre.

Vouloir refaire un SIP en jabber ne me semble pas forcément l'idée la plus efficace en terme de travail, de factorisation, d'utilisation des infras existantes, etc...
C'est un autre débat, certes ce n'est peut-être pas terrible niveau réutilisation de l'existant, mais SIP me parait beaucoup trop compliqué pour ce qu'on lui demande de faire 99% du temps.

SIP a une vision bien plus large et permet bien plus de choses que Jabber en ce qui concerne la voix et la vidéo.

Tu aurais des exemples ?

Spark implémente la XEP Attention. À ma connaissance c'est le seul.

Je ne pense pas que la vidéo soit intégrée un jour, il est compréhensible de devoir passer par un protocole autre (SIP) pour ça.

Ratai. Empathy supporte déjà Jingle (équivalent de SIP pour Jabber) et permet de faire de la voix et de la visio par jabber. Et ce n'est pas le seul client, sip-communicator supporte aussi jingle, et gajim a une branche le supportant.

Perso je vois pas ce que SIP apporte de plus que Jabber, à part la complexité. De toutes façons la partie difficile, le passage des NAT, s'effectue au niveau transport en utilisant la même technique pour SIP et jingle : ICE.

Je comptais bien sur ne pas me limiter au francophone, mais le problème étant qu'on ne peut pas choisir sa langue pour le randomchat pour le moment, et donc que certaines personnes pourraient ne pas se comprendre, ce qui serait vraiment dommage.

Nous comptons un jour ou l'autre implémenter le choix de la langue, et à ce moment nous en parlerons sur les ml de la xsf, et je pense que le programme ne s'adresse pas particulièrement à la mailing list social, en effet c'est pas un réseau social là, juste une manière de discuster, par contre j'en parlerais sur les listes jdev et juser bien sur.

Le but c'est pas de faire des rencontres galantes (c'est pas en postant sur linuxfr qu'on va attirer beaucoup d'utilisatrices de toutes façons). Le but c'est un peu de rencontrer n'importe qui, de parler de n'importe quoi, de délirer avec des gens qu'on ne connait pas.

D'ailleurs je me demande si y'a vraiment un but, mais les logiciels les plus inutiles ne sont-ils pas les plus indispensables ?

Ca ne doit pas exister.

Ton problème n'a rien à voir avec Gajim, mais avec la passerelle MSN que tu utilises, et je pense qu'il n'y a pas vraiment de solution, sauf faire un patch pour la passerelle MSN pour quelle supporte une version plus récente de MSNP.

s/Fake/Multi

Et par rapport à FileX [http://www.projet-plume.org/fiche/filex], c'est quoi la différence ? On utilise ça dans mon école et ça marche plutôt bien.

J'oubliais : Pandion n'est pas un logiciel libre, donc ça ne peut pas être un concurrent libre à Psi.

Un client n'est pas forcément bon juste parce qu'il a copié un peu l'interface graphique de MSNM. Et pour info j'ai testé ces deux clients, et je parle en connaissance de cause.

Non psi ne gère pas encore les métacontacts. Par contre ça devrait l'être dans un future plus ou moins proche vu que 2 des co-auteurs de la XEP sur les métacontacts sont les devs principaux de Psi (le 3ème auteur étant le dev principal de Gajim).

- meilleure gestion des ressources sous gajim
Tu veux dire quoi par ça ? Pour moi Psi et Gajim gèrent tous les deux très bien les ressources.

- meilleure gestion des statuts envoyés à chaque personne sous Psi (en fait on ne peut carrément pas le faire sous Gajim).
On ne peut pas le faire sous Psi, et on va pouvoir le faire sous gajim dans la prochaine version si je ne dis pas de bétises.

Attention, malgré le nom, Gajim n'a rien à voir avec Gaim.

Gajim est un client uniquement Jabber et qui fait bien son boulot (et qui gère nottament la découverte des services Jabber), alors que Gaim (qui s'appelle maintenant pidgin) est un client multi-protocole avec un support limité de jabber/XMPP.

Par contre, niveau sécurité, la confirmation passe par ton serveur Jabber, donc t'as intérêt à avoir confiance ... parce que on pourra hijacker la session facilement si on est un admin de serveur jabber (bon, juste le temps de la session).

L'admin du serveur OpenID peut aussi se faire passer pour toi, mais là c'est sur que ça rajoute un intermédiaire qui peut se connecter à ta place à tous les endroits où tu utilises openID.

À quand un id jabber pour tous (FT est un gros supporteur d'XMPP) ?

J'ai plutôt l'impression qu'on tend vers un windows live ID pour tous. Orange a arrêté son orange messenger depuis quelques mois au profit de « Orange messenger by windows live » qui utilise donc le réseau MSN.

De toutes façons je n'ai jamais compris la stratégie de FT/Wanadoo/Orange au niveau de Jabber. Orange messenger utilisait XMPP, mais la procédure de login n'était pas standart (donc c'était difficile de se logguer avec un client Jabber normal), et le serveur n'était pas ouvert au réseau Jabber public. Autant utiliser un protocole propriétaire si le but c'est de faire un réseau complètement fermé.