CDR via IP on 81c

[rfwhite]

81c with Symposium 4.2

I'd like to make use of the cdr info that comes directly from the switch. Because of our traffic volume the data badly overruns the existing tty port. I could add another port but that seems like a halfway solution. I don't have OTM. Anybody who could tell me how to get cdr stuff via the ip connection?

 

[johnpoole]

not from the switch ip, cdr doesn't set up that way, and a second serial port from the switch is not a solution. i have in the past used pcplus to capture the data to a txt file and ftp that file to a server on a schedule.. a serial server would work on the cdr port, making sure you are set up to accept streaming data

john poole
bellsouth business
columbia,sc

 

[I2007]

We often use buffers from Lantronix (CoBox-FL), to convert serial data and transmit it over Ethernet with the FTP protocol and it works perfect. We also connect it to a TTY port where we can manage the serial port on the ITG card ie. It can store several MB's of data. You can also use UDS100 which is smaller and onl have 1 MB buffer, but it works fine.

i2007

 

[rfwhite]

I don't currently have a problem with getting the data where I need it once I get it out of the switch, but the buffers apparently fill in the switch after just a few minutes and some cdr information is lost as a result. The only solution I could see was to get a bigger pipe coming out of the switch.

 

[acewarlock]

How are you collecting the CDR data from the port now? in your question you state your using a tty port is that going to a printer?

 

[rfwhite]

Capturing with ProComm on a pc connected to the cdr tty port.

 

[johnpoole]

here's a script that will turn capture on, wait 12 hours turn it off and start over, i've used this on a cdr pc before. if you modify you file path, it will even save it with the date stamp..

proc main
loop:
capture on
pause 43200
capture off
goto loop
endproc

john poole
bellsouth business
columbia,sc

 

[rfwhite]

Right, thanks; but I still would have the problem of overrunning the buffers after a few minutes because of the amount of cdr data being output. I have looked at the call-by-call stuff in Symposium. If we use historical reporting as opposed to near real time I can get what I need from Crystal Reports but it would be very useful not to have to wait for the next interval.

 

[johnpoole]

the buffer will not be a factor if you dumping to a cap file, i don't know how much traffic you have but i am using that setup to dump my 81 (7000 stations) and 2 remote switches of 3000 stations.. the redisplay buffer is saved in a .cap file

john poole
bellsouth business
columbia,sc

 

[acewarlock]

What speed is your TTY port set for?

 

[rfwhite]

Maybe it is just the 9600 link speed that is the bottleneck. The closest example I can give is that it looks similar (amount of data-wise) to what you would see on a tty displaying d channel messaging with all the options 'On'. We have a high call volume and extremely short talk times, thus a tremendous amount of cdr activity. I have no trouble capturing or even sending data across to a Sun workstation for the first few minutes or under low traffic conditions, but when busy times hit there are large gaps in cdr and several minutes' delay at times.

 

[acewarlock]

There is a prompt somewhere but I can't remember where it is, but you can set CDR to High Priorty for buffers and I think you can raise the tty speed also.

 

[rfwhite]

That sounds promising, but would those buffers be common to the ones for call processing? I wouldn't want to chance slowing the overall throughput of call flow.

 

[johnpoole]

no the txt buffer is not used for call processing, the connection is stored in dup on the ram's, txt buffers are stored on the hd.. i still can't see why your having buffer problems, my 81 dumps call records as fast as they are produced, streaming data to a cap file, when a call ends, i get a line of txt direct from the tty (serial).. then i use the script to close and ftp that file.. my switch buffer never comes into play

john poole
bellsouth business
columbia,sc

 

[rfwhite]

Just an FYI update. Thanks for the ideas, guys. I'm not at a solution yet but now know lots more than when I started.

johnpoole- I'm still 'crunching numbers' to make sure but according to NTP 553-2631-100 we probably have hit the limit of the buffers.

acewarlock- Unfortunately massaging the buffers (call registers) can be done to give precedence to CDR but it is at the expense of call handling and I can't take that chance.

I looked into CLNK thinking maybe I could hijack the tape port but it appears to have basically the same limitations as the tty cdr port and would be a lot more trouble to work with.

Currently trying to understand the CDR collection that Symposium does- maybe I can grab onto that data stream somehow/somewhere.

 

[gengelke]

Just a thought,
would cutting down on what your capturing to cdr help?
If you are mainly looking at it from a real time perspective maybe you are a just interested in certain data. Just a thought.
The symposium stream is locked down pretty good. The best you could get from there is the 15 min updates.