The CDR issue of hipath4000

[wabe-hk]

Hello everyone：
I’ve encountered a strange issue about CDR Issue . Every day around 20:19 , the system automatically generates a CDR record with identical content ,the caller is 8005 and the same called number (this call record does not correspond to an actual call), and the call duration is extremely long (approximately 18 hours and 20 minutes).
We've attempted both deleting the 8005 extension and rebooting the ADP board, but we're still seeing the same issue.
I would greatly appreciate any advice on how to troubleshoot and resolve this problem.

Thank you very much!"

the Hipath4000 system version V2.0
hereafter is the CDR log
call duration*begin datetime * end datetime
***0562* 8005:00: 0212033XXXXXX*18-20-00*2025:07:21*01-59-20*2025:07:21*20*19*20~5~~

 

[lisluk]

Thread 'OPENSCAPE 4000 V 7.0 cdr 18 hour problem'

Nov 3, 2015

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

• eniyamath
• Replies: 3
• Forum: Siemens: Hicom

 

[wabe-hk]

Thread 'OPENSCAPE 4000 V 7.0 cdr 18 hour problem'

Nov 3, 2015

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

• eniyamath
• Replies: 3
• Forum: Siemens: Hicom

Hi lisluk，
Thank you for your reply. Based on your post, was the issue resolved after performing a CC switchover (from CCA switch to CCB running or CCB switch to CCA )?
I checked this pbx (v2.0 with cdr issue)
<TEST-DIMSU:;
TEST-DIMSU:;
H500: AMO DIMSU STARTED
H01: CC: 98 % OF THE TOTAL STATIC MEMORY AREAS AND 80 % OF THE
TOTAL DYNAMIC MEMORY AREAS RESERVED FOR THE FLEXAMA ARE USED.
H01: LTG: 67 % OF THE TOTAL STATIC MEMORY AREAS AND 67 % OF THE
TOTAL DYNAMIC MEMORY AREAS RESERVED FOR THE FLEXAMA ARE USED.

AMO-DIMSU-111 DIMENSIONING OF FEATURES, SWITCHING UNIT
TEST COMPLETED;

For comparison reference
I specifically checked another HiPath 4000 system running V5.0 and executed the test-dimsu; command, which showed the following:
test-dimsu;
TEST-DIMSU;
H500: AMO DIMSU STARTED<br>H01: CC: 100 % OF THE TOTAL STATIC MEMORY AREAS AND 98 % OF THE TOTAL DYNAMIC MEMORY AREAS RESERVED FOR THE FLEXAMA ARE USED.
H01: LTG: 74 % OF THE TOTAL STATIC 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;

The CC reached 100%, but there don't seem to be any issues, including the CDR problem I mentioned.

I will look for an opportunity to perform a switchover or simply reboot the entire PBX to see if that resolves the problem.
thank's a lot!

 

[sbcsu]

Ah now - that old problem is back !

65535 as everyone knows is a 64K buffer
But 65535 seconds in hours and minutes is - you've guessed it 18 Hours : 12 Minutes : 15 Seconds
So when that buffer fills up it generates a call record - it's a bug basically and how to fix it is as follows:

DIS-ZANDE:OPTFEA,ACTFLAGS;
CHA-ZANDE:OPTFEA,A,193;
EXE-UPDAT:BP;

For V7 the above should work - if not then a different patch would have to be activated.


GRZW:
This AMO allows Call-Limits to be set. If a limit is set a call record will be output when the limit is reached. For example to set a time limit of HH hrs, MM minutes, and SS seconds, use the following command format:
ADD-GRZW:RCD,,,HHMMSS;

The default value is 181215 (18hrs, 12 mins, 15secs) and is not normally required to be altered.

Note: setting a limit in this way does not limit the call to this length, it simply causes a CDR record to be output each time the call reaches the limit value.

 

[wabe-hk]

Ah now - that old problem is back !

65535 as everyone knows is a 64K buffer
But 65535 seconds in hours and minutes is - you've guessed it 18 Hours : 12 Minutes : 15 Seconds
So when that buffer fills up it generates a call record - it's a bug basically and how to fix it is as follows:

DIS-ZANDE:OPTFEA,ACTFLAGS;
CHA-ZANDE:OPTFEA,A,193;
EXE-UPDAT:BP;

For V7 the above should work - if not then a different patch would have to be activated.


GRZW:
This AMO allows Call-Limits to be set. If a limit is set a call record will be output when the limit is reached. For example to set a time limit of HH hrs, MM minutes, and SS seconds, use the following command format:
ADD-GRZW:RCD,,,HHMMSS;

The default value is 181215 (18hrs, 12 mins, 15secs) and is not normally required to be altered.

Note: setting a limit in this way does not limit the call to this length, it simply causes a CDR record to be output each time the call reaches the limit value.

Hi,sbcsu:
Thank's for your reply, I have try the AMOs you posted
DIS-ZANDE:OPTFEA,ACTFLAGS;
CHA-ZANDE:OPTFEA,A,193;

Not applicable to Hipath4000 V2.0, could you please let me know how to fix it with H4k R2.0
Thank you and have a nice day!

---------- amo display in H4k V2.0 ----------
<DIS-ZANDE:OPTFEA,ACTFLAGS;
M34: VALUE NOT WITHIN ADMISSIBLE RANGE
TYPE =
M16: COMMAND PROCESSING ABORTED
<CHA-ZANDE:OPTFEA,A,193;
M34: VALUE NOT WITHIN ADMISSIBLE RANGE
TYPE = ?
TYPE : DESIRED SYSTEM OPTION
CHARACTERISTIC : REQUIRED CONDITIONAL
POSS. VALUES : KEYSYS SETTINGS FOR KEY SYSTEM
ACD SETTINGS FOR ACD-G
ATND SETTINGS FOR ATTENDANT CONSOLE
OPTISET SETTINGS FOR OPTISET DEVICES
ALLDATA ALL SYSTEM DATA
MLPP MULTI-LEVEL PRECEDENCE AND PREEMPTION SERVICE
TYPE =
M16: COMMAND PROCESSING ABORTED
<

 

[sbcsu]

Hi,
Not sure if V2 can be resolved but try the patch as follows:

Optional patch must be activated followed by BP restart in order to clear out the duration issue.
System revisions covered are V4 R2 and V6 R1

1)act-patch:
opt,s,193;
or
2)act-patch:
opt,s,194;

The patch will suppress these faulty data records
This will probably work on V3 but not sure about V2

 

[wabe-hk]

Hi,
Not sure if V2 can be resolved but try the patch as follows:

Optional patch must be activated followed by BP restart in order to clear out the duration issue.
System revisions covered are V4 R2 and V6 R1

1)act-patch:
opt,s,193;
or
2)act-patch:
opt,s,194;

The patch will suppress these faulty data records
This will probably work on V3 but not sure about V2

Hi,
I have followed your suggestion and patched it. I will observe it in the next two days to see if the problem can be solved. Or restart the PBX at a suitable time.
The test results will be reported to you after completion
Thank you very much ！

<reg-patch;
TYPE = opt;
REG-PATCH:OPT;
H500: AMO PATCH STARTED
ACT-PATCH:OPT,S,0193&0194;

AMO-PATCH-111 PATCH ADMINISTRATION ON HD AND (DE)ACTIVATION
REGENERATE COMPLETED;
<