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, ¤t); > isup_msg_end_optional_part(msg, sizeof(msg), ¤t); > > 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>
|