Posted: Mon Dec 03, 2007 4:58 pm Post subject: [Bristuff-users] Problem
Hello again,
I have a small problem using bristuff-0.4.0-test4-xr3 on Asterisk 1.4.13
and zaptel 1.4.6, with a phonicEQ four port BRI card (qozap driver)
plugged in Spanish RDSI lines (ISDN).
I more or less randomly (sometimes 3 times a day, sometimes once per
week) get messages like these on a span (usually with span 1 or 3, that
are more used, but it sometimes happens with others as well):
[Dec 3 15:49:06] VERBOSE[8677] logger.c: == Primary D-Channel on span
1 down
When I try to make a call through the "downed" span, I get this, which
sound kind of logical when a span is down:
[Dec 3 15:53:40] WARNING[14889] app_dial.c: Unable to create channel of
type 'ZAP' (cause 34 - Circuit/channel congestion)
Meanwhile, I still get incoming calls from that span!!, and I can still
make calls to other spans without problems. Restarting Asterisk (no need
to reload qozap) makes everything work again, until next time....
I tried the intensive debug, which showed me some timeouts at those
moments on t203 and/or t200 timers, restarting the span without success.
The only weird thing was a window value of "-1/7" on "pri show span",
while the other spans have "0/7":
*CLI> pri show span 1
Primary D-channel: 3
Status: Provisioned, Up, Active
Switchtype: EuroISDN
Type: CPE
Window Length: -1/7
Sentrej: 0
SolicitFbit: 0
Retrans: 0
Busy: 0
Overlap Dial: -1
T200 Timer: 1000
T203 Timer: 10000
T305 Timer: 30000
T308 Timer: 4000
T309 Timer: -1
T313 Timer: 4000
N200 Counter: 3
I really don't know what's happening (actually, I don't even know what a
"Window Length" is...), but I could use some help to find a cure or at
least some workaround (right know, if HANGUPCAUSE is 34 I just "restart
when convenient"....).
Posted: Mon Dec 03, 2007 5:18 pm Post subject: [Bristuff-users] Problem
On Mon, Dec 03, 2007 at 05:49:18PM +0100, François Delawarde wrote:
Quote:
Hello again,
I have a small problem using bristuff-0.4.0-test4-xr3 on Asterisk 1.4.13
and zaptel 1.4.6, with a phonicEQ four port BRI card (qozap driver)
plugged in Spanish RDSI lines (ISDN).
I more or less randomly (sometimes 3 times a day, sometimes once per
week) get messages like these on a span (usually with span 1 or 3, that
are more used, but it sometimes happens with others as well):
[Dec 3 15:49:06] VERBOSE[8677] logger.c: == Primary D-Channel on span
1 down
You use PtP rather than PtMP signalling. Bristuff's chan_zap does not
supress that message for ptp spans. Not sure why. Having the span down
most of the time is common with many BRI providers. Maybe also when
ptp is used.
Quote:
When I try to make a call through the "downed" span, I get this, which
sound kind of logical when a span is down:
[Dec 3 15:53:40] WARNING[14889] app_dial.c: Unable to create channel of
type 'ZAP' (cause 34 - Circuit/channel congestion)
Meanwhile, I still get incoming calls from that span!!,
When calls come in, is the span temporarily up?
Seems so from the information below.
One very silly guess: try having 'pridialplan=unknown' in zapata.conf .
Or perperly set up internationalprefix, nationalprefix, etc. This is
something that can cause outgoing calls to fail.
Quote:
and I can still
make calls to other spans without problems. Restarting Asterisk (no need
to reload qozap) makes everything work again, until next time....
I tried the intensive debug, which showed me some timeouts at those
moments on t203 and/or t200 timers, restarting the span without success.
The only weird thing was a window value of "-1/7" on "pri show span",
while the other spans have "0/7":
*CLI> pri show span 1
Primary D-channel: 3
Status: Provisioned, Up, Active
Switchtype: EuroISDN
Type: CPE
Window Length: -1/7
Sentrej: 0
SolicitFbit: 0
Retrans: 0
Busy: 0
Overlap Dial: -1
T200 Timer: 1000
T203 Timer: 10000
T305 Timer: 30000
T308 Timer: 4000
T309 Timer: -1
T313 Timer: 4000
N200 Counter: 3
I really don't know what's happening (actually, I don't even know what a
"Window Length" is...), but I could use some help to find a cure or at
least some workaround (right know, if HANGUPCAUSE is 34 I just "restart
when convenient"....).
Posted: Mon Dec 03, 2007 6:29 pm Post subject: [Bristuff-users] Problem
Hello Tzafrir, and thanks for rapid answer.
Tzafrir Cohen wrote:
Quote:
On Mon, Dec 03, 2007 at 05:49:18PM +0100, François Delawarde wrote:
> Hello again,
>
> I have a small problem using bristuff-0.4.0-test4-xr3 on Asterisk 1.4.13
> and zaptel 1.4.6, with a phonicEQ four port BRI card (qozap driver)
> plugged in Spanish RDSI lines (ISDN).
>
> I more or less randomly (sometimes 3 times a day, sometimes once per
> week) get messages like these on a span (usually with span 1 or 3, that
> are more used, but it sometimes happens with others as well):
> [Dec 3 15:49:06] VERBOSE[8677] logger.c: == Primary D-Channel on span
> 1 down
>
You use PtP rather than PtMP signalling. Bristuff's chan_zap does not
supress that message for ptp spans. Not sure why. Having the span down
most of the time is common with many BRI providers. Maybe also when
ptp is used.
Thanks for suggestion, I had signalling=bri_cpe, and changed it to
signalling=bri_cpe_ptmp, I'll check if it works better.
Quote:
> When I try to make a call through the "downed" span, I get this, which
> sound kind of logical when a span is down:
> [Dec 3 15:53:40] WARNING[14889] app_dial.c: Unable to create channel of
> type 'ZAP' (cause 34 - Circuit/channel congestion)
>
> Meanwhile, I still get incoming calls from that span!!,
>
When calls come in, is the span temporarily up?
All I know is that at some point the span was showing Up again in "pri
show spans" (at least until I restarted), but the problem was not
disappearing (I only had incoming calls from the span). The server is in
production, so lots of calls and it might perfectly be that there were
incoming calls every time I checked that.
Quote:
Seems so from the information below.
One very silly guess: try having 'pridialplan=unknown' in zapata.conf .
Or perperly set up internationalprefix, nationalprefix, etc. This is
something that can cause outgoing calls to fail.
I have pridialplan=local, nationalprefix=0 and internationalprefix=00,
and it worked so far. I will test changing those after checking if
changing signalling to ptmp works or not.
Quote:
> and I can still
> make calls to other spans without problems. Restarting Asterisk (no need
> to reload qozap) makes everything work again, until next time....
>
> I tried the intensive debug, which showed me some timeouts at those
> moments on t203 and/or t200 timers, restarting the span without success.
> The only weird thing was a window value of "-1/7" on "pri show span",
> while the other spans have "0/7":
> *CLI> pri show span 1
> Primary D-channel: 3
> Status: Provisioned, Up, Active
> Switchtype: EuroISDN
> Type: CPE
> Window Length: -1/7
> Sentrej: 0
> SolicitFbit: 0
> Retrans: 0
> Busy: 0
> Overlap Dial: -1
> T200 Timer: 1000
> T203 Timer: 10000
> T305 Timer: 30000
> T308 Timer: 4000
> T309 Timer: -1
> T313 Timer: 4000
> N200 Counter: 3
>
> I really don't know what's happening (actually, I don't even know what a
> "Window Length" is...), but I could use some help to find a cure or at
> least some workaround (right know, if HANGUPCAUSE is 34 I just "restart
> when convenient"....).
>
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
