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]> 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]>> 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]> >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> >> >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
