NAT, Stun, registration time, 3x spa und eingehende Anrufe

VoIP hinter einer NAT-Firewall
STUN

Bei STUN (Simple Traversal of UDP Through NATs, RFC3489) handelt es sich um eine weitere Möglichkeit, mit der Endgeräte hinter einem NAT-Router die Netzwerkkonfiguration herausfinden können. Hierbei sendet das Endgerät eine Nachricht an einen außerhalb des LAN befindlichen STUN-Server. Dieser schickt dann ein Paket zurück, das Absenderadresse und -port enthält, also die tatsächlichen Informationen, die vom NAT-Router dort eingetragen wurden.

Verwendet ein Endgerät beispielsweise die lokale Adresse 192.168.80.5:8888, so schickt es mit dieser Adresse eine Anfrage an den STUN-Server. Dieser empfängt das Paket mit der Absenderadresse 134.96.249.10:8899 und antwortet an diese Adresse mit einem Paket, das diese IP/Port-Kombination enthält. Somit kann das hinter dem NAT befindliche Endgerät dann für alle folgenden Verbindungen diese Kombination in den SIP/SDP-Paketen verwenden, während es selbst weiterhin auf 192.168.80.5:8888 hört.

Durch die Verbindung zum STUN-Server ist automatisch ein Port im NAT geöffnet, der zum Endgerät weitergeleitet wird. Bei bestimmten NAT-Implementationen ist es allerdings so, dass nur der STUN-Server diesen Port nutzen darf („symmetrisches NAT“). Beim so genannten „Full Cone NAT“ darf ein beliebiger externer Host den Port nutzen.

also warum sollte man auf STUN verzichten können (anderer Beitrag)


"Ans Call Without Reg:" auf YES = Anrufe werden vom Sipura auch beantwortet wenn er sich nicht registriert hat. Wenn allerdings deine externe IP nach 24 Stunden eine ander ist , geht das wohl auch in die Hose. Der Reg. Intervall sitz aber auf 300sek also eigentlich kein Problem.

ich habe z.b in meiner Fritzbox nicht einen Port geforwoarded, und habe 3 Accounts auf der Fb , 1 Sipura PAP2 und einen Sipura SPA941 dranhängen, und keinerlei Probleme.
so langsam glaube ich dass dein Router mit den ports ein problem hat.

also eventuell mal alle Forwardings rauswerfen....maybe

nimm doch einfach stun.sipgate.net und nicht stun.sipgate.de

wenn das wie in den anderen Threads beshrieben mit VIA funktionieren soll alles auf -> YES

hier:
Handle VIA received: NO
Handle VIA rport: NO
Insert VIA received: NO
Insert VIA rport: NO

STUN dann aus.

momentan hab ich keine Idee mehr

TobiasKa schrieb:

Ok! Was soll cih dann einstellen?

Code:

Handle VIA received: NO
Handle VIA rport: NO
Insert VIA received: NO
Insert VIA rport: NO
Substitute VIA Addr: YES
Send Resp To Src Port: NO
STUN Enable: YES
STUN Test Enable: YES
STUN Server: stun.sipgate.de:10000
NAT Keep Alive Intvl: 10

Richtig?

Zum Vergrößern anklicken....

Ja, du kannst alternativ mal einen anderen STUN-Server benutzen. Ich benutze iphone-stun.freenet.de, obwohl ich nicht bei freenet bin. Der Server ist bisher 100% stabil gewesen.

Ferner musst du bei Line 1 und Line 2 folgendes einstellen:

NAT Mapping Enable: YES
NAT Keep Alive Enable: YES (nicht zwingend, aber sicherer)
NAT Keep Alive Msg: $NOTIFY (oder auch möglich: $REGISTER)
NAT Keep Alive Dest: (frei lassen)

Und noch zu der Frage mit "Use Auth ID": Wenn es auf YES gestellt wird, dann musst du den Usernamen bei "Auth ID:" eintragen und nicht bei User-ID.

TobiasKa schrieb:

Dann verstehe ich aber diesen Post nicht: http://www.ip-phone-forum.de/showthread.php?p=646231#post646231

Zum Vergrößern anklicken....

Also STUN schadet nie.

TobiasKa schrieb:

Ich hab noch eine Frage zu dem "Ans Call Without Reg:" Was bewirkt das? Heißt das, dass wenn der Account nicht regisriert ist, keine Anrufe durchkommen (Man merkt also gar nix/kein klingeln)? Oder anders?

Zum Vergrößern anklicken....

Genau: Wenn du nicht registriert bist, dann (und nur dann) bekommen eingehende Anrufe das besetzt-Zeichen. Das trifft damit nur auf direkte SIP-IP-Calls zu.


Ich würde den DNS-Server so belassen wie er ist und nicht einen Telekom-DNS benutzen, wie hier vorgeschlagen wurde.

Ferner kann ich in deinen Syslogs nichts von STUN sehen. Vielleicht ist der Syslog vom SYSTEM noch nicht richtig eingestellt oder aber STUN wird nicht versucht. Probier mal den freenet STUN server.

Hallo TobiasKa!

1) STUN macht für dich viele Dinge:

• es stellt deine externe IP fest
• es stellt fest, welchen Firewalltyp du hast
• es stellt fest, wie damit am besten umzugehen ist

2) je nach dem, wie 'normal' dein Router ist ergeben sich daraus zwei Möglichkeiten der Konfiguration:

• nur STUN um ext. IP zu bekommen, Umgehung der Firewall durch Portforward am Router, dann ist kein NAT keepalive notwendig,
  jeder SPA eigenen SIPport, RTPBereich
• STUN mit Tests für 'Vollautomatik', NAT keepalive notwendig, kein Portforwarding, jeder SPA eigenen SIPport, RTP kann der selbe sein
• optional (wenn du eine feste ext. IP hast) STUN aus, Portforward am Router, IP ins 'ext IP' Feld

3) Der STUN Server merkt sich nichts über dich, das macht alles der SPA, in dem er logische Schlüsse aus der Kommunikation mit dem (beliebig gewählten) STUN-Server zieht (Anders bei Netzen, wo z.B. der Proxy und STUN Server mit im privaten Netz stehen. Da führt die Verwendung eines externen STUN-Servers zu heilloser Verwirrung) Der Port ist am gewählten STUN Server definiert und nicht frei wählbar! Da der Server von hinter der Firewall kontaktiert wird, brauchst du für die Rückrichtung kein Portforwarding am Router. Er hält auch keine Verbindung offen.

4a) NAT keepalive ist nur notwendig, wenn keine Portforwards eingerichtet sind: da die Firewalls keinen Verbindungsaufbau von aussen zulassen, muß die 1. Verbindung zum Proxy (beim Registrieren) von innen 'offen' gehalten werden.

4b) NAT mapping ist immer zu verwenden, wenn interne/externe IP existieren!

5) VIA handling
Handle VIA received: NO
Handle VIA rport: NO
Insert VIA received: NO
Insert VIA rport: NO
Substitute VIA Addr: YES
Send Resp To Src Port: NO

sollte so passen.

6) Ans Call Without Reg

YES nur notwendig, wenn du Anrufe an deine SIP_URI (xyz@deineext-IP) ermöglichen möchtest ohne bei deinem SIP Provider registriert zu sein. Der Proxy deines Providers sendet dir sowieso nur Verbindungen, wenn dur registriert bist.

7) outbound proxy:
alles auf NO, da der Proxy deines Anbieters eh direkt erreichbar ist.

8) use auth ID:
manche Provider akzeptieren zur Registrierung am Proxy den 'Benutzernamen', andere werten nur das authid Feld aus.

Welche Schlüsse du aus diesen Erklärungen ziehst, sei dir überlassen. Es gibt sicher mehrere stabile Einstellungen.

ich habe STUN, ohne Tests, mit NAT mapping, ohne Keepalive, dafür Portforwarding (da ich auch direkt IP-IP Anrufe ermöglichen will) seit Monaten ohne Probleme am Laufen....

schufti

ein guter Tip: editiere deine DebugPostings, da sind deine Accountdaten, Vollname, ext. IP Adresse etc. ersichtlich. Auch wenn man es nicht zum gratis Telefonieren nutzen kann, Blödsinn lässt sich damit allemal anstellen!

Vergleich mal die NAT-Einstellungen der beiden Leitungen.

Sehr eigenartig. Vielleicht kann man im Syslog was erkennen.

TobiasKa schrieb:

hm, jetzt hab ich mal wieder ein total untypisches problem.

...

Im Sipgate Kundenbereich bekomme ich jetzt unter Einstellungen -> Übersicht für den de account alles richtig angezeigt: [email protected].167:49154 (externe IP + hohen port)
dagegen wird mir bei meinem AT interface: sip:[email protected]:5061 angezeigt. Also meine interne IP und den sip port vom spa1001 (line1)

Wie kann das sein, und was läuft da falsch??? (bald bin ich am verzweifeln - nur gut das es auf ankommende rufe keinen unterscheid macht)

Zum Vergrößern anklicken....

In deinem Syslog steht:

Warning: 399 spa "Symmetric NAT Detected"
Das ist sehr schlecht! In diesem Fall schaltet der SPA das NAT-Mapping ab. Das heisst es findet keine Substitution von IP-Adresse und Port mit der externen IP und dem Port statt!
Daher erscheinen bei Sipgate diese internen IP-Adressen.

Die Ursache ist bei deinem Router zu suchen.
Laufen deine Verbindungen vielleicht durch mehrere NATs?


Über die Suchfunktion sollte es mehr zu diesem Fehler geben.

Ja, du solltest auf jeden Fall zusätzlich zu den STUN-Einstellungen noch die Ports weiterleiten!

Direktanschluss am Speedtouch denke ich macht keinen Unterschied.

Das kann ich dir nicht beantworten. Dafür brauche ich einen kompletten Syslog-Mitschnitt, bei dem man sehen kann, wie der SPA bootet.

UPnP ist eigentlich problemlos. Das würde ich nur aus anderen Gründen abschalten.

Hast du nun die Portweiterleitungen aktiviert?
Mail doch bitte mal einen Screenshot davon.

1.) Also UPnP im Router ermöglicht es einem Client selbständig Ports in der Firewall auf zu machen und durchzuleiten. Das benötigt man nicht wirklich.

2.) Mit den Portweiterleitungen sollte es klappen.

3.) Eine einzelne statische IP bringt in dieser Hinsicht keinen Vorteil. Wenn du aber gleich ein ganzes Subnetz hättest, dann könnte der SPA eine eigene feste externe IP bekommen und ohne NAT und ohne STUN arbeiten. Sowas gibt es aber i.d.R. nicht für Privatkunden.