On 13:53, Fri 09 May 08, Gunnar Schaller wrote:
> Another update: It seems that layer 1 is not active the whole time. If
> the ISDN line is in idle mode I have the "cause 34" errors. After
> dialing in the layer is active again and I can dial out. But after
> some time the layer 1 is in idle mode again.
> Is there any way to force the layer 1 to be always up? Some option for
> the qozap driver? Or is there some way to modify the soruce code to
> handle the idle mode?
You have to ask your telco to disable energy saving.
We had the same issue with a couple of customers. One call to the telco
was enough to fix it.
1. How do you check a telco line has energy saving turned on or off ?
2. Did you also have a site successfully running with energy saving turned on ? In other words, do you mean "energy savings implies cause 34 errors error messages" ?
Posted: Thu May 15, 2008 5:14 pm Post subject: [Bristuff-users] "Cause 34" on free channel
On 16:30, Thu 15 May 08, Olivier wrote:
Quote:
Michiel,
2008/5/9 Michiel van Baak <michiel@vanbaak.info>:
> On 13:53, Fri 09 May 08, Gunnar Schaller wrote:
> > Another update: It seems that layer 1 is not active the whole time. If
> > the ISDN line is in idle mode I have the "cause 34" errors. After
> > dialing in the layer is active again and I can dial out. But after
> > some time the layer 1 is in idle mode again.
> > Is there any way to force the layer 1 to be always up? Some option for
> > the qozap driver? Or is there some way to modify the soruce code to
> > handle the idle mode?
>
> You have to ask your telco to disable energy saving.
> We had the same issue with a couple of customers. One call to the telco
> was enough to fix it.
1. How do you check a telco line has energy saving turned on or off ?
As far as I know:
Leave the line idle for like 15 minutes. If the error shows up after
that: Bingo.
But other than that the only way to find out is bug your telco.
Quote:
2. Did you also have a site successfully running with energy saving turned
on ? In other words, do you mean "energy savings implies cause 34 errors
error messages" ?
No, we never got it running without issues on a line that has energy
saving turned on.
As soon as we see 'cause 34' errors we call the telco and demand to
disable it. Sometimes you have to speak with firm words before they do
it, but I found out the line: "I understand that you cannot help me. No
problem. Now connect me to your supervisor so I can find out who to call
to get things correct. Dont worry, I'll tell your supervisor you have
been of great help and that this problem is beyond your duties"
They know it's getting recorded and they know I know so they transfer me
to some level2,3,4,5 tech and that does the job.
On 16:30, Thu 15 May 08, Olivier wrote:
> Michiel,
Quote:
> 1. How do you check a telco line has energy saving turned on or off ?
As far as I know:
Leave the line idle for like 15 minutes. If the error shows up after
that: Bingo.
But other than that the only way to find out is bug your telco.
Just to be 100% sure we're talking of the same thing, would you say those lines have energy savings turned on ?
(those ports come from the same board, from a setup causing "cause 34" errors. As you can see, at the moment I typed the command, port 1 was unused and port 2 was used)
4 ztqoz1/2/1 Clear (In use)
5 ztqoz1/2/2 Clear (In use)
6 ztqoz1/2/3 HDLCFCS (In use)
...
If positive (if energy saving mode is on), then allow me to say it's strange to link errors and energy saving mode : I've got alternate installations with, I think, the same set of settings and I don't get a single "cause 34".
On 16:30, Thu 15 May 08, Olivier wrote:
> Michiel,
>
>
> 2008/5/9 Michiel van Baak <michiel@vanbaak.info (michiel@vanbaak.info)>:
>
> > On 13:53, Fri 09 May 08, Gunnar Schaller wrote:
> > > Another update: It seems that layer 1 is not active the whole time. If
> > > the ISDN line is in idle mode I have the "cause 34" errors. After
> > > dialing in the layer is active again and I can dial out. But after
> > > some time the layer 1 is in idle mode again.
> > > Is there any way to force the layer 1 to be always up? Some option for
> > > the qozap driver? Or is there some way to modify the soruce code to
> > > handle the idle mode?
> >
> > You have to ask your telco to disable energy saving.
> > We had the same issue with a couple of customers. One call to the telco
> > was enough to fix it.
>
>
> 1. How do you check a telco line has energy saving turned on or off ?
As far as I know:
Leave the line idle for like 15 minutes. If the error shows up after
that: Bingo.
But other than that the only way to find out is bug your telco.
So, would you say ?
1. this error would occur each time after a 15 (or so) minutes idle period (100%).
2. this error would occur from time to time after a 15 minutes idle period (0% < N <100%).
If it occurs each time, it should occur every morning, when the first employees places its first outgoing call.
For yourself, have you kept log files that could give a rough estimee of N (miss/trials ratio) ?
Beside that, restarting Asterisk shouldn't change Asterisk behaviour too much.
Posted: Mon May 19, 2008 6:58 pm Post subject: [Bristuff-users] "Cause 34" on free channel
On 17:16, Mon 19 May 08, Olivier wrote:
Quote:
2008/5/15 Michiel van Baak <michiel@vanbaak.info>:
So, would you say ?
1. this error would occur each time after a 15 (or so) minutes idle period
(100%).
2. this error would occur from time to time after a 15 minutes idle period
(0% < N <100%).
If it occurs each time, it should occur every morning, when the first
employees places its first outgoing call.
From memory this was not the case. It would happen from time to time.
Must be the telco doing stuff on their end.
Someone told me you have to disable the powersavings on the line if you
want to connect an alarm system to it, because of the same stuff you are
seeing in asterisk now.
I'm not a BRI guru, but this is all from experience and it worked on
several setups spread over the country.
Quote:
For yourself, have you kept log files that could give a rough estimee of N
(miss/trials ratio) ?
No. We dropped all BRI setups and went with pure voip wherever possible,
leaving 2 or 3 setups with PRI.
Quote:
Beside that, restarting Asterisk shouldn't change Asterisk behaviour too
much.
Restarting asterisk resets the ports on your BRI card. That will be
enough to issue a line reset at the telco side I think.
Again, I'm no BRI guru and I dont know exactly how it works.
On 17:16, Mon 19 May 08, Olivier wrote:
> 2008/5/15 Michiel van Baak <michiel@vanbaak.info (michiel@vanbaak.info)>:
>
Quote:
So, would you say ?
> 1. this error would occur each time after a 15 (or so) minutes idle period
> (100%).
> 2. this error would occur from time to time after a 15 minutes idle period
> (0% < N <100%).
>
> If it occurs each time, it should occur every morning, when the first
> employees places its first outgoing call.
From memory this was not the case. It would happen from time to time.
Must be the telco doing stuff on their end.
Someone told me you have to disable the powersavings on the line if you
want to connect an alarm system to it, because of the same stuff you are
seeing in asterisk now.
I'm not a BRI guru, but this is all from experience and it worked on
several setups spread over the country.
> For yourself, have you kept log files that could give a rough estimee of N
> (miss/trials ratio) ?
No. We dropped all BRI setups and went with pure voip wherever possible,
leaving 2 or 3 setups with PRI.
Restarting asterisk resets the ports on your BRI card. That will be
enough to issue a line reset at the telco side I think.
Again, I'm no BRI guru and I dont know exactly how it works.
Maybe we could :
1. make sure that each Asterisk restart issues a line reset at the Telco side.
2. understand why I do have locations served by the same Telco and behaving differently (one didn't have any cause 34, one is having every 3 or 4 weeks).
does it relate to distance between location and Telco switch ?
3. request this energy saving mode to be supported wherever it should (bristuff, DAHDI, ?)
I'm wondering if this mode is specific to BRI or comes also along PRI.
Posted: Wed May 28, 2008 5:25 pm Post subject: [Bristuff-users] "Cause 34" on free channel
Am 09.05.2008 14:30 Uhr schrieb Michiel van Baak:
Quote:
On 14:08, Fri 09 May 08, Gunnar Schaller wrote:
> Is there no way to handle it on the Asterisk side? Something to force
> the layer 1 to be up all the time? Does the qozap driver detect the
> idle mode/ energy saving?
If layer 1 is going down, the qozap driver will detect this. It will
also printk() a message if you load the driver with debug=n. If n > 2,
you will also see a message from the driver indicating that it tried to
re-enable layer 1.
Quote:
There's no way to keep the layer 1 up with the qozap driver.
You really need your telco to disable it
This is not correct. If layer 1 goes down, the HFC chips will signal
this and qozap will try to re-enable layer 1. Look at
bristuff-0.3.0-PRE-1y-q/qozap/qozap.c, line 1000 ff:
if (l1state == 3) {
qoztmp->st[st].l1up = 0;
if (qoztmp->st[st].t3 > -1) {
/* keep layer1 up, if the span is started. */
if (qoztmp->spans[st].flags & ZT_FLAG_RUNNING) {
if (debug > 2)
printk("qozap: re-activating layer1 span %d\n", st);
qoz_outb(qoztmp,qoz_A_ST_WR_STA,0x60);
Posted: Thu May 29, 2008 11:14 am Post subject: [Bristuff-users] "Cause 34" on free channel
Hello,
Thank you very much for your help. As discussed on Asterisk-Tag in
Berlin there is definitly a problem with power-saving mode/ layer 1
not active the whole time. So if the qozap driver handles it correctly
the failure is maybe in Asterisk or libpri...
I now commented the line 1005 and 1010 ("if (debug > 2)") in qozap.c
out so the qozap driver prints every try to re-activate the layer 1.
It would be fine to have somebody else trying this. We need the error
again to find out what happens in the inside of
Asterisk/libpri/zaptel/qozap. I hope we can fix it.
Thanks,
Gunnar
Wednesday, May 28, 2008, 8:23:05 PM, you wrote:
Quote:
Am 09.05.2008 14:30 Uhr schrieb Michiel van Baak:
Quote:
> On 14:08, Fri 09 May 08, Gunnar Schaller wrote:
>> Is there no way to handle it on the Asterisk side? Something to force
>> the layer 1 to be up all the time? Does the qozap driver detect the
>> idle mode/ energy saving?
Quote:
If layer 1 is going down, the qozap driver will detect this. It will
also printk() a message if you load the driver with debug=n. If n > 2,
you will also see a message from the driver indicating that it tried to
re-enable layer 1.
Quote:
> There's no way to keep the layer 1 up with the qozap driver.
> You really need your telco to disable it
Quote:
This is not correct. If layer 1 goes down, the HFC chips will signal
this and qozap will try to re-enable layer 1. Look at
bristuff-0.3.0-PRE-1y-q/qozap/qozap.c, line 1000 ff:
Quote:
if (l1state == 3) {
qoztmp->st[st].l1up = 0;
if (qoztmp->st[st].t3 > -1) {
/* keep layer1 up, if the span is started. */
if (qoztmp->spans[st].flags & ZT_FLAG_RUNNING) {
if (debug > 2)
printk("qozap: re-activating layer1 span %d\n", st);
qoz_outb(qoztmp,qoz_A_ST_WR_STA,0x60);
Posted: Thu May 29, 2008 11:17 am Post subject: [Bristuff-users] "Cause 34" on free channel
Hello Olivier,
No. It's hard to be noticed by Junghanns. Read my other post a few
minutes ago. I will try to contact Junghanns after find out some more
information regarding the bug.
Posted: Thu May 29, 2008 12:06 pm Post subject: [Bristuff-users] "Cause 34" on free channel
Quote:
Gunnar, are you still hit today, by these cause 34 issue ?
Sorry for my late answer. Yes I still have the "cause 34". But after
disabling power saving mode by the telco it works much better. Now
layer 1 is always active. We need to find the bug, see my other post
on that (reply to Henning Holtschneider).
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
