[asterisk-bugs] [LibPRI 0017361]: Q931 not sending RELEASE after getting DISCONNECT
Asterisk Bug Tracker
noreply at bugs.digium.com
Sun Jul 18 10:26:25 CDT 2010
A NOTE has been added to this issue.
======================================================================
https://issues.asterisk.org/view.php?id=17361
======================================================================
Reported By: ruffle
Assigned To:
======================================================================
Project: LibPRI
Issue ID: 17361
Category: General
Reproducibility: random
Severity: major
Priority: normal
Status: acknowledged
Asterisk Version: 1.4.31
JIRA: SWP-1681
libpri Version: I did not set the version. :(
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Disclaimer on File?: N/A
Request Review:
======================================================================
Date Submitted: 2010-05-19 08:25 CDT
Last Modified: 2010-07-18 10:26 CDT
======================================================================
Summary: Q931 not sending RELEASE after getting DISCONNECT
Description:
Several times per day, I'm getting Disconnection Cause Codes 102's
(recovery on timer expiry) which BT tell me are the result of Asterisk not
sending
a RELEASE in response to a DISCONNECT.
I'm seeing a handfuls of these in 'bursts' on a system making/taking
around 1500 calls per day and while the net result is that we loose a
channel for 30 seconds while it times out, these instances are visible to
the boss and I'm getting grief over them :-(
I've turned on pri debug and attached an example of one of these calls and
it does seem that BT are correct - there's no response sent to the
DISCONNECT
message and the exchange sends a RELEASE with a cause code of 102 some 30
seconds after the original DISCONNECT was sent.
Curiously the logger always seems to output the same strangeness for the
Cause data in these instances like so:-
[May 18 14:27:45] VERBOSE[4471] logger.c: < Protocol Discriminator: Q.931
(8) len=16
[May 18 14:27:45] VERBOSE[4471] logger.c: < Call Ref: len= 2 (reference
215/0xD7) (Originator)
[May 18 14:27:45] VERBOSE[4471] logger.c: < Message type: RELEASE (77)
[May 18 14:27:45] VERBOSE[4471] logger.c: < [08 02 80 90]
[May 18 14:27:45] VERBOSE[4471] logger.c: < Cause (len= 4) [ Ext: 1
Coding: CCITT (ITU) standard (0) Spare: 0 Location: User (0)
[May 18 14:27:45] VERBOSE[4471] logger.c: < Ext: 1
Cause: Normal Clearing (16), class = Normal Event (1) ]
[May 18 14:27:45] VERBOSE[4471] logger.c: < [08 05 82 e6 33 30 35]
[May 18 14:27:45] VERBOSE[4471] logger.c: < Cause (len= 7) [ Ext: 1
Coding: CCITT (ITU) standard (0) Spare: 0 Location: Public network
serving the local user (2)
[May 18 14:27:45] VERBOSE[4471] logger.c: < Ext: 1
Cause: Recover on timer expiry (102), class = Protocol Error (e.g. unknown
message) (6) ]
[May 18 14:27:45] VERBOSE[4471] logger.c: < Cause data:[May
18 14:27:45] VERBOSE[4471] logger.c: 33[May 18 14:27:45] VERBOSE[4471]
logger.c: 30[May 18 14:27:45] VERBOSE[4471] logger.c: 35[May 18 14:27:45]
VERBOSE[4471] logger.c: (Timer T[May 18 14:27:45] VERBOSE[4471] logger.c:
3[May 18 14:27:45] VERBOSE[4471] logger.c: 0[May 18 14:27:45] VERBOSE[4471]
logger.c: 5[May 18 14:27:45] VERBOSE[4471] logger.c: )
[May 18 14:27:45] VERBOSE[4471] logger.c: -- Processing IE 8 (cs0, Cause)
[May 18 14:27:45] VERBOSE[4471] logger.c: -- Processing IE 8 (cs0, Cause)
[May 18 14:27:45] VERBOSE[4471] logger.c: q931.c:3801 q931_receive: call
215 on channel 5 enters state 0 (Null)
[May 18 14:27:45] VERBOSE[4471] logger.c: -- Channel 0/5, span 1 got
hangup, cause 102
If it's any help, here's the timing of the instances this week (grep
'cause 102' /var/log/asterisk/full.X) so you can see the clumping:
Monday:
[May 17 09:41:38] VERBOSE[4472] logger.c: -- Channel 0/7, span 2 got
hangup, cause 102
[May 17 15:44:21] VERBOSE[4471] logger.c: -- Channel 0/5, span 1 got
hangup, cause 102
[May 17 15:44:26] VERBOSE[4471] logger.c: -- Channel 0/1, span 1 got
hangup, cause 102
[May 17 15:44:37] VERBOSE[4472] logger.c: -- Channel 0/4, span 2 got
hangup, cause 102
[May 17 15:46:11] VERBOSE[4472] logger.c: -- Channel 0/9, span 2 got
hangup, cause 102
[May 17 15:46:19] VERBOSE[4472] logger.c: -- Channel 0/3, span 2 got
hangup, cause 102
Tuesday:
[May 18 14:26:17] VERBOSE[4472] logger.c: -- Channel 0/7, span 2 got
hangup, cause 102
[May 18 14:26:24] VERBOSE[4472] logger.c: -- Channel 0/8, span 2 got
hangup, cause 102
[May 18 14:27:14] VERBOSE[4471] logger.c: -- Channel 0/6, span 1 got
hangup, cause 102
[May 18 14:27:45] VERBOSE[4471] logger.c: -- Channel 0/5, span 1 got
hangup, cause 102
Today (so far):
[May 19 11:03:27] VERBOSE[4472] logger.c: -- Channel 0/6, span 2 got
hangup, cause 102
[May 19 11:04:15] VERBOSE[4471] logger.c: -- Channel 0/2, span 1 got
hangup, cause 102
[May 19 11:04:23] VERBOSE[4472] logger.c: -- Channel 0/5, span 2 got
hangup, cause 102
[May 19 11:04:32] VERBOSE[4471] logger.c: -- Channel 0/3, span 1 got
hangup, cause 102
======================================================================
----------------------------------------------------------------------
(0124680) rsw686 (reporter) - 2010-07-18 10:26
https://issues.asterisk.org/view.php?id=17361#c124680
----------------------------------------------------------------------
I'm seeing this issue on Asterisk 1.6.1.18. The system handles around 3,500
calls per day. The hangup cause 102 happens a few times a week.
Issue History
Date Modified Username Field Change
======================================================================
2010-07-18 10:26 rsw686 Note Added: 0124680
======================================================================
More information about the asterisk-bugs
mailing list