Gelöst: Sipura hinter NAT + Zwangstrennung (ohne Routereingriff!)

Lösung siehe mein 2. Posting hier!

Hallo,
schon seit langer Zeit versuche ich das Problem einen SPA zuverlässig hinter einem NAT-Router zu betreiben in den Griff zu bekommen. Die 24-Stunden Zwangstrennung sorgt jedoch zuverlässig für Probleme, so dass nach einer Trennung immer die Registrierung des einen oder anderen Accounts auf meinem SPA-3000 dauerhaft fehlschlägt (Registration State: Failed).

Als Router benutze ich eine ältere Version von IPCop und habe schon sämtliche Prozeduren ausprobiert, die NAT-Mapping-Tabelle bei einer Zwangstrennung zu löschen. Unter anderem habe ich folgendes Skript gebaut, welches bei einem Verbindungsauf- und abbau aufgerufen wird:


Obwohl das Skript ausgeführt wird, stehen in der NAT-Tabelle (cat /proc/net/ipcontrack) alte UDP-IP-Mappings. Es bleibt also unzuverlässig...

ABER:
Letztens bin ich über den Eintrag Reg Retry Intvl gestolpert, meine Idee war es nun, diesen Eintrag auf einen Wert größer als in ip_conntrack_udp_timeout_stream zu stellen: Dadurch sollte das Problem ganz ohne Eingriffe in den Router zu lösen sein, denn wenn die Registrierung fehlschlägt, würde der SPA einfach einige Minuten mit dem nächsten Registrierungsversuch warten. In dieser Zeit wird auch bei älteren Routern das Tracking gelöscht...
Aber Pustekuchen: Obwohl nun die Re-registrierung verzögert wird, sendet dieser doofe SPA weiterhin die ja sonst benötigten Keep-Alive-Messages, womit mein schöner Traum von einem Problemlosen Betrieb hinter einem NAT-Router ohne Portforwardings zerplatzt. Würde die Firmware so schlau sein und diese Keep-Alive-Messages auch nicht senden, wäre die 24-Stunden-Trennung sicher viel unproblematischer bei vielen Router-Nutzern...

Habe ich eine Einstellungsmöglichkeit übersehen oder wäre das vielleicht wirklich mal ein wichtiger Verbessungsvorschlag für die Firmware der Sipuras?

Gruß Lutz

Lösungsmöglichkeit gefunden!

Hallo,
mittlerweile ist mir selbst eine Lösungsmöglichkeit in den Sinn gekommen, die ich im moment ausprobiere, vielleicht können andere Benutzer diese mal testen und ihre Erfahrungen dazu hier posten. Mein Lösungsansatz besteht darin, die nötigen NAT-Keepalive-Messages nicht durch das dafür vorgesehende System im SPA erzeugen zu lassen, was übrigens oft zu "falschen Fehlern" in der Syslog führt, wenn SIP-Server dieses NOTIFY-Kommando nicht kennen, sondern durch etwas regelmäßigere Registrierungsvorgänge. Die Registrierungsvorgänge halten nämlich den Port ebenso offen, so dass bei einem genügend kleinem Intervall das Keep-Alive vom SPA überflüssig wird. Hier mal ein "Rezept" von mir zur vorgehensweise.

Zuverlässiger Betrieb eines SIPURAS hinter NAT-Router trotz Zwangstrennungs-Problematik
1. Schritt: Herausfinden, wie lange UDP-Mappings in der NAT-Tabelle gespeichert werden. Dazu entweder auf Erfahrungswerte zurückgreifen oder im Linux-Router diesen Wert abrufen als root mit folgendem Kommando (klappt aber nur wenn netfilter im Einsatz ist):
Dies ergibt bei meinem IPCOP 1.4.6 den Wert 180, also nach 180 Sekunden inaktivität auf dem UDP-Port wird dieser aus der Tabelle verworfen und kann mit neuer IP-Adresse aufgenommen werden. Also, um das Mapping aufrecht zu erhalten, damit der SPA angerufen werden kann, muss in Abständen von unter 180 Sek. auf diesen Port etwas passieren. Im Fehlerfall, also bei falscher IP durch die Zwangstrennung muss für eine Zeitspanne von mind. 180 Sek. absolute Funkstille auf diesem Port herschen.

2. Schritt: Im SPA unter "SIP" - "SIP Timer Values (sec)" muss für die Parameter "Reg Retry Intvl:" und "Reg Retry Long Intvl:" ein Wert eingetragen werden, der ein etwas (etwa 10%) größer ist als der udp-timeout, also im vorliegenden Fall nutze ich z.B. 300.
Unter "NAT Support Parameters" sollten die Einstellungen so sein, als wenn man NAT benutzt (was ja weiterhin der Fall sein soll), also das meiste auf "YES" sowie ein gültiger STUN-Server.
Der Parameter "NAT Keep Alive Intvl:" spielt dabei keine Rolle, da der Trick ja genau darin besteht, dieses nicht zu nutzen. Falls Sipura mit einem Firmwareupdate reagiert und bei fehlerhaften Registrierungen auch die Keep-Alive-Nachrichten unterdrückt, wird man diesen Wert wieder nutzen können. Hier sollte ein Wert eingetragen werden, der etwas kleiner ist als der udp-Timeout, im vorliegenden Fall nutze ich hier 25.

3. Schritt: In den entsprechenden Line-Settings unter "Line 1" bzw. "PSTN Line" nun unter "NAT Settings" zwar "NAT Mapping Enable:" auf "YES" belassen , aber die Keep-Alive-Nachrichten deaktivieren, in dem "NAT Keep Alive Enable:" auf "NO" gesetzt wird. Die Einstellungen für "NAT Keep Alive Msg:" und "NAT Keep Alive Dest:" bleiben auf den Defaultwerten.
Damit bei erfolgreicher Registrierung die NAT-Tabelle erhalten bleibt, wird nun der Registrierungsintervall auf einen Wert eingestellt, der kleiner als das UDP-Timeout ist. Dazu unter "Proxy and Registration" die Parameter "Register Expires:" und "Proxy Fallback Intvl:" entsprechend belegen. In meinem Fall habe ich 120 eingetragen. Damit erfolgt alle 120 Sekunden eine erneute Registrierung, was auch dafür sorgt, das der Eintrag in der NAT-Tabelle weiterhin gültig bleibt.

Mit diesen Einstellungen sollte es möglich sein, ohne Veränderungen am Router und ohne Portweiterleitungen den SPA hinter einem Router zu betreiben. Bei einer Zwangstrennung dauert es dann etwa "Reg Retry Intvl:" + "Register Expires:" Sekunden, bis der SPA wieder eine neue erfolgreiche Registrierung hat.

Bitte eure Erfahrungen und auch eure UDP-Timeout-Werte hier mal posten.

Gruß Lutz

Update:
Mittlerweile habe ich diese Lösung einige Zeit getestet und die Zwangstrennung hat keine größeren Probleme mehr bereitet, daher deklariere ich es als eine Lösung.

Das wäre logisch, wenn dein Asterik-Server im lokalen Netz ist und QSC im Internet. Die Problematik taucht nur auf, wenn der SPA über einen NAT-Router "nach draussen" telefoniert, im lokalen Netz gibts normalerweise weder NAT noch entsprechende NAT-Tabellen...

Nein, es läuft ja alles über den selben Port. Für den Verbindungsaufbau als auch zur Anrufsignalisierung ist der Port zuständig, der auch zur Registrierung verwendet wird.

Richtig. Und daher wird das Registrierungsintervall ja kürzer eingestellt, als die Gültigkeitsdauer der NAT-Mappings.
Was ich bisher noch nicht erwähnt habe, ist das es bei einer neuen Registrierung wärend eines Telefonates ein leichtes Knacksen hören kann, was man vermutlich nur bemerkt, wenn man den Countdown unter "Next Registration In:" beim Telefonieren im Auge behält.