Intermittent IVR Silence - Strange VCE Timing Pattern, Looking for Insights

[phillytky]

Environment:

• 3CX Version: 20.0.7.1080 (Update 7 Hotfix)
• Platform: Azure VM (Linux)
• Trunk: SIP provider via UDP (Telnyx)
• Issue: IVR occasionally answers calls but plays no greeting (caller hears silence)

Background:I've had a few reports of inbound calls routing to our IVR (Digital Receptionist) but callers hearing silence instead of the greeting. Most calls work perfectly fine. I finally got a reproducible case where our VP called the same DID three times in a row:

• Call 1: Rang, answered, silence, hung up after ~20 seconds
• Call 2: Rang, answered, silence, hung up after ~20 seconds
• Call 3: Rang, answered, greeting played normally

All three calls were from the same caller to the same DID within 90 seconds, so I dug into the logs to see what was different.

What I Found (and I'm not sure if I'm interpreting this correctly):

Looking at the CallFlow and MediaServer logs, all three calls show identical routing and an identical strange pattern. In the CallFlow log, all three show:

Proceed to prompt:(False)
Call finished with result=(null)
Waiting for the end of call

But the successful call still played the greeting even with that "False" evaluation.

The MediaServer logs show what I think might be the issue. On all three calls, the IVR endpoint gets created, then immediately removed while waiting for the Voice Compose Engine (3cxVCE) to respond, then rejoined when VCE answers. The RACETRACKER entries show this happening:

Failed - Call 1:

11:19:33.881 - EP joined to call, then immediately removed
[289ms gap]
11:19:34.170 - EP rejoined, VCE answered, state ACTIVE

Failed - Call 2:

11:19:57.614 - EP joined to call, then immediately removed
[199ms gap]
11:19:57.813 - EP rejoined, VCE answered, state ACTIVE

Successful - Call 3:

11:20:52.619 - EP joined to call, then immediately removed
[67ms gap]
11:20:52.685 - EP rejoined, VCE answered, state ACTIVE

The "Proceed to promptFalse)" evaluation happens during the gap when the endpoint is removed. On the successful call, the gap was only 67ms. On the failed calls, it was 199-289ms.

My Theory (but I could be wrong):It seems like when the IVR call flow evaluates whether to play the prompt, it checks if the media channel is ready. If VCE is slow to respond (200ms+), the IVR sees no active media channel during that gap and decides not to play anything. Even after the endpoint becomes ACTIVE moments later, it never recovers. When VCE responds quickly (<100ms), everything works.

Questions:

1. Am I reading these logs correctly? Is this actually a race condition with VCE response timing?
2. Has anyone else seen intermittent IVR silence that resolves on retry?
3. Is there any configuration that affects how long the IVR waits for media channel readiness?
4. Why would VCE response time vary so much between identical calls seconds apart?

I haven't had time to dig into the other reported incidents yet to see if they show the same pattern. Just trying to figure out if I'm on the right track here or completely misunderstanding what these logs are telling me.

Any insights would be greatly appreciated. Happy to provide more detailed log excerpts if anyone thinks they can help troubleshoot this.

 

[KyriacosS_3CX]

Without going to deep into things, what are the specs if the VM? How is the load/disk space on it?

 

[VoIPTools]

I was going to ask similar questions about the resources on the server. I've been implementing 3CX for nearly 20 years and have never seen or heard of similar problems PROVIDED you have sufficient hardware.

I would also ask whether you are using supported SIP trunks. You did not mention the use of a Call Flow Designer, so I assume we are talking about a standard Digital Receptionist.

 

[phillytky]

Without going to deep into things, what are the specs if the VM? How is the load/disk space on it?

We are using the Standard B2s which has 2 vCPUs, 4GiB RAM, 30GB Premium SSD LRS (IOPS 120, Throughput MBps 25, Disk tier P4 running on Linux Debian 12. Load is within spec and not outside the ordinary. Disk space is ok.

 

[phillytky]

I was going to ask similar questions about the resources on the server. I've been implementing 3CX for nearly 20 years and have never seen or heard of similar problems PROVIDED you have sufficient hardware.

I would also ask whether you are using supported SIP trunks. You did not mention the use of a Call Flow Designer, so I assume we are talking about a standard Digital Receptionist.

The hardware is sufficient from my understanding and experience, but I just replied to the previous poster with an answer. Let me know what you think. We are using FlowRoute and Telnyx with this customer. We do have a very basic CFD setup for a 3rd party CRM popup URL manipulation, but it doesn't run on this trunk.

 

[KyriacosS_3CX]

Perhaps a packet capture would help, at least to see where the audio is getting lost. Is it not getting played, or being lost along the way?