can anyone clarify why our sip trunk registration state flips between registered and unregistered every 30 seconds after we push a configuration update via the platform api?
we are building a premium appfoundry integration that dynamically updates sip trunk settings based on customer contract tiers. the app uses the /api/v2/telephony/providers/edges/siptrunks/{trunkId} endpoint to modify the authentication credentials and codec preferences. we are running this against the us-east-1 region, targeting multiple orgs via our multi-org oauth flow. the sdk version in use is genesys-cloud@2.13.0 for node.js.
the issue manifests immediately after the put request returns a 204 no content status. the sip trunk logs in the admin console show a 401 unauthorized challenge from our pstn provider, followed by a successful re-registration, only to drop again shortly after. this cycle repeats indefinitely, causing significant call drop rates for our clients.
we have verified that the credentials being pushed are correct and that the rate limits on the api side are not being hit. the integration handles token refresh correctly, as confirmed by our previous posts on oauth issues. the problem seems isolated to the timing of the configuration propagation versus the sip registrar’s cache invalidation.
has anyone encountered a race condition where the platform api accepts the new config but the underlying sip edge service retains stale credentials for a brief period, causing the registrar to reject the initial re-registration attempt? we are considering adding a delay before the trunk attempts to re-register, but that feels like a workaround rather than a solution. any insights into the internal sync mechanism between the platform api and the sip edge services would be appreciated. we need a reliable way to ensure the trunk is stable before routing live traffic.