Was'nt sure if this mail got through earlier:
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..?
Thanks
sam!!
