STUN

[F.S.K.]

Hey,

eine Frage, die nur mittelbar etwas mit Endgeräten zu tun hat...:

Es gibt SIP-Endgeräte die zur Überwindug der NAT-Problematik STUN einsetzen (z.B. SIPgate-Variante).
So weit ich gehört habe, hat STUN aber den Nachteil, dass dabei von seiten des SIP-Anbieters mit einer Art Zwangs-"Zwischenhop" gearbeitet wird um die beiden Teilnehmer miteinander verbinden zu können.
Daraus folgt, dass dann auch der Mediastream über diesen Zwischenhop läuft und unnötigerweise die Netzinfrastruktur (Ports) des SIP-Anbieters belastet, obwohl es vielleicht einen "kürzeren" Weg zwischen den Teilnehmern gibt (im Voice-Bereich wird das "Tromboning" genannt und macht im Extremfall den Dienst nicht mehr wettbewerbsfähig).

Frage:
Ist das so? Oder läßt sich STUN auf andere Weise implementieren? Gibt es Alternativen zu STUN?

Gruss

 

[rajo]

...diese Interpretation von STUN ist mir neu...

AFAIK ist STUN (Simple Traversal of UDP throut NAT, RFC 3489)
eine Möglichkeit mit der Endgeräte, die sich hinter einem NAT-Router befinden, die Netzwerkkonfiguration herausfinden können. Hierbei sendet das Endgerät eine Nachricht an einen ausserhalb des NATs befindlichen STUN-Server. Dieser antwortet dann mit der Kombination aus IP-Adresse und Port, mit der das Paket abgesendet wurde.

Verwendet ein Endgerät z.B. die lokale Adresse 192.168.1.3:12345, so schickt es mit dieser Adresse eine Anfrage an den STUN-Server ausserhalb des NATs. Dieser Empfängt das Paket mit der Absendeadresse 134.96.249.10:8899 und antwortet an diese Adresse mit einem Paket, dass diese IPort-Kombination enthält. Somit kann das hinter dem NAT befindliche Endgerät dann für alle folgenden Verbindungen diese Adresse in den SIP/SDP-Paketen verwenden, während es selbst weiterhin auf 192.168.1.3:12345 hört.

Mittels dieser Informationen kann das Endgerät herausfinden, ob es Netzwerkzugang hat, ob eine Firewall UDP blockt und ob NAT zum Einsatz kommt.



Mit anderen Worten: Das Endgerät stellt eine Anfrage an einen STUN-Server (der auch beim Provider stehen kann) und verwendet dann lediglich die von diesem Server zurückgelieferte IPort Kombination in den SIP-Nachrichten. Der Medienstrom läuft also keineswegs deswegen über den Server des SIP-Anbieters.

Siehe hierzu auch:
http://corp.deltathree.com/technology/nattraversalinsip.pdf


gruss
Rainer

 

[sip-store.de]

Es gibt SIP-Endgeräte die zur Überwindug der NAT-Problematik STUN einsetzen (z.B. SIPgate-Variante).
So weit ich gehört habe, hat STUN aber den Nachteil, dass dabei von seiten des SIP-Anbieters mit einer Art Zwangs-"Zwischenhop" gearbeitet wird um die beiden Teilnehmer miteinander verbinden zu können.

STUN ist nur damit da um die externe IP Addresse und den Typ des NAT-Routers festzustellen. Bei Anbietern wie SipGate solltest du keinen STUN support brauchen.

Daraus folgt, dass dann auch der Mediastream über diesen Zwischenhop läuft und unnötigerweise die Netzinfrastruktur (Ports) des SIP-Anbieters belastet, obwohl es vielleicht einen "kürzeren" Weg zwischen den Teilnehmern gibt (im Voice-Bereich wird das "Tromboning" genannt und macht im Extremfall den Dienst nicht mehr wettbewerbsfähig).Frage:
Ist das so? Oder läßt sich STUN auf andere Weise implementieren? Gibt es Alternativen zu STUN?

Das funktioniert anders und ist abhaengig vom SIP-Server. Der Sipgate server sollte folgendermassen funktionieren:

Wenn der SIP-Server bei der Registrierung feststellt das sich dein Telefon mit einer privaten Addresse (RFC1918) adresse anmeldet dann wird die Registrierung umgeschrieben und du wirst ueber eine art UDP Zwangsproxie geleitet so das die Gespraeche immer ueber den Proxy und nicht zwichen den beiden IP/SIP Telefonen laufen.

Um den Proxie zu vermdeiden sollte man Produkte wie das GrandStream HT 486 (sobald verfuegbar) oder SIP telefone und NAT Router mit UPNP oder SIP unterstuetzung einsetzen.

Desweiteren schlage ich vor du liest mal die STUN RFC

gruss,

:: Arnd ::

 

[matze75]

 

[exim]

 

[Anonymous]

 

[sip-store.de]

 

[matze75]

 

[exim]

 

[johnnyt]