[asterisk-ss7] chan_ss7 block CIC's
Anders Baekgaard
ab at sifira.dk
Mon Feb 26 09:08:49 MST 2007
Hi Udo
There is a bug the the CLI block/unblock commands that causes the
block/unblock to be sent for every 32 CICs in a linkset. This is fixed in the
next version of chan_ss7.
Best regards
Anders Baekgaard
On Monday 26 February 2007 16: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.
More information about the asterisk-ss7
mailing list