[Home]

Summary:ASTERISK-14419: [patch] Unable to make ISDN PRI calls after upgrade.
Reporter:Alec Davis (alecdavis)Labels:
Date Opened:2009-07-05 21:50:49Date Closed:2009-07-23 11:01:21
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_dahdi
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) bug15452.patch
( 1) Invalid-information-element-contects-100.txt
( 2) pri-not-working.txt
( 3) pri-working.txt
Description:After upgrade to SVN-trunk-r204919M from SVN-branch-1.6.2-r203077M we are unable to make ISDN PRI calls.

reverting back to 1.6.2-r203077M with exactly same configs, works again.

Console output as attached files.

The difference is the extra "Ext: 1  DS1 Identifier: 0" that's not present using older code.


****** ADDITIONAL INFORMATION ******

chan_dahdi.conf

context=incoming
group = 0
pridialplan = unknown
prilocaldialplan = unknown
facilityenable=yes
transfer=yes
switchtype=qsig
signalling=pri_cpe
qsigchannelmapping=physical
channel => 1-15,17-31

Comments:By: Alec Davis (alecdavis) 2009-07-07 17:07:30

Description below of initially uploaded files.

pri-working.txt: using SVN-branch-1.6.2-r203077M
pri-not-working.txt: using SVN-trunk-r204919M

Both of the above traces were connected to a JTec ETSI QSIG trunk.


By: Alec Davis (alecdavis) 2009-07-07 17:22:34

libpri version: SVN-branch-1.4-r865
Asterisk SVN-trunk-r205014
DAHDI Version: 2.2.0 Echo Canceller: MG2

Connecting to a Jtec QSIG card the call fails as reported.

If we connect to a JTec E1MN ETSI card, the call will succeed. Still has an error come back.

uploaded Invalid-information-element-contects-100.txt
This is a successful call, using a non-qsig trunk, still there is a STATUS message indicating not happy.
By: Alec Davis (alecdavis) 2009-07-08 05:42:14

excerpt from ITU Q.931 (05/98)

4.5.13 Channel identification
The purpose of the Channel identification information element is to identify a channel within the
interface(s) controlled by these signalling procedures.
The Channel identification information element is coded as shown in Figures 4-18 and 4-19 and
Table 4-13. The channel identification element may be repeated in a message, e.g. to list several
acceptable channels during channel negotiation.
The default maximum length for this information element is network dependent
<pre>    8       7       6       5       4       3       2       1      Octet
o-------o-------o-------o-------o-------o-------o-------o-------o
|     Channel identification information element identifier     |
|   0   |   0   |   0   |   1   |   1   |   0   |   0   |   0   |  1
o-------o-------o-------o-------o-------o-------o-------o-------o
|         Length of channel identification contents             |  2
o-------o-------o-------o-------o-------o-------o---------------o
|  ext  |Int Id | Int   | Spare | Pref  |D-Chan | Info Channel  |  3
|   1   |Present| Type  |   0   | Excl  |  Ind  |  Selection    |
o-------o-------o-------o-------o-------o-------o-------o-------o
|  ext  |             Interface Identifier                      |  3.1
|  0/1  |                                                       | (Note 1)
o-------o-------o-------o-------o-------o-------o-------o-------o
|  ext  |   Coding      |Number |       Channel type            |  3.2
|   1   |   Standard    | /Map  |        / Map element Type     | (Note 2 & 5)
o-------o-------o-------o-------o-------o-------o-------o-------o
|                  Channel number/Slot map (Note 3)             |  3.3
|                                                               | (Note 2,4 & 5)
o-------o-------o-------o-------o-------o-------o-------o-------o</pre>

NOTE 1 – When the "interface identifier present" field in octet 3 indicates "interface implicitly identified" octet 3.1 is omitted. When octet 3.1 is present, it may be extended by using the extension bit (bit 8).

NOTE 2 – When the "interface type" field in octet 3 indicates "basic interface", octets 3.2 and 3.3 are functionally replaced by the "information channel selection" field in octet 3,and thus omitted.

NOTE 3 – When channel number is used and a single channel is indicated, bit 8 shall be set to "1". When channel number is used and multiple channels are indicated, bit 8 shall be used as an extension bit to indicate an extension to subsequent channels and coded according to the rules specified in 4.5.1.

NOTE 4 – When channel number is used, this octet may be repeated to indicate multiple channels.

NOTE 5 – These octets shall be omitted when the entire interface is to be identified.
By: Alec Davis (alecdavis) 2009-07-08 06:30:22

Reading further http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-143.pdf , around pages 68-70 to do with 'channel identification'.

<b>NOTE 1 Since the interface is never explicitly identified at the Q reference point, octet 3.1 of ITU-T Rec. Q.931 is always omitted.<b>
By: Alec Davis (alecdavis) 2009-07-13 15:48:03

Summary:

Since sig-pri work the inclusion of Octect 3.1 in the channel indentification is causing us problems.

The standards ECMA-143 infer that it is always ommited.

If Octect 3.1 is present, then Octects 3.2 and 3.3 are ommitted.
By: Alec Davis (alecdavis) 2009-07-21 16:01:41

Please assign to jpeeler, 'change of behaviour not intentional' as discussed on IRC on Friday.
By: Jeff Peeler (jpeeler) 2009-07-22 16:58:11

I believe this restores the previous correct behavior, let me know the results.
By: Alec Davis (alecdavis) 2009-07-22 17:55:28

Applied bug15452.patch to SVN-trunk-r205014M

testing:
Succesfully made calls, when connected to either PRI ETSI trunk and a QSIG ETSI trunk.

Previously, the PRI trunk would report an error, but still proceed, where as the QSIG trunk would fail, now both work.
By: Alec Davis (alecdavis) 2009-07-23 00:15:40

SVN-trunk-r208193M with patch applied.

tested inbound and outbound calls: worked as expected.

tested to SIP - > PABX, primarily to check for 'No Audio bug - dialling flag not cleared issue', worked as expected.
By: Digium Subversion (svnbot) 2009-07-23 10:59:49

Repository: asterisk
Revision: 208267

U   trunk/channels/chan_dahdi.c
U   trunk/channels/sig_pri.c
U   trunk/channels/sig_pri.h

------------------------------------------------------------------------
r208267 | jpeeler | 2009-07-23 10:59:49 -0500 (Thu, 23 Jul 2009) | 13 lines

Fix sending of interface identifier unconditionally in sig_pri

The wrong logic was being used in chan_dahdi to convert a sig_pri_chan
to the proper libpri channel number. The most significant bit must only
be set only when trunk groups are being used.

(closes issue ASTERISK-14419)
Reported by: alecdavis
Patches:
     bug15452.patch uploaded by jpeeler (license 325)
Tested by: alecdavis


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=208267
By: Digium Subversion (svnbot) 2009-07-23 11:00:59

Repository: asterisk
Revision: 208268

_U  branches/1.6.0/

------------------------------------------------------------------------
r208268 | jpeeler | 2009-07-23 11:00:58 -0500 (Thu, 23 Jul 2009) | 18 lines

Blocked revisions 208267 via svnmerge

........
 r208267 | jpeeler | 2009-07-23 10:59:44 -0500 (Thu, 23 Jul 2009) | 13 lines
 
 Fix sending of interface identifier unconditionally in sig_pri
 
 The wrong logic was being used in chan_dahdi to convert a sig_pri_chan
 to the proper libpri channel number. The most significant bit must only
 be set only when trunk groups are being used.
 
 (closes issue ASTERISK-14419)
 Reported by: alecdavis
 Patches:
       bug15452.patch uploaded by jpeeler (license 325)
 Tested by: alecdavis
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=208268
By: Digium Subversion (svnbot) 2009-07-23 11:01:08

Repository: asterisk
Revision: 208269

_U  branches/1.6.1/

------------------------------------------------------------------------
r208269 | jpeeler | 2009-07-23 11:01:08 -0500 (Thu, 23 Jul 2009) | 18 lines

Blocked revisions 208267 via svnmerge

........
 r208267 | jpeeler | 2009-07-23 10:59:44 -0500 (Thu, 23 Jul 2009) | 13 lines
 
 Fix sending of interface identifier unconditionally in sig_pri
 
 The wrong logic was being used in chan_dahdi to convert a sig_pri_chan
 to the proper libpri channel number. The most significant bit must only
 be set only when trunk groups are being used.
 
 (closes issue ASTERISK-14419)
 Reported by: alecdavis
 Patches:
       bug15452.patch uploaded by jpeeler (license 325)
 Tested by: alecdavis
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=208269
By: Digium Subversion (svnbot) 2009-07-23 11:01:21

Repository: asterisk
Revision: 208270

_U  branches/1.6.2/

------------------------------------------------------------------------
r208270 | jpeeler | 2009-07-23 11:01:20 -0500 (Thu, 23 Jul 2009) | 18 lines

Blocked revisions 208267 via svnmerge

........
 r208267 | jpeeler | 2009-07-23 10:59:44 -0500 (Thu, 23 Jul 2009) | 13 lines
 
 Fix sending of interface identifier unconditionally in sig_pri
 
 The wrong logic was being used in chan_dahdi to convert a sig_pri_chan
 to the proper libpri channel number. The most significant bit must only
 be set only when trunk groups are being used.
 
 (closes issue ASTERISK-14419)
 Reported by: alecdavis
 Patches:
       bug15452.patch uploaded by jpeeler (license 325)
 Tested by: alecdavis
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=208270