Damien Sandras a écrit 350 commentaires

Malheureusement, la plupart des problèmes de stabilité qu'Ekiga a rencontrés n'étaient pas dûs à Ekiga lui-même mais à l'utilisation avancée du multimédia sous Linux il y a 5 ou 6 ans, alors que Linux lui-même n'était pas prêt pour cela.

Je pense à diverses choses qui me rappellent la dure bataille que j'ai dû mener pour combattre certains de ces problèmes :
- le manque de support Full-Duplex dans la plupart des drivers OSS de l'époque
- l'arrivée d'ALSA, mais avec des bugs déclenchant des deadlocks du noyau en utilisation full-duplex
- la norme video4linux avec la plupart des drivers webcam complètement buggés et inutilisables, tout va mieux avec video4linux2
- l'arrivée de pulseaudio et son intégration d'office alors que la latence introduite par le démon rendait toute utilisation de piètre qualité
- les problèmes de GTK+ en environnement multi-thread
- les problèmes liés à GConf lors de son introduction dans les environnements GNOME
- …
et j'en oublie beaucoup…

Sans compter l'arrivée d'Ubuntu qui a recompilé la plupart des packages Debian sans jamais tester le produit compilé.

Ekiga, quant à lui, sur un environnement stable était testé pour pouvoir passer et prendre des milliers d'appels sans jamais planter ni présenter de fuites de mémoire.
C'est la raison pour laquelle tu trouveras sur le WEB beaucoup de rapports vantant la stabilité du produit, mais quelques-uns également se plaignant de la stabilité.

Ceci étant dit, merci pour ton commentaire plus que constructif.

Depuis quand le mot de passe SIP se balade-t-il en clair ?

D'autant qu'il y a aussi XMPP+Jingle qui devrait permettre des trucs sympas (quand ICE sera complet et intégré, si j'ai tout suivi).

Malheureusement, ICE, qui est aussi disponible avec SIP, ne résoud pas le problème du NAT symmétrique sans soutien d'un serveur public.

je ne compte pas risquer mon job en proposant une solution VoIP qui va _justement_ choisir de ne pas marcher au mauvais moment (ah ben oui m'sieur l'directeur, c'est normal que vous n'ayez pas pu appeler vos enfants depuis cet hôtel, leur NAT était symétrique).

Je ne comprends pas ce genre d'argumentaire pour plusieurs raisons que je vais brièvement soulever ici :
1) Skype est un fabuleux trou de sécurité. Personnellement, je ne risquerais pas mon job en proposant l'utilisation de Skype à ma direction.
2) le monde de l'industrie et des PBXs évolue vers SIP. Pourquoi ne pas pousser l'utilisation d'un IPBX compatible SIP au sein de l'entreprise et y connecter un softphone libre via un VPN ? Ca marche de manière infaillible, c'est sécurisé, et tu en as le contrôle.

Pour moi, Skype n'est qu'une solution de facilité, et la problématique du NAT, du moins en entreprise, n'en est pas une : un bon admin système configurera les choses pour bloquer Skype et faciliter le passage de SIP.

Au sein de la population des utilisateurs néophytes, la problématique est différente, il faut que ça fonctionne du premier coup, sans chipoter. On y arrive tout doucement car :
1) Beaucoup de modem/routeurs WIFI intègrent le support de SIP dans leur stack NAT, tout comme ils intègrent IRC ou FTP ;
2) La plupart des autres modem/routeurs WIFI fonctionnent en NAT non-symmétrique ;
3) Il reste toujours possible d'utiliser des proxies publics en dernier recours ;

Je pense que beaucoup d'entre vous confondent client voip et protocole de voip.

Skype est certes infaillibles pour passer NAT et pare-feux, tout simplement parce qu'il passe par un proxy externe. Ce proxy externe peut être n'importe qui avec une adresse IP publique.

SIP fait les choses de manière propre, du coup, il n'utilise pas n'importe qui sur le réseau pour relayer les communications.

Alors, que faut-il changer ? Le client VoIP qui supporte SIP, ou créer encore un nouveau protocole qui n'aura pas le soutien du monde de l'industrie ?

Et sous Windows, X-Lite, par exemple.

Voir :
http://wiki.ekiga.org/index.php/Ekiga_Interoperability

Il y a foule de softs SIP sous windows. Notamment, X-Lite par exemple.
La version WIN32 est toujours d'actualité, mais on manque de développeurs talentueux sur cette merveilleuse plateforme.

A noter qu'on sait même envoyer des SMS. Tu rentres un numero de GSM dans le roster, et à partir de là, soit tu ouvres un "chat", c'est le SMS, soit tu fais un "appel".

Oui.

Alors il suffit de réunir une équipe commerciale, une équipe de développeurs, de créer un nouveau protocole et d'investir dans les infrastructures serveurs nécessaires...

De ton point de vue, qu'est ce qui rend SIP difficile à appréhender pour l'utilisateur lambda (c'est une vraie question) ?

Le fait que pour l'instant, le grand public, la seule chose qui l'intéresse, c'est MSN ou Skype, tout simplement...

Alors vas lui parler de client SIP...

Reste à voir si SIP est vraiment fait pour le type de personnes que tu décris.

A l'heure actuelle, peut-être pas.

Je pense que ce problème est limité par le fait qu'il existe d'excellentes solutions supportant SIP (ou H.323) sous Windows.

Maintenant, pourquoi Ekiga n'est-il pas supporté officiellement sous Windows ?

C'est regrettable, en effet :
- nous avons une build qui fonctionne
- nous avons un support DirectVideo pour la capture video
- nous avons un support DirectDraw pour l'affichate
- nous avons relativement peu de bugs connus

Cependant, nous n'avons personne pour maintenir cette version. Maintenir, signifie corriger les bugs spécifiques à cette plateforme.

Mon temps libre ne me permet pas de le faire. Donc si quelqu'un qui lit ceci a des affinités avec windows ou connaît quelqu'un avec de telles affinités, sachez que la masse de travail à accomplir est minime, mais qu'il faut néanmoins quelqu'un.

SIP a tendance à avoir besoin d'une moule'titude de ports différents ce qui rend conntrack difficile.

Tout comme Jingle, SIP utilise RTP et un port pour la signalisation SIP, donc c'est pareil.

Avec Pidgin qui s'y met également, la VoIP débarquent enfin dans les solutions libres (tant logiciel que protocoles).

C'est pas trop tôt !

Sans vouloir faire celui qui se vexe pour un rien, GnomeMeeting, en 2001, c'était pas aussi de la VoIP ?

Qu'avez-vous fait pour l'instant, en ce qui concerne la présence et l'IM par XMPP ?

Pour l'instant rien, même si nous avons une architecture qui permet à présent d'intégrer XMPP.

Cependant, restons terre à terre. Ekiga est un projet purement libre, que je maintiens depuis 8 ans, en plus des lourdes responsabilités qui me sont assignées au niveau de ma boîte.

A l'heure actuelle, mon point de vue est que Jabber devrait arrêter d'essayer de faire de la VoIP et SIP devrait arrêter d'essayer de faire de l'IM et de la présence. Le client idéal est donc un client qui supporte les deux. L'avenir dira si SIP/SIMPLE réussit à remplacer XMPP ou pas.

Ekiga ne possède pas suffisamment de contributeurs pour ajouter le support Jabber. Mais si quelqu'un se propose (en réutilisant une librairie), ce n'est pas si compliqué que cela. Tout ce qu'il faut est un mainteneur.

Nous avons déjà une personne pour SIP (moi), une personne pour les codecs (Matthias), plusieurs personnes pour Ekiga (Julien et moi), il suffit d'avoir une personne supplémentaire pour XMPP. Je ne suis vraiment pas contre.

Je suis juste contre MSN, ICQ, et consorts...

(il serait bon d'arrêter de réfléchir à intégrer XMPP à Ekiga, mais le faire réellement...)

Tu as du temps libre ?

Et comment faire pour que deux softs implémentent la chose de la même façon puisque ce n'est pas défini ?

Là réside tous le problème.

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.

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

Dans ce cas, ce n'est pas fait en signalisation pure, mais via un artifice...

Pour résumer tes réponses, il y a beaucoup de "yaka".

Quelques exemples triviaux :
- intercepter un appel à destination d'un collègue si on en a le droit
- recevoir les indications de réception de messages vocaux
- effectuer un transfert à l'aveugle
- effectuer une transfert consultatif
- négociation des codecs vidéos avec paramétrage avancé
- changement de codec en cours d'appel
- Shared Line Appearance (difficile de traduire)
- ...

Je continue ?

Perso je vois pas ce que SIP apporte de plus que Jabber

C'est parce que tu penses en terme de "chat" et pas de "téléphonie". 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.

C'est comme comparer des patins à roulettes avec un avions à réaction... :-)

Non, c'était juste un problème réseau chez neuf...

Ekiga.net vient de tomber. Pas de bol. Ca n'était plus arrivé depuis une panne de courant il y a un an...

Les causes du retard ?

Des changements trop nombreux, trop ambitieux, et un mainteneur qui a été très très occupé. Cependant, ça progresse assez bien dernièrement.

Je pense que nous allons bientôt sortir une première BETA, et sans doute la 3.00 sortira-t-elle avant GNOME 2.24.

Mentionnons aussi que si Sun était présent l'an dernier, il faut noter que :
- SUN n'avait pas de stand commercial
- la raison en était simplement que les leaders des projets invités étaient employés par SUN

A l'heure actuelle, la majorité des projects leaders sont employés par SUN, RedHat ou google.

Tout d'abord, ce n'est pas Nicolas Pettiaux qui a initié le FOSDEM, mais Raphaël Bauduin.

Ensuite, voici l'historique.

Courant 2000, nous avions organisé un événement Linux sur Louvain-La-Neuve en Belgique, et j'y ai rencontré Raphaël.

Peu après (je ne saurais plus dire quand exactement), Raphaël m'a contacté pour me demander si j'étais d'accord de l'aider à monter un événement 100% dédié aux développeurs du libre. Les exposés y seraient très techniques de manière à n'attirer que des développeurs, pas des débutants GNU/Linux. L'idée était novatrice, car toutes les manifestations étaient orientées "utilisateurs/grand public" et nous voulions faire quelque chose orienté "développeurs".

Raphaël, Renaud Larssen, et moi-même avons donc démarré le FOSDEM (OSDEM à cette époque) suivant ce principe. J'ai par la suite quitté l'organisation du FOSDEM (cette année), mais c'est une autre histoire.

Je confirme donc bien que Nicolas Pettiaux n'est pas à l'origine du FOSDEM, et que le FOSDEM a une orientation très différente des RMLL : si tu ne sais pas coder, tu n'y as pas ta place... Il s'agit donc probablement du plus grand événement international pour développeurs.

La plupart des grandes figures du libre que j'ai pu inviter ont pu le confirmer au fur et à mesure des éditions.