Jingle, ça fonctionne déjà malgré les NATs, grâce à la technique du "hole-punching". En gros, à condition d'avoir une troisième machine totalement démunie de NAT et dévouée à cette tâche, deux machines "masquées" par un NAT chacune peuvent établir une liaison bidirectionnelle directe en UDP. Ca a juste quelques inconvénients :
tous les types de NAT ne le supportent pas (et il est difficile de savoir le type de son NAT, ce n'est pas à proprement parler écrit sur le routeur),
si les deux "parties" de la conversation n'arrivent pas à s'entendre sur la phase préliminaire, notamment s'ils n'ont pas de machine tierce, ça ne fonctionnera pas.
La technique de traversée de NAT "directe" est formalisée sous le nom de STUN. Pour plus de robustesse, on lui adjoint généralement TURN - une formalisation du principe de "relais", pour une traversée "indirecte" du NAT. Et pour rendre tout ça "simple", on a formalisé une méthodologie qui indique quelles techniques employer dans quel ordre : ICE.
Jingle (de base) s'appuie sur ICE pour mettre en place son canal de communication.
Des gens ont également proposé une XEP pour permettre de mieux supporter les cas pourris (pas de serveur disponible pour faire du TURN ni du STUN). Cette XEP utilise l'approche qui a rendu Skype célèbre, en l'adaptant à la sauce XMPP : se servir des (rares) clients qui n'ont PAS à souffrir des méfaits du NAT pour fournir les fonctions de TURN et STUN aux autres. Et, tant qu'à bien faire, essayer de calquer ça sur le roster de l'utilisateur (qu'on ne se retrouve pas à perdre de la BP pour la conversation de deux mecs qu'on ne connaît ni d'Eve ni d'Adam).
Cette amélioration de Jingle, elle porte le nom de "Jingle Nodes", et elle est actuellement implémentée par (au moins) deux clients libres : OneTeam et Jitsi (anciennement SIP Communicator).
[^] # Re: Juste pour s'échanger des commérages !
Posté par Larry Cow . En réponse à la dépêche XMPP au printemps, le grand rafraîchissement. Évalué à 10.
Jingle, ça fonctionne déjà malgré les NATs, grâce à la technique du "hole-punching". En gros, à condition d'avoir une troisième machine totalement démunie de NAT et dévouée à cette tâche, deux machines "masquées" par un NAT chacune peuvent établir une liaison bidirectionnelle directe en UDP. Ca a juste quelques inconvénients :
La technique de traversée de NAT "directe" est formalisée sous le nom de STUN. Pour plus de robustesse, on lui adjoint généralement TURN - une formalisation du principe de "relais", pour une traversée "indirecte" du NAT. Et pour rendre tout ça "simple", on a formalisé une méthodologie qui indique quelles techniques employer dans quel ordre : ICE.
Jingle (de base) s'appuie sur ICE pour mettre en place son canal de communication.
Des gens ont également proposé une XEP pour permettre de mieux supporter les cas pourris (pas de serveur disponible pour faire du TURN ni du STUN). Cette XEP utilise l'approche qui a rendu Skype célèbre, en l'adaptant à la sauce XMPP : se servir des (rares) clients qui n'ont PAS à souffrir des méfaits du NAT pour fournir les fonctions de TURN et STUN aux autres. Et, tant qu'à bien faire, essayer de calquer ça sur le roster de l'utilisateur (qu'on ne se retrouve pas à perdre de la BP pour la conversation de deux mecs qu'on ne connaît ni d'Eve ni d'Adam).
Cette amélioration de Jingle, elle porte le nom de "Jingle Nodes", et elle est actuellement implémentée par (au moins) deux clients libres : OneTeam et Jitsi (anciennement SIP Communicator).
C'est mieux, comme ça? ;)