[asterisk-ss7] chan_ss7 bug - was Re: Some Channels are Blocked with remote maintanence

Gregory Massel greg at csurf.co.za
Thu Dec 8 01:36:14 CST 2011 

I have confirmed and the remote end is deeming it to be a protocol 
violation and raising an ISDN Alarm when chan_ss7 generates REL or RLC 
messages with Optionals enabled and an empty optional section.

I'll try work on a patch for l4isup.c. It doesn't look like it should be 
too difficult to change the applicable code.


On 2011/11/21 02:11 PM, Gregory Massel wrote:
> Looking at l4isup.c and the dump, I'm just wondering, is it correct 
> behaviour to have an empty optionals section?
>
> e.g. code like the following in isup_send_rlc():
> isup_msg_start_optional_part(msg, sizeof(msg), &varptr, &current);
> isup_msg_end_optional_part(msg, sizeof(msg), &current);
>
> Should this not just be stripped out?
>
> Similar code exists in isup_send_rel(), except that optionals are 
> added in the event of certain if() conditions being matched. Again, 
> the question I have is should the isup_msg_start_optional_part and 
> isup_msg_end_optional_part functions even be called if the conditions 
> are such that no optionals need to be added?
>
> --Greg
>
> On 2011/11/21 01:36 PM, Gregory Massel wrote:
>> 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 byhttp://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 byhttp://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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-ss7/attachments/20111208/0a7f60d8/attachment-0001.htm>

More information about the asterisk-ss7 mailing list