Quand on est derrière du NAT, il y a plein de cas possibles.
Si ce n'est pas ce qu'on appelle du NAT symmétrique, alors on peut toujours réussir à passer Directement en NAT to NAT sans utiliser de passerelle. A première vu on se dit que c'est pas possible, mais si! suffit de faire transiter les flux en udp, et de savoir ou envoyer (qu'elle ip et quel port).
Pour le cas ou l'un des deux est dans un NAT symmetrique, alors on a le choix, passer par une passerelle spécifique au protocole ou passer par une passerelle générique (appelée TURN, cf draft en cours à l'ietf). La passerelle, après elle peut être soit dédiée sur un serveur central, soit sur un client dont le réseaux n'est pas du NAT symmetrique.
ça c'était pour les flux audios eux mêmes... pour permettre à SIP/SDP de passer lui aussi le NAT, on doit utiliser des serveurs STUNs (standard de l'ietf) pour résoudre les problèmes d'adressage du protocole.
[^] # Re: routeur NAT
Posté par ecyrbe . En réponse à la dépêche Avancées importantes dans le support de la voix sous Jabber/XMPP. Évalué à 4.
Si ce n'est pas ce qu'on appelle du NAT symmétrique, alors on peut toujours réussir à passer Directement en NAT to NAT sans utiliser de passerelle. A première vu on se dit que c'est pas possible, mais si! suffit de faire transiter les flux en udp, et de savoir ou envoyer (qu'elle ip et quel port).
Pour le cas ou l'un des deux est dans un NAT symmetrique, alors on a le choix, passer par une passerelle spécifique au protocole ou passer par une passerelle générique (appelée TURN, cf draft en cours à l'ietf). La passerelle, après elle peut être soit dédiée sur un serveur central, soit sur un client dont le réseaux n'est pas du NAT symmetrique.
ça c'était pour les flux audios eux mêmes... pour permettre à SIP/SDP de passer lui aussi le NAT, on doit utiliser des serveurs STUNs (standard de l'ietf) pour résoudre les problèmes d'adressage du protocole.