seltene Aussetzer

[tippo]

Hallo,
suche Rat.
Ich mach schon seit einigen Wochen am folgenden Problem rum und ich brings einfach nicht weg:
Wenn eine Verbindung zum ISDN besteht, kann es vorkommen dass ich den Gesprächspartner plötzlich für ca.2 sec. nicht höre. Umgekehrt auch. Danach ist alles ganz normal. Es komm rel. selten vor, vielleicht jedes 4. -5. Gespräch. Ab und zu hört man auch ein leichtes Knacken, ist aber nicht sehr störend und weniger ein Problem. Die Aussetzer allerdings schon.

Hab * (1.2.9.1) mit'ner AVM (passiv) 1Port auf'm P4 2,6GHz 1Gig RAM und Suse 9.3 laufen. Als Telefon hab ich drei Atcom AT-320 (PA168) mit neuester IAX2 Firmware 1.51.

Was hab ich nicht alles schon probiert:
ISDN Karte umgesteckt, USB disabled, alles disabled was nur ging, ACPI off, weil ich ein IRQ Problem / Performance vermutete- doch hat nichts gebracht.
Dann upgedatet von früher 1.2.1 bis auch die neueste *, chan_capi upgedated, an TOS rumgespielt, Phone Firmware upgedated - alles hat nichts gebracht. Hab auch keine Fehlermeldung oder Warnings wenn ich * starte, ich meine es ist sauber installiert.

Vieleicht habt ihr ne Idee oder habt so was schon mal wegbekommen.

Wo ich unsicher bin ist beim debuggen und auswerten um das Problem einzukreisen.
Wie geht man da am besten vor?

Für Tipps wäre ich echt dankbar.
Frank

 

[tippo]

jetzt isses weg

...und zwar macht offensichtlich die Authentifizierung bei XP Clients Probleme.
Diese sind am VoIP Telefon angeschlossen. Disabled man also am XP unter Netzwerkeinstellungen LAN Verbinding Authentifizierung die Option IEEE 802.1X dann ist alles OK. Dieses IEEE 802.1X ist übrigens per default bei Windows XP eingestellt.

Das sporadische Knacken habe ich allerdings immer noch.

 

[armincm]

Ich koennte mir vorstellen, dass der Rechner durch eine Aktion (Prozess, Festplattenaktivitaet) belastet ist und Asterisk hier nicht genug Rechenzeit bekommt.
Ich kann sowas sehr einfach reproduzieren, wenn man z.B. sehr viel kleine Daten sehr schnell auf ein ext3 (journaling)Filesystem ablegt.
Schau einfach mal nach, welche Prozesse so am laufen sind und was sie machen (top).

Armin

 

[tippo]

Hallo,
Danke für den Hinweis. Die CPUlast hatte ich auch schon verdächtigt, weil das in der *-Literatur auch so beschrieben ist. Die IRQ für die Fritzkarte hatte ich auch schon mal umgestellt.
Jedenfalls wenn ich top mitlaufen lasse, dann komme ich während eines 10 minütigen Gesprächs gerade mal auf max. 4% CPU im top, obwohl der * Rechner auch Gateway mit Firewall ist. Ich glaube nicht, dass der Festplattenkontroller die CPU-Zeit * wegfrisst.

Ich werde mal wieder am XP das IEEE 802.1 Authentifizierung einschalten und wenn's wieder Aussetzter gibt, dann liegts halt mal wieder an Onkel Bill

Frank

 

[pi4tel]

Jedenfalls wenn ich top mitlaufen lasse, dann komme ich während eines 10 minütigen Gesprächs gerade mal auf max. 4% CPU im top, obwohl der * Rechner auch Gateway mit Firewall ist. Ich glaube nicht, dass der Festplattenkontroller die CPU-Zeit * wegfrisst.

Eine Beobachtung mit Top ist allerdings auch etwas grob, da man kurze CPU Belastungen kaum mitbekommt.
Hat der Asterisk Prozess eine höhere Priorität als normale Prozesse? Falls nicht bereits vorhanden oder falls nicht die Asterisk Option "-p" genutzt wird, vor dem Start von Asterisk:

/usr/bin/renice -10 -p $$

Was für eine Platte ist es (IDE/SATA/SCSI) ? Auch wenn der Festplattencontroller nicht die CPU Zeit wegfrisst, kann er den Bus für kurze Zeit blockieren. Für ein Knacken sollte das reichen.

Stefan

 

[tippo]

Hallo,
Die Platte ist eine SATA, angeschlossen auf einem onboard SATA Controller. Das Motherboard ist ein Intel D865PERLK.

Ich hab die Priorität mit renice für den Asterisk Prozess auf -10 gesetzt. Mal sehen ob das knacken weg ist. Melde mich wieder.

 

[tippo]

...es knackst weiter in der Leitung Die Prio hochzusetzen hat nichts gebracht.

 

[tippo]

Rtt

Bei meiner Suche nach dem Fehler habe ich mal iax2 show netstat eingegeben:

-------- LOCAL --------------------- -------- REMOTE --------------------
Channel RTT Jit Del Lost % Drop OOO Kpkts Jit Del Lost % Drop OOO Kpkts
IAX2/302-5 -3560 -1 0 -1 -1 0 -1 39 0 0 0 0 0 0 0
1 active IAX channel


Dabei handelt es sich um ein Gespräch das von draußen über das ISDN / CAPI reinkommt und vom IAX2 Telefon (302) angenommen wurde.

Was mich ehrlich etwas wundert ist der negative und hoch RTT Wert von -3560.

Könnt ihr mir evtl. erklären ob der RTT Local so OK ist.
Was habt ihr so für Werte?

 

[pi4tel]

Bei meiner Suche nach dem Fehler habe ich mal iax2 show netstat eingegeben:

iax2 show netstats - mit s

-------- LOCAL --------------------- -------- REMOTE --------------------
Channel RTT Jit Del Lost % Drop OOO Kpkts Jit Del Lost % Drop OOO Kpkts
IAX2/302-5 -3560 -1 0 -1 -1 0 -1 39 0 0 0 0 0 0 0
....
Könnt ihr mir evtl. erklären ob der RTT Local so OK ist.

Eine Round Trip Time kann nicht negativ sein. Ebenso kann schlecht eine negative Anzahl von Paketen verlohrengehen. Doppelt empfangene müßten als Out Of Order gelisted werden (erscheint mir zumindest plausibel).

RTT "started" schon mal mit dem Wert 1000, was ein Dummy für noch nicht ermittelte Werte zu sein scheint. Ansonsten sind 50 ms bis 100 ms bei Telefonie über Internet realistisch.

Stefan

 

[tippo]

Danke für die Info.

Bin ein Stück weiter gekommen. Die negativen Werte sind weg und habe nun andere RTT Werte. Doch von vorne:

Die negativen RTT Werte kamen mir auch recht komisch vor. Der Grund war, dass in iax.conf "jitterbuffer=no" stand. Habe danach auf yes gestellt - und dann volles Caos.
Wenn ein Anruf per CAPi rein kam, gab es zuerst ein Warning im CLI dass resynct wurde.
WARNING[1264]: chan_iax2.c:695 jb_warning_output: Resyncing the jb. last....

Manchmal dauerte es dann bis 10 sec nach dem der Hörer am IAX Phone abgenommen wurde bis das Gespräch zustande kam. Ab und zu stand im * ERROR[1602]: chan_capi.c:1266 capi_write: No data....
Hab mich auf die Suche gemacht was das mit dem Rsync auf sich hat. Bin auf die PA168 Herstellerseite gelandet und hab gesehen dass es eine neuere Firmware(1.50.002) für IAX gibt.
Nach dem die neue Firmware auf dem IAX Phone war, hatte ich diese Werte:

-------- LOCAL --------------------- -------- REMOTE --------------------
Channel RTT Jit Del Lost % Drop OOO Kpkts Jit Del Lost % Drop OOO Kpkts
IAX2/302-2 60 1 77 0 0 1 0 19 0 0 0 0 0 0 0
1 active IAX channel

Hab zwar immer noch Jitter und einige verlorene Pakete, aber das sieht schon besser aus.
Das Knacken hab ich allerdings immer noch
Auch die Aussetzer, die ich glaubte mit disablen von IEEE Authentifikation wegbekommen zu haben, sind jetzt beim AT-320 wieder da :-( ...und nun sehe auch was im Asterisk CLI:

Jul 13 16:22:14 ERROR[1602]: chan_capi.c:1266 capi_write: No data for FRAME_VOICE CAPI/ISDN3/9730XXXX-2
Jul 13 16:22:15 WARNING[1264]: chan_iax2.c:695 jb_warning_output: Resyncing the jb. last_delay -95, this delay 2409, threshold 1002, new offset -25027

Der anschliessende netstats zeigte folgendes:

*CLI> iax2 show netstats
-------- LOCAL --------------------- -------- REMOTE --------------------
Channel RTT Jit Del Lost % Drop OOO Kpkts Jit Del Lost % Drop OOO Kpkts
IAX2/302-2 2494 1 72 20 0 7 0 90 0 0 0 0 0 0 0
1 active IAX channel

Komischerweise ist das RTT wieder auf über 2000 hochgeschnellt

Vielleicht bekommt man das nich mit Feintuning hin. Vorschläge gerne.

 

[tippo]

scheint wohl ein PA168 Problem zu sein

Hatte mal wieder Zeit mich mit diesem Problem zu beschäftigen und nach einiger Zeit googlen hab ich im Yahoo Forum für PA168 Chip das ja in dem Atcom AT-320 verbaut ist, Hinweise gefunden.
http://groups.yahoo.com/group/pa1688/message/5235

Nach dem Stand dort, bin ich nicht der einzige der mal Ausetzer im Gespräch von 1-3 sec. hat. Auch das Knacken oder "Click" liegt am PA168 bzw. dessen Firmware. Die neue1.53 Version hat übrigens nichts gebracht und ich habe beide, sowohl mit der IAX2 wie auch SIP Firmware, getestet.
Also, den PA168 Spezialisten ist das Problem bekannt und somit bleibt nur auf die nächste Firmware zu warten. :-Ö
Für diverse Einstellungen die das Problem entschärfen bin ich trotzdem dankbar.
Frank

 

[vWalter]

Hi,

ich habe auch hin und wieder Meldungen dieser Art :

Aug 12 12:48:15 WARNING[4772]: chan_iax2.c:698 jb_warning_output: Resyncing the jb. last_delay 0, this delay -14390, threshold 1000, new offset 14390

- Das tritt immer dann auf, wenn zuviel Traffic auf der Netzleitung ist.



Gruss
Walter

 

[tippo]

...normalerweise haste recht wenn man über z.B DSL raus geht und gerade jemand etwas downloaded etc.
Doch bei mir sind die drei AT-320 über einen Gigabit-Switch mit dem Asterisk Server verbunden.
Meine Vermutung ist dass manchmal die UDP Pakete nicht in der richtigen Reihenfolge am AT-320 oder am Asterisk ankommen, der RTT Wert dann negativ wird und es dann zu einem resync kommt.