I’m seeing an increase in ‘Ghost Calls’ in our Quality Management dashboard—these are interactions with a duration of 0 or 1 second that never reach an agent but are still counted against our Queue statistics.
Looking at the SIP traces on our BYOC-Cloud trunk (Carrier: Bandwidth), I’m seeing a lot of SIP/2.0 408 Request Timeout responses coming back from the Genesys Cloud side during the initial INVITE. It seems like the media server is failing to respond within the 4-second window.
The strange part is that this only happens during our peak hours. Is there a capacity limit on the Edge/Media tier for handling simultaneous INVITEs that could be causing this?
I’ve seen this in our multi-org setup. A 408 Request Timeout usually indicates that the signaling was received, but the internal routing (Architect or Queue logic) didn’t ‘pick up’ the call in time.
Check your Architect flows. Do you have a lot of Data Actions firing immediately upon ‘Inbound Call’? If those Data Actions are slow or timing out, they can hold up the signaling process long enough for the carrier to give up and send a CANCEL, resulting in a zero-duration ghost call in the logs.
Exactly! We had this during our migration from PureConnect. We had a Data Action hitting a slow CRM. We moved the Data Action after the initial ‘Play Audio’ (even just 1 second of silence) and the 408s dropped significantly. The ‘Play Audio’ forces the media server to establish the ‘Answer’ state, which stops the carrier’s 408 timer.
From an AWS integration perspective, make sure your Lambda or backend API isn’t hitting a cold start during those peak hours. If the first few INVITEs of a spike hit a cold Lambda, you’ll get that 4-second delay and a 408.
Also, check your ‘Max Concurrent Calls’ on the trunk. If you’re hitting your limit, Genesys should send a 503 Service Unavailable, but depending on the carrier, it might manifest as a 408 if the signaling gets stuck in a queue.