pull CDR record from HiPath 4000 1

[ccmjgb]

Hi all,

I've been asked to pull a couple of CDR records for Inbound calls to a couple of stations during a specific time frame. Can someone please provide some AMO guidance and also how I can pull using Assistant? There is no CDR logger connected to the HiPath 4000 so I'm assuming the CDRs are in some buffer somewere...

Thank you!!

 

[donb01]

You have to go through one of the service ports, and there are some specific port numbers you have to hit like 1201 or something to get the data. I'm glad my vendor set mine up for me because the document I had on configuring CDR for the 4000 was over an inch thick! It might be easiest to get some kind of cheap call logger with a web interface to grab the data.

 

[ccmjgb]

so based on your comment... is it not possible to extract a couple calls that came in last week? can Assistant assist?

 

[sbcsu]

Hi,
If you DIS-SELS;
Are any of them set to ON or COLLECT ?
If so then you MIGHT have the records.
The HiPath only stores so many of them and will overwrite them when full.
That overwriting of the CDR records will throw up an alarm (Maintenance Alarm CDR Buffer Full #29)

If none of the SELS are set to on then your HiPath is not collecting calls.

To keep call records you have to connect up an external device to keep the lines of text.

You can also see the status of any ports (Including CDR ports) by
DIS-LSSM;

If port 1202 has an IP address on the Right Hand Side (other than 192.0.2.3) and a port number other than 1202 (again on the right hand side) then it is collecting - somewhere...

 

[ccmjgb]

thank you sbcsu!

DIS-SELS; (all off)
DIS-LSSM; (port 1201 and 1202 both have IP 192.0.2.3)

so that's that...

out of curiosity... do you know how many entries the CDR Buffer will hold before the alarm triggers?

also... how would I turn on the CDR logging to buffer in case I would need to pull a record or two... nothing fancy is needed... just in case a call comes in or goes out that would need to be pulled.

 

[sbcsu]

The CDR buffer size depends on how large the records that are generated are.
Initially in the setup configuration they are normally added with max values however the defaults are not maximum values.

The 'problem' with CDR on HiPath is that you could have a single ASCII character coming out to a printer after each call if you so desired, also it really depends on if you want to output internal calls, incoming calls, outgoing calls as well.
And then of course how many calls are made on your system.

The design of the buffer is really only used in the field for a temporary store if you have to change the unit that the calls are output to or if the output unit goes off line maybe for a weekend.

In the past 'semiconductor buffers' were popular and were placed before a Call Charging Server/PC.

This Server/PC unit would bring the line of text (for each call) in over the LAN. It 'decodes' it depending on the 'mask' that has been setup on the HiPath.
This Server/PC is then used to get information out of it's database as to how responsive an operator is or how many calls a telephone set has made.

As for 'turning on' CDR output on the HiPath - because you can output anything in any format it would be best to contact a local tech to get the lines of text from them.

CDR on the HiPath 4000 is not for the faint hearted.
Special courses used to be run at one time specifically aimed at CDR.
If you are installing a system or maintaining a system it would be best to set aside the CDR task and offload it to someone who is doing it all the time.

The following AMOS' are used (and more besides but these are the main ones)
DAGR - sizes of files for storage
FEACG - circular or stop of records on hard disk
DAVF - currency on output
GEFE/GRZU - Carrier selection
FBTN - assign numbers to each trunk that you wish to be shown in the output
GEZU - output to which device
SELG - What mask is used for outputting to what device and for what calls
SELS - the output on/off/collect
TLZO - output of a dummy number for incoming/outgoing/internal calls
TTBL - positioning of numbering ?
FTBL - the main area where the output 'mask' or line of text is decided, normally one for incoming and one for outgoing
TEXT - the textual outputs that you are going to use for different occurrences on the system


Turning on CDR needs changes in LDAT, Trunk COP/COT parameters and FEASU

 

[ccmjgb]

thank you for the feedback sbcsu... will leave as is.

 

[donb01]

sbcsu, I am having a dilemma with mine. My traffic analyst software is polling at 15 minute intervals and cannot be set to a shorter interval. Our "network" is generating just ofver 16K total calls on a typical weekday of all types. I am getting occasional buffer errors at the 70% threshold. I have put in a ticket with the vendor to have that adjusted to 80% because the incidents are fairly spread out. The "claim" they have contacted Unify and they claim it cannot be adjusted. I know I used to change a lot of those vadsu paramters myself because I have clinics that have a tendancy to unplug phones when they are not used and it tends to cause alarms. I know there should be a way to change that 70% to 80% but I do not know which parameter it is or which section it's in - I have tried looking.

Do you have alternate information on the actual ability to change that alarm threshold? It would be appreciated. )

 

[sbcsu]

Hi Don
You could put a buffer between the HiPath and your software. That would store all the data and the HiPath then would be out of the equation.
They are relatively inexpensive and once they have the data they can be FTP'd in to or the unit can email as well.

I have one customer that has so many calls per hour that the CDR on the Atlantic LAN could not be handled, and it was loosing calls so we had to use the Assistant to store calls and then FTP them out, however that is another story.

If you
REG-VADSU;
REG-VADSM;
first just to have a record of the way things were.

Then DIS-VADSU;
What you are looking for is Alarm Gruop: Central SWU Alarms
Alarm Number 29 (maintenance note) - that is the CDR alarm.

To change it experiment with CHA-VADSM:,CENTRAL,29
You could increase the thresholds there to stop the ongoing triggering of the alarm at lower levels than you want.

You could always turn off the alarm via SIGNL but I suppose that is cheating