Caller ID is wrong in a recording name

Source and affected scope

VICIdial stereo call recordings ↗

Source date

Not stated in source

Source checked

2026-11-07

Reported version

Version-specific behavior; inspect the installed release

Guide updated

2026-11-07

• Recording filename or displayed caller number appears inconsistent with the call.

Before you start

• Use one existing consented synthetic call and its authorized metadata; do not copy real numbers.
• Identify whether the affected artifact is mono or stereo and the installed revision.

Diagnose the reported problem

1. Step 1Inspect the saved naming pattern

   Open Admin → Campaigns → the affected campaign → Recording Filename and record its exact value; inspect the in-group recording fields too when the call uses inbound overrides. Labels and precedence vary by revision.

   Compare that pattern with the captured call’s actual metadata and native recording record. For the documented lab pattern DOCS_FULLDATE_CUSTPHONE, the CUSTPHONE portion identifies a customer-number component; a changed prefix or caller-ID transformation can make the displayed result differ. Treat the exact expansion as build-specific until observed.

   Fictional reading example: if the field is FULLDATE_CUSTPHONE and the synthetic customer number is 9001101, expect a generated date/time component and a customer-number component corresponding to 9001101; separators and exact substitution must be verified against the installed build, not copied from this illustration.

   Expected observation

   You can identify which native setting and synthetic record produced the filename without assuming its number is an authenticated caller ID.

   If this check fails

   If the recording type, route or applicable override is unknown, stop and trace the call before changing the pattern.

2. Step 2Follow the synthetic number

   Compare the inbound channel caller-ID, DID/in-group routing and recording row/file name at the same test time. A filename may reflect a stored or transformed number, not the caller’s verified identity.

   Expected observation

   The first point at which the synthetic number differs is identified.

   If this check fails

   A correct filename does not prove caller-ID authenticity or audio integrity.

Correct the confirmed cause

Use this branch only when your diagnostic observations match the affected scope above. The lab result states which outcomes were actually tested.

1. Step 3Adjust the owning configuration only

   Save the existing pattern and route. If the correct setting is shown to be wrong, update only that isolated campaign or in-group using its native form under an approved change window.

   Expected observation

   The saved field matches the agreed format.

   If this check fails

   Do not rename or overwrite historical recordings or alter call history.

Verify the outcome

• Using a separately authorized synthetic call, compare new caller-ID, recording metadata and filename to the expected expansion; check that the audio file exists and is playable by an authorized reviewer.

Recover or roll back

• Restore the exact prior setting through the native form and verify it on reopen. Keep existing files and audit records unchanged.

Screenshot evidence

No native screenshot is attached to this guide.

• VICIdial stereo call recordings · Primary documentation; checked 2026-11-07