[asterisk-bugs] [Asterisk 0012757]: [branch] when BRI span go down cannot make call
Asterisk Bug Tracker
noreply at bugs.digium.com
Thu Nov 13 12:23:13 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 12:23 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
======================================================================
----------------------------------------------------------------------
(0094853) francesco_r (reporter) - 2008-11-13 12:23
http://bugs.digium.com/view.php?id=12757#c94853
----------------------------------------------------------------------
I have reproduced the problem. As you can see in this output:
PRI span 1/0: Provisioned, In Alarm, Up, Active
PRI span 2/0: Provisioned, In Alarm, Up, Active
PRI span 3/0: Provisioned, In Alarm, Down, Active
PRI span 4/0: Provisioned, In Alarm, Down, Active
But no cable are connected to the b410p but span 1 and two are up. If
reconnect the cable i can't dial in these ports. If i do an incoming call i
can answer but no audio (wrong b-channel?):
-- Executing [s at macro-dial:7] Dial("DAHDI/1-1", "SIP/509,,tk") in new
stack
== Using SIP RTP TOS bits 184
== Using SIP RTP CoS mark 5
== Using SIP VRTP TOS bits 136
== Using SIP VRTP CoS mark 6
-- Called 509
== Extension Changed 509[ext-local] new state Ringing for Notify User
509
-- SIP/509-084d45c8 is ringing
q931.c:2802 q931_alerting: call 76 on channel 1 enters state 7 (Call
Received)
T_200 timer already going (1)
> Protocol Discriminator: Q.931 (8) len=8
> Call Ref: len= 1 (reference 76/0x4C) (Terminator)
> Message type: ALERTING (1)
> [1e 02 81 88]
> Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0)
0: 0 Location: Private network serving the local user (1)
> Ext: 1 Progress Description: Inband
information or appropriate pattern now available. (8) ]
-- SIP/509-084d45c8 answered DAHDI/1-1
q931.c:2909 q931_connect: call 76 on channel 1 enters state 8 (Connect
Request)
T_200 timer already going (1)
> Protocol Discriminator: Q.931 (8) len=11
> Call Ref: len= 1 (reference 76/0x4C) (Terminator)
> Message type: CONNECT (7)
> [18 01 89]
> Channel ID (len= 3) [ Ext: 1 IntID: Implicit Other Spare: 0
Exclusive Dchan: 0
> ChanSel: B1 channel
]
> [1e 02 81 82]
> Progress Indicator (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0)
0: 0 Location: Private network serving the local user (1)
> Ext: 1 Progress Description: Called
equipment is non-ISDN. (2) ]
== Extension Changed 509[ext-local] new state InUse for Notify User 509
Timed out looking for connect acknowledge
q931.c:2973 q931_disconnect: call 76 on channel 1 enters state 11
(Disconnect Request)
T_200 timer already going (1)
> Protocol Discriminator: Q.931 (8) len=8
> Call Ref: len= 1 (reference 76/0x4C) (Terminator)
> Message type: DISCONNECT (69)
> [08 02 81 90]
> Cause (len= 4) [ Ext: 1 Coding: CCITT (ITU) standard (0) Spare: 0
Location: Private network serving the local user (1)
> Ext: 1 Cause: Normal Clearing (16), class = Normal
Event (1) ]
pbx*CLI>
< [ 00 c3 01 03 ]
pbx*CLI>
< Supervisory frame:
< SAPI: 00 C/R: 0 EA: 0
< TEI: 097 EA: 1
< Zero: 0 S: 0 01: 1 [ RR (receive ready) ]
< N(R): 001 P/F: 1
< 0 bytes of data
pbx*CLI>
< [ 00 c5 01 03 ]
pbx*CLI>
< Supervisory frame:
< SAPI: 00 C/R: 0 EA: 0
< TEI: 098 EA: 1
< Zero: 0 S: 0 01: 1 [ RR (receive ready) ]
< N(R): 001 P/F: 1
< 0 bytes of data
Notice: this only happen in PtMP, with PtP is ok.
Issue History
Date Modified Username Field Change
======================================================================
2008-11-13 12:23 francesco_r Note Added: 0094853
======================================================================
More information about the asterisk-bugs
mailing list