BCM50 CDR – Call Detail Recording – Pull Data Demystified!

The Nortel BCM50 is a workhorse of a phone system. Designed for small businesses, it took customers from their older MICS/CISC/616/824 systems into the IP age. Based around a Linux Operating system running ported code from the NT based BCM200/BCM400 family, the BCM50 (and it’s bigger brother, the BCM450) allowed customers to utilise their existing phones, and expand to IP trunks, IP sets and a host of other features.

If you’re using a BCM50 you may have some call accounting software, now this will usually obtain it’s data in one of three ways.

#1 FTP Push – the maximum frequency of this is daily, so makes it less useful for realtime reporting.
#2 Pull – using a nortel supplied application, you can pull CDR files from the BCM via some command line switches. Up until now, this was the easiest way I had found to utilise CDR data.
#3 Live Stream – again, using a nortel supplied application, a live stream of the CDR data is available to the screen. However, without figuring out how this works or hooks in, it’s impossible to use.

Now #1 and #2 supply you with the same sort of log files, and it’s #2 which I’m going to demystify today, as it’s recently become possible to pull the files directly from the BCM50 without any third party software or dll files. #3 at this point, still remains a mystery sadly.

So I started off by having a look round my BCM’s hard disk, mounted on my local PC, and I found the apache log file. This was a goldmine, and instantly things clicked.

What happens is that the nortel app sends a request to the BCM on the https port (443) to /upgrade-cgi-bin/clipcgi.exe a number of query string variables are parsed;

?zip=no&delete=yes&startlow=0&starthigh=0&stoplow=1&stophigh=1&timestamp=2014-11-23_16.00.00&debug=no

So these appear to generate the log files for you. It asks if you want them zipped, should they be deleted afterwards, and a timestamp. Debug causes more verbose data to be returned to the client as plain text. I’m unsure at this point on startlow, starthigh, stoplow and stophigh.

So, with debug on, this is what you’ll get;

CLIP CGI: zip? NO
CLIP CGI: del? NO
CLIP CGI: ClientTimestamp: 2014-11-30_11.25.00
CLIP CGI: debug? YES
CLIP CGI: startlow  = 0
CLIP CGI: starthigh = 0
CLIP CGI: stoplow   = 1
CLIP CGI: stophigh  = 1
First Entering into handleDirTree, flag = 1
First Entering into handleDirTree, flag = 1
First Entering into handleDirTree, flag = 0
First Entering into handleDirTree, flag = 0
First Entering into handleDirTree, flag = 0
get a file
First Entering into handleDirTree, flag = 0
First Entering into handleDirTree, flag = 0
finish    GetFileList()
CDRClip DONE
CDRClip Succeeded
file name = /var/nn/CDRDataFiles/Record.20141202190038
copyItem = /bin/cp /var/nn/CDRDataFiles/Record.20141202190038 /var/nn/voice/pulldata 2>&1>/dev/null
after system call rc = 0
system execution status 0
chmod file /var/nn/CDRDataFiles/Record.20141202190038
MarshallFiles DONE
>>rc=0<<
>>pullTransferSize=569<<

This gives you a bit of an inkling as to what’s going on. You then request /cdr-pull/CDRFileListings.index which is a file listing, and then say /cdr-pull/Record.20141123155620 for the record file. Save that to disk. Then the system posts some data to /Upgrade-cgi-bin/deletefilecgi.exe – I’m unsure exactly what at this point, but I intend to packet capture a conversation soon to see what it does. I’m guessing that a filename is passed, and it will delete the file.

Finally, this is called; /Upgrade-cgi-bin/FinishCDR.exe?rc=0&failed=0&passed=1&bytes=66&numFiles=1&largest=66&smallest=0&msg=&timestamp=2014-11-23_15.57.30&debug=no which loads the statistics into the CDR Transfer Statistics in Element Manager. Here’s what you’ll see back;

FinishCDR queryString = rc=2&failed=0&passed=0&bytes=0&numFiles=0&largest=0&smallest=0&msg=&timestamp=2014-11-30_11.12.30&debug=yes
Debug        = 1
clearOnly    = 0
getStatsOnly = 0
rc           = 2
numFailed    = 0
numPassed    = 0
numBytes     = 0
numFiles     = 0
largest      = 0
smallest     = 0
timestamp    = 2014-11-30_11.12.30
message      =
R = 0
NumOfFiles = 238
data size = 4
>>rc=0<<

That’s all! So with this information you can poll the BCM50 (and probably it’s bigger brother) directly and drag the data off whenever you wish, I’d imagine a frequency of once a minute could be sustained assuming you can keep up processing the data.

Posted in BCM50, Phone Systems


Leave a Reply


Powered by WordPress. Designed by Försäkra Online.