Asterisk Absturz chan_capi.c

[redasystems]

Hallo,

ich habe eine Asterisk Installation mit chan_capi und mehr als 30 Cisco IP Phones 7970

einige male in der Woche, teilweise sogar pro Tag hängt sich die Anlage aus unerklärlichen Gründen auf

Folgende Zeile wiederholt sich dann ständig

/var/log/asterisk/messages

Mar 1 13:29:43 ERROR[6026] chan_capi.c: Could not write to pipe for ISDN3#02

habe eine 4 Port IDSN PCI Karte im Server

der Dienst asterisk -f läuft noch, jedoch funktioniert auf den Phones nichts mehr

nach einem Server reboot läufts wieder.

Bitte um Hilfe

Vielen Dank

Daniel

 

[Netview]

Alles sehr informativ!

Welche asterisk-Version, welche chan-capi, welch chan-sccp-Version oder sind die Ciscos per SIP angeschlossen - also etwas mehr Information darf es schon sein!

 

[redasystems]

Meine Versionen

Hallo,

Asterisk 1.2.13
SCCP channel version: 20060408 (die letzte aktuelle Version)

show modules

chan_misdn.so Channel driver for mISDN Support (Bri/Pr 0
chan_sccp.so Skinny Client Control Protocol (SCCP). R 0

lspci

0000:00:12.0 Network controller: AVM Audiovisuelles MKTG & Computer System GmbH Fritz!PCI v2.0 ISDN (rev 01)
0000:00:14.0 Network controller: AVM Audiovisuelles MKTG & Computer System GmbH Fritz!PCI v2.0 ISDN (rev 02)

lsmod

mISDN_dsp 191788 0
avmfritz 20268 0
mISDN_capi 92236 0
mISDN_l2 36416 0
mISDN_l1 10760 0
capi 16288 0
kernelcapi 43936 2 mISDN_capi,capi
capifs 5576 2 capi
mISDN_isac 14880 1 avmfritz
mISDN_core 70656 7 mISDN_dsp,avmfritz,mISDN_capi,l3udss1,mISDN_l2,mISDN_l1,mISDN_isac

 

[divB]

Wie gut kennst du dich aus?

Weil glücklicherweise ist der Sourcecode ja verfügbar!

Hätte ich das Problem, würde ich in den Sourcecode schauen wo die Meldung herkommt und was dafür verantwortlich ist.

Ggf. auch auf die chan_capi-Mailinglist posten, da das ein chan_capi spezifischer Fehler ist (offenbar).

 

[armincm]

Offenbar wird aber chan_misdn verwendet!?

Dann waere weder capi noch chan-capi notwendig.
Beides zusammen jedenfalls macht keinen Sinn.

Armin

 

[dynamic]

Hi,

ich habe das gleiche Problem ... :
- Asterisk v1.2.14 auf FBF
- chan_sccp.so Version vom 20060408

Das Problem kann einigermaßen eingegrenzt und reproduziert werden und tritt ( zumindest in meinem Fall ) lediglich bei der Eingabe von Touch-Tones ( DTMF Tönen ) z.B. für die Eingabe des Passcodes für Telefonkonferenzen oder Ähnlichem auf.

Anbei ein log-out bei eingeschaltetem capi debug:

    -- Executing Dial("SCCP/701-00000007", "CAPI/ISDN1/9765432:067771234567|40|b") in new stack
       > data = ISDN1/9765432:067771234567 format=8
       > capi request for interface 'ISDN1'
  == ISDN1#02: Call CAPI/ISDN1/067771234567-7   (pres=0x00, ton=0x00)
    -- ISDN1#02: received CONNECT_CONF PLCI = 0x1901
    -- Called ISDN1/9765432:067771234567
    -- CAPI queue frame:[ TYPE: Control (4) SUBCLASS: Unknown control '15' (15) ] [ISDN1#02]
    -- CAPI/ISDN1/067771234567-7 is proceeding passing it to SCCP/701-00000007
    -- CAPI queue frame:[ TYPE: Control (4) SUBCLASS: Unknown control '14' (14) ] [ISDN1#02]
    -- CAPI queue frame:[ TYPE: Control (4) SUBCLASS: Ringing (3) ] [ISDN1#02]
    -- CAPI/ISDN1/067771234567-7 is making progress passing it to SCCP/701-00000007
    -- CAPI/ISDN1/067771234567-7 is ringing
    -- CAPI queue frame:[ TYPE: Control (4) SUBCLASS: Answer (4) ] [ISDN1#02]
       > ISDN1#02: DTMF conf(PLCI=0x1901)
    -- CAPI/ISDN1/067771234567-7 answered SCCP/701-00000007
    -- SCCP: Channel type undefined, setting to type 'SCCP'
    -- SCCP: Outgoing call has been answered SCCP/701-00000007 on 701@SEP001234567890-7
    -- SEP001234567890: Cisco Digit: 00000001 (1) on line 701
       > ISDN1#02: DTMF conf(PLCI=0x1901)
    -- SEP001234567890: Cisco Digit: 00000009 (9) on line 701
       > ISDN1#02: DTMF conf(PLCI=0x1901)
    -- SEP001234567890: Cisco Digit: 00000008 (8) on line 701
       > ISDN1#02: DTMF conf(PLCI=0x1901)
    -- SEP001234567890: Cisco Digit: 00000007 (7) on line 701
       > ISDN1#02: DTMF conf(PLCI=0x1901)
    -- SEP001234567890: Cisco Digit: 00000008 (8) on line 701
       > ISDN1#02: DTMF conf(PLCI=0x1901)
    -- SEP001234567890: Cisco Digit: 00000008 (8) on line 701
       > ISDN1#02: DTMF conf(PLCI=0x1901)
    -- SEP001234567890: Cisco Digit: 00000009 (9) on line 701
       > ISDN1#02: DTMF conf(PLCI=0x1901)
    -- SEP001234567890: Cisco Digit: 00000008 (8) on line 701
       > ISDN1#02: DTMF conf(PLCI=0x1901)
    -- SEP001234567890: Cisco Digit: 00000005 (5) on line 701
       > ISDN1#02: DTMF conf(PLCI=0x1901)
    -- SEP001234567890: Cisco Digit: 00000005 (5) on line 701
       > ISDN1#02: DTMF conf(PLCI=0x1901)
    -- SEP001234567890: Cisco Digit: 00000004 (4) on line 701
       > ISDN1#02: DTMF conf(PLCI=0x1901)
    -- SEP001234567890: Cisco Digit: 00000005 (5) on line 701
       > ISDN1#02: DTMF conf(PLCI=0x1901)
    -- SEP001234567890: Cisco Digit: 00000006 (6) on line 701
       > ISDN1#02: DTMF conf(PLCI=0x1901)
    -- SEP001234567890: Cisco Digit: 00000003 (3) on line 701
       > ISDN1#02: DTMF conf(PLCI=0x1901)
    -- SEP001234567890: Cisco Digit: 00000002 (2) on line 701
Mar 12 09:03:09 ERROR[3851]: chan_capi.c:918 local_queue_frame: Could not write to pipe for ISDN1#02
Mar 12 09:03:09 ERROR[3851]: chan_capi.c:918 local_queue_frame: Could not write to pipe for ISDN1#02
Mar 12 09:03:09 ERROR[3851]: chan_capi.c:918 local_queue_frame: Could not write to pipe for ISDN1#02
Mar 12 09:03:10 ERROR[3851]: chan_capi.c:918 local_queue_frame: Could not write to pipe for ISDN1#02

 

[seschmid]

Hallo,

hatte auch das gleiche Problem ... :
- Asterisk v1.4.2 auf FBF
- chan_sccp.so letzte subversion

Trat zunächst auch nur nach Eingabe von DTMF Tönen auf.

Nach Änderung der capi.conf
>softdtmf=off
>relaxdtmf=off
trat die Meldung nicht mehr auch.

 

[dynamic]

@seschmid

Gibt es bei OpenWRT mittlerweile die 1.4.2 Version ? Ist mir gar nicht aufgefallen Muss ich mir nachher mal anschauen.

Bei mir sind beide Flags in der capi.conf bereits auf OFF aber das Problem tritt nach wie vor auf.
Evtl. ist das Problem ja in der 1.4.2'er Version behoben, falls unter OpenWRT wirklich diese verfügbar sein sollte.

Ich schaue bei OpenWRT heute Abend nochmal vorbei ...

Gruß
dynamic

 

[seschmid]

@dynamic

Ich habe mir die 1.4.2 + chan_capi nachträglich manuell kompiliert und erst mal nur über nfs eingebunden.
vor änderung der capi.conf wurden die DTMF töne lt. den debug ausgaben auch gar nicht erkannt.
es mag zufall sein - die sprachqualität war nach der änderung auch besser.

 

[dynamic]

@seschmid

auch auf die Gefahr hin, daß ich vom Thema etwas abweiche.
Habe vorhin die aktuelle * Version unter OpenWRT kompiliert und diese ist derzeit nochbei 1.2.16.

Welche * distri nutzt Du denn ? Musstest Du die sourcen patchen ?

Gruß
dynamic

 

[seschmid]

@dynamic

Ich habe mir die ds-mod ds-0.2.9_26-14.1,asterisk 1.42,chan_capi quellen runtergeladen,
asterisk/chan_cap dann mit dem gcc aus ds-0.2.9_26-14.1 kompiliert - unter opensuse10.0 - und dann in meine fb eingebunden.
war teilweise etwas handarbeit erforderlich,
auf den ersten blick funktioniert auch (fast) alles was ich möchte.
nur moh wird zu 50% beim raustelefonieren ins festnetz sofort wieder gestoppt,
>Stopped music on hold on...is making progress passing it
passiert allerdings nicht nach einem callback

 

[dynamic]

@seschmid

Thanks für die Info ... dann gehe ich davon aus, daß Du die * Version von zandbelt nutzt ?

Also wenn sich diese Version ganz ohne manuelle Eingriffe compilieren lässt, dann schaue ich mir das am Wochenende vielleicht auch mal an

Zurück zum Thema:
Ich habe mit den DTMF Settings unter capi.conf uach mal rumexperiementiert ( ich habe von "off" nach "on" geswitcht ) und irgendwie habe ich den Fehler gestern noch nicht gehabt ... könnte aber Zufall sein.

Werde im Laufe nochmal einen Update posten ...

Gruß
dynamic

 

[seschmid]

@dynamic

Nein, ich habe mir die Quellen direkt bei asterisk.org runtergeladen
und dann mit ./configure make menuconfig usw. kompiliert
und auf die fb verschoben.
muss dazu sagen das beim make unter /main/editline - keine ahnung was das macht
- immer ein fehler auftrat. nach stunden der fehlersuche habe ich dann einfach das entsprechende exit aus dem makefile entfernt - dann lief alles durch.
sicher nicht die eleganteste variante - scheint aber alles zu funktionieren.
Die zandbelt Version kannte ich bis eben noch gar nicht - hätte mir aber sicher
viel zeit erspart.

 

[dynamic]

@seschmid
Die Änderungen in der capi.conf haben wohl doch nicht die erwartete "heilende Wirkung" gezeigt. Problem tritt nach wie vor auf.
Ich kompiliere gerade mal die * 1.4.2 Version von zandbelt ... mal sehen ob dort das Problem behoben ist

Thanks!

 

[seschmid]

@dynamic

Ich habe gerade mal die beiden Werte wieder auf ON gesetzt, die Fehlermeldung
erschien hier bei vier Versuchen ( Call back auf ISDN Anschluss) auch nicht mehr.
Vielleicht doch noch eine andere Ursache.
Habe ja inwischen auch noch diverse Änderungen im Dialplan und SIP.CONF vorgenommen.
Bei meinen ersten Tests trat der Fehler aber definitiv auch bei mehreren Versuchen
immer auf, und war nach SOFTDTMF / RELAXDTMF = OFF sofort weg.
Allerdings nutze ich die Funktion auch kaum - wollte nur mal sehen was geht.