@britzelfix: Die Aussage ist in der Allgemeinheit verwirrend. Sowohl symmetrisches alsauch nicht symmetrisches NAT erlauben es, UDP-Pakete an interne IPs zu senden.
Hintergund zum Thema NAT:
Jedes UDP/TCP-Paket hat ein Absender-Port und einen Zielport. Die Absenderporst werden bei vielen Anwendungen zufällig gewählt (z.B. www), während die Zielports meistens an Standards gebunden sind (www: TCP-Port 80). Beim NAT muss der NAT-Router sich irgendwie merken, welche Pakete, die von außen kommen an welche interne IP weitergeleitet werden müssen. Dazu ändert der NAT-Router den Absender-Port. Pakete, die dann von außen auf diesen Absender-Port geschickt werden, werden dann auf die interne IP und den internen Absender-Port weitergeleitet, von dem ursprünglich eine Nachricht ins Internet ging.
Manche NAT-Router schicken dann alle Pakete, die von außen auf diesen geänderten Port eingehen an den ursprüngliche IP & Port. Das sind nichtsymmetrische NAT-Router. Sie haben den Nachteil, dass sobald ein interner Rechner einmal eine Verbindung zu einem externen Rechner aufgebaut hat, alle externen Rechner auf den internen Pakte schicken können.
Um das zu verhindern gibt es 2 Strategiene:
1. Der Router leitet nur Pakete an dem geänderten Absender-Port an den internen Rechner weiter, die von der IP stammen, zu der der interne Rechner selbst zuerst ein Paket geschickt hat. Das nennt sich Portbeschränktes "Port-restricted", nicht symmetrisches NAT.
2. Der Router verwendet für jede Verbindung einen anderen externen, geänderten Port. Wird von dem internen Rechner zu zwei externen Rechnern von dem gleichen Absender-Port eine Verbindung aufgebaut, so ändert der symmetrisch NATende Router die Absender-Ports in zwei verschiedene. Dadurch ist es für den internen Rechner nicht möglich vorauszusagen, welchen Absender-Port im öffentlichen IP-Netz die eigenen Pakete haben. Diese Information muss aber im SIP-Protokoll übermittelt werden, um den Transport von Audio-Daten über einen anderen Port als den, der für SIP verwendet wird, zu ermöglichen. Bei symmetrischem NAT sind für dieses Problem folgende Lösungen möglich:
1. im NAT-Router wird für die relevanten rtp-Ports (die bei VoIP bei jeder Anwendung andere sind, weil sie im SIP-Protokoll ausgehandelt werden und nicht standardisiert sind) eine Weiterleitung eingerichtet.
2. Wenn der Gesprächspartner nicht auch hinter einem symmetrischem NAT sitzt, so kann der Audio-Verbindungsaufbau in umgekehrter Richrtung als üblich erfolgen. Der Anrufer, der hinter dem symmetrischen NAT sitzt, baut dann die Audioverbindung zu dem Port auf, den der Gesprächspartner in seiner SIP-Nachricht angegeben hat. Der Gesprächspartner akzeptiert auf diesem Port die Audio-Daten von jedem Absender-Port, so dass er nicht vorher in der SIP-Nachricht übertragen werden muss. (Das leistet die Option "rport" in SIP-Protokoll)
3. Der NAT-Router erkennt das SIP-Protokoll und setzt automatisch entsprechende Portweiterleitungen. Soweit mir bekannt, versucht das zum Beispiel der Draytek 2500. Allerdings hat der wohl einen Bug, so dass dieser NAT-Router das VoIPen vollkommen zum Glücksspiel macht, wenn man diese eigentlich gute Funktion nicht abstellt.
4. Falls beide Gesprächspartner hinter einem symmetrischen NAT sitzen, keine Portweiterleitungen eingerichtet werden können und der Router nicht SIP-aware ist, ist eine VoIP-verbindung nur möglich über einen dritten Rechner, einen rtp-Proxy, über den alle Audiodaten laufen. Sipgate setzt einen solchen rtp-Proxy automatisch ein, wenn es feststellt, dass eine interne IP-Adresse in der SIP-Nachricht verwendet wurde. Dadurch funktioniert sipgate immer, wenn KEIN STUN-Server verwendet wird und nicht firewalls oder kaputte Router doch noch einen Strich durch die Rechnung machen.
Gruß,
Pfeffer.