Why is that? Does it provide rate-limiting for subnets of sending traffic as well?<div><br></div><div>Seems like the function needs to be redone altogether with the whole tree business..</div><div>-Brett</div><div><br><br>

<div class="gmail_quote">On Mon, Jun 29, 2009 at 12:02 PM, Bogdan-Andrei Iancu <span dir="ltr">&lt;<a href="mailto:bogdan@voice-system.ro">bogdan@voice-system.ro</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

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.<div class="im"><br>
<br>
Regards,<br>
Bogdan<br>
<br>
Brett Nemeroff wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
Yeah, that&#39;s a great idea actually, I could just concatenate some PVs to form a key like $si-$rU.<br>
<br>
<br></div><div><div></div><div class="h5">
On Mon, Jun 29, 2009 at 8:53 AM, Bogdan-Andrei Iancu &lt;<a href="mailto:bogdan@voice-system.ro" target="_blank">bogdan@voice-system.ro</a> &lt;mailto:<a href="mailto:bogdan@voice-system.ro" target="_blank">bogdan@voice-system.ro</a>&gt;&gt; wrote:<br>


<br>
    Hi Brett,<br>
<br>
    This will be kind of pike but instead of using as input the source<br>
    IP string, it should use a custom string you build form script,<br>
    right ? this string will be a kind of key (logical one) to<br>
    identify the loop.<br>
<br>
    Regards,<br>
    Bogdan<br>
<br>
    Brett Nemeroff wrote:<br>
<br>
        Hey All,<br>
        I was wanting to submit a feature request for loop detection.<br>
        Specifically NOT SIP loop detection, but when another<br>
        technology / B2BUA is involved where max-forwards can&#39;t be<br>
        used. This is for big loops.<br>
        The idea is similar to the pike module. However, you<br>
        bascically look at the to_did and the source IP and if you see<br>
        more than X calls in Y period, begin to reject them for Z seconds.<br>
<br>
        Simple enough. This has come up a dozen times for me and for<br>
        now I have to handle it with kludge of memcache, and perl<br>
        scripts to detect these issues in my cdr.<br>
<br>
        The loops are a bit nuts and are always the results of someone<br>
        doing something stupid (but hey, it does happen). The loops<br>
        are like, my customer sends me a call to one of thier own DIDs<br>
        (they&#39;ve misrouted it to me) and I send it to my carrier, who<br>
        sends it to the pstn, back to my customer, back to me, etc..<br>
        There may be a ss7 portion in there so it keeps looking like a<br>
        new call on the SIP side.<br>
        So without anything, this can clog up my call paths pretty<br>
        quickly, the proposed feature would blacklist the source_ip<br>
        to_did combination for a period of time to kill the loop.<br>
<br>
        Thoughts?<br>
        -Brett<br>
<br>
        ------------------------------------------------------------------------<br>
<br>
        _______________________________________________<br>
        Users mailing list<br></div></div>
        <a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a> &lt;mailto:<a href="mailto:Users@lists.opensips.org" target="_blank">Users@lists.opensips.org</a>&gt;<div class="im"><br>
        <a href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
         <br>
<br>
<br>
</div></blockquote>
<br>
</blockquote></div><br></div>