[asterisk-ss7] chan_ss7 block CIC's

[Anton]

In the scheme A <--> B, description given below describes 
that is CIC is blocked by side A, that side B cannot 
initiate calls to A, but A can initiate to B unless B also 
sent a blocking request.
(http://www.asknumbers.com/SS7ISUPMessages.aspx)

Quoting ---
Blocking (BLO) message sent only for maintenance purposes to 
the exchange at the other end of a circuit, to cause an 
engaged condition of that circuit for subsequent calls 
outgoing from that exchange. When a circuit is used in the 
bothway mode of operation, an exchange receiving the 
blocking message must be capable of accepting incoming 
calls on the concerned circuit unless it has also sent a 
blocking message. Under certain conditions, a blocking 
message is also a proper response to a reset circuit 
message.

On 26 February 2007 20:19, 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.