Stumbled on a weird bug today with SIP trunk registration stability when our AppFoundry integration attempts to provision multiple trunks simultaneously across different tenant organizations. The integration is designed to automate the setup process for new clients, which involves calling POST /api/v2/telephony/sip/trunks to create the trunk entity followed by immediate configuration updates.
The issue manifests specifically when the orchestration layer triggers these API calls in parallel for a batch of new tenants. While the initial creation request succeeds with a 201 Created response, the subsequent registration attempts to the Genesys Cloud SIP edge fail intermittently. The logs from our side show a successful handshake initiation, but the server responds with a 503 Service Unavailable after approximately 500ms. This happens roughly 30% of the time during peak provisioning windows, usually between 9 AM and 11 AM PST.
We are using the latest version of the Genesys Cloud REST API SDK for Python. The OAuth tokens are valid and possess the necessary telephony:trunk:write scopes. Rate limiting headers indicate we are well within the standard limits, so throttling does not appear to be the root cause. The error payload returned by the SIP edge is minimal, providing little insight into the backend state.
SIP/2.0 503 Service Unavailable
Via: SIP/2.0/TCP 192.168.1.100:5060;branch=z9hG4bK...
From: <sip:[email protected]>;tag=12345
To: <sip:[email protected]>;tag=67890
Call-ID: abc-123-def-456
CSeq: 1 REGISTER
Content-Length: 0
Has anyone encountered similar instability with bulk SIP trunk provisioning via the API? We are investigating whether this is a transient resource exhaustion issue on the Genesys Cloud side or if there is a specific dependency or delay required between the API creation and the actual SIP registration attempt. Any insights into the internal lifecycle of a newly created SIP trunk would be appreciated.