How come this setting causes 403 Forbidden errors when scaling SIP trunk registrations? The environment is Genesys Cloud US1. The goal is to simulate 100 concurrent SIP endpoints registering to the BYOC edge. The OAuth token refresh works fine for the initial batch, but as the JMeter thread group ramps up, the registration requests fail.
- Genesys Cloud US1
- JMeter 5.6
- Endpoint: /api/v2/telephony/sip/trunks/{trunkId}/registrations
- Config: 100 concurrent threads, 5 second ramp-up
- Error: 403 Forbidden - Access Denied
The error message indicates an authentication failure, yet the tokens are valid for the first 20 requests. The subsequent requests return 403 immediately. The JMeter script uses the same client ID and secret for token generation. The load pattern is steady, not bursty. The BYOC edge status shows healthy connections.
Is there a hidden rate limit on SIP registration endpoints? The documentation does not specify a concurrent registration limit. The API returns 403 instead of 429. This makes it hard to distinguish between permission issues and rate limiting. The test fails after 30 seconds. The goal is to validate the system can handle 100 registrations in 5 seconds. The current setup fails. The logs show no server-side errors. The issue seems to be on the Genesys Cloud side. The request payload is standard. The headers are correct. The timeout is set to 30 seconds. The connection pool is sufficient. The problem persists across multiple test runs. The environment is dedicated. The load is isolated. The issue is reproducible. The fix is unknown. The workaround is to reduce concurrency. This is not a viable solution for production scale. The team needs a reliable way to test high-volume SIP registrations. The current approach is flawed. The error is misleading. The documentation is unclear. The support ticket is pending. The deadline is close. The pressure is high. The result is negative. The expectation is positive. The reality is harsh. The question remains. Why does this happen?