Journal Support de Jingle pour SIP-Communicator

Posté par  (site web personnel) .
Étiquettes :
8
26
nov.
2010
Cher journal,

SIP-Communicator [http://sip-communicator.org], le logiciel libre multiplateforme de "VOix sur IP" (VOIP) et de messagerie instantanée, vient tout juste d'ajouter la gestion de Jingle.

SIP-Communicator est un acteur de la communication libre depuis 2005 (date de la première release sur java.net) plus de 25 développeurs actifs, participations aux FOSDEM depuis 2006 et au GSoC depuis 2007. Il aura tout de même fallu plus d'une année de développement pour ajouter la gestion de Jingle aux nombreuses fonctionnalités déjà intégrées (téléphone/vidéo SIP avec encryption ZRTP, Jabber/XMPP, ICQ, MSN, AIM, Facebook, zeroconf, etc.).

Qu'est-ce que Jingle ? C'est une extension de XMPP permettant de réaliser des échanges multimédias (par exemple téléphonie et vidéoconférence) qui était surtout connue grâce à la "libjingle" qui est une implémentation réalisé pour Google Talk sous licence BSD.

Pour le moment la prise en charge de Jingle dans SIP-Communicator permet de réaliser :
  • Des appels de 1 vers 1 ;
  • Des appels vidéo ;
  • Le support "basic" d'appels en mode conférence ;
  • et pleins d'autres choses à découvrir.
Bien que la gestion de Jingle soit encore en phase de tests (v0.1), il est néanmoins d'ores et déjà totalement fonctionnel. C'est donc le moment de télécharger la dernière version de SIP-Communicator et de tester cette nouvelle fonctionnalité en faisant remonter les éventuels problèmes et les différents bugs restants.
  • # Trucs que je pige pas.

    Posté par  . Évalué à 4.

    Tiens, j'en profite pour poser des questions chiantes:

    - Ça faisait longtemps qu'on avait, sous Jabber, des technologies de passage de NAT qui marchaient plutôt bien, pour s'envoyer des fichiers. Ça s'est amélioré avec le temps, et depuis.. je dirais, 1 ou 2 ans, il n'y a pas de problème pour s'envoyer un fichier via Jabber en étant chacun derrière un modem-routeur domestique. Alors pourquoi Jingle a mis du temps à vraiment fonctionner correctement?

    Comment se fait-il que le passage de NAT pour un flux audio/vidéo ait été en retard sur le passage de NAT pour un flux fichier? Où est la différence?

    - La dernière fois que j'ai voulu tester l'audio/vidéo sur Jabber, je me suis bouffé des freezes sur la webcam, le flux audio marchait pas terrible non plus. Pourtant, en testant la lecture du flux webcam avec VLC ou Camorama, ça juste marche très bien. J'ai même pu streamer ma webcam avec VLC (horribles les options de config, horribles) via un VPN et ça marchait mieux qu'avec Jabber.

    Comment se fait-il que le flux audio/vidéo soit aussi contrariant via Jingle alors qu'avec d'autres outils ça juste marche?

    J'arrive pas à comprendre pourquoi c'est si compliqué de prendre un "traverseur de NAT" qui marche et des pilotes audio/vidéo qui marchent et de causer avec.

    Question subsidiaire de parano: à quand le support de GPG pour les flux transportés par Jingle?

    THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

    • [^] # Re: Trucs que je pige pas.

      Posté par  . Évalué à 2.

      Comment se fait-il que le passage de NAT pour un flux audio/vidéo ait été en retard sur le passage de NAT pour un flux fichier? Où est la différence?

      Je dis peut-être une grosse connerie, mais il me semble que le transfert de fichiers via Jabber n'a utilisé un "vrai" passage de NAT (comprendre à base de "hole punching") que très récemment, voire pas du tout. Autant que je sache, c'est juste que ça pouvait utiliser le serveur Jabber comme "file transfer proxy" en cas de besoin.

      Si c'est le cas, tout s'explique : ce qui est acceptable pour du transfert de fichier (un peu plus de latence? bouarf!) est gênant sur de la voix/vidéo.
      • [^] # Re: Trucs que je pige pas.

        Posté par  . Évalué à 3.

        Je crois pas. Le transfert de fichier sur un même LAN a toujours été très rapide (j'ai testé y'a plus d'un an), à la vitesse du LAN ou des disques durs (bien plus que l'upload de mon ADSL, en tout cas).
        Alors que, récemment (y'a quelques mois, lors de la première version de Gajim avec support de jingle) l'audio/vidéo en LAN c'était pas encore ça.

        THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.

        • [^] # Re: Trucs que je pige pas.

          Posté par  (site web personnel) . Évalué à 3.

          Si je ne me trompe pas le transfert de fichier utilisant Jingle [http://xmpp.org/extensions/xep-0234.html] essaie en premier lieu de créer une connexion directe du type SOCKS5 Bytestreams ("S5B") qui d'après le XEP cité ci-dessus : "does not always result in NAT or firewall traversal.". Dans le cas où la connexion ne peut pas être établie en SOCKS5 Bytestreams ("S5B"), le client peut en dernier recours créer une connexion utilisant le mécanisme In-Band Bytestreams ("IBB") [http://xmpp.org/extensions/xep-0047.html] qui lui peut être relayé par le serveur, ce qui supprime les problèmes de traversé de NAT et de firewall.

          Toujours d'après mes souvenirs, concernant le multimédia pour Jingle (notamment téléphonie et vidéoconférence), seule la connexion directe entre les pairs est autorisée. Ce qui pour Jingle nécessite l'implémentation de ICE. Pour SIP-Communicator qui est en java cela a donné lieu à pas mal de travail pour développer la librairie ice4j [http://code.google.com/p/ice4j/] qui inclue en autre les mécanismes TURN et STUN.

          Enfin concernant les problèmes de "freeze" de caméra et pour l'ajout de GPG, les retours de bugs ainsi que les demandes de nouvelles fonctionnalités sont toujours les bienvenus sur la liste de développement (dev@sip-communicator.dev.java.net).
    • [^] # Re: Trucs que je pige pas.

      Posté par  (site web personnel, Mastodon) . Évalué à 2.

      Le transfert de fichier c'est bien sur le papier, mais pas toujours en pratique avec xmpp:

      - les 2 modes obligatoires sont socks5 (out-band) et via un flux xml en interne (in-band). Le premier ça peut être la galère s'il y a un NAT, le deuxième marche toujours mais c'est (potentiellement) lent et ça met à contribution le serveur.
      - on peut utiliser un proxy avec l'out-band, mieux pour les NAT, mais re-problème d'une machine au milieu
      - le in-band n'est pas toujours implémenté (genre gajim: certains dév n'aiment pas du tout si je me souviens bien)
      - il y d'autre possibilités, mais c'est principalement ces 2 là qui sont utilisées, cf xep-0096
      - psy utilise un protocole à lui, qui n'est pas (encore ?) une xep mais qui est documenté sur son site, qui passe bien les nat mais pose parfois des problèmes avec certains clients (j'ai pas de source sous les yeux, mais je me souviens avoir lu ça quelque part).
      - on peut transférer un fichier via jingle (xep-0234), c'est une xep expérimentale, peut être le futur standard ?

      bref, selon les clients/les configurations réseau, ça peut se passer sans soucis ou poser problème.

      Et c'est quoi c'est mode de dire des trucs du genre «ça juste marche» ? Une tentative de traduction mot à mot de l'anglais ? Nan parce qu'en français c'est juste horrible
  • # Utilisabilité

    Posté par  . Évalué à 1.

    Salut,
    Je connaissais pas le projet ça a l'air interessant, et en plus pour une fois une GUI qui ressemble à quelque chose (allez convaincre quelqu'un d'utiliser un programme tout moche ;))
    Ma question est simple, à prioris la réponse à l'air non mais on sait jamais

    Est il possible de faire de la multi-conférence audio, de préférence avec une bonne réduction d'echo, ainsi que de la multi-conférence video.
    Car c'est ce genre de chose qui me fait utiliser skype, et je n'hésiterais pas à filler sous une alternative si dispo.

    Pour ceux qui vont suggeré mumble
    -Son qui oscille entre acceptable et mauvais suivant le parametrage du serveur (dans mon cas l'appel peut consomer 80% de la BP d'une communication ADSL sans problèmes)
    - Anti-Echo tout pourris

    Dernière question
    La prise en main de la bête est elle facile ? (Pareil un client de VOIP tout seul ça sert à rien)
    • [^] # Re: Utilisabilité

      Posté par  (site web personnel) . Évalué à 1.

      Il est possible de faire une multi-conférence audio en utilisant SIP ou Jingle. Concernant la réduction d'écho, une première partie a déjà été intégrée mais il reste encore du travail de ce côté là. Enfin pour la multi-conférence vidéo, je n'ai pas encore essayé (mes vidéo-conférences se sont toujours limitées à 2 participants pour le moment).

      La prise en main est relativement facile, mais le mieux est toujours de se faire une idée par soi même. De même que pour utiliser SIP il suffit d'avoir un compte chez un fournisseur (par exemple [http://ippi.fr]), pour utiliser Jingle il suffit de disposer d'un compte Jabber/XMPP (par exemple un compte gmail). La seule limitation est la traversé des NAT et des firewall. Pour le moment ICE est activé par défaut, mais ce dernier ne peut utiliser STUN/TURN qu'en configurant un/des serveur(s) gérant ces protocoles (par exemple la page [http://www.voip-info.org/wiki/view/STUN] liste une série de serveurs STUN publics).

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.