I have the exact same condition with chan_ss7 on Asterisk 1.4 and
Asterisk 1.8 and can confirm that I've run all versions of chan_ss7 from
1.3 up to 2.1.0 (2.1.0 on Asterisk 1.8 and the previous versions on
Asterisk 1.4).
The remote end is, to the best of my knowledge, a Siemens EWSD.
The following feedback was provided by the remote carrier and may prove
useful in explaining the problem:
SWTNRB 26 1-26 TRUNK BW 0-24 2-26 IDLE
SWTNRB 27 1-27 TRUNK BW 0-24 2-27 INC &
FRCD &
IALM
SWTNRB 28 1-28 TRUNK BW 0-24 2-28 IDLE
SWTNRB 29 1-29 TRUNK BW 0-24 2-29 INC &
FRCD &
IALM
SWTNRB 30 1-30 TRUNK BW 0-24 2-30 IDLE
With the IALM condition is caused by "end of optional parameter in the
wrong place".
If you should see in the attachment I have highlighted the REL and RLC
message from your nodes.
Both of these have the optional parameter "indicated".
If it is possible can you please set optional parameters OFF (
parameter indicator =0) for
These two messages.
If you can let me know so that we can reset the circuits as we have done
previously.
They also provided the following:
--------------------------------------------------------------------------------
Octet001 ITU-T SS7 Count=000001 Time=08/22/2011 13:21:14:023
--------------------------------------------------------------------------------
10010010 BIB/BSN (146) 1/18
11111001 FIB/FSN (249) 1/121
..001110 SU type/length (14) MSU14
00...... Spare 0
--------------------------------------------------------------------------------
Octet004 Service information octet
--------------------------------------------------------------------------------
....0101 Service indicator (5) ISUP ISDN User Part
..00.... Message priority 0
11...... Network indicator (3) NAT1 National network
--------------------------------------------------------------------------------
Octet005 Routing label
--------------------------------------------------------------------------------
........ DPC 01-1-03-0 JNL#1
........ OPC 00-6-01-0 SWITCHTEL
1001.... SLS 9
--------------------------------------------------------------------------------
Octet009 Circuit identification code
--------------------------------------------------------------------------------
........ CIC 217
0000.... Spare 0
--------------------------------------------------------------------------------
Octet011 ISUP Release message
--------------------------------------------------------------------------------
00001100 Message type (12) REL Release
00000010 Pointer->cause 2
00000100 Pointer->optionals 4
--------------------------------------------------------------------------------
Octet014 Cause indicators parameter
--------------------------------------------------------------------------------
00000010 Parameter length 2
....0101 Location (5) Private network serving the remote user (RPN)
...0.... Spare 0
.00..... Coding standard (0) CCITT standard
1....... Extension bit (1) Last octet
.0010000 Cause (16) Normal call clearing
1....... Extension bit (1) Last octet
--------------------------------------------------------------------------------
Octet017 ISUP End of optional parameters
--------------------------------------------------------------------------------
00000000 Parameter name code (0) ISUP End of optional parameters
--------------------------------------------------------------------------------
Checksum CRC16................ 0001110100001111 hex=1D0F
--------------------------------------------------------------------------------
As far as I am aware, there is no way to disable the optionals in chan_ss7.
Interestingly, the is not on all REL and RLC messages, only some of them.
I guess it's time to look through the source code, but this hasn't
proven terribly problematic for me thus far because it's only a few
random CICs that block in that state. It seems the remote end does
eventually remove the admin block by itself after a certain amount of
time, but restarting asterisk or chan_ss7 won't help. Usually I just get
the guys on the remote end to manually clear the condition.
On 2011/11/21 10:35 AM, Stefan Schmidt wrote:
Hello list,
i have two E1 running on a asterisk 1.8 with chan_ss7 which i have set
to production state last week. And after around 5000 calls i can see
that 3 channels are in state BLOCKED Remote Maintenance. My carrier said
he hasnt blocked anything on this two E1 lines but he can see some
messages even on busy lines he doesnt understand.
Asterisk was automatically restarted every night but these three
channels stay at this state.
Is this a known bug or what can i do to solve this problem?
asterisk verison 1.8 (Asterisk SVN-schmidts-unleash-the-beast-r343849)
chan_ss7 version (chan_ss7 version 2.1.0) but with some patches to isup
for connected line information and also the patch for the additional
calling party header.
thanks!
best regards
stefan schmidt
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-ss7 mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-ss7
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-ss7 mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-ss7
