Why does this config cause immediate 488 Not Acceptable Here responses when pushing concurrent SIP INVITE traffic through the BYOC edge? We are running a controlled load test using JMeter 5.6.2 with custom SIP samplers to validate the telephony capacity of our US1 Genesys Cloud instance. The goal is to hit the theoretical limit of 1000 concurrent calls per edge node, but the failures start appearing when concurrent sessions reach roughly 450. The environment uses a standard BYOC configuration with TLS 1.2 enabled and SRTP mandatory. The error occurs specifically on the initial INVITE request before any media path is established. The SIP response body contains a minimal SDP offer that seems malformed or rejected by the Genesys SIP proxy. We have checked the trunk registration status, and it remains active with a 200 OK during the test. The issue appears to be related to the simultaneous session limit enforced by the edge rather than a network timeout, as the response time is under 50ms. We are using the standard Genesys SIP URI format for routing. The load test script uses a ramp-up period of 10 minutes to gradually increase the call volume. The failure rate spikes to 80% once the threshold is crossed. We have verified that the IP addresses in the JMeter test plan are correctly whitelisted in the Genesys admin console. The error log shows no indication of certificate mismatch or authentication failure. The problem persists even when we reduce the codec complexity to G.711 only. We need to understand if this is a hard limit on the BYOC edge configuration or if there is a specific setting in the Telephony Integrations tab that needs adjustment to handle higher concurrency. The current configuration uses the default session timer values. We are looking for guidance on how to increase the effective capacity or identify the exact bottleneck causing the 488 errors. The test data includes realistic headers and payload sizes to mimic production traffic patterns. We have also checked the API rate limits for the associated webhook endpoints, but they are not being hit. The issue is isolated to the SIP signaling layer. Please advise on the correct configuration parameters to adjust for higher load scenarios.