Configuration is broken for some reason… as expected. We are managing 15 BYOC trunks across APAC regions, specifically Singapore and Tokyo, and the outbound routing failover logic in Architect is behaving inconsistently. When the primary carrier (let’s call it Carrier A) returns a SIP 408 Request Timeout, the flow does not immediately pivot to the secondary carrier (Carrier B). Instead, the call hangs for approximately 12 seconds before dropping with a generic 503 Service Unavailable, bypassing the defined failover path entirely.
The environment details are as follows:
- Genesys Cloud Release: 2024.02
- BYOC Edge Version: 2.8.1
- SIP Profile: Standard TLS enabled, 5061
- Architect Flow: Simple outbound routing with a 3-second timeout on the ‘Make Call’ widget before triggering the next node.
I have verified the SIP registration status for both trunks. Carrier A is registered but exhibits high latency spikes during peak hours (09:00 - 11:00 SGT). Carrier B is registered and healthy. The issue appears to be that the BYOC Edge is swallowing the 408 response from Carrier A and not propagating it correctly to the Architect engine, or the timeout threshold on the Edge is misaligned with the flow logic.
Here is the payload configuration we are using for the outbound route:
{
"outboundRoute": {
"name": "APAC-Priority-Failover",
"trunks": [
{
"id": "trunk-sg-primary-01",
"priority": 1,
"timeoutMs": 3000
},
{
"id": "trunk-jp-secondary-02",
"priority": 2,
"timeoutMs": 3000
}
],
"failoverStrategy": "FIRST_AVAILABLE"
}
}
Has anyone else encountered this specific 408 swallowing behavior with BYOC Edges? We need the failover to trigger within the 3-second window defined in the flow, not after a 12-second delay. Any insights into the Edge’s internal retry logic or timeout handling would be appreciated.