Problem beim Instant Messaging sind Direktverbindungen zwischen Stationen hinter NAT-Routern.
Die Router setzen Ports und Adressen auf unterschiedliche Weise um. Weitere Informationen:
Test mit 
http://midcom-p2p.sourceforge.net/
NAT-Typen in Kurzform:
non-symmetric:
- Restricted Cone: Paket muß von der IP-Adresse kommen, an die die Anfrage gerichtet war.
- Port Restricted Cone: muß zusätzlich auch noch von dem Port kommen, an den die Anfrage gerichtet war.
- Full Cone: auch ohne abgehend aufgebaute Verbindung (port fowarding, endpoint independent mapping)
symmetric:
- Symmetric (Cone) NAT (mapping in Abhängigkeit von der Ziel-IP-Adresse). Nicht mit STUN.
Man geht davon aus, dass der Client denselben Port sowohl für das Senden als auch das Empfangen der Datenpakete verwendet. Damit ist "Port Restricted" i.d.R. problemlos.
Die Routingtabelle hat aber nur eine begrenzte zeitliche Gültigkeit (Session-Intervall).
Für eine peer-peer-Verbindung senden beide Teilnehmer UDP-Pakete auf dem gleichen Port an den Gegner. Nur das erste gesendete Paket wird geblockt, danach ist (wegen des zuvor abgehenden Paketes) ein Routingeintrag vorhanden.
Um zwischen solchen Stationen eine Verbindung aufbauen zu können, gibt es verschiedene Möglichkeiten:
- STUN: Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs). RFC 3489, IETF, Mar. 2003. Dabei hilft ein "STUN-Server" herauszufinden, wie das NAT-Gateway arbeitet: 'Untechnisch gesprochen schickt das VoIP-Endgerät eine Testanfrage an den STUN-Server ("wie lautet die öffentliche IP-Adresse des NAT-Systems und von welchem Port aus kommt die Anfrage?"), dieser schickt eine Antwort zurück ("Die Testanfrage kam von der öffentlichen IP-Adresse 217.232.xxx.xxx auf Port 12345."' (florianmessner.com). Nicht mit symmetric mapping.
- "UPnP ermöglicht Windows das Erkennen und Steuern von UPnP-Geräten" (Routern). Mag ich nicht.
- "Port forwarding" im Router (zu umständlich)
Beschreibungen NAT-Problematik: