Brauche Details wie STUN am Snom funktioniert

[Pingpong]

Weiss zufällig jemand wie das Snom mit STUN hinter NAT umgeht?
Nutzt es vom STUN-Server nur die WAN-IP für die SIP-Header, oder hat auch der externe Port irgendeine Bedeutung?
Angenommen das Snom möchte RTP auf Port 10000 empfangen, durch NAT wird der Port aber im Router auf z.B. 1024 umgesetzt. Würde das Snom dann im SDP die 10000 einsetzen, oder die 1024?

 

[Tiny_Dragon]

Hallo,

mir ist garnicht bewusst das STUN in einer weise einfluss auf den verwendeten Port nehmen kann.
Ich habe mir gerade mal die schematische Darstellung von NAT hier angeschaut.

Ich selbst, so denke ich, habe in den meisten Fällen mit restricted cone NAT zu tun.

So wie ich das mal gelernt habe stellt der Client aus dem LAN eine "normale" anfrage über den Router:

ich (IP: 192.168.10.x) frage dich (IP: 208.69.34.132) auf Port 80 an und möchte auf Port 80 meine Antwort von Dir.

Dies geht an den Router, weil der Client keinen Direkten Zugriff auf die Zieladresse hat. Da nun aber Theoretisch eine zweite Anfrage von einem anderen Client im Netzwerk kommen kann (IP: 192.168.1.y) macht der router nun daraus folgendes:

ich (IP: 85.80.19.xxx) frage dich (IP: 208.69.34.132) auf Port 80 an und möchte auf Port 123456 meine Antwort von Dir.

Wenn nun die erwähnte gleiche Anfrage aus dem LAN von anderem Client käme, würde der Router zur Unterscheidung den Antwortport auf 123457 ändern um die beiden Anfragen zu unterscheiden.

Die Arbeit an sich liegt eigentlich beim NAT-Router und nicht beim Telefon. Wenn im Telefon STUN aktiviert ist sollte lediglich die Sourceadresse im SIP-Paket auf die Public-IP des Routers gesetzt werden, weil die Gegenstelle ja nichts mit der Private-IP anfangen kann.

Aber ich werde das gleich auch ausprobieren, da ich Heute oder Montag noch NAT-Tests machen muss.

BR

 

[Pingpong]

Hallo,
das Telefon kann natürlich keinen Einfluss auf den durch NAT umgesetzten Port nehmen, aber wenn es weiss wie der Port umgesetzt wird, dann könnte es in die SDP Nachricht diesen externen Port einsetzen.

Die meisten Heim-Router dürften heutzutage auf Linux basieren, und damit Linux Masquerading als NAT haben. Leider finde ich nirgendwo eine genaue Doku wie das arbeitet. Ich habe im Internet ein kleines Programm gefunden mit dem man STUN Server abfragen kann und sehen kann wie die Ports umgesetzt werden: http://code.google.com/p/boogu/

So wie es aussieht versucht Linux den Ursprungsport wenn möglich beizubehalten. Nur wenn das nicht geht wird ein neuer Port ab 1024 aufwärts vergeben. Das würde erklären warum mein VoIP meistens funktioniert, in seltenen Fällen aber One-way-Audio auftritt (RTP-Daten kommen nicht bei mir an).

Ich würde gerne verstehen wann es zu diesem Fall kommt, um mir dann überlegen zu können was ich dagegen unternehme. Dazu muss ich wissen wie Linux Masquerading genau arbeitet, und was das Telefon mit den Informationen vom STUN-Server anfängt. Speziell im Hinblick auf SDP/RTP.

 

[Pingpong]

Jetzt habe ich was gefunden:
http://lists.netfilter.org/pipermail/netfilter/2003-October/047790.html

In order to make STUN/RTP work with Linux, you need to multiplex the
protocols. Your client must send the STUN request to the negotiated port(s)
on the server, and the server must be listening on those ports for both STUN
and RTP requests.

STUN und RTP auf dem gleichen Server und Port gibts doch so gut wie nie. Das wird also nicht funktionieren.
Da helfen nur noch feste Portforwardings für den RTP-Bereich. Das funktioniert aber nur, wenn das Snom den von ihm zufällig gewählten Port beibehält (aus dem Range "Dynamischer RTP Port Start" bis "Dynamischer RTP Port stop") und nicht aus der Antwort des STUN-Servers in die SDP Nachricht einsetzt. Ist das so, weiss das jemand?

Nochmal andersrum erklärt, ich hoffe dann versteht es jeder:
Damit die Gegenseite uns Daten schicken kann, müssen wir ihr im SDP unsere externe IP und den externen Port mitteilen. Externe IP leuchtet jedem ein, mit der internen kann die Gegenseite nichts anfangen. Aber auch der Port muss der externe sein, falls der durch NAT geändert wird (Linux versucht aber ihn möglichst beizubehalten). Korrekt wäre also, beides aus der Antwort des STUN-Servers zu nutzen. Im Fall von port restricted cone funktioniert das aber nicht, außer RTP und STUN würden auf dem gleichen Server und Port laufen. Hier helfen uns nur feste Portforwardings, aber dann darf eben nicht der externe Port (wie es eigentlich korrekt wäre) eingesetzt werden den der STUN-Server lieferte (weil der für unsere Zwecke falsch ist).

 

[Tiny_Dragon]

nun wieder zur Theorie,

wenn der linux-router dafür sorgt das die ports wenn möglich gleich bleiben dann ist es doch garkein problem mit den portforewardings zu arbeiten.
Du definierts auf jedem Telefonen einen eigenen RTP-Bereich (Advanced -> Sip/RTP * RTP/RTCP)

Telefon 1:

Dynamischer RTP Port start:40000
Dynamischer RTP Port stop: 41000

Telefon 2:

Dynamischer RTP Port start:42001
Dynamischer RTP Port stop: 43000

Damit dass die Anfragen unikate sind sollte der RTP strom nach extern durch das NAT auch auf die gleichen Ports gehen.
Nun noch ein portforewarding der definierten Ports auf das jeweilige Telefon und es sollten keine Probleme auftauchen.

 

[Pingpong]

wenn der linux-router dafür sorgt das die ports wenn möglich gleich bleiben dann ist es doch garkein problem mit den portforewardings zu arbeiten.

Genau das ist doch das Problem: wenn möglich
Das bedeutet dass es in 90% der Fälle funktioniert und in 10% nicht. Ich will aber 100%.

Spinnen wir die Theorie mal weiter: nach der ersten STUN-Abfrage ist der Port "besetzt". Folgt jetzt eine weitere STUN-Abfrage auf einen anderen STUN-Server, so muss auf einen anderen Port ausgewichen werden. Vielleicht ist das auch des Rätsels Lösung: derzeit nutze ich bei jedem Account im Snom den STUN-Server des jeweiligen Providers. Für Sipgate stun.sipgate.net, für Sparvoip stun.sparvoip.de usw. Vielleicht sollte man besser für jeden Account den gleichen STUN-Server benutzen und das Problem wäre weg?