asterisk/libpri

PRI Library

libpri's Issues

Documentation

Hi,

Recently I've started working with this library, but the software that I'm working on was build with use of libpri 1.4.11.5 and now I need to do the update.
By any chance is it possible to get somekind of documentation for this library?

User-user information IE missing in SETUP retransmission

Issue type:
Bug

Description:
When libpri retransmits a SETUP message, UUI Information Element (IE) that was present in first SETUP is missing in second SETUP.

Operating System detail:
(problem not related to OS)

libpri version:
1.6.0 (should also occur with 1.6.1: involved code unchanged)

Information on any third party software:
Asterisk 18.6.0, dahdi 3.1.0

Frequency and timing of the issue:
Always, when SETUP is repeated after T303 timeout.

Symptoms described in specific detail:
Called party receives second SETUP without UUI, although Asterisk provided a UUI value.
The defect is visible in Asterisk with CLI command "pri set debug on span ".

Steps required to reproduce the issue:
This Issue requires, when using libpri with Asterisk :

• UUI support in Asterisk: compile channels/sig_pri.c with #define SUPPORT_USERUSER
• UUI activation from Asterisk dialplan: set _USERUSERINFO Channel variable before Dial(),
• a SETUP retransmission: it can be reproduced with a slow called equipment, or a very short T303 timer configuration.

Workarounds in detail with specific steps:
No workaround.

Debugging output:
Enable "pri set debug on span " before making the call.
First SETUP carries UUI.
Repeated SETUP, after T303 timeout, does not.

Analysis:
The problem comes from libpri q931.c use of useruserinformation field in q931_call structure as a ephemeral storage field.
In outgoing direction, useruserinformation field is cleared as soon as UUI IE is generated (function transmit_user_user()).
Note: in incoming direction, useruserinformation field is also set while decoding IE, and cleared when libpri generates event for application.

I will try to submit a patch soon.

Please consider updating the GPL-2.0 license text

The file LICENSE contains an incorrect/obsolete FSF mailing address. This is not a major issue, but it is easy to correct. Please consider using the latest GPL-2.0 license text from https://www.gnu.org/licenses/old-licenses/gpl-2.0.txt instead.

(The newer text refers to the GNU Lesser General Public License instead of the GNU Library General Public License, and there were trivial changes to whitespace and to placeholder text, but the terms remain unchanged.)

$ curl -L https://www.gnu.org/licenses/old-licenses/gpl-2.0.txt > LICENSE

B-Channel possibly blocked after link loss in BRI Net point-to-multipoint configuration

Issue type:
Bug

Description:
A B-Channel can remain blocked (marked as not idle) in BRI Net point-to-multipoint configuration, if following conditions occur:

• Call established,
• Loss of BRI link (disconnection),
• Hangup initiated before layer 2 release indication.

Operating System detail:
(problem not related to OS)

libpri version:
1.6.0 (should also occur with 1.6.1: involved code unchanged)

Information on any third party software:
Asterisk 18.6.0, dahdi 3.1.0

Frequency and timing of the issue:
Always, in conditions described below (see: steps to reproduce the issue)

Symptoms described in specific detail:
Asterisk does not use the B-Channel anymore for outgoing calls.

Steps required to reproduce the issue:
When a call is established, using libpri and Asterisk, on a BRI span configured in Net point-to-multipoint mode,
if the BRI link is lost (disconnection),
if Asterisk user hangs up quickly (before BRI layer 2 down indication)
then the B Channel never goes back Idle, even after link reconnection.

Workarounds in detail with specific steps:
Restart Asterisk chan_dahdi.so module (module unload / module load, dahdi restart should work too).

Debugging output:
When the problem occurs, Asterisk "pri show channels" shows B-Channels as not Idle, with no Asterisk Channel associated.
Example, with 2 B-Channels blocked :

# rasterisk -x 'pri show channels'
PRI       B    Chan Call       PRI  Channel
Span Chan Chan Idle Level      Call Name
   1    1 Yes  No   Idle       No
   2    2 Yes  No   Idle       No
   3    3 Yes  Yes  Idle       No
   4    4 Yes  Yes  Idle       No

Analysis:
The problem comes from libpri q931_dl_event() function ("Receive a DL event from layer 2"), when processing Q931_DL_EVENT_DL_RELEASE_IND after an disconnect request, specifically in Net point-to-multipoint configuration (bri_net_ptmp) :

• q931_dl_event() processes Q931_DL_EVENT_DL_RELEASE_IND,
• call state (call->ourcallstate) is Q931_CALL_STATE_DISCONNECT_REQUEST,
• q931_dl_event() "switch (call->ourcallstate)" executes default section,
• link outboundbroadcast flag (cur->outboundbroadcast) is true,
• a comment says "Simply destroy non-winning subcalls." but code actually does not check "winning" status of subcall, and calls q931_destroycall().

If we fix the test, in accordance with the comment :
replace: if (cur->outboundbroadcast)
with: if (cur->outboundbroadcast && call != q931_find_winning_call(call))
then the B-Channel blocking problem does not occur any more.

I will try to submit a patch (first time for me in new Issue / Code Contribution environment).