[asterisk-bugs] [LibPRI 0013118]: Outgoing ISDN call blocked with cause (100) in Libpri 1.4.5 and 1.4.4, not in 1.4.3, because change in q931.c
Asterisk Bug Tracker
noreply at bugs.digium.com
Wed Feb 25 16:46:35 CST 2009
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=13118
======================================================================
Reported By: radpeter
Assigned To: mattf
======================================================================
Project: LibPRI
Issue ID: 13118
Category: General
Reproducibility: always
Severity: block
Priority: normal
Status: assigned
Asterisk Version: 1.4.21
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Disclaimer on File?: N/A
Request Review:
======================================================================
Date Submitted: 2008-07-20 16:35 CDT
Last Modified: 2009-02-25 16:46 CST
======================================================================
Summary: Outgoing ISDN call blocked with cause (100) in
Libpri 1.4.5 and 1.4.4, not in 1.4.3, because change in q931.c
Description:
Recently I updated from asterisk 1.4.18.3, libpri 1.4.3 to asterisk
1.4.21.1, libpri 1.4.5, zaptel 1.4.11
In my system I have a TE405P card, with the 1st port connected by a E1 to
a telco, and the 2nd port by a E1 to an Alcatel 4400 E pbx, using EuroISDN
The incoming calls are received by asterisk and, when appropriate, passed
through to the Pbx, which usually results in native bridge.
After a while I detected that incoming ISDN modem calls, which are passed
through to the Alcatel Pbx, wheren't answered properly. Inspection revealed
that at the moment Asterisk dialed the Alcatel PBX, the SETUP (5) resulted
in a response RELEASE COMPLETE (90) from the Alcatel, because of a Invalid
Information Contents (100).
Voice calls had no problems. A significant difference is that while voice
calls use PRI_TRANS_CAP_SPEACH, modems use PRI_TRANS_CAP_DIGITAL
Inspection of the logfile for the modme calls revealed that while Asterisk
originally received a 4-byte SETUP message from the Telco, it used a 5-byte
SETUP message to the PBX, which refused this.
After some digging I traced this to a change in the
FUNC_SEND(transmit_bearer_capability)
Originally (1.4.3)
if ((tc & PRI_TRANS_CAP_DIGITAL) && (pri->switchtype ==
PRI_SWITCH_EUROISDN_E1)) {
/* Apparently EuroISDN switches don't seem to like user layer 2/3 */
return 4;
}
In 1.4.4, perhaps related to 11593, r525
if ((tc & PRI_TRANS_CAP_DIGITAL) && (pri->switchtype ==
PRI_SWITCH_EUROISDN_E1) &&
(call->transmoderate == TRANS_MODE_PACKET)) {
/* Apparently EuroISDN switches don't seem to like user layer 2/3 */
return 4;
}
In my case call->transmoderate == TRANS_MODE_64_CIRCUIT so I placed an
additional
if ((tc & PRI_TRANS_CAP_DIGITAL) && (pri->switchtype ==
PRI_SWITCH_EUROISDN_E1) &&
(call->transmoderate == TRANS_MODE_64_CIRCUIT)) {
/* Apparently EuroISDN switches don't seem to like user layer 2/3 */
return 4;
}
And this solved the problem, as far as I have been able to test this for
now.
======================================================================
Relationships ID Summary
----------------------------------------------------------------------
related to 0014507 [patch] Regression in LibPRI regarding ...
======================================================================
----------------------------------------------------------------------
(0100761) jsmith (manager) - 2009-02-25 16:46
http://bugs.digium.com/view.php?id=13118#c100761
----------------------------------------------------------------------
I think this patch is on the right track, but specific to EuroISDN
circuits. I've added a more generic patch to bug 14507, which does
essentially the same thing, but works for 4ESS, 5ESS, National, etc.
switches as well.
Issue History
Date Modified Username Field Change
======================================================================
2009-02-25 16:46 jsmith Note Added: 0100761
======================================================================
More information about the asterisk-bugs
mailing list