[ERLEDIGT] Asterisk Troubleshooting

Hallo Alle,

ich nutze Asterisk seit Anfang des Jahres, nach 2 Monaten Testlaufes, produktiv, ich habe seitdem (wie bei jeder grösseren Umstellung) einige Fehler gemeldet bekommen und auch beseitigt, zweierlei kritische Problem halten sich leider immer noch.

Fehler 1 : MOH wird während eines Gespräches aktiv
Auftreten : selten
CLI : Ausgabe in der CLI ist leider unbekannt
Betroffene HW : SIP und ZAP über ISDN sowie VoIP (keine Eingrenzung)

Leider war es mir bisher immer vergönnt so etwas mal in Natura zu erleben.
Bemerkt sei hier das ich "madplay" als MOHPlayer nutze, was aber eigentlich keine Auswirkungen haben sollte.

[hier kommt die Lösung...]

EDIT - LÖSUNG :

DTMF Töne treten sporadisch in Gesprächen auf, man kann dieses Problem bei meiner genannten HW-konstellation leider nur minimieren, in dem man Asterisk nicht mehr die Werte tT mit auf den Weg gibt, jedoch endgültig gelöst ist das ganze nicht. (Stand 09/06)

[weiter im alten Thread...]

Fehler 2 : Gesprächspausen/abbrüche während eines Telefonates
Auftreten : häufig
CLI : Keine Ausgabe in der CLI
Betroffene HW : SIP/ZAP/mISDN (auf 2 x HFC)

Es treten während des Gespräches "Sprechpausen" auf die für beide Seiten gelten, zB hört man seinen Gegenüber nicht mehr und nach 3 Sekunden ist er wieder da als ob nichts gewesen wäre. VoIP sei mal aussen vor, diese Probleme treten auch bei ISDN verbundenen Gesprächen auf.

Ich habe lange Zeit gedacht das läge an dem Übergang zum VoIP Provider, was ich aber nun gänzlich ausschliessen kann da ich dieses Theather in den letzten zwei Tagen beobachten durfte und das Routing nur noch über ISDN ging.

[hier kommt die Lösung...]

EDIT - LÖSUNG : Die Aussetzer im Gespräch sind behoben, ein Breitschuss von sauberen Implementierungen haben dies geschafft.

Änderungen an den Telefonen : Alle meiner vier Allnet Telefon (7950) sind aussortiert, eins ist noch im Einsatz - aber sowieso nur sehr selten. Codec 711a ist der einzig akzeptierte Codec.

Änderungen am Netz : Wegbegleitendes QoS, angefangen an den SNOM Telefonen (ToS-Wert 184), weiter zu einem neuen managebaren Switch mit QoS Funktionalität (ToS und CoS sowie Port-Priorisierung) bis hin zum QoS Router welcher nach Portnummer priorisiert. Der weitere Weg ist leider nun einmal nicht beeinflussbar (Provider).

Änderungen am Hardware-Einsatz : Alle Fritz!Boxen sind rausgeflogen, stattdessen gibt es Linksys´s PAP2 - bessere Qualität , kein Theather mehr mit Standardkonformitäten.

[weiter im alten Thread...]

Es wäre schön wenn mir jemand raten würde wie er an die Fehlersuche herangehen würde, ich habe in der letzten Zeit nach Schwachstellen im Netz gesucht, wurde jedoch nicht fündig, auch das Ersetzen und des Routers und das Einführen von QoS mit TOS Bits und Prioritäten war zwar ein schöner Zeitvertreib, jedoch ist es nun gänzlich unwichtig geworden da mein Hauptfehler (2) ja auch über ISDN verbundene Gespräche auftritt.
Am stärksten treten Gesprächspausen bei gewählten Nummern auf, bei angenommenen eher geringfügig bis überhaupt nicht.

Meine Hardware besteht aus einem Asus 3Ghz PC mit 512 MB Ram, Digium Wildcard TDM40B (4x intern analog) und 2 x baugleichen HFC Karten.
Asterisk läuft auf Debian mit Kernel 2.6.8.

Asterisk,Zaptel und Addons sind in der Version 1.2.0.
mISDN (gehört in eine andere Kategorie) ist in der Version 0.2.1 .
Ein Netzwerkpinging ist ohne verlorene oder verzögerte Pakete durchgegangen, mein Netz ist ein Daten- und Sprachnetz, für Sprache wird tos 0x18 gesetzt und priorisiert, mein Hauptswitch ist ein Etentech 24 Port unmanaged Switch, der Router und der Server hängen an einem 4er Switch zusammen, die SIP Telefone sind an einem weiteren 4erSwitch in meiner Produktion verteilt.

Lohnt ein Update auf 1.2.5 für ein produktives System ?

Ich hoffe jemand von euch hat ggf. einen guten Rat.

Beste Grüsse,

Stefan

Erster Fund bzgl Fehler 2 - Sprechpausen.

Folgendes bekomme ich ausgespuckt wenn die Verbindungen abreissen, wenn der Fehler in der CLI auftaucht ist alles wieder vorüber :

Bei der Suche im LOG nach diesem Ereignis meldet er mir zahlreiche Ausgaben und dieser Fehler scheint auch schon in meinem Testsystem vorhanden gewesen zu sein, also von Anfang an.

Google spuckt einen BUG bei Digium für die Version 1.0.x im Queue.

Kann mir jemand helfen diesen Ansatz weiterzuverfolgen ?

Einen weiteren (den ich auch im mISDN Forums-Thread gestellt habe, der sich aber auf * bezieht) :

Mar 29 11:29:57 WARNING[2353]: chan_sip.c:11253 do_monitor: chan_sip: ast_sched_runq ran 26 all at once

Beste Grüße,

Stefan

Da hast Du aber ein Antiquariat (Thread) ausgebuddelt


Also :

Meine Probleme (s.o.) sind alle durchweg gelöst, jedoch ist das spezifisch auf mein System.

Was ich Dir empfehlen kann um die Probleme in den Griff zu bekommen bzw. den Kreis einzuengen :

a) Spezifiere das gesamte Szenario bitte detailreicher, teelfonierst Du ausschliesslich mit SIP oder auch IAX, ZAP, ISDN (Bri oder mISDN) - hängt eine Anlage mit dran, was ist mit Asterisk - ist "nur" Asterisk ohne weiteren Anlagen installiert?, wie ist Dein Netzwerk aufgebaut, was geschieht da so im Tagesgeschäft mit (Druckjobs-FTP-etcetc), welchen Provider hast Du, was für Telefone sind im Einsatz, hast Du ggf. Fastpath, wie siehts mit FW aus - was für ein Router etc etc etc, eine Signatur hilft immer sehr schnell die ganze Schose einzuengen.

b) Besorg Dir MTR - entweder auf Linux Basis (Debian ist es ein StdPaket) oder den WinMTR, besorg Dir die IP Deines VoIP Providers und pinge diesen mal eine Weile um herauszufinden ob es dort Störungen gibt

c) Pinge ebenfalls die Telefone um Leitungsprobleme auszuschalten (Intervall niedriger setzen)

d) Deaktiviere erst einmal QoS um vor falschen Fehlern in der Konfiguration geschützt zu sein

e) Checke Deine PortRanges, ich habe es hier mittlerweile so eingeführt das jeder Apparat seine eigenen 10 Ports hat (etwas übertrieben - aber Platz war genug, also..)

f) Vergiss den Initial Deadlock ersteinmal, es ist "nur" ein WARNING, Asterisk kennt viiiiiele Warnungen und ein Bruchteil ist relevant

etc etc etc

Schreib mal eine genaue Info über alles was so läuft bei Dir.

Dein Rechner sollte - wie Du selber erkannt hast - ausreichen, kein Problem.

Die Sirrix nutzt einen hauseigenen Channel soweit ich das auf deren Website erlesen konnte, ich habe mal etwas in Zusammenhang "viel ISDN" und Deadlocks gelesen, das ganze drehte sich da aber um eine TK Anlage die mit im Spiel war.

Also - ich muss ganz ehrlich sagen das Du viel Kram nutzt von dem ich nicht viel Ahnung habe - s.h. Sirrix, s.h. Suse (brr ).

Nun ist die Frage - was macht der Channeltreiber von Sirrix - bzw. was kann er, hast Du mal testweise einen SIP Account besorgt und den eingepflegt und fleissig lostelefoniert - mit mehr als einem apparat - wenns geht, kümmer dich um sirrix - wenn nicht - ist es hausgemacht - wäre so eine idee in meiner müden birne..

aufgepasst - natürlich musst du schauen ob der provider >1 Verbdg. zulässt..(PBX tut dies zB)

Grüsse, Strefan

Nun muss ich fragen auf welches Problem Du Dich beziehst, bei dem Sirrix Problem von oben kann ich nur sehr begrenzt helfen, das können andere hier wesentlich besser !

Bei auf meine HW & Anwendungen bezogenen Problemen kann ich natürlich helfen..

Grüsse, Stefan

Hi Foschi,

bei mir ist das Deadlock eher sekundär, "gelöst" kann man das nicht nennen, eher gefunden und als "nicht wichtig" befunden.

Bei mir ist es eine Nebenstelle die nach Geschäftsschluss keinen Strom mehr erhält, da der kluge Elektriker die Dosen an das Licht gekoppelt hat - und das ganze hinter eine VA Verkleidung gesetzt.

Generell müsste man differenzieren - bringt der Deadlock Probleme mit sich oder ist es eher die Tatsache das er überhaupt existiert

Ein Deadlock kann ja auch - wie in meinem Fall einfach nur heissen das Asterisk endlos versucht einen Peer zu connecten der "einfach verschwand".

@Foschi : "Von mISDN abraten" - differenzieren bitte !

mISDN ist immer noch eine experimentelle Umgebung - d.h. man kann nicht erwarten das man mISDN aufsetzt und keine Fehler erhält, jedoch kann man aber erwarten das man diese Fehler beheben kann.

Hier läuft mISDN produktiv, es ist zwar immer noch die unstable Version - ist allerdings fehlerlos seit ca. 3 Monaten im Einsatz, denn da gab es die letzte relevante Änderung - und auch der letzte "Fehler" war reine Einstellungssache (neuer Echocancler im Einsatz, EC-Wert zu niedrig).

Aber hier laufen wir offtopic.Schluss.


@Spelljammer

Sorry, ich hatte in meiner letzten Antwort den Faden nicht vernünftig aufgegriffen, da ich nicht so weit zurück gelesen hatte - natürlich habe ich das Problem als "gelöst" eingestuft - da es - wie oben geschrieben - nicht wirklich ein Problem darstellte und Asterisk mit diesem Deadlock anscheinend gut leben kann (erstes auftreten ist nun mehr als ein Jahr her)

Im alten Thread gaaaaanz oben habe ich mal die Problemlösung für die Fragen hinzueditieren.

Grüsse, Stefan

Hi KaMe,

puuh, ich muss sagen das dieser Thread wirklich alt ist ( > 1 Jahr mW)

Ich denke - mach lieber einen neuen Thread auf, der weckt dann auch mehr Interesse als meine damalige , eher allgemein gemeinte , Troubleshooting des Asterisk Beschreibung.

Wichtig hierbei ist das Du einen Debug der Gespräche machst, da das Problem ja reproduzierbar ist, wie Du es beschreibst.

Also nicht vergessen :

- * Version
- ggf Komponenten Version
- Snom FW Version der Anruferpartei sowie des Angerufenen Snoms
- Debug und Verbose der Asterisk CLI
- Sip debug der entsprechenden Stelle

Damit hast Du Hilfe im Handumdrehen.

Ich würde so vorgehen.

Wenn Du trotzdem hier den Thead fortführen möchtest, so melde Dich mit den o.g. Auszügen zurück und ich mache den Thread wieder auf.

Grüsse, Stefan