FB hinter Router - Voip Neuregistrierung bei Wechsel der öffentlichen IP

[PeterPawn]

Auch eine Signalisierung eines eingehenden Anrufs im SIP-Protokoll umfaßt ja eine Bestätigung seitens des "SIP-Clients". Wenn es bei 1&1 tatsächlich Probleme bei mehrfachen Registrierungen geben sollte, weil nur der erste registrierte Client eine entsprechende INVITE-Message erhält (und quittiert), ist das nicht automatisch mit der Existenz einer älteren Registrierung, die auf eine nicht mehr zugewiesene IP-Adresse verweist, zu vergleichen.

Wenn der Provider auf dieser IP-Adresse die Signalisierung versucht und es kommt dort keine Antwort (auch keine negative), dann dauert es eben bis zum SIP-Timeout, bis der nächste registrierte Client benachrichtigt wird (solange 1&1 da keinen "Parallelruf" - nicht wirklich, ist immer noch dieselbe Rufnummer - anbietet). Das merkt der Anrufer dann in der Regel daran, daß es bis zum "RINGING" etwas länger braucht - gibt es keine weitere Registrierung, kommt mit dieser Verzögerung durch das Timeout dann eben eine andere Signalisierung für den aufgetretenen Fehler.

Ein "UNREGISTER" halte ich also für überflüssig - auch das zuständige RFC 3261 kennt kein "UNREGISTER". Mit etwas gutem Willen kann man Punkt 6 des Registrierungsprozesses (Abschnitt 10.3, "contact=*,expires=0") noch als "UNREGISTER" verstehen. Es gibt aber Regeln, wann und wie das "refresh" für ein Binding erfolgen soll (Abschnitt 10.2.4).

Die FRITZ!Box sendet ja ihrerseits einen "Vorschlag", wie lange aus ihrer Sicht die Registrierung gültig sein soll (ttl-Parameter in der voip.cfg für die Rufnummer (uaX)) ... wenn ein Provider seinerseits eine kürzere Zeit festlegt, ist das auch noch in Ordnung, eine längere hingegen ist nach Punkt 7 des Ablaufs der Registrierung nach RFC nicht vorgesehen.

Wenn dem Registrar die angebotene Zeitspanne nicht groß genug ist, muß er mit "423" antworten und nicht seinerseits einfach einen höheren Wert in seiner Antwort senden bzw. die FRITZ!Box sollte diesen ignorieren, wenn er größer ist als der eigene Vorschlag (da wäre das Beachten der Vorgabe des Providers dann vielleicht wirklich ein Firmware-Fehler).

Keine Ahnung, wie groß die SIP-Timeouts (für ein INVITE) bei den verschiedenen Anbietern sein mögen ... wenn aber einer mehrfache Registrierungen für dieselbe Rufnummer auch mit unterschiedlichen "Call-ID"s zuläßt (das wären dann ja unterschiedliche Endgeräte und nicht nur unterschiedliche "Adressen", auf denen derselbe SIP-Client zu erreichen ist), dann wird er sicherlich auch kein 60 Sekunden-Timeout verwenden und damit ein "totes" Binding recht zeitnah auch als solches erkennen, wenn ein Anruf signalisiert werden soll und ein neueres Binding existiert.

Man muß sich also (meiner Ansicht und Erfahrung nach) nur um die rechtzeitige Registrierung mit der neuen IP-Adresse kümmern. Wenn der vorgelagerte Router eine DynDNS-Aktualisierung kennt, nimmt man eben die und leitet sie auf einen internen HTTP-Server um, der hinter diesem einzelnen Aufruf dann weitere (für den "richtigen" DynDNS-Service und ggf. für die FRITZ!Box) ausführt.

Die simpelste Form bleibt es aber weiterhin, das FRITZ!OS zu erweitern und in regelmäßigen Intervallen (die max. denkbare "Unerreichbarkeit" der Telefonnummer) einfach eine STUN-Abfrage zu machen und bei Wechsel der öffentlichen IP-Adresse (auch da muß man natürlich aufpassen, wenn es eine gesonderte Verbindung für die IP-Telefonie gibt, was wirklich gewechselt hat) ruft man dann einfach "voipd -U" und "voipd -R" auf (i.d.R. reicht auch letzteres).

EDIT: Wobei natürlich auch das Anpassen von "ttl" schon helfen sollte, solange man diese nicht unter 5 Minuten drückt.

 

[broeselmeier]

Das hier kann man m.E. schon sehr eindeutig als "unregister" ansehen.
Die Bedeutung für das hier angesprochene Problem der unmittelbaren Neuregistrierung nach IP-Wechsel des vorgeschalteten Routers würde ich aber auch nicht überbewerten.

10.2.2 Removing Bindings

Registrations are soft state and expire unless refreshed, but can also be explicitly removed. A client can attempt to influence the expiration interval selected by the registrar as described in Section 10.2.1. A UA requests the immediate removal of a binding by specifying an expiration interval of "0" for that contact address in a REGISTER request. UAs SHOULD support this mechanism so that bindings can be removed before their expiration interval has passed.

The REGISTER-specific Contact header field value of "*" applies to all registrations, but it MUST NOT be used unless the Expires header field is present with a value of "0".

Use of the "*" Contact header field value allows a registering UA to remove all bindings associated with an address-of-record without knowing their precise values.

Zum clientseitigen Senden des Expires zusammen mit dem Register-Request heißt es

When a client sends a REGISTER request, it MAY suggest an expiration interval that indicates how long the client would like the registration to be valid. (As described in Section 10.3, the registrar selects the actual time interval based on its local policy.)

Also MAY.
Im konkreten Fall läuft der Alice/o2-Sip-Account in der 7490 wohl als "anderer Anbieter".
Gibt es einen einfacheren Weg als Einfangen der Request-Message im Netzwerk, um herauszufinden, ob und welches Expire sich die FB wünscht?
Einen Enstellparameter im Webinterface scheint es dafür ja nicht zu geben.

Vielleicht ist das aber auch nicht zielführend, denn das hier liest sich für mich schon so, als wenn sich die FB an das Expire des Providers zu halten hat

10.2.4 Refreshing Bindings

Each UA is responsible for refreshing the bindings that it has previously established. A UA SHOULD NOT refresh bindings set up by other UAs.

The 200 (OK) response from the registrar contains a list of Contact fields enumerating all current bindings. The UA compares each contact address to see if it created the contact address, using comparison rules in Section 19.1.4. If so, it updates the expiration time interval according to the expires parameter or, if absent, the Expires field value. The UA then issues a REGISTER request for each of its bindings before the expiration interval has elapsed. It MAY combine several updates into one REGISTER request.

A UA SHOULD use the same Call-ID for all registrations during a single boot cycle. Registration refreshes SHOULD be sent to the same network address as the original registration, unless redirected.

Wo wären Ansätze für Änderungen am FritzOS?

Ignorieren des Expire des Providers geht wohl eher nicht.
Im SIP-Conntrack-Helper des netfilter-Projects sind 3600s, auf die das Timeout des SIP-UDP-NAT-Eintrags im Router gesetzt wird, eingetragen. D.h. die Programmierer scheinen davon auszugehen, dass innerhalb von 3600s in jedem Fall eine Neuregistrierung gemacht wird. Im FritzOS könnte man das vielleicht so regeln, dass das Expire des Providers berücksichtigt wird, aber max. 3600s eingestellt werden. Aber 3600s dürften als Maximale Nichterreichbarkeitszeit nach IP-Wechsel auch nicht konsensfähig sein.

Ob die angesprochene Verwendung von STUN am Ende durchführbar ist, weiß ich nicht.
Wurde das schon irgendwo einmal diskutiert?
Dann wird es vermutlich auch so sein, dass die großen SIP-Provider AVM Vorgaben machen, wie ihre STUN-Server zu benutzen sind, falls sie überhaupt einen STUN-Server verwenden. Ohne sich Arger einzuhandeln, kann AVM die Benutzung der STUN-Server vielleicht auch nicht einfach ändern.

Zu den nicht regulären Hacks, um die FB nach IP-Wechsel zum Neuregistrieren zu bringen:

Der Vorschlag, die DynDNS-Neuregistrierung des vorgeschalteten Routers als Trigger für die Neuregistrierung des SIP-Accounts der FB abzugreifen, dürfte für solche Router gemeint sein, bei denen man keine detaillierte Kontrolle über die Abläufe beim Erneuern der IP hat.
Im konkreten Fall des Linux-Routers (fli4l) gehe ich davon aus, dass man freien Zugriff auf die IP-Up/-Down-Skripte hat.

Am elegantesten klingt vielleicht der von AVM bevorzugte Weg über TR-064
https://avm.de/service/schnittstellen/

Eine remote steuerbare Steckdose für die FB sollte auch funktionieren.

Kann jemand etwas dazu sagen, wie es mit den Expires bei den anderen großen Providern aussieht. D.h. ist der Wert von mehr als 1h bei Alice/o2 auffällig lange oder machen andere das genau so?

 

[koyaanisqatsi]

Ähem, zur Info :silly:
Das Expiry wird von 1&1 festgelegt auf: 7200 Sekunden
...hab ich gerade aus meinen F!B-Support-Daten, angelegt direkt nach Neustart, gegrept.

Die Fritz!Box gewährt auf ihre Registrare: 300 Sekunden

 

[PeterPawn]

Einfach weiterlesen:

The registrar MAY choose an expiration [COLOR="#008000"]less[/COLOR] than the requested expiration interval.  
If and only if the requested expiration interval is greater than zero AND smaller than 
one hour AND [COLOR="#008000"]less than a registrar-configured minimum[/COLOR], the registrar MAY reject the 
registration with a response of 423 (Interval Too Brief).  This response MUST contain
a Min-Expires header field that states the minimum expiration interval the registrar is
willing to honor.  It then skips the remaining steps.

Ich hätte ja zuerst mal probiert, was denn Alice von einem "Expires"-Wert von 5 Minuten hält. Kommt da kein "423", sollte der Client auch diese 300 Sekunden verwenden, wenn sie das kürzere Intervall im Vergleich zum Wert vom Provider spezifizieren. Ich wüßte nicht, wie der Provider (vielleicht nennen wir ihn ja korrekterweise "UAS") ohne passende Fehlernachricht den Wert vom UAC einfach ignorieren kann. Zumindest müßte sich der UAC an einen größeren Wert auch nicht halten (ohne 423 wohlgemerkt).

Daß man das "removing bindings" mit etwas gutem Willen als "UNREGISTER" auffassen könnte, hatte ich IIRC selbst geschrieben ... daß es sich nicht um ein "UNREGISTER" handelt, sieht man schon an der Wortwahl der Autoren des RFC-Textes.

Bei der Lösung hast Du mich auch gründlich mißverstanden ... Du selbst hast die Möglichkeit über Telnet angesprochen. Wobei ich nicht verstehe, was ein Telnet-Zugang an dieser Stelle bringen mag, man wird sich ja kaum beim Wechsel der IP-Adresse einloggen und eine neue Registrierung anstoßen wollen. Zwar ginge das theoretisch auch (man müßte halt erst einmal den Trigger festlegen und wer in diesem Gespann nun eine Änderung des Zustands detektieren und/oder signalisieren soll), aber das braucht dann ja auch mindestens einen externen (Telnet-)Client, der sich in die FRITZ!Box (automatisch) einloggen würde.

Mein Vorschlag basierte ziemlich deutlich auf einer periodischen Abfrage der öffentlichen IP-Adresse über einen STUN-Server (und da das der AVM-Code nicht macht, muß da selbstverständlich eine eigene Lösung her) und die daran anschließende direkte Steuerung der Registrierung des "voipd" - das geht natürlich nur auf der Box selbst.

Wenn Du unbedingt von außerhalb der FRITZ!Box agieren willst, geht das logischerweise "auch irgendwie" (den Vorschlag mit der Steckdose beim simplen Wechsel der IP-Adresse halte ich für Unsinn, aber das ist vermutlich nur meine persönliche Ansicht, weil ich nach einem Wechsel der IP-Adresse jetzt nicht ein Gerät (mit bekannten Folgen für die Lebenserwartung) sinnlos aus- und einschalten und in der Folge komplett neu starten würde) - auch hier wäre aber die eigentliche Frage, wer das triggert und worauf die Entscheidung dann basiert, denn so eine Steckdose kriegt die Änderung der externen IP ja auch nicht von alleine mit.

Wenn das Steuern über TR-064 aber am Ende wesentlich aufwändiger ist (m.W. hat keine der Funktionen an dieser Stelle die Möglichkeit, nur die Aktivierung einer Rufnummer aus- und einzuschalten, was dann sicherlich auch eine neue Registrierung auslösen würde und damit liefe das am Ende ggf. sogar auf Löschen und Neueinrichten des Accounts hinaus), dann sollte man vielleicht mit den eigenen Überlegungen noch einmal ein paar Schritte zurückgehen.

Einen Mechanismus zur Erkennung der Änderung der öffentlichen IP-Adresse in eine FRITZ!Box als kaskadierten Router einzubauen, dauert ca. 10 Minuten ... beim Programmieren einer passenden Lösung über TR-064 (auch wenn das die offizielle Schnittstelle sein mag und ich liebe solche dokumentierten Schnittstellen nachgerade) würde man vermutlich wesentlich länger benötigen. Erst recht dann, wenn die Schnittstelle die eigentlich notwendigen Funktionen gar nicht bietet - dokumentierte Schnittstellen sind gut und sinnvoll, wenn sie die Arbeit erleichtern. Da die Lösung mit der STUN-Abfrage am Ende vielleicht aus 20 Zeilen Shell-Code besteht (vielleicht noch die BusyBox austauschen), würde ich da auch die Gefahr des "Veraltens" durch Änderungen seitens AVM eher vernachlässigen.

 

[broeselmeier]

Ähem, zur Info :silly:
Das Expiry wird von 1&1 festgelegt auf: 7200 Sekunden
...hab ich gerade aus meinen F!B-Support-Daten, angelegt direkt nach Neustart, gegrept.

Die Fritz!Box gewährt auf ihre Registrare: 300 Sekunden

Ok, dann scheint Alice/o2 da ja in "guter" Gesellschaft zu sein.

Kann man in den Support-Daten auch sehen, ob und welches Expire sich die FB im Register-Request an 1&1 gewünscht hat?

 

[koyaanisqatsi]

Schau ich später mal nach und poste, da Daten schon gelöscht und F!B Neustart angesagt ist.

 

[broeselmeier]

@PeterPawn
Ok, da habe wir wahrscheinlich unterschiedliche Ausgangssituationen. Für mich ist die FB bei der konkreten Fragestellung am Ende nur ein x-beliebiger SIP-Client, den ich im Detail wenig kenne.

Mein Gebiet ist eher der vorgeschaltete Router und der macht per Cron-Job den IP-Wechsel irgendwann in der Nacht, wenn es höchstwahrscheinlich niemanden stört. Aber selbst wenn der Router mal am Tage durchgestartet werden muss, dann laufen da die entsprechenden Shell-Skripte ab, die sich um die Aktionen kümmern, die beim IP-Wechsel im Router gemacht werden müssen.

Falls die FB eine remote erreichbare Schnittstelle hätte, über die man die Neuregistrierung der SIP-Accounts anstoßen könnte oder eine remote steuerbare Steckdose hätte, dann könnte man die erforderlichen Aktionen in das IP-UP-Skript des Routers einbinden.
Aus Sicht der Router-Projekt-Developer wäre sicher eine Lösung wünschenswert, die mit allen SIP-Clients funktioniert.

Wenn wir mal bei der FB bleiben, dann klingt die besprochene Anwendung von STUN direkt innerhalb der FB aber auch sehr elegant, denn dann muss man am Router gar nichts machen.
Kann man tatsächlich solche eigenen Skripte in jede VOIP-fähige FB einbauen, ohne dass man die Kompatibilität mit AVM-Firmware-Updates verliert?

edit: zum reject mit 423 steht auch wieder nur MAY

the registrar MAY reject the registration with a response of 423 (Interval Too Brief)

 

[PeterPawn]

Erstens ... nein, kann man nicht in jede FRITZ!OS-Firmware einbauen.

Zweitens ... der Kontext (allgemein gehaltene Lösung für Nachnutzung an anderen Stellen und mit anderen SIP-Clients) war aus

habe hier einen Fall, da hat jemand eine 7490 als SIP-Client für einen alice-voip Account hinter einem Router erfolgreich am Laufen.

nicht direkt abzulesen oder ich habe mich dafür zu blöd angestellt.

Wenn es einen externen Trigger gibt (bei fli4l ja wahrscheinlich), dann reicht es im Extremfall schon aus, in die AVM-Firmware einfach eine einzige Zeile einzufügen. Benutzt man dafür die "inetd.conf" und startet beim Eintreffen eines UDP-Paketes auf einem vereinbarten Port einfach ein Shell-Skript, welches die erneute Registrierung der Rufnummern im "voipd" anstößt, kann dieses Skript im Extremfall sogar auf dem internen NAND-Flash der FRITZ!Box liegen. Auch das Hinzufügen der einen Zeile zur "inetd.conf" könnte man (im Prinzip) ohne eine Änderung am Inhalt des SquashFS-Images für das FRITZ!OS machen ... zumindest bei einigen Modellen (was in erster Linie die neueren meint). Dann fügt man einfach im Bootprozess an der richtigen Stelle das Schreiben dieser einen Zeile ein ... ich habe bei mir da mehr als einen Eintrag zusätzlich liegen, mit jedem einzelnen kann ich ein Skript mit einem definierten Namen aufrufen (welches ich vorher auch per NAS-Zugriff ändern kann, wenn ich will). Will man aus Sicherheitsgründen keine "dynamischen Skripte", die über FTP/Samba/HTTP zu ändern wären, ruft man das eben von einer unzugänglichen Stelle aus auf.

Das Polling über den STUN-Server ist nur dann notwendig und sinnvoll, wenn es keinen externen Trigger gibt ... ist ein solcher vorhanden, ist das nur sinnloser Traffic (inkl. nicht genau kalkulierbarer Verzögerung vom Wechsel der IP bis zum Feststellen der Änderung).

 

[broeselmeier]

Dass das Problem aus Sicht des fli4l-Routers nach einer möglichst allgemeingültigen Lösung schreit, ist mir wahrscheinlich erst klargeworden, nachdem sich herausgestellt hat, dass das lange Expire von Alice/o2 kein Einzelfall ist.
Ich habe selbst bisher nur mit iptel.org und sipgate.de SIP-Experimente gemacht.
Iptel.org sorgt sogar serverseitig dafür, dass der SIP-NAT-Eintrag im Router nicht nach 180s in den Timeout läuft. Bei sipgate ist das Expire 10 Minuten. Von daher war ich anfänglich der Meinung, dass man für den Einzelfall Alice und die FB7490 nur nach einer Einzellösung suchen muss.

So lange es den Telnet-Zugang zu den FB gab, gab es sogar eine Fli4l-Erweiterung, die den voipd in der Fritzbox beim IP-UP neu gestartet hat.
http://svn.fli4l.de/branches/3.10/testing/src/packages/fritzbox/opt/etc/ppp/ip-up900.fritzbox

Deine Ausführungen zu den Möglichkeiten innerhalb der Fritzboxen verstehe ich auf die Schnelle nicht.

 

[PeterPawn]

Das Skript ist aus 2007 ... wer heute noch im LAN auf diesem Weg (Benutzername/Kennwort im Klartext) Dienste auf irgendeinem Gerät steuert, hat (für meine Begriffe) die letzten 5-8 Jahre verschlafen.

Aber das ist zumindest mal wieder ein sehr schönes Beispiel dafür, warum der Telnet-Zugang erst einmal ausgebaut werden mußte aus der Firmware. Jeder Account, der über ausreichende Rechte für das Telnet-Login verfügt, kann parallel dazu auch zur Konfiguration der Box verwendet werden.

Was sich daraus ergeben kann, darf sich jeder selbst ausmalen ... also meine dringende Bitte an alle Kinder, die jetzt noch mitlesen: Bitte nicht daheim nachmachen.

Mein Vorschlag ist zwar auch nicht besonders gut abgesichert (hier steht halt "einfach" gegen "richtig sicher") ... aber die einzige Konsequenz, die sich aus einem "Mißbrauch" ergeben würde, ist die wiederholte Registrierung eines SIP-UACs beim UAS.

Ansonsten ist da an meinem Vorschlag auch nicht viel zu verstehen ... es geht nur darum, den "internet super server" namens "inetd", der in der FRITZ!Box ohnehin verwendet wird, um ein zusätzliches Shell-Skript zu bereichern, das nach einem beliebigen UDP-Paket an einen definierten Port der FRITZ!Box dann abgearbeitet wird - auch das ist kein Dogma, es kann auch TCP sein oder irgendetwas mit einer intensiveren Prüfung (z.B. hosts.allow/hosts.deny), daß der Trigger von einem berechtigten System kam.

Was es in meinen Augen nicht sein kann/darf, ist eine beliebig offene Schnittstelle mit Authentifizierung im Klartext, wo jeder Depp am Ende die FRITZ!Box beliebig steuern kann. Solange es auf der FRITZ!Box keine Mißbrauchsmöglichkeiten gibt, mag das auch noch angehen ... wenn dort ein SIP-Client für eine Nummer beim Provider registriert ist, ist der Schaden in meinen Augen vorprogrammiert.

 

[broeselmeier]

Vielleicht mal eine Frage, die im AVM-Unterforum OT ist:

Bevor man versucht, durch einen proprietären Hack einen AVM-Router, den man zum SIP-Client hinter einem NAT-Router degradiert hat, dazu zu überreden, bei Wechsel der öffentlichen IP die SIP-Accounts neu zu registrieren:

Kennt jemand einen SIP-Client, der das von Haus aus besser unterstützt? D.h. der entweder einen Mechanismus hat, mit dem er den Wechsel der öffentlichen IP selbst bemerkt und dann die SIP-Accounts neu registriert bzw. eine handhabbare Schnittstelle hat, über die der vorgeschaltete Router die Neuregistrierung der SIP-Accounts anstoßen kann?

---
Bzgl. TR-064
Der Service X_VoIP1 bietet tatsächlich keine für die Neuregistrierung der SIP-Accounts geeignete Action.
Der Service DeviceConfig1 bietet aber Reboot als Action.
https://avm.de/fileadmin/user_upload/Global/Service/Schnittstellen/deviceconfigSCPD.pdf

Wenn man sich das FHEM-Projekt anschaut, dann scheint der Zugriff per TR-064 auf die Fritzboxen auch längst gängige Praxis zu sein. http://www.fhemwiki.de/wiki/FRITZBOX