Asterisk "verliert" mit der Zeit Channels

[ziererk]

Hallo zusammen,
habe seit dem Upgrade von Asterisk auf 1.2.x folgendes Problem:
Nach dem Asterisk neu gestartet wurde, läuft alles bestens. Nach einiger Zeit (manchmal 2 Stunden, manchmal 2 Tage) geht nur noch ein Channel gleichzeitig. Wieder nach etwa der gleichen Zeitspanne gehen dann beide Channel nicht mehr. Keiner kann dann mehr raus- oder reinrufen.

Zuerst hatte ich Asterisk 1.2.1-BRIstuffed-0.3.0-PRE-1g, danach dachte ich, ein Update hilft vielleicht.
Jetzt benutze ich Asterisk 1.2.4-BRIstuffed-0.3.0-PRE-1l, aber das Problem ist noch immer da. Ansonsten ist das System ein 2.6.12.5 Kernel auf einem P4 mit ner Fritz! und ner HFC-Karte im NT-Modus.

Ein Bug? Eine Einstellung? Mit Asterisk 1.0.x lief's auf jeden Fall bestens.

Danke schon mal.

Klaus

zapata.conf

[trunkgroups]

[channels]
language=de
context=default
switchtype=euroisdn
pridialplan=local
overlapdial=yes
rxwink=300
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
rxgain=0.0
txgain=0.0
group=1
callgroup=1
pickupgroup=1
immediate=no
progzone=de
signalling = bri_net_ptmp
group = 1
channel => 1-2

zaptel.conf

loadzone=nl
defaultzone=nl

span=1,1,3,ccs,ami
bchan=1-2
dchan=3

 

[ziererk]

Habe noch etwas nachgeforscht. Bei zap show channel 1 scheint es so, als würde der Channel im Gespräch hängen bleiben. Oder kann mir jemand diese Werte deuten? Es läuft definitiv kein Gespräch, Asterisk hat "0 active channels".

fileserver*CLI> zap show channel 1
Channel: 1
File Descriptor: 21
Span: 1
Extension:
Dialing: no
Context: default
Caller ID:
Calling TON: 0
Caller ID name:
Destroy: 0
InAlarm: 0
Signalling Type: PRI Signalling
Radio: 0
Owner: <None>
Real: <None>
Callwait: <None>
Threeway: <None>
Confno: -1
Propagated Conference: -1
Real in conference: 0
DSP: no
Relax DTMF: no
Dialing/CallwaitCAS: 0/0
Default law: alaw
Fax Handled: no
Pulse phone: no
Echo Cancellation: 128 taps, currently OFF
PRI Flags: Call
PRI Logical Span: Implicit
Hookstate (FXS only): Onhook

fileserver*CLI> zap show channel 2
Channel: 2
File Descriptor: 22
Span: 1
Extension:
Dialing: no
Context: default
Caller ID: 947022
Calling TON: 1
Caller ID name:
Destroy: 0
InAlarm: 0
Signalling Type: PRI Signalling
Radio: 0
Owner: <None>
Real: <None>
Callwait: <None>
Threeway: <None>
Confno: -1
Propagated Conference: -1
Real in conference: 0
DSP: no
Relax DTMF: no
Dialing/CallwaitCAS: 0/0
Default law: alaw
Fax Handled: no
Pulse phone: no
Echo Cancellation: 128 taps, currently OFF
PRI Flags:
PRI Logical Span: Implicit
Hookstate (FXS only): Onhook

 

[kombjuder]

Hallo ziererk,

ich hatte evtl. diese Phänomen neulich auf meinem Probierasterisk auch. Wenn ich das richtig in Erinnerung habe, trat das nach einem nicht richtig gehandelten Anruf auf. Genauers weiss ich aber nicht mehr.

 

[ziererk]

Hallo kombjuder,
was genau meinst du mit nicht richtig gehandelten Anruf? Ich hab bei mir auf jeden Fall das Gefühl, das Problem tritt (dennoch sporadisch) dann auf, wenn jemand während der Voicemail-Ansage auflegt. Und es lässt sich auch dadurch beheben, dass ich nur das chan_zap-Modul neu lade.

Klaus

 

[kombjuder]

Hallo kombjuder,
was genau meinst du mit nicht richtig gehandelten Anruf?

Asterisk landet in einer ungültigen extension bzw einer ohne für den Anruf gültige Regel.

Gruß

Kombjuder