I’m completely stumped as to why the SIP trunk registrations are failing with a 408 Request Timeout error when we push concurrent SIP UA instances above 800. We are running a load test to determine the maximum call capacity of our Genesys Cloud SIP trunk configuration. The environment is set up in the APAC region (Singapore edge). We are using a custom SIP stack written in C++ for the load generator, simulating softphone registrations. The JMeter script handles the orchestration of the SIP UAs, ramping up connections over 30 seconds. The test holds steady until the 800 concurrent user mark. After that, the SIP REGISTER requests to the Genesys Cloud SIP URI start timing out. The error logs from the SIP UAs show the 408 Request Timeout response from the Genesys Cloud SIP server. We have verified that the network latency is low and stable. The CPU and memory usage on the load generator servers are well within limits. We are not hitting any obvious rate limits on the platform API side, as this is direct SIP signaling. The Genesys Cloud SIP trunk is configured with a maximum concurrent call limit of 1000. We are using the latest version of the Genesys Cloud SDK for monitoring the registration status. The issue seems to be specific to the SIP signaling layer under high concurrency. We have tried increasing the SIP UA timeout values, but the 408 errors persist. We are also seeing some sporadic 401 Unauthorized errors during the ramp-up phase, which we believe are related to authentication token refresh delays under load. However, the primary issue is the 408 timeout. We need to understand the underlying cause of these timeouts to accurately determine the SIP trunk’s capacity. Any insights into how Genesys Cloud handles high concurrency SIP registrations would be appreciated. We are looking to optimize our load test configuration and SIP trunk settings to handle higher concurrent call volumes without these registration failures.