the IPs are internally kept in a tree that assumes that the data is IP-only - each node can have maximum 256 sub-nodes, but with some twists I can do it more generic, to support any kind of data..
Regards, Bogdan Brett Nemeroff wrote: > Why is that? Does it provide rate-limiting for subnets of sending > traffic as well? > > Seems like the function needs to be redone altogether with the whole > tree business.. > -Brett > > > On Mon, Jun 29, 2009 at 12:02 PM, Bogdan-Andrei Iancu > <[email protected] <mailto:[email protected]>> wrote: > > OK, let me see how difficult is to re-design the pike module, as > so far, the way the internal data is kept is highly IP-format > dependent. > > > Regards, > Bogdan > > Brett Nemeroff wrote: > > Yeah, that's a great idea actually, I could just concatenate > some PVs to form a key like $si-$rU. > > > On Mon, Jun 29, 2009 at 8:53 AM, Bogdan-Andrei Iancu > <[email protected] <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>>> wrote: > > Hi Brett, > > This will be kind of pike but instead of using as input the > source > IP string, it should use a custom string you build form script, > right ? this string will be a kind of key (logical one) to > identify the loop. > > Regards, > Bogdan > > Brett Nemeroff wrote: > > Hey All, > I was wanting to submit a feature request for loop > detection. > Specifically NOT SIP loop detection, but when another > technology / B2BUA is involved where max-forwards can't be > used. This is for big loops. > The idea is similar to the pike module. However, you > bascically look at the to_did and the source IP and if > you see > more than X calls in Y period, begin to reject them for > Z seconds. > > Simple enough. This has come up a dozen times for me > and for > now I have to handle it with kludge of memcache, and perl > scripts to detect these issues in my cdr. > > The loops are a bit nuts and are always the results of > someone > doing something stupid (but hey, it does happen). The loops > are like, my customer sends me a call to one of thier > own DIDs > (they've misrouted it to me) and I send it to my > carrier, who > sends it to the pstn, back to my customer, back to me, > etc.. > There may be a ss7 portion in there so it keeps looking > like a > new call on the SIP side. > So without anything, this can clog up my call paths pretty > quickly, the proposed feature would blacklist the source_ip > to_did combination for a period of time to kill the loop. > > Thoughts? > -Brett > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Users mailing list > [email protected] > <mailto:[email protected]> > <mailto:[email protected] > <mailto:[email protected]>> > > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > > _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
