[Frage] Verständnisfrage STUN mit und ohne ICE

[MPW]

Hallo,

ich versuche derzeit zu verstehen, wie STUN-Server funktionieren und wo der Unterschied zwischen STUN mit und ohne ICE liegt.

Situation ist, dass ich mit CSipSimple von Android oder Linphone vom Laptop mich auf meine FritzBox Zuhause schalte und von überall mit WLAN meine Festnetzgespräche entgegen nehmen kann. Soweit funktioniert das auch, mit STUN+ICE.

Soweit ich STUN verstanden habe, hilft es nur dabei, die NATs zu überwinden, das eigentliche Gespräch, respektive die eigentliche Verbindung, wird aber direkt zwischen den Teilnehmern aufgebaut. Also in diesem Fall zwischen meinem Laptop/Android-Gerät und meiner FritzBox.

Mit ICE funktioniert es, ohne nicht. Wo ist da jetzt der Unterschied? Welche Art von Firewall/NAT kann ICE überwinden, die das klassische STUN-Protokoll nicht schafft?

Und zweite Frage: Warum funktioniert das bei Verbindungen zu meiner FritzBox, nicht aber bei direkten SIP-Anrufen, z.B. zu sip:[email protected]? Dort höre ich nichts, trotz STUN+ICE. Oder wird STUN gar nicht verwendet, wenn man lokal direkt raustelefoniert? Wie könnte ich das hinbekommen?

Zu STUN selbst habe ich schon den Wiki-Artikel gelesen, der das ja sehr gut erklärt. Aber ICE hab ich noch nichts einfaches gefunden, außer die Spezifikations-PDF. Würde mich freuen, wenn mir jemand weiterhelfen kann. Insbesondere frage ich mich, warum ich noch keine direkten SIP-Gespräche führen kann.

Grüße
MPW

 

[koyaanisqatsi]

Moins

Naja, anscheinend bist du auch an der Fritz!Box registriert, die macht dann das "STUN".
Und hier musst du aufpassen: Ging der (eingehende) Anruf an "PUBLICIP:5060" (Fritz!Box) ?
...oder an: "PUBLICIP:DYNAMIC-SIPPORT" ?
Und STUN (& ICE) kann beides: "PUBLICIP:STATIC-SIPPORT" oder "PUBLICIP:DYNAMIC-SIPPORT"

Bei STUN ist nicht nur die IP wichtig, der Port kann ja mal fürs Internet freigegeben sein.
...wie bei der Fritz!Box.


Ein grosses Manko, meines Wissens, bei CSipSimple: Fehlende Möglichkeit der STUN Eingabe im jeweiligen Profil
...da wäre es meines Erachtens besser aufgehoben. Aber vielleicht geht das irgendwie nicht unter Android.

 

[MPW]

Hi Koyaanisqatsi,

danke für deine Antwort. Leider hab ich es noch nicht verstanden.

Also es geht um die Verbindung zwischen dem Sip-Client irgendwo hinter einer Firewall (nicht das Heimnetz) und der FritzBox mit globaler IPv4.

Die Verbindung von der FritzBox zum Gesprächsteilnehmer ist nicht das Problem, das funktioniert. Es geht um die Verbindung zwischen der FritzBox und dem Softphone. Die klappt ausschließlich mit STUN+ICE. Daher denke ich nicht, dass die FritzBox hier STUN betreibt, sondern der SIP-Client. Ich habe dort stun.sipgate.net:10000 eingestellt.

Ohne ICE klappt es nicht.

Frage: Was macht ICE, was STUN nicht kann? Du hattest über Ports gesprochen. Also STUN kann nur Port 5060 und ICE kann auch mit dynamischen Ports umgehen? Ich hab da bzgl. Ports nichts eingestellt, was macht die FritzBox denn standardmäßig?

Frage2: Wieso klappt STUN+ICE zur FritzBox aber nicht bei direkten ausgehenden SIP-Verbindungen zu Sip-Adressen wie [email protected]? Gerade wenn du schreibst, dass CSipSimple überall dieselben Einstellungen verwendet, müsste es ja überall klappen, da jedes Mal derselbe NAT-Server überwunden werden muss.

Grüße
MPW

 

[koyaanisqatsi]

Die Fritz!Box kennt die PUBLICIP deswegen in "Gänsefüßchen".
Klients ohne STUN kennen nur ihre lokale IP.
STUN wird doch für die NAT Umgehung benötigt.

Also, ein IP-Telefon, egal ob Softfon oder SIP-Klient auf Smartfon oder sonstwo, baut eine Verbindung auf.
Das ist ersteinmal nur SIP.
Dafür wird ja wohl irgendwie ein Port benötigt, richtig?
Normal ist das also immer so:
1. Lokale Geräte dürfen ins Internet
2. Dafür wird ihnen erlaubt einen unpriviligierten* Port zu öffnen
3. Dieser Port wird dann auch als (SIP) Rückkanal benutzt und muss offengehalten** werden.
...und das macht*** STUN, nur mit dem "offenhalten" bin ich mir nicht sicher. :gruebel:

STUN liefert zwar auf den ersten Blick "nur die öffentliche IP", viel wichtiger jedoch ist die Behandlung des Ports.
Ist er dynamisch? Etwa statisch? STUN sag mir einfach welcher es ist!

Danach erst kann über SIP ausgehandelt weden welche/r RTP Port/s verwendet werden.
Und die müssen auch, wegen NAT, von "innen" geöffnet werden.
Es gibt ja keine Portfreigaben/weiterleitungen dafür.
Das passiert alles von Innen nach Außen und wird via SIP bekanntgegeben/ausgehandelt.

* Jenseits der ersten 1024 (oder waren es 1056?) Ports
** Sonst kann es nicht klingeln
*** Die Infos bereitstellen

Wenn also mal STUN den Statischen, 5060, liefert, was klingelt dann also bei dir?

 

[rollo]

Ich versuchs mal ganz kurz:

STUN (Session Traversal Utilities for NAT) macht erstmal nichts anderes als dem SIP-Client auf Anforderung seinen externen Socket, also externe IPort mitzuteilen. Der kann das dann in seine SIP-Daten als Absenderkennung übernehmen. Setzt er stattdessen die privateIPort ein, kommt bei einigen Providern eine Fehlermeldung, andere übernehmen einfach die Infos aus Schicht 3 und 4 als Absender.

Man kann das mit PhonerLite sehr schön sehen, wenn man das registarlos betreibt wird in der Statusleiste ohne STUN die lokale, mit STUN die externe IP in der Form user@IPort angezeigt.

Für den Schritt zu ICE fehlt noch die Komponente TURN.
TURN (Tracersal using Relays around NAT) setzt wie der Name schon sagt neben einem STUN-Server noch ein Relay voraus, über das die Kommunikation läuft.

ICE (Interactive Connectivity Establishment) ist als Framework für SIP, NAT, STUN und TURN anzusehen. Es ist nur TCP oder UDP möglich, kein TLS.
ICE geht davon aus, dass der Client über mehrere Sockets (Transportadressen) erreichbar ist. Für die Kommunkation wird dann der sinnvollste angewendet, z.B. die externe Adresse.

Im Normalfall sollte STUN ausreichen, ICE kann evtl. in komplexeren Szenarien hilfreich sein. Andererseits ist STUN eine "Untermenge" von ICE, so dass man mit der Einstellung nicht viel falsch machen kann.

HTH

jo

 

[MPW]

Hallo rollo,

danke für deine Infos zu ICE. Das was du geschrieben hast, habe ich glaub so grob verstanden. Kannst du ein konkretes Beispiel geben, in dem STUN+ICE aber STUN alleine nicht funktionieren würde? So von der Netzwerkkonfiguration her?

Grüße
MPW

 

[koyaanisqatsi]

Also, nach dem was was rollo, besonders im letzten Absatz, anmerkte, muss es eher ICE & STUN heissen.
...demnach kann STUN ohne ICE garnicht funktionieren?

Ich frag so, weil ich das auch mal abhaken möchte.

 

[rollo]

STUN alleine geht schon aber ICE braucht STUN (und TURN).
Einen konkreten Anwendungsfall habe ich leider nicht.
Bei mir hat bislang STUN in Verbindung mit NAT immer ausgereicht. Mit IPv6 ist das dann eh alles nicht mehr nötig.

jo

 

[koyaanisqatsi]

OK, nehmen wir mal PhonerLite.
Da (Konfiguration: Reiter Server) kannste nur den STUN Serverort angeben.
Auf dem Reiter Netzwerk gibt es: [] Verbindungsart erzwingen
Wird das angehakt, nimmt STUN den dort als lokal eingestellten Port.
...anstatt einen Dynamischen.

Hat das was mit ICE zu tun?
...oder ist/wäre das nur eine naive Vermutung?

Ansonsten wüsste ich auch nicht, was ICE ist und wofür es Verantwortlich ist.

 

[MPW]

Kann mir jemand erklären, warum weder Linphone noch CSipSimple die STUN+ICE-Konfiguration für einen direkten SIP-Anruf (z.B. [email protected]) verwenden?

 

[rollo]

Nach der "ICE-Theorie" hätte der Client 2 Sockets: Interne IP:internerPort, Externe IP:externerPort. Für die externe Kommunikation ist letzeres wichtig, das bekommt man mit eine STUN-Abfrage heraus.
Bei Phoner Lite ist der lokale Clientport einstellbar, der externe ergibt sich aus dem verwendeten NAT.
Bei Anwahl einer SIP-URI setzt der Client dank STUN die Informationen externeIP:externerPort als SIP-Absender. Dafür wird nur STUN benötigt.

 

[MPW]

Interne und externe IP ist mir völlig klar, NAT-Portfreigaben etc. Das ist mir alles ersichtlich. Und auch, dass STUN dazu da ist, das auszuhebeln, bzw. einen Tunnel zu ziehen.

Was mir halt nicht klar ist, was ICE macht und warum STUN bei direkten Gesprächen nicht funktioniert.

 

[henry90]

Da ich zur Zeit nichts besseres zu tun habe, habe ich mal Linphone auf meinem PC Windows 7, der sich hinter einer Fritz 7390 befindet, installiert.

warum STUN bei direkten Gesprächen nicht funktioniert.

Ich muss zwingend STUN (stun.sipgate.net) angeben, sonst kommt bei einem SIP-URI-Telefonat kein Ton zu Stande, bzw. ich muss meine öffentliche IP angeben.
Warum STUN bei direkten Gesprächen bei dir nicht funktioniert, seltsam ...

 

[MPW]

Danke für den Test, aber genau das funktioniert bei mir Zuhause auch.

Es funktioniert aber nicht, wenn ich hinter dieser ominösen Firewall in der Uni bin. Da funktioniert hingegen dann STUN+ICE. Daher versuche ich ja die technischen Details zu verstehen .

 

[imagomundi]

Ob da nicht auch noch der ISP und das damit vorgegebene Routing (Server + Ports des Providers) eine Rolle spielen?

 

[rollo]

Um das zu klären müsste man mehr über die Struktur des Uninetzes wisssen. Du kannst aber mal Traces mit und ohne ICE machen. Evtl. kann man daran was sehen.

jo