[asterisk-ss7] chan_ss7 block CIC's
asterisk at nicox.org
asterisk at nicox.org
Mon Feb 26 08:41:17 MST 2007
Which Version of Asteris/Zaptel and chan_ss7 aou use?
Thanks
Nico
On Mon, 26 Feb 2007, Udo Dluzinski wrote:
> Hi Kristian,
>
> Kristian Nielsen schrieb:
>> asterisk at nicox.org writes:
>>
>>
>>> I have blocked some CIC's with ss7 block 6 15
>>> and if i check the status with ss7 linestat i see that the CIC's are
>>> blocked, BUT Asterisk initiates new calls to this CIC's
>>>
>>> Did anybody else see this before?
>>>
>>
>> In SS7/ISUP, the blocking of a CIC is a one-way thing.
>>
>>
> That is wrong. Local blocking is for maintain cic´s or something and all
> blocking messages require an ACK message from exchange. After CGB the
> exchange shoudnt signalling any inbound to the blocked cic´s. Read about
> here:
> http://www.asknumbers.com/SS7ISUPMessages.aspx
>
> We have chan_ss7 with 4 spans and recovered an other blocking bug. We
> block one cic on span 1 e.g cic 19 with the command:
> ss7 block 19 1
> we got on the cli:
> ss7 block 19 1
> Sending Blocking message to peer
> Sending Blocking message to peer
> Sending Blocking message to peer
> Sending Blocking message to peer
> [Feb 26 16:15:21] NOTICE[20656]: l4isup.c:3619
> do_group_circuit_block_unblock: Sending CIRCUIT GROUP BLOCKING, cic=19,
> mask=0x00000001.
> [Feb 26 16:15:21] NOTICE[20656]: l4isup.c:3619
> do_group_circuit_block_unblock: Sending CIRCUIT GROUP BLOCKING, cic=51,
> mask=0x00000001.
> [Feb 26 16:15:21] NOTICE[20656]: l4isup.c:3619
> do_group_circuit_block_unblock: Sending CIRCUIT GROUP BLOCKING, cic=83,
> mask=0x00000001.
> [Feb 26 16:15:21] NOTICE[20656]: l4isup.c:3619
> do_group_circuit_block_unblock: Sending CIRCUIT GROUP BLOCKING, cic=115,
> mask=0x00000001.
> [Feb 26 16:15:21] NOTICE[29691]: l4isup.c:3134 process_cga: Process CGA,
> cic=19, range=32
> [Feb 26 16:15:21] NOTICE[29691]: l4isup.c:3134 process_cga: Process CGA,
> cic=51, range=32
> [Feb 26 16:15:21] NOTICE[29691]: l4isup.c:3134 process_cga: Process CGA,
> cic=83, range=32
> [Feb 26 16:15:21] NOTICE[29691]: l4isup.c:3134 process_cga: Process CGA,
> cic=115, range=32
>
> we got an ACK for cic 19 on all 4 spans :-)
>
> Thats not okay because all channels have ascending cic numbers:
> voip-dus-06*CLI> ss7 show channels
> Linkset: vstCLI>
> CIC 1 Busy
> CIC 2 Idle
> CIC 3 Idle
> CIC 4 Busy
> CIC 5 Idle
> CIC 6 Busy
> CIC 7 Idle
> CIC 8 Busy
> CIC 9 Idle
> CIC 10 Busy
> CIC 11 Idle
> CIC 12 Busy
> CIC 13 Idle
> CIC 14 Busy
> CIC 15 Busy
> CIC 17 Busy
> CIC 18 Busy
> CIC 19 Idle BLOCKED Local Maintenance
> CIC 20 Busy
> CIC 21 Busy
> CIC 22 Busy
> CIC 23 Busy
> CIC 24 Busy
> CIC 25 Busy
> CIC 26 Busy
> CIC 27 Busy
> CIC 28 Idle
> CIC 29 Idle
> CIC 30 Initiating call
> CIC 31 Idle
> CIC 33 Busy
> CIC 34 Busy
> CIC 35 Idle
> CIC 36 Idle
> CIC 37 Idle
> CIC 38 Busy
> CIC 39 Busy
> CIC 40 Initiating call
> CIC 41 Idle
> CIC 42 Busy
> CIC 43 Busy
> CIC 44 Idle
> CIC 45 Idle
> CIC 46 Busy
> CIC 47 Idle
> CIC 48 Busy
> CIC 49 Idle
> CIC 50 Busy
> CIC 51 Busy BLOCKED Local Maintenance
> CIC 52 Busy
> CIC 53 Idle
> CIC 54 Busy
> CIC 55 Idle
> CIC 56 Busy
> CIC 57 Idle
> CIC 58 Busy
> CIC 59 Busy
> CIC 60 Idle
> CIC 61 Busy
> CIC 62 Idle
> CIC 63 Idle
> CIC 65 Idle
> CIC 66 Busy
> CIC 67 Idle
> CIC 68 Initiating call
> CIC 69 Idle
> CIC 70 Busy
> CIC 71 Idle
> CIC 72 Busy
> CIC 73 Idle
> CIC 74 Busy
> CIC 75 Busy
> CIC 76 Busy
> CIC 77 Idle
> CIC 78 Initiating call
> CIC 79 Busy
> CIC 80 Busy
> CIC 81 Busy
> CIC 82 Busy
> CIC 83 Busy BLOCKED Local Maintenance
> CIC 84 Idle
> CIC 85 Idle
> CIC 86 Initiating call
> CIC 87 Idle
> CIC 88 Busy
> CIC 89 Idle
> CIC 90 Busy
> CIC 91 Busy
> CIC 92 Busy
> CIC 93 Idle
> CIC 94 Busy
> CIC 95 Idle
> CIC 97 Idle
> CIC 98 Initiating call
> CIC 99 Idle
> CIC 100 Busy
> CIC 101 Busy
> CIC 102 Busy
> CIC 103 Idle
> CIC 104 Busy
> CIC 105 Idle
> CIC 106 Busy
> CIC 107 Idle
> CIC 108 Busy
> CIC 109 Busy
> CIC 110 Busy
> CIC 111 Idle
> CIC 112 Idle
> CIC 113 Idle
> CIC 114 Idle
> CIC 115 Idle BLOCKED Local Maintenance
> CIC 116 Busy
> CIC 117 Idle
> CIC 118 Busy
> CIC 119 Busy
> CIC 120 Idle
> CIC 121 Busy
> CIC 122 Idle
> CIC 123 Idle
> CIC 124 Busy
> CIC 125 Idle
> CIC 126 Busy
> CIC 127 Idle
>
> We think that is a bug definitely.
>
> The good thing is that an unblock do the same :-)
> ss7 unblock 19 1
> Sending Unblocking message to peer
> Sending Unblocking message to peer
> Sending Unblocking message to peer
> Sending Unblocking message to peer
> [Feb 26 16:17:42] NOTICE[20656]: l4isup.c:3619
> do_group_circuit_block_unblock: Sending CIRCUIT GROUP UNBLOCKING,
> cic=19, mask=0x00000001.
> [Feb 26 16:17:42] NOTICE[20656]: l4isup.c:3619
> do_group_circuit_block_unblock: Sending CIRCUIT GROUP UNBLOCKING,
> cic=51, mask=0x00000001.
> [Feb 26 16:17:42] NOTICE[20656]: l4isup.c:3619
> do_group_circuit_block_unblock: Sending CIRCUIT GROUP UNBLOCKING,
> cic=83, mask=0x00000001.
> [Feb 26 16:17:42] NOTICE[20656]: l4isup.c:3619
> do_group_circuit_block_unblock: Sending CIRCUIT GROUP UNBLOCKING,
> cic=115, mask=0x00000001.
> [Feb 26 16:17:42] NOTICE[29691]: l4isup.c:3189 process_cua: Process CUA,
> cic=19, range=32
> [Feb 26 16:17:42] NOTICE[29691]: l4isup.c:3189 process_cua: Process CUA,
> cic=51, range=32
> [Feb 26 16:17:42] NOTICE[29691]: l4isup.c:3189 process_cua: Process CUA,
> cic=83, range=32
> [Feb 26 16:17:42] NOTICE[29691]: l4isup.c:3189 process_cua: Process CUA,
> cic=115, range=32
>
> Greets
>
> Udo
>
>> So if exchange A does a local blocking of CIC 6, that means that a remote
>> exchange B at the other end of CIC 6 will no longer initiate incoming calls on
>> CIC 6. But it does not prevent in any way exchange A from initiating a call on
>> CIC 6 towards exchange B.
>>
>> I do not know/remember the details of blocking in chan_ss7, but I suspect that
>> the above is the reason that local calls still take place on locally blocked
>> circuits. If so, it should be fairly simple to add something to the code that
>> marks blocked curcuits busy in some way, so that the channel allocation will
>> skip them.
>>
>> Hope this helps,
>>
>> - Kristian.
>>
>>
>
>
> --
> Für weitere Fragen stehe ich Ihnen selbstverständlich zur Verfügung und verbleibe bis dahin,
>
> mit freundlichen Grüßen
>
> ____________________________________________________
> Udo Dluzinski | CTO
>
> dus.net GmbH
>
> Hauptsitz
> Straelener Weg 83
> D-40472 Düsseldorf
>
> NL Connecta Park
> In der Steele 29
> D-40599 Düsseldorf
>
> T: +49 (0)211 2370 41-47
> F: +49 (0)211 2370 41-44 oder 45
> E: dlu at dus.net
> W: http://dus.net
>
> HRB: 51060
> AG: Düseldorf
> GF: Andree Meier, Udo Dluzinski
>
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-ss7 mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-ss7
>
More information about the asterisk-ss7
mailing list