Page Index Toggle Pages: 1 Send TopicPrint
Normal Topic STUN und symmetrisches NAT (Read 7132 times)
Pfeffer
Guest


STUN und symmetrisches NAT
01. Aug 2005 at 14:42
Print Post  
Hi!

ich weiß nicht, was RFC vorsieht für den Fall, dass per STUN ein symmetrisches NAT entdeckt wird.
Ich denke bei einem symmetrscihen NAT gibt es noch 2 Fälle zu unterscheiden (wenn keine Portweiterleitungen am NAT-Router eingerichtet werden können):
1. Die Gegenseite ist nicht auch hinter einem symmetrischen NAT, dann genügt es, die Aufbaurichtung der rtp-Verbindung umzukehren durch Angabe von rport ohne Parameter in der SIP-Nachricht.

2. Die Gegenstelle ist ebenfalls hinter einem symmetrischen NAT. Dann kann nur eine rtp-Verbindung aufgebaut werden, wenn ein rtp-Proxy dazwischen geschaltet wird. Was sieht RFC für diesen Fall vor? Logisch wäre folgendes: Wenn der SIP-Provider (zum Beispiel, weil beide Clients  rport angegeben haben) merkt, dass beide Gesprächsteilnehmer hinter einem symmetrischen NAT sitzen, so ändert er die SIP-Nachrichten und leitet die Audiodaten über einen rtp-proxy. (sipgate macht das, es "erkennt", dass die Daten über einen rtp-proxy laufen sollen, daran, dass in den SIP-Nachrichten als contact eine andere IP angegeben ist als die von der die SIP-Nachricht kommt).
Da STUN bei symmetrischem NAT eh keinen Sinn macht, wäre es sinnvoll, die mittels STUN ermittelte IP, wenn symmetrisches NAT entdeckt wurde, nicht zu verwenden. Dann würde sipgate den rtp-Verkehr automatisch über einen rtp-proxy laufen lassen.

1. Wie verhält sich Phoner derzeit?
2. macht mein Vorschlag Sinn?

Gruß,
  Pfeffer.
  
Back to top
 
IP Logged
 
Suppenkasper
God Member
*****
Offline


Phoner-Support

Posts: 1536
Location: Aachen
Joined: 29. Mar 2005
Gender: Male
Re: STUN und symmetrisches NAT
Reply #1 - 01. Aug 2005 at 20:29
Print Post  
@Pfeffer,

ich kann leider beide Fragen nicht beantworten; jedoch zur Information: Die RFC 3489 mit dem schönen Betreff:

STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)

Eigentlich sollten sich die für Fachleute ergebenden Fragen - bis auf das Verhalten von Phoner - hieraus beantworten lassen.

Quelle: de.wikipedia.org

Viele Grüße vom Kai
  
Back to top
IP Logged
 
Pfeffer
Guest


Re: STUN und symmetrisches NAT
Reply #2 - 02. Aug 2005 at 01:02
Print Post  
Hallo!

nein, aus dem STUN-RFC geht eben nicht hervor, wie das SIP und rtp-protokoll reagieren soll, wenn symmetrisches NAT entdeckt wurde. Ich weiß nicht, ob irgendwo steht, was dann passieren soll?

in dem STUN-RFC steht direkt in der Einleitung:

"In particular, STUN does not enable incoming UDP
   packets through symmetric NATs (defined below), which are common in large enterprises." - und ich ergänze: bei allen Linux-Routern.

Also STUN löst für symmetrsische NATs das Problem eben nicht. Es kann lediglich feststellen, dass symmetrscihes NAT vorliegt. Was dann passieren sollte, ist zumindest in diesem RFC nicht festgelegt. - Vielleicht sollte ich meine Vorschlag gleich als RFC einreichen Wink

Gruß,
  Pfeffer.
  
Back to top
 
IP Logged
 
Phoner Admin
YaBB Administrator
*****
Offline



Posts: 11389
Location: Germany
Joined: 12. Oct 2003
Gender: Male
Re: STUN und symmetrisches NAT
Reply #3 - 07. Aug 2005 at 07:30
Print Post  
Was schlägst du denn vor?
  
Back to top
WWW  
IP Logged
 
Pfeffer
Guest


Re: STUN und symmetrisches NAT
Reply #4 - 11. Aug 2005 at 01:29
Print Post  
1. feststellen (per STUN), ob symmetrisches NAT vorliegt.

2. prüfen (per STUN) , ob evtl. eine Weiterleitung der relvanten Ports im  NAT-device konfiguriert ist. Wenn ja: kein Problem

3. Falls nein: 
  a) in der SIP-INVITE-Nachricht "rport" ohne Portangabe einfügen. Das führt laut RFC dazu, dass der Aufbau der rtp-Verbindung in umgekehrter Richtung erfolgen soll. Also vom Anrufer zum Angerufenen. Das löst das Problem, solange der Angerufene nicht auch hinter einem symmetrischen NAT sitzt.

  b) Falls der Angerufene per rport-Angabe signalisiert, dass auch er hinter einem symmetrischen NAT sitzt, sollte Phoner nicht die öffentliche, sondern die interne IP in dem Contact- Header und in dem SDP-Teil verwenden. Denn dann schalten einige VoIP-Provider (wie z.B. sipgate) automatisch eine rtp-proxy dazwischen. - 

Jetzt fällt mir gerade ein, dass die entsprechende INVITE-Nachricht vom Anrufer dann natürlich schon raus ist, wenn die Information vorliegt, ob der Angerufene auch hinter symmetrischem NAT steckt. Beim Angerufenen liegen diese Informationen rechtzeitig vor. Er kann sich so verhalten, wie beschrieben. Also wenn der Angerufene selbst hinter symmetrischem NAT sitzt und eine SIP-INVITE-Nachricht bekommt mit rport, dann sollte Phoner die interne IP senden, damit der VoIP-Provider einen rtp-Proxy dazwischen schaltet.

Beim Anrufer liegt die Info, ob der Angerufene auch hinter einem symmetrischen NAT sitzt, zu spät vor (d.h. erst, nachdem der Anrufer seine INVITE-Nachricht rausgeschickt hat). Oder besteht die Möglichkeit zunächst eine INVITE-Nachricht zu verschicken ohne SDP, um herauszufinden, ob die Gegenstell auch hinter symmetrischem NAT sitzt?

Verhält sich der Angerufene wie beschrieben, so ist es nicht nötig, dass der Anrufer die interne IP sendet. Nur Falls der Angerufe auch hinter symmetrischem NAT sitzt und nicht die interne IP sendet, sollte das der Angerufene machen. Es würde die Kompatibilität erhöht werden, wenn der Anrufende die Möglichkeit hätte, bevor er seine SDP-Nachricht verschickt, herauszubekommen, ob der Angerufene ebenfalls hinter einem symmetrischen NAT sitzt und entsprechend die interne IP senden. Aber nötig ist das eigentlich nicht.

Eine einfache Möglichkeit wäre auch: Immer die interne IP senden, wenn symmetrisches NAT (und keine Portweiterleitungen) entdeckt wurde. Dann schaltet der VoIP-Provider (hoffentlich) immer einen rtp-Proxy dazwischen und es sollte einfach immer funktionieren. Nachteil ist bloß, dass der Traffic dann einen weiteren Weg laufen muss (eben über den rtp-proxy). Ich denke, das ist erstmal eine gute Zwischen-Lösung, die immer funktioniren sollte (außer mit providern, die nicht automatisch einen rtp-proxy dazwichen schalten, z.B. GMX. Aber mit denen kann zwischen zwei Leuten, die hinter symmetrischem NAT sitzen eh keine Verbindung aufgebaut werden). Hmm so toll ist diese Zwischenlösung doch nicht. Denn wenn der Angerufene nicht hinter symmetrischem NAT sitzt, ist ja durch die Angabe von rport ein Verbindungsaufbau problemlos möglich. 

Fazit: wenn Phoner einen Anruf erhält mit dem rport-Eintrag ohne Portangabe und selbst hinter symmetrischem NAT ohne Portforwaring hängt, dann sollte es in der SIP und SDP-Nachricht die interne IP verwenden, um den VoIP-Provider zu veranlassen einen rtp-Proxy dazwischen zu schalten. Wenn der VoIP- Provider das dann macht und sich alle Clients nach diesem Schama verhalten, so ist es immer ohne Portweiterleitung möglich, hinter jedem NAT zu voipen.

Was hälst Du von dem Vorschlag? - Es müsste sich erst noch genau getestet werden.

Gruß,
  Pfeffer.
  
Back to top
 
IP Logged
 
Phoner Admin
YaBB Administrator
*****
Offline



Posts: 11389
Location: Germany
Joined: 12. Oct 2003
Gender: Male
Re: STUN und symmetrisches NAT
Reply #5 - 11. Aug 2005 at 06:54
Print Post  
Leider gibt es einige provider, die rejecten den Call sofort, wenn private IP-Adressen verwendet werden.
Ich denke mal, dass die bisherige Implementierung den größten Kompromiss darstellt.
Es gibt sicherlich immer Optimierungsmöglichkeiten. Ich möchte jedoch vermeiden, pro Provider spezielle Sachen zu machen.
Leider schaffe ich es zur Zeit nicht einmal, schon länger anstehende Dinge zu implementieren. Ich werde das also hinten anstellen müssen.
Ich werde mir die "rport"-Geschichte aber mal anschauen, ob das auch generell hilft, wenn kein STUN konfiguriert ist...
  
Back to top
WWW  
IP Logged
 
Page Index Toggle Pages: 1
Send TopicPrint