PRI line resetting on incoming call

I have been having a weird issue with my telco’s ISDN PRI occasionally resetting on a incoming call, i suspect it to possibly be a timing issue since some of the incoming call work. This problem happens very frequently.

I am using asterisk-1.6.0.1 with libpri-1.4.9, the asterisk server is connected viw TDMoE to a Redfone Fonebridge into which my telco’s ISDN PRI line is connected. I have used the exact same setup in another office and it worked seamlessly.

After setting it up, i would notice every couple of minutes the entire line would reset usually timed with a incoming call, i tried getting help from my telco, but they were completely incompetent. Before deploying the asterisk solution the PRI was hooked up to an hardware PBX, and the line worked fine, even now when i hook it up to the hardware pbx is works great, but when connected to the asterisk server we start to see these disconnects.

Following are some of the pertinent sections of my chan_dadhi & dahdi/system.conf:

dahdi/system.conf

# spans
dynamic=ethmf,eth1/00:50:C2:65:D6:54/0,31,2
dynamic=ethmf,eth1/00:50:C2:65:D6:54/1,31,1

# Channels
bchan=1-15,17-31
dchan=16
bchan=32-46,48-62
dchan=47

alaw=1-62

# Tonezone
loadzone=in
defaultzone=in

chan_dahdi.conf


[channels]
pridialplan=unknown
overlapdial=yes
usecallerid=yes
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=no

group=1
callgroup=1
pickupgroup=1

group=2
context=autoatt
switchtype=national
signalling=pri_cpe
musiconhold=default
channel=1-15,17-31
useincomingcalleridondahditransfer = yes

group=3
context=hardpbx
switchtype=euroisdn
signalling=pri_net
musiconhold=default
channel=32-46,48-62
useincomingcalleridondahditransfer = yes

I began to look at the ISDN debug output to try and determine what was causing the line to reset. After a few days of pouring over the output i noticed a pattern:

< [ 02 01 14 16 08 02 06 1e 4d ]

< Informational frame:
< SAPI: 00  C/R: 1 EA: 0
<  TEI: 000        EA: 1
< N(S): 010   0: 0
< N(R): 011   P: 0
< 5 bytes of data
Handling message for SAPI/TEI=0/0
-- ACKing all packets from 10 to (but not including) 11
-- Since there was nothing left, stopping T200 counter
-- Stopping T203 counter since we got an ACK
-- Nothing left, starting T203 counter
< Protocol Discriminator: Q.931 (8)  len=5
< Call Ref: len= 2 (reference 1566/0x61E) (Originator)
< Message type: RELEASE (77)
-- Making new call for cr 1566

> [ 00 01 16 16 08 02 86 1e 5a 08 02 81 d1 ]

> Informational frame:
> SAPI: 00  C/R: 0 EA: 0
>  TEI: 000        EA: 1
> N(S): 011   0: 0
> N(R): 011   P: 0
> 9 bytes of data
Stopping T_203 timer
Starting T_200 timer
-- Restarting T200 timer
> Protocol Discriminator: Q.931 (8)  len=9
> Call Ref: len= 2 (reference 1566/0x61E) (Terminator)
> Message type: RELEASE COMPLETE (90)
> [08 02 81 d1]
> Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0  Location: Private network serving the local user (1)
>                  Ext: 1  Cause: Invalid call reference value (81), class = Invalid message (e.g. parameter out of range) (5) ]
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null
NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null
-- Restarting T203 timer

< [ 00 01 01 18 ]

< Supervisory frame:
< SAPI: 00  C/R: 0 EA: 0
<  TEI: 000        EA: 1
< Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
< N(R): 012 P/F: 0
< 0 bytes of data
Handling message for SAPI/TEI=0/0
-- ACKing all packets from 10 to (but not including) 12
-- ACKing packet 11, new txqueue is -1 (-1 means empty)
-- Since there was nothing left, stopping T200 counter
-- Stopping T203 counter since we got an ACK
-- Nothing left, starting T203 counter
-- Restarting T203 timer
q921.c:842 q921_reset: q921_state now is Q921_LINK_CONNECTION_RELEASED

I would see the RELEASE message, and then a ‘Making new call’ indication following which i would see a RELEASE COMPLETE message with ’ Invalid call reference value’ and then the line resets. Any idea why this would happen…?