Just noticed that our failover logic for three specific BYOC trunks in the Singapore region is triggering 403 Forbidden responses from the carrier when the primary route fails over. The primary route handles registration perfectly fine with standard SIP digest authentication, but the moment the secondary route attempts to register, the carrier rejects the credentials immediately.
We are using the standard trunk configuration in Genesys Cloud v2.0 and the carrier documentation states they support both MD5 and SHA-256 digest algorithms. However, the logs show the request is being sent with an Authorization header that seems to be calculated based on the primary route’s realm, even though we have distinct SIP credentials configured for each route.
Is there a known issue with how the platform handles realm differentiation during failover events for BYOC trunks? We have verified the passwords are correct by testing them directly against the carrier’s test server. The error occurs consistently during our scheduled maintenance windows when we force the failover. Any insights into the digest calculation logic during route switching would be appreciated.