Hello,
Call history is completely empty in both the Web Client and Admin Console. Missed calls and recent calls are not visible at all, although calls themselves work perfectly (phones ring, calls connect, both trunks registered).
WHAT I MEASURED
1) The API endpoint /xapi/v1/CallHistoryView returns an empty array:
{"@odata.context":"...#CallHistoryView","value":[]}
2) Database row counts (database_single):
cdroutput = about 6023 rows (populated and live)
cl_calls = 0 rows
cl_segments = 0 rows
cl_participants = 0 rows
cl_segments_view = 0 rows
calldetails = 0 rows
callhistory3 = 0 rows
call_history_view = 0 rows
3) A recent test call IS correctly recorded in cdroutput (incoming, not answered, cancelled), with a correct timestamp and caller number. So the PBX records calls properly, but they never reach the call history tables.
4) The definition of the view call_history_view references tables named "segments" and "participants", but no tables with those names exist in the database. The actual tables are named cl_segments and cl_participants. The view therefore returns empty without raising an error.
5) The Management Console log repeatedly shows:
Microsoft.OData.ODataException: Could not find a property named 'StartTime' on type 'Pbx.CallHistoryView'
WHAT I ALREADY TRIED (no effect)
- Restarted 3CXCfgServ01 and 3CXPhoneSystemMC01
- Rebooted the entire virtual machine
- Updated from 20.0.10.1277 to 20.0.10.1621, and 3CX AI to 1.6.57
- Verified all services are running (HasNotRunningServices = false)
- Confirmed all cdroutput rows are marked processed = true
SYSTEM
Version 20.0 Update 10 (Build 1621 Alpha - AI 1.6.57)
On Premise, Debian 12, self managed
9 of 40 extensions in use, 2 of 2 trunks registered
NOTE
I ran this past the Technical Support Assistant on the 3CX website. It concluded this is not a SIP trunk, registration or call-routing problem, but a call-history schema or projection defect in the database layer, and that there is no supported Level 1 procedure to repopulate these tables from cdroutput. It advised escalating to Level 2, but my portal shows 0 support tickets available.
So I am asking here. Has anyone seen this mismatch between the view definition and the actual table names? Is there a documented migration or repair procedure for this build?
A full backup has already been taken and preserved. I have not modified the database in any way.
Thank you.
Call history is completely empty in both the Web Client and Admin Console. Missed calls and recent calls are not visible at all, although calls themselves work perfectly (phones ring, calls connect, both trunks registered).
WHAT I MEASURED
1) The API endpoint /xapi/v1/CallHistoryView returns an empty array:
{"@odata.context":"...#CallHistoryView","value":[]}
2) Database row counts (database_single):
cdroutput = about 6023 rows (populated and live)
cl_calls = 0 rows
cl_segments = 0 rows
cl_participants = 0 rows
cl_segments_view = 0 rows
calldetails = 0 rows
callhistory3 = 0 rows
call_history_view = 0 rows
3) A recent test call IS correctly recorded in cdroutput (incoming, not answered, cancelled), with a correct timestamp and caller number. So the PBX records calls properly, but they never reach the call history tables.
4) The definition of the view call_history_view references tables named "segments" and "participants", but no tables with those names exist in the database. The actual tables are named cl_segments and cl_participants. The view therefore returns empty without raising an error.
5) The Management Console log repeatedly shows:
Microsoft.OData.ODataException: Could not find a property named 'StartTime' on type 'Pbx.CallHistoryView'
WHAT I ALREADY TRIED (no effect)
- Restarted 3CXCfgServ01 and 3CXPhoneSystemMC01
- Rebooted the entire virtual machine
- Updated from 20.0.10.1277 to 20.0.10.1621, and 3CX AI to 1.6.57
- Verified all services are running (HasNotRunningServices = false)
- Confirmed all cdroutput rows are marked processed = true
SYSTEM
Version 20.0 Update 10 (Build 1621 Alpha - AI 1.6.57)
On Premise, Debian 12, self managed
9 of 40 extensions in use, 2 of 2 trunks registered
NOTE
I ran this past the Technical Support Assistant on the 3CX website. It concluded this is not a SIP trunk, registration or call-routing problem, but a call-history schema or projection defect in the database layer, and that there is no supported Level 1 procedure to repopulate these tables from cdroutput. It advised escalating to Level 2, but my portal shows 0 support tickets available.
So I am asking here. Has anyone seen this mismatch between the view definition and the actual table names? Is there a documented migration or repair procedure for this build?
A full backup has already been taken and preserved. I have not modified the database in any way.
Thank you.
