Hello,
I am testing the new AI transcription functionality on our production 3CX system and have encountered what appears to be a reproducible problem in the 3CX transcription pipeline.
System configuration:
Some calls are transcribed correctly, but in other calls the transcription initially works normally and then enters a repetition loop.
A block of previously transcribed conversation starts repeating many times, while the actual remainder of the call is lost.
This is not just an occasional duplicated sentence. In the affected calls, the same block may be repeated dozens of times until the transcription ends.
I have now reproduced this with two different call recordings.
Test performed to isolate the problem
I downloaded the original WAV files from 3CX and submitted the exact same files directly to the OpenAI Transcriptions API using:
model=gpt-4o-mini-transcribe
language=bg
In both cases the result was:
3CX → OpenAI: transcription enters a repetition loop and loses the remainder of the actual conversation.
Same WAV → OpenAI API directly: complete and normal transcription of the entire call, without the repetition loop.
Therefore the audio files themselves and the OpenAI GPT-4o Mini Transcribe model do not appear to be the cause.
The problem seems to occur somewhere in the 3CX AI transcription workflow — possibly chunking, retry handling, response assembly or other processing between 3CX and the OpenAI API.
Additional test
During testing I also found a separate issue with Cyrillic characters in 3CX-generated recording filenames.
A recording with a filename such as:
[Кремена]_...wav
resulted in:
HTTP 400 (invalid_request_error: unsupported_value) Parameter: file Unsupported file format
The WAV itself was valid PCM WAV. After changing the 3CX user name to Latin characters, newly generated recordings such as:
[Kremena]_...wav
were accepted for transcription.
This appears to be a separate Unicode filename issue.
Questions
Thank you.
I am testing the new AI transcription functionality on our production 3CX system and have encountered what appears to be a reproducible problem in the 3CX transcription pipeline.
System configuration:
- 3CX Version 20.0 Update 9, Build 995 Release
- AI version: 1.4.48
- License: AI Edition, 8 SC
- Transcription provider: OpenAI
- Speech-to-Text model: GPT-4o Mini Transcribe
- Language: Bulgarian
- Analysis Text Model: gpt-5.4-mini
- Recordings: standard 3CX PCM WAV, 16-bit, mono, 8 kHz
Some calls are transcribed correctly, but in other calls the transcription initially works normally and then enters a repetition loop.
A block of previously transcribed conversation starts repeating many times, while the actual remainder of the call is lost.
This is not just an occasional duplicated sentence. In the affected calls, the same block may be repeated dozens of times until the transcription ends.
I have now reproduced this with two different call recordings.
Test performed to isolate the problem
I downloaded the original WAV files from 3CX and submitted the exact same files directly to the OpenAI Transcriptions API using:
model=gpt-4o-mini-transcribe
language=bg
In both cases the result was:
3CX → OpenAI: transcription enters a repetition loop and loses the remainder of the actual conversation.
Same WAV → OpenAI API directly: complete and normal transcription of the entire call, without the repetition loop.
Therefore the audio files themselves and the OpenAI GPT-4o Mini Transcribe model do not appear to be the cause.
The problem seems to occur somewhere in the 3CX AI transcription workflow — possibly chunking, retry handling, response assembly or other processing between 3CX and the OpenAI API.
Additional test
During testing I also found a separate issue with Cyrillic characters in 3CX-generated recording filenames.
A recording with a filename such as:
[Кремена]_...wav
resulted in:
HTTP 400 (invalid_request_error: unsupported_value) Parameter: file Unsupported file format
The WAV itself was valid PCM WAV. After changing the 3CX user name to Latin characters, newly generated recordings such as:
[Kremena]_...wav
were accepted for transcription.
This appears to be a separate Unicode filename issue.
Questions
- Is the GPT-4o Mini Transcribe repetition-loop problem a known issue in AI 1.4.48?
- Does 3CX split recordings into chunks before sending them to OpenAI or perform any post-processing/assembly of the returned transcription?
- Is there a hotfix or newer AI component compatible with V20 Update 9 that addresses this?
- Is either the repetition issue or the Unicode filename issue fixed in a later 3CX version?
- both original WAV recordings;
- the faulty transcriptions produced through 3CX;
- the complete direct OpenAI API transcription results;
- relevant Event Log entries.
Thank you.
