Posted: Fri May 30, 2008 6:51 am Post subject: [Bristuff-users] "Cause 34" sum up
Hi,
Here is a short description of previous threads :
Symptoms
Users cannot issue any outgoing call though Basic Rate Interface lines are not all busy.
Each time this happens, logs show "WARNING[26083] app_dial.c: Unable to create channel of type 'Zap' (cause 34 - Circuit/channel congestion)" (from /var/log/asterisk/full).
Environment
Either :
A - 1.4.17-BRIstuffed-0.4.0-test6 (olivier)
B- "last 3 versions of asterisk 1.2 bristuffed" (paco)
C- 0.3.0-PRE-1y-p or 0.3.0-PRE-1y-k (gunnar)
Frequency
No message during a couple of days then up to 30 messages a day.
Restarting Asterisk (asterisk -rx "restart when convenient") restores outgoing call capability for a new period of time.
Steps to reproduce symptoms:
None identified at the moment
Investigations:
Direction 1 : "Energy saving mode"
This issue might occur because Telco are entering energy-saving mode (Michiel).
Forbidding this energy saving mode fixed this.
We're using the same Telco (France Telecom) in 5 locations.
Problems occur in a single location where brand new BRI lines were provisioned.
Obviously, every morning, lines were inactive for last several hours, so lines should be "asleep".
In spite of that, we had no message for the first call in the morning.
1. Where can you read about energy-saving mode in ISDN BRI access ?
2. How can you check Telco enabled energy-saving mode ?
For me, it is very difficult to any reliable data from Telco on this.
Having a way to check things on my own would be very useful.
3. Beside Michiel, who has ever cured these symptoms after forbidding energy-saving mode ?
4. Why does this occur in 2008 ? Is this a new trend in Telco habbits ? BRI lines are here for years.
Direction 2 : reporting to Software editor
Has someone filed a bug report to Junghanns ?
If positive, is there anything ongoing on this ?
Should this be also handled to Digium ?
Posted: Fri May 30, 2008 8:35 am Post subject: [Bristuff-users] "Cause 34" sum up
Hi
As you might have noticed, I have been aufully quiet on this thread.
On Fri, May 30, 2008 at 09:50:34AM +0200, Olivier wrote:
Quote:
Hi,
Here is a short description of previous threads :
Symptoms
Users cannot issue any outgoing call though Basic Rate Interface lines are
not all busy.
Each time this happens, logs show "WARNING[26083] app_dial.c: Unable to
create channel of type 'Zap' (cause 34 - Circuit/channel congestion)" (from
/var/log/asterisk/full).
Environment
Either :
A - 1.4.17-BRIstuffed-0.4.0-test6 (olivier)
B- "last 3 versions of asterisk 1.2 bristuffed" (paco)
C- 0.3.0-PRE-1y-p or 0.3.0-PRE-1y-k (gunnar)
I'm surprised nobody noticed bristuff 0.4.0-RC1 . There is also 0.0.3 -q
with a number of small fixes, though nothing as drastic, IIRC.
I should hopefully release a -xr1 based on it (still not sure if I
should enable most patches by default). It seems to be reproduced there.
Not sure yet.
But I'll point to another way this error could be create on a multi-port
cards with BRI ptmp. Just to make sure that those two issues are not
related.
We had a slightly related issue yesterday:
we have a device with two BRI TE ports. For some reason I connected the
BRI connector to the second connetor. As of habbit, I used a "catch-all"
trunk (Zap/g1, and all the BRI TE ports had
group=1,<something-else,port-specific>)
The line was originally connected to the first BRI port, and things
worked fine. Now I connected the line to the second port, and bam, I get
exactly the error as above.
Why is that? Normally if a line is disconnected, the driver tells
Asterisk that the port is in RED alarm. A channel in alarm i not taken
into account when choosing the one to call through.
However, in BRI PTMP (due to power saving mode) the TE side knows that
it might have to take a port up. So Asterisk ignores RED alarms. And
thus it tried to call through the first port, which was disconnected.
So back to the original problem: what we have here layer one not ebing
up in time to make the call after being down. This is something that the
driver eeds to do right now. The whole situation is messy and allows
hiding errors, as you noticed from my example above.
(And thus: use ptp if you can)
Quote:
Frequency
No message during a couple of days then up to 30 messages a day.
Restarting Asterisk (asterisk -rx "restart when convenient") restores
outgoing call capability for a new period of time.
Steps to reproduce symptoms:
None identified at the moment
Investigations:
Direction 1 : "Energy saving mode"
This issue might occur because Telco are entering energy-saving mode
(Michiel).
Forbidding this energy saving mode fixed this.
We're using the same Telco (France Telecom) in 5 locations.
Problems occur in a single location where brand new BRI lines were
provisioned.
Obviously, every morning, lines were inactive for last several hours, so
lines should be "asleep".
In spite of that, we had no message for the first call in the morning.
1. Where can you read about energy-saving mode in ISDN BRI access ?
2. How can you check Telco enabled energy-saving mode ?
For me, it is very difficult to any reliable data from Telco on this.
Having a way to check things on my own would be very useful.
3. Beside Michiel, who has ever cured these symptoms after forbidding
energy-saving mode ?
4. Why does this occur in 2008 ? Is this a new trend in Telco habbits ? BRI
lines are here for years.
Direction 2 : reporting to Software editor
Has someone filed a bug report to Junghanns ?
As actually getting the line up is something the specific driver needs
to do, with what drivers was this reproduced?
* qozap
* zaphfc
- Anybody tried vzaphfc?
* Anybody got that with xpp/xpd_bri?
Quote:
If positive, is there anything ongoing on this ?
Should this be also handled to Digium ?
Only if you use Asterisk 1.6 and libpri >= 1.4.4 . This supports BRI
ptmp (though TE mode only). Should be interesting to compare.
Posted: Mon Jun 02, 2008 7:34 am Post subject: [Bristuff-users] "Cause 34" sum up
Hello,
Quote:
I'm surprised nobody noticed bristuff 0.4.0-RC1 . There is also 0.0.3 -q
with a number of small fixes, though nothing as drastic, IIRC.
OK I will try the latest Bristuff and report here. By the way I'm
using qozap.
Quote:
But I'll point to another way this error could be create on a multi-port
cards with BRI ptmp. Just to make sure that those two issues are not
related.
Quote:
We had a slightly related issue yesterday:
Quote:
we have a device with two BRI TE ports. For some reason I connected the
BRI connector to the second connetor. As of habbit, I used a "catch-all"
trunk (Zap/g1, and all the BRI TE ports had
group=1,<something-else,port-specific>)
Quote:
The line was originally connected to the first BRI port, and things
worked fine. Now I connected the line to the second port, and bam, I get
exactly the error as above.
Quote:
Why is that? Normally if a line is disconnected, the driver tells
Asterisk that the port is in RED alarm. A channel in alarm i not taken
into account when choosing the one to call through.
This is definitly not the case at my side. Every port is in a separate
group. After restarting Asterisk I can use the group again after
having "cause 34". It is a software problem.
Quote:
(And thus: use ptp if you can)
Not possible here. In Switzerland you cannot port your numbers to a
ptp connection. With ptmp you have multiple separate numbers (msn) and
with ptp you have a did.
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
