thr3ads.net - asterisk users - [asterisk-users] t200_expire: q921_state now is Q921_LINK_CONNECTION

If this information is useful, please help other people find it:
Share via:

Darshaka Pathirana

2010-Apr-10 10:32 UTC

[asterisk-users] t200_expire: q921_state now is Q921_LINK_CONNECTION_RELEASED

Hi everyone.

We have a problem here... Hope somebody can give us some hints.

We have a HP ProLiant DL180 G6 Server with a Debian/Lenny sytem.
Asterisk 1.4.21.2 (1.4.21.2~dfsg-3+lenny1) with zaptel (1.4.11) and
libpri (1.4.3) is installed.

There is a QuadBRI-Card installed:

# lspci -vv -s 06:04.0
06:04.0 ISDN controller: Cologne Chip Designs GmbH ISDN network Controller
[HFC-4S] (rev 01)
        Subsystem: Cologne Chip Designs GmbH Device b752
        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
        Interrupt: pin A routed to IRQ 30
        Region 0: I/O ports at cc00 [size=8]
        Region 1: Memory at fb6ff000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-


zttest gives me an average of 99.992% and zttool shows no alarms.

But every about 3,5 minutes we get this (with "debug span 1"
enababled):

1 -- Timeout occured, restarting PRI
1 q921.c:859 t200_expire: q921_state now is Q921_LINK_CONNECTION_RELEASED
1 Sending Set Asynchronous Balanced Mode Extended
1 q921.c:534 q921_send_sabme: q921_state now is Q921_AWAITING_ESTABLISH
  == Primary D-Channel on span 1 down
[Apr 10 12:16:05] WARNING[28541]: chan_zap.c:2498 pri_find_dchan: No D-channels
available!  Using Primary channel 3 as D-channel anyway!
1 Sending Set Asynchronous Balanced Mode Extended
1 -- Got UA from network peer  Link up.
1 -- Restarting T203 counter
  == Primary D-Channel on span 1 up

% cat /etc/zaptel.con

# Autogenerated by /usr/sbin/genzaptelconf -- do not hand edit
# Zaptel Configuration File
#
# This file is parsed by the Zaptel Configurator, ztcfg
#

# It must be in the module loading order


# Span 1: ztqoz/1/1 "quadBRI PCI ISDN Card 1 Span 1 [TE] (cardID 0)"
(MASTER)
span=1,1,3,ccs,ami
# termtype: te
bchan=1-2
dchan=3

# Span 2: ztqoz/1/2 "quadBRI PCI ISDN Card 1 Span 2 [TE] (cardID 0)" 
span=2,2,0,ccs,ami
# termtype: te
bchan=4-5
dchan=6

# Span 3: ztqoz/1/3 "quadBRI PCI ISDN Card 1 Span 3 [TE] (cardID 0)" 
span=3,3,0,ccs,ami
# termtype: te
bchan=7-8
dchan=9

# Span 4: ztqoz/1/4 "quadBRI PCI ISDN Card 1 Span 4 [TE] (cardID 0)" 
span=4,4,0,ccs,ami
# termtype: te
bchan=10-11
dchan=12

# Global data

loadzone        = at
defaultzone     = at

% cat /etc/asterisk/zapata.conf
[channels]
  language=de
  switchtype=euroisdn
  pridialplan=unknown
  prilocaldialplan=dynamic
  priindication=passthrough
  context=incoming
  immediate=no
  usecallingpres=yes
  usecallerid=yes
  group=1
  nationalprefix=00
  internationalprefix=000

signalling=bri_cpe
echocancel=Yes
overlapdial=Yes

; group=2
; signalling=bri_cpe
; context=incoming
; channel => 10-11
; 

channel => 1-2
; channel => 4-5
; channel => 7-8
; channel => 10-11


(Only one span is connected to ISDN right now.)

qozap is loaded and ztcfg -v gives me:

Zaptel Version: 1.4.11
Echo Canceller: MG2
Configuration
=====================
SPAN 1: CCS/ AMI Build-out: 399-533 feet (DSX-1)
SPAN 2: CCS/ AMI Build-out: 0 db (CSU)/0-133 feet (DSX-1)
SPAN 3: CCS/ AMI Build-out: 0 db (CSU)/0-133 feet (DSX-1)
SPAN 4: CCS/ AMI Build-out: 0 db (CSU)/0-133 feet (DSX-1)

12 channels to configure.

Any idea what this could mean and how this could be fixed? Any help
would be helpful. Thx.

Greetings,
 - Darsha

Darshaka Pathirana

2010-Apr-10 12:34 UTC

head link

[asterisk-users] t200_expire: q921_state now is Q921_LINK_CONNECTION_RELEASED

Hi!

On 04/10/2010 02:04 PM, Tzafrir Cohen wrote:> On Sat, Apr 10, 2010 at 12:32:49PM +0200, Darshaka Pathirana wrote:
>>
>> We have a problem here... Hope somebody can give us some hints.
>>
>> We have a HP ProLiant DL180 G6 Server with a Debian/Lenny sytem.
>> Asterisk 1.4.21.2 (1.4.21.2~dfsg-3+lenny1) with zaptel (1.4.11) and
>> libpri (1.4.3) is installed.
> 
> Sadly those packages diverge from the mainline Asterisk in one important
> aspect: they use the bristuff patch in both asterisk and libpri.
Hmm. Yes I know. Why sadly? Anything bad about it?  We need some
features which are missing without bristuff. I also thought "qozap"
needs a bristuffed Asterisk/libpri...
> Do you need NT PtMP support (It doesn't look that way from your
> system)? If not, I wonder if you would consider a backport of latest
> Squeeze packages, which I maintain:
> 
> http://updates.xorcom.com/pkg-voip/
Indeed this setup just needs PtP. Is PtMP not supported in Asterisk
1.6?

Greetings,
 - Darsha

Matthew Fredrickson

2010-Apr-13 11:32 UTC

head link

[asterisk-users] t200_expire: q921_state now is Q921_LINK_CONNECTION_RELEASED

This is not actually a problem... it's a side affect of how older 
versions of libpri handled PTMP links.  Basically, after 3-5 minutes, 
the other side is probably trying to drop layers 1 and 2 due to no calls 
being active.  For the most part, unless you see any issues, you should 
just ignore the message.  This is just libpri re-establishing layer when 
the other side tries to drop it, due to its desire to have the 
perception of a persistent layer 2 (in older versions).

In newer libpri (1.4 branch) it allows layer 2 to drop and stay dropped 
until it is needed by layer 3.

Matthew Fredrickson
Digium, Inc.


Darshaka Pathirana wrote:> Hi everyone.
> 
> We have a problem here... Hope somebody can give us some hints.
> 
> We have a HP ProLiant DL180 G6 Server with a Debian/Lenny sytem.
> Asterisk 1.4.21.2 (1.4.21.2~dfsg-3+lenny1) with zaptel (1.4.11) and
> libpri (1.4.3) is installed.
> 
> There is a QuadBRI-Card installed:
> 
> # lspci -vv -s 06:04.0
> 06:04.0 ISDN controller: Cologne Chip Designs GmbH ISDN network Controller
[HFC-4S] (rev 01)
>         Subsystem: Cologne Chip Designs GmbH Device b752
>         Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
>         Interrupt: pin A routed to IRQ 30
>         Region 0: I/O ports at cc00 [size=8]
>         Region 1: Memory at fb6ff000 (32-bit, non-prefetchable) [size=4K]
>         Capabilities: [40] Power Management version 2
>                 Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold-)
>                 Status: D0 PME-Enable- DSel=0 DScale=0 PME-
> 
> 
> zttest gives me an average of 99.992% and zttool shows no alarms.
> 
> But every about 3,5 minutes we get this (with "debug span 1"
enababled):
> 
> 1 -- Timeout occured, restarting PRI
> 1 q921.c:859 t200_expire: q921_state now is Q921_LINK_CONNECTION_RELEASED
> 1 Sending Set Asynchronous Balanced Mode Extended
> 1 q921.c:534 q921_send_sabme: q921_state now is Q921_AWAITING_ESTABLISH
>   == Primary D-Channel on span 1 down
> [Apr 10 12:16:05] WARNING[28541]: chan_zap.c:2498 pri_find_dchan: No
D-channels available!  Using Primary channel 3 as D-channel anyway!
> 1 Sending Set Asynchronous Balanced Mode Extended
> 1 -- Got UA from network peer  Link up.
> 1 -- Restarting T203 counter
>   == Primary D-Channel on span 1 up
> 
> % cat /etc/zaptel.con
> 
> # Autogenerated by /usr/sbin/genzaptelconf -- do not hand edit
> # Zaptel Configuration File
> #
> # This file is parsed by the Zaptel Configurator, ztcfg
> #
> 
> # It must be in the module loading order
> 
> 
> # Span 1: ztqoz/1/1 "quadBRI PCI ISDN Card 1 Span 1 [TE] (cardID
0)" (MASTER)
> span=1,1,3,ccs,ami
> # termtype: te
> bchan=1-2
> dchan=3
> 
> # Span 2: ztqoz/1/2 "quadBRI PCI ISDN Card 1 Span 2 [TE] (cardID
0)"
> span=2,2,0,ccs,ami
> # termtype: te
> bchan=4-5
> dchan=6
> 
> # Span 3: ztqoz/1/3 "quadBRI PCI ISDN Card 1 Span 3 [TE] (cardID
0)"
> span=3,3,0,ccs,ami
> # termtype: te
> bchan=7-8
> dchan=9
> 
> # Span 4: ztqoz/1/4 "quadBRI PCI ISDN Card 1 Span 4 [TE] (cardID
0)"
> span=4,4,0,ccs,ami
> # termtype: te
> bchan=10-11
> dchan=12
> 
> # Global data
> 
> loadzone        = at
> defaultzone     = at
> 
> % cat /etc/asterisk/zapata.conf
> [channels]
>   language=de
>   switchtype=euroisdn
>   pridialplan=unknown
>   prilocaldialplan=dynamic
>   priindication=passthrough
>   context=incoming
>   immediate=no
>   usecallingpres=yes
>   usecallerid=yes
>   group=1
>   nationalprefix=00
>   internationalprefix=000
> 
> signalling=bri_cpe
> echocancel=Yes
> overlapdial=Yes
> 
> ; group=2
> ; signalling=bri_cpe
> ; context=incoming
> ; channel => 10-11
> ; 
> 
> channel => 1-2
> ; channel => 4-5
> ; channel => 7-8
> ; channel => 10-11
> 
> 
> (Only one span is connected to ISDN right now.)
> 
> qozap is loaded and ztcfg -v gives me:
> 
> Zaptel Version: 1.4.11
> Echo Canceller: MG2
> Configuration
> =====================> 
> SPAN 1: CCS/ AMI Build-out: 399-533 feet (DSX-1)
> SPAN 2: CCS/ AMI Build-out: 0 db (CSU)/0-133 feet (DSX-1)
> SPAN 3: CCS/ AMI Build-out: 0 db (CSU)/0-133 feet (DSX-1)
> SPAN 4: CCS/ AMI Build-out: 0 db (CSU)/0-133 feet (DSX-1)
> 
> 12 channels to configure.
> 
> Any idea what this could mean and how this could be fixed? Any help
> would be helpful. Thx.
> 
> Greetings,
>  - Darsha
> 
>

Possibly Parallel Threads

Search for more apparently analagous threads

asterisk users - Apr 2010 - t200_expire: q921_state now is Q921_LINK_CONNECTION_RELEASED

[asterisk-users] t200_expire: q921_state now is Q921_LINK_CONNECTION_RELEASED

[asterisk-users] t200_expire: q921_state now is Q921_LINK_CONNECTION_RELEASED

[asterisk-users] t200_expire: q921_state now is Q921_LINK_CONNECTION_RELEASED

Possibly Parallel Threads