- Why does this config cause 408 Request Timeout errors specifically on the SIP INVITE leg when the Genesys Cloud edge receives a burst of >200 concurrent calls per second, even though the underlying SIP trunk provider confirms healthy connection states and no packet loss on their end?
- The environment is configured with the ‘Europe/London’ timezone and utilizes the latest stable release of the Genesys Cloud platform, specifically leveraging the Architect flow version 14.2 for inbound routing logic.
- The issue manifests exclusively when the ‘SIP Trunk Connection Keep-Alive’ interval is set to 60 seconds, whereas increasing this to 120 seconds temporarily stabilizes the connection but introduces latency issues in subsequent dialog legs.
- Debug logs from the Genesys Cloud side show the INVITE being sent to the upstream SIP proxy, but no 100 Trying or 180 Ringing response is received within the 3-second timeout window, leading to an immediate 408 error returned to the originating switch.
- The ServiceNow integration, which relies on a webhook payload triggered by the ‘conversation.created’ event, fails to populate the incident record because the conversation object is never fully instantiated due to the SIP handshake failure.
- We have verified that the NAT traversal settings are correct, and the RTP port range is open and correctly mapped through the firewall, ruling out basic network connectivity issues.
- The SIP trace provided by the trunk vendor shows the INVITE arriving at their ingress point, but they do not forward it further, suggesting the Genesys Cloud edge might be dropping the packet before the vendor even sees the response, or the vendor’s stateful firewall is timing out the Genesys Cloud IP due to a perceived lack of keep-alive activity.
- Is there a known limitation with the ‘SIP Trunk Connection Keep-Alive’ setting interacting with stateful firewalls in the London data center region, or should we be investigating the Architect flow’s handling of rapid-fire SIP registration updates?
- The goal is to stabilize the inbound call flow without resorting to the workaround of increasing the keep-alive interval, which negatively impacts overall call setup time and agent experience.