3CX 20.0.8.1121 -- Recorded Web Meeting Post-Session Emails Not Sending / "Queue Not Started" Exception in GatewayService

[Mike Hammett]

Running 3CX 20.0.8.1121 on Linux (Ubuntu 24). Starting approximately April 7, 2026, web meetings with recording enabled stopped generating post-session email notifications. Unrecorded meetings send notifications normally.


Observed behavior: Organizers no longer receive the post-meeting email with the recording link when a meeting is recorded. Unrecorded meetings are completely unaffected.


How we investigated: Pulled logs from /var/lib/3cxpbx/Instance1/Data/Logs/3CXGatewayService.log and found that every session ending with "recstarted":true throws this exception immediately after the DB insert to meetingsession succeeds:

System.Exception: Queue Not Started
at WebMeetingBridge.ClusterManager.ApiHandler.Append(ApiCommand apiCommand, Boolean clearQueue)
at WebMeetingBridge.ClusterManager.Commands.ReceiveSessionEndIndication.<>c__DisplayClass1_0.<<Create>b__0>d.MoveNext()

The GatewayService then returns "error":"Command failed" to the MCU, and the POST https://wmr.3cx.net/manager/requestconversion call -- which triggers recording conversion and the notification email -- never fires. Sessions with recstarted: false complete cleanly with "error":"" because they don't call ApiHandler.Append.


What we think is happening: The ApiQueue inside the GatewayService enters a stopped state and is not reinitialized on WebSocket reconnection. Since the recording path is the only one that calls ApiHandler.Append, only recorded meetings are affected.


What fixed it: A clean restart of 3CXGatewayService reinitializes the queue. A recorded test meeting immediately after the restart was completed successfully, and the email was delivered. We do not yet know if this is a one-time condition or if it will recur.


Impact: We have 8 recorded sessions during the failure window with recordings stuck in an unconverted state on the cloud MCU. They do not appear via the /webmeeting/api/v1/reports/ API endpoint.


Questions for the community and 3CX:

1. Has anyone else encountered this on 20.0.8.x?
2. Is there a known patch build that addresses this?
3. Is there any way to manually trigger requestconversion for the affected sessions, or can 3CX support do so on the backend? The 7-day retention window is a concern.

Happy to provide additional log excerpts if useful.

 

[Alphabetic]

You should use the ISO to install 3CX which comes on the Debian distro as this is the supported method.

 

[Mike Hammett]

You should use the ISO to install 3CX which comes on the Debian distro as this is the supported method.

Yes, that's the method that I've always used.

 

[NikosT_3CX]

@Mike Hammett you mentioned that you use " Running 3CX 20.0.8.1121 on Linux (Ubuntu 24) " but Ubuntu is nowhere mentioend that its supported from our side.
Run the ISO as per our guide and then let us know if you have the same issues :
http://3cx.com/docs/manual/installing-debian-linux-pbx/

 

[Mike Hammett]

@Mike Hammett you mentioned that you use " Running 3CX 20.0.8.1121 on Linux (Ubuntu 24) " but Ubuntu is nowhere mentioend that its supported from our side.
Run the ISO as per our guide and then let us know if you have the same issues :
http://3cx.com/docs/manual/installing-debian-linux-pbx/

That's the method I used. The initial report was just an error.

 

[NikosT_3CX]

@Mike Hammett the Ubuntu you mentioned what is, the machine where you have the PBX or the Virtualization Platform where
you loaded the VM to ?


http://3cx.com/docs/manual/installing-debian-linux-pbx/

Step 2: Check VM platform requirements​

3CX is tested and supported to run as a Virtual Machine on these hypervisor platforms:

• VMware vSphere Hypervisor (ESXi) 6.5u1 and above, with VMWare Tools package installed.
• Microsoft Hyper-V Server (6.2) and above capable of running Debian 12 - see our Hyper-V Page for required settings.
• KVM 2.8 and up.
• Citrix XenServer 7.0 and above.
• Avoid using 3CX on converted VMs (P2V) due to possible timing issues, causing the guest OS not to sync with the hypervisor’s timer.

 

[Mike Hammett]

@Mike Hammett the Ubuntu you mentioned what is, the machine where you have the PBX or the Virtualization Platform where
you loaded the VM to ?


http://3cx.com/docs/manual/installing-debian-linux-pbx/

Step 2: Check VM platform requirements​

3CX is tested and supported to run as a Virtual Machine on these hypervisor platforms:

• VMware vSphere Hypervisor (ESXi) 6.5u1 and above, with VMWare Tools package installed.
• Microsoft Hyper-V Server (6.2) and above capable of running Debian 12 - see our Hyper-V Page for required settings.
• KVM 2.8 and up.
• Citrix XenServer 7.0 and above.
• Avoid using 3CX on converted VMs (P2V) due to possible timing issues, causing the guest OS not to sync with the hypervisor’s timer.

I wish I could edit the original post because it's not running Ubuntu, it's the 3CX ISO. I used AI to help me diagnose the problem, and it mistakenly assumed it was Ubuntu (for which I've since scolded Claude). That's the only way I've ever installed the dozens of 3CX installations I've done and currently maintain.

From the hypervisor:
root@Sycamore2:~# kvm --version
QEMU emulator version 9.2.0 (pve-qemu-kvm_9.2.0-5)
Copyright (c) 2003-2024 Fabrice Bellard and the QEMU Project developers
root@Sycamore2:~#


The hypervisor version at play isn't meaningfully related to how the MCU interations work, however. I'd like to redirect the conversation towards how to process those recorded sessions before they expire.

 

[NikosT_3CX]

@Mike Hammett for the webmeeting recordings this can vary from multiple factors, like your SMTP sees the link in there
and blocks the emails.
On any case you can check the link below and retrieve them from API.
You have this option for 7 days.
Check here :

https://www.3cx.com/blog/docs/video-conference-recording/

 

[Mike Hammett]

Thanks for the link. To clarify -- this isn't an SMTP issue. The problem is that the POST https://wmr.3cx.net/manager/requestconversion call never fires at all due to the Queue Not Started exception in the GatewayService. The recording is never converted on the cloud MCU side, which is why it doesn't appear via the /webmeeting/api/v1/reports/ API endpoint -- the same endpoint your linked article references. The API only surfaces completed conversions.


Per the article, a conversion error triggers an alert to your engineers, who then reschedule. Is that process applicable here? We have 8 affected sessions from April 7-9. The recordings may still be on the MCU in an unconverted state within the 7-day window. Session IDs are available if your team can attempt manual recovery.

 

[NikosT_3CX]

@Mike Hammett in order to be sure about this, the PBX must be in Verbose mode to have a clear view of the logs and what happened.
You may open a ticket and we can check this ( if this can be replicated ) or you may get your recordings via the curl commands.