dahdi_ss7_error libss7

Asterisk Asterisk Support
1

Hi

My ss7 link is up using libss7, asterisk, wanpipe on Sangoma A108 card and working but I am not able to make outbound calls.

debian*CLI> ss7 show linkset 1
SS7 linkset 1 status: Up

The error message is
ERROR[19658]: chan_dahdi.c:11917 dahdi_ss7_error: !! Unable to handle message of type 0x3 on CIC 1

This is the debug trace when outgoing call is made

Connected to Asterisk 1.6.2.0 currently running on debian (pid = 19614)
Verbosity is at least 6
Core debug is at least 1
Len = 18 [ ef f7 0f c1 0b b4 5a 0c 11 80 0c 0d 0e 0f 10 11 12 13 ]
FSN: 119 FIB 1
BSN: 111 BIB 1
<[0] MSU
[ ef f7 0f ]
Network Indicator: 3 Priority: 0 User Part: STD_TEST (1)
debian*C[ c1 ]
OPC 12650 DPC 13323 SLS 0
[ 0b b4 5a 0c ]
H0: 1 H1: 1
[ 11 ]

Len = 18 [ f7 f0 0f c1 6a f1 02 0d 21 80 0c 0d 0e 0f 10 11 12 13 ]
FSN: 112 FIB 1
BSN: 119 BIB 1

[0] MSU
[ f7 f0 0f ]
Network Indicator: 3 Priority: 0 User Part: STD_TEST (1)
[ c1 ]
OPC 13323 DPC 12650 SLS 0
[ 6a f1 02 0d ]
H0: 1 H1: 2
[ 21 ]

Len = 16 [ bc da 0d c5 0b b4 5a 3c 01 00 0c 02 00 02 82 9f ]
FSN: 90 FIB 1
BSN: 60 BIB 1
<[1] MSU
[ bc da 0d ]
Network Indicator: 3 Priority: 0 User Part: ISUP (5)
debian*C[ c5 ]
OPC 12650 DPC 13323 SLS 3
[ 0b b4 5a 3c ]
CIC: 1
[ 01 00 ]
Message Type: REL
[ 0c ]
–VARIABLE LENGTH PARMS[1]–
Cause Indicator:
Coding Standard: 0
Location: 2
Cause Class: 1
Cause Subclass: 15
Cause: Normal, unspecified (31)
[ 02 82 9f ]

Len = 12 [ da bd 09 c5 6a f1 02 1d 01 00 10 00 ]
FSN: 61 FIB 1
BSN: 90 BIB 1

[1] MSU
[ da bd 09 ]
Network Indicator: 3 Priority: 0 User Part: ISUP (5)
[ c5 ]
OPC 13323 DPC 12650 SLS 1
[ 6a f1 02 1d ]
debian*CLI> CIC: 1
[ 01 00 ]
Message Type: RLC
[ 10 ]

-- Hungup 'DAHDI/1-1'

[Jan 4 17:59:54] WARNING[20104]: func_strings.c:778 csv_quote: No argument specified!
[Jan 4 17:59:54] WARNING[20104]: func_strings.c:778 csv_quote: No argument specified!
[Jan 4 17:59:54] WARNING[20104]: func_strings.c:778 csv_quote: No argument specified!
[Jan 4 17:59:54] NOTICE[20104]: pbx_spool.c:339 attempt_thread: Call failed to go through, reason (1) Hangup
Len = 18 [ bd db 0f c1 0b b4 5a 1c 11 80 0d 0e 0f 10 11 12 13 14 ]
FSN: 91 FIB 1
BSN: 61 BIB 1
<[1] MSU
[ bd db 0f ]
debian*CNetwork Indicator: 3 Priority: 0 User Part: STD_TEST (1)
[ c1 ]
OPC 12650 DPC 13323 SLS 1
[ 0b b4 5a 1c ]
H0: 1 H1: 1
[ 11 ]

Len = 18 [ db be 0f c1 6a f1 02 1d 21 80 0d 0e 0f 10 11 12 13 14 ]
FSN: 62 FIB 1
BSN: 91 BIB 1

[1] MSU
[ db be 0f ]
Network Indicator: 3 Priority: 0 User Part: STD_TEST (1)
[ c1 ]
OPC 13323 DPC 12650 SLS 1
[ 6a f1 02 1d ]
H0: 1 H1: 2
[ 21 ]

-- Attempting call on Dahdi/g1/9044012514 for s@demo:1 (Retry 2)

Len = 37 [ db bf 22 c5 6a f1 02 1d 01 00 01 00 60 01 0a 00 02 0a 08 81 10 09 44 10 52 41 0f 0a 07 01 10 09 44 10 73 05 00 ]
FSN: 63 FIB 1
BSN: 91 BIB 1

[1] MSU
[ db bf 22 ]
Network Indicator: 3 Priority: 0 User Part: ISUP (5)
[ c5 ]
OPC 13323 DPC 12650 SLS 1
[ 6a f1 02 1d ]
CIC: 1
[ 01 00 ]
Message Type: IAM
[ 01 ]
–FIXED LENGTH PARMS[4]–
Nature of Connection Indicator:
Satellites in connection: 0
Continuity Check: Check not required (0)
Outgoing half echo control device: not included (0)
[ 00 ]
Forward Call Indicators:
Nat/Intl Call Ind: call to be treated as a national call (0)
End to End Method Ind: no end-to-end method(s) available (0)
Interworking Ind: no interworking encountered (0)
End to End Info Ind: no end-to-end information available (0)
ISDN User Part Ind: ISDN user part used all the way (1)
ISDN User Part Pref Ind: ISDN user part not preferred all the way (1)
ISDN Access Ind: originating access ISDN (1)
SCCP Method Ind: no indication (0)
[ 60 01 ]
Calling Party’s Category:
Category: Ordinary calling subscriber (10)
[ 0a ]
Transmission Medium Requirements:
Speech (0)
[ 00 ]
–VARIABLE LENGTH PARMS[1]–
debian*CLI> Called Party Number:
Nature of address: 1
NI: 0
Numbering plan: 1
Address signals: 9044012514#
[ 08 81 10 09 44 10 52 41 0f ]
–OPTIONAL PARMS–
Calling Party Number:
Nature of address: 1
NI: 0
Numbering plan: 1
Presentation: 0
Screening: 0
Address signals: 9044013750
[ 0a 07 01 10 09 44 10 73 05 ]

Len = 18 [ bf dc 0f c5 0b b4 5a 3c 01 00 06 02 04 01 29 01 01 00 ]
FSN: 92 FIB 1
BSN: 63 BIB 1
<[1] MSU
[ bf dc 0f ]
Network Indicator: 3 Priority: 0 User Part: ISUP (5)
[ c5 ]
debian*COPC 12650 DPC 13323 SLS 3
[ 0b b4 5a 3c ]
CIC: 1
[ 01 00 ]
Message Type: ACM
[ 06 ]
–FIXED LENGTH PARMS[1]–
Backward Call Indicator:
Charge indicator: 2
Called party’s status indicator: 0
Called party’s category indicator: 0
End to End method indicator: 0
Interworking indicator: 0
End to End information indicator: 0
ISDN user part indicator: 1
Holding indicator: 0
ISDN access indicator: 0
Echo control device indicator: 0
SCCP method indicator: 0
[ 02 04 ]
–OPTIONAL PARMS–
Optional Backward Call Indicator:
In-band information indicator: 1
Call diversion may occur indicator: 0
Simple segmentation indicator: 0
MLPP user indicator: 0
[ 29 01 01 ]

Len = 14 [ bf dd 0b c5 0b b4 5a 3c 01 00 03 01 00 00 ]
FSN: 93 FIB 1
BSN: 63 BIB 1
<[1] MSU
[ bf dd 0b ]
Network Indicator: 3 Priority: 0 User Part: ISUP (5)
[ c5 ]
debian*COPC 12650 DPC 13323 SLS 3
[ 0b b4 5a 3c ]
CIC: 1
[ 01 00 ]
Message Type: Unknown
[ 03 ]
[Jan 4 17:59:59] ERROR[19658]: chan_dahdi.c:11917 dahdi_ss7_error: !! Unable to handle message of type 0x3

[Jan 4 17:59:59] ERROR[19658]: chan_dahdi.c:11917 dahdi_ss7_error: !! Unable to handle message of type 0x3 on CIC 1

The .call file used to make an outbound call is

Channel: Dahdi/g1/9044012514
CallerId: “ss7” <9044013750>
MaxRetries: 10
RetryTime: 5
WaitTime: 60
Account: ss7
Context: demo
Extension: s
Priority: 1
Archive: Yes

The config in chan_dahdi.conf is

;Sangoma A108 port 1 [slot:4 bus:5 span:1]
switchtype=euroisdn
context=tata
group=1
echocancel=yes
signaling=ss7 ;this is ss7 signaling
ss7type=itu ;using the ITU variant
ss7_called_nai=dynamic ;NAI for outgoing calls
ss7_calling_nai=dynamic ;NAI for incoming calls
ss7_internationalprefix=00 ;international prefix value for incoming calls
ss7_nationalprefix=0 ;national prefix value for incoming calls
ss7_subscriberprefix= ;subscriber prefix value for incoming calls
ss7_unknownprefix= ;unknown prefix value for incoming calls
ss7_explictacm=yes ;ACM is send as soon as call enters the dial plan…may not accepted yet though
linkset=1 ;arbitrary name for this set of channels
pointcode=13323 ;the point code for this system…aka SPC
adjpointcode=12650 ;the point code for the system that we are signaling to… aka APC
defaultdpc=12650 ;the point code for the system that the CICs will be negotiated with…aka DPC
networkindicator=national_spare ;NI value for MTP3
cicbeginswith=1 ;the starting value of the CICs
channel =>1-15
cicbeginswith=17 ;the starting value of the CICs
channel =>17-31 ;the channels that are CICs
sigchan=16 ;the signaling channel

Verions are
libss7-1.0.2
Asterisk 1.6.2.0
wanpipe 3.4.8

uname -a

Linux debian 2.6.26-2-686 #1 SMP Thu Nov 25 01:53:57 UTC 2010 i686 GNU/Linux

2

Howdy,

Try the vendor of your card and see if they can help.

Cheers.

3

I think problem is with Network-Indicator. Your card is configured for national spare

networkindicator=national_spare

which is 0x01

But when sending ISUP message you set it to 0x03 which is Reserved.

4

Thanks Amit,

I gave the NI as national_spare because for any other value, the asterisk console issued a warning, saying that it is receiving the NI as national_spare from the switch. However, as you said, I should try changing it and may be ignore the warning.

The update is that chan_ss7 worked flawlessly on my link with mostly default setting. So that means the link is not making error. Perhaps there is a bug in libss7 or some config problem. I will update.

Here is my working chan_ss7 1.4.3, wanpipe 3.5.18 and asterisk 1.6.2 config files that work with Sangoma A108 card.

cat /etc/asterisk/ss7.conf

[linkset-siuc]
enabled => yes
enable_st => no
use_connect => yes
hunting_policy => even_mru
context => ss7
language => da
t35 => 15000,timeout
subservice => auto

[link-l1]
linkset => siuc
channels => 1-15,17-31
schannel => 16

; The first CIC
firstcic => 1

enabled => yes
echocancel => no
echocan_train => 350
echocan_taps => 128

[host-debian]
; The host is enabled
enabled => yes
opc => XXXXX
dpc => siuc:XXXX

; Syntax: links => link-name:digium-connector-no
; The links on the host is ‘l1’, connected to span/connector #1
links => l1:1

[devices]
wanpipe1 = WAN_AFT_TE1, Comment

[interfaces]
w1g1 = wanpipe1, , TDM_VOICE, Comment

cat /etc/wanpipe/wanpipe1.conf

[wanpipe1]
CARD_TYPE = AFT
S514CPU = A
CommPort = PRI
AUTO_PCISLOT = NO
PCISLOT = 4
PCIBUS = 5
FE_MEDIA = E1
FE_LCODE = HDB3
FE_FRAME = NCRC4
FE_LINE = 1
TE_CLOCK = NORMAL
TE_REF_CLOCK = 0
TE_SIG_MODE = CCS
TE_HIGHIMPEDANCE = NO
TE_RX_SLEVEL = 430
LBO = 120OH
FE_TXTRISTATE = NO
MTU = 1500
UDPPORT = 9000
TTL = 255
IGNORE_FRONT_END = NO
TDMV_SPAN = 1
TDMV_DCHAN = 0
TE_AIS_MAINTENANCE = NO

TDMV_HW_DTMF = NO
TDMV_HW_FAX_DETECT = NO
HWEC_OPERATION_MODE = OCT_NORMAL

HWEC_DTMF_REMOVAL = NO
HWEC_NOISE_REDUCTION = NO
HWEC_ACUSTIC_ECHO = NO
HWEC_NLP_DISABLE = NO
HWEC_TX_AUTO_GAIN = 0
HWEC_RX_AUTO_GAIN = 0
HWEC_TX_GAIN = 0
HWEC_RX_GAIN = 0

[w1g1]
ACTIVE_CH = ALL
TDMV_HWEC = NO
MTU = 8

It may be noted that wanpipe1.conf for libss7 and chan_ss7 is the same with both having TDMV_DCHAN = 0

cat /etc/dahdi/system.conf

loadzone=us
defaultzone=us

#Sangoma A108 port 1 [slot:4 bus:5 span:1]
span=1,1,0,ccs,hdb3
bchan=1-31
echocanceller=mg2,1-15,17-31

Note that in dahdi/system.conf all channels are defined as bearer channels. chan_ss7 deals with the “D Channel” or signchan in its internal space as defined in ss7.conf

Thanks,
Bailoo.

5

I’m encountering a similar problem with a Digium TE420 card using libss7 and asterisk 1.6.

I don’t believe the “message of type 0x3” is referring to network indicator. It is my understanding that this is referring to ISUP message type 0x3 which is INR (Information Request). I have the same conditions the original poster explained where I can make calls to Asterisk fine, but cannot make calls from Asterisk as I get the same error message.

For what it’s worth, CLIP seems to be the root cause in my case, but I haven’t figured it all out yet. I did notice that if CLIP was provisioned for the called party (i.e. in the adjacent exchange NOT Asterisk) I would get this error, but if CLIP was not provisioned (turned off) I could call from Asterisk without any issues. Let me reiterate that these CLIP settings are the ones in the adjacent exchange and not the Asterisk specific CLIP settings.