[Home]

Summary:ASTERISK-12111: [branch] when BRI span go down cannot make call
Reporter:Francesco Romano (francesco_r)Labels:
Date Opened:2008-05-29 12:16:54Date Closed:2011-06-07 14:08:10
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_zap
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
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
Comments:By: Francesco Romano (francesco_r) 2008-11-13 11:59:31.000-0600

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 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...


By: Francesco Romano (francesco_r) 2008-11-13 12:23:13.000-0600

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

span 1 and two 2 up but no cable are connected to the b410p. 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@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

Note: libpri is updated to 1.4.7 and this only happen in PtMP, with PtP all is ok.


By: Jason Parker (jparker) 2009-03-16 16:51:29

In ASTERISK-13176 francesco_r stated that this could be closed.  If this is incorrect, please reopen.