Outgoing Call über chan_capi bleibt hängen

[jj458]

Habe häufig folgendes Problem:

• outgoing call wird von asterisk initiiert (über Datei call.txt in /var/spool/asterisk/outgoing)
• Angerufener ISDN Teilnehmer legt auf
• Die Verbindung wird nicht abgebaut, die ISDN Karte ist blockiert.
• Es hilft nur ein core restart

vega*CLI> core show channels verbose
Channel              Context              Extension        Prio State   Application  Data                      CallerID        Duration Accountcode BridgedTo   
0 active channels
1 active call
11 calls processed
vega*CLI> capi show channels
CAPI B-channel information:
Line-Name       NTmode state i/o bproto isdnstate   ton  number
----------------------------------------------------------------
ISDN1#02         no    Conn   O  trans  *BP         0x00 '18'->'**12'  B3q=1120 B3count=0
ISDN1#01         no    Disc   -  trans              0x00 ''->''  B3q=0 B3count=0

Es ist mir einmal gelungen, den Fehler mit eingeschaltetem capi debug zu fangen, siehe Attachment.

Konfiguration:

• Fedora 13
• Dual-Core Rechner
• asterisk-1.6.2.11-1.fc13.x86_64
• chan_capi.so Rev. 831
• AVM B1 V4.0
• Eumex 322

Im angehängten Logfile hatte ich noch eine ältere chan_capi Version. Der gleiche Fehler trat auch schon auf mit einer passiven Fritz! PCI Karte mit fcpci.

Erläuterungen zum angehängten Logfile:
- Anruf immer von MSN 18 zu MSN **12
- Der abgehende Anruf ist auch als ankommender Anruf auf demselben BUS zu sehen
- Im Logfile sind zwei Anrufe enthalten:
ab Zeile 39 der Gut-Fall, ab Zeile 382 der Schlecht-Fall.

Anlagen:

• asterisk 20100820-2-nl.txt (Logfile)
• extensions.conf (relevanter Teil)
• capi.conf
• call.txt (Datei, die den Call auslöst)

Was mache ich falsch, was läuft da schief?

Jochen

 

[armincm]

Das könnte an dem Fehler liegen, der seit chan_capi HEAD revision 838 behoben sein müsste. Bitte teste es mal mit der aktuellen HEAD Version.

Armin

 

[jj458]

Hallo Armin,

Danke für die Antwort!

Habe (versehentlich) anstelle der aktuellen Head Version die chan_capi-1.1.5 (Revision: 789) genommen. Dort ist das Problem nicht mehr aufgetreten.
Habe allerdings auch die Hardware geändert: anstelle einer AVM B1 ist jetzt eine DIVA Server 4BRI verbaut.

Jochen