[asterisk-bugs] [Asterisk 0017079]: qsigchannelmapping parameter

[Asterisk Bug Tracker]

The following issue has been UPDATED. 
====================================================================== 
https://issues.asterisk.org/view.php?id=17079 
====================================================================== 
Reported By:                -KeX-
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   17079
Category:                   Channels/chan_dahdi
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     closed
Asterisk Version:           1.6.2.6 
JIRA:                       SWP-1134 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
Resolution:                 no change required
Fixed in Version:           
====================================================================== 
Date Submitted:             2010-03-23 04:18 CDT
Last Modified:              2011-03-01 13:28 CST
====================================================================== 
Summary:                    qsigchannelmapping parameter
Description: 
I've connected Asterisk with 4 PRI to a Siemens HiPath 4000. For
CALLERID(name) 
feature I wanna use Q.SIG as switchtype. Cause Siemens PBX orders Channels

logical I need the parameter qsigchannelmapping=logical. Here is my
chan_dahdi.conf
trunkgroups]

[channels]
language=de
context=default
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=yes
relaxdtmf=yes
rxgain=0.0
txgain=0.0
group=1
callgroup=1
pickupgroup=1
immediate=no
qsigchannelmapping=logical
discardremoteholdretrieval=yes
overlapdial=yes


switchtype=qsig
context=from-siemens
group=1
echocancel=yes
signalling=pri_cpe
channel =>1-15,17-31

switchtype=euroisdn
context=from-siemens
group=2
echocancel=yes
signalling=pri_net
channel =>32-46,48-62

switchtype=euroisdn
context=from-siemens
group=2
echocancel=yes
signalling=pri_net
channel =>63-77,79-93

switchtype=qsig
context=from-siemens
group=1
echocancel=yes
signalling=pri_cpe
channel =>94-108,110-124

If I check the status of my two Q.SIG spans, I see this:
asterisk*CLI> pri show span 1
Primary D-channel: 16
Status: Provisioned, Up, Active
Switchtype: Q.SIG switch
Type: CPE
Window Length: 0/7
Sentrej: 0
SolicitFbit: 0
Retrans: 0
Busy: 0
Overlap Dial: 1
Logical Channel Mapping: 0
T200 Timer: 1000
T203 Timer: 10000
T305 Timer: 30000
T308 Timer: 4000
T309 Timer: -1
T313 Timer: 4000
N200 Counter: 3
Overlap Recv: Yes

Same, for pri show span 4

Logical Channel Mapping is 0, but should be 1. It is configured in 
chan_dahdi.conf as described here:
https://issues.asterisk.org/view.php?id=13454

Anyone seen this problem? Or anyone using qsigchannelmapping=logical?
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
related to          0013454 [patch] Several libpri issues (bugs/fea...
====================================================================== 

---------------------------------------------------------------------- 
 (0132496) rmudgett (administrator) - 2011-03-01 13:28
 https://issues.asterisk.org/view.php?id=17079#c132496 
---------------------------------------------------------------------- 
Closing since this was a configuration issue and the configure script
probably needed to be regenerated.  The configure script has been
regenerated several times since the last posting. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-03-01 13:28 rmudgett       Note Added: 0132496                          
2011-03-01 13:28 rmudgett       Status                   acknowledged => closed
2011-03-01 13:28 rmudgett       Resolution               open => no change
required
======================================================================