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:
> 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)
>
>
> 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?
> 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.
--
Tzafrir Cohen
icq#16849755 jabber:[EMAIL PROTECTED]
+972-50-7952406 mailto:[EMAIL PROTECTED]
http://www.xorcom.com iax:[EMAIL PROTECTED]/tzafrir
_______________________________________________
Bristuff-users mailing list
[email protected]
http://lists.three-dimensional.net/mailman/listinfo/bristuff-users
