[asterisk-users] PRI line resetting on incoming call

[Samuel Nair]

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