[asterisk-bugs] [Asterisk 0012757]: [branch] when BRI span go down cannot make call
Asterisk Bug Tracker
noreply at bugs.digium.com
Thu Nov 13 11:59:31 CST 2008
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=12757
======================================================================
Reported By: francesco_r
Assigned To: mattf
======================================================================
Project: Asterisk
Issue ID: 12757
Category: Channels/chan_zap
Reproducibility: always
Severity: minor
Priority: normal
Status: assigned
Asterisk Version: 1.6.0-beta8
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Disclaimer on File?: N/A
Request Review:
======================================================================
Date Submitted: 2008-05-29 12:16 CDT
Last Modified: 2008-11-13 11:59 CST
======================================================================
Summary: [branch] when BRI span go down cannot make call
Description:
I have installed Asterisk 1.6beta9 with libpri 1.4.4 and zaptel 1.4.10.1.
I know that BRI support is in alpha stage but i wanted to test because we
european users of asterisk we were "disregarded" until now :)
Misdn works, but not very well. The biggest problem is the echo, also with
hardware echo cancellation card like Digium B410P there are some calls with
echo, perhaps because chan_misdn has internal additional delay (see
http://peter.schlaile.de/mISDN/). The other problem is that the driver of
the cards based on the HFC-multi chipset hang on some circumstances, when
there are poor quality lines, and a reboot is needed (if you unload the
driver the kernel crash...).
I have installed and configured the unofficial qozap driver for Digium
B410P available from
http://svn.digium.com/view/zaptel/team/mattf/bri-related/
I have to say, in preliminar testings, that zaptel and bri works well. No
echo or stability problems occured, comparing the same hardware using
misdn. For now i have only one little problem that have affected for years
the users of bristuffed asterisk...
In Italy, but i think in the whole world, the provider put down the layer
1 very often in BRI lines, but fortunately the qozap driver try to put the
layer 1 up. So i have thousands of this messages in the console:
Primary D-Channel on span 1 down
Primary D-Channel on span 1 up
The span go down for 2 secs circa.
But if someone make a call in the exact moment when the span is down
asterisk correctly fails to call: "Everyone is busy/congested at this time
(1:0/1/0)"
This is an ouput of pri debug:
-- Got Disconnect from peer.
Sending Unnumbered Acknowledgement
q921.c:777 q921_reset: q921_state now is Q921_LINK_CONNECTION_RELEASED
== Primary D-Channel on span 1 down
q921.c:777 q921_reset: q921_state now is Q921_LINK_CONNECTION_RELEASED
Sending TEI management message 1, TEI=127
q921.c:777 q921_reset: q921_state now is Q921_LINK_CONNECTION_RELEASED
Sending TEI management message 1, TEI=127
Sending Set Asynchronous Balanced Mode Extended
q921.c:206 q921_send_sabme: q921_state now is Q921_AWAITING_ESTABLISH
-- Got UA from network peer Link up.
q921.c:777 q921_reset: q921_state now is Q921_LINK_CONNECTION_RELEASED
q921.c:728 q921_dchannel_up: q921_state now is
Q921_LINK_CONNECTION_ESTABLISHED
== Primary D-Channel on span 1 up
q921.c:777 q921_reset: q921_state now is Q921_LINK_CONNECTION_RELEASED
Sending TEI management message 1, TEI=127
This is my Zaptel.conf:
loadzone=it
defaultzone=it
span=1,1,3,ccs,ami
bchan=1-2
dchan=3
span=2,0,3,ccs,ami
bchan=4-5
dchan=6
span=3,0,3,ccs,ami
bchan=7-8
dchan=9
span=4,0,3,ccs,ami
bchan=10-11
dchan=12
And this is zapata.conf
[channels]
language = it
switchtype = euroisdn
signalling = bri_cpe_ptmp
pridialplan = dynamic
prilocaldialplan = local
nationalprefix = 0
internationalprefix = 00
overlapdial = yes
priindication = passthrough
echocancel=yes
echocancelwhenbridged=no
group = 0
context=from-zaptel
channel => 1-2,4-5,7-8,10-11
So i think that perhaps is necessary to reduce the time of this down
interval or, better, force asterisk to put the layer 1 up so the call can
proceed. Misdn in misdn.conf has the option that solve this situation
"pmp_l1_check=no".
Thank you
Francesco
======================================================================
----------------------------------------------------------------------
(0094850) francesco_r (reporter) - 2008-11-13 11:59
http://bugs.digium.com/view.php?id=12757#c94850
----------------------------------------------------------------------
I have retested with the new DAHDI 2.1.0-rc3/Asterisk 1.6.1 r156547 and
driver wcb4xxp but this bug it's still, i have tons of
== Primary D-Channel on span 2 down
== Primary D-Channel on span 2 up
in PTMP configuration.
I have also found another problem in but now i'm unable to reproduce. I
have disconnected the cable during a call and reconnected to another port,
the call was correctly disconnected but the span remained up forever. When
i reconnected the cable to this port i was unable to call (congestion). So
i did a an incoming test call that regularly arrived but hanguped after a
few seconds of ringing. I recalled and answered immediately, the channels
remained open but there was no audio. Instead the other 3 ports of the card
continued to work regularly. To restore the port i was forced to restart
asterisk. Notice that this problem is very old, present from long time in
bristuff versions of asterisk; i have encountered many times in these years
with the quad-bri cards from junghanns and beronet. But with bristuff/qozap
couple every time happened i was forced to reboot the machines because if i
simply restarted asterisk the problem did not solve, and if i unloaded the
module there was often a kernel panic...
Issue History
Date Modified Username Field Change
======================================================================
2008-11-13 11:59 francesco_r Note Added: 0094850
======================================================================
More information about the asterisk-bugs
mailing list