Hält SIP Ports offen? Reg-Intervall hinter NAT-Verbindung

Fux

Mitglied
Mitglied seit
3 Jun 2004
Beiträge
440
Punkte für Reaktionen
1
Punkte
18
Mod on
Thread-Split, Ausgang war Verbindungsproblem hinter der KD-Firewall und ein Umgehen der Angelegenheit mit Reg-Intervall von 5 Minuten ...

Gruß,
Exim
Mod off


SIP hält definitiv keine Ports offen. Mit wem sollte es sich auch verbinden. Oder weißt du schon vorher, wer gleich anruft ? ;)
Es ist darauf angewiesen, daß ein Request auf den bekannten UDP-Ports zumClient durchkommt.
Zur Begründung der Firewall: Interessant. Dennoch wäre es besser (=im Sinne des Kunden), wenn er eine Wahlmöglichkeit hätte, ob die FW an ist oder nicht.
 
SIP hält mittels Registrierung die Ports offen, denn die Signalisierung (Ruf kommt/geht) und Registrierung laufen über den selben Port. Nikotel arbeitet, wenn ich es richtig verstanden habe, ausschließlich so. Deshalb benötigen sie kein "NAT keep alive".
 
Hm, wenn dem so wäre, bräuchte man die ganzen Portforwardings nicht.
Ist es nicht eher so, daß die Registrierung dem Server lediglich mitteilt, unter welches IP der Client momentan erreichbar ist ?
Ich meine, mich zu erinnern, daß man bei * auch ohne Client-registrierung arbeiten kann, wenn diese nicht dynamisch sind - also immer dieselbe IP haben.
Bei einer Registrierung, die nur alle 60 Minuten erfolgt, wirst du auch Probleme haben, eine Firewall, die nach 3 Minuten wieder dichtmacht offen zu halten.
 
Richtig, deshalb ist der Geheimtip auch "Register Expiration 5 Minuten". Nikotel empfiehlt bei den Sipura einstellungen sogar 60sec!

Bei meinem Router brauche ich kein Forwarding ... Sicher wird bei der Registrierung auch die IP gesendet, aber eben auch die Firewall offen gehalten - wie gesagt, so habe ich es verstanden.
 
Nochmal hm: Selbst wenn das Verkürzen der Expiration den Signalport offen hält (und die Last beim SIP-Provider erhöht), so öffnet es doch nicht die Audio-Ports. Ohne die kann man nun aber mal schlecht telefonieren...

EDIT

Wenn es so einfach wäre, dann hätten wir hier im Board sicherlich nicht diese Massen von Posts zu dem Thema: Ich kann meinen Gegenüber hören aber er mich nicht...

/EDIT
 
Ok, wir werden hier ziemlich OT, evtl. kann einer der Admins mal teilen :)

Womit wir beim nächsten Thema wären. SIP beschreibt alles das, was zum Verbindungsaufbau, die Registrierung und sonstige Informationen (z.B. DTMF als Info) nötig ist. Dafür wird üblicherweise Port 5060 genutzt. Die Audioports sind unterschiedlich, bei SIPPs 30000-30005, bei den Sipura 16xxx usw. und werden während der Signalisierungsphase ausgehandelt.

Z.B. Sipps, Du rufst irgendwo an: Am Ende Deiner Invite-Message kommt irgendwo die Zeile "m=audio 30000 RTP/AVP 0 8 97 2 3", heißt "ich nehme Mediaport 30000". Der Registrar antwortet z.B. in der "183 Session Progress"-Message mit "m=audio 19092 RTP/AVP 0 100", womit die Mediaports ausgehandelt sind. Jetzt müssen die theoretisch nur noch jeweils von innen geöffnet werden und bingo!
 
Trennung passiert gleich. Die 60 Sekunden in der Nikotel-SPA-Anleitung sind übrigens ein Fehler, das sollte 3600 heissen, der Autor hat gedacht dass da analog zur GS-Hardware Minuten eingetragen werden.
 
Danke Exim!

Leider hast Du auch meine schöne Theorie zerstört :-? Gibt es denn ne andere Antwort, warum Nikotel kein NAT keep alife braucht?
 
@ Robinson
Nun bin ich wieder etwas schlauer :)
Aber eine Frage hab ich trotzdem noch. Nach der Aushandlung der RTP-Ports über SIP - öffnet der Adapter diese Ports dann selbstständig vom sich aus ?
 
Nach meiner Theorie: ja ...
 
Nach der Aushandlung der RTP-Ports über SIP - öffnet der Adapter diese Ports dann selbstständig

NEIN - die Ports werden bereits WÄHREND der Aushandlung geöffnet.
 
Robinson schrieb:
Danke Exim!

Leider hast Du auch meine schöne Theorie zerstört :-? Gibt es denn ne andere Antwort, warum Nikotel kein NAT keep alife braucht?

Nikotel benötigt keinen STUN(!) da die wohl (Vermutung) einfach die Absender-IP und den Absenderport direkt von den IP-Paketen(!) der Register-Anfragen nutzen und sich nicht um die im SIP-Register-Request stehende IP kümmern. Wie gesagt nur Vermutung, aber das wäre technisch auf jeden Fall so machbar.

NAT-Keepalive: Am NAT-Keepalive geht aber unter Umständen auch bei Nikotel kein weg vorbei, Beispiel: Der Router hat einen angenommenen NAT-Table-Timeout von 1 Minute, d.h. er verwirft nach einer Minute die NAT-Information, dass von innen Port 5060 etwas nach aussen zu einer bestimmten IP ging. Kommen innerhalb dieser Minute von der bestimmten IP Pakete an Port 5060 werden sie aufgrund der NAT-Tabelle nach innen weitergeleitet. Nach dieser einen Minute (NAT-Eintrag im Router gelöscht) lässt der Router die Pakete nicht durch. Bei einem Reg-Intervall von beispielsweise einer Stunde kommt dann eben schon nach einer Minute kein Anruf mehr an da der Router die auf Port 5060 geschickten SIP-Invite-Nachrichten blockt, bzw. genauer gesagt die betreffenden IP-Pakete. In so einer Konstellation hilft entweder der NAT-Keepalive (für den entsprechenden SIP-Port, hier eben 5060) mit Intervall < 60 Sekunden oder - und das ist meiner Meinung nach die bessere da sauberere Lösung - Portforwarding.

Ich habe Portforwarding aktiviert, NAT-Keepalive ist aus, Reg-Intervall bei Nikotel ist 30 Minuten. Soll heissen nach einer Änderung der externen IP (bei mir etwa 2x pro Woche) ist der SPA maximal 30 Minuten nicht erreichbar. STUN (der "nicht beworbene" von Nikotel) läuft bei mir trotzdem damit der SPA seine ext. IP kennt und Direktverbindungen SPA <--> SPA - beide hinter Firewall und NAT-Router - funktionieren.

Und nochwas zum Unterschied NAT-Keepalive bei SPA und GS: Ein SPA schickt SIP-Notify-Messages (daran stört sich beispielsweise der sipgate-Proxy, der Nikotel-calamar findet es ok). Ein GS schickt IIRC 4 Byte große UDP-Pakete an den Proxy. Genau solche 4 Byte-Pakete (ich glaube es waren 4 Byte, der letzte trace von NAT-Keepalives ist schon länger her) schickt übrigens der Sipgate-Proxy regelmässig an den SIP-Port des registrierten UserAgent. Wahrscheinlich um den Onlinestatus festzustellen - kommt eine ICMP-Meldung "Port unrecheable" oder dgl. zurück fliegt wohl bei Sipgate der Onlinestatus raus. Nur Vermutung ...
 
Glaube, daß der Onlinestatus bei Sipgate nach der Registrierung des Telefons einfach gecached/gespeichert und gar nicht geprüft wird und nur an der eingestellten Register-Intervall-Zeit festgemacht wird und erst geprüft wird,wenn ein Anruf von außen eingeht.
Hab meine Expire-Zeit sehr lang gesetzt und auch wenn meine Netzverbindung gekappt ist, dauert es beim Anrufen eine Weile, bis ein Besetzt kommt (keine Voicemailbox). Nach Ablauf der Registrierungs-Zeit kommt dagegen gleich die Voicemailbox...
Ein netter Nebeneffekt ist, daß man so mit einem GS-Telefon, das nur ein einziges Profil kann, gleichzeitig mit zwei (oder mehreren?) Festnetznummern bei Sippgate erreichbar sein kann, wenn man nacheinder auf der Configuration-HTML-Seite die Anmeldedaten verschiedener Accounts einträgt, abspeichert und das Telefon bootet. Man bleibt als online gemeldet (und erreichbar, wenn die Verbindung einschließlich IP unverändert bleibt) bis die Zeit abgelaufen ist. Raustelefonieren geht mit der zuletzt registrierten Nummer. Nervend nur, daß man das von Hand eintippen muß. Deshalb wär's hilfreich, wenn ich die wechselnden config-daten per TFTP einlesen lassen könnte. Nur wie bekomme ich die? Gibt es da irgendwo 'ne Beschreibung des Aufbau's der Datei, ich bastele die mir gern auch mit 'nem Hex-Editor (gefährlich sind wahrscheinlich die Prüfsummen).
 

Statistik des Forums

Themen
244,695
Beiträge
2,216,692
Mitglieder
371,315
Neuestes Mitglied
jack-mack
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.