[fli4l] NAT timeou?==?utf-8?Q?t für udp und tcp

[Erwin Lottermann]

Zitat: Matthias Taube schrieb am Sa, 16 April 2016 21:28
----------------------------------------------------
> Am 16.04.2016 um 11:14 schrieb Erwin Lottermann:
> 
> > Habe inzwischen einige RFCs zum Thema SIP/RTP und NAT
> > überflogen.
> > Wenn ich es richtig verstanden habe, wird prinzipiell von
> > expliziten
> > Routerkonfigurationen für SIP abgeraten, weil die ehe
> > kontraproduktiv
> > sind. Denn:
> >
> > 1. Sind für SIP/RTP hinreichend Mechanismen spezifiziert, wie
> > SIP-User-Clients und SIP-Proxys mit NAT umzugehen haben und
> >
> > 2. führen spezielle SIP-Routerkonfigurationen meistens dazu,
> > dass SIP
> > nur für einen Client hinter dem Router funktioniert. D.h. falls
> > es dazu
> > kommt, dass Besucher in deinem Netz SIP nomadisierend benutzen
> > wollen,
> > dann kann das durch die Rounterkonfiguration unmöglich sein.
> 
> Zu 1 - Wie gesagt, das hat bei mir (Fritzbox hinter Fli4l) nicht 
> funktioniert. Möglicherweise hätte ich das durch drastisches
> Verkürzen 
> der SIP-Pings der Fritzbox ändern können.
> 

Ich hätte da eher den Verdacht, dass das SIP-Ping in deinem Fall ganz
wirkungslos war.
Bei mir ist es ja auch so, dass die in der FB eingestellten 5 Min. für
das SIP-Ping größer sind als das UDP-Timeout des fli4l, das hier
genannt wurde.
Also müsste mein NAT-Eintrag laufend weg sein.
Zumindest laut Webinterface des fli4l kann ich das aber nicht
nachvollziehen.

Kann mir jemand sagen, wie man den Quellport sehen kann, den der fli4l
für die UDP-Verbindung vergibt?
Im Webinterface des fli4l habe ich nur den Quellport von der FB und den
Zielport am SIP-Proxy gesehen.

Wenn das NAT des fli4l so arbeitet, dass es den Quellport des
SIP-Clients auch nach außen verwendet, so lange es für diesen Port
noch keinen Eintrag in der NAT-Tabelle gibt, dann wäre das eine
mögliche Erklärung, warum die SIP-Verbindung manchmal funktioniert und
manchmal nicht. 
Es funktioniert immer dann, wenn der fli4l Port 5060 als Quellport für
die Verbindung vergibt und funktioniert nicht mehr, wenn der fli4l einen
anderen Quellport für die Verbindung vergibt, weil es noch einen
NAT-Eintrag für 5060 gab.

Laut https://tools.ietf.org/html/rfc6314 soll ein SIP-UserClient hinter
einem NAT-Router dem SIP-Proxy per STUN und SIP-RPORT-Parameter 
mitteilen, dass er auf dem Port zu erreichen ist, den der NAT-Router
vergeben hat.
Wenn das so funktioniert, dann macht ein Portforwarding für 5060 wenig
Sinn.

> Zu 2 - Ich habe in meinem Netz ja nur einen Client, nämlich die 
> Fritzbox. Die fungiert ja als lokaler Server für alle Telefone.
> Meine 
> Besucher fragen mich höchstens, ob sie mal mein Telefon verwenden
> können 
> - nomadisierende Nutzung von SIP dürfte im Heimbereich bisher kaum
> 
> vorkommen.
> 
> Ich bin erstmal froh, wenn es in der einen Konfiguration (Telekom
> SIP - 
> fli4l - fritzbox) stabil funktioniert. Bei der Telefonie ist der
> Rest 
> der Familie heikel - da kann es echt Stress geben wenn das nur
> instabil 
> klappt.
> 

Ja, die klassischen Telefongesellschaften wollen SIP derzeit nur für
die Verbidnung zwischen ihrem Telefon-Gateway und dem Endkunden haben,
damit sie einen Teil der dedizierten Telefoninfrastruktur einsparen
können.

Wenn ich es dabei belasse, habe ich den starken Verdacht, dass der fli4l
bei mir einem von der Telekom verwalteten Router weichen wird, sobald
mir die Telekom den ISDN-Anschluss kündigt.

Vom technischen Hintergrund her erinnert mich das an mein
Homebanking-Programm, dass trotz Internet seine Transaktionen immer noch
per BTX machen wollte und die Telekom dazu ein BTX-Gaterway im Internet
bereitgestellt hatte.

M.E. ist Telefonieren mit den klassischen Telefonnummern tot, wenn es
keine dedizierte Infrastruktur mehr dafür gibt.
Die gibt es noch bei GSM und UMTS.

Gefühlt nimmt die Anzahl der Menschen, die nicht mehr über Festnetz
erreichbar sind, laufend zu.
SIP macht für mich am meisten Sinn, wenn ich auch per SIP erreichbar
bin und nicht nur über das Telefon-SIP-Gateway der Telekom.
Am naheliegendsten erscheint mir dabei, dass jede Email-Adresse
grundsätzlich auch als SIP-Account eingerichtet wird.

Derzeit möchte ich also darauf hinaus, dass meine häuslichen Telefone
per ISDN und per SIP erreichbar sind, so dass man ein Gefühl dafür
entwickeln kann, wie wichtig man die Erreichbarkeit unter der bisherigen
Festnetznummer überhaupt noch nehmen muss.
Außerdem müsste es nach Abschaltung der ISDN-Infrastruktur technisch
möglich sein, dass man bei der Telekom für seine Festnetznummer ein
Weiterleitung auf einen SIP-Account nach eigener Wahl hinterlegt, so
dass man für alle klassischen Anrufer unter der Nummer erreichbar
bleibt.

> Und für die Tests rate ich Dir einfach mit dem Handy 10 Minuten
> lang 
> einmal pro Minute die Festnetznummer anzurufen - da sieht man dann
> ob 
> alle Anrufe bis zum Klingeln am Endgerät durchgeschaltet werden
> (und wie 
> lange es nach einem IP-Wechsel dauert, bis man wieder Anrufe 
> entgegennehmen kann).
> 

Mein Test-SIP-Account bei iptel.org ist nur per SIP erreichbar.

>  > Weißt du, was der conntrack helper für SIP genau macht?
> 
> Nein, evtl. braucht man den auch bei einem so breiten Portforward
> nicht. 
> Aber zur Sicherheit lasse ich den drin - siehe die Ausführung mit
> dem 
> Stress oben.
> 

M.W. machen die RFCs für SIP/RTP keine Vorgaben zu den Ports für die
RTP/RTCP-Verbindungen, da die dynamisch per SIP ausgehandelt werden. 
Mit "breitem Portforwaring" meinst du sicher die empirisch ermittelten
Portbereiche für die RTP/RTCP Verbindungen, die von Fritzboxen und dem
Telekom-Telefon-Gateway bevorzugt werden.

Der oben genannte RFC beschreibt Mechanismen, wie SIP User Clients
UDP-Ports für die RTP/RTCP-Verbindungen im Router dynamisch öffnen und
die vom Router vergebenen Portnummern per SIP der Gegenseite mitteilen
sollen.

Bei meinem Test funktionierte die Audioverbindung auch ohne
Portforwardings.
Allerdings könnte auch das wieder Zufall gewesen sein, falls der fli4l
zufällig die gleichen Ports als Quellport vergeben hat, die die FB
gewählt hat.

Gruß Erwin