No, that is not possible with SER. Jan. On 11-11 22:12, verbalkint(a)virgilio.it wrote: >I have a very urgent question and I would know if anyone is dealing with >CAC on SER....exist any methods/function in statefull proxy mode to count >simultaneous calls coming from the same calling party number (from HF), >feeded from one IP PBX (like Asterisk) with just one single digest account >and one permitted uri, in case setting two call thresholds (one for the >allowed simoltaneous calls and one for the allowed call per second)? If >yes, is it possible blacklisting/barring this user (in a cached table with >function like file permission.deny) for some time/forever if the call counters >exceed limit settled by threshold?

Hi Jan, thank you for your prompt replay....just an ultimate question about this topic..with the avp_db module and/or avpops module and some external polling function on DB (query every 3 minutes (e.g.) that counts the INVITE method and sip_status (200) and not yet disconnected (not yet received BYE) sorted by from HF)...if this count exceeds some limit (settled per username@domain) stored in the avp table (simultaneous call limit), an external script insert the hit username in the blocked ACL....does it make sense for you? in case, which drawbacks do you see? Best regards, Verbal ----- Original Message ----- From: "Jan Janak" <jan(a)iptel.org> To: <verbalkint(a)virgilio.it> Cc: <serusers(a)lists.iptel.org> Sent: Sunday, November 14, 2004 1:10 PM Subject: Re: [Serusers] Call Admission Control on SER _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

if I not yet received the BYE related with the INVITE (same sip_callid), I can suppose with some margin error that this call is still alive....or i really wrong/forgot something?? what I mean, if I polling in real-time the DB, I can fetch the real time stats on ended calls, refused calls, missed-calls and live calls even if I know that SER don't 'retain' the call state but maybe I can 'derive' this call state from accounting/polling from/to DB.....or maybe the risk to not account the BYE message is too high???