Asterisk 1.6 hängt bei SIP-Verbindungen

[Kermit23]

Puh, ich habe ein schwer zu beschreibenden Fehler:
Ich habe nun von 1.4 auf 1.6.2.0-1 upgedatet und habe ein seltsames Problem mit SIP-Verbindungen: Wenn ich Asterisk gerade frisch starte klappt erst mal alles einwandfrei. Wenn ich dann mehrere Stunden nichts tue (kein Anruf rein und raus) und auch nur intern mit einem SIP-Telefon das andere anrufe oder gar nur eine Demoansage anrufe, so höre ich alles nur einige Sekunden bruchstückhaft/abgehackt bis es ganz verstummt und das SIP-Telefon die Verbindung abbricht (mit 2 verschiedenen SIP-Telefonen getestet). Mein Server ist dann für einige Minuten nichts zu erreichen - offenbar blockiert Asterisk total! Ich habe mal ein "top" mit nice -20 parallel laufen lassen. Bei der Anzeigen-Aktualisierung von top konnte ich sehen, wie die CPU-Last vom Asterisk-Prozess auf 85% gestiegen ist und dann war es vorbei (top-Anzeige / ssh-Verbindung eingefroren).

Wenn der Server sich wieder beruhigt hat nach 1-5Minuten (geht schlagartig), läuft wieder alles (auch SIP-Telefonate!) einwandfrei. Nach einigen Stunden Ruhe zickt Asterisk wieder so rum. Habe auch keine Fehlermeldung im Syslog und keine ungewöhnliche auf der Asterisk-Cli. Auch eine sip debug zeigt nichts ungewöhnliches an. Es bleibt einfach nur hängen!

Hat jemand eine Idee, was das sein könnte, bzw. ist so ein Fehler bekannt, der durch irgendeine Einstellung ausgelöst wird? Vorher lief Asterisk 1.4 mit misdn + sip einwandfrei. Jetzt habe ich eine frische 1.6er ohne chan_misdn und frische nur minimal angepasste sample Config-Files und dann solche Probleme.


NACHTRAG: Kann es sein, dass ich zwingend so einen dahdi_dummy modul brauche? Mir ist nun aufgefallen, dass unmittelbar nach einem SIP-Verbindungsaufbau das Gespräch in der 1.-2. Sekunde immer abgehackt ist, bis es funktioniert. Werde auch mal probieren diesen Jitter-Buffer einzuschalten...

NACHTRAG2: So, dahdi_dummy läuft und meetme() geht auch (vorher stand, dass das pseudo-device fehlt). Die SIP-Probleme bestehen aber immer noch. Werde also noch mal mit den SIP einstellungen spielen.

 

[VoIP_Indianer]

Ich habe nun von 1.4 auf 1.6.2.0-1 upgedatet

Was ist das für eine Version? Aus irgendeinem Binary oder aus den Sourcen selbst kompiliert?

 

[Kermit23]

debian binary. Um mir das selbst kompilieren zukünftig zu sparen, habe ich gerade alle ISDN-Geräte rausgeschmissen.

NACHTRAG: Offenbar hat die Länge der Ruhepause zwischen zwei aktiven SIP-Verbindung etwas mit der Länge der Blockade zu tun. Als ob Asterisk irgendwie die verstrichene Zeit mit voller CPU-Last "nacharbeiten" müsste?

 

[Kermit23]

So, nach ein paar Rückfrage/Transfer Timeout-Tests (atxfer) zwischen SIP und MGCP-Telefonen ist wieder so ein krasser Hänger aufgetreten, der eine halbe Minute meinen kompletten Server blockiert hat (keine Reaktion mehr, nicht mal auf ping). Diesmal kam der Fehler aber abrupt und es kam eine ziemlich eigentümliche Fehlermeldung. Ich dachte erst, dass das ein Scherz ist:

[Jan 16 20:22:51] WARNING[23228] channel.c: Unexpected control subclass '-1'
[Jan 16 20:23:00] NOTICE[23235] rtp.c: Comfort noise support incomplete in Asterisk (RFC 3389). Please turn off on client if possible. Client IP: 192.168.16.36
[Jan 16 20:24:00] NOTICE[23225] chan_sip.c: Peer 'gmx' is now UNREACHABLE! Last qualify: 46
[Jan 16 20:24:00] NOTICE[23225] chan_sip.c: Peer 'sipgate' is now UNREACHABLE! Last qualify: 52
[Jan 16 20:24:06] NOTICE[23235] features.c: We exceeded our AT-timeout
[Jan 16 20:24:06] NOTICE[23235] features.c: We're trying to call MGCP/aaln/[email protected]
[Jan 16 20:24:06] NOTICE[23235] features.c: Unable to request channel MGCP/aaln/[email protected]
[Jan 16 20:24:24] WARNING[23217] asterisk.c: The canary is no more. He has ceased to be! He's expired and gone to meet his maker! He's a stiff! Bereft of life, he rests in peace. His metabolic processes are now history! He's off the twig! He's kicked the bucket. He's shuffled off his mortal coil, run down the curtain, and joined the bleeding choir invisible!! THIS is an EX-CANARY. (Reducing priority)
[Jan 16 20:25:06] NOTICE[23235] features.c: We exceeded our AT-timeout
[Jan 16 20:25:06] NOTICE[23225] chan_sip.c: Peer 'gmx' is now Reachable. (97ms / 2000ms)
[Jan 16 20:25:06] NOTICE[23225] chan_sip.c: Peer 'sipgate' is now Reachable. (96ms / 2000ms)
[Jan 16 20:25:07] NOTICE[23235] features.c: Unable to request channel MGCP/aaln/[email protected]

Siehe die Warnung um 20:24:24. Bekloppte Entwickler! Ich sehe schon: Produktiv ist Asterisk 1.6 wohl noch nicht einsetzbar.


Habe nun auch einen entsprechenden debian bug-report gefunden:

When Asterisk runs in real-time scheduling priority (-p, the default in Debian), it may not be so nice if it gets into a 100% CPU loop. Thus as
of Asterisk 1.6.0 there is a separate Asterisk Canary" child process that runs at a normal priorty [..]
For most Lenny and above systems this feature is not really needed
anyway, because as of kernel 2.6.25, the "real-time scheduling priority"
will not resort to taking only 95% CPU time after a while.

Diese extremen Hänger habe ich also auch, da ich noch Kernel 2.6.19 einsetze! Wie kann ich denn generell Asterisk von einer real-time sceduling priority in eine "normale" bringen? Meine 1.4er waren auf Grund von mISDN immer selbst gebaut und die liefen dann wahrscheinlich nicht mit real-time priority. Mein Server ist "nur" ein Pentium3 500MHz. Aber trotzdem sollte das doch eigentlich für 3 IP-Telefone reichen?

NACHTRAG: Ok, hab's gefunden: In der /etc/init.d/asterisk kann kann ich über die Variable AST_REALTIME="yes" die Priorität steuern.

NACHTRAG2: Fehler behoben! Nachdem Asterisk jetzt nicht mehr im Real-Time Mode läuft, funktioniert auch nach mehreren Stunden standby der erste SIP-Ruf problemlos! Allerdings kann ich nicht 100% sagen, ob es daran lag: Habe auch alle Module, die ich nicht brauche entladen.

 

[gboelter]

Abenteuerliche Geschichte, auch wenn's ja jetzt funktioniert.

Spontan wuerden mir da so zwei Dinge einfallen:

1. Wenn man als Programmierer nicht aufpasst, dann verliert man - warum auch immer - schon mal nach einer gewissen Zeit die Verbindung zum MySQL-Server. Und natuerlich dauert es einen Moment, die dann wieder aufzubauen. Das kann bei so'm ollen Pentium schon mal ein wenig CPU kosten.

2. Kann es auch sein, dass auf dem Asterisk so eine 'dumme' Stromsparfunktion aktiv ist, also Festplatte abschalten nach 60 Minuten oder etwas in der Art?

Wie gesagt, nur so ein spontaner Gedanke.

Hier laeuft uebrigens die 1..6.2.0 ohne Probleme, allerdings auch ohne MySQL ...

 

[Kermit23]

Hallo,
nein, ich nutze keine Stromsparfunktionen (Platte schaltet niemals ab.). Und selbst wenn, dann dürfte das hochfahren der Platte ja keine 30 Sekunden und mehr dauern.
Und meines Wissens nutze ich, bzw. die Standardinstallation aus dem debian repository, auch keinen mysql Server. Jedenfalls läuft kein entsprechender Prozess!
Seitdem ich realtime abgeschaltet habe, hatte ich bis jetzt tatsächlich keine Probleme mehr! Ich habe auch nur noch einen Asterisk-Prozess (wenn realtime ein ist, gibt es tatsächlich noch ein "astcanary"-Prozess!)

 

[blauerpeti]

Bekloppte Entwickler!

Du solltest Dir mal überlegen was du sagst. Oder kannst du etwas zur Entwicklung von OpenSource beitragen. Ausser Meckern natürlich..

 

[Kermit23]

Jetzt bleib mal auf dem Teppich! Ich habe schon einige Software unter GPL veröffentlicht und auch an vielen Projekten mitgewirkt (und wenn auch nur als Tester). Aber so eine bescheuerte Fehlermeldung wie "The canary is no more. He has ceased to be! He's expired and gone to meet his maker! He's a stiff! Bereft of life, he rests in peace. His metabolic processes are now history! He's off the twig! He's kicked the bucket. He's shuffled off his mortal coil, run down the curtain, and joined the bleeding choir invisible!! THIS is an EX-CANARY. (Reducing priority)" ist mir noch nie untergekommen!

 

[foschi]

Monty Python halt Die Entwickler würden sagen, dass Du keinen Humor hast und das Leben zu ernst nimmst ;-)