[asterisk-ss7] Some Channels are Blocked with remote maintanence

[Gregory Massel]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-ss7/attachments/20111121/c80c4044/attachment.htm>