ISDN ausgehend bricht ab

[jaw]

Also erst mal die Rahmenbedingungen:
Eine ISDN Anlage hängt mit dem externen S0 Bus an der HFC-Karte, und telefoniert über den Asterisk (1.4.21.1-BRIstuffed-0.4.0-RC3b unter Debian Stable) per VoIP raus. Das ganze lief schon mal völlig ohne Probleme. Verkabelung ist also in Ordnung.

Jetzt hab ich leider das Problem, dass ausgehende Anrufe von der ISDN Anlage kurze Zeit nach der Dial Applikation abgebrochen werden. Meist hört man noch das erste Freizeichen, dann bricht die Verbindung ab.
Rufe ich dagegen über die ISDN Anlage die Voicebox des Asterisks an, bleibt die Verbindung bestehen, und ich kann ganz normal die Box abhören. Eingehende Anrufe vom Asterisk in die Anlage gehen auch problemlos ohne Abbruch.

Leider hab ich momentan grade gar keine Idee, wo ich mit der Suche anfangen soll - und gesucht hab ich schon 'ne Menge, leider ohne Erfolg.

Die HFC hat einen eigenen Interrupt für sich alleine.

cat /proc/zaptel/1:
Span 1: ZTHFC1 "HFC-S PCI A ISDN card 0 [NT] layer 1 ACTIVATED (G3)" (MASTER) AMI/CCS

1 ZTHFC1/0/1 Clear (In use)
2 ZTHFC1/0/2 Clear (In use)
3 ZTHFC1/0/3 HDLCFCS (In use)

Auffällig ist dabei, dass der ISDN Link down geht, und danach wieder up - an statt up zu bleiben.

Ich kann leider nicht genau sagen, seit wann das Problem auftritt. Es könnte mit einer FC2 zusammen hängen, die später rein kam und über CAPI betrieben wird.

Wie kann ich auch ausgehende Verbindungen wieder ermöglichen?

Das Debug Log sagt dazu folgendes:

-- Called xxxx@provider
1 -- T200 counter expired, What to do...
1 -- Timeout occured, restarting PRI
1 q921.c:840 t200_expire: q921_state now is Q921_LINK_CONNECTION_RELEASED
1 Sending TEI remove tei=64
1
> [ fe ff 03 0f 7d 4a 06 81 ]
1
> Unnumbered frame:
1 > SAPI: 63  C/R: 1 EA: 0
>  TEI: 127        EA: 1
1 >   M3: 0   P/F: 0 M2: 0 11: 3  [ UI (unnumbered information) ]
> 5 bytes of data
== Primary D-Channel on span 1 down
== Primary D-Channel on span 1 down for TEI 64
[Jul 14 13:06:33] WARNING[768]: chan_zap.c:2510 pri_find_dchan: No D-channels available!  Using Primary channel 3 as D-channel anyway!
1 NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Active, peerstate Active
1 q931.c:3492 q931_disconnect: call 1 on channel 2 enters state 11 (Disconnect Request)
1
> [ 02 81 00 00 08 01 81 45 08 02 81 90 ]
1
> Informational frame:
1 > SAPI: 00  C/R: 1 EA: 0
>  TEI: 064        EA: 1
1 > N(S): 000   0: 0
> N(R): 000   P: 0
> 8 bytes of data
1 Starting T_200 timer
1 > Protocol Discriminator: Q.931 (8)  len=8
1 > Call Ref: len= 1 (reference 129/0x81) (Terminator)
1 > Message type: DISCONNECT (69)
1 > [08 02 81 90]
1 > Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0  Location: Private network serving the local user (1)
1 >                  Ext: 1  Cause: Normal Clearing (16), class = Normal Event (1) ]
1 NEW_HANGUP DEBUG: Destroying the call, ourstate Disconnect Request, peerstate Disconnect Indication
== Spawn extension (to-provider, xxxxx, 7) exited non-zero on 'Zap/2-1'
-- Executing [h@to-provider:1] Playback("Zap/2-1", "vm-goodbye") in new stack
[Jul 14 13:06:33] WARNING[9302]: file.c:677 ast_readaudio_callback: Failed to write frame
-- <Zap/2-1> Playing 'vm-goodbye' (language 'de')
[Jul 14 13:06:33] WARNING[9302]: app_playback.c:439 playback_exec: ast_streamfile failed on Zap/2-1 for vm-goodbye
1
< [ fc ff 03 0f 17 89 01 ff ]
1
< Unnumbered frame:
1 < SAPI: 63  C/R: 0 EA: 0
<  TEI: 127        EA: 1
1 <   M3: 0   P/F: 0 M2: 0 11: 3  [ UI (unnumbered information) ]
< 5 bytes of data
1 Sending TEI assign ri=6025 tei=64
1
> [ fe ff 03 0f 17 89 02 81 ]
1
> Unnumbered frame:
1 > SAPI: 63  C/R: 1 EA: 0
>  TEI: 127        EA: 1
1 >   M3: 0   P/F: 0 M2: 0 11: 3  [ UI (unnumbered information) ]
> 5 bytes of data
-- Executing [h@to-provider:2] Hangup("Zap/2-1", "") in new stack
== Spawn extension (to-provider, h, 2) exited non-zero on 'Zap/2-1'
1 uter*CLI>
< [ 00 81 7f ]
1
< Unnumbered frame:
1 < SAPI: 00  C/R: 0 EA: 0
<  TEI: 064        EA: 1
1 <   M3: 3   P/F: 1 M2: 3 11: 3  [ SABME (set asynchronous balanced mode extended) ]
< 0 bytes of data
1 -- Got SABME from cpe peer.
1 Sending Unnumbered Acknowledgement
1
> [ 00 81 73 ]
1
> Unnumbered frame:
1 > SAPI: 00  C/R: 0 EA: 0
>  TEI: 064        EA: 1
1 >   M3: 3   P/F: 1 M2: 0 11: 3  [ UA (unnumbered acknowledgement) ]
> 0 bytes of data
1 -- Restarting T203 counter
== Primary D-Channel on span 1 up
== Primary D-Channel on span 1 up for TEI 64
Really destroying SIP dialog '75c283464285bc8b72b3365a05ee0f5d@provider' Method: INVITE
-- Hungup 'Zap/2-1'

 

[laureen]

1. schau mal, ob sich der zaphfc treiber in deinem syslog dumm und dämlich loggt ("buffer underrun" etc.)

2. mach mal im leerlauf (also ohne aktivem call)

# watch -n 1 cat /proc/zaptel/1

um zu sehen, ob der channel zwischen "ACTIVATED" und "DEACTIVATED" hin und her springt.

3. weisst du, ob der externe S0 der ISDN anlage auf point-to-point oder point-to-multipoint geschaltet ist?

grüße,
laureen

 

[jaw]

also es sind gelegentliche Underruns drin, im Schnitt würde ich sagen alle 1-2h ein Logeintrag.
Was mich halt wundert ist, dass die Verbindung zum Asterisk klappt, und auch Verbindungen vom Asterisk in die TK-Anlage (T-Concept 520 XL).


while true; do cat /proc/zaptel/1; done
liefert auch über mehrere Minuten nur ACTIVATED - ist also stabil

Wenn es da klappern würde, müsste ja auch die Voicemail-Abfrage abbrechen, und auch eingehende Gespräche nicht funktionieren. Die gehen aber problemlos auch 'ne Stunde am Stück, wenns sein muss.

Die Anlage kann zwischen zwei Anschlusstypen umgeschaltet werden. Da mir die beide jetzt nicht wirklich auf Anhieb was sagen, schau ich morgen in der Config nach, wie das da genau benannt wurde.
die zapata.conf steht auf
signalling = bri_net_ptmp

wenn ich bri_net nehme, dann geht gar nichts, und die CLI überhäuft mich mit Fehlern.
Mich wundert halt vor allem, dass es schon mehrere Wochen ohne Probleme und ohne Abbrüche lief, bevor die FC2 rein kam. Es kann, muss aber nicht einen kausalen Zusammenhang geben.

 

[laureen]

das kann natürlich sein, dass da diese FC2 reinspuckt, ich kenn mich mit chan_capi nicht wirklich aus, aber hätte da mal 3 ansätze:

1. check mal, welche karte für das timing verwendet wird (falls es da bei capi was gibt), vielleicht sind beide karten so konfiguriert, dass sie als primäre timing source arbeiten, was nicht gut ist. bei der zaphfc ist das der 2. parameter in der span zeile in der zaptel.conf

2. konfiguriere den zaphfc-treiber mit jitterbuffer=3 beim laden des kernel-modules, das hilft bei mir oft auf "problematischer" hardware

3. schmeiss die FC2 raus und ersetze sie duch eine zweite HFC-S karte, dann aber auch darauf achten, dass die 2. karte als sekundäre timing source arbeitet (zaptel.conf):

...
span = 1,[highlight]1[/highlight],3,ccs,ami
...
span = 2,[highlight]2[/highlight],3,ccs,ami
...

[EDIT]

while true; do cat /proc/zaptel/1; done

AUA! wenn schon mit while, dann bitte so:

# while true; do cat /proc/zaptel/1; sleep 0.1; done

[/EDIT]
grüße,
laureen

 

[jaw]

[EDIT]
AUA! wenn schon mit while, dann bitte so:

# while true; do cat /proc/zaptel/1; sleep 0.1; done

[/EDIT]
grüße,
laureen

kurzzeitig darf der Test ruhig 100% CPU verbraten - dazu kann der Kernel ja Multitasking.

Die Lösung mit zwei HFC-Karten war mein erster Versuch, doch leider klappte das nicht, deshalb hab ich die HFC-S durch die FC2 ersetzt, siehe http://www.ip-phone-forum.de/showthread.php?t=168093 - im Prinzip ist mir ja egal, mit welcher Karte es funktioniert - so lange es läuft.
Ich werds mit dem Timing-Parameter noch versuchen - der war in der zaptel.conf bei beiden Spans auf 1 - vielleicht löst das ja meinen anderen Thread. Jitterbuffer werd ich später noch ausprobieren, und bei der Gelegenheit auch gleich noch das Debugging im zaphfc-Modul einschalten.

Für die capi.conf muss ich erst mal 'ne gute Referenz suchen. Allerdings müsste es dann ja gehen, wenn ich den Capi-Treiber entferne und den Asterisk nur mit einer ISDN Leitung starte. Probier ich auch nacher noch.
Muss leider jetzt erst mal arbeiten.

 

[laureen]

kurzzeitig darf der Test ruhig 100% CPU verbraten - dazu kann der Kernel ja Multitasking.

das funktioniert auch sicherlich, solange keine hardware im spiel ist, aber die HFC-S karte sendet 8000 interrupts pro sekunde an die cpu...ich weiss nicht, ob das noch so reibungslos funktioniert. zumindest bei hyperthreading cpus würde ich mir da gedanken machen, dual-cores schaffen das (denke ich)...

zurück zum thema: bitte achte darauf, dass die beiden karten einen dedizierten irq haben, zur not würde ich usb und/oder soundkarte abdrehen, wenn du diese nicht brauchst. herausfinden kannst du das mit

# cat /proc/interrupts

grüße,
laureen

 

[jaw]

naja, die Interrupts und Kernelprozesse haben ja Priorität vor User-Prozessen, von daher denke ich nicht, dass es Probleme macht, jedenfalls nicht, so lange die Kernel-Prozesse selber nicht 100% Rechenzeit verbraten.

Die HFC hat einen dedizierten Interrupt, die FC2 muss sich einen Int mit einer NIC teilen. Das wird sich vermutlich nicht umgehen lassen, denn es ist schon alles deaktiviert, was ich nicht benötige, aber in der Kiste sind 3 NICs und 2 ISDN Karten drin - und dazu noch 'ne GraKa für Diagnosezwecke, aber ohne Int.

An der entsprechenden NIC (3Com Cyclone, verarbeitet recht viel on Chip und wenig im Treiber) liegen nur VLans mit geringem Datendurchsatz an - als Dauerlast nur zwei IP-Phones. Mehr optimieren kann ich nur schlecht - evtl. kann ich noch schauen, dass sich zwei der NICs einen Int teilen, um so einen für die 2. HFC dediziert frei zu bekommen. Ich setz die Vorschläge gleich heute Abend mal um. Meine Hoffnung setz ich grade vor allem auf den Timer vom 2. Span. Kann man das am Debugging von dem anderen Thread irgendwie sehen, ob es damit zusammen hängen kann?

 

[laureen]

mit sicherheit kann ich dir das nicht sagen, ich habe jedoch die erfahrung gemacht, dass interrupt-probleme meistens mit "buffer overflow" bzw. "buffer underrun" meldungen im syslog hand in hand gehen.

hatte es schon mal, dass eine hfc karte den irq der netzwerkkarte mitverwendete, war nicht wegzubekommen (via epia embedded motherboard), und sobald ich ein "ngrep" machte, hat der zaphfc treiber wie verrückt diese buffer meldungen geloggt. hab da rund 2 monate rumgesucht, gepatcht, ausprobiert etc.

nach langem debuggen hab ich die ursache dann gefunden: sobald die netzwerkkarte im promiscuous mode war, sendete die massenweise interrupts zum kernel, da war die hfc karte gar nicht erfreut und hat begonnen, haufenweise buffer underruns und overflows anzumeckern. dann kam irgendwann der punkt, da der syslog die meldungen auch auf die platte zurückschreiben musste, was zu einer cpu auslastung von 100% sys führte, da die platte eine CF-karte war und nicht schnell genug wegschreiben konnte. ein beenden des ngrep brachte dann auch nichts mehr, einzig ein unload des hfc treibers beendete den zustand. erst ein anheben des jitterbuffers auf 3 behob das problem einigermassen, es kamen immer noch hin und wieder mal buffer meldungen, aber dieses aufschaukeln war nicht mehr zu beobachten - klingt seltsam, ist aber so....

grüße,
laureen