[Home]

Summary:ASTERISK-15860: qsigchannelmapping parameter
Reporter:Christoph (-kex-)Labels:
Date Opened:2010-03-23 04:18:45Date Closed:2011-06-07 14:05:14
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_dahdi
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
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?

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

I tried with these versions:
dahdi-linux-2.2.1
dahdi-tools-2.2.1
libpri-1.4.10.2
asterisk-1.6.2.6 (also tried with asterisk-1.6.2.4)
Comments:By: Thomas Arimont (tomaso) 2010-03-23 10:18:38

-KeX-
Have you compiled asterisk with the compile-option
HAVE_PRI_PROG_W_CAUSE? (I don't know what the default is)

It was not my idea to combine the qsigchannelmapping option with the option 'sending progress messages with cause' ...

(consider that the qsigchannelmapping option is only reasonable and valid for lines with protocol type qsig, for edss1 this parameter is ignored)

Thomas
By: Christoph (-kex-) 2010-03-23 10:25:29

Hi Thomas,

Thanks for your response!
I've compiled asterisk without any special options.

I just looked at the sources and the option is enabled:
configure:30582:#define HAVE_PRI_PROG_W_CAUSE 1

How does this option interact with qsigchannelmapping?

I know that this is only done for lines with qsig. The dss1 lines are orderd physicaliy from the Siemens PBX as well.

Chris...
By: Thomas Arimont (tomaso) 2010-03-23 11:20:07

Hi Chris,
are you sure you have libpri-1.4.10.2 installed and active?
Have you tried the current libpri svn head?

We use that feature successfully (after we have introduced it to asterisk anyway) but we have an older 1.6 beta version in production use.

Strange, it should work ...

>How does this option interact with qsigchannelmapping?
It does not really interact in the meaning of protocol behaviour. It's just a common compiler flag for some newer QSIG features. And you're right, it's switch on by default (at least in 1.6.2.6).

Our config:

[channels]
switchtype=qsig
qsigchannelmapping=logical
discardremoteholdretrieval=yes
overlapdial=yes
..
context=isdn-in
group=1
signalling=pri_cpe
channel=>1-15,17-31
channel=>32-46,48-62
;signalling=pri_net
channel=>63-77,79-93
channel=>94-108,110-124

Maybe you should try it without the dss1 lines being configured. Nothing is perfect ...

Thomas
By: Christoph (-kex-) 2010-03-23 12:40:35

Hi,

I'm sure I'm using libpri-1.4.10.2. I've set up the Server from scratch 1 month ago, because of the qsigchannelmapping parameter.

I haven't used svn head, cause it's a productive installation : / An as you wrote in your issue 0013454, that the channels can be orderd logically as well I upgraded from an older version. (1.4.x to 1.6.2.4 and then to 1.6.2.6)

I've tried with 4 qsig lines, and with your configuration snip, nothing changes. Logical Channel Mapping: is allways 0 : /

The Server is a HP DL360 with a Sangoma A104. Everything is working fine, except the logical channel mapping : /

Any other hints how I can get this working?

Chris...
By: Thomas Arimont (tomaso) 2010-03-24 08:16:10

Hi Chris,
my first assumption was right. HAVE_PRI_PROG_W_CAUSE is not defined. There is something getting wrong in the configure process.

Here is a quick hack as long as the 'configure' has not been corrected:

If you change ../include/asterisk/autoconfig.h by adding the line
#define HAVE_PRI_PROG_W_CAUSE 1 (e.g. somewhere after HAVE_PRI is defined)
AFTER you have called the configure tool, you will compile (make) a version that should work.
I tested it by using the current asterisk 1.6.2.6 and libpri 1.4.10.2

By the way: autoconfig.h is the right place where to look after missing or included preprocessor defines after configuring.

Regards Thomas
By: Thomas Arimont (tomaso) 2010-03-24 08:52:05

In my opinion the line
#undef HAVE_PRI_PROG_W_CAUSE
in /include/asterisk/autoconfig.h.in is missing and should be fixed.

@Chris: If you add this line to the *in file the configure process works properly and generates the proper autoconfig.h file. This should be the much better alternative than my first quick hack proposal.
By: Christoph (-kex-) 2010-03-24 09:45:30

Hi Thomas,

Thanks for your replay. Your reply helped : ) Everything is working fine now. And I can use all my 108 channels *hehe

So there is a 'bug' in the configure process. With #define HAVE_PRI_PROG_W_CAUSE 1 everything works, without the qsigchannelmapping parameter is completely ignored.

Regards,

Chris...
EDIT: did the hack : )


By: Thomas Arimont (tomaso) 2010-03-24 10:00:34

You're welcome.
Somebody at Digium will/can fix that properly now for the next *-release.
Regards from Aachen, Germany
By: Christoph (-kex-) 2010-03-25 08:30:23

Hi,

Just successfully testet calls over channel 28 : ) It works.

One question, don't know if this is the right place: The patch for calling name in Q.SIG(ROSE_NAME_PRESENTATION_ALLOWED_EXTENDED) is it inclued in libpri? Or do I have to patch it, and where do I get it?

Regards from Salzburg, Austria : )
By: Thomas Arimont (tomaso) 2010-03-25 08:53:27

Hi Chris,
yes and no, only the simple name format (namePresentationAllowedSimple) is supported in encoding direction.
In decoding direction namePresentationAllowedExtended should be understood as long as characterset iso8859-1 is used.
Normally that should work.

Haven't seen any other libpri implementation for the extended format yet.
What kind of characterset do you want to use? I guess it's the same character set (iso8859-1) like the one implicitly used in the simple name format.

Alternative: Can't you configure the HICOM in such a way that it is using the simple name format?

Regards Thomas


By: Christoph (-kex-) 2010-03-25 09:35:16

Hi Thomas,

Callerid Name is present when calling from HICOM to Asterisk. But when calling from Asterisk to HICOM only the name of the Trunk (Asterisk) is shown (and the Nr.).

What configuration to I need on the HICOM side so CallingName is presented as well? I can't configure the HICOM on my own, but I've a Siemens technician who can.

Regards, Chris...
By: Thomas Arimont (tomaso) 2010-03-25 09:47:10

Is the trunk name (Asterisk) defined in the HICOM?
Please post a logging and your configuration (core verbose, pri debug, extensions.conf ,chan_dahdi.conf, etc.)
By: Christoph (-kex-) 2010-03-25 10:24:01

Hi,
extensions.conf
[default]
exten => 123455,1,Set(CALLERID(name)=testinger)
exten => 123455,n,Set(CALLERID(num)=1234)
exten => 123455,n,Dial(DAHDI/122/59600)

exten => 59600,1,Answer()
exten => 59600,n,Wait(1)
exten => 59600,n,Verbose(${CALLERID(all)})
exten => 59600,n,PlayBack(demo-echotest)    
exten => 59600,n,Echo
exten => 59600,n,Hangup

chan_dahdi.conf
[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

;Sangoma A104 port 1 [slot:1 bus:10 span:1] <wanpipe1>                                                                                                                                                                                      
switchtype=qsig
context=from-siemens
group=1
echocancel=yes
signalling=pri_cpe
;channel =>1-15                                                                                                                                                                                                                            
channel =>1-15,17-31

;Sangoma A104 port 2 [slot:1 bus:10 span:2] <wanpipe2>                                                                                                                                                                                      
switchtype=euroisdn
overlapdial=yes
context=from-siemens
group=2
echocancel=yes
signalling=pri_net
channel =>32-46,48-62

;Sangoma A104 port 3 [slot:1 bus:10 span:3] <wanpipe3>                                                                                                                                                                                      
switchtype=euroisdn
context=from-siemens
group=2
echocancel=yes
signalling=pri_net
channel =>63-77,79-93

;Sangoma A104 port 4 [slot:1 bus:10 span:4] <wanpipe4>                                                                                                                                                                                      
switchtype=qsig
context=from-siemens
group=1
echocancel=yes
signalling=pri_cpe
;channel =>94-108                                                                                                                                                                                                                          
channel =>94-108,110-124

 == Using SIP RTP CoS mark 5
 == Using SIP VRTP CoS mark 6
   -- Executing [123455@default:1] Set("SIP/commpany.at-000007b0", "CALLERID(name)=testinger") in new stack
   -- Executing [123455@default:2] Set("SIP/commpany.at-000007b0", "CALLERID(num)=1234") in new stack
   -- Executing [123455@default:3] Dial("SIP/commpany.at-000007b0", "DAHDI/122/59600") in new stack
-- Making new call for cr 32776
   -- Requested transfer capability: 0x00 - SPEECH
> Protocol Discriminator: Q.931 (8)  len=31
> Call Ref: len= 2 (reference 8/0x8) (Originator)
> Message type: SETUP (5)
> [04 03 80 90 a3]
> Bearer Capability (len= 5) [ Ext: 1  Q.931 Std: 0  Info transfer capability: Speech (0)
>                              Ext: 1  Trans mode/rate: 64kbps, circuit-mode (16)
>                                User information layer 1: A-Law (35)
> [18 03 a1 83 9c]
> Channel ID (len= 5) [ Ext: 1  IntID: Implicit  PRI  Spare: 0  Preferred  Dchan: 0
>                        ChanSel: As indicated in following octets
>                       Ext: 1  Coding: 0  Number Specified  Channel Type: 3
>                       Ext: 1  Channel: 28 ]
> [6c 06 21 80 31 32 33 34]
> Calling Number (len= 8) [ Ext: 0  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
>                           Presentation: Presentation permitted, user number not screened (0)  '1234' ]
> [70 06 80 35 39 36 30 30]
> Called Number (len= 8) [ Ext: 1  TON: Unknown Number Type (0)  NPI: Unknown Number Plan (0)  '59600' ]
q931.c:3134 q931_setup: call 32776 on channel 29 enters state 1 (Call Initiated)
   -- Called 122/59600
< Protocol Discriminator: Q.931 (8)  len=10
< Call Ref: len= 2 (reference 8/0x8) (Terminator)
< Message type: SETUP ACKNOWLEDGE (13)
< [18 03 a9 83 9c]
< Channel ID (len= 5) [ Ext: 1  IntID: Implicit  PRI  Spare: 0  Exclusive  Dchan: 0
<                        ChanSel: As indicated in following octets
<                       Ext: 1  Coding: 0  Number Specified  Channel Type: 3
<                       Ext: 1  Channel: 28 ]
-- Processing IE 24 (cs0, Channel Identification)
q931.c:3891 q931_receive: call 32776 on channel 29 enters state 2 (Overlap sending)
   -- Accepting overlap call from '1234' to '59600' on channel 0/1, span 1
   -- Starting simple switch on 'DAHDI/1-1'
   -- Executing [59600@from-siemens:1] Answer("DAHDI/1-1", "") in new stack
   -- Executing [59600@from-siemens:2] Wait("DAHDI/1-1", "1") in new stack
< Protocol Discriminator: Q.931 (8)  len=10
< Call Ref: len= 2 (reference 8/0x8) (Terminator)
< Message type: CALL PROCEEDING (2)
< [18 03 a9 83 9c]
< Channel ID (len= 5) [ Ext: 1  IntID: Implicit  PRI  Spare: 0  Exclusive  Dchan: 0
<                        ChanSel: As indicated in following octets
<                       Ext: 1  Coding: 0  Number Specified  Channel Type: 3
<                       Ext: 1  Channel: 28 ]
-- Processing IE 24 (cs0, Channel Identification)
q931.c:3683 q931_receive: call 32776 on channel 29 enters state 3 (Outgoing call  Proceeding)
   -- DAHDI/122-1 is proceeding passing it to SIP/commpany.at-000007b0
< Protocol Discriminator: Q.931 (8)  len=76
< Call Ref: len= 2 (reference 8/0x8) (Terminator)
< Message type: CONNECT (7)
< [18 03 a9 83 9c]
< Channel ID (len= 5) [ Ext: 1  IntID: Implicit  PRI  Spare: 0  Exclusive  Dchan: 0
<                        ChanSel: As indicated in following octets
<                       Ext: 1  Coding: 0  Number Specified  Channel Type: 3
<                       Ext: 1  Channel: 28 ]
< [1c 1d 9f aa 06 80 01 00 82 01 00 8b 01 00 a1 0f 02 02 f2 94 02 01 55 30 06 82 04 06 1c 08 40]
< Facility (len=31, codeset=0) [ 0x9F, 0xAA, 0x06, 0x80, 0x01, 0x00, 0x82, 0x01, 0x00, 0x8B, 0x01, 0x00, 0xA1, 0x0F, 0x02, 0x02, 0xF2, 0x94, 0x02, 0x01, 'U0', 0x06, 0x82, 0x04, 0x06, 0x1C, 0x08, '@' ]
PROTOCOL 1F
AA 0006 (CONTEXT SPECIFIC [10])
 80 0001 00 (CONTEXT SPECIFIC [0])
 82 0001 00 (CONTEXT SPECIFIC [2])
8B 0001 00 (CONTEXT SPECIFIC [11])
A1 000F (CONTEXT SPECIFIC [1])
 02 0002 F2 94 (INTEGER: 62100)
 02 0001 55 (INTEGER: 85)
 30 0006 (SEQUENCE)
   82 0004 06 1C 08 40 (CONTEXT SPECIFIC [2])
< [1c 1d 9f aa 06 80 01 00 82 01 00 8b 01 00 a1 0f 02 02 f2 a3 02 01 02 a1 06 04 01 2e 02 01 01]
< Facility (len=31, codeset=0) [ 0x9F, 0xAA, 0x06, 0x80, 0x01, 0x00, 0x82, 0x01, 0x00, 0x8B, 0x01, 0x00, 0xA1, 0x0F, 0x02, 0x02, 0xF2, 0xA3, 0x02, 0x01, 0x02, 0xA1, 0x06, 0x04, 0x01, '.', 0x02, 0x01, 0x01 ]
PROTOCOL 1F
AA 0006 (CONTEXT SPECIFIC [10])
 80 0001 00 (CONTEXT SPECIFIC [0])
 82 0001 00 (CONTEXT SPECIFIC [2])
8B 0001 00 (CONTEXT SPECIFIC [11])
A1 000F (CONTEXT SPECIFIC [1])
 02 0002 F2 A3 (INTEGER: 62115)
 02 0001 02 (INTEGER: 2)
 A1 0006 (CONTEXT SPECIFIC [1])
   04 0001 2E (OCTETSTRING: 2e)
   02 0001 01 (INTEGER: 1)
< [1e 02 81 82]
< Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  0: 0  Location: Private network serving the local user (1)
<                               Ext: 1  Progress Description: Called equipment is non-ISDN. (2) ]
-- Processing IE 24 (cs0, Channel Identification)
-- Processing IE 28 (cs0, Facility)
Q.932 Network facility extensions component is not handled
Q.932 Interpretation component is not handled
Handle Q.932 ROSE Invoke component
 [ Handling operation 85 ]
!! Unable to handle ROSE operation 85 [ 30 06 82 04 06 1C 08 40 ] - [0......@]
-- Processing IE 28 (cs0, Facility)
Q.932 Network facility extensions component is not handled
Q.932 Interpretation component is not handled
Handle Q.932 ROSE Invoke component
 [ Handling operation 2 ]
!! Unable to handle ROSE operation 2 [ A1 06 04 01 2E 02 01 01 ] - [........]
-- Processing IE 30 (cs0, Progress Indicator)
q931.c:3626 q931_receive: call 32776 on channel 29 enters state 10 (Active)
> Protocol Discriminator: Q.931 (8)  len=5
> Call Ref: len= 2 (reference 8/0x8) (Originator)
> Message type: CONNECT ACKNOWLEDGE (15)
   -- DAHDI/122-1 answered SIP/commpany.at-000007b0
   -- Executing [59600@from-siemens:3] Verbose("DAHDI/1-1", ""ASTERISK" <1234>") in new stack
ASTERISK <1234>
   -- Executing [59600@from-siemens:4] Playback("DAHDI/1-1", "demo-echotest") in new stack
   -- <DAHDI/1-1> Playing 'demo-echotest.gsm' (language 'de')
[Mar 25 16:19:31] NOTICE[20823]: chan_sip.c:21369 handle_request_subscribe: Received SIP subscribe for peer without mailbox: 50006
   -- Executing [h@default:1] GotoIf("SIP/commpany.at-000007b0", "0?10") in new stack
   -- Executing [h@default:2] UnpauseQueueMember("SIP/commpany.at-000007b0", ",") in new stack
[Mar 25 16:19:33] WARNING[19564]: app_queue.c:4820 upqm_exec: Missing interface argument to PauseQueueMember ([queuename],interface[,options[,reason]])
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Active, peerstate Connect Request
q931.c:3015 q931_disconnect: call 32776 on channel 29 enters state 11 (Disconnect Request)
> Protocol Discriminator: Q.931 (8)  len=9
> Call Ref: len= 2 (reference 8/0x8) (Originator)
> Message type: DISCONNECT (69)
> [08 02 81 90]
> Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0  Location: Private network serving the local user (1)
>                  Ext: 1  Cause: Normal Clearing (16), class = Normal Event (1) ]
   -- Hungup 'DAHDI/122-1'
 == Spawn extension (default, 123455, 3) exited non-zero on 'SIP/commpany.at-000007b0'
   -- Channel 0/1, span 1 got hangup request, cause 16
< Protocol Discriminator: Q.931 (8)  len=9
< Call Ref: len= 2 (reference 8/0x8) (Terminator)
< Message type: RELEASE (77)
< [08 02 80 90]
< Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0  Location: User (0)
<                  Ext: 1  Cause: Normal Clearing (16), class = Normal Event (1) ]
-- Processing IE 8 (cs0, Cause)
q931.c:3801 q931_receive: call 32776 on channel 29 enters state 0 (Null)
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Release Request
> Protocol Discriminator: Q.931 (8)  len=9
> Call Ref: len= 2 (reference 8/0x8) (Originator)
> Message type: RELEASE COMPLETE (90)
> [08 02 81 90]
> Cause (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0)  Spare: 0  Location: Private network serving the local user (1)
>                  Ext: 1  Cause: Normal Clearing (16), class = Normal Event (1) ]
NEW_HANGUP DEBUG: Calling q931_hangup, ourstate Null, peerstate Null
NEW_HANGUP DEBUG: Destroying the call, ourstate Null, peerstate Null
 == Spawn extension (from-siemens, 59600, 4) exited non-zero on 'DAHDI/1-1'
   -- Hungup 'DAHDI/1-1'


Chris...
By: Thomas Arimont (tomaso) 2010-03-25 10:37:16

Try

facilityenable = yes

in your chan_dahdi.conf ! ;-)
By: Christoph (-kex-) 2010-03-25 12:27:54

*ha, that did the trick : )
Thanks!

For my part, the bug is found, think the fix should be easy. This can be closed.

Thanks,
Chris...
By: Richard Mudgett (rmudgett) 2011-03-01 13:28:35.000-0600

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.