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. > > -- 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@xxxxxxx W: http://dus.net HRB: 51060 AG: D?seldorf GF: Andree Meier, Udo Dluzinski
|