Related closed report: https://www.3cx.com/community/threa...alid-wav-files-v20-update-9-ai-1-4-48.137762/
We have additional reproduction evidence on 3CX 20.0.10.1716 (Update 10 RC), Debian 12 x86_64. During the native failures, STT was gpt-4o-transcribe-diarize with Polish language selected. Native recording transcription returned HTTP 400: invalid_request_error / unsupported_value / parameter file / Unsupported file format. The stored native transcript and summary were empty.
A controlled direct-API comparison on 23 October 2026 used the identical valid 20.992-second PCM16 mono 8 kHz WAV (335,918 bytes), the same OpenAI credential, model and options:
- Original SDK-generated upload filename metadata containing Polish ł (U+0142): HTTP 400.
- Literal ASCII recording.wav upload filename metadata: HTTP 200 with diarized segments.
- File-part Content-Type was omitted in BOTH requests. Audio bytes, language=pl, response_format=diarized_json and chunking_strategy=auto were unchanged. There were no retries or analysis calls in the comparison.
A synthetic illustration of a Polish-character name is test_ł.wav; this is not an actual recording filename or an independently tested third case. The comparison changed the complete filename metadata, including its encoding/path/length. It does not prove that all Unicode filenames fail, nor isolate exactly which filename-parser behavior triggers rejection.
The comparison used a direct uploader with metadata checked against the installed .NET SDK; it was not a capture of the native HTTP request. The native and comparison credential references were not verified equivalent. Consequently, filename handling is a strong explanation for this native failure pattern, while actual native transcript-plus-summary acceptance remains unverified.
An ASCII display-name workaround was applied through supported configuration for future recordings. No new call/native reprocessing has yet verified it end to end, and no vendor binary or existing recording was renamed or patched.
Separately, during inspection the Admin dropdown labelled the previously configured diarized model unavailable because it was absent from its static options list. That UI warning is not itself a provider/account availability test; the controlled ASCII request succeeded with the diarized model.
Could 3CX confirm the supported fix/build for upload filename normalization (for example, a constant ASCII multipart filename while preserving the stored recording identity), and a supported way to reprocess affected existing recordings? The earlier thread is closed, so this adds current-build evidence rather than assuming its workaround is a permanent product fix.
No audio, transcript, personal names, actual filenames, credentials, licence/account identifiers, raw logs or private support bundles are included.
We have additional reproduction evidence on 3CX 20.0.10.1716 (Update 10 RC), Debian 12 x86_64. During the native failures, STT was gpt-4o-transcribe-diarize with Polish language selected. Native recording transcription returned HTTP 400: invalid_request_error / unsupported_value / parameter file / Unsupported file format. The stored native transcript and summary were empty.
A controlled direct-API comparison on 23 October 2026 used the identical valid 20.992-second PCM16 mono 8 kHz WAV (335,918 bytes), the same OpenAI credential, model and options:
- Original SDK-generated upload filename metadata containing Polish ł (U+0142): HTTP 400.
- Literal ASCII recording.wav upload filename metadata: HTTP 200 with diarized segments.
- File-part Content-Type was omitted in BOTH requests. Audio bytes, language=pl, response_format=diarized_json and chunking_strategy=auto were unchanged. There were no retries or analysis calls in the comparison.
A synthetic illustration of a Polish-character name is test_ł.wav; this is not an actual recording filename or an independently tested third case. The comparison changed the complete filename metadata, including its encoding/path/length. It does not prove that all Unicode filenames fail, nor isolate exactly which filename-parser behavior triggers rejection.
The comparison used a direct uploader with metadata checked against the installed .NET SDK; it was not a capture of the native HTTP request. The native and comparison credential references were not verified equivalent. Consequently, filename handling is a strong explanation for this native failure pattern, while actual native transcript-plus-summary acceptance remains unverified.
An ASCII display-name workaround was applied through supported configuration for future recordings. No new call/native reprocessing has yet verified it end to end, and no vendor binary or existing recording was renamed or patched.
Separately, during inspection the Admin dropdown labelled the previously configured diarized model unavailable because it was absent from its static options list. That UI warning is not itself a provider/account availability test; the controlled ASCII request succeeded with the diarized model.
Could 3CX confirm the supported fix/build for upload filename normalization (for example, a constant ASCII multipart filename while preserving the stored recording identity), and a supported way to reprocess affected existing recordings? The earlier thread is closed, so this adds current-build evidence rather than assuming its workaround is a permanent product fix.
No audio, transcript, personal names, actual filenames, credentials, licence/account identifiers, raw logs or private support bundles are included.
