I used to do a lot of telecom consulting for a large customer who we transitioned to a 100% SIP carrier. This particular carrier used AdTran TA 900 series gateways to provide T1-CAS/PRI to older phone switches. The project was particularly interesting because the carrier let me (a third-party analyst) have unheard of access to their infrastructure. Once I earned their trust, I had access to all of the AdTran devices, as well as their core switching and CDR reporting tools.
I actually just put wraps on a Ruby script that I use to analyze call concurrency from CDR exports (from CDRTool [1]). I dropped it in a Gist if you're interested. It takes a CDRTool query export (CSV data) and outputs a tab-delimited concurrency datafile that can be used pretty easily with gnuplot. The script could be easily adapted to any CDR report that uses single-line call entries.
https://gist.github.com/1706903
1 - http://www.ag-projects.com/CDRTool.html
PS - If you find this at all interesting, hit me up on Twitter to keep in touch https://twitter.com/#!/bradleyland
These days I'm swung back more towards DBs and servers and stuff, but not a CDR in sight thankfully.
Liked your ruby; not a ruby ninja myself but it looks quite readable and almost pythonic :)
I worked telecom billing about 10 years ago... Our system consisted of a couple dozen fairly large C++ programs, and numerous DBF tables.
This system was originally written in Clipper(1), which IIRC defines numeric as an 18 digit text field. Well, when that particular program got ported to C++, the author simply used a 32-bit int in place of NUMERIC... Which needless to say worked just fine up until we started getting clients that had values larger than 2^31-1 for that field.
The scary part, is that it would just overflow, so you wouldn't get any errors... It wasn't until some guy in ops noticed a number that just seemed a little too odd.
1: Serendipity: The founder was a medical student that happened to know clipper, that happened to have a friend that had just started a telecom company and needed a billing solution (right after the Bell breakup).
Indeed, the systems for generating the dollar value on our invoice were almost entirely separate from the systems for generating the line-items on our invoices, and they never did agree, and our upstream provider didn't even see that as a problem.
My boss at one point, if I understood him correctly, claimed that (in 2009 or 2010), the process for the telco to know how much to bill us involved human operators exporting to a reel of magnetic tape, moving the magnetic tape reel across the room, and importing it into a different database. He wasn't much of a one for leg-pulling, but I dunno.