[Bristuff-users] "Cause 34" sum up

[Gunnar Schaller]

Hello again,
Today I had the "cause 34" again. Environment:
- bristuff-0.3.0-PRE-1y-s.tar.gz
- qoadbri card with qozap driver
- 1 isdn ptmp link at port 1, zap group 1
- I had no chance to get "pri show span 1"
- Linux kernel 2.6.22-4 in Debian etch

output of qozap driver (line 1001):
Jul 31 10:37:02 borox kernel: card 1 span 1 state F4 (A_ST_RD_STA = 0x44)
Jul 31 10:37:02 borox kernel: card 1 span 1 state F5 (A_ST_RD_STA = 0x5)
Jul 31 10:37:02 borox kernel: card 1 span 1 state F6 (A_ST_RD_STA = 0x16)
Jul 31 10:37:02 borox kernel: card 1 span 1 state F7 (A_ST_RD_STA = 0x17)
Jul 31 10:42:01 borox kernel: card 1 span 1 state F6 (A_ST_RD_STA = 0x16)
Jul 31 10:42:01 borox kernel: card 1 span 1 state F3 (A_ST_RD_STA = 0x43)
Jul 31 10:43:36 borox kernel: card 1 span 1 state F6 (A_ST_RD_STA = 0x16)
Jul 31 10:43:36 borox kernel: card 1 span 1 state F7 (A_ST_RD_STA = 0x17)
Jul 31 10:45:45 borox kernel: card 1 span 1 state F6 (A_ST_RD_STA = 0x16)
Jul 31 10:45:45 borox kernel: card 1 span 1 state F3 (A_ST_RD_STA = 0x43)
Jul 31 10:45:58 borox kernel: card 1 span 1 state F4 (A_ST_RD_STA = 0x44)
Jul 31 10:45:58 borox kernel: card 1 span 1 state F5 (A_ST_RD_STA = 0x5)
Jul 31 10:45:58 borox kernel: card 1 span 1 state F6 (A_ST_RD_STA = 0x16)
Jul 31 10:45:58 borox kernel: card 1 span 1 state F7 (A_ST_RD_STA = 0x17)
Jul 31 10:58:11 borox kernel: card 1 span 1 state F6 (A_ST_RD_STA = 0x16)
Jul 31 10:58:11 borox kernel: card 1 span 1 state F3 (A_ST_RD_STA = 0x43)
Jul 31 11:04:41 borox kernel: card 1 span 1 state F6 (A_ST_RD_STA = 0x16)
Jul 31 11:04:41 borox kernel: card 1 span 1 state F7 (A_ST_RD_STA = 0x17)

short summary of what's going with Asterisk in this timeslot:
Jul 31 10:45:58 external call from SIP-phone to Zap/1-1
Jul 31 10:46:01 Zap/1-1 ringing
Jul 31 10:46:32 Zap/1-1 answered
Jul 31 10:47:30 incoming call Zap/2-1, tried to forward to Zap/g1, failed with "cause 34"
Jul 31 10:53:41 incoming call Zap/2-1, tried to forward to Zap/g1, failed with "cause 34"
Jul 31 10:55:18 incoming call Zap/2-1, tried to forward to Zap/g1, failed with "cause 34"
Jul 31 10:57:26 hungup Zap/1-1 --> all channels should be free now
Jul 31 11:04:41 incoming call Zap/1-1, tried to forward to Zap/g1, failed with "cause 34"
Jul 31 11:05:30 SIP phone tried to call outside with Zap/g1, failed with "cause 34"

At first there was a call from a SIP-phone to the outside. So first
B-channel was in use while another calls came in. Asterisk tried to
forward these calls to another external number.
Executing Dial("Zap/2-1", "ZAP/g1/XXXXXX")
That failed cause there was no free B-channel, so "cause 34" was
normal and correct. But after all two B-channels were free it was also
not possible to dial out. First there was a try from Zap/1-1 to Zap/g1
at 11:04:41, later a try from a SIP-phone to Zap/g1 at 11:05:30. Both
not successful with "cause 34".
I think Asterisk came in trouble at 10:47:30. Is it possible Asterisk
"forget" to reset some internal variables to mark the channels as free
channels? What debug output is needed to find out more (beside "pri
show span 1")?


Regards,
Gunnar Schaller