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@xxxxxxxxx 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.
|