3CX Queue Callback Not Clearing When Call Returns from External AI/SIP System (Ghost Call in Queue)

[Pat Huesers]

3CX Queue Callback Issue — Scenario Analysis & SIP Flow Sketch​

(All identifying phone numbers, IPs, and hostnames have been generalized.)

---

1. Overview of the Problem​

When callers enter the main queue and choose Queue Callback (QCB), they are prompted to verify their callback number. If they hang up before verifying, the call should terminate and be removed from the queue.

✔ Scenario 1 – Works Normally​

Caller → 3CX IVR → Main Queue → QCB prompt → Caller hangs up → Call is removed from the queue as expected.

Scenario 2 – Ghost Call Appears​

Caller → 3CX IVR → Sent to Vida AI Agent → Caller requests human → Vida sends call back to 3CX queue → Caller reaches QCB prompt → Caller hangs up before verifying → Call remains in queue and is later presented to an agent with no one there.

Both SIP legs in Scenario 2 do terminate properly, yet 3CX keeps a stale queue entry. This strongly suggests an internal 3CX queue/QCB state bug when calls come from an external SIP endpoint rather than directly from the original inbound trunk.

---

2. Key Finding​

✔​

• Carrier → 3CX leg: Carrier sends BYE, 3CX responds 200 OK
• Vida → 3CX leg: 3CX sends BYE, Vida responds 200 OK

​

This proves:

The stuck call is not due to SIP signaling but due to how 3CX manages queue/QCB state for calls arriving from an external SBC/AI agent.

---

3. SIP Flow Ladder Diagram (Generalized)​

Below is a simplified sketch showing both scenarios.

Scenario 1 — Normal (works)​

Caller Carrier SBC 3CX IVR/Queue
| INVITE --------------------------> |
| <---------- 180 Ringing ---------- |
| <----------- 200 OK -------------- |
| ACK ------------------------------>|
| |
| (Caller chooses QCB, hangs up) |
| BYE ------------------------------>|
| <----------- 200 OK -------------- |
| |
3CX removes call from queue ✓

---

Scenario 2 — With Vida (fails)​

Caller Carrier SBC 3CX IVR Vida AI 3CX Queue
| INVITE ----->| | | |
| <--- 180/200 | | | |
| ACK -------->| | | |
| |--- INVITE ----->| | |
| | |-- INVITE ---->| |
| | |<-- 180/200 ---| |
| | |--- ACK ------>| |
| | | |-- INVITE ---->|
| | | |<-- 180/200 ---|
| | | |--- ACK ------>|
| | | | |
| (Caller hangs up during QCB verify) | |
| BYE ------->| | | |
| <--- 200 OK | | | |
| (3CX ends Vida leg)
| BYE --------------------------->|
| <----------- 200 OK ------------|
| (Problem)
| Queue entry is **not** cleared

---

4. Why the Issue Occurs​

In Scenario 2, the call is not returning to 3CX as the same dialog. Instead, Vida generates a new INVITE into 3CX. When the caller hangs up:

• The original carrier leg sends BYE → 3CX → OK (clean)
• The Vida → 3CX queue leg is later terminated by 3CX sending BYE

3CX correctly ends the SIP call — but does not remove the associated queue/QCB object.

This is consistent with an internal 3CX bug in:

• QCB session tracking for calls that arrive through external SIP endpoints
• OR queue session lifecycle not correctly mapped when originating from a different trunk/path.

---

5. Summary to Post in 3CX Forums (Safe, Redacted)​

We are experiencing an issue with Queue Callback (QCB) when calls are routed through an external AI agent before re-entering our 3CX queue.

Scenario 1 (direct to queue): Caller hangs up during QCB number verification → 3CX receives BYE → 3CX removes call from queue → works normally.

Scenario 2 (via external AI): Caller goes to AI, requests a human, AI sends a new INVITE back into 3CX queue. Caller hangs up during QCB verification. Both SIP dialogs (original carrier leg and AI→3CX leg) are terminated cleanly with BYE/200 OK. However, 3CX does not remove the queue entry, and a ghost call is eventually delivered to an agent.

SIP shows:

• Original trunk call: BYE from carrier → 200 OK from 3CX
• AI→3CX queue call: BYE from 3CX → 200 OK from AI

Because all SIP sessions are correctly torn down, the issue appears to be internal to 3CX queue/QCB state handling when a queue call originates from an external SBC/AI via a new INVITE.

Has anyone seen similar behavior or is this a known limitation in QCB with re-invited external legs?

 

[fxbastler]

@Pat Huesers
A question on the side:
Does the same behavior occur when the Vida AI sends the call to a 3CX dummy extension (multiple calls allowed, the extension is not registered anywhere, immediate forwarding to the queue)?

Maybe it also requires a 3CX entity that briefly accepts the call from Vida. In that case, it would essentially be an internal call to the 3CX queue and Vida should no longer be involved.

 

[Pat Huesers]

Thanks for your message. I tested your idea, but it did the exact same thing as before. After the caller hangs up, the call remains in the queue.