[fli4l] VoIP: Prob?==?utf-8?Q?leme mit eingehenden Anrufe?==?utf-8?Q?n

[Erwin Lottermann]

Hallo Thomas,

ja, so hat man eine viel bessere Basis, um Probleme einzugrenzen.

Ich muss aber zugeben, dass ich so etwas selbst noch nicht hinbekommen
hätte.
Den Output meine ich aber zu verstehen.

Was mir auffällt:

* der NAT-UDP-Timeout ist bei dir 3600s. 

Bei mir ist er 180s, was der fli4l-Standardwert sein dürfte
http://forum.nettworks.org/index.php?t=msg&th=7158&start=0& . Falls du
das nicht bewusst umgestellt hast, dann könnte das durch den
SIP-ConntrackHelper gemacht worden sein, den du wahrscheinlich noch
aktiv hast.

* über deine SIP-Verbindung gehen keine regelmäßigen Daten

Irgendwo in den SIP-RFC habe ich gelesen, dass bei SIP potentielle
Verbindungsprobleme durch tote Verbindungen innerhalb von 2 Minuten
erkannt werden sollen. Das kann man nach meinem Verständnis nur dadurch
erreichen, dass man innerhalb dieser Zeitspanne Daten über die
Verbindung schickt. Client- oder serverseitiges SIP-Ping per UDP (wegen
geringerer Serverlast als TCP) scheint mir das angesagte Mittel für
diesen Zweck zu sein. Lange Timeouts oder statische Portforwardings
sagen nichts darüber, ob die Verbindung auch in dem Moment
funktionieren würde, wenn jemand anrufen will.

Wie die einzelnen SIP-Provider das handhaben, weiß ich nicht. Da der
summierte SIP-Ping aller Kunden nicht unerhebliche Ressourcen beim
Provider fressen kann, mag es Provider geben, die die Zeitintervalle
größer eingestellt haben, oder von sich aus gar nichts unternehmen, um
die SIP-Verbindung zu überwachen bzw. nicht ausreichend
Serverressourcen bereitstellen um hinreichend zuverlässig auf
clientseitiges SIP-Ping zu antworten.
Getestet habe ich bisher iptel.org und sipgate.de.
iptel.org macht serverseitiges SIP-Ping, so dass auch ohne SIP-Ping der
FB und mit 180s UDP-Timeout die Verbindung dauernd steht (zumindest so
weit ich das im Webinterface des fli4l beobachten konnte ;))
sipgate.de macht kein serverseitiges SIP-Ping. Ohne Ping der FB, ist die
Verbindung nach 180s weg und wird nach insgesamt 10 Minuten neu
aufgebaut. D.h. sipgate scheint der FB ein Reconnect-Interfall von 600s
zu schicken.
Wenn ich in der FB den SIP-Ping auf kleiner 180s stelle, bleibt auch die
sipgate-Verbindung durchgehend aktiv.
Nachteil der (meiner) FB ist, dass das SIP-Ping nur global für alle
konfigurierten Verbindungen eingestellt werden kann. D.h. iptel.org muss
jetzt auch mit dem SIP-Ping der FB leben.

* weil über deine SIP-Verbindung keine regelmäßigen Daten gehen, ist
die Verbindung nach Ablauf deines UDP-Timeouts von 1h weg (17:38 in
deinem Log), falls nicht zwischenzeitlich jemand telefoniert oder ein
Anruf eingeht (z.B. 17:58)

Ohne manuelles Forwarding für 5060 auf die FB wärst du jetzt nicht
erreichbar. Rausrufen sollte funktionieren, weil dann die FB dafür
sorgt, dass die Verbindung neu aufgebaut wird.

* nach 6 Minuten wird die Verbindung neu aufgebaut

Wir wissen jetzt nicht, ob das durch Ablauf des Reconnect-Intervalls,
das O2 mit der FB ausgehandelt hat, passiert ist oder dadurch, dass
jemand raustelefoniert hat.

Was könnte man jetzt testen?

Folgende Fragen scheinen mir relevant:

1. Ist man in den Zeiten ohne aktive Verbindung im fli4l erreichbar und
kann man dann rausrufen? d.h. will man ein manuelles Forwarding für
5060 auf die FB konfigurieren und führt das auch dazu, dass man auch
ohne aktive Verbindung erreichbar ist und telefonieren kann? 

2. Wie lange kann es nach Störungen maximal dauern, bis die Verbindung
neu aufgebaut wird? D.h. wie lang ist das O2-Reconnect-Intervall?

So wie es jetzt bei dir ist, scheint der Reconnect der FB der einzige
Mechanismus zu sein, der dafür sorgt, dass nach einer beliebigen
Störung wieder eine funktionierende SIP-Verbindung aufgebaut wird (ich
weiß z.B. nicht, wie es sich mit den NAT-Einträgen im fli4l verhält,
wennn der fli4l eine neue öffentliche IP erhält). Die FB bekommt
normal nichts von einem Wechsel der öffentlichen IP mit und wenn das
O2-Reconnectintervall 1h oder größer ist, dann kann es schon stören,
falls der fli4l mal tagsüber eine neue IP bekommt.

Je nachdem, was bei den Tests herauskommt, käme dann das SIP-Ping der
FB ins Spiel. 
D.h. wenn in den Zeiträumen ohne aktive Verbindung Telefonieren oder
Erreichbarkeit nicht gewährleistet ist oder es nach Störungen zu lange
dauern kann, bis wieder eine funktionierende SIP-Verbindung aufgebaut
wird, kann man versuchen das SIP-Ping in der FB anzuschalten. 2 Minuten
wäre vielleicht ein Anfangswert.

Irgendwie kann es aber nicht Sinn der Sache sein, dass jeder Kunde das
irgendwie einstellt, so dass der Provider seine Serverlast eigentlich
nicht kalkulieren kann. Ich denke aber, dass hier noch nicht alle
Provider zu Ende gedacht haben und es deshalb durchaus zu
nichtvorhersehbarem Verhalten kommen kann. Da derzeit fast alle
SIP-Provider offiziell keine SIP-Clients hinter NAT-Routern
unterstützen, muss man wohl auch davon ausgehen, dass es den Providern
egal ist, ob und wie zuverlässig das funktioniert.