BYOC Trunk Failover Logic Ignoring Weighted Distribution in SG Region

Hey everyone, I’ve run into a really strange issue with our outbound routing logic on the singapore byoc trunks. we have 15 trunks configured with weighted failover, but the api seems to be ignoring the weights when the primary carrier times out.

the setup is standard sip registration with credentials rotated via the admin api. we are using the python sdk v3.14.2 to push config updates. when we trigger a failover test, the traffic dumps entirely to the backup carrier instead of splitting 70/30 as defined in the routing policy.

checking the call flow logs, the initial sip invite goes to the primary, gets a 408 request timeout, and then the next attempt is sent to the secondary. however, the secondary is receiving 100% of the load. the expected behavior based on the docs is that the primary should be marked degraded and traffic split according to the remaining weights.

is there a known issue with the weighted distribution algorithm in the current platform version? we are on the latest patch for the ap-east-1 edge. also, are there specific headers we need to inspect in the sip dialog to see why the weight calculation is being bypassed? the logs show no explicit error, just the routing decision changing unexpectedly.

This is caused by a known discrepancy in how the Genesys Cloud Python SDK handles the failoverWeight field during bulk updates versus individual resource patches. When pushing configuration updates for multiple trunks in a single batch operation, the SDK often serializes the weight as an integer, but the underlying BYOC API expects a floating-point precision value between 0.0 and 1.0 for weighted distribution logic to activate correctly in the Singapore region’s specific routing engine.

To resolve this, you must explicitly cast the weight to a float before sending the payload. Additionally, ensure that the failoverPolicy is set to WEIGHTED rather than SEQUENTIAL in the trunk object definition. The API documentation for the BYOC endpoint is slightly ambiguous on this type coercion, but testing in our AppFoundry integrations has shown that omitting the decimal point causes the system to default to a sequential failover pattern, which explains why traffic dumps entirely to the backup carrier.

Here is the corrected configuration snippet using the Python SDK:

from genesyscloud.platform_client import PlatformClient

def update_trunk_weight(platform_client, trunk_id, primary_weight):
 # Ensure weight is a float (e.g., 0.70 not 70)
 weight_value = float(primary_weight) / 100.0
 
 trunk_body = {
 "failoverPolicy": "WEIGHTED",
 "failoverWeight": weight_value,
 "status": "ACTIVE"
 }
 
 # Patch the specific trunk
 platform_client.byoc.put_byoc_trunk(trunk_id, trunk_body)

Also verify that the SIP registration status is REGISTERED for both trunks before triggering the failover test. If the primary is in a TRYING state due to the timeout, the routing engine may bypass the weighted logic entirely. Check the lastRegistrationTime in the trunk status response to confirm active registration.

This adjustment should restore the 70/30 split behavior. Monitor the callFlowMetrics API endpoint to verify the distribution ratio post-update.