Posted: Thu Jul 31, 2008 9:12 am Post subject: [Bristuff-users] "Cause 34" sum up
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
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")?
Posted: Fri Aug 01, 2008 9:25 am Post subject: [Bristuff-users] "Cause 34" sum up
I think this has been suggested previously, but I would definitely
consider switching the signalling to Point-to-Point (PtP) rather than
point-to-multipoint (PtMP).
The difference is that PtMP has no pre-setup channel between the NTE
and CPE. The caller sends a "broadcast" to the D-channel saying "does
anybody want this number", and if it gets a response, it sets up a
shared B-channel for the duration of the call. PtP will effectively
associate each B-channel in advance with a known endpoint, and will
send keepalives to ensure that the endpoint is still there and able to
accept calls.
The biggest problem with PtMP is it is horrible at determining that
there is a fault - It basically waits about 10 seconds for the
broadcast to time out. Also, because there is no pre-agreed channel,
it does not know what the fault really is. It just knows that the
broadcast is getting no response.
Regards,
Steve
2008/8/1 Gunnar Schaller <linux@nowin.de>:
Quote:
It happened again (no one is one the phone, but "cause 34" when trying
to make a call) and now I have some output.
Posted: Mon Aug 04, 2008 6:36 pm Post subject: [Bristuff-users] "Cause 34" sum up
Hello Steve,
In Switzland it is not possible to switch from p2mp to ptp without
loosing the phone numbers. Yes I know p2p works as described and that
it would solve the problem, but not for me without loosing my
well-known phone numbers.
I want to find the bug. Can anyone please read my logs or tell me how
to isolate the bug?
Thanks,
Gunnar Schaller
Friday, August 1, 2008, 12:25:23 PM, you wrote:
Quote:
I think this has been suggested previously, but I would definitely
consider switching the signalling to Point-to-Point (PtP) rather than
point-to-multipoint (PtMP).
Quote:
The difference is that PtMP has no pre-setup channel between the NTE
and CPE. The caller sends a "broadcast" to the D-channel saying "does
anybody want this number", and if it gets a response, it sets up a
shared B-channel for the duration of the call. PtP will effectively
associate each B-channel in advance with a known endpoint, and will
send keepalives to ensure that the endpoint is still there and able to
accept calls.
Quote:
The biggest problem with PtMP is it is horrible at determining that
there is a fault - It basically waits about 10 seconds for the
broadcast to time out. Also, because there is no pre-agreed channel,
it does not know what the fault really is. It just knows that the
broadcast is getting no response.
You can post new topics in this forum You can reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
