asterisk users - Mar 2007 - DISCONNECT 41 hangup problem on PRI

Hey everyone,

we are using several TE410 cards in a production environment that are
connected to several operators PRI's and it works great..
For one of the operators we have seen some strange problems in cdr
mismatches however.

Our cdr's show phonecalls that are disconnected at a certain timelimit
while the operators cdr's show the user has disconnected a lot
earlier.
I thought asterisk maybe has some strange hangup bug that happens only
with this operator for some reason and i began delving into the isdn
frames to try and find an explanation:

When i do some intense debug logging i see that for normal calls that
are terminated fine at our side and for which the cdr's match
perfectly we have an isdn frame flow that goes like this :

< Message type: SETUP (5)
> Message type: CALL PROCEEDING (2)
> Message type: CONNECT (7)
< Message type: CONNECT ACKNOWLEDGE (15)
< Message type: DISCONNECT (69), Ext: 1  Cause: Normal Clearing (16),
class = Normal Event (1)
> Message type: RELEASE (77), Ext: 1  Cause: Normal Clearing (16), class =
Normal Event (1)
< Message type: RELEASE COMPLETE (90)


for the calls that mismatch in CDR and for which asterisk keeps on
going and does not trigger the hangup at the correct time we see :

< Message type: SETUP (5)
> Message type: CALL PROCEEDING (2)
> Message type: CONNECT (7)
< Message type: CONNECT ACKNOWLEDGE (15)
< Message type: DISCONNECT (69), Ext: 1  Cause: Temporary failure
(41), class = Network Congestion (resource unavailable) (2)
< Message type: RELEASE (77), Ext: 1  Cause: Temporary failure (41),
class = Network Congestion (resource unavailable) (2)
< Message type: RELEASE (77), Ext: 1  Cause: Temporary failure (41),
class = Network Congestion (resource unavailable) (2)
> Message type: RELEASE COMPLETE (90), Ext: 1  Cause: Temporary failure (41),
class = Network Congestion (resource unavailable) (2)
No hangup extension is triggered however until the global time limit
for the call we set is reached, and the call finishes eventually by
calling the T extension...
The CDR is not correct of course and does not match the time of the
"release complete" you see above.

It's very strange behavior because asterisk mentions the
-- Channel 0/22, span 1 got hangup request
-- Channel 0/22, span 1 got hangup
at the right time in the logs but the hangupextension is not triggered
until the global timelimit is reached...? Apparently this only happens
when DISCONNECT 41 is the hangupcause...

Why would asterisk send an ISDN RELEASE COMPLETE frame and then not
hangup the call ?

We are using asterisk 1.4.2 btw. I have also tried svn version of
asterisk and zaptel from yesterday. Makes no difference.
We tried setting autofallthrough both to yes and no and tried the same
setup on a TE412 card on a different server. Results for the
DISCONNECT 41 were the same however.


Any help or info greatly appreciated,

Tom