[asterisk-bugs] [LibPRI 0017360]: [patch] LibPRI problem with restart of PBX processor (Testing SVN 1688)
Asterisk Bug Tracker
noreply at bugs.digium.com
Tue Aug 31 17:51:04 CDT 2010
A NOTE has been added to this issue.
======================================================================
https://issues.asterisk.org/view.php?id=17360
======================================================================
Reported By: shawkris
Assigned To: rmudgett
======================================================================
Project: LibPRI
Issue ID: 17360
Category: General
Reproducibility: have not tried
Severity: minor
Priority: normal
Status: assigned
Asterisk Version: 1.4.30
JIRA: SWP-1680
libpri Version: I did not set the version. :(
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!): 1688
Disclaimer on File?: N/A
Request Review:
======================================================================
Date Submitted: 2010-05-19 07:57 CDT
Last Modified: 2010-08-31 17:51 CDT
======================================================================
Summary: [patch] LibPRI problem with restart of PBX processor
(Testing SVN 1688)
Description:
Asterisk is connected to legacy Siemens PBX. PBX has dual CPU and switches
over active/passive processors at (or close to) 00:00.
During the switchover, the link stays up but the PBX sends SABME. Asterisk
should clear state to restart q921. A few seconds after the first call
comes in, we see the legacy PBX drops the link and tries to re-establish -
it normally does this after a protocol error (timer expiry etc).
I will try and reproduce with pri debugging enabled.
======================================================================
----------------------------------------------------------------------
(0126514) rmudgett (administrator) - 2010-08-31 17:51
https://issues.asterisk.org/view.php?id=17360#c126514
----------------------------------------------------------------------
I did not see anything in the log indicating why the PBX dropped the link.
However, it might have been because Q.921 passed i-frames to Q.931 before
Q.921 was finished handling the frame's state variables. The only thing
that I think would be a protocol error because of the incomplete Q.921
frame processing is the P/F bit may be incorrect. The patch also delays
passing i-frames to Q.931 until Q.921 completes processing the frame
event.
The frame with the bad N(S) in the last trace was the STATUS message sent
right after receiving the SABME frame.
Issue History
Date Modified Username Field Change
======================================================================
2010-08-31 17:51 rmudgett Note Added: 0126514
======================================================================
More information about the asterisk-bugs
mailing list