FreePBX System Recordings: reusable audio, language and replacement boundaries

Keep the reusable object, media and consumer separate

A FreePBX System Recording is a named reusable object that other modules can select. Its saved identity and ordered playback parts are not the same thing as one uploaded or handset-recorded audio file, and neither proves which Announcement, IVR, Directory, queue, conference or custom destination uses it. Preserve the object name, description, language, playback order and consumer references as separate inventory.

Changing a shared recording can change several caller paths without editing those consumers. Before replacement, enumerate every known reference and identify an owner, acceptance path and rollback for each one. Do not infer exclusive use from a friendly name.

Inventory the ordered playback parts and language

Record the System Recording object and every playback item in order, including uploaded or recorded media, any built-in prompts, the selected language, available formats and the expected spoken content. Sangoma's GraphQL model exposes name, description, language, playback items, codecs and optional feature-code fields as distinct data, which is a useful ownership model even when administration occurs in the GUI.

A compound recording can sound partly correct while one item is stale, missing or in another language. Keep channel language and installed sound-pack behavior separate from the recording object's own selection; a visible file does not prove that Asterisk resolves or decodes the representation used by a particular caller path.

Treat upload, handset capture and replacement as changes

Use an approved source file or an authorized handset capture, preserve its provenance and confirm the preview before saving. Sangoma's guide warns that the next recorded or uploaded media can replace the existing green file when the recording is saved. Take a backup or retain the prior asset and object definition before any rerecording.

Save and Apply Config remain different checkpoints. Record the submitted object, saved result, generated state and loaded behavior rather than treating the browser upload or a success banner as caller-path acceptance. Avoid repeated conversions and normalize through a controlled, reversible process when format changes are required.

Protect feature-code rerecording as privileged content change

A System Recording can expose an optional feature code so an authorized caller can replace its media from a handset. Inventory the exact code, authentication or password control, permitted origin and operational owner without copying secrets into shared evidence. Dial access proves only that the rerecording workflow was reached; it does not prove that the intended object changed or that every consumer now plays the accepted result.

Disable or restrict unused rerecording paths. For an approved update, record the timestamp, calling endpoint, target object, captured media, saved result and subsequent caller-path tests. A feature code changes the shared content; it does not repoint an IVR or Announcement to a different recording.

Follow the consuming module into Asterisk playback

Start with the caller path and prove the consumer selected the intended recording. Then follow its generated dialplan into the actual Asterisk application and filenames. Playback resolves filenames without an extension, searches relative names under the sounds directory and reports PLAYBACKSTATUS; BackGround similarly plays files while accepting digits and reports BACKGROUNDSTATUS. Missing-file failure, answer behavior and digit collection therefore belong to the application and call flow as well as the reusable object.

Do not repair a wrong Announcement destination by replacing the shared audio, and do not repair a missing language variant by repointing every consumer. Stop at the first boundary where saved selection, generated state, file lookup, playback status or audible content diverges.

Accept each consumer and preserve rollback

Test a direct authorized preview or managed playback first, then each representative caller path that references the object. Preserve call direction, selected consumer, channel language, resolved playback items, application status, answer or early-media state, DTMF behavior where applicable and what the caller actually heard. Preview success is useful but is not caller-channel proof.

Restore the prior object or media through the supported module if acceptance fails; do not overwrite files under the sounds directory behind FreePBX. Reapply configuration only in the supported scope and replay every affected consumer. This workflow is documentation-derived and was not reproduced on a customer or laboratory PBX.

Use a recording as content, not outcome evidence

A System Recording can be selected by Route Congestion Messages, but its identifier, media files, generated macro-outisbusy reference, loaded dialplan, Playback status and audible result remain separate states.

Keep wake-up prompt selection distinct from delivery

Wake Up Calls can use language-scoped prompt sequences, but a selected recording does not prove that the scheduled channel answered or that the intended person heard and confirmed it. The focused guide follows the complete path.