3CX AI Transcribing Email

[Joshua Ray]

I have an issue where transcribed voicemails show up in the 3CX app but the email with the voicemail is blank. I checked the template and it still shows the spot for the transcribed information. Has anyone seen this recently? And could I get some pointers to look at. Thank you in advance.

 

[NCIA]

We've been experiencing this lately too. Seems like there's just a delay as VMs won't be transcribed immediately in the app, emails won't contain a transcription, and then a few minutes later the transcription will become available via the app.

 

[nikolascx]

Hello Dears

Seems like the transcription is not happening in time.

Can you give us more information?

1. What transcription service are you using? openai, google, 3CX Cloud, or 3CX onboard?
2. If the transcription job does not happen in time, the Voicemail will be sent (voicemail is not blocked waiting for the transcription to occur)

Thanks so much

 

[nikolascx]

Hi Dear Team
I'm thinking more about this:

From your explanation I see that the transcription is definitely completing after the voicemail email is already sent, which explains the behavior you're seeing:

• The 3CX app shows the transcription (once it's ready)
• But the email remains blank (since it was sent earlier)

Why this happens (technical explanation)

Voicemail transcription is handled as a separate background job, and there are a few steps involved:

1. When a voicemail is received, a transcription job is created. This "job" means 3CX sends a request to the transcription API (whatever service it is) and gives the Voicemail recording as Context.
2. The system (depending on the provider: 3CX AI, OpenAI, Google, etc.) needs to request an inference task on a GPU via the API.
3. At that moment some things might happen:
   1. The GPU/service may be busy or under load
   2. The request may take a few seconds to a few minutes to process depending on the length of the recording
4. Meanwhile, 3CX waits for a specific amount of time (on hold) but not much, before sending the voicemail email. In a perfect scenario, the transcription should arrive instantly, and builds the voicemail email template, bundling the transcription and sends it forward.
5. IMPORTANT: Another reason might be Network related. Normally a request originating from inside to an external server (the AI / transcription API) has a port mapping telling the API server "Hey - when you reply, contact me back here on this IP : PORT". When the transcript comes back, the API will send it to the IP : PORT it was instructed to receive it on. If the Firewall you have bordering your 3CX "Forgets" what it committed to a couple of minutes before, OR if the firewall expects this mapping to work for a specified period of time and that time is elapsed, then the firewall has the right to drop this packet so no transcript will arrive.

If 5 is the problem,
That mapping stays alive only while:

• There is active traffic, or
• The firewall/NAT idle timeout hasn’t expired yet

How does it appear in the Web Client / App under Transcriptions?
It does yes - because later on, 3CX contacts the Transcription server to make a sync. And this is why you see it later.

We need some info from you:

1. How often do you get this?
2. If you try it now with a short voicemail and right now with a long voicemail, does it work?
3. Does this affect longer voicemails?

I'm leaning more to a combination of issues - A little delay at the transcript side, just enough for the firewall to "forget" what it contracted earlier. We are checking.

Thanks so much and thanks for reporting.

 

[Joshua Ray]

Voicemails are being transcribed by 3CX AI on the pbx. Is there a way to delay the email going out or is that a hard set amount of time? And on the questions I am asking right now if its affecting shorter and longer voicemails. I will have an update on that once I recieve that.

 

[VoIPTools]

Hey nikolascx, thanks for the detailed explanation.

There are clearly competing needs: (1) the need to quickly inform the user that a new voicemail was received, and (2) the need to provide a transcription.

I have pondered this scenario myself, and I should look at my own code to see how we are handling the same issue. Perhaps, rather than sending a blank transcription, you could put in it's place a message like "voicemail transcription in process. Check your web client for the transcription" or something similar so the user understands the feature is not broken, rather, the transcription service is delayed.

It's a small thing, but good in-app communication can save everyone from spending time researching what looks like a problem, but is actually intentional and by design. I am trying hard to remember that fact and incorporate this approach into everything I do.

 

[nikolascx]

Voicemails are being transcribed by 3CX AI on the pbx. Is there a way to delay the email going out or is that a hard set amount of time? And on the questions I am asking right now if its affecting shorter and longer voicemails. I will have an update on that once I recieve that.

We made an investigation and found out that there was a scarcity of GPU's in a US Zone for approx 28 min.
If the voicemail engine does not get the transcription in 10 minutes, it gives up and proceeds to send the voicemail via email without the transcript.

 

[nikolascx]

Hey nikolascx, thanks for the detailed explanation.

There are clearly competing needs: (1) the need to quickly inform the user that a new voicemail was received, and (2) the need to provide a transcription.

I have pondered this scenario myself, and I should look at my own code to see how we are handling the same issue. Perhaps, rather than sending a blank transcription, you could put in it's place a message like "voicemail transcription in process. Check your web client for the transcription" or something similar so the user understands the feature is not broken, rather, the transcription service is delayed.

It's a small thing, but good in-app communication can save everyone from spending time researching what looks like a problem, but is actually intentional and by design. I am trying hard to remember that fact and incorporate this approach into everything I do.

Yes definitely. We will in fact add this.
A message
Transcription not available - Check the Webclient > Voicemails for the transcript later.
Something along these lines

 

[VoIPTools]

Yikes... 10 minutes seems like a long time to wait for notification regarding an urgent voicemail. If you were to ask my opinion, 1 minute would be closer to my expectation.

That said, as with all things, ignorance and experience feed into those decisions and I supposed if you found sending the voicemail emails within one minute would result in a significant number of blank transcriptions, perhaps a 1-minute expectation is unreasonable.

It all depends on whether you value fast notification, or email transcriptions more. Someone had to make the call, and it seems transcriptions were valued higher than urgency. Fair enough.

 

[nikolascx]

Yikes... 10 minutes seems like a long time to wait for notification regarding an urgent voicemail. If you were to ask my opinion, 1 minute would be closer to my expectation.

That said, as with all things, ignorance and experience feed into those decisions and I supposed if you found sending the voicemail emails within one minute would result in a significant number of blank transcriptions, perhaps a 1-minute expectation is unreasonable.

It all depends on whether you value fast notification, or email transcriptions more. Someone had to make the call, and it seems transcriptions were valued higher than urgency. Fair enough.

Hi Matthew, Good to hear from you!
Long time.

I think there’s a small misunderstanding regarding that 10-minute window!

In 99% of cases, the process is near-instant. The voicemail is sent to an ultra-fast GPU cluster, inference is performed, and the result is returned in roughly 500ms. From the user's perspective, there is no perceptible delay between the call ending and the email arriving with the transcript.

The 10 minutes I mentioned isn't the target speed - it’s the grace period.

Think of it like an SMTP delay queue or a "fail-safe." Because GPUs are currently the most requested resource globally, we have that 10-minute buffer to account for extraordinary conditions (like the temporary GPU scarcity in the US zone I mentioned). We wait that long to give the system every possible chance to include the text before "giving up" and sending the audio alone so the notification isn't lost entirely.

To clarify why this shouldn't be a recurring issue:

• Instant Processing: Under normal loads, the transcription and email bundle happen immediately.
• Resource Priority: We use high-performance clusters to ensure the "inference" task doesn't sit in a long queue.
• The "Yikes" Factor: If we lowered the grace period to 1 minute during a data center spike, users would get an email with no transcript, even if the transcript was ready at 1 minute and 5 seconds.

We believe it's better to wait a few extra minutes during a rare technical hiccup to ensure the email is complete, rather than habitually sending "blank" emails during minor spikes.

Take care & God bless

 

[VoIPTools]

Hi nikolascx,

No misunderstanding. I knew that was the worst case scenario. This is one of those situations where there are tradeoffs, and balancing the urgency to receive a notification while minimizing the number of empty transcriptions requires a compromise. A 10 minute max is a defendable choice.

And it has been a VERY long time. Hope you are doing well.

 

[Joshua Ray]

Thank you everyone for an update and the explanation