Trunks registrieren sich nicht nach IP-Wechsel

[rostreich]

Hallo liebe Mitglieder,

ich habe schon graue Haare bekommen, da ich alles erdenkliche ausprobiert habe, wie ich das in den Griff bekommen könnte. Habe die Suche natürlich benutzt, aber die Suchbegriffe 'IP dynamisch' , 'IP Wechsel' , 'dynamic IP Trunk' waren wohl falsch. Google direkt spuckte auch nicht viel aus.


Die Box hängt hinter einem aktuell gepatchen IP-Fire. Einfachste Config: grünes+rotes Netz. Die Ports 5060 UDP und 10000-20000 UDP sind für die IP des Asterisk geöffnet.

An meinem Asterisk (eigentlich elastix 2.4) funktioniert alles. Mit diversen Trunks rausrufen, CallerID, Rufumleitung, die Sondertasten an den Snoms und sogar das analoge Faxgerät funktioniert problemlos.

Nur wenn ich vom Provider eine neue IP bekomme (alle 24h), gehen die Trunks nicht mehr online und das Log füllt sich mit:

Registration for '[email protected]' timed out, trying again (Attempt #53)

bzw.

für den Sipgate Trunking Tarif ebenso:

 Registration for '[email protected]' timed out, trying again (Attempt #53)

usw.

Elastix hat ja noch FreePBX als Oberfläche, das dürften die meisten eher kennen.
Da sieht meine Config folgendermaßen aus:

NAT Settings

NAT: Yes
IP Configuration: Dynamic
Dynamic Host: meine.dyndns.org Refresh rate: 10 // Die Dyndns ist selbstverständlich immer aktiv und auch pingbar, die korrekte IP-Adresse wird also aufgelöst.
Local Networks: 10.0.0.0/255.255.254.0 // Das stimmt definitiv.

Ich hatte auch mal spaßeshalber Static IP samt dyndns ausprobiert, das ging auch nur bis zum nächsten IP Wechsel.
Mein IP Wechsel findet morgens um 5:00 statt, vorgestern funktionierte das und die Trunks gingen sofort wieder online. Heute morgen (nichts an der Einstellung geändert) ging es wieder nicht.

Hier mal meine Trunks, evtl. ist da was krumm:

Büro:

type=peer
insecure=very
nat=yes
username=1111111t1
fromuser=1111111t1
fromdomain=sipconnect.sipgate.de
secret=vollgeheim
host=sipconnect.sipgate.de
qualify=yes
canreinvite=no
dtmfmode=rfc2833

Privat:

type=peer
insecure=very
nat=yes
username=1111111e2
fromuser=1111111e2
fromdomain=sipgate.de
secret=vollgeheim2
host=sipgate.de
qualify=yes
canreinvite=no
dtmfmode=rfc2833

Reconnecte ich den ipfire manuell, habe ich es auch noch nicht geschafft, irgendwie wieder die Trunks online zu bringen. Nur ein Neustart der Asteriskmaschine bringt die Trunks online.

Wer kann helfen, wer weiß was? Habe meinen Wecker derzeit auf 5:30 gestellt, damit ich den Server rebooten und mich die Kundschaft erreichen kann.



Edit:

Habe nun wohl den Übeltäter gefunden:

[Mar 21 22:30:29] ERROR[3363] netsock2.c: getaddrinfo("meine.dyndns.org", "(null)", ...): Name or service not known
[Mar 21 22:30:29] NOTICE[3363] chan_sip.c: Warning: Re-lookup of 'meine.dyndns.org' failed!

Das wird auch nur 3x gemacht und ich schätze, dass es zu wenig ist, bis die dyndns aktualisiert wurde und sich das wohl überschneidet und erklären würde, warum es vorgestern mal ging und heute wieder nicht.

Was kann ich da nun machen?

 

[rostreich]

Habe nun die Lösung:

Der IPfire (und sicherlich einige andere Firewalls) halten die UDP Ports offen, weil der Asterisk bedingt durch den 'qualify=yes' dauernd Pakete sendet. Dadurch kommt kein UDP Timeout zustande und es wird nie ein Cache Flush ausgelöst.

Im IPFire Forum hatte einer den entscheidenden Hinweis zu conntrack gegeben. Habe dann auf der Konsole vom IPFire mal 'Conntrack -F' eingegeben und sofort waren meine Trunks wieder online ohne den Asterisk komplett neu zu starten. Man könnte dies natürlich in einen Cronjob packen, allerdings killt dieser Befehl sämtliche UDP-Verbindungen, was bei zusätzlichem VPN nicht so prickelnd ist. Die hoffentlich elegante Lösung ist qualifyfreq.

Meine Lösung war nun bei den Trunks noch den Wert 'qualifyfreq=300' einzugeben, damit genug Zeit bleibt, dass die alten Einträge auf IPFire einen Timeout bekommen.
Wird nur 'qualify=yes' genommen, wird alle 2 Sekunden ein Paket gesendet.

 

[xrated]

Qualify 2s ist aber nicht default sondern 60s. Wahrscheinlich eine Verwechslung mit qualify=2000 das nur festlegt das der Peer unresponsive ist wenn die Antwort nicht innerhalb 2s erfolgt.

 

[rostreich]

Mittlerweile habe ich eine feste IP und das Problem tritt seltenst noch auf, stört aber immer noch irgendwie.

Nur ein Neustart vom Asterisk bringts dann.

Zufriedenstellend ist echt anders....