Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

OPENSCAPE 4000 V 7.0 cdr 18 hour problem

Status
Not open for further replies.

eniyamath

Technical User
Jun 4, 2012
266
IN
we have installed Openscape 4000 V 7.0 system and we are facing teh costi buffer hanging issue.
Due to that lot of call records are 18 hours and 10 hours .and these calls are not genuine.
Can any one help me to resolve this issue.
Secondly how we can control the call duration for trunks.(example all subscribers cannot make make calls more than 15 mineutes).
please guide me any one who has faced this issue or done the call duration cut off.
Thanks in advance
 
Please explain more about the "costi buffer hanging issue" because I have been asking if there is an "issue" with CDR for a year and a half now, as I am getting some really obnoxious long call records that are way out of the ball park and I really can't trust ANY of the long calls reported because of it. I mean calls that literally show up as hundreds of hours between like switchboard and ER, and stupid things like that. I would expect some 6 - 8 hour calls if there might be an occasional all day conference call, but anything much over those rare occurrances I would deem hogwash - unles there is an equipment problem or a stuck modem or something.

My impression of that problem is that on some calls for some reason there is not adequate "call supervision" and the system does not know that call has been disconnected and the trunk released long ago. I don't know of any mind of tolerance setting or COT/COP parameter that can enhance the call disconnect supervision.


Don Bruechert, Voice Comm Analyst II
CareTech Solutions @ Holy Family Memorial
Manitowoc, WI, USA
 
This is because the buffers fill up at the known number 65535
65535 seconds is just over 18 hours
This happens when a particular buffer becomes full.

Ensure that the HiPath is fully up to date
Ensure that the Call Charging is programmed similar to a known working system.
Also check to see that the DIMSU is set correctly
T-DIMSU; should give a value below 80%

If the software was V5 or below you have to switch processors
However because you have V7 then you should escalate

 
Hello,
I also have the same problem with HiPath 4000 V4;
Here is my T-DIMSU; :
< TEST-DIMSU:;
TEST-DIMSU:;
H500: AMO DIMSU STARTED
H01: CC: 97% OF THE TOTAL SHARED MEMORY AREAS AND 94% OF THE
TOTAL DYNAMIC MEMORY AREAS RESERVED FOR THE FLEXAMA ARE USED.
H01: LTG: 74% OF THE TOTAL SHARED MEMORY AREAS AND 70% OF THE
TOTAL DYNAMIC MEMORY AREAS RESERVED FOR THE FLEXAMA ARE USED.

AMO-DIMSU-111 DIMENSIONING OF FEATURES, SWITCHING UNIT
TEST COMPLETED;
What should I do to correct this?
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top