[asterisk-ss7] chan_ss7 block CIC's
Udo Dluzinski
dlu at dus.net
Mon Feb 26 08:19:40 MST 2007
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
More information about the asterisk-ss7
mailing list