Configuration is broken for some reason… specifically regarding the secondary leg activation for our 15 BYOC trunks hosted in the Asia/Singapore region. We are attempting to enforce a strict failover logic where the primary carrier drops, and traffic immediately routes to the secondary SIP endpoint. However, when we simulate a primary trunk failure using the Platform API to set the status to DISABLED, the secondary trunk does not pick up the load. Instead, the outbound calls fail with a 403 Forbidden error from the carrier gateway, even though the SIP credentials for the secondary trunk are identical to the primary and verified as valid in the carrier portal.
The issue appears isolated to the failover transition window. During normal operation, both trunks register successfully. The problem manifests only when the primary trunk’s registration status flips to UNREGISTERED or FAILED. We have checked the SIP traces in the Genesys Cloud admin console, and the INVITE messages are being sent to the secondary carrier, but the response comes back immediately with a 403. This suggests a potential mismatch in the From header or the authentication challenge handling during the dynamic routing switch.
We are using the latest version of the Genesys Cloud platform, and our outbound routing policies are set to Least Cost with Failover enabled. The trunks are configured with mutual TLS, and the certificates are up to date. Here is the JSON payload we are using to update the trunk configuration via the POST /api/v2/telephony/providers/edges/{edgeId}/trunks endpoint:
{
"name": "Secondary Carrier Trunk",
"description": "Failover trunk for Asia/Singapore",
"enabled": true,
"sip_settings": {
"sip_user": "byoc_secondary_user",
"sip_password": "secure_pass_123",
"sip_server": "sip.secondarycarrier.com",
"sip_port": 5061,
"transport": "TLS",
"registration": {
"enabled": true,
"expiry": 3600
}
},
"routing": {
"type": "FAILOVER",
"priority": 2
}
}
Has anyone encountered this specific 403 error during BYOC trunk failover? We need to ensure high availability for our call center operations, and this blocker is preventing us from completing our quarterly disaster recovery tests. Any insights into the SIP authentication behavior during dynamic routing changes would be greatly appreciated.