hi Graeme,
At one site I have the CDRs being imported into a database for similar purposes, and came across some issues you may also find. The biggest one I came across is that the time format in the CDRs doesn't match the date/time datatype of the database, or an easily converted datatype: in the end the imported CDRs have been treated as pure text, then stripped down to it's components, which are then in turned into correct database datatypes. The next biggest problem is something that is totally understandable but mildly frustrating: the same call can appear in multiple CDRs, with different H323-conf-id values (if you watch syslog with a call going through a complicated transfer sequence, with accounting debug on, you'll see it happening), so how do you isolate a single call in all it's steps? (In your example, if extension 356 called extension 366 but the call was then transferred on out to 1-800-number-that-shouldn't-have-been-called-by-356, you won't see that as a call from 356?). You can track on feature correlation id, and select calls based on "h323_conf_id in feature_correlation_id" and you should see all of the call legs.
You'll find you're collecting far more data than you wish if you just import all CDRs exported via ftp: of the 120-or so fields in each record, I think we actually use thirty (at the very most) in this particular application - and I'm including derived fields in that. If you collect CDRs using RADIUS you can filter which fields are reported, but afaik CCA doesn't provide that option? (Please - anyone - if I'm wrong let me know!). CCA does let you export via ftp, and it also lets you setup syslog, but getting plain text via ftp is easier than syslog into database.
Andy
Message was edited by: ANDY BILLINGTON. (Added reference to feature correlation id vs h323 conf id)
