asterisk users - Apr 2009 - Cause 34 still there

My comment, (forwarded from Bristuff list) - A few people are seeing a
Cause 34 (congestion) from ISDN installs, where there clearly is an
available channel. This was originally related to Bristuff as it
happens to ISDN2 users, but there is at least one report of an
unpatched 1.6.x user seeing the same issue.

2009/4/23 Steve Davies <davies147 at gmail.com>:
> I think I have a site where this is happening, but all I see is a
> series of outbound calls, which look perfectly normal, but at some
> "random" point, ISDN channels stop being available, until they
run
> out. It can go anywhere from weeks down to a couple of hours before
> failing, which makes it even more mystifying.
>
> This site it unique (to us) in that it is in Ireland, and not mainland
> UK - We do not believe we see the problem anywhere else, so it could
> perhaps be encouraged by a local telco setting - I'll feed back if I
> discover any more info.
Replying to myself - I am seeing the following coming from the telco:

2 Sending Receiver Ready (5)
2
> [ 02 01 01 0a ]
2
> Supervisory frame:
2 > SAPI: 00  C/R: 1 EA: 0
>  TEI: 000        EA: 1
2 > Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
> N(R): 005 P/F: 0
> 0 bytes of data
2 -- Restarting T203 counter
2 -- Restarting T203 counter
    -- Channel 0/2, span 2 received AOC-E charging 0 units
2 bx*CLI>
< [ 02 01 53 ]
2
< Unnumbered frame:
2 < SAPI: 00  C/R: 1 EA: 0
<  TEI: 000        EA: 1
2 <   M3: 2   P/F: 1 M2: 0 11: 3  [ DISC (disconnect) ]
< 0 bytes of data
2 -- Got Disconnect from peer.
2 Sending Unnumbered Acknowledgement
2
> [ 02 01 73 ]
2
> Unnumbered frame:
2 > SAPI: 00  C/R: 1 EA: 0
>  TEI: 000        EA: 1
2 >   M3: 3   P/F: 1 M2: 0 11: 3  [ UA (unnumbered acknowledgement)
]
> 0 bytes of data
2 -- Restarting T203 counter
2 T203 counter expired in weird state 0
1 bx*CLI>
< [ fe ff 03 0f 00 00 04 ff ]
1
< Unnumbered frame:
1 < SAPI: 63  C/R: 1 EA: 0
<  TEI: 127        EA: 1
1 <   M3: 0   P/F: 0 M2: 0 11: 3  [ UI (unnumbered information) ]
< 5 bytes of data
2 bx*CLI>
< [ fe ff 03 0f 00 00 04 ff ]
2
< Unnumbered frame:
2 < SAPI: 63  C/R: 1 EA: 0
<  TEI: 127        EA: 1
2 <   M3: 0   P/F: 0 M2: 0 11: 3  [ UI (unnumbered information) ]
< 5 bytes of data


The "DISC" is a disconnect that we get from the remote end - Might
this be a timeout of some kind? We never recover the line once that
happens. Is that right? Is this a mode that is not supported by
Asterisk perhaps? Is there some "wakeup" handshake that can occur when
a "DISC" is received?

Thanks for any insight.

Regards,
Steve

2009/4/23 Steve Davies <davies147 at gmail.com>:
> My comment, (forwarded from Bristuff list) - A few people are seeing a
> Cause 34 (congestion) from ISDN installs, where there clearly is an
> available channel. This was originally related to Bristuff as it
> happens to ISDN2 users, but there is at least one report of an
> unpatched 1.6.x user seeing the same issue.
>
[snip]

Something I just found, which others might want to consider trying if
they get cause 34 issues is uncommenting the following line in
libpri's Makefile:

#LAYER2ALWAYSUP=-DLAYER2ALWAYSUP

This (in theory anyway) simply causes libpri to attempt to
re-negotiate L2 if the far end closes it down with a 'DISC'.

Regards,
Steve