Well, I have no problem releasing the code, but there are a few technical constraints. - This is very much a test jig. For example, it uses psql via a pipe to do all database access. That stuff is layered out, so it can easily be directed at a real postgres perl module, but we have some issues with perl modules so tend not to use them, at least in early development. I would expect it to start groaning at around 100 calls/minute. We're in a beta test at the moment and will be in production within a month. When our call volume increases, we will certainly recode this in C. However, using direct database access from perl would probably give an 80% of the gains, so that might be the next step. - It depends on a special syslogd version. The change is simple -- the timestamp is written as "seconds since 1970" to msec precision instead of the human-readable representation. Unix time_t is simply more natural for this kind of work. I didn't attempt to layer the timestamp processing, but it only occurs in one or two places, so introducing mktime() and giving up on msecs would generalize this. I have a converted Linux syslogd.c. I'm pretty sure less than 10 lines changed. I know I converted a FreeBSD syslogd as well, but I can't find it. - The script uses the database to keep state. The first INVITE inserts the call detail and the call is active (no call_end time). The first BYE with matching call_id updates the call_end time. Heuristics are then applied to match each log entry from the gateway (cisco based) to the database entry. This allows detection of missed BYEs. The point is that the the database is integral in the matching algorithm. The side-benefit is that the database can be used to display active calls. The algorithm is dependent on efficient database indexing. - There is no particular dependency on database type except I do record endpoint IPs as Postgres "inet" types, but these are not searched so could as easily be "char" type. A "timestamp" type of some kind is pretty much crucial. So, I'm happy to push the code out to the group "as is". If nothing else, there are probably code fragments worthy of harvest. I can also put a bit of time into generalizing it a little before making it available. Opinions? Andy -- Andrew Fullford Email: andy(a)august.net August.Net Services, LLC Web: www.august.net