Asterisk 1.4: Probleme Anmeldung Sipgate nach 24h Disconnect powered by T-Online :-)

MeTRiX

Neuer User
Mitglied seit
3 Feb 2009
Beiträge
55
Punkte für Reaktionen
0
Punkte
0
Hallo zusammen,

ich habe in den letzten Tagen schon einiges rumgesucht aber bin bisher nicht zum Erfolg gekommen. Ich habe das Problem, dass nach dem 24h Disconnect der Telekom (und damit neue IP) sich mein Asterisk nicht mehr richtig bei Sipgate anmeldet.

Unter "sip show registry" bleibt er dann bei "Request sent" hängen und bekommt einen Timeout. Erst wenn ich Asterisk mal für 5 Minuten beende und neu starte bekomme ich eine Verbindung. Denke mal ich werde von Sipgate geblockt wegen "falscher" Anmeldungen?!?!

Ich habe schon gelesen, dass im SIP-Header die externe IP steht und das dies vermutlich zu den Problemen führt (mein Asterisk steht hinter einem NAT).

Ich habe daraufhin folgende Parameter in meine sip.conf aufgenommen:
externhost=meinDynDNSName
externrefresh=10
localnet=10.0.0.0/8

Leider funktioniert dies noch immer nicht. Im Moment ist mein Workaround, dass ich meinen 24h Disconnect manuell über einen Cronjob steuere und eine Minute vorher Asterisk beende und eine Minute später neu starte. Das geht, hilft aber nicht sollte die Leitung mal zu einem anderen Zeitpunkt fliegen.

Ich bin im Moment etwas ratlos :-(
 
Hallo MeTRiX,

ich hatte das gleiche Problem früher schon mit 1.2, und jetzt auch teilweise mit 1.6. Allerdings passiert das bei mir nur alle paar Tage, teilweise auch zwei Wochen lang nicht. Meistens hilft ein sip reload, damit die Registrierung bei sipgate wieder klappt. Manchmal kracht Asterisk dabei aber dann endgültig zusammen. Mein Workaround besteht aus einem Cronjob, der die /var/log/asterisk/messages nach aktuellen Registrierungsfehlern durchsucht. Hier ist noch eine andere Möglichkeit beschrieben, leider funktioniert der Download nicht mehr.

Rentier
 
hmm, danke für die Antwort.

Das klingt aber alles nicht so richtig toll. Ein Update auf 1.6 lohnt scheinbar auch nicht wenn ich dich richtig verstehe?!?

Macht es sinn irgendeinen SIP-Proxy zu installieren und dann Asterisk den Proxy connecten zu lassen?!?


danke + gruß
metrix
 
* dezentes nach-oben-schieb *

Bei mir war's heute Nacht mal wieder so weit, dass die Sipgate Registrierungen weg waren ("Request Sent").

Nach dem letzten IP-Wechsel-Registrierungsfehler hatte ich registerattempts raus genommen. Das hat dazu geführt, dass ein sip reload heute auch nichts mehr gebracht hat, sondern ich musste Asterisk stoppen.

Hat denn niemand zumindest eine Idee, was da passieren könnte?

Rentier
 
Router-Problem

Hi,

bin gerade über diesen Eintrag gestolpert, da ich ein ähnliches Problem habe. Bei mir hilt dann immer eine Reset der States in PfSense (Router) und plötzlich gingen die Register wieder.
Habe eben mal den pfsense auf das 1.2.3 Release upgedates und das Packet fit123 hinzuinstalliert - das soll das angeblich automatisch machen - mal sehen....
Vielleicht könnt ihr mal schauen ob bei euch auch ein Router Restart helfen kann ohne den Asterisk anzufassen - dann wüßten wir, ob Asterisk das Problem macht oder der Router.

Um das ganze aber besser zu Monitoren, suche ich eigentlich ein Skirpt oder so was, dass mir im Falle nicht registrierter SIP peers eine Mail schickt - kennt jemand sowas?

Grüße
 
Hallo,

das SuSE, auf dem mein Asterisk läuft, hängt direkt am DSL und fungiert gleichzeitig als Router. Da ist sonst nichts mehr dazwischen, was ich resetten könnte.

Ich trenne per crontab um 3:00 die Verbindung (ifdown dsl0), um den IP-Zwangswechsel (danke T-Com) in die Nacht zu verlegen. Wenn dann treten die Probleme direkt danach auf. Eine viertel Stunde später läuft deshalb das hier:

PHP:
<?php
ob_start();
passthru("/usr/sbin/asterisk -rx 'sip show registry'");
$r=ob_get_contents();
ob_end_clean();

$a = explode("\n",$r);

foreach ($a AS $k => $v) {
    if (!preg_match("/sipgate/i",$v)) continue;
    if (!preg_match("/registered/i",$v)) {
        system("/usr/sbin/asterisk -rx 'sip reload'");
        break;
    }
}

?>

Vielleicht kannst Du was damit anfangen.

Rentier
 
Hallo Leute,

ich hatte ebenfalls das Problem, dass nach einem IP Wechsel keine neue Registrierung bei Sipgate mehr moeglich war -> wegen Timeouts bei der Registrierung.

Ich habe mir das Ganze mal mit tcpdump auf meinem Firewall angeschaut. Und tatsaechlich:

Es liegt daran, dass iptables z.T. noch alte IP Adressen im '/proc/net/ip_conntrack' gespeichert hat. Im Source NATing wird folglich noch die alte IP eingetragen, weswegen die Antworten von
Sipgate auf die Registrierung natuerlich nie ankommen.

Per default bekommt iptables vom IP Wechsel gar nichts mit. Das ist manchmal sogar gewuenschtes Verhalten, da nach Interface-down nicht
notwendigerweise ueberall eine neue IP vergeben wird. Deswegen loesche ich nach IP Wechsel immer explizit mit

Code:
conntrack -F
alle Ueberreste meiner alten IP im Connection Tracking => hat das Problem fuer mich geloest. Kein Asterisk Restart (mit vorheriger 3min Wartezeit) mehr noetig.

Der Workaround oben
Asterisk mal für 5 Minuten beende
tut im Endeffekt dasselbe. Nach 3 Minuten Timeout (*NUR* falls in der Zwischenzeit keine neuen Verbindungsversuche stattfinden) werden die alten Eintraege ebenfalls aus der 'ip_conntrack'' geloescht.

- sparkie
 
Zuletzt bearbeitet:
Liegt am NAT

Ihr müsst die entsprechenden Einträge aus der NAT Tabelle löschen, am besten beim Abbauen der PPP Vebindung:

Code:
conntrack -F

löscht die ganze NAT Tabelle, ihr könnt aber auch gezielt die SIP-Einträge löschen.
 
Bei mir gibt's selbst als root kein conntrack ("command not found"). :noidea:
whereis conntrack bringt auch nichts und in den RPMs hab ich auch nichts passendes gefunden. SuSE 10.2

Svenja
 
löscht die ganze NAT Tabelle, ihr könnt aber auch gezielt die SIP-Einträge löschen.

danke! Ist klar, aber so genau geht's bei mir nicht. Ich habe noch keine unerwuenschten Verbindungsabbrueche (interner Verbindungen) dabei festgestellt.

- sparkie
 
Bei mir gibt's selbst als root kein conntrack ("command not found").

hast du verfizieren koennen, dass mit der alten IP ge'source'NAT'ed wird?
Dann hast du tatsaechlich das gleiche Problem.

Ich verwende hier debian squeeze, da sind die Tools installierbar. Ansonsten hilft wahrscheinlich nur selber compilieren:
http://conntrack-tools.netfilter.org/

eigentlich macht das Tool nur nen:
Code:
                cth = nfct_open(CONNTRACK, 0);
                if (!cth)
                        exit_error(OTHER_PROBLEM, "Can't open handler");
                res = nfct_query(cth, NFCT_Q_FLUSH, &family);
                nfct_close(cth);

ich weiss nicht wie man die EIntraege anders geflush't bekommt.

- sparkie
 
Das Problem ist, dass Asterisk ja alle paar Sekunden sip Pakete verschickt. Daher werden die NAT Einträge nie gelöscht, auch nicht, wenn der Rechner längst eine neue IP bekommen hat, denn es wird immer die falsche source IP genattet.

Da hilft nur, die sip einträge aus der conntrack-Tabelle zu löschen, und "conntrack" ist genau das userland tool dazu.

Am besten packt man das in ein ip-up skript. Das Tool sollte es auch für Suse geben. Man kann auch /proc/net/ip_conntrack direkt manipulieren, aber das ist nicht unbedingt ratsam.
 
Durch sparkies Hinweis (hier) bin ich auf diesen Beitrag aufmerksam geworden. Zum Thema ein paar Infos/Gedanken.
Bis vor einigen Monaten habe ich ebenfalls conntrack verwendet. Ich hatte genau das beschriebene Problem, dass die sip states nichts von der neuen WAN-IP mitbekommen und nie gelöscht wurden. Für conntrack habe ich keine zufriedenstellende Lösung gefunden. Daher habe ich auf PF packet filter umgestellt. Hier gibt es Laufzeitoptionen (z.B. set timeout interval x) die es erlauben, states alle x Sekunden zu löschen. Meine Asterisk defaultexpiry beträgt beispielsweise 600 Sekunden abzüglich 15 Sekunden und 5 Sekunden Sicherheit werden meine sip states alle 580 Sekunden gelöscht. Seither keinerlei Probleme mehr beim IP-Wechsel. Aus Bequemlichkeit verwende ich nun pfSense.
Vielleicht hilft das dem Einen oder Anderen.
 
Und wo stellt man die Laufzeitoptionen ein???????
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.