Voice bot running Dialog Engine v2 handles initial screening. NLU slots fill correctly, then the flow hits a Transfer to Queue action. Staging works fine. Prod drops the call with SIP 408 Request Timeout right at the handoff step. Console traces show the bot finishes processing, but the SIP INVITE never actually reaches the queue.
trunk config is standard SIP-T over TLS 5061. auth headers look solid. Checked the SIP trace in the admin portal and the Via header gets rewritten twice before the timeout fires.
bumped the timeout to 60. still don’t see the INVITE leaving the edge. call just rings out on the carrier side. looks like the Genesys SIP edge isn’t releasing the media session before the INVITE goes out. prod org is AP-1, currently running v2024-07 release.
you’re likely hitting a timeout mismatch between the Dialog Engine’s internal processing window and the SIP trunk’s invite expiration. the bot finishes the NLU step, but the underlying SIP INVITE from the media server to the ACD queue isn’t getting a 100 Trying response fast enough, so the trunk drops it as a 408.
i’ve seen this exact behavior when the “Transfer to Queue” action in Architect doesn’t explicitly set a timeout property, defaulting to a value that’s too aggressive for prod latency. also, check your queue’s “Wrap-up Time” and “Skill Assignment” logic. if the queue has no available agents with the required skills, the ACD might delay the ringing, causing the upstream SIP timer to expire.
try adding a specific timeout to the transfer action in the flow JSON. here’s how that looks in the action definition:
also, verify the SIP trunk’s “Max Invite Retries” is set to at least 3. if it’s 1, any transient network blip kills the call. in the admin UI, go to Admin → Telephony → Trunks → [Your Trunk] → Advanced Settings.
another common gotcha: ensure the queue isn’t in “Closed” state during your prod tests. staging often has default open hours, but prod might be configured with strict business hours. if the queue is closed, the ACD rejects the invite immediately, which can sometimes manifest as a timeout if the rejection packet gets lost in the TLS handshake.
i’d also suggest adding a “Delay” action for 2 seconds right before the transfer. gives the SIP stack a moment to stabilize the session before firing the INVITE. ugly, but effective.
yeah, the timeout mismatch theory is solid, but if you’re seeing the INVITE rewrite twice in the Via header, that usually points to a NAT or proxy issue upstream, not just a clock skew. i’ve run into this exact headache when ingesting webhook events from GC where the signature verification fails because the timestamp drift is too large. similar principle here. the media server is trying to route the call, but the SIP stack is choking on the header manipulation.
you need to explicitly set the timeout property in your Architect flow action, but more importantly, check your trunk’s max_forwards and ttl settings. if the Via header gets rewritten, you’re likely hitting a loop or a strict proxy that’s dropping the packet before it hits the queue.
try adding this to your transfer action config in the flow JSON:
also, disable rewriteViaHeader on the trunk config if your provider allows it. GC’s default behavior can be aggressive with header cleaning. i’m using Faraday to monitor the webhook logs for similar drift issues, and setting a strict timeout on the HTTP client side usually masks the underlying SIP issue, but it’s a band-aid. you want the SIP stack to play nice.
if the 408 persists, check the tVoicemail and tContacting metrics in the conversation analytics. if they’re spiking, the bot is hanging up before the SIP handshake completes. it’s not always the queue; sometimes it’s the bot’s internal state machine timing out and sending a BYE before the INVITE gets a 200 OK. weird, i know.
408 Request Timeout. The Via header rewriting is the smoking gun. If you’re seeing that rewrite, the SIP stack is trying to loop back or correct a NAT mapping, which kills the handshake before the 100 Trying gets sent.
Since I’m piping these events into Kafka, I can confirm the architect.flow.execution topic shows the transfer action completing successfully on the Genesys side. The failure is strictly network-layer. The media server thinks it sent the invite, but the trunk proxy is dropping it because of that header bloat.
Try disabling SIP-T header preservation on the trunk config. Force it to use SIP-I instead. It strips the extra Via headers before they hit the ACD queue. I’ve seen this fix 408s on high-latency links. You lose some call context data in the trace, but the call actually connects. If you’re logging to a data lake, you can reconstruct the context from the event stream anyway. Just kill the header preservation flag.