Hey everyone, I’ve run into a really strange issue with our BYOC trunk configuration while stress-testing the new inbound routing logic for a multi-tenant AppFoundry integration. The environment is Genesys Cloud v2.24.0, and we are using the standard SIP trunk setup with our own SIP registrar.
During our load test, which simulates approximately 150 concurrent inbound calls per second, roughly 15% of the SIP INVITE requests are failing with a 503 Service Unavailable response. This happens even though the trunk capacity in the Genesys admin console shows available channels. The 503 responses are not consistent; they appear sporadically, often clustered in bursts of 5-10 failures within a 2-second window.
We have verified that our SIP registrar is healthy and not dropping packets. The issue seems to be on the Genesys edge side, as the 503 is returned directly from the Genesys SIP proxy. The error occurs before any Architect flow execution begins, suggesting it is a connection or resource allocation issue rather than a logic error in the flow.
Here is a sample of the SIP INVITE header we are sending:
{
"from": {
"displayName": "Test Caller",
"uri": "sip:[email protected]"
},
"to": {
"displayName": "Genesys Target",
"uri": "sip:[email protected]"
},
"contact": "sip:[email protected]",
"callId": "unique-call-id-123",
"cseq": "1 INVITE",
"contentType": "application/sdp",
"body": "v=0\r\no=- 123456 123456 IN IP4 192.168.1.1\r\ns=-\r\nc=IN IP4 192.168.1.1\r\nt=0 0\r\nm=audio 4000 RTP/AVP 0\r\na=rtpmap:0 PCMU/8000"
}
We have checked the API logs for the trunk and do not see any explicit rate limit errors (429s) on the /api/v2/telephony/providers/edges endpoint. Is there a known limitation on concurrent SIP session establishment on the Genesys edge for BYOC trunks? Or could this be related to the SIP registrar’s keepalive settings conflicting with Genesys’s expected session timeout? Any insights on how to debug this further would be appreciated.